bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken

2019-06-03 Thread Robert Vollmert
ghc-tasty depends via “inputs” on ghc-clock-bootstrap (v0.5) which is built without tests, while ghc-clock (v0.7) depends via “native-inputs” on ghc-tasty for tests. This means that any package which depends on ghc-tasty and ghc-clock is potentially broken, e.g.: Warning: This package

bug#36078: [staging] AArch64 missing substitute for 'libdrm'

2019-06-03 Thread Marius Bakke
Hello, There is no substitute for /gnu/store/9b5y8vr3q67cx7gm41k5snkk9g4gmvdn-libdrm-2.4.98 on . Unfortunately I don't know what the problem is. There is no build log: . Does Cuirass provide

bug#36077: [staging] Mesa build failure on i686

2019-06-03 Thread Marius Bakke
Hello, On the 'staging' branch, Mesa fails a test for i686. From : --8<---cut here---start->8--- Ok: 64 Expected Fail: 0 Fail: 1 Unexpected

bug#36040: Guix Installation Bug Report

2019-06-03 Thread Danny Milosavljevic
Hi, yeah, you have a hidden Wifi network in range and we had a bug with them (see bug# 35941). It has since been fixed--but there was no new Guix release yet. If possible, can you move out of range of the hidden Wifi to install (just to install) Guix? If not, I can build a new installation iso

bug#36076: Manual should clarify that glibc-utf8-locales is needed by default on foreign distros

2019-06-03 Thread Jack Hill
Hi Guix, While setting up Guix on a foreign distribution (CentOS 7), I elected to use the full glibc-locales while following section 2.6.1 of the manual for application setup. I installed the glibc-locales package in both my user's profile and root's so that the locales would be available to

bug#36074: [PATCH] etc: guix-daemon.service.in: fix GUIX_LOCPATH quoting

2019-06-03 Thread Jack Hill
etc/guix-daemon.service.in: Move the GUIX_LOCPATH environment varialbe name inside the quotes are required in systemd unit files. --- etc/guix-daemon.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/etc/guix-daemon.service.in b/etc/guix-daemon.service.in index

bug#36074: Incorrect quoting of GUIX_LOCPATH environment variable in guix-daemon.service

2019-06-03 Thread Jack Hill
I wrote more about this on help-guix@ https://lists.gnu.org/archive/html/help-guix/2019-06/msg00024.html

bug#36074: Incorrect quoting of GUIX_LOCPATH environment variable in guix-daemon.service

2019-06-03 Thread Jack Hill
Hi Guix, Based on my experience setting up Guix on a CentOS 7 foreign distribution, if quoted, the variable name in a systemd unit Environment definition should be inside the quotes. I didn't not find definitive documentation stating this, but all the examples show it this way. If the value

bug#35996: User account password got locked when booting old generation

2019-06-03 Thread Danny Milosavljevic
For debugging, I've used "chattr +i" in the past in order to make such files (i.e. /etc/shadow) immutable. This would hopefully expose the mutator (other than Guix)--it should log some error somewhere. pgpKrPhEw9hmR.pgp Description: OpenPGP digital signature

bug#35996: User account password got locked when booting old generation

2019-06-03 Thread Ludovic Courtès
Hello, "pelzflorian (Florian Pelz)" skribis: > Please add more logging and/or locking. Note that the elogind has the > following comment in its locking implementation in > /gnu/store/dm2ri0qvjirl0iq2ndfk5z9lq9dyk4jf-elogind-241.3-checkout/src/basic/user-util.c: > > /* This is roughly

bug#35996: User account password got locked when booting old generation

2019-06-03 Thread pelzflorian (Florian Pelz)
On Mon, Jun 03, 2019 at 03:22:51PM +0200, Ludovic Courtès wrote: > > After multiple reconfigures, it happened again, my /etc/shadow has ! > > again in the password field. My recently changed root password became > > empty as well, like 35902. I did not even run sudo concurrently. The > >

bug#35785: ‘string->uri’ is locale-dependent and breaks in ‘sv_SE’

2019-06-03 Thread Timothy Sample
Hi Ludo, Ludovic Courtès writes: > Hi Timothy, > > Timothy Sample skribis: > >> Here’s a patch for Guile that uses explicit lists of characters in the >> ‘(web uri)’ module instead of character ranges. It includes two tests >> that are pretty verbose, but seem to do the trick. >> >> I have a

bug#35996: User account password got locked when booting old generation

2019-06-03 Thread Ludovic Courtès
Hi Florian, "pelzflorian (Florian Pelz)" skribis: > After I booted to a Guix install USB, chrooted as described on the > Arch wiki and started a Guix daemon, I could reconfigure as before. > There was no need to fiddle with grub-install. > > After multiple reconfigures, it happened again, my

bug#35785: ‘string->uri’ is locale-dependent and breaks in ‘sv_SE’

2019-06-03 Thread Ludovic Courtès
Hi Timothy, Timothy Sample skribis: > Here’s a patch for Guile that uses explicit lists of characters in the > ‘(web uri)’ module instead of character ranges. It includes two tests > that are pretty verbose, but seem to do the trick. > > I have a bit more background on the problem, mostly

bug#35996: User account password got locked when booting old generation

2019-06-03 Thread pelzflorian (Florian Pelz)
Please add more logging and/or locking. Note that the elogind has the following comment in its locking implementation in /gnu/store/dm2ri0qvjirl0iq2ndfk5z9lq9dyk4jf-elogind-241.3-checkout/src/basic/user-util.c: /* This is roughly the same as lckpwdf(), but not as awful. We *

bug#35996: User account password got locked when booting old generation

2019-06-03 Thread Gábor Boskovits
Hello, pelzflorian (Florian Pelz) ezt írta (időpont: 2019. jún. 3., Hét 8:04): > After I booted to a Guix install USB, chrooted as described on the > Arch wiki and started a Guix daemon, I could reconfigure as before. > There was no need to fiddle with grub-install. > > After multiple

bug#35996: User account password got locked when booting old generation

2019-06-03 Thread pelzflorian (Florian Pelz)
After I booted to a Guix install USB, chrooted as described on the Arch wiki and started a Guix daemon, I could reconfigure as before. There was no need to fiddle with grub-install. After multiple reconfigures, it happened again, my /etc/shadow has ! again in the password field. My recently