bug#30537: glibc 2.26 refuses to run on CentOS 6.8

On Mon, Feb 19, 2018 at 07:46:02PM +0100, Ricardo Wurmus wrote: > Hi Guix, > > I have a bad day. After the upgrade to glibc 2.26 none of the > Guix-installed software runs on the HPC cluster running CentOS 6.8. > > The glibc 2.26 expects a minimum kernel version of 3.x on x86_64, but > CentOS 6.

bug#30540: ssh: No user exists for uid 1000

Hello Leo, On Mon, Feb 19, 2018 at 07:30:44PM -0500, Leo Famulari wrote: > We discussed this previously in . > On Debian Stretch, I found that `apt-get install nscd` was sufficient. > I'm going to merge this report with #30298. thank you for your helpful reply and for

bug#30537: glibc 2.26 refuses to run on CentOS 6.8

On Mon, Feb 19, 2018 at 08:22:29PM -0500, Leo Famulari wrote: > My questions are, how does the glibc team choose the minimum kernel > version? What could go wrong if we apply this patch and somebody uses > Guix on a pre-3.2.0 kernel? > > Perhaps they simply chose to not support glibc on any kernel

bug#30540: ssh: No user exists for uid 1000

On Tue, Feb 20, 2018 at 11:08:17AM +0100, Andreas Enge wrote: > Hello Leo, > > On Mon, Feb 19, 2018 at 07:30:44PM -0500, Leo Famulari wrote: > > We discussed this previously in . > > On Debian Stretch, I found that `apt-get install nscd` was sufficient. > > I'm going to

bug#30540: ssh: No user exists for uid 1000

On Tue, Feb 20, 2018 at 06:54:30AM -0500, Leo Famulari wrote: > I do wonder if we should configure glibc with --enable-obsolete-nsl, > which apparentely restores the old behavior, at least until deprecation > turns into removal. I guess it depends on how many complaints there are, > and how soon we

bug#30547: Hurd patch for `patch` does not apply to latest release

There is a new version of GNU Patch, 2.7.6: https://ftp.gnu.org/gnu/patch/ I noticed that our patch, 'patch-hurd-path-max.patch', doesn't apply. I have an idea of how to adapt the patch, but I don't really have a way to test it. Manolis, are you able to adapt the patch to Patch 2.7.6? signatur

bug#30537: glibc 2.26 refuses to run on CentOS 6.8

Leo Famulari writes: > On Mon, Feb 19, 2018 at 08:22:29PM -0500, Leo Famulari wrote: >> My questions are, how does the glibc team choose the minimum kernel >> version? What could go wrong if we apply this patch and somebody uses >> Guix on a pre-3.2.0 kernel? >> >> Perhaps they simply chose to n

bug#30537: glibc 2.26 refuses to run on CentOS 6.8

On Tue, Feb 20, 2018 at 01:34:27PM +0100, Ricardo Wurmus wrote: > The only reason for moving the lower bound to Linux 3.2 is that 2.6 has > reached EOL. This allows the glibc developers to assume certain > kernel features and simplify their code. > > The RHEL kernels are special, though, in that

bug#30540: ssh: No user exists for uid 1000

On Tue, Feb 20, 2018 at 01:08:10PM +0100, Andreas Enge wrote: > On Tue, Feb 20, 2018 at 06:54:30AM -0500, Leo Famulari wrote: > > I do wonder if we should configure glibc with --enable-obsolete-nsl, > > which apparentely restores the old behavior, at least until deprecation > > turns into removal.

bug#30537: glibc 2.26 refuses to run on CentOS 6.8

Leo Famulari writes: >> For future updates to the glibc we would have to re-evaluate if the >> current RHEL 6.x kernel still supports all features the glibc expects, >> and decide once more if we can justify patching glibc to allow that one >> particular kernel version. > > Yes... and this will

bug#30547: Hurd patch for `patch` does not apply to latest release

Hello Leo, On 02/20/18 14:20, Leo Famulari wrote: > There is a new version of GNU Patch, 2.7.6: > > https://ftp.gnu.org/gnu/patch/ > > I noticed that our patch, 'patch-hurd-path-max.patch', doesn't apply. I > have an idea of how to adapt the patch, but I don't really have a way to > test it. >

bug#30522: offloading requires guile-readline on the remote system

Ludovic Courtès writes: >> It would still be good with a better failure mode, but I'll file this >> under "pebkac" for now. > > Yes, I’m surprised it ended up looping. Did you try to strace it or > something to see what was going on? Perhaps guile failed to start > altogether and Guile-SSH kept

bug#30537: glibc 2.26 refuses to run on CentOS 6.8

Ricardo Wurmus writes: > Leo Famulari writes: > >>> For future updates to the glibc we would have to re-evaluate if the >>> current RHEL 6.x kernel still supports all features the glibc expects, >>> and decide once more if we can justify patching glibc to allow that one >>> particular kernel ve

bug#30311: efi-less grub install fails

Hi Marius, hmm, if the conditional doesn't have an alternative case, doesn't that mean that the value is unspecified? The list constructor doesn't like that... You probably meant '() Other than that, I agree that something like this patch is the low-risk workaround to do.

bug#30311: efi-less grub install fails

Also, grub-hybrid is supposed to use efi so the workaround shouldn't be used with it... What do you think about my direct grub patch?

bug#30311: efi-less grub install fails

Hi Danny, >> This change breaks my mips64el-linux GuixSD system, which is supported >> by GRUB, but where "--target=i386-pc" is obviously not appropriate. On >> my system I need a different 'target' setting. > > A pretty safe workaround is to substitute /sys/firmware/efi by > /sys/firmware/non-

bug#30311: efi-less grub install fails

> I don’t understand this patch. How does it work? > > What is the effect of replacing /sys/firmware/efi with > /sys/firmware/non-efi? It won't find EFI since it's looking in the wrong place. That's what we want :)

bug#30311: efi-less grub install fails

Danny Milosavljevic writes: >> I don’t understand this patch. How does it work? >> >> What is the effect of replacing /sys/firmware/efi with >> /sys/firmware/non-efi? > > It won't find EFI since it's looking in the wrong place. > > That's what we want :) So the value “/sys/firmware/non-efi” mi

bug#30311: efi-less grub install fails

Hi Ricardo, On Tue, 20 Feb 2018 22:49:19 +0100 Ricardo Wurmus wrote: > So the value “/sys/firmware/non-efi” might as well be > “/does-not-exist”? Yes. > Your patch subject says “Make sure that non-EFI grub doesn't try to use > EFI”, but the problem I had was that GRUB insisted on being passed

bug#30562: "guix import pypi" fails now with "guix pulled" guix.

"guix import pypi" fails now with "guix pulled" guix. The "guix pulled" guix is: latest -> /gnu/store/97s03kq3ppc626bw6hpnyhias2pmp5wp-guix-latest . $ guix import pypi pytest-warnings Backtrace: 14 (apply-smob/1 #) In ice-9/boot-9.scm: 713:2 13 (call-with-prompt _ _ #) In ice-9/ev

bug#30562: "guix import pypi" fails now with "guix pulled" guix.

Danny Milosavljevic writes: > "guix import pypi" fails now with "guix pulled" guix. > > The "guix pulled" guix is: > > latest -> /gnu/store/97s03kq3ppc626bw6hpnyhias2pmp5wp-guix-latest > > . > > $ guix import pypi pytest-warnings > Backtrace: > 14 (apply-smob/1 #) > In ice-9/boot-9.scm: