bug#41413: guix-install.sh broken on Gentoo

[Maxim Cournoyer]

Hi Vincent,

Vincent Legoll  writes:

> Hello Tobias, ZC,
>
> I created a gentoo VM (i686 / following gentoo handbook) and tried
> the official upstream guix installer.
>
> It worked properly, not detecting the OS init system, I think this is
> because the gentoo handbook made me install cronie instead of plain
> cron, so there's no "/etc/init.d/cron" file. And so it did not try to
> install the guix-daemon service init.d file through update-rc.d.
> And told me to run the daemon manually, which worked OK.
>
> Running it with a local guix-install.sh + binary tarball with my
> pending changes (which includes openrc support). It also worked
> properly, detecting the OS as being openrc managed and doing what
> is needed.
>
> So, I'll still cook up a patch to fix sysvinit detection, because
> assuming sysvinit on the mere presence of /etc/init.d/cron is not
> really the right thing to do. (and the fix will need to be tested
> on a sysvinit-based distro, which I'll do)
>
> But on the other hand, I don't know what to do with this bug report,
> I cannot reproduce the exact problem, and I'm not trying all the other
> available cron variants from gentoo (bcron, dcron, fcron).
>
> So either ZC tells us more about his setup and shows us more output
> to be able to understand what did go wrong, or we cannot help further.
>
> Couldn't keep ZC CC'ed as the issue was created without his email
> address, let's hope he follows it via another way...

It seems the installer is working fine as per your tests and that the
original issue cannot be reproduced.  I'm closing this bug.

Thank you,

Maxim

bug#39970: guix commands broken on Azerbaijani 'az_AZ' and Turkish 'tr_TR' locales

[Maxim Cournoyer]

"pelzflorian (Florian Pelz)"  writes:

> On Tue, Mar 17, 2020 at 10:20:01PM +0100, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)"  skribis:
>> > `LC_ALL=tr_TR.utf8 make check` is still very unhappy though.
>> > There are many failures.  I will continue to investigate later today.
>> 
>> OK.
>
> The tests fail to many other uses of [a-z] in regexps.  I will look;
> for e.g. guix/import/cran.scm
>
> (if (string-match "^[A-Za-z][^ :]+:( |\n|$)" line)
> …)
>
> it would be easier and clearer to just list [a-z] explicitly:
>
>
>> LGTM, thank you!
>
> :) Pushed as 771c5e155d7862ed91a5d503eecc00c1db1150ad.

Closing.

Thank you,

Maxim

bug#40649: VM image file lacks ".qcow2" extension, which confuses GNOME Boxes

[Maxim Cournoyer]

Hi!

Leo Famulari  writes:

> On Wed, Apr 15, 2020 at 10:36:11PM +0200, mray wrote:
>> Hi there,
>> 
>> the QEMU Image download links toa file that misses the "*.qcow2" filetype.
>> 
>> That way Gnome Boxes is not able to start the image. I suggest renaming
>> all respective files.
>
> We could use something like the attached patch (untested!), but I'll
> wait for review from a maintainer since they would have to deal with any
> breakage.
>
> From a9bc503689e7d524265fd23811627323d8059ece Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> Date: Thu, 28 May 2020 22:43:16 -0400
> Subject: [PATCH] maint: Add a file extension to the VM image.
>
> This allows the file to be opened easily in GNOME Boxes.
>
> Fixes .
>
> * Makefile.am (release): Add ".qcow2" to the name of the VM image.
> * doc/guix.texi (Running Guix in a VM): Adjust accordingly.
> ---
>  Makefile.am   | 6 +++---
>  doc/guix.texi | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 5b64386b53..f1031863de 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -836,9 +836,9 @@ release: dist-with-updated-version
>   echo "failed to produced Guix VM image for $$system" >&2 ;  
> \
>   exit 1 ;
> \
> fi ;  
> \
> -   xz < "$$image" > 
> "$(releasedir)/$(GUIX_SYSTEM_VM_IMAGE_BASE).$$system.xz.tmp" ;   \
> -   mv "$(releasedir)/$(GUIX_SYSTEM_VM_IMAGE_BASE).$$system.xz.tmp"   
> \
> -  "$(releasedir)/$(GUIX_SYSTEM_VM_IMAGE_BASE).$$system.xz" ; 
> \
> +   xz < "$$image" > 
> "$(releasedir)/$(GUIX_SYSTEM_VM_IMAGE_BASE).$$system.qcow2.xz.tmp" ; \
> +   mv "$(releasedir)/$(GUIX_SYSTEM_VM_IMAGE_BASE).$$system.qcow2.xz.tmp" 
> \
> +  "$(releasedir)/$(GUIX_SYSTEM_VM_IMAGE_BASE).$$system.qcow2.xz" ;   
> \
>   done
>   @echo
>   @echo "Congratulations!  All the release files are now in 
> $(releasedir)."
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 5b9942d420..0adadf69fa 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -27747,7 +27747,7 @@ Whether or not the droplet should be created with 
> IPv6 networking.
>  @cindex virtual machine
>  To run Guix in a virtual machine (VM), one can use the pre-built Guix VM 
> image
>  distributed at
> -@url{@value{BASE-URL}/guix-system-vm-image-@value{VERSION}.x86_64-linux.xz}.
> +@url{@value{BASE-URL}/guix-system-vm-image-@value{VERSION}.x86_64-linux.qcow2.xz}.
>  This image is a compressed image in QCOW format.  You will first need to
>  decompress with @command{xz -d}, and then you can pass it to an emulator such
>  as QEMU (see below for details).

