bug#26302: [website] translations

[Ludovic Courtès]

Hello Florian and all!

(Cc: sirgazil + Julien.)

Ludovic Courtès  skribis:

> I think you can go ahead and push this series to a branch, say
> ‘wip-i18n’ (the ‘wip-’ prefix meaning that you reserve the right to
> rebase the branch as you will.)
>
> We can then maybe set up a ‘static-web-site’ service on berlin, with
> appropriate nginx rules, to build and publish the manual at a separate
> URL so we can all test it.  See hydra/berlin.scm in maintenance.git.

Sorry that it’s taken this long, but I’m happy to say that the
‘wip-i18n’ branch of the manual is now visible at:

  https://guix.gnu.org/.i18n/de/
  https://guix.gnu.org/.i18n/en/

Whenever you push to that branch, the web site should be automatically
updated within an hour.

In IceCat the navigation bar at the top with “radio buttons” gets
incorrectly displayed for some reason.

We’ll need the nginx magic to honor ‘Accept-Language’ and such; I think
you submitted something that I may have overlooked, don’t hesitate to
refresh my mind.  :-)

Anyway, we have a good starting point, and perhaps we’ll be able to
switch quickly; what else do we need?


For the record, the changes to the config of berlin.guix.gnu.org to make
it possible were:

  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=e86c686b607a0f772ae004db021181607ba805ee

Thanks,
Ludo’.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Tue, Oct 22, 2019 at 02:10:59PM +0200, Ludovic Courtès wrote:
> Sorry that it’s taken this long, but I’m happy to say that the
> ‘wip-i18n’ branch of the manual is now visible at:
> 
>   https://guix.gnu.org/.i18n/de/
>   https://guix.gnu.org/.i18n/en/
> 

Thank you. :)


> Whenever you push to that branch, the web site should be automatically
> updated within an hour.
> 

I will rebase wip-i18n later this week and when the documentation
videos are decided.



> In IceCat the navigation bar at the top with “radio buttons” gets
> incorrectly displayed for some reason.
>

The CSS is not loaded from the .i18n subdirectory, it seems.


> We’ll need the nginx magic to honor ‘Accept-Language’ and such; I think
> you submitted something that I may have overlooked, don’t hesitate to
> refresh my mind.  :-)
>
> Anyway, we have a good starting point, and perhaps we’ll be able to
> switch quickly; what else do we need?
> 
> 


I would be happy if you could review my Guix patches at

https://lists.gnu.org/archive/html/bug-guix/2019-10/msg00068.html

After that I also sent maintenance patches, but redirection only works
for URLs ending in .html right now…


Regards,
Florian

bug#37822: guile-fibers build failure

[Ludovic Courtès]

Hi Chris,

Christopher Baines  skribis:

> I've now tried running the tests using Guix immediately prior to the
> recent core-updates merge (d57660c54907cc6fba8b0adf6295fd2311ada6cf),
> and immediately after the merge
> (cf3d1763ede1a329c2bc932c84591ab594bb6c96) and the tests passed before,
> and failed afterwards.
>
> I've also tried running the tests manually, I did see a couple of times
> a failure that mentioned about "Too many open files" [1].
>
> I then attempted to raise the limit for open files, I think using
> prlimit like `prlimit --nofile=8096:8096 --pid GUIX_DAEMON_PID` did the
> trick, and that meant that I built the package sucessfully.
>
> I'm thinking now that there's a relationship between the number of cores
> the tests are run with, and the required file descriptors. Also, I'm
> pretty sure this behaviour changed when core-updates was merged.

Indeed, Fibers uses ‘epoll’ and for that it consumes file descriptors
proportionally to the number of threads, IIRC.  You’d still have to have
a large number of threads to hit the default rlimit, but that’s not
impossible.

> I'll close this bug for now, as I've found a way to build the package.

To avoid “random” build failures, perhaps we should include a hack in
the ‘check’ phase, like calling ‘setrlimit’ right from there, WDYT?

Thanks,
Ludo’.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Tue, Oct 22, 2019 at 02:28:40PM +0200, pelzflorian (Florian Pelz) wrote:
> The CSS is not loaded from the .i18n subdirectory, it seems.
> 

I suppose your fix at

https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/commit/?id=0d627303680ef21efd63fba0728e39afc08d67eb

would address it had I rebased.

