bug#44491: Support GUIX_DISABLE_NETWORK_TESTS environment variable

[Vagrant Cascadian]

On 2020-11-10, Vagrant Cascadian wrote:
> On 2020-11-10, Ludovic Courtès wrote:
>> Vagrant Cascadian  skribis:
>>> On 2020-11-08, Ludovic Courtès wrote:
 Vagrant Cascadian  skribis:

> If this could be considered for the upcoming 1.2 release, that would be
> appreciated, though I can also carry the patches in Debian...

 Yay!  It should be doable, let’s see.
>>>
>>> It seems like a simpler workaround is to pass RES_OPTIONS=attempts:0,
>>> which should disable name resolution, and thus the network checks will
>>> fail.
>>>
>>> With the RES_OPTIONS workaround, the changes to guix/tests.scm
>>> network-reachable are no longer needed ... i think. :)
>>
>> Oooh nice, the wonders of glibc!
>>
>>> Might still be worth refactoring some of *.sh tests to use common
>>> functions, since the code is basically copied and pasted in several
>>> different places.
>>
>> Yes, that’s still a good idea.  Would you like to adjust your patch
>> accordingly?
>
> Thanks for the review!
>
> Updated patch attached, with changes:
>
> * Copyright header added to common.sh.
> * New function skip_if_network_unreachable in common.sh
> * Dropped GUIX_DISABLE_NETWORK_TESTS in favor of using
>   RES_OPTIONS=attempts:0.
> * Updated tests to use skip_if_network_unreachable or network_reachable.

...

> diff --git a/tests/common.sh b/tests/common.sh
> new file mode 100644
> index 00..f9dd3c2c59
> --- /dev/null
> +++ b/tests/common.sh
...
> +network_reachable() {
> +if ! guile -c '(getaddrinfo "www.gnu.org" "80" AI_NUMERICSERV)' 2> 
> /dev/null; then
> +return 0
> +fi
> +}

Ooops. I inverted that check... probably "if guile -c ..." and probably
should return 1 or something if it isn't... or maybe 77?


anyways... testing again.


live well,
  vagrant


signature.asc
Description: PGP signature

bug#44491: Support GUIX_DISABLE_NETWORK_TESTS environment variable

[Vagrant Cascadian]

On 2020-11-10, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> On 2020-11-08, Ludovic Courtès wrote:
>>> Vagrant Cascadian  skribis:
>>>
 If this could be considered for the upcoming 1.2 release, that would be
 appreciated, though I can also carry the patches in Debian...
>>>
>>> Yay!  It should be doable, let’s see.
>>
>> It seems like a simpler workaround is to pass RES_OPTIONS=attempts:0,
>> which should disable name resolution, and thus the network checks will
>> fail.
>>
>> With the RES_OPTIONS workaround, the changes to guix/tests.scm
>> network-reachable are no longer needed ... i think. :)
>
> Oooh nice, the wonders of glibc!
>
>> Might still be worth refactoring some of *.sh tests to use common
>> functions, since the code is basically copied and pasted in several
>> different places.
>
> Yes, that’s still a good idea.  Would you like to adjust your patch
> accordingly?

Thanks for the review!

Updated patch attached, with changes:

* Copyright header added to common.sh.
* New function skip_if_network_unreachable in common.sh
* Dropped GUIX_DISABLE_NETWORK_TESTS in favor of using
  RES_OPTIONS=attempts:0.
* Updated tests to use skip_if_network_unreachable or network_reachable.


live well,
  vagrant

From 3fd93fec957491450639c647e05a5f72f1e787fd Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 10 Nov 2020 19:26:04 -0800
Subject: [PATCH] tests: Add common functions for to check for network
 reachability.

* tests/common.sh: New file.
* tests/guix-build-branch.sh, tests/guix-pack.sh,
  tests/guix-package-net.sh: Use skip_if_network_unreachable function
  from common.sh.
* tests/guix-environment.sh: Use network_reachable function from
  common.sh.
---
 Makefile.am|  1 +
 tests/common.sh| 30 ++
 tests/guix-build-branch.sh |  8 ++--
 tests/guix-environment.sh  |  5 ++---
 tests/guix-pack.sh |  5 ++---
 tests/guix-package-net.sh  |  9 ++---
 6 files changed, 39 insertions(+), 19 deletions(-)
 create mode 100644 tests/common.sh

diff --git a/Makefile.am b/Makefile.am
index e7053ee4f4..7dbe41201c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -599,6 +599,7 @@ EXTRA_DIST +=		\
   tests/test.drv	\
   tests/signing-key.pub	\
   tests/signing-key.sec	\
+  tests/common.sh	\
   tests/cve-sample.json	\
   tests/civodul.key	\
   tests/rsa.key		\
diff --git a/tests/common.sh b/tests/common.sh
new file mode 100644
index 00..f9dd3c2c59
--- /dev/null
+++ b/tests/common.sh
@@ -0,0 +1,30 @@
+# GNU Guix --- Functional package management for GNU
+# Copyright © 2018, 2019, 2020 Ludovic Courtès 
+# Copyright © 2020 Vagrant Cascadian 
+#
+# This file is part of GNU Guix.
+#
+# GNU Guix is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or (at
+# your option) any later version.
+#
+# GNU Guix is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Guix.  If not, see .
+
+network_reachable() {
+if ! guile -c '(getaddrinfo "www.gnu.org" "80" AI_NUMERICSERV)' 2> /dev/null; then
+return 0
+fi
+}
+
+skip_if_network_unreachable() {
+	if ! network_reachable ; then
+		exit 77
+	fi
+}
diff --git a/tests/guix-build-branch.sh b/tests/guix-build-branch.sh
index 79aa06a58f..89f7ea4a08 100644
--- a/tests/guix-build-branch.sh
+++ b/tests/guix-build-branch.sh
@@ -24,12 +24,8 @@ guix build --version
 
 # 'guix build --with-branch' requires access to the network to clone the
 # Git repository below.
-
-if ! guile -c '(getaddrinfo "www.gnu.org" "80" AI_NUMERICSERV)' 2> /dev/null
-then
-# Skipping.
-exit 77
-fi
+. $(dirname $0)/common.sh
+skip_if_network_unreachable
 
 orig_drv="`guix build guile-gcrypt -d`"
 latest_drv="`guix build guile-gcrypt --with-branch=guile-gcrypt=master -d`"
diff --git a/tests/guix-environment.sh b/tests/guix-environment.sh
index f8be48f0c0..ce01ac04be 100644
--- a/tests/guix-environment.sh
+++ b/tests/guix-environment.sh
@@ -174,9 +174,8 @@ case "$transformed_drv" in
 *)   false;;
 esac
 
