bug#35387: unpack phase in the gnu-build-system is sometimes non-deterministic
Ludovic Courtès writes:
> Hi Chris,
>
> Christopher Baines skribis:
>
>> I believe that the direnv package has encountered an issue with the
>> gnu-build-system [1].
>>
>> 1: https://issues.guix.info/issue/35386
>>
>> Due to the combination of the 'setup-go-environment phase from the
>> go-build-system, and the 'unpack phase of the gnu-build-system, there
>> are two directories to be considered by first-subdirectory when called
>> from the unpack phase.
>>
>> It seems from direnv that this either consistently, with the package
>> working on one machine, or failing consistently on another.
>>
>> To avoid issues like this in the future, I think it would be good to
>> have first-subdirectory raise an error if it's behaviour could be
>> non-deterministic.
>
> ‘file-system-fold’ is just a wrapper around ‘readdir’ so the order in
> which it sees directory entries is non-deterministic.
>
> What about writing it like this:
>
> (define (first-subdirectory directory)
> "Return the file name of the first sub-directory of DIRECTORY."
> (match (scandir directory
> (lambda (file)
> (and (not (member file '("." "..")))
>(file-is-directory? (string-append directory "/"
> file)
> ((first . _) first)))
>
> The result will be deterministic since ‘scandir’ sorts entries.
That sounds great :)
signature.asc
Description: PGP signature
bug#35500: ocaml-utop fatal error
Le Mon, 29 Apr 2019 21:58:49 -0500, Brett Gilio a écrit : > I have ocaml-utop installed in an environment. When I run utop from > the shell it returns this rather unamusing error message. > > brettg@guixsd ~ [env]$ utop > Fatal error: exception Not_found > > There is a reference to this error on github, here > https://github.com/ocaml-community/utop/issues/224 > > I tried patching this myself but I did not get far. > > Brett Gilio > > > Running strace on utop showed that it was trying to open a file in /usr and that's what it couldn't find. Fixed in 6215132155e1a36629fdc5001edbf9dd53ead93f.
bug#35462: maven ignoring mirror-settings in ~/.m2/settings.xml
Le Sat, 27 Apr 2019 22:53:37 +0200, Arne Babenhauserheide a écrit : > Hi, > > When I set a mirror in ~/.m2/settings.xml, that mirror is not used by > the maven in Guix. > > To reproduce: > > mkdir -p ~/.m2/ > echo ' > > > > internal > foo > bar > > > > > nexus > nexus > http://nexus.example.com/nexus/content/groups/public/ > * > > > > ' > ~/.m2/settings.xml > # run maven somewhere > > With this setting, maven should run every request through the > configured nexus (which in this case means that any try to download > should fail). > > In my setup, maven just ignores this setting and keeps downloading > from repo.maven.apache.org which (a) could leak internal information > and (b) does not get our internal packages. > > Best wishes, > Arne Hi, I've given a look at this bug and it seems that our maven package totally ignores settings, even if given on the CLI: mvn help:effective-settings --debug -s ~/.m2/settings.xml -gs ~/.m2/settings.xml has no effect... strace -f mvn ... doesn't show any reference to a settings.xml either (not even the globabl one in the store...).
bug#35484: GDM failing to start stumpwm after merge
Hello! Timothy Sample skribis: > I pushed three commits to master: > > 1. e8c6e771c1 gnu: gdm: Avoid selecting the placeholder session. > 2. 4ec42524dd gnu: awesome: Use absolute paths in session file. > 3. aa7cdc57dc gnu: i3-wm: Use absolute paths in session files. > > I then cherry-picked them onto the “version-1.0.0” branch. Sorry if > that’s not what you meant. That’s exactly what I meant, thank you! :-) Ludo’.
bug#35475: [bug #35475] [PATCH] Add filesystem flag NOATIME
rendaw <7e9wc56emja...@s.rendaw.me> skribis: > On 4/29/19 7:14 PM, Ludovic Courtès wrote: [...] >> I tweaked the doc, added a commit log that follows our conventions¹, and >> committed. >> >> Thank you! >> >> Ludo’. >> >> ¹ >> https://www.gnu.org/software/guix/manual/en/html_node/Submitting-Patches.html > > Thank you! And sorry, I'll read more carefully next time. Don’t be sorry, it’s perfectly understandable! Ludo’.
bug#35501: libplist 2.0.0 build failure: File does not exist.
Hi Brendan, Brendan Tildesley skribis: > = > libplist 2.0.0: test/test-suite.log > = > > # TOTAL: 29 > # PASS: 26 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 3 > # XPASS: 0 > # ERROR: 0 > > .. contents:: :depth: 2 > > FAIL: largecmp > == > > File does not exists > FAIL largecmp.test (exit status: 2) > > FAIL: hugecmp > = > > File does not exists > FAIL hugecmp.test (exit status: 2) > > FAIL: bigarraycmp > = > > File does not exists > FAIL bigarraycmp.test (exit status: 2) It seems to be a non-deterministic failure. Could you see if setting #:parallel-builds? #f and then building with ‘--rounds=10’ (say) works? Thanks, Ludo’.
bug#35501: libplist 2.0.0 build failure: File does not exist.
Ludovic Courtès skribis: > It seems to be a non-deterministic failure. > > Could you see if setting #:parallel-builds? #f and then building with > ‘--rounds=10’ (say) works? I’ve confirmed this and pushed the fix as e4b2866cd015a52973063c0b389cf328ef0b9d18. Ludo’.
bug#35462: maven ignoring mirror-settings in ~/.m2/settings.xml
Hi Julien, Julien Lepiller writes: >> In my setup, maven just ignores this setting and keeps downloading >> from repo.maven.apache.org which (a) could leak internal information >> and (b) does not get our internal packages. > I've given a look at this bug and it seems that our maven package > totally ignores settings, even if given on the CLI: > > mvn help:effective-settings --debug -s ~/.m2/settings.xml > -gs ~/.m2/settings.xml > > has no effect... > > strace -f mvn ... doesn't show any reference to a settings.xml either > (not even the globabl one in the store...). Thank you for checking! Do you have an idea how we can fix that? Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
bug#35350: Some compile output still leaks through with --verbosity=1
Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Ludovic Courtès writes: >> >>> The third read(2) call here ends on a partial UTF-8 sequence for LEFT >>> SINGLE QUOTATION MARK (we get the first two bytes of a three byte >>> sequence.) >>> >>> What happens is that ‘process-stderr’ in (guix store) gets that byte >>> string from the daemon, passes it through ‘read-maybe-utf8-string’, >>> which replaces the last two bytes with REPLACEMENT CHARACTER, which is >>> itself a 3-byte sequence. >> >> It seems to me that what's needed here is to save the UTF-8 decoder >> state between calls to 'process-stderr'. > > So there are two things. To fix the issue you reported (build output > that goes through), I think we must simply turn off UTF-8 decoding from > ‘process-stderr’ and leave that entirely to ‘build-event-output-port’. Can we assume that UTF-8 is the appropriate encoding for (current-build-output-port)? My interpretation of the Guix manual entry for 'current-build-output-port' suggests that the answer should be "no". Also, in your previous message you wrote: The problem is the first layer of UTF-8 decoding that happens in ‘process-stderr’, in the ‘%stderr-next’ case. We would need to disable it, but only if the build output port is ‘build-event-output-port’ (i.e., it’s capable of interpreting “multiplexed build output” correctly.) It sounds like you're suggesting that 'process-stderr' should look to see if (current-build-output-port) is a 'build-event-output-port', and in that case it should use binary I/O primitives to write raw binary data to it, otherwise it should use text I/O primitives and write characters to it. Do I understand correctly? IMO, it would be cleaner to treat 'build-event-output-port' uniformly, and specifically as a textual port of unknown encoding. What do you think? > However, ‘build-event-output-port’ would still fail to properly decode > split UTF-8 sequences, and for that we’d need to preserve decoder > state as you describe. I would suggest changing 'build-event-output-port' to create an R6RS custom *textual* output port, so that it wouldn't have to worry about encodings at all, and it would only be given whole characters. Internally, it would be doing exactly what you suggest above, but those details would be encapsulated within the custom textual port. However, I don't think we can use Guile's current implementation of R6RS custom textual output ports, which are currently built on Guile's legacy soft ports, which I suspect have a similar bug with multibyte characters sometimes being split (see 'soft_port_write' in vports.c). Having said all of this, my suggestions would ultimately entail having two separate places along the stderr pipeline where 'utf8->string!' would be used, and maybe that's too much until we have a more optimized C implementation of it. Thoughts? Mark
bug#35509: Stopping gdm-service results in an unresponsive system
On my x86_64-linux system running the Guix system, when I include gdm-service in my system services, 'herd stop xorg-server' results in a state where I seemingly cannot recover except by rebooting. I'm left in what appears to be an empty Linux text console with a cursor in the top left corner, but the keyboard is unresponsive, and I'm not able to switch VTs. Perhaps there is some SysRq key combination that could be used to recover, but I haven't yet tried. Since I prefer to use Wayland, and would rather not have a separate Xorg session running that I never use, this means that currently I must avoid using 'gdm-service' entirely. Note that this is on a system running fairly recent 'master', but before 'staging' was merged. I'll try again and report back after I've finished rebuilding my post-staging-merge system. Regards, Mark
bug#35510: My GNOME sound settings occasionally get lost
On my x86_64-linux Guix system, I run GNOME 3 within Wayland. However, I need to keep 'slim-service' around for one purpose only: to occasionally remind GNOME sound settings of my preferred "alert" sound, since it forgets several times per month. I personally find the default "Drip" sound to be intolerable. However, no matter how many times I tell GNOME to use "Sonar" instead, it seems to only remember that setting for a week or so, and then reverts back to "Drip", much to my annoyance :-/. To make matters worse, the GNOME sound settings doesn't work within Wayland. It launches, and I can view my settings, but if I change *any* sound setting, it immediately crashes. When this happens, I shut down my Wayland session, relaunch SLiM, log into GNOME within Xorg, reset the alert sound to "Sonar", and then switch back into Wayland. In the meantime, if anyone knows the magic incantation to change the GNOME alert sound to "Sonar" without using GNOME sound settings (and preferably from the command line) I would be grateful. Note that I'm running recent 'master', but pre-staging-merge. It's possible that the problem was fixed in 'staging'. I'll report back after I finish building my post-staging-merge system. Mark
bug#33693: Missing icons in GNOME Shell since core-updates merge
This issue was fixed when 'staging' was merged into master, so I'm closing this bug. Mark
bug#35010: Many CPAN download URLs are no longer available
I believe that these broken URLs are now fixed, so I'm closing this bug. Mark
bug#35519: librsvg broken on i686-linux
Hydra failed to build librsvg on i686-linux, because it depends on Rust which is still broken on i686-linux in Guix. https://hydra.gnu.org/build/3477308 Mark
bug#35520: libplist FTB on i686, causing loss of Nautilus, MATE, LXDE, GNOME, etc
libplist fails to build on i686-linux: https://hydra.gnu.org/build/3484341 Collateral damage from this includes GVFS, Nautilus, MATE, LXDE, and GNOME. Mark
bug#35462: maven ignoring mirror-settings in ~/.m2/settings.xml
Le 30 avril 2019 22:15:25 GMT+02:00, Arne Babenhauserheide a écrit : >Hi Julien, > >Julien Lepiller writes: >>> In my setup, maven just ignores this setting and keeps downloading >>> from repo.maven.apache.org which (a) could leak internal information >>> and (b) does not get our internal packages. >> I've given a look at this bug and it seems that our maven package >> totally ignores settings, even if given on the CLI: >> >> mvn help:effective-settings --debug -s ~/.m2/settings.xml >> -gs ~/.m2/settings.xml >> >> has no effect... >> >> strace -f mvn ... doesn't show any reference to a settings.xml either >> (not even the globabl one in the store...). > >Thank you for checking! Do you have an idea how we can fix that? > >Best wishes, >Arne I hade no idea :/ Maybe there's something wrong wuth our maven-settings or something maven expects is not there which leads it to not load config?