Eh, sorry for not seeing this earlier; I've applied the same fix on the
version-1.3.0 branch with commit
ebf5d77eab148394c6db0dd135ea119ca377aaed, so at least this is fixed in
the soon released Guix v1.3.0 (planned for the 10th of May!).

Closing.

Maxim

bug#43384: guix pull: backtrace "no route to host"

[Chris Marusich]

Jan Wielkiewicz  writes:

> Hello, 
> I tried running "guix pull" but it gave me a backtrace.
>
> guix substitute: error: connect: No route to host
> @ substituter-failed
> /gnu/store/c4mzhay8jrg5r43wkn4f9004afvly0ad-po4a-0.57 256 fetching path
> `/gnu/store/c4mzhay8jrg5r43wkn4f9004afvly0ad-po4a-0.57' failed with
> exit code 1 @ substituter-started
> /gnu/store/s6ha2sssblw06sjpw4zawzx98zwbj5m7-graphviz-2.42.3 substitute
> killing process 6694 Backtrace: 11 (primitive-load
> "/gnu/store/lardz9zqi5ypgrdrj6dyfgj9p3bca2ab-compute-guix-derivation")
> In ice-9/eval.scm: 155:9 10 (_ _) 159:9  9 (_
> #(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?)
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) In ./guix/store.scm: 2042:24  8
> (run-with-store # _
> #:guile-for-build _ #:system _ #:target _) 1876:8  7 (_ _) In
> ./guix/gexp.scm: 244:18  6 (_ _)
>1064:2  5 (_ _)
> 924:2  4 (_ _)
> 785:4  3 (_ _)
> In ./guix/store.scm:
>   1924:12  2 (_ #)
>1357:5  1 (map/accumulate-builds # 7fe2f10265f0> _ _) 1368:15  0 (_ # 7fe2f10265f0> 7fe2f10265f0> _ _)
>
> ./guix/store.scm:1368:15: ERROR:
>   1. &store-protocol-error:
>   message: "some substitutes for the outputs of derivation
> `/gnu/store/bxw2dzjmdrq7qmv0w1mpzqrkfqs9p7q2-po4a-0.57.drv' failed
> (usually happens due to networking issues); try `--fallback' to build
> derivation from source " status: 1 guix pull: error: You found a bug:
> the program
> '/gnu/store/lardz9zqi5ypgrdrj6dyfgj9p3bca2ab-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "71992a532dd0bb88b39dda285482b332a24dae66"; system: "x86_64-linux";
> host version: "1192ae940434808560b3170107e4ce44855816c3"; pull-version:
> 1). Please report it by email to .
>
>
> Jan Wielkiewicz

It sounds like perhaps this error was caused by a networking error.
Although much time has passed since you opened this bug report, I think
in situations like this, you can work around the issue by trying the
command with the --fallback option, as the error message suggests.  Did
you try that?

You could try something like this:

  guix pull --fallback

You could also try building just that one problematic derivation with
fallback, like this:

  guix build --fallback 
/gnu/store/bxw2dzjmdrq7qmv0w1mpzqrkfqs9p7q2-po4a-0.57.drv

If successful, you can then retry "guix pull" without the --fallback
option, but if a network error was the cause, the same kind of issue
might happen again for any other derivation.  Therefore, I would
recommend trying "guix pull --fallback" if this sort of problem happens
frequently for you.

FYI, you can also add "--fallback" to various commands, like "guix
build" and "guix package".

-- 
Chris


signature.asc
Description: PGP signature

bug#48213: offlineimap build fails

[Bone Baboon via Bug reports for GNU Guix]

>> This would accommodate Guix users who have disabled ipv6.
>
> Guix doesn't virtualise the kernel and expects it to provide all that
> is needful.  Linux offers knobs for *everything*; that doesn't mean
> everything is supported.  Disabling kernel support for basic things
> (namespaces, UNIX domain sockets, IPv6) *will* break certain software.
>
> We shouldn't feel obligated to accommodate strange configurations out
> of the box, but we try to do so when the maintenance cost is very low.
> In this case, you'd need to ensure the test still runs on the vast
> majority of systems with IPv6.

Sorry I should have explained the rationale for this in my initial
message.

For privacy conscious individuals one tool for improving online privacy
is a VPN service. Many VPN service providers recommend disabling
ipv6. This is because of ipv6 leaks. 

https://ipv6leak.com/ is a ipv6 leak testing site.  It is the first
result when searching for "ipv6 leak" with searx.ir.  Using this website
I can see that the privacy provided by my VPN service provider is
compromised by an ipv6 leak when I enable ipv6.  This is why I have ipv6
disabled.

I am open to suggestions on free software alternatives to using a VPN
service that do not require ipv6 to be disabled. The current VPN service
I am using allows the use of a openvpn client so I do not need to
install any proprietary software on my computer to use their service.  I
am aware of Tor or I2P but have not yet looked into how I could to send
my network traffic over those networks.

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Mark H Weaver writes:
> Right.  Unfortunately, these timeouts are too short for many slower
> machines, such as 32-bit ARM systems.  Bone Baboon has also recently
> reported being unable to build 'glib' on a 32-bit i686 system due to
> these timeouts, even when making extreme efforts to reduce load from
> other processes.

Here is information on the computer that is having tests timeout when
building glib.

* 4 GiB of RAM installed (the maximum)

* i686 32-bit 1 Core with 2.6 GHz

bug#46038: guix 1.3.0rc1 test failure: channels-news, one entry

[Vagrant Cascadian]

On 2021-05-04, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> On 2021-01-22, Vagrant Cascadian wrote:
>>> I've uploaded guix 1.2.0 built against guile-2.2 to Debian, and while it
>>> builds fine on the official buildd.debian.org infrastructure, on amd64
>>> and arm64 the "channel-news, one entry" test from tests/channels.scm
>>> fails on tests.reproducible-builds.org.
>>>
>>> There are likely a few differences in the two build environments,
>>> possibly including network access.
>>>
>>> Does the "channel-news, one entry" test indirectly depend on network or
>>> bootstrap binaries?
>>>
>>> Could a difference in locale related variables affect the result of the
>>> test (e.g. LANGUAGE=en:en_US vs. LANGUAGE unset, LC_ALL unset
>>> vs. LC_ALL=C or LC_ALL=C.UTF-8)?
>>>
>>>   
>>> https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/guix.html
>>
>> Still basically the same story with 1.3.0rc1, in some cases this test
>> fails, but I haven't consistently figured out what triggers it.
>>
>>
>>> test-name: channel-news, one entry
>>> location: /build/1st/guix-1.2.0/tests/channels.scm:324
>>> source:
>
> [...]
>
>>> +  (lset= equal?
>>> + (map channel-news-entry-title
>>> +  (channel-news-for-commit channel commit5))
>>> + '((("en" . "Another file!"))
>>> +   (("en" . "Old news.") ("eo" . "Malnova?oj."
>
> The culprit is right here: it should read “Malnovaĵoj”, but there’s a
> question mark instead of ‘ĵ’.
>
> Could it be that you’re not running tests in a UTF-8 locale?

Thanks for taking a deeper look!

Yes, on tests.reproducible-builds.org, one build is run in the C locale,
the other in various UTF-8 locales (somewhat arbitrarily tied to
architecture exactly which UTF-8 locale is used). I'm guessing
buildd.debian.org use C.UTF-8, since it builds fine there.

So now the question is what to do; should tests be able to assume a
UTF-8 locale?

Should I try to adapt the test to work in C?

Should I workaround it in the Debian packaging by forcing to use a UTF-8
locale (on Debian, the only one definitely available is C.UTF-8, which
isn't in upstream glibc, and thus not in guix itself).


live well,
  vagrant


signature.asc
Description: PGP signature

bug#48213: offlineimap build fails

[Mark H Weaver]

Hi,

Bone Baboon via Bug reports for GNU Guix  writes:
> On a x86_64 computer when I run `guix build --no-substitutes
> offlineimap` the build fails because the "test_ipv6_available" test
> fails.
>
> In the system configuration ipv6 is disabled:
[...]
> Taking the failing test's name "test_ipv6_available" literally I would
> like to ask if having this test required to build this offlineimap
> dependency is necessary?  Could this test be allowed to fail or be
> skipped without failing the build?  This would accommodate Guix users
> who have disabled ipv6.

I will defer to the Guix maintainers on this question, but I just wanted
to point out that since 'offlineimap' is the _only_ package in Guix that
depends on the 'python2-rfc6555' package, it's quite painless to work
around this particular issue using Guix's "--without-tests" package
transformation option.

>From the command line, you can simply do this:

  guix build offlineimap --without-tests=python2-rfc6555

Within an OS configuration, or within a profile "manifest" file (if you
use "guix package --manifest", which is highly recommended), you can use
the following Scheme expression in place of 'offlineimap':

--8<---cut here---start->8---
  (let ((transform (options->transformation
'((without-tests . "python2-rfc6555")
(transform offlineimap))
--8<---cut here---end--->8---

Note that you'll also need to put "(use-modules (guix transformations))"
at the top of the file, to import the 'options->transformation'
procedure.

Please let us know if this works for you.

 Thanks,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Earlier, I wrote:
> I think that this recently-reported bug ()
> demonstrates that we can't safely remove the substitution.

To avoid having to scroll past the very long build log in the initial
bug report, it's probably best to read the bug report starting here:

https://bugs.gnu.org/48024#20

  Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48225: Wrong result of package-name->name+version

[Ludovic Courtès]

Hi Guillaume,

Guillaume Le Vaillant  skribis:

> The 'package-name->name+version' function defined in
> "guix/build/utils.scm" returns a wrong result if there is a '-'
> followed by a number in the package name:
>
> (use-modules ((guix build utils)))
> (package-name->name+version "sbcl-3d-vectors-3.1.0-1.29bb968")
>
> $1 = "sbcl"
> $2 = "3d-vectors-3.1.0-1.29bb968"
>
>
> It should be:
>
> $1 = "sbcl-3d-vectors"
> $2 = "3.1.0-1.29bb968"
>
> Can someone think of an elegant modification for
> 'package-name->name+version' so that it finds where the version is
> even if there are several hyphens before of after it (as in
> "sbcl-3d-vectors-3.1.0-1.29bb968" or "nyxt-2-pre-release-6")?

It’s implements a heuristic meant to work for most packages.  It’s hard
to tweak that without breaking something else instead.  (Plus,
“nyxt-2-pre-release-6” looks really bogus to me.)

A better fix would be to not guess and instead pass #:name and #:version
to all the build phases, with the value taken from the  object.
(That’s a world-rebuild fix though.)

WDYT?

> This is related to issue #48208, and also probably to issue #41437.

Perhaps we can find a workaround for these?

Thanks,
Ludo’.

bug#48184: Evaluating (current-guix) causes segfault

[Ludovic Courtès]

Hi,

Leo Prikler  skribis:

> Am Montag, den 03.05.2021, 14:18 +0200 schrieb Leo Prikler:
>> Am Montag, den 03.05.2021, 13:59 +0300 schrieb David Dashyan:
>> > David Dashyan writes:
>> > 
>> >  Here my guix describe output:
>> >guix 065d2cd
>> >  repository URL: https://git.savannah.gnu.org/git/guix.git
>> >  branch: master
>> >  commit: 065d2cd6ced96ddb38c15a46f798488f61660a33
>> > 
>> >  What I did?
>> >  $ guile
>> > > ,use (gnu packages package-management)
>> > > (current-guix)
>> >  $ Segmentation fault
>> I think you ought to run the above inside a `guix repl' rather than
>> your personal guile, where it yields a package.  As for why it
>> doesn't
>> when launched from your personal guile, let me get back to you after
>> some investigation.
> Follow-up, it appears we're abusing libgit in a manner similar to the
> one fixed by 5b35c9adc899749a0bd96a0e6d2c3bbf88e38963.