-
-if guile -c '(getaddrinfo "www.gnu.org" "80" AI_NUMERICSERV)' 2> /dev/null
-then
+. $(dirname $0)/common.sh
+if network_reachable ; then
 # Compute the build environment for the initial GNU Make.
 guix environment --bootstrap --no-substitutes --search-paths --pure \
  -e '(@ (guix tests) gnu-make-for-tests)' > "$tmpdir/a"
diff --git a/tests/guix-pack.sh b/tests/guix-pack.sh
index 0339221ac2..822a67b157 100644
--- a/tests/guix-pack.sh
+++ b/tests/guix-pack.sh
@@ -23,9 +23,8 @@
 
 # A network connection is required t

bug#44563: Update python-ipykernel to 5.3.4

[Stephen Christie via Bug reports for GNU Guix]

I was trying to set up Jupyter notebook with guix-jupyter, but ran into an 
issue with receiving rendered images (e.g. from matplotlib), which crashes the 
ipykernel. I hope an update of python-ipykernel to upstream stable may fix 
this? If this is the case, it would likely be due to incompatibilities with 
newer python versions.
Note that this issue only occurs when running through guix-jupyter, so it may 
not be the source of that issue.

Apologies for not creating a patch -- I am new to Guix and do not have a 
development tree set up.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#44491: Support GUIX_DISABLE_NETWORK_TESTS environment variable

[Ludovic Courtès]

Vagrant Cascadian  skribis:

> On 2020-11-08, Ludovic Courtès wrote:
>> Vagrant Cascadian  skribis:
>>
>>> If this could be considered for the upcoming 1.2 release, that would be
>>> appreciated, though I can also carry the patches in Debian...
>>
>> Yay!  It should be doable, let’s see.
>
> It seems like a simpler workaround is to pass RES_OPTIONS=attempts:0,
> which should disable name resolution, and thus the network checks will
> fail.
>
> With the RES_OPTIONS workaround, the changes to guix/tests.scm
> network-reachable are no longer needed ... i think. :)

Oooh nice, the wonders of glibc!

> Might still be worth refactoring some of *.sh tests to use common
> functions, since the code is basically copied and pasted in several
> different places.

Yes, that’s still a good idea.  Would you like to adjust your patch
accordingly?

> I suspect there are some additional tests that should check for network,
> but that is probably a separate bug once they have been identified.

OK!

Thanks,
Ludo’.

bug#35594: bug#36376: Application menu of desktop environment not automatically updated

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Tue, 10 Nov 2020 at 16:25, Ludovic Courtès  wrote:

[...]

>> The main downside is extra grafting, which means extra disk and CPU
>> usage for our users.  However, libx11 (11K dependents) is also grafted,
>> so it shouldn’t make things worse (GLib has 6K dependents).
>
> No free lunch. :-)
> Is it really slow or acceptable?

If you’re installing a graphical applications, it’s already being
grafted, so the extra graft doesn’t make a difference.

Non-graphical applications that depend on GLib will now need to be
grafted, but I think there aren’t many of them, and they too might also
be grafted for other reasons.

Ludo’.

bug#44558: Mesa isn't update to date

[romulasry via Bug reports for GNU Guix]

Mesa 20.2.2 is released

November 6, 2020

https://docs.mesa3d.org/relnotes/20.2.2.html

Also it would be nice to see it built with lllvm 11

Sent with [ProtonMail](https://protonmail.com) Secure Email.

bug#44559: gnutls 3.6.12 fails to build: FAIL: status-request-revoked

[Christopher Baines]

I found this when trying to build guile3.0-gnutls:

  guix time-machine --commit=94585fffb23079fe71110e2bf99782eb4ccfa12b -- build 
--no-grafts --check guile3.0-gnutls
  

FAIL: status-request-revoked


trying NORMAL:-VERS-ALL:+VERS-TLS1.2
received status request
received status request
cert_verify_callback:263: certificate verify status doesn't match: 100402 != 
22FAIL status-request-revoked (exit status: 1)


signature.asc
Description: PGP signature

bug#44511: guix system vm-image fails when using grub-efi-bootleader

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Attempting to build the lightweight-desktop.tpml image configuration using:
>
> $ guix system vm-image gnu/system/examples/lightweight-desktop.tmpl 
> --verbosity=10 --no-offload

[...]

> installing bootloader...
> Backtrace:
>1 (primitive-load "/gnu/store/8v2p9vi8249z31f8gsvrdf3c0b4
> In ./gnu/build/vm.scm:
> 485:6  0 (initialize-hard-disk "/dev/vda" #:bootloader-package _ 
> ./gnu/build/vm.scm:485:6: In procedure initialize-hard-disk:
> ERROR:
>   1. &message: 
> "'/gnu/store/8jf4yz2vb77d7ww1q42x3hqr5bd6nwl3-grub-efi-2.04/sbin/grub-install 
> --boot-directory /fs/boot --bootloader-id=Guix --efi-directory /fs/dev/vda' 
> exited with status 1; output follows:\n\n "

Fixed in 7a20c1676a8421f3ac06a2634a27c2837293df0b by mimicking what
‘virtualized-operating-system’ does.

> file-size: 
> /gnu/store/0llx3y194278l5ksr4xh9kc64mh8nn8d-nss-certs-3.52.1/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem:
>  No such file or directory
> file-size: 
> /gnu/store/8i7j0d7hwz56hkzd83cwbdfnir2d1g68-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem:
>  No such file or directory

Oh, I’ll address this one separately.

Thanks,
Ludo’.

bug#44146: CVE-2020-15999 in FreeType

[Maxim Cournoyer]

Hello,

Marius Bakke  writes:

> Hello,
>
> The 'freetype' package is vulnerable to CVE-2020-15999.
>
> According to
> https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html,
> an exploit already exists in the wild.
>
> I'm busy for a couple of days and won't be able to work on it in time.
> Volunteers wanted!

This was fixed by Tobias in commit
d32b210f282ef74caf9890e1d4ffe8eb04bd64e5.

Closing.

Thank you for the report!

Maxim

bug#41780: UEFI bios not supported out of the box when burning to usb stick

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> Hello,
>
> romulasry via Bug reports for GNU Guix  writes:
>
>> This would be a nice feature to have in the future when all there will be is 
>> UEFI (bioses).
>
> I've installed Guix on UEFI systems before; it should definitely work.
> Could you provide more details on what you tried exactly and what errors
> you've encountered?

No news, and as mentioned up-thread, this is already supported.  Please
open a new issue with the details of what you tried if you still
encounter problems.

Closing.

Thank you!

Maxim

bug#44383: gst-plugins-good fails its test suite on armhf-linux

[Marius Bakke]

Maxim Cournoyer  writes:

> Here's the output for the failing tests:

This is using QEMU transparent emulation, right?

There is a substitute on Berlin:

$ guix weather -s armhf-linux gst-plugins-good
computing 1 package derivations for armhf-linux...
looking for 1 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  100.0% substitutes available (1 out of 1)
  at least 4.1 MiB of nars (compressed)
  5.5 MiB on disk (uncompressed)
  1.402 seconds per request (1.4 seconds in total)
  0.7 requests per second

I'm not sure to what extent we should patch packages to work with QEMU
transparent emulation.  And currently the CI does not use it at all for
32-bit ARM (albeit for rather different reasons).

Thoughts?


signature.asc
Description: PGP signature

bug#37491: guix master build fails with msgmerge error

[Maxim Cournoyer]

Hello,

Roel Janssen  writes:

> On Mon, 2019-09-23 at 16:07 +0200, Danny Milosavljevic wrote:
>> msgmerge  --lang=en@quot e...@quot.po guix.pot -o e...@quot.new.po
>> .
>> ... done.
>> make[5]: Leaving directory '/home/dannym/src/guix-heads-
>> v5/guix/po/guix'
>> make[4]: Leaving directory '/home/dannym/src/guix-heads-
>> v5/guix/po/guix'
>> rm -f e...@quot.gmo && /gnu/store/h4v540l0p97mjy9ll9lc86cpz8m3l23f-
>> profile/bin/msgfmt -c --statistics --verbose -o e...@quot.gmo 
>> e...@quot.po
>> e...@quot.po:2837: format specifications in 'msgstr[0]' are not a
>> subset of those in 'msgid_plural'
>> e...@quot.po:2844: format specifications in 'msgstr[0]' are not a
>> subset of those in 'msgid_plural'
>> /gnu/store/h4v540l0p97mjy9ll9lc86cpz8m3l23f-profile/bin/msgfmt: found
>> 2 fatal errors
>> e...@quot.po: 915 translated messages.
>> make[3]: *** [Makefile:201: e...@quot.gmo] Error 1
>> 
>> Git commit: 3dd3ac4d83db0609e10637e9d21d7abb2198398d
>
> I'm getting the same error with commit
> 462ca0bbb73206569073814dd8daa7e2b6a2a048.
>
> Do you know how you solved this?
>
> Kind regards,
> Roel Janssen

That probably was an error in the translation files that got resolved.
Master currently builds fine.

Closing,

Thank you!

Maxim

bug#44491: Support GUIX_DISABLE_NETWORK_TESTS environment variable

[Vagrant Cascadian]

On 2020-11-08, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> If this could be considered for the upcoming 1.2 release, that would be
>> appreciated, though I can also carry the patches in Debian...
>
> Yay!  It should be doable, let’s see.

It seems like a simpler workaround is to pass RES_OPTIONS=attempts:0,
which should disable name resolution, and thus the network checks will
fail.

With the RES_OPTIONS workaround, the changes to guix/tests.scm
network-reachable are no longer needed ... i think. :)

Might still be worth refactoring some of *.sh tests to use common
functions, since the code is basically copied and pasted in several
different places.

I suspect there are some additional tests that should check for network,
but that is probably a separate bug once they have been identified.


live well,
  vagrant


signature.asc
Description: PGP signature

bug#36376: Application menu of desktop environment not automatically updated

[zimoun]

On Tue, 10 Nov 2020 at 16:25, Ludovic Courtès  wrote:

> Video!

Héhé!  Nice :-)

> So I think we should include this fix in 1.2.  What do people think?

You mean only the initial patch.  If it works in "real conditions" for
bob on 'antelope' (desktop.tmpl), then it would nice to have for 1.2,


> The main downside is extra grafting, which means extra disk and CPU
> usage for our users.  However, libx11 (11K dependents) is also grafted,
> so it shouldn’t make things worse (GLib has 6K dependents).

No free lunch. :-)
Is it really slow or acceptable?