Regards,
Florian

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Tue, Oct 22, 2019 at 02:28:40PM +0200, pelzflorian (Florian Pelz) wrote:
> > Whenever you push to that branch, the web site should be automatically
> > updated within an hour.
> > 
> 
> I will rebase wip-i18n later this week and when the documentation
> videos are decided.
> 

Also it appears I broke URLs to the manual.

bug#37851: Grub installation only checks for encrypted /boot folder

[Ludovic Courtès]

Hola Miguel,

Miguel Arruga Vivas  skribis:

> Attached can be found a workaround to mount all encrypted partitions.
> There is no way to tell the devices to mount without changing
> boot-parameters, where I'd add another field with the needed mapped
> devices (a traversal onto the mapped-device dependency tree
> of /gnu/store).  Do you think this is a good idea?  At least I think
> it's the best way to encode the dependencies into the grub.cfg file,
> even though the typical graph will contain 0 or 1 nodes.

> From 9b50e2d8eb8b744595a54a9543993eb4e3813742 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
>  
> Date: Mon, 21 Oct 2019 14:35:02 +0200
> Subject: [PATCH] system: Mount luks devices on boot.
>
> * gnu/bootloader/grub.scm (grub-configuration-file)[builder]: Mount all
> encrypted partitions.
> ---
>  gnu/bootloader/grub.scm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
> index d984d5f5e3..b29477ec71 100644
> --- a/gnu/bootloader/grub.scm
> +++ b/gnu/bootloader/grub.scm
> @@ -369,6 +369,7 @@ keymap ~a~%" keymap)
>(format port
>"# This file was generated from your Guix configuration.  
> Any changes
>  # will be lost upon reconfiguration.
> +cryptomount -a

Does that cause GRUB to mount all the LUKS partitions it was aware of at
installation time, or does it cause it to scan all the partitions in
search of a LUKS signature?

In the latter case that wouldn’t be great, but in the former case it
sounds like we could go ahead (well, with a comment above explaining
what this does.  :-)).

Thanks for working on it!

Ludo’.

bug#37867: bug on x86_64-linux AMD box

[Leo Barge]

I found a bug.

I immediately went looking for the full log but failed to find it at the 
reported location in /tmp.  My box is a $3000 AMD system that freezes 
once or twice a day -- to let you know -- so now it is a $3000 television.


---

At hour 0437 on date 22 OCT 2019, a ten-hour long guix pull that I ran 
ended with the following message, in a summary of operation:



Full log written to 
/tmp/guix-build-glib-2.60.6.drv-0/build/meson-logs/testlog.txt

