From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id cl82IA6Lt2AOZAEAgWs5BA (envelope-from ) for ; Wed, 02 Jun 2021 15:43:42 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 0Ea5Gg6Lt2DuUgAAbx9fmQ (envelope-from ) for ; Wed, 02 Jun 2021 13:43:42 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 09D1A13976 for ; Wed, 2 Jun 2021 15:43:42 +0200 (CEST) Received: from localhost ([::1]:60832 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loR9p-0003sM-36 for larch@yhetil.org; Wed, 02 Jun 2021 09:43:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51792) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loKXq-0008BD-Tw for guix-devel@gnu.org; Wed, 02 Jun 2021 02:40:02 -0400 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:37831) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loKXo-0000Cl-Ka for guix-devel@gnu.org; Wed, 02 Jun 2021 02:40:02 -0400 Received: by mail-wr1-x433.google.com with SMTP id q5so1065193wrs.4 for ; Tue, 01 Jun 2021 23:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:message-id:mime-version; bh=2cRwihgleEp9/ZphG4GwHdXG1zk7gCPzaBaLyyJEWmg=; b=CTzNj77uTnfylak0Zk7cvHKi5xk5BnEZdWogqPQvFFzWRjEfHZeX6YOjgs3BT0IeWE oOKXCgp+H+e93oGnActmqgGROe4bsE/UJqTJ0yMZWnWsK39gQrcXs4r09+5woDWqz/+N GyUPispdbO+uqqFvblU9zIn5rBTZmkPJ/XBULC9MS6WR+gKVW1izGMGVmfUEIhz3m9LM rA1FE48RrJoeicS46HgV6TNdtsl38fkuFMEucGUzbnK4Zu7ma1yWcw0yRAY938ecK+I5 ctlYYA8IzZmdzNzylkTF98njIFJcnqcHr2m2hfTk5kiRWi5ozOt6olxu5QefzJKuKDJC 9F7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:message-id :mime-version; bh=2cRwihgleEp9/ZphG4GwHdXG1zk7gCPzaBaLyyJEWmg=; b=L3RyLdnFjIoz5TtE8QPPaRBo3quKCbrNDVX4NsGjJKodi9LExdSmZ8bwqvR3fkhnCi YWYy5Ia2zWTT0iFBnICmGvavwFjNbEYm7xd1Z3mbHDzeZXLEJmjDPCPcKjLrels2sWeA dgYhb/K+R8nQm8J+NflpcSuy1T2Cakxm5RO1WC5BWjnos4YhULkXWeiYsD1yM6uVhFe+ m9bXBsPf1otJ6gp4KF303KcgpOVsb4CAh+syk0sYv/GDlXm1Gp3mngdSXnjtPKTBmtR/ PqEfp8Bvo6UcAhR+bU8jWr3kkYuY9C9GVPW5F5rkLDSIbBqIuybuxL34pmie5SJ1R5rE D6tw== X-Gm-Message-State: AOAM531/QHkk6KG3CRDaPXcuP93BJQ+aPsnGZ4MXpHYVSJaOYKj7jUVA YqnqimFVwdJnifLH07LLQpIbBZxLbDA= X-Google-Smtp-Source: ABdhPJxI8TLH8fevsXz9UeaFTsQmr7x3ukzIyaKuUx6J4ltZ9oz4PkPKzu6QglVShMVqMPIpz4eFHA== X-Received: by 2002:a5d:6984:: with SMTP id g4mr19527606wru.7.1622615998068; Tue, 01 Jun 2021 23:39:58 -0700 (PDT) Received: from cern.ch (84-74-112-29.dclient.hispeed.ch. [84.74.112.29]) by smtp.gmail.com with ESMTPSA id p1sm1603683wmc.11.2021.06.01.23.39.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jun 2021 23:39:57 -0700 (PDT) From: Ignacio Coterillo To: guix-devel@gnu.org Subject: Questions reqarding packaging and conventions Date: Wed, 02 Jun 2021 07:55:31 +0200 User-agent: mu4e 1.4.15; emacs 28.0.50 Message-ID: <87eedk22ir.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=ignacio.coterillo@gmail.com; helo=mail-wr1-x433.google.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 02 Jun 2021 09:43:29 -0400 X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1622641422; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=2cRwihgleEp9/ZphG4GwHdXG1zk7gCPzaBaLyyJEWmg=; b=CvKEtP0C+flQjWWaws1q8UaJulyHwnQkQuO/+tEn46bCElbamP4C1fr4jzy1xifQWGJPN/ ee51FYY24cVGfxS839eb431GWoZPjjHa+E6mR8qFZaPBEeqtt2ZUEbhH5DNrzmYmQly9wN O7+uC9tAUmxWqb8Q9uA3SgM6YvWR3PgpzHbuu8QWauDs77tSxrmV8uNfIsOjksx0xz9eiN Bs4KwOZSQOIcUGuQrNExAr6LA8g84qG6zNBeuFhRV2t/zUz26tyb9sz5lhjkNcCZQOA48e y4N/PiI5spxeqazjGu+x7pM+rmkah1Wvl+0UnfPv662IhZdHEUx9cBR3RJvB4w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1622641422; a=rsa-sha256; cv=none; b=lQ3dFrOu8iJC0+MnejAv8NWYDh78tUFKDGC8FebV2KmnMjNJfl1+c5gL6wQ7A2c0H3bPEe ejlLzrNK08A0s29ifDW2sfz1Qg/zvyfWKUJYUxDcIZI1/8b6kHB8H8GUfa1L/+/QOXjSqc Eb1Fbe2PcqUqE4t0Jn8niZLfHsY/95WxA3DksZwWmL54Ml/ePWyvRdqGJKGkNr1BGuEdD8 QU8VnMiYqiOu1PfZzG1zLvl9C3KmBKx1sqHh0/owxHhrXnW4LYfm21EnoJVJ/qUWz3Fl/S 1lv+3RVefqaNtpH0b0V/IuCAKXmIDizj0MX5xCXbRdUTXIrpqDAeeenWwPIfbg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=CTzNj77u; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -1.93 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=CTzNj77u; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 09D1A13976 X-Spam-Score: -1.93 X-Migadu-Scanner: scn0.migadu.com X-TUID: MIdsHvliXSps --=-=-= Content-Type: text/html; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hello,

