bug#29634: Hydra fails to honor 'max-silent-time' for early guile build

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> An early 'guile' build on armhf-linux consistently fails on Hydra, >> because the 'timeout' and 'max-silent-time' properties are not honored. >> For example: >> >> https://hydra.gnu.org/build/2391845 >> >> This is a longstandi

bug#29662: 'guix gc' as user makes system unbootable

Hi Quiliro, > 'guix gc' as user makes system unbootable.- > > I had executed 'guix gc' and then 'guix package -i blender' and then > 'guix package -u', all as user without running 'guix pull' recently > (did it last week). When rebooting, current GrUB boot menu entry did > not work. But previous

bug#29662: 'guix gc' as user makes system unbootable

Ricardo Wurmus writes: > Quiliro Ordonez Baca writes: > 'guix gc' as user makes system unbootable.- > […] >>> Did you remove anything under /var/guix/profiles/ before running “guix >>> gc”? >> >> No. > > Could you please show us the output of this command: > >ls -l /var/guix/profiles/sy

bug#29662: 'guix gc' as user makes system unbootable

Quiliro Ordonez Baca writes: >>> 'guix gc' as user makes system unbootable.- […] >> Did you remove anything under /var/guix/profiles/ before running “guix >> gc”? > > No. Could you please show us the output of this command: ls -l /var/guix/profiles/system* Has the disk label changed? -- R

bug#29662: 'guix gc' as user makes system unbootable

Ricardo Wurmus writes: > Hi Quiliro, > >> 'guix gc' as user makes system unbootable.- >> >> I had executed 'guix gc' and then 'guix package -i blender' and then >> 'guix package -u', all as user without running 'guix pull' recently >> (did it last week). When rebooting, current GrUB boot menu ent

bug#29662: 'guix gc' as user makes system unbootable

'guix gc' as user makes system unbootable.- I had executed 'guix gc' and then 'guix package -i blender' and then 'guix package -u', all as user without running 'guix pull' recently (did it last week). When rebooting, current GrUB boot menu entry did not work. But previous versions (#1,#2,#3) worke

bug#23274: Misleading error message when running guix-daemon as unprivileged user

Hi Martin, Martin Castillo skribis: >> “Address already in use” makes me directly think that there is already >>another daemon running. > > This was in response to OP, saying that I don't think that needs to be > changed. > > The rest was about testing it with root and I (half) expected an erro

bug#29337: Bash reads system-wide bashrc unconditionally.

Ludovic Courtès writes: > Roel Janssen skribis: > >> Ludovic Courtès writes: > > [...] > > Now, we’re compiling Bash with "-DSYS_BASHRC='\"/etc/bashrc\"'". I > wonder if removing that flag solves the --init-file case. It does. So, I have a custom bash package for my specific

bug#23274: Misleading error message when running guix-daemon as unprivileged user

Hi, I could have expressed myself more clearly. > “Address already in use” makes me directly think that there is already >another daemon running. This was in response to OP, saying that I don't think that needs to be changed. The rest was about testing it with root and I (half) expected an err

bug#29337: Bash reads system-wide bashrc unconditionally.

Roel Janssen skribis: > Ludovic Courtès writes: [...] Now, we’re compiling Bash with "-DSYS_BASHRC='\"/etc/bashrc\"'". I wonder if removing that flag solves the --init-file case. >>> >>> It does. So, I have a custom bash package for my specific use-case. >>> I'm not sure how it affe

bug#29337: Bash reads system-wide bashrc unconditionally.

Ludovic Courtès writes: > Roel Janssen skribis: > >> Ludovic Courtès writes: >> >>> Heya, >>> >>> Roel Janssen skribis: >>> Roel Janssen skribis: >> On CentOS 7, the following happens (yes, I added the echo-statement to >> /etc/bashrc on CentOS as well): >> $ env - bash -

bug#27284: [PATCH 1/4] gnu: Fix ambiguous 'zip' reference.

* gnu/packages/photo.scm: Hide 'zip' from (srfi srfi-1). --- gnu/packages/photo.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/photo.scm b/gnu/packages/photo.scm index 666058c9d..7e9313f82 100644 --- a/gnu/packages/photo.scm +++ b/gnu/packages/photo.scm @@

bug#27284: [PATCH 4/4] pull: Reload modules before doing anything else.

* build-aux/build-self.scm (build): Uncomment call to 'reload-guix'. Set '%fresh-auto-compile' --- build-aux/build-self.scm | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/build-aux/build-self.scm b/build-aux/build-self.scm index d9d926367..04185e0a5 100

bug#27284: [PATCH 0/4] 'guix pull' reloads modules, second try

Hello! I’ve pushed the following patches to ‘wip-pull-reload’ so you can test from whatever snapshot you’re currently running: guix pull --branch=wip-pull-reload As a reminder, this patch set does two things: 1. Build Guix as several derivations, with the eventual goal of having substi

bug#27284: [PATCH 2/4] gexp: 'computed-file' has a new #:guile parameter.

* guix/gexp.scm ()[guile]: New field. (computed-file): Add #:guile. (computed-file-compiler): Honor 'guile'. --- guix/gexp.scm | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/guix/gexp.scm b/guix/gexp.scm index 1929947d9..f005c4d29 100644 --- a/guix/gexp.scm +

bug#27284: [PATCH 3/4] Add (guix self) and use it when pulling.

This mitigates . * guix/self.scm: New file. * Makefile.am (MODULES): Add it. * po/guix/POTFILES.in: Add it. * build-aux/build-self.scm (libgcrypt, zlib, gzip, bzip2, xz) (false-if-wrong-guile, package-for-current-guile, guile-json) (guile-ssh, guile-git, guile-bytestruc

bug#29642: guix 0.14.0 cannot use HTTPS with guile 2.0

Hello, ng0 skribis: > 藍挺瑋 transcribed 1.7K bytes: >> This problem happens on Fedora 27, which uses Guile 2.0.14. > > Do we still support building with guile 2.0? Yes. >> If I revert commit 866f37f, this problem can be avoided. The commit >> (download: Improve efficiency of 'write-request' over

bug#29634: Hydra fails to honor 'max-silent-time' for early guile build

Mark H Weaver skribis: > An early 'guile' build on armhf-linux consistently fails on Hydra, > because the 'timeout' and 'max-silent-time' properties are not honored. > For example: > > https://hydra.gnu.org/build/2391845 > > This is a longstanding issue. In past core-updates cycles, I have > w

bug#23274: Misleading error message when running guix-daemon as unprivileged user

Hi Martin, Martin Castillo skribis: > “Address already in use” makes me directly think that there is already > another daemon running. Strangely, starting another daemon as root > works. It seems to take the socket from the other daemon away. Is this > intended? Or can two daemons run in paralle