bug#53511: guix pull command fails

[Maxime Devos]

xdrcft56 schreef op ma 24-01-2022 om 23:35 [+]:
> Thank you.  I've attached the requested log file 
> (/var/log/guix/drvs/aj/mmafhpmi83ssxg860wd93z9yhhhk5w-gcc-10.3.0.drv.bz2).

‘collect2: fatal error: ld terminated with signal 9 [Killed]’

this could indicate an out-of-memory situation, which Guix cannot
really do anything about.   If it is a OOM, the dmesg should contain a
message about it (I don't know exactly how it looks like).  A future
OOM can be avoided by closing some memory intensive applications (e.g.
most web browsers) and reducing the number of cores used for building:
"guix pull --cores=2 --max-jobs=1".

In principle, it could be something else though.  Can you reproduce
with "guix pull --cores=2 --max-jobs=1"?

Also, I'm noticing you are building everything from source.
To avoid having to build things (and hence reduce the chance of
an OOM) (and save energy), I recommend enabling and authorising
substitutes.

Greetings,
Maxime.


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

bug#53514: Guix should not set global variables that may affect host

[Liliana Marie Prikler]

Hi,

Am Montag, dem 24.01.2022 um 17:24 -0500 schrieb Maxim Cournoyer:
> Hello!
> 
> There are multiple reports about the negative effects of Guix setting
> variables such as XDG_DATA_DIRS on foreign distributions, that may
> cause problems a severe as locking users out of their graphical
> session [0].
> 
> In my opinion, we should pursue patching every application/library to
> use a Guix-specific variant, e.g. GUIX_XDG_DATA_DIRS instead of
> XDG_DATA_DIRS, to avoid interfering with the host system, as was done
> for GUIX_PYTHONPATH.
> 
> This is a big task in itself; we can open more focused/actionable
> tasks for each environment variable, starting with those causing the
> most serious issues.
> 
> Any takers?
I'm not convinced that patching XDG_DATA_DIRS is a good solution here.
Even if we go forward and implement this for each and every
library/application, (it would be reasonably simple to do so for glib
and qt at least, but there's many more consumers, including Guix
itself), we'd just force users on foreign distros to set up their
XDG_DATA_DIRS for us if they e.g. want to have desktop icons available,
so they'd quickly encounter the same issue on their own.

I see two ways forward for this:  First, "ignore it" and just document
the behaviour.  This isn't just a bug Guix is suffering from, it also
affects other third-party package installers like Flatpak and Snap. 
Since distros increasingly become aware of them, this will soon no
longer be an issue for most our users.  Second, extend search-paths
with a way of enforcing a default value when none is set.  This way,
Guix will still override XDG_DATA_DIRS, but since
$HOME/.local/share:/usr/share is set as the default as per spec, it
will do what the distro expected.

WDYT?

bug#53355: guix shell --check: confusing error message

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> Ludovic Courtès  writes:
>
>> What’s confusing is that ‘--check’ does the same job whether or not
>> ‘--container’ is passed: it checks the behavior of your shell *outside*
>> a container.
>>
>> I think ‘--check’ should just do nothing when ‘--container’ is used,
>> possibly emitting a warning saying it’s not doing anything (patch
>> below).
>>
>> Now, the diagnostic is hopefully correct if you use, say, ‘--pure’
>> instead of ‘--container’.  Could you check whether this is the case?
>
> That sounds reasonable.  I tested your patch.  It now correctly emits a
> warning when both --container and --check are provided.

Great, I’ll commit it.

> First, I tried without --pure or --container.  Below, you can see that
> it claims LIBRARY_PATH is missing, but it does not seem to be missing:

[...]

> Next, I tried with --pure and --check - once again, it claims
> LIBRARY_PATH is missing, even though it does not seem to be missing:

It looks like the shell-check machinery is misdiagnosing things, as
Vagrant reported in  (is this on
Debian too?).

Could you try the debugging tricks I proposed there?

TIA,
Ludo’.

bug#53406: union-build incorrectly handles grafts

[Ludovic Courtès]

Hi John,

John Kehayias  skribis:

> Yes, that makes sense, thank you for clarifying. So this is the currently 
> expected behavior. Ideally grafting would be smarter to maybe avoid this 
> (missing changes in e.g. version number)? But I would guess this is not 
> something that would be expected to cause a problem for the vast majority of 
> cases, as you explain, and adds complexity to the process.

I don’t think it can be smarter; grafting is just text substitution, it
knows nothing about the files it’s fiddling with (with the exception of
debugging sections in ELF files).

> Perhaps I was too hasty in noting this "problem" which like I said was not 
> the error I originally encountered. I was using a package that constructs 
> both the 64- and 32-bit libraries to put in a container (say, a /lib32 and 
> /lib64 or something similar to an FHS environment). A collision was happening 
> between a file and directory, one being a good symlink and the other broken, 
> rather than a "real" mismatch in file vs directory. Anyway, going back to 
> that what I see is that one link is broken for the above reasons, but the 
> good one is good because it is to the *ungrafted* library store path. I don't 
> know now if these 2 things are connected other than one led me to the other, 
> but I turn now to what demonstrates my original problem.
>
> I don't know why this happens or if it is something in this building process 
> that is not correct, but I did come up with a minimal example (attached). The 
> code is a bit odd in its stripped down form, though hopefully is clear in 
> what way this would be used to do something useful (again, like an FHS 
> environment or other container). Apologies for the old style and lack of 
> gexps which I'm finally getting used to. The example package just tries to 
> make a dummy package that has, for illustration, a "/lib64" and "/lib32" 
> which link to the respective union-build inputs (of a single library for 
> simplicity). I don't think the actual package being made matters so much, or 
> how it is constructed, but that two inputs are union-builds of the same 
> library (x86_64 and i686) which should have a graft of expat. Just my guess 
> though.
>
> Doing:
>
> ls -la $(guix build -f graft-test.scm)/lib64/lib/libexpat*
> lrwxrwxrwx 1 root root 71 Dec 31  1969 
> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.la
>  -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la*
> lrwxrwxrwx 1 root root 71 Dec 31  1969 
> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so
>  -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so*
> lrwxrwxrwx 1 root root 73 Dec 31  1969 
> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1
>  -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1*
> lrwxrwxrwx 1 root root 77 Dec 31  1969 
> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1.8.1
>  -> 
> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.1
>
> is what we saw already: libexpat is the newer (replacement, 2.4.3) version, 
> with the full version symlink broken since the version number is wrong. 
> Likewise in other pieces that have the version number, like share/doc. Okay, 
> that's expected. But now, in the i686-linux union-build input:
>
> ls -la $(guix build -f graft-test.scm)/lib32/lib/libexpat*
> lrwxrwxrwx 1 root root 71 Dec 31  1969 
> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.la
>  -> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.la*
> lrwxrwxrwx 1 root root 71 Dec 31  1969 
> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so
>  -> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so*
> lrwxrwxrwx 1 root root 73 Dec 31  1969 
> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1
>  -> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so.1*
> lrwxrwxrwx 1 root root 77 Dec 31  1969 
> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1.8.1
>  -> 
> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so.1.8.1*
>
> all the links are good and to the original (version 2.4.1) expat. In other 
> words, the constructed union64 and union32 inputs (in the sample code) do not 
> both get grafted, even though doing just the fhs-union command on it's own 
> (not building both for another package) does graft for either architecture. 
> At least that seems like the most obvious difference between the earlier 
> example and this new one.
>
> Why? Does the grafting just happen "once" somehow and misses the "same" input 
> again (but built for different system)? Is this expected or just a 
> weird/wrong way to do this kind of build which is causing this? I'm not sure 
> if this is just with union-build or

bug#53194: System test partition.img differs in size across hosts(?)

[Maxim Cournoyer]

Hi Tobias,

[...]

> diff --git a/gnu/build/image.scm b/gnu/build/image.scm
> index bdd5ec25a9..81caa424f8 100644
> --- a/gnu/build/image.scm
> +++ b/gnu/build/image.scm
> @@ -3,7 +3,7 @@
>  ;;; Copyright © 2016 Christine Lemmer-Webber 
>  ;;; Copyright © 2016, 2017 Leo Famulari 
>  ;;; Copyright © 2017 Marius Bakke 
> -;;; Copyright © 2020 Tobias Geerinckx-Rice 
> +;;; Copyright © 2020, 2022 Tobias Geerinckx-Rice 
>  ;;; Copyright © 2020 Mathieu Othacehe 
>  ;;;
>  ;;; This file is part of GNU Guix.
> @@ -62,8 +62,10 @@ (define (size-in-kib size)
>  
>  (define (estimate-partition-size root)
>"Given the ROOT directory, evaluate and return its size.  As this doesn't
> -take the partition metadata size into account, take a 25% margin."
> -  (* 1.25 (file-size root)))
> +take the partition metadata size into account, take a 25% margin.  As this in
> +turn doesn't take any constant overhead into account, force a 1-MiB minimum."
> +  (max (ash 1 20)
> +   (* 1.25 (file-size root
>  
>  (define* (make-ext-image partition target root
>   #:key

Looks reasonable to me (although it is interesting that the behavior is
not the same across machines...).

While at it, you may want to fix this docstring:

--8<---cut here---start->8---
 (define (file-size file)
-  "Return the size of bytes of FILE, entering it if FILE is a directory."
+  "Return the size in bytes of FILE, entering it if FILE is a directory."
   (file-system-fold (const #t)
 (lambda (file stat result);leaf
   (+ (stat:size stat) result))
--8<---cut here---end--->8---

in guix/build/store-copy.scm.

Thanks!

Maxim

bug#53511: guix pull command fails

[xdrcft56 via Bug reports for GNU Guix]

I attempted the "guix pull --cores=2 --max-jobs=1" command as root and received 
the following output and error:

Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: Git error: error inflating zlib stream

I also ran "guix archive --authorize < 
~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub" in order enable and 
authorize a substitute but received the same error as above upon running "guix 
pull --cores=2 --max-jobs=1" subsequently.

Finally, I reviewed dmesg and saw no change during the course of executing 
these commands.

‐‐‐ Original Message ‐‐‐

On Tuesday, January 25th, 2022 at 2:59 AM, Maxime Devos 
 wrote:

> xdrcft56 schreef op ma 24-01-2022 om 23:35 [+]:
>
> > Thank you. I've attached the requested log file 
> > (/var/log/guix/drvs/aj/mmafhpmi83ssxg860wd93z9yhhhk5w-gcc-10.3.0.drv.bz2).
>
> ‘collect2: fatal error: ld terminated with signal 9 [Killed]’
>
> this could indicate an out-of-memory situation, which Guix cannot
>
> really do anything about. If it is a OOM, the dmesg should contain a
>
> message about it (I don't know exactly how it looks like). A future
>
> OOM can be avoided by closing some memory intensive applications (e.g.
>
> most web browsers) and reducing the number of cores used for building:
>
> "guix pull --cores=2 --max-jobs=1".
>
> In principle, it could be something else though. Can you reproduce
>
> with "guix pull --cores=2 --max-jobs=1"?
>
> Also, I'm noticing you are building everything from source.
>
> To avoid having to build things (and hence reduce the chance of
>
> an OOM) (and save energy), I recommend enabling and authorising
>
> substitutes.
>
> Greetings,
>
> Maxime.

bug#53533: [DISCUSSION] Quality of services in reproducible build environment Guix

[Sharlatan Hellseher]

Hi Guix team!

The current QA for the accepted changes in Gujx is far away from
trustible. For example, some
changes in package update may cause a faileur of the whole chain of
packages depending on it. It
would be nice to have some soft policy of changes, check list or some
procedure to have a "stable"
branch which may guarantee all packages build successfully and pass of
all enabled tests.

I find current [[id:60941898-0ed4-4188-b473-d2dcda158d61][CI/CD]]
(https://ci.guix.gnu.org/) is missleading in case of providing some
visibility
of all successful builds for the current pushed changes (on master
branch). I would like to conclude
from the CI is which commit broke how many packages. Other open
question - if I've sticked to a
specific "stable" branch how I may be sure that another ~guix pull~
will not break my packages in
case of un-pinned version?

Some missing features of CI
- Timing - current view has missing a clear representation of build date-time
- Overall slats for the current commit to the specific branch - and
how many package are become
  broken after update of package X.
- Sort of "blocking on merge" of a commit which causes some issues (do
not merge broken packages
  into stable branch)
- Some documentation for all UI features (green dots, red dots, grey dots etc.
  https://ci.guix.gnu.org/eval/54326/dashboard)

Some missing practice of packaging:
- Some essential message of the reason why tests were disabled and any
sort of suggestions on how to
  make them enabled. Contact upstream if required.
- Before sending patch make sure (at least for the localhost
architecture) it's built, linted and in
  case of bumping version - all dependent chain still can be built.

Related commits and issues which broke other packages in ~master~ branch:
- https://issues.guix.gnu.org/53230
- fix 6445f412b993ec7b52dc4c81e99f49af38b3a967 RawTherapee stopped
building with wrong configure key,
  the previous update to 5.8 was never tested before been merged.

  #+begin_src sh
git checkout master
git pull
git log -n1 --pretty="%h %s %cd - %cn"
  #+end_src
  : 4235c6ee92 gnu: QGIS: Build without QtWebKit. Tue Jan 25 15:10:19
2022 -0500 - Leo Famulari

  Excess changes which could be prevented with just local attempt to build
  #+begin_src sh
git log --grep="Fix build" --pretty="%h %s %cd - %cn" | wc -l
  #+end_src
  : 1025


-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#53515: Solarus Quest Editor makes new quests read-only

[Nicolas Goaziou]

Hello,

Jesse Gibbons  writes:

> 1. Launch solarus-quest-editor (in package solarus-quest-editor)
>
> 2. File->New quest...
>
> 3. Make a new directory for the quest,  select that directory, click "Open"
>
> A dialog pops up with an error like the following:
>
> *
>
> I believe this is likely because it recursively copies a template from
> /share/solarus-quest-editor/assets/initial_quest/ relative to the
> installed solarus-quest-editor to the destination and keeps
> permissions.

Confirmed.

It may be worth reporting it upstream. Do you want to take care of it?

Regards,
-- 
Nicolas Goaziou

bug#53415: binutils-mesboot1-2.14 configure phase fails, In procedure stat: No such file or directory: "config.status"

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> I've seen this failure consistently on one of the machines behind
> bordeaux.guix.gnu.org, you can see the full logs via following the "View
> build" links here [1].
>
> 1: 
> http://data.guix.gnu.org/gnu/store/xd8rnmr0k3fhfhilzi66hnggsnx67d5i-binutils-mesboot1-2.14.drv
>
> I've tried building multiple times on the machine where the failures
> occurred, and it's not once succeeded.
>
>>From looking at the kept build directory, the config.status file doesn't
> exist. There is config.status.VX1nZz, but it's empty.
>
>
>
> starting phase `configure'
> running ./configure --disable-nls --disable-shared --disable-werror 
> --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu --with-sysroot=/ 
> --prefix=/gnu/store/gvmha2v54svwzxigcbap8862rg3fya0w-binutils-mesboot1-2.14
> error: in phase 'configure': uncaught exception:
> system-error "stat" "~A: ~S" ("No such file or directory" "config.status") 
> (2) 
> phase `configure' failed after 0.0 seconds

I just tried this on my laptop:

  guix build \
/gnu/store/xd8rnmr0k3fhfhilzi66hnggsnx67d5i-binutils-mesboot1-2.14.drv \
--check

and the ‘configure’ phase completes without problems.  I have:

--8<---cut here---start->8---
$ uname -srv
Linux 5.15.12-gnu #1 SMP 1
--8<---cut here---end--->8---

This reminds me of:

  https://issues.guix.gnu.org/49985
  https://issues.guix.gnu.org/45165

Could it be something with the kernel options, as discussed at
?

Thanks,
Ludo’.

bug#53157: guix/ui.scm:203 requires guile-3.0.3

[Ludovic Courtès]

Hi Efraim,

Ludovic Courtès  skribis:

> Efraim Flashner  skribis:
>
>> I'm using ./pre-inst-env on my powerpc-linux machine, using guile-3.0.2
>> as provided by Debian. When I try to run the following command:
>> ./pre-inst-env guix build -L /path/to/repo -m /path/to/manifest.scm -n
>> I get the following error:
>>
>> guix/ui.scm:230:13: error: default-optimization-level: unbound variable
>>
>> It doesn't make sense to gate this with (target-ppc32?) since it's due
>> to the guile version. If I had configured within 'guix shell -D guix' I
>> would be using guile-3.0.7.
>>
>> configure.ac checks for guile 3.0.
>
> I’m in favor of updating ‘configure.ac’ to check for Guile > 3.0.x
> (we’ll have to check which value of ‘x’ works).

As you suggested on IRC, I went ahead and did that in commit
d582b399781f6fd80c63d07746524196603972e4.

Thanks,
Ludo’.

bug#53514: Guix should not set global variables that may affect host

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

> Hi,
>
> Am Montag, dem 24.01.2022 um 17:24 -0500 schrieb Maxim Cournoyer:
>> Hello!
>> 
>> There are multiple reports about the negative effects of Guix setting
>> variables such as XDG_DATA_DIRS on foreign distributions, that may
>> cause problems a severe as locking users out of their graphical
>> session [0].
>> 
>> In my opinion, we should pursue patching every application/library to
>> use a Guix-specific variant, e.g. GUIX_XDG_DATA_DIRS instead of
>> XDG_DATA_DIRS, to avoid interfering with the host system, as was done
>> for GUIX_PYTHONPATH.
>> 
>> This is a big task in itself; we can open more focused/actionable
>> tasks for each environment variable, starting with those causing the
>> most serious issues.
>> 
>> Any takers?
> I'm not convinced that patching XDG_DATA_DIRS is a good solution here.
> Even if we go forward and implement this for each and every
> library/application, (it would be reasonably simple to do so for glib
> and qt at least, but there's many more consumers, including Guix
> itself), we'd just force users on foreign distros to set up their
> XDG_DATA_DIRS for us if they e.g. want to have desktop icons available,
> so they'd quickly encounter the same issue on their own.

They may end up doing so, but at least they wouldn't be locked out of
their graphical session just for installing a package from Guix, which
is a clear improvement over the current situation.

> I see two ways forward for this:  First, "ignore it" and just document
> the behaviour.  This isn't just a bug Guix is suffering from, it also
> affects other third-party package installers like Flatpak and Snap.
>
> Since distros increasingly become aware of them, this will soon no
> longer be an issue for most our users.  Second, extend search-paths
> with a way of enforcing a default value when none is set.  This way,
> Guix will still override XDG_DATA_DIRS, but since
> $HOME/.local/share:/usr/share is set as the default as per spec, it
> will do what the distro expected.

That sounds good to, and should be easier to achieve.

Thanks,

Maxim

bug#53533: [DISCUSSION] Quality of services in reproducible build environment Guix

[Leo Famulari]

On Tue, Jan 25, 2022 at 08:45:22PM +, Sharlatan Hellseher wrote:
> Related commits and issues which broke other packages in ~master~ branch:
> - https://issues.guix.gnu.org/53230
> - fix 6445f412b993ec7b52dc4c81e99f49af38b3a967 RawTherapee stopped
> building with wrong configure key,
>   the previous update to 5.8 was never tested before been merged.

The previous update of the Rawtherapee package happened in February
2020, almost two years ago. It was definitely tested at that time. Since
then, some other changes in the distro broke it.

>   #+begin_src sh
> git checkout master
> git pull
> git log -n1 --pretty="%h %s %cd - %cn"
>   #+end_src
>   : 4235c6ee92 gnu: QGIS: Build without QtWebKit. Tue Jan 25 15:10:19
> 2022 -0500 - Leo Famulari
> 
>   Excess changes which could be prevented with just local attempt to build
>   #+begin_src sh
> git log --grep="Fix build" --pretty="%h %s %cd - %cn" | wc -l
>   #+end_src
>   : 1025

Can you say what this shell snippet means?

bug#53533: [DISCUSSION] Quality of services in reproducible build environment Guix

[Leo Famulari]

On Tue, Jan 25, 2022 at 08:45:22PM +, Sharlatan Hellseher wrote:
> The current QA for the accepted changes in Gujx is far away from
> trustible. For example, some
> changes in package update may cause a faileur of the whole chain of
> packages depending on it. It
> would be nice to have some soft policy of changes, check list or some
> procedure to have a "stable"
> branch which may guarantee all packages build successfully and pass of
> all enabled tests.

People are definitely supposed to check that their changes don't break
things before they push them, but it doesn't always happen.

It's not easy to make sure that all packages build successfully. I've
never seen 100% of packages build successfully since I joined Guix in
2015. It's a nice goal but it requires some work... a lot more work.
Everyone is invited to help. Probably, the first step is to remove
several hundred packages that don't build; it might even be a couple
thousand.

> I would like to conclude from the CI is which commit broke how many
> packages.

Agreed, this is a very important missing feature. Also, we need the
capability to compare commits in terms of CI results.

Our CI software is called Cuirass:

https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git

We need more people to help develop Cuirass!

> Some missing practice of packaging:
> - Some essential message of the reason why tests were disabled and any
> sort of suggestions on how to
>   make them enabled. Contact upstream if required.

Everyone is supposed to do this when writing packages. It's a failure of
the code review process if that is not happening.

> - Before sending patch make sure (at least for the localhost
> architecture) it's built, linted and in
>   case of bumping version - all dependent chain still can be built.

This is supposed to be done for patches that go to the master branch.
That is, patches that affect <300 packages. Other patches that affect
more than 300 packages are batched on development branches such as
'core-updates' [0], and then we need a lot of Guix contributors to help
get all the packages building again. Maybe we should remove broken
packages more casually, like I suggested above.

>   Excess changes which could be prevented with just local attempt to build
>   #+begin_src sh
> git log --grep="Fix build" --pretty="%h %s %cd - %cn" | wc -l
>   #+end_src
>   : 1025

We have 92225 commits total:

--
$ git log --oneline | wc -l
92225
--

So, about 1.1% of them are "Fix build" commits.

However, not all of these commits were made on the master branch. Many
of them are on development branches such as 'core-updates' and
'staging', and so users never experienced the problems that were fixed.

That doesn't mean that Guix QA is perfect, but rather that your
measurement is inaccurate and misleading.

[0] To learn more about development branches like core-updates, see
item 8:
https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

bug#53541: backtrace during fresh Guix System install during formatting

[bdju]

On Tue Jan 25, 2022 at 9:21 PM CST, bdju via Bug reports for GNU Guix wrote:
> Using a "latest" installer image from the last day or two
> Picture of error taken with my phone attached (eh, what can ya do?)
>
> >Device /dev/sdc is still in use.
>
> This sticks out and appears in a couple spots.
if I don't view the details of /boot it tells me it can't read
/dev/sda1 and to format it, then if I select it, it
becomes ext4 by default and format is set to no

Should the boot partition be fat32, ext4, or could it even be btrfs? I'm
doing an encrypted install and I want btrfs for the root partition.

bug#53543: kmessagelib fails to build

[Leo Famulari]

For as long as ci.guix.gnu.org keeps history (that is, December 2021),
kmessagelib fails to build, as shown below.

This breaks kmail, kmailcommon, and akregator.

--
[ 66%] Building CXX object 
messagecomposer/src/snippet/autotests/CMakeFiles/convertvariablesjobtest.dir/convertvariablesjobtest.cpp.o
cd 
/tmp/guix-build-kmessagelib-20.04.1.drv-0/build/messagecomposer/src/snippet/autotests
 && /gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin/c++ 
-DBUILD_TESTING -DKCOREADDONS_LIB -DKF_DEPRECATED_WARNINGS_SINCE=0x06 
-DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_GUI_LIB -DQT_NETWORK_LIB 
-DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_CAST_TO_ASCII 
-DQT_NO_DEBUG -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_SIGNALS_SLOTS_KEYWORDS -DQT_NO_URL_CAST_FROM_STRING 
-DQT_STRICT_ITERATORS 
-DQT_TESTCASE_BUILDDIR=\"/tmp/guix-build-kmessagelib-20.04.1.drv-0/build\" 
-DQT_TESTLIB_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB 
-DTRANSLATION_DOMAIN=\"libmessagecomposer\" -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/tmp/guix-build-kmessagelib-20.04.1.drv-0/build/messagecomposer/src/snippet/autotests
 
-I/tmp/guix-build-kmessagelib-20.04.1.drv-0/messagelib-20.04.1/messagecomposer/src/snippet/autotests
 
-I/tmp/guix-build-kmessagelib-20.04.1.drv-0/build/messagecomposer/src/snippet/autotests/convertvariablesjobtest_autogen/include
 -I/tmp/guix-build-kmessagelib-20.04.1.drv-0/build/messagecomposer/src 
-I/tmp/guix-build-kmessagelib-20.04.1.drv-0/messagelib-20.04.1/messagecomposer/src
 -I/tmp/guix-build-kmessagelib-20.04.1.drv-0/build/messagecore/src 
-I/tmp/guix-build-kmessagelib-20.04.1.drv-0/messagelib-20.04.1/messagecore/src 
-I/tmp/guix-build-kmessagelib-20.04.1.drv-0/build/messageviewer/src 
-I/tmp/guix-build-kmessagelib-20.04.1.drv-0/messagelib-20.04.1/messageviewer/src
 -I/tmp/guix-build-kmessagelib-20.04.1.drv-0/build/mimetreeparser/src 
-I/tmp/guix-build-kmessagelib-20.04.1.drv-0/messagelib-20.04.1/mimetreeparser/src
 -isystem /gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/include/qt5 
-isystem 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/include/qt5/QtTest 
-isystem 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/include/qt5/QtCore 
-isystem 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/qt5/mkspecs/linux-g++
 -isystem 
/gnu/store/cnimk54z2bh2m7r5s8kx0666qdkrq5py-kmime-20.04.1/include/KF5/KMime 
-isystem /gnu/store/cnimk54z2bh2m7r5s8kx0666qdkrq5py-kmime-20.04.1/include/KF5 
-isystem 
/gnu/store/8634m469lclyd1m9fqj7a40c30dkhf5g-kpimcommon-20.04.1/include/KF5/PimCommon
 -isystem 
/gnu/store/8634m469lclyd1m9fqj7a40c30dkhf5g-kpimcommon-20.04.1/include/KF5/pimcommon
 -isystem 
/gnu/store/8634m469lclyd1m9fqj7a40c30dkhf5g-kpimcommon-20.04.1/include/KF5 
-isystem 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/include/qt5/QtNetwork 
-isystem 
/gnu/store/7iycanrjj90k6y02jwapp5jsl02sa4g8-kio-5.70.1/include/KF5/KIOCore 
-isystem /gnu/store/7iycanrjj90k6y02jwapp5jsl02sa4g8-kio-5.70.1/include/KF5 
-isystem 
/gnu/store/x7hfkl6807xp23xiica95xvk1jhyqxq4-kcoreaddons-5.70.0/include/KF5/KCoreAddons
 -isystem 
/gnu/store/x7hfkl6807xp23xiica95xvk1jhyqxq4-kcoreaddons-5.70.0/include/KF5 
-isystem 
/gnu/store/qy075f1x3gmzywhwqd5lpabann5bd2dr-kservice-5.70.0/include/KF5/KService
 -isystem 
/gnu/store/qy075f1x3gmzywhwqd5lpabann5bd2dr-kservice-5.70.0/include/KF5 
-isystem 
/gnu/store/l5f203bk2pwdclrvrgy64mgn2103i5jc-kconfig-5.70.0/include/KF5/KConfigCore
 -isystem 
/gnu/store/l5f203bk2pwdclrvrgy64mgn2103i5jc-kconfig-5.70.0/include/KF5 -isystem 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/include/qt5/QtConcurrent
 -isystem 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/include/qt5/QtDBus 
-isystem 
/gnu/store/iwyybzykgw12ib9vj3mbkshmp1gl4ijy-kconfigwidgets-5.70.0/include/KF5/KConfigWidgets
 -isystem 
/gnu/store/iwyybzykgw12ib9vj3mbkshmp1gl4ijy-kconfigwidgets-5.70.0/include/KF5 
-isystem 
/gnu/store/f1zypajmalnv5ln75l29d2m28nf8lcrc-kcodecs-5.70.0/include/KF5/KCodecs 
-isystem /gnu/store/f1zypajmalnv5ln75l29d2m28nf8lcrc-kcodecs-5.70.0/include/KF5 
-isystem 
/gnu/store/9wwh9bx42cl4acanm2mzpw8l0jhlzac6-kwidgetsaddons-5.70.0/include/KF5/KWidgetsAddons
 -isystem 
/gnu/store/9wwh9bx42cl4acanm2mzpw8l0jhlzac6-kwidgetsaddons-5.70.0/include/KF5 
-isystem 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/include/qt5/QtWidgets 
-isystem 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/include/qt5/QtGui 
-isystem 
/gnu/store/l5f203bk2pwdclrvrgy64mgn2103i5jc-kconfig-5.70.0/include/KF5/KConfigGui
 -isystem 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/include/qt5/QtXml 
-isystem 
/gnu/store/bzkimf70laxf0pv5r3a3w7j3g7hiddff-kauth-5.70.0/include/KF5/KAuth 
-isystem /gnu/store/bzkimf70laxf0pv5r3a3w7j3g7hiddff-kauth-5.70.0/include/KF5 
-isystem 
/gnu/store/7gj34bdvhz67whn6l8ag894g8yb8lwli-akonadi-20.04.1/include/KF5/AkonadiCore
 -isystem 
/gnu/store/p0apw6

bug#53214: Release 1.4.0 progress

[Leo Famulari]

There are new crashes in the installer:

https://issues.guix.gnu.org/53541
https://issues.guix.gnu.org/53544

bug#53519: python-seaborn build failure

[Arun Isaac]

Hi Bonface,

It looks like this problem is due to matplotlib 3.5.x and is known
upstream. See
https://github.com/mwaskom/seaborn/issues/2663 . We might have to wait
for an upstream release or cherry pick commits.

Regards,
Arun


signature.asc
Description: PGP signature

bug#53547: Error sending email with OpenSMTPD, fatal: time_to_text: bsnprintf

[Timmy Douglas via Bug reports for GNU Guix]

I recently installed opensmtpd and have been trying to send email. It
appears there is an error with the bsnprintf function:

$ ./sendmail -t
To: timmy
From: me 
Subject: hi

aoeueou
(press ^D)
sendmail: time_to_text: bsnprintf

I reported this issue here:
https://github.com/OpenSMTPD/OpenSMTPD/issues/1166

mcron appears to invoke sendmail with `-t`, which is how I discovered
the issue.

If anyone is trying to figure out how to setup the setuid on Guix
system, here is my config.scm file (I couldn't find anything online so
maybe this will help):

(operating-system
 ; ...
   (append (list (setuid-program
  (program (file-append opensmtpd "/sbin/smtpctl"))
  (setuid? #f)
  (setgid? #t)
  (user "root")
  (group "smtpq"))
 (setuid-program
  (program (file-append opensmtpd "/sbin/sendmail"))
  (setuid? #f)
  (setgid? #t)
  (user "root")
  (group "smtpq")))
   %setuid-programs))

I tried building the latest opensmtpd from git, which required a few
other changes to patch the bug:



diff --git a/usr.sbin/smtpd/smtpc.c b/usr.sbin/smtpd/smtpc.c
index 49750dca..4ed506dc 100644
--- a/usr.sbin/smtpd/smtpc.c
+++ b/usr.sbin/smtpd/smtpc.c
@@ -114,8 +114,8 @@ parse_tls_options(char *opt)
servname = value;
break;
case -1:
-   if (suboptarg)
-   fatalx("invalid TLS option \"%s\"", suboptarg);
+ //if (suboptarg)
+ //fatalx("invalid TLS option \"%s\"", suboptarg);
fatalx("missing TLS option");
}
}
diff --git a/usr.sbin/smtpd/smtpctl.c b/usr.sbin/smtpd/smtpctl.c
index 00c49cb7..3630ef1d 100644
--- a/usr.sbin/smtpd/smtpctl.c
+++ b/usr.sbin/smtpd/smtpctl.c
@@ -52,6 +52,8 @@
 #endif
 #include 
 
+#include 
+
 #include "smtpd.h"
 #include "parser.h"
 #include "log.h"
diff --git a/usr.sbin/smtpd/to.c b/usr.sbin/smtpd/to.c
index 3ea04d89..9928d09b 100644
--- a/usr.sbin/smtpd/to.c
+++ b/usr.sbin/smtpd/to.c
@@ -176,7 +176,7 @@ const char *
 time_to_text(time_t when)
 {
struct tm *lt;
-   static char buf[40];
+   static char buf[50];
char *day[] = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
char *month[] = {"Jan","Feb","Mar","Apr","May","Jun",
 "Jul","Aug","Sep","Oct","Nov","Dec"};
@@ -193,6 +193,9 @@ time_to_text(time_t when)
 #elif defined HAVE_DECL_ALTZONE && defined HAVE_DECL_TIMEZONE
offset = lt->tm_isdst > 0 ? altzone : timezone;
tz = lt->tm_isdst > 0 ? tzname[1] : tzname[0];
+#else
+   offset = 0;
+   tz = "GMT";
 #endif
 
/* We do not use strftime because it is subject to locale substitution*/