I=E2=80=99m trying to debug and fix issues with Kerberos based authenticati= on on both Icecat and qutebrowser and got a few questions:

Via strace I found that icecat tries load `libgssapi.so` which doesn=E2=80= =99t exist.

Trivially creating the file as a symbolic link to the `libgssapikrb5.s= o` provided by the `mit-krb5` package and exposing via LDLIBRARYPATH solves the issue and fixes Kerberos based authentication.

  • Qu= estion 1: Should this be fixed in the mit-krb5 package or in the icecat pac= kage?

  • Question 2: What would be the best way of creating this link in a package?

    I=E2=80=99ve played with creating a modified `mit-krb5` (i.e. `my-mit-krb5`= ) with the following additional build phase:

    (modify-phases %standard-phases (add-after =E2=80=99install =E2=80=99create-link (lambda _ (let* ((libpath (getenv =E2=80=9Cout=E2=80=9D)) (origin (format #f =E2=80=9C~a/lib/libgssapikrb5.so= =E2=80=9D libpath)) (target (format #f =E2=80=9C~a/lib/libgssapi.so=E2=80=9D libpat= h))) (symlink origin target)) #t))

    This works, but creates the link with full path target instead of relative = like the rest of links created naturally by the original build process:

    =E2=9D=AF ls -l /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.1= 8/lib/libgssapi* lrwxrwxrwx 3 root root 21 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv= 859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapikrb5.so -> libgssap= ikrb5.so.2.2 lrwxrwxrwx 3 root root 21 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv= 859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapikrb5.so.2 -> libgss= apikrb5.so.2.2 -r=E2=80=93r=E2=80=93r=E2=80=93 2 root root 380520 Jan 1 1970 /gnu/store/= irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapikrb5.so= .2.2 lrwxrwxrwx 7 root root 82 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv= 859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi.so -> /gnu/store/irhvqdpc4zvy= j9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapikrb5.so

    Should I try to `chdir` to the path before creating the link, or is there a= cleaner way of doing something like this?

qutebrowser Kerberos support comes from `qtwebengine`. The only change need= ed would be to add `mit-krb5` as input and add the =E2=80=9C=E2=80=93webengine-kerbe= ros=3Dyes=E2=80=9D qmake option in its `configure` build phase.

My question here is about whether there is any policy requiring formal just= ification to increase the number of dependencies of a certain package or this would be c= onsidered a valid request/patch.

Best regards,

Ignacio

--=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I'm trying to debug and fix issues with Kerberos based authentication on bo= th Icecat and qutebrowser and got a few questions: Via strace I found that icecat tries load `libgssapi.so` which doesn't exis= t. Trivially creating the file as a symbolic link to the `libgssapi_krb5.so` p= rovided by the `mit-krb5` package and exposing via LD_LIBRARY_PATH solves the issue= and fixes Kerberos based authentication. - Question 1: Should this be fixed in the mit-krb5 package or in the icecat= package? - Question 2: What would be the best way of creating this link in a package? I've played with creating a modified `mit-krb5` (i.e. `my-mit-krb5`) with= the following additional build phase: (modify-phases %standard-phases (add-after 'install 'create-link (lambda _ (let* ((libpath (getenv "out")) (origin (format #f "~a/lib/libgssapi_krb5.so" libpath)) (target (format #f "~a/lib/libgssapi.so" libpath))) (symlink origin target)) #t)) This works, but creates the link with full path target instead of relativ= e like the rest of links created naturally by the original build process: =E2=9D=AF ls -l /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1= .18/lib/libgssapi* lrwxrwxrwx 3 root root 21 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514= lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so -> libgssapi_krb5.so.2= .2 lrwxrwxrwx 3 root root 21 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514= lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so.2 -> libgssapi_krb5.so= .2.2 -r--r--r-- 2 root root 380520 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514= lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so.2.2 lrwxrwxrwx 7 root root 82 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514= lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi.so -> /gnu/store/irhvqdpc4zvyj= 9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so Should I try to `chdir` to the path before creating the link, or is there= a cleaner way of doing something like this? qutebrowser Kerberos support comes from `qtwebengine`. The only change need= ed would be to add `mit-krb5` as input and add the "--webengine-kerberos=3Dyes" qmak= e option in its `configure` build phase. My question here is about whether there is any policy requiring formal just= ification to increase the number of dependencies of a certain package or this would be c= onsidered a valid request/patch. Best regards, Ignacio --=-=-=--