All the best,
simon

bug#43738: Patch file names too long

[Ludovic Courtès]

Ludovic Courtès  skribis:

> There are several patch file names that are too long for ‘tar’, as
> reported during ‘make dist’:
>
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/ocaml-bisect-fix-camlp4-in-another-directory.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-signature-of-multiplyCheckOverflow.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python2-pygobject-2-gi-info-type-error-domain.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-division-by-zero-BlockCodec-runPull.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python-robotframework-honor-source-date-epoch.patch
>  dosiernomo tro longas (maks 99); ne ŝutita

Fixed by:

  8515ea12d2 gnu: audiofile: Shorten patch file names.
  74361d3ee8 gnu: python2-pygobject@2: Shorten patch file name.
  f161bd2cd7 gnu: Remove unused patch.
  ab96f929c6 gnu: python-robotframework: Shorten patch file name.

Ludo’.

bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> Guillaume Le Vaillant  writes:
>
>> I guess we could increase the default max space size to 4 or 5 GB
>> without causing swapping issues on users' machines (at least on x86-64).
>> And users wanting a smaller one can use the "dynamic-space-size" option
>> at runtime.
>
> Fine with me, let's do it now on staging then?

Yes, go ahead.


signature.asc
Description: PGP signature

bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?

[Pierre Neidhardt]

Guillaume Le Vaillant  writes:

> I guess we could increase the default max space size to 4 or 5 GB
> without causing swapping issues on users' machines (at least on x86-64).
> And users wanting a smaller one can use the "dynamic-space-size" option
> at runtime.

Fine with me, let's do it now on staging then?

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#36376: Application menu of desktop environment not automatically updated

[Ludovic Courtès]

Hi Maxim,

So I went further to test the initial GLib patch I posted in “real
conditions”.

‘guix system vm-image’ takes an awful lot of time for big images; I
patiently waited for completion for an image of ‘desktop.tmpl’, but then
its root file system turned out to be too small for me to run ‘guix
install’.

So instead I tried this:

  1. ‘guix system vm desktop.tmpl’;

  2. ‘guix install inkscape -p /tmp/test’ on my actual machine;

  3. Start the GNOME VM created above;

  4. Inside the VM, search for Inkscape, notice it’s not there;

  5. Inside the VM, have ~/.guix-profile point to the profile created on
 the host above, and notice that Inkscape becomes available.

Video!

  mpv http://web.fdn.fr/~lcourtes/tmp/gnome-desktop-app-detection.webm

So I think we should include this fix in 1.2.  What do people think?

The main downside is extra grafting, which means extra disk and CPU
usage for our users.  However, libx11 (11K dependents) is also grafted,
so it shouldn’t make things worse (GLib has 6K dependents).

Maxim, did you have a variant of the GLib patch that also checks
/run/current-system?

Thanks,
Ludo’.

bug#43893: [PATCH] maint: update-guix-package: Optionally add sources to store.

[Maxim Cournoyer]

Hi again!

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>>> Thanks for the patch, that should break the deadlock and allow us to
>>> proceed with the release!
>>>
>>> Next we need to update the ‘release’ target so
>>> GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT is set.
>>
>> Done!
>
> Thanks!
>
>>> the extra dependency on Git,
>>
>> To me, this script (update-guix-package), is an extension of the
>> Make-based build system (that's currently it's sole entry-point).  There
>> are already calls to git in this build system (for example, to get the
>> commit corresponding to HEAD), so I don't perceive it as nasty in this
>> context.  It can also be used as a reminder of things that are missing
>> in (guile git), for the purists ;-).
>
> I think we had everything needed in Guile-Git.

