bug#37790: MANPATH missing from non-default profile

[zimoun]

Hi Maxim,

On Thu, 3 Mar 2022 at 07:26, Maxim Cournoyer  wrote:

> tags 37790 notabug

>From my understanding, it is a "bug" as explained here:

1: 

Or at least an inconvenient behaviour. :-)


> >> I agree it’s inconvenient, but how would you add an exception?
> >
> > I'm not too sure how Guix works here, but what about when building the
> > profile, systematically populating etc/profile with MANPATH=...?
>
> I don't think special casing ~/.guix-profile like this, polluting other
> profiles is a good idea.

It appears to me the contrary, no?  That ~/.guix-profile is special here.

Well, using a multi-profiles style management, it appears to me
adequate to install "man" (or man-db) once, i.e.,  in one profile say
~/.cache/guix/profiles/utilities, and then install other packages, say
git, in another profile, say ~/, .cache/guix/profiles/tools, etc.

With the current design, each profile other than ~/.guix-profile
requires 'man-db' which seems unfortunate, non?


Cheers,
simon

bug#54234: Dropping versioned docdir for license files?

[Maxim Cournoyer]

Hello Guix,

Recently while packaging sysbench, I noticed that the gnu-build-system's
docdir expands to 'share/doc/name', while the 'install-license-files'
phase installs the license files to 'share/doc/name-version' instead:

--8<---cut here---start->8---
$ find /gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/bin
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/bin/sysbench
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/etc
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/etc/ld.so.cache
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/doc
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/doc/sysbench
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/doc/sysbench/manual.html
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/doc/sysbench-1.0.20
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/doc/sysbench-1.0.20/COPYING
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/bulk_insert.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/oltp_delete.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/oltp_insert.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/oltp_read_only.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/oltp_point_select.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/oltp_update_index.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/oltp_read_write.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/oltp_update_non_index.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/select_random_points.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/select_random_ranges.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/oltp_write_only.lua
/gnu/store/97q84ivbx8xa2lm3pn4pyb3i96n58i5g-sysbench-1.0.20/share/sysbench/oltp_common.lua
--8<---cut here---end--->8---

It seems to me it'd be nicer to have both agree on the same docdir.  We
could drop the version and use gnu-build-system's docdir, or alter the
default gnu-build-system docdir to use a versioned output.  The later
some more troublesome, as we'd have to do the same adjustment for each
build system, and I'm not convinced of the value added.  So I'd suggest
we simply normalize to use the standard docdir.

What do you think?

Thanks,

Maxim

bug#37790: MANPATH missing from non-default profile

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi Maxim,
>
> On Thu, 3 Mar 2022 at 07:26, Maxim Cournoyer  
> wrote:
>
>> tags 37790 notabug
>
> From my understanding, it is a "bug" as explained here:
>
> 1: 
>
> Or at least an inconvenient behaviour. :-)

Sorry, I fail to see where is the bug :-).  This is our the search-path
specifications have always worked; they work per profile and are
attached to the application acting as the "consumer" of the environment
variable it sets.

If we want to work on improving this we already have the following
issues opened awaiting work:

20255 'search-paths' should respect both user and system profile.

and somewhat related:

22138 Search paths of dependencies are not honored

Thanks,

Maxim

bug#54234: Dropping versioned docdir for license files?

[Maxime Devos]

Maxim Cournoyer schreef op do 03-03-2022 om 08:37 [-0500]:
> It seems to me it'd be nicer to have both agree on the same docdir.  We
> could drop the version and use gnu-build-system's docdir, or alter the
> default gnu-build-system docdir to use a versioned output.  The later
> some more troublesome, as we'd have to do the same adjustment for each
> build system, and I'm not convinced of the value added.  So I'd suggest
> we simply normalize to use the standard docdir.
> 
> What do you think?

This does not really answer your question, but if we do this, we could
combine this with another change:

Some software does not work with a COPYING or LICENSE file, or they do
but also have other relevant licenses.  E.g., gnunet-scheme follows
REUSE and puts the license texts in a LICENSES directory and some extra
information in '.reuse/dep5'.  It would be nice if those were copied
as well.

