bug#28756: Substitute download progress bar doesn't reach 100%

I just upgraded to the latest Guix and, while downloading substitutes, I noticed the progress bar seems to never reach 100%, as shown below. I'm not sure if this started recently or not. Downloading https://mirror.hydra.gnu.org/guix/nar/gzip/drm4pj1k5mkb5784i0rkqb0bg2z8lmyw-libabw-0.1.1... libab

bug#28754: webkitgtk@2.18.0: WebCore/HysteresisActivity.h: No such file or directory

It seems that packages depending on webkitgtk@2.18.0 might fail to be built. What should we do? See the log below: --8<---cut here---start->8--- In file included from /tmp/guix-build-webkitgtk-2.18.0.drv-0/webkitgtk-2.18.0/Source/WebCore/platform/graphics/cai

bug#28745: tarballs generated on github are generated on demand (leading to different hash sums)

ng0 writes: > Right now we have around 449 packages with tarball sources from > github in our gnu/packages. I assume that this problem does not exist for tarballs that have been signed and uploaded by the maintainer. This is only a problem for auto-generated tarballs for tags, so it’s probably

bug#28745: tarballs generated on github are generated on demand (leading to different hash sums)

ng0 writes: > ng0 transcribed 2.1K bytes: > … >> Since some of our own dependencies are on github (at the very least >> guile-git), we need to come up with a solution. > … > > Correction: libgit2 is on github, a dependency of guile-git (which is on > gitlab). Sure, see bug#28659 ...possbily this

bug#28752: openvpn-client-service error

Hey, I am facing a problem with (openvpn-client-service) when trying to reconfigure the system. Its GuixSD on a x86-64, the system config is attached. Backtrace: In srfi/srfi-1.scm: 592:29 19 (map1 (#< type: # …)) 592:29 18 (map1 (#< type: # …)) 592:29 17 (map1 (#< type: # …)) 592:29

bug#28751: GuixSD setuid-programs handling creates setuid binaries in the store

l...@gnu.org (Ludovic Courtès) skribis: > l...@gnu.org (Ludovic Courtès) skribis: > >> On GuixSD, ‘activate-setuid-programs’ in (gnu build activation) would >> create setuid-root binaries under /gnu/store for all the programs listed >> under ‘setuid-programs’ in the ‘operating-system’ declaration.

bug#28751: GuixSD setuid-programs handling creates setuid binaries in the store

l...@gnu.org (Ludovic Courtès) skribis: > On GuixSD, ‘activate-setuid-programs’ in (gnu build activation) would > create setuid-root binaries under /gnu/store for all the programs listed > under ‘setuid-programs’ in the ‘operating-system’ declaration. Fixed by

bug#28751: GuixSD setuid-programs handling creates setuid binaries in the store

On GuixSD, ‘activate-setuid-programs’ in (gnu build activation) would create setuid-root binaries under /gnu/store for all the programs listed under ‘setuid-programs’ in the ‘operating-system’ declaration. ‘activate-setuid-programs’ in (gnu build activation) does this: (define (make-setuid-prog

bug#24445: GNOME desktop session crash when re-arranging dock

Howdy! Thomas Danckaert skribis: > Ha, I was just going to reply the same (see attached patch). I've > tested it on my system as well, and it works. > > Indeed encoding the absolute file name of the icon theme seems hard, > unless we set the icon theme inside the system configuration? Not sure

bug#28749: guix build --subsitute-urls does not override guix-daemon run with --no-subsitutes

From the kind people on #guix, I've heard that "guix build --subsitute-urls" should override "guix-daemon --no-subsitutes", but it seems it's not doing so for me. Here's the situation I ran in to: While doing a "./pre-inst-env guix pull" I got an error about: output path `/gnu/store/53lj4z9

bug#24445: GNOME desktop session crash when re-arranging dock

l...@gnu.org (Ludovic Courtès) writes: > I think that’d be OK. > > Though libXcursor contains a few ‘getenv’ calls, notably for > XCURSOR_PATH, which looks like it’s what we’re looking for. > > I tested the attached path in a VM and it seems to fix the bug: I can > drag a window in the overview ar

bug#24445: GNOME desktop session crash when re-arranging dock

Hello! Thomas Danckaert skribis: > libxcursor's configure script has an option "--with-cursorpath=" > to set a default search path for cursors. If no option is given (as is > the case with our package), the default is > DEF_CURSORPATH="~/.icons:${datadir}/icons:${datadir}/pixmaps", which is > e

bug#24445: GNOME desktop session crash when re-arranging dock

Mark H Weaver writes: > I can confirm that the problem does not occur on Debian, and I've not > found reports of it happening on any other mainstream distro. I would > guess that our unusual filesystem layout prevents GNOME Shell from > finding something that it's looking for, and that the error

bug#28745: tarballs generated on github are generated on demand (leading to different hash sums)

ng0 transcribed 2.1K bytes: … > Since some of our own dependencies are on github (at the very least > guile-git), we need to come up with a solution. … Correction: libgit2 is on github, a dependency of guile-git (which is on gitlab). -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG:

bug#28745: tarballs generated on github are generated on demand (leading to different hash sums)

Past and recent discussion in our IRC channel and on the mailing list show that we can not rely on tarballs on github keeping the same hash forever. According to github they are "generated on demand", leading to regular hash mismatches. Since some of our own dependencies are on github (at the very

bug#28743: guix package dry-run upgrade shows not required derivations (UI issue)

Previous discussion thread and attached debugging files: https://lists.gnu.org/archive/html/help-guix/2017-10/msg0.html After patching no new generation created. But dry-run still shows available upgrades and that will be build some derivations. l...@gnu.org (Ludovic Courtès) writes: > I’v