Not for the current implementation, that uses git worktrees and search
for the presence of the commit corresponding to HEAD in the upstream
remote.  If my (summary) analysis of the current state of (guile git) is
wrong, I'd be happy to migrate the bits shelling out to git to actual
library calls via (guile git).

[...]

> I hope this discussion can at least help improve mutual understanding on
> future patches and review processes.
>
> Thanks again for your time and patience!

I am equally grateful for yours.  This is a long thread!

Thanks,

Maxim

bug#43893: [PATCH] maint: update-guix-package: Optionally add sources to store.

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

>> Thanks for the patch, that should break the deadlock and allow us to
>> proceed with the release!
>>
>> Next we need to update the ‘release’ target so
>> GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT is set.
>
> Done!

Thanks!

>> the extra dependency on Git,
>
> To me, this script (update-guix-package), is an extension of the
> Make-based build system (that's currently it's sole entry-point).  There
> are already calls to git in this build system (for example, to get the
> commit corresponding to HEAD), so I don't perceive it as nasty in this
> context.  It can also be used as a reminder of things that are missing
> in (guile git), for the purists ;-).

I think we had everything needed in Guile-Git.

>> the extra copies of the whole tree,
>
> There used to be 3 copies required in total (the Guix checkout, a first
> dummy copy in the store, and a final copy in the store).
>
> Now, we have 2 copies unless GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT is set,
> in which case we get a third one in the store.  Seems pretty even to me!

Right, I stand corrected.

>> the extra code
>
> The extra code make things smoother (better/faster diagnostic), causes
> less friction in the workflow (I don't need to go paranoid about my tree
> being in pristine condition before 'make update-guix-package' -- I can
> rely on Guix computing it deterministically from the last commit).
>
>> and the shell pipelines, something avoided in the rest of Guix.
>
> Again, to me this script is a standalone extension of the build system.
> It's not defined as a module, cannot be used in the rest of the code
> base, so that it does things a bit differently doesn't strike me as bad.

Note that quite a few modules started their life under build-aux/.

>> Perhaps that suggests there are unwritten coding guidelines we should
>> eventually discuss and write.  We’ll see!
>
> That could be nice.  Although a linter included with Guile (ala Rust or
> Go) and configurable through a config file could have even more impact,
> in my opinion.  In any case I'd be honored that my code got to be the
> spark behind such guidelines/tool, eh :-).

I don’t think a linter could flag high-level patterns like the ones
we’re talking about, but human-written text could.

I hope this discussion can at least help improve mutual understanding on
future patches and review processes.

Thanks again for your time and patience!

Ludo’.

bug#43893: [PATCH v3] maint: update-guix-package: Prevent accidentally breaking guix pull.

[Maxim Cournoyer]

