Re: Questions reqarding packaging and conventions

[Leo Famulari]

On Wed, Jun 02, 2021 at 07:55:31AM +0200, Ignacio Coterillo wrote:
> I'm trying to debug and fix issues with Kerberos based authentication on both 
> Icecat and
> qutebrowser and got a few questions:
> 
> Via strace I found that icecat tries load `libgssapi.so` which doesn't exist.
> 
> Trivially creating the file as a symbolic link to the `libgssapi_krb5.so` 
> provided
> 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?

If the mit-krb5 authors aim to provide libgssapi.so, then we should
adjust our package to achieve that. Otherwise, I'd guess it's a problem
in icecat / firefox. Do you know what other distros do?

> - 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))

That would work, but like I said above, the mit-krb5 build scripts
should have a way to do this, or it's likely a change to be made in the
icecat package.

>   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:
> 
>   ❯ ls -l 
> /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi*
>   lrwxrwxrwx 3 root root 21 Jan  1  1970 
> /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so
>  -> libgssapi_krb5.so.2.2
>   lrwxrwxrwx 3 root root 21 Jan  1  1970 
> /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-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/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so.2.2
>   lrwxrwxrwx 7 root root 82 Jan  1  1970 
> /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi.so 
> -> 
> /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-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?

Not sure, but I agree that it should be a relative link, if adjusting
mit-krb5 is the solution we choose.

> qutebrowser Kerberos support comes from `qtwebengine`. The only change needed 
> would
> be to add `mit-krb5` as input and add the "--webengine-kerberos=yes" qmake 
> option in its
> `configure` build phase.

Sounds good.

> My question here is about whether there is any policy requiring formal 
> justification to
> increase the number of dependencies of a certain package or this would be 
> considered a valid
> request/patch.

There's no policy. In general, we aim to provide fully-featured
packages, but that is an informal habit rather than a strict guideline.

Re: Ungrafting CI jobs

[Leo Famulari]

On Wed, Jun 02, 2021 at 07:53:35PM +0200, Mathieu Othacehe wrote:
> I monitored a previous evaluation of the ungrafting Cuirass
> specification that was more successful, with more than 17000 builds
> performed in less than 24 hours, a new record! The recent evaluation is
> sadly less victorious.

Yeah, it was great for a while!

> I need to perform a reconfigure / deploy but I'm waiting to have a few
> days ahead of me to fix potential issues.

Okay. Can you let me know when you do? I'll delay the ungrafting builds
until then.

Re: Rust freedom issue claim

[Bone Baboon]

Ludovic Courtès writes:
> Before triggering an alarm, I would check what major distros, and Debian
> in particular, are doing about Rust; I have not heard of any concerns so
> far.  If the Rust trademark turns out to be a concern, distros should
> try hard, collectively, to resolve it through dialog with Rust
> Foundation people.

I started a thread about the Rust trademark policy on the debian-legal
mailing list.


I participated in the Free Software Foundation's most recent Free
Software Directory meeting.  Several participants in the meeting where
interested in the Rust trademark policy.  I started a thread on the
directory-discuss mailing list as was suggested in the meeting.


The Free Software Foundation's licensing team will be taking a serious
look at the Rust trademark policy issue (no time frame was given).


After reading further on the topic and receiving feedback I have written
an update to my understanding of the Rust trademark policy.

Re: GNU Guix 1.3.0rc2 available for testing!

[Chris Marusich]

Hi Maxim,

Maxim Cournoyer  writes:

> Sorry for the delayed answer.

No worries!  I've waited even longer in replying to you now, so we're
even.  :-)

> The go importer depends on a recent version of guile-lib (0.2.7), which
> added a new #:strict argument to the HTML parser.  We should probably
> skip the test depending on the already available HAVE_GUILE_LIB Automake
> conditional, like so:
>
> modified   Makefile.am
> @@ -457,7 +457,6 @@ SCM_TESTS =   \
>tests/git-authenticate.scm \
>tests/glob.scm \
>tests/gnu-maintenance.scm  \
> -  tests/go.scm   \
>tests/grafts.scm   \
>tests/graph.scm\
>tests/gremlin.scm  \
> @@ -505,6 +504,10 @@ SCM_TESTS =  \
>tests/uuid.scm \
>tests/workers.scm
>  
> +if HAVE_GUILE_LIB
> +SCM_TESTS += tests/go.scm
> +endif
> +
>  if BUILD_DAEMON_OFFLOAD
>  SCM_TESTS  += tests/offload.scm
>  else
>
> Could you give the above a try?  Feel free to commit it if it works as
> expected.

I tested this, and it works.  Thank you!  I can now build the release
(with this change) and run the tests (make check) successfully;
tests/go.scm is just omitted from the tests to run.

By chance, I noticed the following lines below what you added:

--8<---cut here---start->8---
if HAVE_GUILE_LIB
SCM_TESTS += tests/go.scm
endif

if BUILD_DAEMON_OFFLOAD
SCM_TESTS  += tests/offload.scm
else
EXTRA_DIST += tests/offload.scm
endif
--8<---cut here---end--->8---

I guess that if we omit tests/go.scm from SCM_TESTS, it not only means
that the test won't be run, but it also means the test won't get
included in the tarball distribution ("make dist").  Is that right?  It
seems undesirable to omit this test from the distribution just because
the machine on which the distribution was built might have lacked the
library necessary to run the test.  Someone who builds Guix from the
distribution might actually have that library installed and thus be able
to run the test.  To ensure that this test always gets included in the
distribution, perhaps we should also add it to EXTRA_DIST like so:

--8<---cut here---start->8---
diff -u a/Makefile.am b/Makefile.am
--- a/Makefile.am   2021-05-11 11:09:31.0 -0700
+++ b/Makefile.am   2021-06-02 12:55:06.134793001 -0700
@@ -457,7 +457,6 @@
   tests/git-authenticate.scm   \
   tests/glob.scm   \
   tests/gnu-maintenance.scm\
-  tests/go.scm \
   tests/grafts.scm \
   tests/graph.scm  \
   tests/gremlin.scm\
@@ -505,6 +504,12 @@
   tests/uuid.scm   \
   tests/workers.scm
 
+if HAVE_GUILE_LIB
+SCM_TESTS += tests/go.scm
+else
+EXTRA_DIST += tests/go.scm
+endif
+
 if BUILD_DAEMON_OFFLOAD
 SCM_TESTS  += tests/offload.scm
 else
--8<---cut here---end--->8---

What do you think?

-- 
Chris


signature.asc
Description: PGP signature