I think 5b35c9adc899749a0bd96a0e6d2c3bbf88e38963 fixes the issue.

David, can you try the same thing in ‘guix repl’ instead of ‘guile’?  It
works for me.

(When you’re just running ‘guile’, you’re likely loading modules from
/run/current-system/profile/share/guile, which may come from an older
revision than the one ‘guix describe’ prints.)

Thanks,
Ludo’.

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Hi Efraim,

Efraim Flashner  writes:
> In glib-2.68 test_timeout and test_timeout_slow are set to 60 and 180
> respectively.

Right.  Unfortunately, these timeouts are too short for many slower
machines, such as 32-bit ARM systems.  Bone Baboon has also recently
reported being unable to build 'glib' on a 32-bit i686 system due to
these timeouts, even when making extreme efforts to reduce load from
other processes.

> As I understand it, the tests which are are tagged '+slow' get the
> test_timeout_slow property, with the test taking the longest on that
> machine was glib:glib+slow / gvariant, at 65 seconds. By comparison, on
> my Ryzen 3900XT machine it took 2.58 seconds. I figured even at double
> that time it still fell within the 180 seconds given by default in the
> test suite so it was likely safe to remove the substitution entirely.

I think that this recently-reported bug ()
demonstrates that we can't safely remove the substitution.