Hey,

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>>> Maxim Cournoyer  skribis:
>>>
> +(define (assert-clean-checkout repository)
> +  "Error out if the working directory at REPOSITORY contains local
> +modifications."
> +  (define description
> +(let ((format-options (make-describe-format-options
> +   #:dirty-suffix "-dirty")))
> +  (describe-format (describe-workdir repository) format-options)))
> +
> +  (when (string-suffix? "-dirty" description)
> +(leave (G_ "attempt to update 'guix' package from a dirty tree 
> (~a)~%")
> +   description))
> +
> +  (info (G_ "updating 'guix' package to '~a'~%") description))

 Unfortunately this doesn't catch the case where git has explicitly been
 told to '--skip-worktree' on a path or file (the original cause of this
 bug report).  See
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43893#11.
>>>
>>> Any such issue is caught when one eventually runs ‘guix build guix’
>>> (wrong commit ID, wrong hash, etc.).
>>>
>>> But you’re right that the above test isn’t fool-proof: it’s just a way
>>> to catch this common mistake early and report it nicely.
>>
>> Right.  I still don't like that it wouldn't work from a checkout where
>> someone would have modified, e.g., the .dir-locals file locally and
>> marked it with 'git --skip-worktree'.  Having to revert this kind of
>> 'developer setup' is painful.  The current approach makes it unnecessary
>> (only committed changes are taken into account, not just git tracked
>> files).
>
> “Wouldn’t work” is a strong statement: like I wrote, mistakes would
> always be caught when you try to build ‘guix’, as with any other package
> (we don’t have special support for other packages, why would this one
> have to be different?).

True.  I meant it in the sense "I wouldn't be able to update the Guix
package before manually ensuring that the HEAD of my tree was in a
pristine condition, that is, equivalent to the last commit".

Since Guix is the focus of Guix developers, it's much more likely to
have its sources in flux compared to the other packages we update in
Guix.  To me it seems useful to automate the 'cleanliness' part of the
tree rather than force it on developers, since it can be.

We also don't update the package in place from a Git checkout when
updating other packages.  It's a manual work of 'git clone', 'guix hash
-rx' and editing the source manually, which is different from 'make
update-guix-package', which strives to automate the process.

My 2 cents!  Time will tell if this is a viable route.  If it breaks
every time we use it, we can fallback to the simpler scheme.

Maxim

bug#43893: [PATCH] maint: update-guix-package: Optionally add sources to store.

[Maxim Cournoyer]

Hello Ludovic,

Ludovic Courtès  writes:

> Maxim Cournoyer  skribis:

[...]

>> -(define-syntax-rule (with-temporary-git-worktree commit body ...)
>> -  "Execute BODY in the context of a temporary git worktree created from 
>> COMMIT."
>> +(define-syntax-rule (call-with-temporary-git-worktree commit proc)
>> +  "Execute PROC in the context of a temporary git worktree created from
>> +COMMIT.  PROC receives the temporary directory file name as an argument."
>
> This could be a procedure rather a macro now.

I've changed it to a plain define in the latest version (now merged).

> [...]
>
>> +   (call-with-temporary-git-worktree commit
>> +   (lambda (tmp-directory)
>> + (let* ((hash (nix-base32-string->bytevector
>> +   (string-trim-both
>> +(with-output-to-string
>> +  (lambda ()
>> +(guix-hash "-rx" tmp-directory))
>> +(location (package-definition-location))
>> +(old-hash (content-hash-value
>> +   (origin-hash (package-source guix)
>> +   (edit-expression location
>> +(update-definition commit hash
>> +   #:old-hash old-hash
>> +   #:version version))
>> +   ;; When GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT is set, the 
>> sources are
>> +   ;; added to the store.  This is used as part of 'make 
>> release'.
>> +   (when (getenv "GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT")
>> + (with-store store
>> +   (keep-source-in-store store tmp-directory
>
> OK, that should do the job.
>
> Thanks for the patch, that should break the deadlock and allow us to
> proceed with the release!
>
> Next we need to update the ‘release’ target so
> GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT is set.

Done!

> I like that the initial issue is fixed, but I still don’t buy

[...]

Hehe.  Last round of weighing the + and - of this change

> the extra dependency on Git,

To me, this script (update-guix-package), is an extension of the
Make-based build system (that's currently it's sole entry-point).  There
are already calls to git in this build system (for example, to get the
commit corresponding to HEAD), so I don't perceive it as nasty in this
context.  It can also be used as a reminder of things that are missing
in (guile git), for the purists ;-).

> the extra copies of the whole tree,

There used to be 3 copies required in total (the Guix checkout, a first
dummy copy in the store, and a final copy in the store).

Now, we have 2 copies unless GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT is set,
in which case we get a third one in the store.  Seems pretty even to me!

> the extra code

The extra code make things smoother (better/faster diagnostic), causes
less friction in the workflow (I don't need to go paranoid about my tree
being in pristine condition before 'make update-guix-package' -- I can
rely on Guix computing it deterministically from the last commit).

> and the shell pipelines, something avoided in the rest of Guix.

Again, to me this script is a standalone extension of the build system.
It's not defined as a module, cannot be used in the rest of the code
base, so that it does things a bit differently doesn't strike me as bad.

> Perhaps that suggests there are unwritten coding guidelines we should
> eventually discuss and write.  We’ll see!

That could be nice.  Although a linter included with Guile (ala Rust or
Go) and configurable through a config file could have even more impact,
in my opinion.  In any case I'd be honored that my code got to be the
spark behind such guidelines/tool, eh :-).

Thank you,

Maxim

bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> See https://github.com/alex-gutev/generic-cl/issues/6
>
> The space size of our current SBCL package is 2Gb.
> Shall we increase it to 5Gb?
>
> What about adding an option to the build system to pass extra parameters
> to SBCL?  Then we could pass "--dynamic-space-size=5000" just for generic-cl.
>
> Thoughts?  Guillaume?

I guess we could increase the default max space size to 4 or 5 GB
without causing swapping issues on users' machines (at least on x86-64).
And users wanting a smaller one can use the "dynamic-space-size" option
at runtime.


signature.asc
Description: PGP signature

bug#44520: Graphical installer issues on 1.2.0.

[Mathieu Othacehe]

Hello,

I tried again on commit 86e9e5c using an image built by the CI and an
image built locally. I was not able to reproduce any of the issues I had
initially.

Closing this one until we find a reproducible way to trigger those
issues.

Thanks,

Mathieu

bug#44553: Exim has no authenticators

[divoplade]

Dear guix,

Exim has no authenticator drivers. By default, they don't get included
in the binary, but in my case, I want to set up an internet site with
authenticated SMTP 
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-smtp_authentication.htm
. Authentication is necessary, otherwise the system is vulnerable to
spam abuse.

The fix would be to un-comment the following lines in the src/EDITME
(copied as Local/Makefile):

# AUTH_CRAM_MD5=yes
# AUTH_CYRUS_SASL=yes
# AUTH_DOVECOT=yes
# AUTH_EXTERNAL=yes
# AUTH_GSASL=yes
# AUTH_HEIMDAL_GSSAPI=yes
# AUTH_PLAINTEXT=yes
# AUTH_SPA=yes
# AUTH_TLS=yes

Unfortunately, CYRUS_SASL requires cyrus-sasl as a native input and
GSASL, gsasl. HEIMDAL_GSSAPI does not seem to build.

However, it is vital to have plaintext (it is the only one used in the
default exim configuration, 
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_default_configuration_file.html
) and it would be nice to have the other as authenticators. What do you
think?

Best regards,

divoplade 
From 5f1e0ea844a26a6e024443f3898969b8ab1048bb Mon Sep 17 00:00:00 2001
From: divoplade 
Date: Tue, 10 Nov 2020 14:21:17 +0100
Subject: [PATCH] gnu: exim: enable some authenticators

---
 gnu/packages/mail.scm | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
index 488e714976..4eda49e72d 100644
--- a/gnu/packages/mail.scm
+++ b/gnu/packages/mail.scm
@@ -1503,7 +1503,13 @@ delivery.")
  (("(ZCAT_COMMAND=).*" all var)
   (string-append var gzip "/bin/zcat\n"))
  (("# (USE_GNUTLS(|_PC)=.*)" all line)
-  (string-append line "\n")))
+  (string-append line "\n"))
+ (("# AUTH_CRAM_MD5=yes") "AUTH_CRAM_MD5=yes\n")
+ (("# AUTH_DOVECOT=yes") "AUTH_DOVECOT=yes\n")
+ (("# AUTH_EXTERNAL=yes") "AUTH_EXTERNAL=yes\n")
+ (("# AUTH_PLAINTEXT=yes") "AUTH_PLAINTEXT=yes\n")
+ (("# AUTH_SPA=yes") "AUTH_SPA=yes\n")
+ (("# AUTH_TLS=yes") "AUTH_TLS=yes\n"))
;; This file has hard-coded relative file names for tools despite
;; the zcat configuration above.
(substitute* '("src/exigrep.src")
-- 
2.29.2

bug#41158: `guix` command segfaults after doing Ctrl-C during a frozen `guix pull`

[zimoun]

Dear,

On Tue, 10 Nov 2020 at 13:28, JoJo  wrote:
>
> Sorry, but I changed distro to Arch again some months ago for the time
> being, so I can't reproduce this.

Since the bug cannot be reproduced, I am closing.   Feel free to
reopen it if you hit it again.


All the best,
simon

bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?

[Pierre Neidhardt]

See https://github.com/alex-gutev/generic-cl/issues/6

The space size of our current SBCL package is 2Gb.
Shall we increase it to 5Gb?

What about adding an option to the build system to pass extra parameters
to SBCL?  Then we could pass "--dynamic-space-size=5000" just for generic-cl.

Thoughts?  Guillaume?

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#41158: `guix` command segfaults after doing Ctrl-C during a frozen `guix pull`

[JoJo]

Sorry, but I changed distro to Arch again some months ago for the time
being, so I can't reproduce this.

Johan

On tor, okt 29 2020, zimoun wrote:

> Dear,
>
> Thank you for the report.
>
> On Sat, 09 May 2020 at 20:38, JoJo  wrote:
>> Due to an unrelated issue, I was updating my system with `guix
>> pull`. During update, the process seemed to freeze / get stuck. My
>> system was responsive and all, but the `guix pull` output was stuck. I
>> don't remember what the last line in the output was, but after
>> studying the output of an application of
>> `/run/current-system/profile/bin/guix`, I think the output stuck at
>> the last step, "building profile with 1 package...". It definitely
>> said something about "profile" and "1 package" at least. I don't know
>> what caused the freeze. A casual guess is that it's related to my
>> screen blanking and the screen locker (`slock`) activatin due to no
>> input for a while.
>
> Hum?  Weird…
>
>> Anyways, I decided to end the apparently frozen command, so I killed
>> it with Ctrl-C. Immediately afterwards when trying to `guix pull`
>> another time, `guix` just started segfaulting. Doesn't matter what
>> subcommand I try, or if I call `guix` with no subbcommand -- it just
>> segfaults in either case.
>>
>> ```
>> jojo@astoria ~$ guix pull
>> Segmentation fault
>> jojo@astoria ~$ guix
>> Segmentation fault
>> jojo@astoria ~$ guix show
>> Segmentation fault
>> ```
>
> What do these commands
>
>/run/current-system/profile/bin/guix pull -p ~/.config/guix/current
>guix pull
>
> do?
>
>
>
> All the best,
> simon

bug#44551: Clients can trigger daemon file descriptor exhaustion

[Ludovic Courtès]

Hi!

--8<---cut here---start->8---
$ guix time-machine --branch=version-1.2.0 -- package -A '^r-' | wc -l

[...]

1488
$ r_packages="`guix time-machine --branch=version-1.2.0 -- package -A '^r-' | 
cut -f1`"
$ guix time-machine --branch=version-1.2.0 -- build --no-grafts $r_packages 
--max-jobs=20 --keep-going
process 61621 acquired build slot '/var/guix/offload/141.80.167.178:22/1'
normalized load on machine '141.80.167.177' is 0.03
building 
/gnu/store/ix9x8qzdy3cf0435b7a8p1gl77vcn82c-r-shinycssloaders-1.0.0.drv...
process 61683 acquired build slot '/var/guix/offload/141.80.167.178:22/1'
process 61683 acquired build slot '/var/guix/offload/141.80.167.172:22/1'

[...]

normalized load on machine '141.80.167.178' is 0.01
building 
/gnu/store/7ws1c6nkxkgkb86qdcgy9lq483jz5rf4-r-shinydashboard-0.7.1.drv...
process 61725 acquired build slot '/var/guix/offload/141.80.167.171:22/4'
process 61725 acquired build slot '/var/guix/offload/141.80.167.159:22/2'

[...]

normalized load on machine '141.80.167.171' is 0.16
building /gnu/store/j6walvqfdbavr56ymlnivnrc1z07yjfp-r-shinyfiles-0.8.0.drv...
guix build: error: creating pipe: Too many open files
--8<---cut here---end--->8---

On closer inspection, it seems that the guix-daemon for that session
opens each .drv file along with the corresponding .lock file, and spawns
one ‘guix offload’ process for each (?) and creates one pipe per offload
process:

--8<---cut here---start->8---
$ sudo guix processes| recsel -e 'ClientCommand ~ "r-biasedurn"'
SessionPID: 3412
ClientPID: 3343
ClientCommand: 
/gnu/store/b7rixb64yp00znz0d5rwd5zzklwzlzmv-guile-wrapper/bin/guile 
--no-auto-compile 
/home/ludo/.cache/guix/inferiors/pnxkhd7va5d3u5jas4mwsbic4vrkcbyv2too7sd74xd5vjyz54pq/bin/guix
 build --no-grafts r-a3 r-a4 r-a4base r-a4classif r-a4core r-a4preproc 
r-a4reporting r-aasea r-abacus r-abadata r-abaenrichment r-abbyyr r-abc 
r-abc-data r-abc-rap r-abcadm r-abcanalysis r-abcdefba r-abcoptim r-abcp2 
r-abcrf r-abcrlda r-abctools r-abd r-abe r-abemus r-abf2 r-abhgenotyper r-abind 
r-abjutils r-abn r-abnormality r-abodoutlier r-abps r-abseqr r-absfiltergsea 
r-absim r-abstractr r-abtest r-abundant r-ac3net r-aca r-acc r-accelerometry 
r-accelmissing r-accept r-acceptancesampling r-acclma r-accrual r-accrued 
r-accsda r-acd r-acdm r-ace2fastq r-acebayes r-acepack r-acet r-acfmperiod 
r-acid r-acm4r r-acmeeqtl r-acmer r-acnr r-acopula r-acousticndlcoder r-acp 
r-acrm […]
LockHeld: /gnu/store/mi6ydc4w47nrsw2ycsyssc2hlpl5jvlb-r-biclust-2.0.2.lock
LockHeld: /gnu/store/zypp435ii1sd256p1bapgvk06p2kc6rq-r-bifet-1.8.0.lock
LockHeld: /gnu/store/x316v7js7rj0wjhvynf3mn3ppxqqnghg-r-bigpint-1.4.0.lock
LockHeld: /gnu/store/jxs6h5f1cvlz7dmmifr3qf3skzziklwa-r-bigrquery-1.3.2.lock
LockHeld: /gnu/store/sw55r4wj1bgj2aqkl1gyqifk077iyvlc-r-aasea-1.1.0.lock
LockHeld: /gnu/store/r4331w4h693zl3596i9cnb0z7437aghp-r-bisquerna-1.0.4.lock
LockHeld: /gnu/store/13jggpxjxzjpbvwfx5vwdscvz5z5md88-r-cdm-7.5-15.lock
LockHeld: /gnu/store/bfvfb4wk1q9idfj3gdi1j7zhp5kj21kw-r-chemminer-3.40.0.lock
LockHeld: 
/gnu/store/2q0pibjmqd51dx331l4iz1xby868y7d3-r-chipkernels-1.1-1.c9cfcacb6.lock
LockHeld: /gnu/store/f195yyipwhhz1cdyvvwvcwd9n93bbgxk-r-chippeakanno-3.22.4.lock
LockHeld: /gnu/store/2igc78ipanbr0cgj508jxq94pqldirlx-r-circus-0.1.5.lock
LockHeld: /gnu/store/sr3h7hxzkjq8kh17f4clb27d5w6li34j-r-citr-0.3.2.lock
LockHeld: /gnu/store/cz7iffxh03mqf0651vxg6669aq31f039-r-cssam-1.4-1.9ec58c9.lock
LockHeld: /gnu/store/6xlx6mbvi6mz44kyps36vlw05r085k9s-r-ddrtree-0.1.5.lock
LockHeld: /gnu/store/6d0j0a5i8vz966w66b76w5gpb9xdpc2m-r-dnabarcodes-1.18.0.lock
LockHeld: /gnu/store/d6c5i3f41hfz4sacgmjc64x78rfk4f1p-r-abstractr-0.1.0.lock
LockHeld: /gnu/store/2kzzqdglrja1fr34jcp51vk8hw6ajk3i-r-dorng-1.8.2.lock
LockHeld: /gnu/store/5rvg6vaa5h5bxqxcw3nd7hl5695m64dz-r-dvmisc-1.1.4.lock
[…]
ChildProcess: 10012:
ChildProcess: 10056:
ChildProcess: 10156:
ChildProcess: 10228:
ChildProcess: 10275:
ChildProcess: 10331: 
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/bin/guile \ 
/gnu/store/c6y2fijkw5v0b6jm336h7pvvzd2wm0yd-guix-1.1.0-30.875c01f/bin/.guix-real
 offload x86_64-linux 3600 1 21600
ChildProcess: 10384:
ChildProcess: 10440:
ChildProcess: 10485:
ChildProcess: 10545:
ChildProcess: 10603:
[…]
$ sudo ls -l /proc/3412/fd  
  total 0
lr-x-- 1 root root 64 Nov 10 13:02 0 -> /dev/null
l-wx-- 1 root root 64 Nov 10 13:02 1 -> /var/log/guix-daemon.log
lr-x-- 1 root root 64 Nov 10 13:02 10 -> 'pipe:[1555282836]'
l-wx-- 1 root root 64 Nov 10 13:02 100 -> 'pipe:[1555302732]'
l-wx-- 1 root root 64 Nov 10 13:02 101 -> 
/var/log/guix/drvs/ph/3347q47fzm7p7xqxrg2yaczq32yhry-r-biasedurn-1.07.drv.gz
lrwx-- 1 root root 64 Nov 10 13:02 102 -> 
/gnu/store/mi6ydc4w47nrsw2ycsyssc2hlpl5jvlb-r-biclust-2.0.2.lock
lr-x-- 1 root root 64 Nov 10 13:02 103 -> 'pi

bug#44548: Acknowledgement (SBCL build system fails to pacakge cl-environments, generic-cl.)

[Pierre Neidhardt]

Good catch!

It also does the trick for generic-cl:

--8<---cut here---start->8---
(arguments
 `(#:tests? #f
   #:phases
 (modify-phases %standard-phases
   (add-after 'unpack 'fix-compile-order
 (lambda _
   (substitute* "generic-cl.asd"
 ((":module \"src\"") ":module \"src\" :serial t")))
---cut here---end--->8---

I don't understand why it works outside our build system.
It works when I run SBCL locally, so technically with the same ASDF.

I'll ask upstream, maybe they have a clue.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#44548: Acknowledgement (SBCL build system fails to pacakge cl-environments, generic-cl.)

[Pierre Neidhardt]

Reported here: https://github.com/alex-gutev/generic-cl/issues/7

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#44548: Acknowledgement (SBCL build system fails to pacakge cl-environments, generic-cl.)

[Guillaume Le Vaillant]

It looks like the files in "src/common/" must be compiled in a specific
order because some files depend on others, but the system definition has
neither the ":depends-on xyx" nor the ":serial t" indications. It causes
the functions defined in "src/common/util.lisp" not being available when
compiling "src/common/macro-util.lisp".
I'm not sure why it fails with asdf-build-system/sbcl but it succeeds
with Quicklisp though; different versions of ASDF maybe, or slightly
different initialization of ASDF...

By adding the missing ":serial t" I was able to build sbcl-cl-environments:

--8<---cut here---start->8---
(define-public sbcl-cl-environments
  ;; TODO: asdf-build-system/sbcl fails here, why?  See if it works with the
  ;; build system revamp once staging is merged after 2020-11-09.
  (let ((commit "bbcd958a9ff23ce3e6ea5f8ee2edad9634819a3a")) ; No version in 2 
years.
(package
  (name "sbcl-cl-environments")
  (version (git-version "0.2.3" "1" commit))
  (source
   (origin
 (method git-fetch)
 (uri (git-reference
   (url "https://github.com/alex-gutev/cl-environments";)
   (commit commit)))
 (file-name (git-file-name name version))
 (sha256
  (base32
   "1pfxl3vcdrb4mjy4q4c3c7q95kzv6rfjif3hzd5q91i9z621d64r"
  (build-system asdf-build-system/sbcl)
  (propagated-inputs
   `(("alexandria" ,sbcl-alexandria)
 ("anaphora" ,sbcl-anaphora)
 ("collectors" ,sbcl-collectors)
 ("optima" ,sbcl-optima)))
  (native-inputs
   `(("prove" ,sbcl-prove)))
  (arguments
   `(#:phases
 (modify-phases %standard-phases
   (add-after 'unpack 'fix-build
 (lambda _
   (substitute* "cl-environments.asd"
 ((":module \"common\"" all)
  (string-append all " :serial t")))
   #t)
  (home-page "https://github.com/alex-gutev/cl-environments";)
  (synopsis "Implements the Common Lisp standard environment access API")
  (description "This library provides a uniform API, as specified in Common
Lisp the Language 2, for accessing information about variable and function
bindings from implementation-defined lexical environment objects.  All major
Common Lisp implementations are supported, even those which don't support the
CLTL2 environment access API.")
  (license license:expat
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#44548: Acknowledgement (SBCL build system fails to pacakge cl-environments, generic-cl.)

[Pierre Neidhardt]

If I build manually it works:

--8<---cut here---start->8---
> sbcl --no-userinit
* (require :asdf)
("ASDF" "asdf" "UIOP" "uiop")

* (asdf:load-asd (truename 
"/gnu/store/pr52bqxa2kf1n8jadhzw4rjsl3jjk6yl-sbcl-cl-environments-0.2.3-1.bbcd958/share/common-lisp/sbcl/cl-environments/cl-environments.asd"))
#
#

* (asdf:compile-system "cl-environments")
WARNING: System definition file 
#P"/home/ambrevar/common-lisp/collectors/collectors.asd" contains definition 
for system "collectors-test". Please only define "collectors" and secondary 
systems with a name starting with "collectors/" (e.g. "collectors/test") in 
that file.
WARNING: System definition file 
#P"/gnu/store/n3sgz03ylnxprkbzj8f20zxvpldfxbcl-cl-symbol-munger-0.0.1-1.97598d4/share/common-lisp/source/cl-symbol-munger/symbol-munger.asd"
 contains definition for system "symbol-munger-test". Please only define 
"symbol-munger" and secondary systems with a name starting with 
"symbol-munger/" (e.g. "symbol-munger/test") in that file.
T
--8<---cut here---end--->8---

The above builds against a local version of collectors, not sure that's
related though.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#44548: SBCL build system fails to pacakge cl-environments, generic-cl.

[Pierre Neidhardt]

Hi!

I'm trying to package generic-cl on staging where the SBCL build system
has been revamped by Guillaume.

--8<---cut here---start->8---
(define-public sbcl-generic-cl
  (package
(name "sbcl-generic-cl")
(version "0.7.1")
(source
 (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/alex-gutev/generic-cl";)
 (commit (string-append "v" version
   (file-name (git-file-name name version))
   (sha256
(base32 "1jjg1d221a667wacbrh7abswrkzq6c9qwapdfh0frzl0la9xjz2f"
(build-system asdf-build-system/sbcl)
(inputs
 `(("agutil" ,sbcl-agutil)
   ("alexandria" ,sbcl-alexandria)
   ("anaphora" ,sbcl-anaphora)
   ("arrows" ,sbcl-arrows)
   ("cl-custom-hash-table" ,sbcl-custom-hash-table)
   ("static-dispatch" ,sbcl-static-dispatch)
   ("trivia" ,sbcl-trivia)))
(native-inputs
 `(("prove" ,sbcl-prove)))
(home-page "https://alex-gutev.github.io/generic-cl/";)
(synopsis "")
(description "")
(license license:expat)))
--8<---cut here---end--->8---

It fails with

--8<---cut here---start->8---
; wrote 
/gnu/store/hkr132gc9ra2pnx16lbvl66pn86w11nx-sbcl-generic-cl-0.7.1/.cache/common-lisp/sbcl-2.0.10-linux-x64/gnu/store/d99q6jgx4xqw7fnk8vhb1xaqqc4h65fl-cl-environments-0.2.3-1.bbcd958/share/common-lisp/source/cl-environments/src/tools/types-tmp1CXFJSK9.fasl
; compilation finished in 0:00:00.012
Unhandled SB-INT:SIMPLE-FILE-ERROR in thread #:
  Error opening 
#P"/gnu/store/jzwgprixssmzm8yc76gh0ir1cw9myr4b-sbcl-static-dispatch-0.3-1.6243afc/lib/common-lisp/sbcl/static-dispatch/src/package-tmpX4BRKI0R.fasl":

Permission denied
--8<---cut here---end--->8---

My suspicion is that generic-cl depends on sbcl-static-dispatch, which
depends on cl-environments, which is a _source_ package and not an SBCL package.

Indeed, I fail to package sbcl-cl-environments:

--8<---cut here---start->8---
(define-public sbcl-cl-environments
  (let ((commit "bbcd958a9ff23ce3e6ea5f8ee2edad9634819a3a")) ; No version in 2 
years.
(package
  (name "sbcl-cl-environments")
  (version (git-version "0.2.3" "1" commit))
  (source
   (origin
 (method git-fetch)
 (uri (git-reference
   (url "https://github.com/alex-gutev/cl-environments";)
   (commit commit)))
 (file-name (git-file-name name version))
 (sha256
  (base32
   "1pfxl3vcdrb4mjy4q4c3c7q95kzv6rfjif3hzd5q91i9z621d64r"
  (build-system asdf-build-system/sbcl)
  (inputs
   `(("alexandria" ,sbcl-alexandria)
 ("anaphora" ,sbcl-anaphora)
 ("collectors" ,sbcl-collectors)
 ("optima" ,sbcl-optima)))
  (native-inputs
   `(("prove" ,sbcl-prove)))
  (home-page "https://github.com/alex-gutev/cl-environments";)
  (synopsis "Implements the Common Lisp standard environment access API")
  (description "This library provides a uniform API, as specified in Common
Lisp the Language 2, for accessing information about variable and function
bindings from implementation-defined lexical environment objects.  All major
Common Lisp implementations are supported, even those which don't support the
CLTL2 environment access API.")
  (license license:expat
--8<---cut here---end--->8---

It errors out with

--8<---cut here---start->8---
; file: 
/gnu/store/xhgnh1yx8z999dx5qnxc0h3iwh1s836j-sbcl-cl-environments-0.2.3-1.bbcd958/share/common-lisp/sbcl/cl-environments/src/common/macro-util.lisp
; in: DEFMACRO! MATCH-STATE
; (CL-ENVIRONMENTS.UTIL:LET-IF ((CL-ENVIRONMENTS.UTIL::START
;(SECOND CL-ENVIRONMENTS.UTIL::STATES) 
:START)
;   (CL-ENVIRONMENTS.UTIL::BODY
;(CDDR CL-ENVIRONMENTS.UTIL::STATES)
;CL-ENVIRONMENTS.UTIL::STATES))
; (EQ (FIRST CL-ENVIRONMENTS.UTIL::STATES) :START)
;   `(LABELS ((,CL-ENVIRONMENTS.UTIL::G!NEXT
; (,CL-ENVIRONMENTS.UTIL::FROM-STATE
;  ,CL-ENVIRONMENTS.UTIL::G!FORCE 
,CL-ENVIRONMENTS.UTIL::G!ARG)
;   (OPTIMA:MULTIPLE-VALUE-MATCH #
; ,@#)))
;  (,CL-ENVIRONMENTS.UTIL::G!NEXT ,CL-ENVIRONMENTS.UTIL::START NIL
;   ,CL-ENVIRONMENTS.UTIL::ARG)))
; 
; caught ERROR:
;   during macroexpansion of
;   (LET-IF (# #)
;   (EQ # :START)
; ...).
;   Use *BREAK-ON-SIGNALS* to intercept.
;   
;The function CL-ENVIRONMENTS.UTIL::GENSYMS is undefined.
--8<---cut here---end--->8---

Guillaume, any clue what's going on?

--
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Descript

bug#43893: [PATCH v5] maint: update-guix-package: Optionally add sources to store.

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Following discussions in , keeping a copy
> of the updated package source is desirable when generating a release.
>
> * build-aux/update-guix-package.scm (version-controlled?): Remove variable.
> (call-with-temporary-git-worktree): Renamed from
> 'with-temporary-git-worktree'.  Update doc.  Do not change directory
> implicitly.
> (keep-source-in-store): New procedure.
> (main): Adjust to use with call-with-temporary-git-worktree.  Add the sources
> to the store when GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT is set.  Exit gracefully
> when FIND-ORIGIN-REMOTE returns #f.
> (%savannah-guix-git-repo-push-url-regexp): Adjust match for a potential colon
> separator.
> * Makefile.am (GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT): Adjust.
> * .dir-locals.el (scheme-mode): Update.
> * doc/contributing.texi (Updating the Guix Package): Update doc.
>
> Co-authored-by: Ludovic Courtès 

Go for it, thanks!

Ludo’.

bug#44530: [1.2.0] linux-libre-5.9.3 deblob fails on aarch64

[Efraim Flashner]

On Mon, Nov 09, 2020 at 11:28:00PM +0200, Efraim Flashner wrote:
> On Mon, Nov 09, 2020 at 01:38:35PM -0500, Leo Famulari wrote:
> > On Mon, Nov 09, 2020 at 02:54:32PM +0200, Efraim Flashner wrote:
> > > I was trying to build my pine64 config on the 1.2.0 branch and the
> > > deblob check failed against 5.9.3. Log attached.
> > 
> > I don't see anything relevant in the log. I wonder, could it have run
> > out of memory?
> 
> That was what confused me too. I'll add 2G of swap to the 2G of RAM and
> try again.

Adding the swap did the trick. I'll go back to making sure my config
builds on aarch64.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature