bug#40682: Installer hangs while connecting to WiFi network

[Maxim Cournoyer]

Hello,

Mathieu Othacehe  writes:

> Hey Leo,
>
>> If we have a fix, can we make a new installer image? There are people on
>> #guix having trouble getting online in the installer, and I think they
>> are hitting this issue.
>
> This bug has been fixed with ea6594e0. However, I left the ticket open
> because I'm supposed to add some testing using the hostapd service Ludo
> proposed.

Are these still in your plans?  Otherwise let's close this old,
high severity bug.

> Regarding providing a new image, I proposed a patch here[1] so that
> Cuirass can host fresh installation images built upon master.

This has been implemented for a while, congrats!

-- 
Thanks,
Maxim

bug#45051: Guix pull fails: `In procedure put-string: Wrong type argument in position 1 (expecting open output port): #`

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hi pkill9,
>
> pkill9  skribis:
>
>> Computing Guix derivation for 'x86_64-linux'... /@ substituter-started
>> /gnu/store/9ph7spq3b72fv4scqqzwxalb8n0wc6xn-graphviz-2.42.3-doc
>> substitute -following redirection to
>
> Could it be that your substitute URL is ?
>
> If so, could you try:
>
>   guix build inkscape --substitute-urls=https://ci.guix.gnu.org

Given this was the actual problem, what was the underlying error that
should have appeared in the error output that would have made that
clear?  A TLS cert validation error?

-- 
Thanks,
Maxim

bug#44903: Guix 1.2.0 installer 'auto-partition!' crash

[Maxim Cournoyer]

Hello,

Gavaskar Kanagaraj  writes:

[...]

> 1764:13 6 (_ #< components: (#<> 
> #<6origin
> origin: "struct-vtable"> #< message: "Wrong type argument in position 
> 1
> (expecting struct): ~S"> #<@irrit.>
> In ice-9/eval.scm:
>
> 619:8 5 (_ #(#(# #< name
> newt init: # exit: # exit-error: 
> # exit-error (file key args)> f..>) .))
>
> 619:8 4 (_ #(#(#(# #< name
> newt init: # exit: # exit-error: 
> # exit-error (file key arg..>) ..) #))
>
> In ice-9/ports.scm:
>
>  [cid:5bb3afc3-1a99-4cf8-a4a4-4e1f7c324061]
> [cid:1404e5ea-4a8f-426a-8dde-e061f3d6211c]

Mathieu, do you think this bug can still exist in 1.3.0 or our current
snapshot installer images?  If not, we should close it, as it's gone
stale and reported against 1.2.0.

-- 
Thanks,
Maxim

bug#34427: guile-bootstrap@2.2 segfault?

[Maxim Cournoyer]

tags 34427 -important
thanks

Hi,

Efraim Flashner  writes:

[...]

>> Besides, if PPC32 is the only platform that has a problem, I think this
>> bug should not be a blocker.
>> 
>> WDYT?
>> 
>> Ludo’.
>
> Here's what I get from strace when running on bare metal. I agree, if
> it's only affecting ppc32 we shouldn't have it be a blocker.

I'd removing the important flag since this appears to affect only ppc32
architecture and has been dormant for years.

Thanks,

Maxim

bug#23118: Duplicate entries in various environment variables

[Maxim Cournoyer]

Hi,

[...]

> More generally, this can become an issue when environment variables
> reach a certain size (and has led to bug reports in Guix before, which
> have since been fixed).  POSIX mandates a syntax, that would allow
> removing already present components first (see [1]), but I can hardly
> imagine what monstrosities we would need to cook up to do this
> reliably.  Not to mention, that some otherwise POSIX-compliant shells
> might not implement that syntax (correctly).

Why are we talking about POSIX here?  Our wrap-program procedure makes
use of Bash; we could make use of its features to filter duplicates,
right?  Unless I'm missing something.

-- 
Thanks,
Maxim

bug#22608: Module system thread unsafety and .go compilation

[Maxim Cournoyer]

Hi,

l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> To speed up the compilation of the many Scheme files in Guix, we use a
>> script that first loads all modules to be compiled into the Guile
>> process (by calling 'resolve-interface' on the module names), and then
>> the corresponding Scheme files are compiled in a par-for-each.
>>
>> While Guile's module system is known to be thread unsafe, the idea was
>> that all mutation should happen in the serial loading phase, and the
>> parallel compile-file calls should then be thread safe.
>>
>> Sadly that assumption isn't met when autoloads are involved.
>
> For the record, these issues should be fixed in Guile 2.2.4:
>
> 533e3ff17 * Serialize accesses to submodule hash tables.
> 46bcbfa56 * Module import obarrays are accessed in a critical section.
> 761cf0fb8 * Make module autoloading thread-safe.
>
> ‘guix pull’ now defaults to 2.2.4, so we’ll see if indeed those crashes
> disappear.

I think we haven't seen these in the last 4 years!  We still have
references to https://bugs.gnu.org/15602 in our code base though;
although the upstream issue appears to have been fixed.  Could we remove
the workarounds now?

-- 
Thanks,
Maxim

bug#25018: GC incorrectly removes the temporary root file of the calling process

[Maxim Cournoyer]

Hi Ludo,

l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> The ‘readTempRoots’ function in gc.cc has this:
>
> /* Try to acquire a write lock without blocking.  This can
>only succeed if the owning process has died.  In that case
>we don't care about its temporary roots. */
> if (lockFile(*fd, ltWrite, false)) {
> printMsg(lvlError, format("removing stale temporary roots file 
> `%1%'") % path);
> unlink(path.c_str());
>
> There’s a thinko here: locking the file also succeeds when the lock is
> already held by the calling process.
>
> In that case, this code ends up removing the temporary root file of
> calling process, which is bad.  Here’s a sample session:
>
> scheme@(guile-user)> ,use(guix)
> scheme@(guile-user)> (define s (open-connection))
> scheme@(guile-user)> (current-build-output-port (current-error-port))
> $2 = #
> scheme@(guile-user)> (set-build-options s #:verbosity 10)
> $3 = #t
> scheme@(guile-user)> (add-text-to-store s "foo" "bar!")
> acquiring global GC lock `/var/guix/gc.lock'
> acquiring read lock on `/var/guix/temproots/4259'
> acquiring write lock on `/var/guix/temproots/4259'
> downgrading to read lock on `/var/guix/temproots/4259'
> locking path `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo'
> lock acquired on `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo.lock'
> `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo' has hash 
> `c756ef12a70bad10c9ac276ecd1213ea7cc3a2e6c462ba47e4f9a88756a055d0'
> lock released on `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo.lock'
> $4 = "/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo"
> scheme@(guile-user)> (delete-paths s (list $4))
> acquiring global GC lock `/var/guix/gc.lock'
> finding garbage collector roots...
> executing 
> `/gnu/store/l99rkv2713nl53kr3gn4akinvifsx19h-guix-0.11.0-3.7ca3/libexec/guix/list-runtime-roots'
>  to find additional roots
> […]
> reading temporary root file `/var/guix/temproots/4259'
> removing stale temporary roots file `/var/guix/temproots/4259'
> […]
> considering whether to delete 
> `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo'
> |   invalidating path `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo'
> |   deleting `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo'
> |   recursively deleting path 
> `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo'
> |   |   /gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo
> deleting `/gnu/store/trash'
> recursively deleting path `/gnu/store/trash'
> |   /gnu/store/trash
> deleting unused links...
> deleting unused link 
> `/gnu/store/.links/1l2ml1b8ga7rwi3vlqn4wsic6z7a2c9csvi7mk4i1b8blw9fymn7'
> note: currently hard linking saves 6699.22 MiB
> $5 = ("/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo")
> $6 = 4096
>
> Notice the “removing stale temporary roots file” message.
>
> Eelco: shouldn’t it be changed along the lines of the attached path?
>
>
> Thanks,
> Ludo’.
>
> diff --git a/nix/libstore/gc.cc b/nix/libstore/gc.cc
> index 72eff52..d92388f 100644
> --- a/nix/libstore/gc.cc
> +++ b/nix/libstore/gc.cc
> @@ -2,6 +2,7 @@
>  #include "misc.hh"
>  #include "local-store.hh"
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -225,10 +226,10 @@ static void readTempRoots(PathSet & tempRoots, FDs & 
> fds)
>  //FDPtr fd(new AutoCloseFD(openLockFile(path, false)));
>  //if (*fd == -1) continue;
>  
> -/* Try to acquire a write lock without blocking.  This can
> -   only succeed if the owning process has died.  In that case
> -   we don't care about its temporary roots. */
> -if (lockFile(*fd, ltWrite, false)) {
> +/* Try to acquire a write lock without blocking.  This can only
> +   succeed if the owning process has died, in which case we don't 
> care
> +   about its temporary roots, or if we are the owning process.  */
> +if (i.name != std::to_string(getpid()) && lockFile(*fd, ltWrite, 
> false)) {
>  printMsg(lvlError, format("removing stale temporary roots file 
> `%1%'") % path);
>  unlink(path.c_str());
>  writeFull(*fd, "d");
>

I'm not Eelco, but your change LGTM.  Note that the upstream version
still uses the original code [0].

I've installed the change, tested that it had the expected result:

--8<---cut here---start->8---
reading temporary root file `/var/guix/temproots/8386'
waiting for read lock on `/var/guix/temproots/8386'
got temporary root `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo'
considering whether to delete `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo'
|   cannot delete `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo' because 
it's a root
|   cannot delete `/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo' because 
it's still reachable
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
  1. :
  message: "cannot delete path 
`/gnu/store/0siy93lggjw7sfdg8gsvrzafaa974h2d-foo' since it is still alive"
   

bug#30265: Fish embeds store file names in UCS-4/UTF-32 literal strings

[Mark H Weaver]

John Soo  writes:
> I looked into it and I think a patch to fish might be required but I
> got buried in other work.

Note that commit 1bab9b9f17256a9e4f45f5b0cceb8b52e0a1b1ed (April 2021)
added support in our grafting code to find and rewrite UTF-16 and UTF-32
store references.  That might have mitigated or even eliminated the
adverse effects of this bug.

However, the Guix daemon's reference scanner still does not detect
UTF-16/32 references.  This could be a problem if some store item is
reachable *only* via UTF-16/32 store references, because "guix gc" might
delete it even though it is still needed.

However, if it is the case that every referenced store item is
represented in ASCII or UTF-8 at least once, everything should work.
Therefore, an easy workaround would be to add another phase that simply
creates a file in the output(s) that contains ASCII or UTF-8 references
to any needed store items.

  Mark

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

bug#58337: guile-build-system does not recognise and pass on #:tests?

[Maxime Devos]

Fixed by: .


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58274: giac 1.9.0-21 fails to build

[Nicolas Goaziou]

Hello,

Maxim Cournoyer  writes:

> The build of giac fails like:
>
> --8<---cut here---start->8---
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -DIN_GIAC -I. -I.. -I. -I.. 
> -g -O2 -fno-strict-aliasing -DGIAC_GENERIC_CONSTANTS -DTIMEOUT 
> -DHAVE_LIBMICROPYTHON -fpermissive -DQUICKJS -MT alg_ext.lo -MD -MP -MF 
> .deps/alg_ext.Tpo -c alg_ext.cc -o alg_ext.o >/dev/null 2>&1
> pari.cc:752:17: error: typedef ‘giac::PFGEN’ is initialized (use ‘decltype’ 
> instead)
>   752 |   typedef GEN (*PFGEN)(ANYARG);

Fixed. Thank you.

Regards,
-- 
Nicolas Goaziou

bug#26202: Guix in foreign distributions: setting XDG_DATA_DIRS causes user session to not start

[Maxim Cournoyer]

Hi,

zimoun  writes:

> Hi Nicolas,
>
> On Thu, 14 May 2020 at 19:32, Nicolas Goaziou  wrote:
>
>> Interesting.
>
> The Gnome that I use for testing is the Gnome from Debian.  The
> initial bug report was about Trisquel/Ubuntu.
>
> - In this case, I'm using Trisquel 7.
> - `gnome-session` command is provided by the
>   "gnome-session-bin", version 3.9.90-0ubuntu12.1+7.0trisquel2.
> - Display manager is lightdm (Trisquel 7's default), version
>   1.10.6-0ubuntu1+7.0trisquel1.

I'm confident that this got resolved with
30810aff713149d53cb25f36ae6d721ec66385da and
7ff169d04f52b15393b33a97959e2cd6a5957e26 of guix-install.sh.

Closing!

-- 
Thanks,
Maxim

bug#30265: Fish embeds store file names in UCS-4/UTF-32 literal strings

[John Soo]

I looked into it and I think a patch to fish might be required but I got buried 
in other work.

bug#30265: Fish embeds store file names in UCS-4/UTF-32 literal strings

[Maxim Cournoyer]

Hello,

John Soo  writes:

> Hi Ludo,
>
> I am willing to work on this. I use fish as my login shell and noticed some 
> more funky behavior when I tried to use fish-foreign-env.
>
> It looks like fish.cpp still uses widestrings. So the references to old store 
> paths I think become stale, if I understand the rest of the conversation. 
>
> I will do some more research on fish semantics and see what might be done.

Were you able to make progress on this?

-- 
Thanks,
Maxim

bug#30265: Fish embeds store file names in UCS-4/UTF-32 literal strings

[Maxim Cournoyer]

Hello,

John Soo  writes:

> Hi Ludo,
>
> I am willing to work on this. I use fish as my login shell and noticed some 
> more funky behavior when I tried to use fish-foreign-env.
>
> It looks like fish.cpp still uses widestrings. So the references to old store 
> paths I think become stale, if I understand the rest of the conversation. 
>
> I will do some more research on fish semantics and see what might be done.
>
> Thanks, as always,
>
> John
>
>
>

-- 
Thanks,
Maxim

bug#57742: QT plugins from profile not found (QT_PLUGIN_PATH)

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> [re-sending again, this time with debbugs in CC]
>
> Hello,
>
> Morgan Smith  writes:
>
>> Hello!
>>
>> Ever since commit 1f466ed6be932526fc69e72ffd50390691d0d382 we don't look
>> at the user's value of QT_PLUGIN_PATH.  The comment says this is to
>> prevent plugin confusion between Qt5 and Qt6 stuff.
>
> Yes; unfortunately Qt doesn't seem to have thought about making that
> variable usable with both Qt5 and Qt6 at the same time.  It's probably
> worth reporting the issue upstream.

Reported upstream with https://bugreports.qt.io/browse/QTBUG-107459.

-- 
Thanks,
Maxim

bug#58362: error when `guix pull'

[Maxim Cournoyer]

Hi,

Tsing Hui  writes:

> I encountered an error while using the "guix pull" command with the
> following error message:
>
>
>
>
> guix pull
> hint: Consider installing the `glibc-utf8-locales' or `glibc-locales'
> package and
> defining `GUIX_LOCPATH', along these lines:
>
>  guix install glibc-utf8-locales
>  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
>
> See the "Application Setup" section in the manual, for more info.
>
> Updating channel 'guix' from Git repository at
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git    6e3dab4
> Computing Guix derivation for 'x86_64-linux'... |
> The following derivations will be built:
>    /gnu/store/px7qqv39gf78da3s2ms0hs5p73vykcp1-profile.drv
> /gnu/store/fj89fvxlh7a4p1h0fqylfa7mlxmx9c3d-inferior-script.scm.drv
>    /gnu/store/zqk3hdg7xqvpzgli4wpka2kzbymjb48b-profile.drv
>    /gnu/store/zyayf57vhrhll4h3x7wl70264yl15mj6-guix-6e3dab473.drv
> /gnu/store/c4n9ychjch61g4clh1v0pdmknfk6q9gj-guix-6e3dab473-modules.drv
> /gnu/store/c1zb3bqv9lfwlxjjxg2ispsrxxnqg3l2-guix-system-tests-modules.drv
> /gnu/store/ygywhmyjlqazckpz6f1sgz545a15la14-guix-system-tests.drv

This was reported in the IRC #guix channnel and reverted 2 hours ago;
with the following up commits 00e843050012961e9cc41b003ea9271eab718541
and 0169aee33e154c1fa8b299c7f126f3e94a8dc9a4 reinstating it and fixing
it, respectively.

Thanks for reporting!

Closing.

-- 
Thanks,
Maxim

bug#58337: guile-build-system does not recognise and pass on #:tests?

[Maxime Devos]

Patch(es) are in theory ready; doing some additional testing (not tested 
on in-tree guile-build-system packages yet) ...


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58309: [BUG report] resolved

[Frank Pursel]

Running guix pull succeeded.  It isn't clear what changed to allow it to
succeed when it had repeatedly failed over the past 48 hrs but this
ticket should now be closed.  I am grateful for the hidden hands and/or
magic that made this possible. 

Regards,
Frank

bug#58352: guix@1.3.0-30.17134b9 test failures on i686

[Ludovic Courtès]

Ludovic Courtès  skribis:

> This is because gvfs now indirectly pulls in librsvg and thus Rust:

It’s not the only one:

--8<---cut here---start->8---
$ ./pre-inst-env  guix graph --path network-manager-applet librsvg -s i686-linux
network-manager-applet@1.28.0
libnma@1.10.2
gtk@4.8.1
gst-plugins-bad@1.18.5
librsvg@2.50.7
--8<---cut here---end--->8---

This part is addressed by these commits:

  31708431c5 tests: Attempt to build 'desktop.tmpl' on all major architectures.
  06deab3321 gnu: libnma: Depend on GTK 4.x only on supported platforms.
  a52f39ad0c gnu: rest@0.9.1: Remove dependency on gtksourceview and libadwaita.

Now the ‘guix’ package needs to be updated.

Ludo’.

bug#55484: Setup PS1 for 'guix shell/environment' in guix-install.sh

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hi,
>
> Maxim Cournoyer  writes:
>
>> Hello Guix,
>>
>> This is a feature request to take care of configuring PS1 in ~/.bashrc
>> (or the most suitable place) for users of guix-install.sh.
>>
>> It's a small thing but it provides a nicer user experience when they can
>> visually see they have entered a Guix environment.
>
> This may be a bit more involved then simply appending the snippet to
> their ~/.bashrc (if available), as Debian for example ships its own PS1
> configuration there.  I guess we could prompt the user whether they want
> the script to override their PS1 configuration.

I found a not too convoluted way to do this and pushed as 9ca0f9e5a9.

Closing.

-- 
Thanks,
Maxim

bug#58352: guix@1.3.0-30.17134b9 test failures on i686

[Ludovic Courtès]

The guix@1.3.0-30.17134b9 package has a test failure on i686-linux:

--8<---cut here---start->8---
+ for example in gnu/system/examples/*.tmpl
+ case "$example" in
+ options=
+ guix system -n disk-image gnu/system/examples/desktop.tmpl
accepted connection from pid 25354, user nixbld
guix system: warning: 'disk-image' is deprecated: use 'image' instead
guix system: error: package gvfs@1.50.2 does not support i686-linux
+ rm -f t-guix-system-24535 t-guix-system-error-24535 
/tmp/guix-build-guix-1.3.0-30.17134b9.drv-0/t-guix-system-24535/config.scm 
/tmp/guix-build-guix-1.3.0-30.17134b9.drv-0/t-guix-system-24535/my-torrc
+ rmdir /tmp/guix-build-guix-1.3.0-30.17134b9.drv-0/t-guix-system-24535
FAIL tests/guix-system.sh (exit status: 1)
--8<---cut here---end--->8---

This is because gvfs now indirectly pulls in librsvg and thus Rust:

--8<---cut here---start->8---
$ ./pre-inst-env  guix graph --path gvfs librsvg -s i686-linux
gvfs@1.50.2
gnome-online-accounts@3.45.2
rest@0.9.1
gtksourceview@5.5.1
gtk@4.8.1
gst-plugins-bad@1.18.5
librsvg@2.50.7
--8<---cut here---end--->8---

It is surprising to see ‘rest’ (a network lib) depend on
‘gtksourceview’; that’s for a demo program:

--8<---cut here---start->8---
$ ldd /gnu/store/6ghbgz1slh70g173rsyhlvs1clgsfva4-rest-0.9.1/bin/librest-demo | 
grep sourcevi
libgtksourceview-5.so.0 => 
/gnu/store/ww28crn08wlg59ldfqhcgk1g8dhsf6cw-gtksourceview-5.5.1/lib/libgtksourceview-5.so.0
 (0x7fad0d574000)
--8<---cut here---end--->8---

I’ll probably tackle it from that angle.

Ludo’.

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

[Christopher Baines]

Leo Famulari  writes:

> On Wed, Jan 19, 2022 at 11:28:28AM -0800, Vagrant Cascadian wrote:
>> I tried building a newer version, but there were new test suite failures
>> on both aarch64 and x86_64 :/
>
> Since the 'guix' package still does not build on aarch64, I'm reopening
> this bug.

It looks to me that there were problems with the guix package on
aarch64-linux, but it's working currently.

1: 
https://data.guix.gnu.org/repository/1/branch/master/package/guix/output-history?output=out=aarch64-linux=none

Also, substitute availability for aarch64-linux and armhf-linux is
OK. Does that mean this issue can be closed?

Thanks,

Chris


signature.asc
Description: PGP signature

bug#28510: crash: guix build -S foo --with-source=bla

[jeremy]

Le 2022-09-20 21:42, Josselin Poiret a écrit :

Hi Simon,

zimoun  writes:


Well, I would add an error handler; as proposed [1]. :-)  Because does
“guix build foo --source --with-source=bla” make sense?  What is the
use-case for such command?


My bad, I didn't see the previous discussion on the subject.  To me, 
the

lack of generality would be unexpected: if I have a package with a
source, I expect to be able to get that source, whatever the source may
be.  Maxime's minimal example shows that it could happen for a variety
of different reasons, not just a --with-source= flag.  I don't know 
what

a proper fix for it would be though, since we're passing things around
that we pretend are derivations but are not, and in many places.

Best,


Hi !

I feel not able to take decision about the proper way right now.
So as a step forward I wrote a test to capture the behavior expected.
Please have a look at it as it's the starting point for me.
Next, I can implement the error handler, making the previous test to 
pass.
As the test checks the behaviour, it will let enough space to change 
implementation later without invalitating the test.


Cheers,
Jérémy(define-module (tests scripts build)
  #:use-module (srfi srfi-64)
  #:use-module (ice-9 exceptions)
  #:use-module (guix scripts build)
  #:use-module (srfi srfi-34))

(test-begin "scripts")

(define DUMMY_DEFINITION_PATH "/tmp/a.scm")

(define (create-dummy-definition)
  (call-with-output-file DUMMY_DEFINITION_PATH
(lambda (port)
  (format port
  "(use-modules (gnu packages) (guix packages) (guix gexp)) 
(package (inherit (specification->package \"hello\")) (source (local-file 
\"a.scm\")))"

(define (delete-dummy-definition)
  (delete-file DUMMY_DEFINITION_PATH))

(test-group-with-cleanup "build"

  (create-dummy-definition)

  (test-equal "package definition as only source"
"/gnu/store/7mnkrg9bmybgyf1dn5n67di6ng6qvhkz-a.scm"
(guard
(ex
 ((exception? ex) #f))
  (guix-build "-f" DUMMY_DEFINITION_PATH "--source")))

  (delete-dummy-definition))

(test-end "scripts")

bug#58033: A bug in file-dynamic-info used by validate-runpath in gnu-build-system and others.

[Ludovic Courtès]

Hi Lukasz,

Lukasz Olszewski  skribis:

> Then if I run $ strip --strip-unneeded --enable-deterministic-archives
> file the files can be run fine, but if I use patchelf to add an extra
> folder to the rpath strip complains like this:
> $ strip --strip-unneeded --enable-deterministic-archives
> /home/luk/dev/backup_FileStoreTest
> strip: /home/luk/dev/stt5WKN1: warning: allocated section `.dynstr'
> not in segment
>
> Then the binary has its elf header mangled as described previously.
>
> By copying the unmodified file, modifying rpath and running strip a
> couple of times I found that there is no problem if the rpath change
> results in rpath of the same or shorter length, but adding even one
> byte to it makes 'strip' later complain and mangle the binary.

I believe PatchELF has the potential to break binaries, especially when
trying to extend RUNPATH (the data has to fit in the string table;
PatchELF is supposed to be able to grow the string table as needed, but
there might be bugs.)

It looks like a workaround is to not run ‘strip’, right?

Ludo’.

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Ludovic Courtès]

Hi!

Samuel Thibault  skribis:

> Ludovic Courtès, le ven. 07 oct. 2022 00:10:15 +0200, a ecrit:

[...]

>> Of course, the thing boots just fine on that machine when using
>> ‘exec.static’.
>
> Uh. At least you have a workaround :)

Yup.  :-)

>> So the issue might be somewhere in ld.so, or triggered by ld.so.
>> Any debugging tricks here?
>
> maybe for a start check with 
>
> show map $map2
>
> what is actually mapped, whether it's just ld.so, or also exec, etc.

On the first trap (page fault) I see:

--8<---cut here---start->8---
db> show all tasks  

 ID TASK NAME [THREADS] 

  0 f5f7cf00 gnumach [7]

  1 f5f7ce40 ext2fs [6] 

  2 f5f7cd80 exec [1]   

db> show map $map2  

Map 0xf5f6ff30: name="exec", pmap=0xf5f71fa8,ref=1,nentries=5   

size=290816,resident:290816,wired=0 

version=14  

 map entry 0xf625ec08: start=0x0, end=0x1000

 prot=1/7/copy, object=0xf5f6a7d0, offset=0x0   

  Object 0xf5f6a7d0: size=0x1000, 1 references  

  1 resident pages, 0 absent pages, 0 paging ops

   memory object=0x0 (offset=0x0),control=0x0, name=0xf5938968  

   uninitialized,temporary  internal,copy_strategy=0

   shadow=0x0 (offset=0x0),copy=0x0 

 map entry 0xf625ebb0: start=0x1000, end=0x26000

 prot=5/7/copy, object=0xf5f6ad70, offset=0x0   

  Object 0xf5f6ad70: size=0x25000, 1 references 

  37 resident pages, 0 absent pages, 0 paging ops   

   memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82780  

   uninitialized,temporary  internal,copy_strategy=0

   shadow=0x0 (offset=0x0),copy=0x0 

 map entry 0xf625eb58: start=0x26000, end=0x34000   

 prot=1/7/copy, object=0xf5f6ad20, offset=0x0   

  Object 0xf5f6ad20: size=0xe000, 1 references  

  14 resident pages, 0 absent pages, 0 paging ops   

   memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82730  

   uninitialized,temporary  internal,copy_strategy=0

   shadow=0x0 (offset=0x0),copy=0x0 

 map entry 0xf625eb00: start=0x34000, end=0x37000   

 prot=3/7/copy, object=0xf5f6acd0, offset=0x0   

  Object 0xf5f6acd0: size=0x3000, 1 references  

  3 resident pages, 0 absent pages, 0 paging ops

   memory object=0x0 (offset=0x0),control=0x0, name=0xf5f826e0  

   uninitialized,temporary  internal,copy_strategy=0

   shadow=0x0 (offset=0x0),copy=0x0 

 map entry 0xf625eaa8: start=0xbfff, end=0xc000 

 prot=3/7/copy, object=0xf5f6ac80, offset=0x0   

bug#58333: Manual PDFs other than en and es fail to build

[Ricardo Wurmus]

With these two changes I can build both German and French PDF manuals:

diff --git a/po/doc/guix-manual.de.po b/po/doc/guix-manual.de.po
index edbe853248..cd7eff86f5 100644
--- a/po/doc/guix-manual.de.po
+++ b/po/doc/guix-manual.de.po
@@ -38181,7 +38181,7 @@ msgstr "{Scheme-Variable} webssh-service-type"
 #. type: deffn
 #: guix-git/doc/guix.texi:20494
 msgid "This is the type for the @uref{https://webssh.huashengdun.org/, WebSSH} program that runs a web SSH client.  WebSSH can be run manually from the command-line by passing arguments to the binary @command{wssh} from the package @code{webssh}, but it can also be run as a Guix service.  This latter use case is documented here."
-msgstr "Dies ist der Diensttyp für das Programm @uref{@uref{https://webssh.huashengdun.org/, WebSSH}}, das einen webbasierten SSH-Client ausführt. WebSSH kann von Hand aus der Befehlszeile heraus aufgerufen werden, indem man Argumente an die Binärdatei @command{wssh} aus dem Paket @code{webssh} übergibt, aber es kann auch als ein Guix-Dienst ausgeführt werden. Letzteres wird hier beschrieben."
+msgstr "Dies ist der Diensttyp für das Programm @uref{https://webssh.huashengdun.org/, WebSSH}, das einen webbasierten SSH-Client ausführt. WebSSH kann von Hand aus der Befehlszeile heraus aufgerufen werden, indem man Argumente an die Binärdatei @command{wssh} aus dem Paket @code{webssh} übergibt, aber es kann auch als ein Guix-Dienst ausgeführt werden. Letzteres wird hier beschrieben."
 
 #. type: deffn
 #: guix-git/doc/guix.texi:20500
diff --git a/po/doc/guix-manual.fr.po b/po/doc/guix-manual.fr.po
index 6762909beb..b0de8a75ba 100644
--- a/po/doc/guix-manual.fr.po
+++ b/po/doc/guix-manual.fr.po
@@ -48355,7 +48355,7 @@ msgstr "Les champs de @code{getmail-retriever-configuration} disponibles sont :"
 #: guix-git/doc/guix.texi:25540
 #, no-wrap
 msgid "{@code{getmail-retriever-configuration} parameter} string type"
-msgstr "{paramètre de @code{getmail-retriever-configuration}}string type"
+msgstr "{paramètre de @code{getmail-retriever-configuration}} string type"
 
 #. type: deftypevr
 #: guix-git/doc/guix.texi:25543

-- 
Ricardo

bug#56389: ruby-nokogiri may be non-deterministic

[Wiktor Zelazny]

On Thu, Jul 07, 2022 at 01:06:06PM -0400, Maxim Cournoyer wrote:
>
> Wiktor Zelazny  writes:
>
> > ruby-nokogiri@1.10.9 to be exact. Did not check @1.12.5. Guix version
> > 4d126e776239cc2e9b2e39718d0a1051f4a9bbc3.
>
> I checked, and only 1.10.9 is nondeterministic.  We should work toward
> eliminating 1.10.9.

Hi Maxim,

Sorry for responding so late.

The 1.10.9 comes with the TODO

   ;; TODO: In the next rebuild cycle, provide texlive a version of ruby-hydra
   ;; that does not depend on byebug and rspec, so that their dependencies can
   ;; be updated more freely.  For now pin this version to avoid rebuilds.

ruby-nokogiri@1.10.9 is an indirect input of ruby-hydra, which in turn
is an input of texlive-hyphen-package. So nothing can be done until the
“next texlive rebuild cycle”. How long are the cycles, and is the
current one coming to an end soon by a chance?

WŻ

bug#58333: Manual PDFs other than en and es fail to build

[Julien Lepiller]

You can push this fix directly to the repo, but please also fix it on weblate 
or it'll break again next time I update translations.

Le 7 octobre 2022 08:34:51 GMT+02:00, Ricardo Wurmus  a 
écrit :
>
>Ricardo Wurmus  writes:
>
>> The error in guix.de.texi is an infinite loop.  The location it points
>> out is wrong syntax:
>>
>> @uref{@uref{https://webssh.huashengdun.org/, WebSSH}}
>>
>> There shouldn’t be a double-wrapping in @uref.
>
>I can confirm that fixing the bad translation in
>po/doc/guix-manual.de.po allows us to build the German version of the
>PDF manual.
>
>-- 
>Ricardo
>
>
>

bug#58333: Manual PDFs other than en and es fail to build

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> The error in guix.de.texi is an infinite loop.  The location it points
> out is wrong syntax:
>
> @uref{@uref{https://webssh.huashengdun.org/, WebSSH}}
>
> There shouldn’t be a double-wrapping in @uref.

I can confirm that fixing the bad translation in
po/doc/guix-manual.de.po allows us to build the German version of the
PDF manual.

-- 
Ricardo