> I don't have other suitably slow hardware to test on, but I am building
> it on my aarch64 board too, so I should be able to say in a day or two
> if it works there.

I don't see how a build test on your aarch64 board is relevant here.
As the comment above the 'increase-test-timeout' phase indicated, the
timeouts were increased for the sake of slower 32-bit ARM boards.

I think that we should re-introduce the 'increase-test-timeout' phase
for all systems on the 'core-updates' branch.  Is there a disadvantage,
besides having to wait a couple more minutes if a test fails to
terminate?

What do you think?

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48166: Dont stop the upgrade process - Better guix handling when Package failed to build

[Ludovic Courtès]

Hi,

Julien Lepiller  skribis:

> To do what you want (create a new generations ignoring failures) is not easy 
> to implement. We would have to "change our mind" and build a different 
> derivation for that new profile.

It’s also not desirable IMO: the way Guix operates is that either it
succeeds the operation you asked for, or it fails, but it never “changes
its mind” in the middle.

Instead, I think what would improve usability would be to notify the
user upfront when a package is known to fail to build.  The build farm
could state that when it replies to narinfo requests, and ‘guix’
commands would print a warning or even stop upfront by default.

Thanks,
Ludo’.

bug#46038: guix 1.3.0rc1 test failure: channels-news, one entry