@ build-log 3297 65
command "meson" "test" "--no-suite" "flaky" failed with status 1
builder for 
`/gnu/store/r1vq08xbknz6710yxwzgf0qvca6vyqwg-glib-2.60.6.drv' failed 
with exit code 1
@ build-failed 
/gnu/store/r1vq08xbknz6710yxwzgf0qvca6vyqwg-glib-2.60.6.drv - 1 builder 
for `/gnu/store/r1vq08xbknz6710yxwzgf0qvca6vyqwg-glib-2.60.6.drv' failed 
with exit code 1
cannot build derivation 
`/gnu/store/clkn2mpdv8yahp16skpdi879fwryjl6y-texlive-bin-20180414.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/kr6c8rvrs745pjzs4dg3448fns5dmm21-po4a-0.56.drv': 1 
dependencies couldn't be built

Backtrace:
In ./guix/monads.scm:
    482:9 19 (_ _)
In ./guix/gexp.scm:
   590:13 18 (_ _)
In ./guix/store.scm:
   1685:8 17 (_ _)
In ./guix/gexp.scm:
    839:2 16 (_ _)
    695:2 15 (_ _)
In ./guix/monads.scm:
    482:9 14 (_ _)
In ./guix/gexp.scm:
   590:13 13 (_ _)
In ./guix/store.scm:
   1685:8 12 (_ _)
In ./guix/gexp.scm:
    839:2 11 (_ _)
    695:2 10 (_ _)
In ./guix/monads.scm:
    482:9  9 (_ _)
In ./guix/gexp.scm:
   590:13  8 (_ _)
In ./guix/store.scm:
   1685:8  7 (_ _)
   1685:8  6 (_ _)
  1708:38  5 (_ #)
In ./guix/packages.scm:
   948:16  4 (cache! # # ?)
In ./guix/grafts.scm:
    323:4  3 (graft-derivation # # # ?)
    172:4  2 (references-oracle # #)
   182:20  1 (_ _ _)
In ./guix/store.scm:
  1215:15  0 (_ # _ _)

./guix/store.scm:1215:15: Throw to key `srfi-34' with args `(#&store-protocol-error [message: "build of 
`/gnu/store/kr6c8rvrs745pjzs4dg3448fns5dmm21-po4a-0.56.drv' failed" 
status: 100] 5dce210>)'.
guix pull: error: You found a bug: the program 
'/gnu/store/p5jy9sxbl93208sn6rp2487b8jydrwhm-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"f5d6c88d0f5e1556295c1a19c46ddfcb7a23107f"; system: "x86_64-linux";

host version: "f27c6c16be002d3c132cfc09c5911384be853f27"; pull-version: 1).
Please report it by email to .


Leo

Communist Party

Ashland, Oregon

bug#37865: guix pull: error: You found a bug:

[Kai Mertens]

Dear Guix Developers,

unfortunately, I do not manage to update my GNU Guix version via “guix
pull”. The command fails with the listed message after being executed
for about 16hours.

I would very much apreciate if you find the time to investigate this
bug. What kind of information shall I provide, else?

best regards
Kai Mertens


~~~

guix pull: error: You found a bug: the program 
'/gnu/store/vi260mff4pp4svm3rwz7lcq7kcdxa03k-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"f0bbf894a1f935c1e0109f35899acb6dfcb977f2"; system: "i686-linux";
host version: "2e62ba46e2dc6f27398a65eb157b4ce711ff0e6b"; pull-version: 1).
Please report it by email to .

~~~

-- 
Kai Mertens 
OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net
Key fingerprint = 7C83 0A80 01FF 679C 6E8E  AFD3 40B1 5AB4 B05B 5BF1
What is that? Please check: https://emailselfdefense.fsf.org/en/



pgplNsjBAgPtC.pgp
Description: OpenPGP digital signature

bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking #include_next

[Carl Dong]

Hi all,

I ran into a similar problem in 37870, whereby the mingw-w64 search path was
placed at the top of the search paths, making include_next very grumpy.

Mark: I'm curious as to why -idirafter was not a viable solution to the problem,
as it seems like the perfect way to add a path to the bottom of the list of
search paths. Perhaps there's something more fundamental that I'm missing?

Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"

bug#37872: GUIXS cannot log in using cyrilic

[Иван Фарленков via Bug reports for GNU Guix]

after sellecting XFCE DE, choosing phonetic russion keyboard and setting user 
Админ with password парол i was unable to log in as this user (System checked 
my password for a short ammount of time before kicking me back to user select 
screen). I did not misspelled my password as i enterd it wrong afterwards and 
it produced diffrent results.
--
Иван Фарленков

bug#37876: Regression in MAKE-GCC-TOOLCHAIN after core-updates merge

[Carl Dong]

Hi all,

I believe there's been a recent regression w/re MAKE-GCC-TOOLCHAIN. I'm unable
to guix build the following minimal reproducer:

--8<---cut here---start->8---
(use-modules (gnu packages commencement)
 (gnu packages gcc)
 (gnu packages base))

(make-gcc-toolchain gcc glibc-2.27)
--8<---cut here---end--->8---

My guix describe output:
Generation 33   Oct 22 2019 15:07:03(current)
  guix f5d6c88
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: f5d6c88d0f5e1556295c1a19c46ddfcb7a23107f

The build failure logs can be found here:
https://www.dropbox.com/s/y7sg3m786ziiwvb/gcc-glibc-2.27-7.4.0.drv.log?dl=0

Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"

bug#37876: Regression in MAKE-GCC-TOOLCHAIN after core-updates merge

[Ludovic Courtès]

Hello,

Carl Dong  skribis:

> I believe there's been a recent regression w/re MAKE-GCC-TOOLCHAIN. I'm unable
> to guix build the following minimal reproducer:
>
> (use-modules (gnu packages commencement)
>  (gnu packages gcc)
>  (gnu packages base))
>
> (make-gcc-toolchain gcc glibc-2.27)
>
> My guix describe output:
> Generation 33   Oct 22 2019 15:07:03(current)
>   guix f5d6c88
> repository URL: https://git.savannah.gnu.org/git/guix.git
> commit: f5d6c88d0f5e1556295c1a19c46ddfcb7a23107f
>
> The build failure logs can be found here:
> https://www.dropbox.com/s/y7sg3m786ziiwvb/gcc-glibc-2.27-7.4.0.drv.log?dl=0

So we see tons of things like:

--8<---cut here---start->8---
In file included from 
/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/include/bits/fcntl.h:61:0,
 from 
/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/include/fcntl.h:35,
 from ../../gcc-7.4.0/gcc/system.h:349,
 from ../../gcc-7.4.0/gcc/genchecksum.c:21:
/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/include/bits/fcntl-linux.h:355:27:
 warning: ISO C++ forbids zero-size array ‘f_handle’ [-Wpedantic]
   unsigned char f_handle[0];
   ^
In file included from ./bconfig.h:3:0,
 from ../../gcc-7.4.0/gcc/genchecksum.c:20:
./auto-host.h:2363:16: error: declaration does not declare anything 
[-fpermissive]
 #define rlim_t long
^
/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/include/bits/resource.h:131:18:
 note: in expansion of macro ‘rlim_t’
 typedef __rlim_t rlim_t;
  ^~
[…]

../../gcc-7.4.0/gcc/system.h:540:20: error: conflicting declaration of C 
function ‘const char* strsignal(int)’
 extern const char *strsignal (int);
^
In file included from 
/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include/c++/cstring:42:0,
 from ../../gcc-7.4.0/gcc/system.h:235,
 from ../../gcc-7.4.0/gcc/genhooks.c:21:
/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/include/string.h:446:14: 
note: previous declaration ‘char* strsignal(int)’
 extern char *strsignal (int __sig) __THROW;
  ^

[…]

In file included from ../../gcc-7.4.0/gcc/genmodes.c:21:0:
../../gcc-7.4.0/gcc/system.h:488:14: error: conflicting declaration of C 
function ‘void* sbrk(int)’
 extern void *sbrk (int);
  ^~~~
In file included from ../../gcc-7.4.0/gcc/system.h:294:0,
 from ../../gcc-7.4.0/gcc/genmodes.c:21:
/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/include/unistd.h:1044:14:
 note: previous declaration ‘void* sbrk(intptr_t)’
 extern void *sbrk (intptr_t __delta) __THROW;
  ^~~~

[…]
make[1]: Leaving directory '/tmp/guix-build-gcc-glibc-2.27-7.4.0.drv-0/build'
make: *** [Makefile:934: all] Error 2
command "make" "-j" "48" 
"FLAGS_FOR_TARGET=-B/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/lib" 
"LDFLAGS_FOR_TARGET=-B/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/lib
 -Wl,-dynamic-linker 
-Wl,/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/lib/ld-linux-x86-64.so.2"
 "LDFLAGS=-Wl,-rpath=/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/lib 
-Wl,-dynamic-linker 
-Wl,/gnu/store/5k8l1l6j8sjws40xvlhs7hqjb68ylf7l-glibc-2.27/lib/ld-linux-x86-64.so.2"
 "BOOT_CFLAGS=-O2 -g0" failed with status
--8<---cut here---end--->8---

The ‘configure’ phase shows that ‘strsignal’ and ‘sbrk’ were not quite
found, but this is confusing:

--8<---cut here---start->8---
checking for strsignal... no
checking for pstat_getstatic... yes
checking for sysconf... no
checking for realpath... yes
checking for sysctl... yes
checking for setrlimit... yes
checking for sysmp... yes
checking for sbrk... no
checking for table... yes
checking for spawnve... no
checking for times... no
checking for spawnvpe... yes
checking for wait3... no
checking for strerror... yes
checking for wait4... yes
checking for strsignal... yes
[…]
checking whether sbrk is declared... yes
--8<---cut here---end--->8---

Does it work with ‘glibc-2.28’?

We’re not building any such toolchain in CI but we probably should…

Ludo’.

bug#37865: guix pull: error: You found a bug:

[Ludovic Courtès]

Hi Kai,

Kai Mertens  skribis:

> unfortunately, I do not manage to update my GNU Guix version via “guix
> pull”. The command fails with the listed message after being executed
> for about 16hours.

Did you enable substitutes from ?
See .

If it run for 16 hours, it may be that substitutes were disabled or
unavailable for some reason, and that Guix went ahead and started
building lots of things, eventually failing.

Perhaps the lines before the error showed the actual build issue?

> guix pull: error: You found a bug: the program 
> '/gnu/store/vi260mff4pp4svm3rwz7lcq7kcdxa03k-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "f0bbf894a1f935c1e0109f35899acb6dfcb977f2"; system: "i686-linux";
> host version: "2e62ba46e2dc6f27398a65eb157b4ce711ff0e6b"; pull-version: 1).
> Please report it by email to .

I tried reproducing it by doing:

  guix pull --commit=2e62ba46e2dc6f27398a65eb157b4ce711ff0e6b -p /tmp/old-guix
  /tmp/old-guix/bin/guix pull --commit=f0bbf894a1f935c1e0109f35899acb6dfcb977f2 
-p /tmp/old-to-new

but that worked.

So I guess the problem has to do with a transient build failure or
something.

Thanks,
Ludo’.

bug#37799: dbus-system

[Ludovic Courtès]

Bonjour,

Gnu Röoty  skribis:

>   (services (append (list (bluetooth-service)
> (udisks-service)
> (service xfce-desktop-service-type)
>   (set-xorg-configuration
>(xorg-configuration
> (keyboard-layout keyboard-layout
> %desktop-services))

Le problème s’en va si tu retires (udisks-service) ci-dessus.  Ça
faisait doublon vu qu’il est déjà dans ‘%desktop-services’, d’où une
erreur plus loin.

~~~

I wonder if there’s something we should do about it, not sure exactly
what/how.

Thoughts?

Ludo’.

bug#37822: guile-fibers build failure

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> I've now tried running the tests using Guix immediately prior to the
>> recent core-updates merge (d57660c54907cc6fba8b0adf6295fd2311ada6cf),
>> and immediately after the merge
>> (cf3d1763ede1a329c2bc932c84591ab594bb6c96) and the tests passed before,
>> and failed afterwards.
>>
>> I've also tried running the tests manually, I did see a couple of times
>> a failure that mentioned about "Too many open files" [1].
>>
>> I then attempted to raise the limit for open files, I think using
>> prlimit like `prlimit --nofile=8096:8096 --pid GUIX_DAEMON_PID` did the
>> trick, and that meant that I built the package sucessfully.
>>
>> I'm thinking now that there's a relationship between the number of cores
>> the tests are run with, and the required file descriptors. Also, I'm
>> pretty sure this behaviour changed when core-updates was merged.
>
> Indeed, Fibers uses ‘epoll’ and for that it consumes file descriptors
> proportionally to the number of threads, IIRC.  You’d still have to have
> a large number of threads to hit the default rlimit, but that’s not
> impossible.
>
>> I'll close this bug for now, as I've found a way to build the package.
>
> To avoid “random” build failures, perhaps we should include a hack in
> the ‘check’ phase, like calling ‘setrlimit’ right from there, WDYT?

If that's possible, it sounds like a good idea.


signature.asc
Description: PGP signature

bug#37876: Regression in MAKE-GCC-TOOLCHAIN after core-updates merge

[Carl Dong]

Hi Ludo’,

> Does it work with ‘glibc-2.28’?

Curiously... glibc-2.28 also doesn't work:
https://www.dropbox.com/s/ly7u4sf0umgz509/gcc-glibc-2.28-7.4.0.drv.log?dl=1

> We’re not building any such toolchain in CI but we probably should…

I think so too, happy to contribute a patch for the CI after we figure this out.

Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"

bug#37799: dbus-system

[Gnu Röoty]

Je savais que si j'enlever le udisk-service ça fonctionner mais le problème
et qu'il est impossible de monter un disque amovible sur xfce4 et je vais
pas installer GNOME juste pour obtenir gvfs afin de monter les disques
amovibles.

bug#37872: GUIXS cannot log in using cyrilic

[raingloom]

On Tue, 22 Oct 2019 19:28:19 +0300
Иван Фарленков via Bug reports for GNU Guix  wrote:

> after sellecting XFCE DE, choosing phonetic russion keyboard and
> setting user Админ with password парол i was unable to log in as this
> user (System checked my password for a short ammount of time before
> kicking me back to user select screen). I did not misspelled my
> password as i enterd it wrong afterwards and it produced diffrent
> results. -- Иван Фарленков
Just to make sure: when setting up the password, you used the same
keyboard layout as you did when you tried loggin in, right?

Either way, I've noticed that i3lock also doesn't accept my password,
and I use the default US layout, so there might be something deeper
going on here.