Also, to partially answer your question: probably not all
gnu-build-system packages actually implement the 'docdir' option
and might even error out if it is passed.  Fixing these build failures
might be tedious.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#54234: Dropping versioned docdir for license files?

[Maxim Cournoyer]

Hi Maxime,

Maxime Devos  writes:

> Maxim Cournoyer schreef op do 03-03-2022 om 08:37 [-0500]:
>> It seems to me it'd be nicer to have both agree on the same docdir.  We
>> could drop the version and use gnu-build-system's docdir, or alter the
>> default gnu-build-system docdir to use a versioned output.  The later
>> some more troublesome, as we'd have to do the same adjustment for each
>> build system, and I'm not convinced of the value added.  So I'd suggest
>> we simply normalize to use the standard docdir.
>> 
>> What do you think?
>
> This does not really answer your question, but if we do this, we could
> combine this with another change:
>
> Some software does not work with a COPYING or LICENSE file, or they do
> but also have other relevant licenses.  E.g., gnunet-scheme follows
> REUSE and puts the license texts in a LICENSES directory and some extra
> information in '.reuse/dep5'.  It would be nice if those were copied
> as well.

What is REUSE?

> Also, to partially answer your question: probably not all
> gnu-build-system packages actually implement the 'docdir' option
> and might even error out if it is passed.  Fixing these build failures
> might be tedious.

Even the packages using their own configure script probably would
install their doc under /share/doc/$name/ as this is the standard on FHS
distribution.  I'm not suggesting to tweak docdir, I'm suggesting to use
the default, non-versioned value.

Thanks,

Maxim

bug#54234: Dropping versioned docdir for license files?

[Maxime Devos]

Maxim Cournoyer schreef op do 03-03-2022 om 10:44 [-0500]:
> What is REUSE?

See .  It's a specification + tool based on
SPDX.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#54061: thermald-2.4.7 build fail following upower update to 0.99.15

[Paul Jewell]

Good afternoon,

Thanks Ludo, and also Maxime and Guillaume.

Upstream have also merged a fix to the original problem, so I guess the 
change made here can be removed again after the next release.


Best regards,
Paul

On 02/03/2022 17:03, Ludovic Courtès wrote:

Hi,

Maxime Devos  skribis:


 From d066a7dcd11757fb19edc79028104f7dbcffeab1 Mon Sep 17 00:00:00 2001
From: Maxime Devos
Date: Sat, 19 Feb 2022 14:52:17 +
Subject: [PATCH 2/2] gnu: thermald: Fix build failure.

* gnu/packages/admin.scm (thermald)[arguments]<#:configure-flags>: Add
'--disable-werror'.

Fixes:
Reported-by: Paul Jewell

Guillaume fixed it independently in commit
73db69bea15e390a31289fdfadb1d5b9a7d13557.

Closing!

Ludo’.

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Jacob MacDonald]

Jesse wrote:
> I do not know if this is specific to guix or a problem generally with Calibre 
> 5.36.

As far as I can tell, it's a problem introduced by Guix, as I noticed
it occurring with Calibre 5.21. For what it's worth, I have the latest
working version that I can find installed.

guix time-machine --commit=b603554ed044638dd40b6863d5dada59eefe03b8 --
package -i calibre

Leo:

I've continued to attempt the last bisect I mentioned, but I'm bogged
down by repeated build errors that force me to skip more commits than
I can test. Is there a trick to building the commits which got merged
in; Do they not work with time-machine? The errors I'm seeing are of
the form:

guix time-machine: error: You found a bug: the program
'/gnu/store/mqhfdbrl834biajwq667fzsck344g09s-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"b2b799e2d8330af934f48bf66afb5114addb4dd7"; system: "x86_64-linux";
host version: "1af78ab5e80b98d1914b85709c60fa7f9782e1db"; pull-version: 1).
Please report it by email to .

That latest failure seems to be related to tcsh, but that's not the
only derivation which has failed for me in the same way.