[Ludovic Courtès]

Hi Vagrant,

Vagrant Cascadian  skribis:

> On 2021-01-22, Vagrant Cascadian wrote:
>> I've uploaded guix 1.2.0 built against guile-2.2 to Debian, and while it
>> builds fine on the official buildd.debian.org infrastructure, on amd64
>> and arm64 the "channel-news, one entry" test from tests/channels.scm
>> fails on tests.reproducible-builds.org.
>>
>> There are likely a few differences in the two build environments,
>> possibly including network access.
>>
>> Does the "channel-news, one entry" test indirectly depend on network or
>> bootstrap binaries?
>>
>> Could a difference in locale related variables affect the result of the
>> test (e.g. LANGUAGE=en:en_US vs. LANGUAGE unset, LC_ALL unset
>> vs. LC_ALL=C or LC_ALL=C.UTF-8)?
>>
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/guix.html
>
> Still basically the same story with 1.3.0rc1, in some cases this test
> fails, but I haven't consistently figured out what triggers it.
>
>
>> test-name: channel-news, one entry
>> location: /build/1st/guix-1.2.0/tests/channels.scm:324
>> source:

[...]

>> +  (lset= equal?
>> + (map channel-news-entry-title
>> +  (channel-news-for-commit channel commit5))
>> + '((("en" . "Another file!"))
>> +   (("en" . "Old news.") ("eo" . "Malnova?oj."

The culprit is right here: it should read “Malnovaĵoj”, but there’s a
question mark instead of ‘ĵ’.

Could it be that you’re not running tests in a UTF-8 locale?

Thanks,
Ludo’.

bug#48156: basic system test broken: qemu-system-x86_64: error while loading shared libraries: libXcursor.so.1: cannot open shared object file: No such file or directory

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> This is on commit 1b792e8b5275dc010c53d91062082340431204f2.
>
> → make check-system TESTS=basic
> Compiling Scheme modules...
> Selected 1 system tests...
> The following derivation will be built:
>/gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv
> building /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv...
> /gnu/store/13v06bndh09k1db50yndqi7610a9170k-qemu-5.2.0/bin/qemu-system-x86_64:
>  error while loading shared libraries: libXcursor.so.1: cannot open shared 
> object file: No such file or directory

That looks fishy.  I cannot reproduce it like this:

--8<---cut here---start->8---
$ TESTS=basic guix time-machine 
--commit=1b792e8b5275dc010c53d91062082340431204f2 -- build -m 
etc/system-tests.scm

[...]

;;; (services (file-system-/dev/shm file-system-/sys/firmware/efi/efivars 
urandom-seed term-tty3 term-tty2 virtual-terminal mcron term-tty4 
console-font-tty5 console-font-tty1 user-file-systems user-processes 
root-file-system console-font-tty2 marionette loopback syslogd nscd term-tty5 
root file-system-/dev/pts term-tty6 file-system-/sys/kernel/debug 
console-font-tty3 guix-daemon term-tty1 user-homes console-font-tty6 sysctl 
console-font-tty4 term-auto host-name file-systems udev))
# of expected passes  27
# of skipped tests1
successfully built /gnu/store/q1p7gbpxv37ycisdpl11vi4x86l73lmg-basic.drv
/gnu/store/2v80zymwawb9cvf9bhdfj87f60nrcpn3-basic
--8<---cut here---end--->8---

It’s not the same derivation though.

I can’t seem to find
/gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv nor
/gnu/store/13v06bndh09k1db50yndqi7610a9170k-qemu-5.2.0.  Where do they
come from?

Thanks,
Ludo’.

bug#48225: Wrong result of package-name->name+version

[Leo Prikler]

Am Dienstag, den 04.05.2021, 13:35 + schrieb Guillaume Le Vaillant:
> Hi,
> 
> The 'package-name->name+version' function defined in
> "guix/build/utils.scm" returns a wrong result if there is a '-'
> followed by a number in the package name:
> 
> --8<---cut here---start->8---
> (use-modules ((guix build utils)))
> (package-name->name+version "sbcl-3d-vectors-3.1.0-1.29bb968")
> 
> $1 = "sbcl"
> $2 = "3d-vectors-3.1.0-1.29bb968"
> --8<---cut here---end--->8---
> 
> It should be:
> 
> --8<---cut here---start->8---
> $1 = "sbcl-3d-vectors"
> $2 = "3.1.0-1.29bb968"
> --8<---cut here---end--->8---
> 
> Can someone think of an elegant modification for
> 'package-name->name+version' so that it finds where the version is
> even if there are several hyphens before of after it (as in
> "sbcl-3d-vectors-3.1.0-1.29bb968" or "nyxt-2-pre-release-6")?
> 
> This is related to issue #48208, and also probably to issue #41437.
I don't think there's any way to cleverly match this.  For all we know,
3d could be a version, we have 2019c, 2021a, 1a, 9d, 9100h and 063a
already.  Perhaps we should forward name and version as keyword
arguments, so that we don't have to reconstruct them, or alternatively
use a different delimiter (e.g. @)

I'm honestly surprised, that many other stuff "works fine" despite the
fact, that they'd probably also suffer from this bug.  Can anyone tell
me why emacs-2048-game builds?

bug#48086: libtool refers to native bash instead of a cross-compiled bash

[Ludovic Courtès]

Hi Maxime,

Maxime Devos  skribis:

> $ guix build libtool --target=aarch64-linux-gnu
>> /gnu/store/yspdgc9wk8ap20729f6a7k0f640r6h7c-libtool-2.4.6
> $ head -n 1 
> /gnu/store/yspdgc9wk8ap20729f6a7k0f640r6h7c-libtool-2.4.6/bin/libtool
>> #! /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
> $ objdump -h 
> /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
>> /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash: \
>> file format elf64-x86-64
>> [...]
>
> It seems the "libtool" script refers to a native bash, instead of the cross 
> bash,
> even though I used --target=aarch64-linux-gnu!

As discussed as , I think this is
not much of a problem because this ‘libtool’ is unused in practice.

I’d be in favor of dismissing this bug; WDYT?

Thanks,
Ludo’.

bug#46246: VTK fails to build, breaking FreeCAD and others

[Leo Famulari]

If I understand correctly, the VTK build failure was fixed in 
251b0f7a6fa550ef4e0975668d7ab8c4c7b214d3

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=251b0f7a6fa550ef4e0975668d7ab8c4c7b214d3

In any case, I get a substitute for FreeCAD now.

bug#44675: guix lint: support for spellchecker or basic grammar

[Ludovic Courtès]

Hi Vagrant,

Vagrant Cascadian  skribis:

> From 4e724fbe9815e1c27967b835f08d2259164538ba Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Wed, 21 Apr 2021 09:26:45 -0700
> Subject: [PATCH] lint: Add description check for pluralized "This package"
>
> Partial fix for: https://issues.guix.gnu.org/44675
>
> * guix/lint.scm (check-pluralized-this-package): Add check for
>   occurances of "This packages" in package descriptions.
> * tests/lint.scm: Add test.

I had missed this patch, nice!

> +  (define (check-pluralized-this-package description)
> +"Check that DESCRIPTION does not contain 'This packages'"
> +(if (string-match "This packages" description)
> + (list
> +  (make-warning package
> +(G_ "description contains 'This packages' but should 
> just be 'This package'")))
> + '()))

How about making this ‘check-spelling’ and generalizing a bit so that it
iterates over a bunch of regexps or strings?

Like:

(if (any (cut string-contains description <>) patterns)
 …)

where ‘patterns’ is a list of strings.

(Note that ‘string-match’ invokes libc’s regcomp + regexec, so it’s more
heavyweight than needed here.)

Thanks,
Ludo’.

bug#48225: Wrong result of package-name->name+version

[Guillaume Le Vaillant]

Hi,

The 'package-name->name+version' function defined in
"guix/build/utils.scm" returns a wrong result if there is a '-'
followed by a number in the package name:

--8<---cut here---start->8---
(use-modules ((guix build utils)))
(package-name->name+version "sbcl-3d-vectors-3.1.0-1.29bb968")

$1 = "sbcl"
$2 = "3d-vectors-3.1.0-1.29bb968"
--8<---cut here---end--->8---

It should be:

--8<---cut here---start->8---
$1 = "sbcl-3d-vectors"
$2 = "3.1.0-1.29bb968"
--8<---cut here---end--->8---

Can someone think of an elegant modification for
'package-name->name+version' so that it finds where the version is
even if there are several hyphens before of after it (as in
"sbcl-3d-vectors-3.1.0-1.29bb968" or "nyxt-2-pre-release-6")?

This is related to issue #48208, and also probably to issue #41437.

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

[Guillaume Le Vaillant]

The cl-environments and generic-cl packages are currently in Guix
(36d4877041e0651d1af56b47127b8566c0fd0259).
Closing.


signature.asc
Description: PGP signature

bug#48223: EXWM knows nothing about Guix profiles

[Leo Prikler]

Hi Guix,

I just recently helped someone debug an issue they encountered when
using EXWM.  It turned out their EMACSLOADPATH was set to
"/run/current-system/profile/share/emacs/site-
lisp:/gnu/store/1zszglsxl4zxy9alcwxjwj26d30qmyv9-emacs-
27.2/share/emacs/27.2/lisp" – quite notably, "$HOME/share/emacs/site-
lisp" was missing.

I think the launcher that we install in the install-xsession does not
do sufficient work to set up the environment variables of the session
appropriately.  In particular, I think it should source /etc/profile
prior to running Emacs.

WDYT?

bug#26604: documentation: pdf generation is broken

[zimoun]

Hi,

On Tue, 4 May 2021 at 12:04, Ricardo Wurmus  wrote:

> At least the first “wizard stuff” is merely a list of packages.
> There isn’t anything we can do to avoid the selection of packages,
> because that stuff is modular by design.  We could have an
> arbitrary collection of Texlive packages, but I’m sure we can’t
> agree on any good set because what exactly is needed depends on
> the document.

[...]

> If the problem is in figuring out what Texlive packages to install
> for generating the Guix manual: we can either document that or add
> the required packages to the inputs.

I agree.  Maybe via a manifest file?

> If you still get errors relating to fonts or font maps: this has
> been fixed on the “master” branch; the texlive-configuration
> profile hook didn’t update the font maps.

Cool!  I have missed.

Well, let close this old bug. \o/

Cheers,
simon

bug#26604: documentation: pdf generation is broken

[Ricardo Wurmus]

zimoun  writes:


Hi Ricardo,

On Mon, 03 May 2021 at 16:06, Ricardo Wurmus 
 wrote:



Shall we close this now?


Personally, I am still puzzled to build PDFs of the 
documentation, even
on core-updates, though I have not followed the recent updates 
on
master.  Maybe I am doing wrong but I still get some errors, as 
reported

in late messages of the thread [1].  Basically, it ends with:

  guix environment -C guix --ad-hoc …wizard stuff…
  …
  make pdf
  …wizard stuff…

I should still miss something.


At least the first “wizard stuff” is merely a list of packages. 
There isn’t anything we can do to avoid the selection of packages, 
because that stuff is modular by design.  We could have an 
arbitrary collection of Texlive packages, but I’m sure we can’t 
agree on any good set because what exactly is needed depends on 
the document.


It’s like creating an arbitrary set of R packages that should work 
well for any number of projects.


If the problem is in figuring out what Texlive packages to install 
for generating the Guix manual: we can either document that or add 
the required packages to the inputs.


If you still get errors relating to fonts or font maps: this has 
been fixed on the “master” branch; the texlive-configuration 
profile hook didn’t update the font maps.


--
Ricardo

bug#48213: offlineimap build fails

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Babs,

Bone Baboon via Bug reports for GNU Guix 写道：
Taking the failing test's name "test_ipv6_available" literally I 
would
like to ask if having this test required to build this 
offlineimap

dependency


I think not, but you should report this upstream first.  They look 
asleep but I didn't hold a mirror under their nose.  If they don't 
respond we might hack around it in Guix.


I suggest that you enable IPv6 support in the meantime.


This would accommodate Guix users who have disabled ipv6.


Guix doesn't virtualise the kernel and expects it to provide all 
that is needful.  Linux offers knobs for *everything*; that 
doesn't mean everything is supported.  Disabling kernel support 
for basic things (namespaces, UNIX domain sockets, IPv6) *will* 
break certain software.


We shouldn't feel obligated to accommodate strange configurations 
out of the box, but we try to do so when the maintenance cost is 
very low.  In this case, you'd need to ensure the test still runs 
on the vast majority of systems with IPv6.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#48214: inetutils-1.9.4 build fails

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Babs,

Bone Baboon via Bug reports for GNU Guix 写道：

FAIL: syslogd.sh


../src/logger: ::1:7041: Cannot assign requested address


Looks like the same cause as : 
missing IPv6 support on the host kernel.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#48216: [CORE-UPDATES] host-inputs for wrong architecture when building for i686 on x86_64

[Efraim Flashner]

I'm trying to see if the rust bootstrap process works on core-updates
and I was unable to build for i686-linux on x86_64 linux. I failed to
build xz, due to some assembly optimizations. It turns out that instead
of using i686 binaries it was using x86_64 binaries and targeting i686,
while passing flags saying it was i686.

It seems there are some other things which need another look. From the
PATH variable:
(ins)efraim@3900XT ~/workspace/guix-core-updates$ file 
/gnu/store/yf4y60dyvb5qca8ram5pvxp7ba7x0z2a-xz-5.2.5/bin/xz
/gnu/store/yf4y60dyvb5qca8ram5pvxp7ba7x0z2a-xz-5.2.5/bin/xz: ELF 64-bit LSB 
executable, x86-64, version 1 (SYSV), dynamically linked, interpreter 
/gnu/store/xd4jlar0rjsvc921b32kn40vn01638hc-glibc-2.33/lib/ld-linux-x86-64.so.2,
 for GNU/Linux 2.6.32, stripped
(ins)efraim@3900XT ~/workspace/guix-core-updates$ file 
/gnu/store/1g3vhzaw78fi04q630swrz4s9yn4wsj2-grep-3.6/bin:/gnu/store/vrdmi9lnd663np8y5hcpxvgkl35v5sby-coreutils-8.32
/gnu/store/1g3vhzaw78fi04q630swrz4s9yn4wsj2-grep-3.6/bin:/gnu/store/vrdmi9lnd663np8y5hcpxvgkl35v5sby-coreutils-8.32:
 cannot open 
`/gnu/store/1g3vhzaw78fi04q630swrz4s9yn4wsj2-grep-3.6/bin:/gnu/store/vrdmi9lnd663np8y5hcpxvgkl35v5sby-coreutils-8.32'
 (No such file or directory)

The ones listed in the environmental file at the base of the build
listed x86_64 binaries.

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


63r37flw2gv4cbna7jb69b4n8c41n6-xz-5.2.5.drv.bz2
Description: Binary data


signature.asc
Description: PGP signature

bug#26604: documentation: pdf generation is broken

[zimoun]

Hi Ricardo,

On Mon, 03 May 2021 at 16:06, Ricardo Wurmus  wrote:

> Shall we close this now?

Personally, I am still puzzled to build PDFs of the documentation, even
on core-updates, though I have not followed the recent updates on
master.  Maybe I am doing wrong but I still get some errors, as reported
in late messages of the thread [1].  Basically, it ends with:

  guix environment -C guix --ad-hoc …wizard stuff…
  …
  make pdf
  …wizard stuff…

I should still miss something.

1: 


Cheers,
simon