bug#49337: Guix pull fails on my Talos II

That's fine with me. Thank you for letting us know. If others have similar issues, they can open a new bug for it. Sorry for the top post. On Thu, Aug 10, 2023, 16:18 wrote: > This bug appears to be solved. I was able to run guix pull successfully on > my friends Talos II > yesterday and take

bug#57990: Add package: python-mat2 (remove metadata from images to improve privacy)

Apologies for the top post. I noticed this email and wanted to point you to prior work, in case it proves useful: https://issues.guix.gnu.org/31307#14 On Thu, Sep 22, 2022 at 12:24 PM Maxime Devos wrote: > > > On 22-09-2022 13:38, Dr. Arne Babenhauserheide wrote: > > > > Tobias Geerinckx-Rice

bug#51466: bug#53355: guix shell --check: confusing error message

Hi Maxime, Maxime Devos writes: > Chris Marusich schreef op za 25-06-2022 om 02:07 [-0700]: >> It turns out that it is probably not OK to rely on shell redirection >> in >> this case, after all.  For example, "dash does not support multi- >> digit &g

bug#53355: guix shell --check: confusing error message

Hi Ludo & Everyone, Chris Marusich writes: > Is it OK to rely on shell redirection? It turns out that it is probably not OK to rely on shell redirection in this case, after all. For example, "dash does not support multi-digit file descriptors": https://bugs.launchpad.net/ub

bug#51466: bug#53355: guix shell --check: confusing error message

at fixes this issue, also. Unless you have more feedback, I'll go ahead and push both patches to master in a few days. -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 From c4fee9e63f8cb694de86ae46bd1e2e4c692eb6f6 Mon Sep 17 00:00:00 2001 From: Chris Marusich

bug#53355: guix shell --check: confusing error message

inal hack (echo a few times) is OK, or perhaps we need something else. How would you like to proceed? Is it OK to rely on shell redirection? -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 From 9a1cef589abf01b61e22656f44c76441f4c50ffd Mon Sep 17 00:00:00 2001 From: C

bug#51466: bug#53355: guix shell --check: confusing error message

ot; "LS_COLORS") ;;; (variable "GUILE_LOAD_COMPILED_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/guile/3.0/site-ccache:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_COMPILED_PATH") ;;; (variable "INFOPATH=/gnu/store/h

bug#51466: bug#53355: guix shell --check: confusing error message

Hi, I also observed this bug and reported it as 53355. I tried to search for bugs, but I didn't find this bug report until Ludo mentioned it. I think it's probably the same bug, so I've merged them. Ludovic Courtès writes: > It looks like the shell-check machinery is misdiagnosing things, as

bug#53355: guix shell --check: confusing error message

Hi Ludo, Thank you for the response! Ludovic Courtès writes: > What’s confusing is that ‘--check’ does the same job whether or not > ‘--container’ is passed: it checks the behavior of your shell *outside* > a container. > > I think ‘--check’ should just do nothing when ‘--container’ is used, >

bug#53355: guix shell --check: confusing error message

Hi, I've grown so used to using "guix environment," I thought I'd try out "guix shell." It looks pretty neat! It's good to try to improve the CLI. However, when I tried "guix shell," I quickly observed this confusing behavior: --8<---cut here---start->8--- [

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

Hi, Chris Marusich writes: > If nobody has further comments, I will commit the attached version to > master in about 24 hours. I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We still need to update the "guix" package, so even if you run "guix pul

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

mlin.scm index 9e0017337a..3dbb8d3643 100644 --- a/tests/gremlin.scm +++ b/tests/gremlin.scm @@ -1,6 +1,7 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2015, 2018, 2020, 2022 Ludovic Courtès ;;; Copyright © 2022 Chris Marusich +;;; Copyright © 2022 Pierre Langlois ;;; ;;; Th

bug#52908: 'tests/guix-system.sh' fails on aarch64-linux

Hi Maxime, Aiko, and Leo, Maxime Devos writes: > Chris Marusich schreef op do 06-01-2022 om 20:32 [-0800]: >> +    (if (string-prefix? "x86_64" >> system) > > There's a target-x86-64? procedure in (guix utils) you could use

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

Aiko Kyle writes: > On the latest master I can run 'guix pull', and the latest guix seems > to build just fine, however when I go to do 'guix system reconfigure', > building guix fails the check phase. Aiko has reported that the fix for 52908 did indeed fix the "tests/guix-system.sh" problem on

bug#52908: 'tests/guix-system.sh' fails on aarch64-linux

is fix is in. Thank you for the review! Aiko, can you confirm that after running "guix pull" the issue is resolved on your end, too? -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 From 79260c8695cc5e3cd64f5b01e262369d5a67f141 Mon Sep 17 00:00:00 2001 From: Ch

bug#52908: 'tests/guix-system.sh' fails on aarch64-linux

Hi Pierre and Aiko, Pierre Langlois writes: > I believe we'll have to update the package as well. For example on > aarch64 I can do a `guix pull' just fine, however `guix system reconfigure' > fails because it builds the full guix package, including running the > tests. > > You've mentioned that

bug#52908: 'tests/guix-system.sh' fails on aarch64-linux

Hi Aiko and Leo, Aiko Kyle writes: > It would be great to get this upstreamed soon so I can start guix > pulling master. I think the guix commit and revision in > package-management.scm will also need to be bumped after applying this > fix. It shouldn't be necessary to update the guix commit an

bug#52908: 'tests/guix-system.sh' fails on aarch64-linux

Hi Aiko, Aiko Kyle writes: > Commit 9309b48 seems to be a week old and I can't seem to apply this > patch on top of the latest commit on master e6fe4e5819. How did you apply the patch? I was able to apply the patch locally to commit 80ebf564e3e264a006d7c7b1f7f2e57fc2468ef1 (".guix-authorizatio

bug#52908: 'tests/guix-system.sh' fails on aarch64-linux

#< type: # value: #< sddm: [... omitted for brevity ...] scheme@(guix-user)> --8<---cut here---end--->8--- What do you think? -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 From 09091cc8495e0b4c302a58961e79ac8455ecd208

bug#24841: close 24841

Hi, As there has been no more feedback recently, I will now close this bug report. -- Chris signature.asc Description: PGP signature

bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

Thiago Jung Bauermann writes: > GDB uses the shell to launch the debugged program. That is probably where > ‘/bin/sh’ is entering the picture here. I don’t know whether that has any > relation to your foreign distro’s libc being used. > > The output of `help run` in GDB mentions that the shell i

bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

Hi Kaelyn, Thank you for the reply. Kaelyn writes: > Are you using Guix on a foreign distro? This line looks like your > distro's normal libc.so was being used and it was from glibc-2.31 or > older. The x86-64 systems I have that run pure Guix don't have any > /lib*/ directories. You might try

bug#49516: [core-updates] glibc-2.31 patches fail to apply

Ludovic Courtès writes: > Hi! > > Chris Marusich skribis: > >> As an aside, when do we remove old versions of glibc? > > Good question. I’d say it’s enough to keep 3 versions in total. > Currently the main (only?) use case for these is when computing locale > dat

bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

Hi, I need a little help figuring out how to use gdb in Guix for bug 48941: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48941 Here's the situation. A libfaketime test hangs forever. Upstream suggested I debug it. I'm trying to, but gdb errors out. What am I doing wrong? It's probably so

bug#49337: Guix pull fails on my Talos II

Hi Tobias, Were you able to "guix pull" successfully? -- Chris signature.asc Description: PGP signature

bug#49516: [core-updates] glibc-2.31 patches fail to apply

Chris Marusich writes: > On core-updates, the glibc-2.31 patch no longer apply cleanly. Looks like the other old glibc versions explicitly declare their patches, like this: --8<---cut here---start->8--- (define-public glibc-2.30 (package

bug#49516: [core-updates] glibc-2.31 patches fail to apply

tonic.patch. We should probably retain 2.31-specific versions of these patches so that users can continue to build glibc-2.31 until we decide to remove it entirely. I have attached a patch which accomplishes this. -- Chris From b1c2c75737a3a68c78d80ba31e3d70274d0af9fe Mon Sep 17 00:00:00 2001

bug#49218: texlive-latex-base fails to build: "missing engine: luajithbtex"

Hi, I've committed the patch as 68b0e0d511c2873603636e9f783ff59aac4b7612 on core-updates. I'm closing this bug report. Chris Marusich writes: > - Will LuaJIT ever support the powerpc64le architecture? Until it does, > I guess we can't use LuaJIT on powerpc64le at all,

bug#49220: luajit doesn't support powerpc64le

Hi, Efraim Flashner writes: > On Thu, Jun 24, 2021 at 11:15:01PM -0700, Chris Marusich wrote: >> Hi LuaJIT community, >> >> Is anyone in the LuaJIT community actively working on adding support for >> the powerpc64le architecture? Specifically, I am wondering about t

bug#24841: Cross-building bootstrap binaries fail in current master

zimoun writes: > What is the status of this bug#24841 report [1]? > > 1: I agree we can close this old bug report. As you mentioned, it is now possible to build bootstrap binaries for various architectures. If someone needs to build bootstrap binaries f

bug#49337: Guix pull fails on my Talos II

Hi, FYI, I was able to successfully "guix pull" from 83f8b6d (Apr 09) to c33e200 (Jul 02) just now on my own POWER9 machine (a Blackbird). -- Chris signature.asc Description: PGP signature

bug#49337: Guix pull fails on my Talos II

Hi Tobias, Tobias Platen writes: > /gnu/store/vc2j3816jx9z4vgrw6zmk357xrka3zy0-texlive-latex-amsmath-51265.drv > wird erstellt … > \ „build“-PhaseBacktrace: > 13 (primitive-load > "/gnu/store/y5sniqlw2x5aaixyk4bw162v2a7bwdpl-compute-guix-derivation") > In ice-9/eval.scm: > 155:9

bug#49220: LuaJIT on powerpc64le-linux-gnu (POWER9)?

428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ make[1]: *** No rule to make target 'vm_ppc64.dasc', needed by 'host/buildvm_arch.h'. Stop. make[1]: Leaving directory '/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/src&

bug#49220: luajit doesn't support powerpc64le

Hi, When attempting to build luajit on powerpc64le-linux, you will get errors like this: --8<---cut here---start->8--- Building LuaJIT 2.1.0-beta3 make -C src make[1]: Entering directory '/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/sr

bug#49218: texlive-latex-base fails to build: "missing engine: luajithbtex"

ed9b8518cfb3ac502f48132fd8 Author: Leo Le Bouter Date: Mon Feb 8 04:47:03 2021 +0100 gnu: texlive-latex-base: Fix compilation on powerpc64le*. * gnu/packages/tex.scm (texlive-latex-base)[arguments]: LuaJIT is not ported to powerpc64le* yet. Update replacement 'build phase to add &quo

bug#49100: make check fails: %derivation-cache

Ludovic Courtès writes: >> The attached patch fixes the issue for me. However, since I'm not sure >> how %derivation-cache is or was supposed to be used, I would appreciate >> a second opinion. > > You forgot to attach the patch, but I think it’s enough to remove the > ‘hash-clear!’ call from ‘c

bug#47698: [powerpc64le-linux] "check" package fails to build

Committed to core-updates in bcdc13454c4afab37b650d4bbfa95e539060619f. -- Chris signature.asc Description: PGP signature

bug#49100: make check fails: %derivation-cache

Hi, On core-updates (a6c292a6f123acc86429722619ccb51ca54f844f), "make check" errors out in tests/builders.scm: --8<---cut here---start->8--- Backtrace: 1 (primitive-load-path "tests/builders.scm") In guix/tests.scm: 146:8 0 (call-with-external-s

bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

Hi, Since I'm not sure how to proceed, I've reported this upstream and asked for help: https://github.com/wolfcw/libfaketime/issues/335 -- Chris signature.asc Description: PGP signature

bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

Hi, On powerpc64le-linux, using Guix commit 7692295f970a292a3f3db31fc21d05efd97dcb25 on top of Debian unstable, the libfaketime package fails to build because one of its tests hangs. It appears to hang during the CLOCK_MONOTONIC test: --8<---cut here---start->

bug#47698: [powerpc64le-linux] "check" package fails to build

Chris Marusich writes: > [...] I've reported this issue upstream: > https://github.com/libcheck/check/issues/333 Branden Archer replied in the above issue. In short, the unreleased upstream commit 4fbe702fa4f35bee8a90512f9f59d1441c4ae82e fixes this issue on PPC platforms. Here

bug#48455: texlive-latex-graphics: non-deterministic build failure

Hi, On commit 100281dd200d0a59958fb17dc6de75d3913e2b7a, the build for texlive-latex-graphics sometimes fails and sometimes succeeds. To reproduce the issue, just try "guix build texlive-latex-graphics" or "guix build --check texlive-latex-graphics" a few times. I used this cumbersome one-liner t

bug#47698: [powerpc64le-linux] "check" package fails to build

Hi, I tried to make a minimal reproduction case, but I couldn't figure it out after a few hours of messing around with it. So, I've reported this issue upstream: https://github.com/libcheck/check/issues/333 Hopefully they can help provide some guidance. -- Chris signature.asc Description: PG

bug#43384: guix pull: backtrace "no route to host"

Jan Wielkiewicz writes: > Hello, > I tried running "guix pull" but it gave me a backtrace. > > guix substitute: error: connect: No route to host > @ substituter-failed > /gnu/store/c4mzhay8jrg5r43wkn4f9004afvly0ad-po4a-0.57 256 fetching path > `/gnu/store/c4mzhay8jrg5r43wkn4f9004afvly0ad-po4a-0.

bug#47698: [powerpc64le-linux] "check" package fails to build

Chris Marusich writes: > I don't really know what's going on, but I'll try compiling GCC 7.5.0 > with the --with-long-double option, and I'll report whether it fixes > this issue. If someone has any other idea before then, I'm all ears. It did not seem to fix

bug#47375: guix test failure: tests/print

Hi, Julien Lepiller writes: > I don't think this is the right fix. Now you define packages with the > incorrect url-fetch, so the test passes, but package->code would still > not work as intended on actual packages that are properly defined. > > It seems that the issue is package->code uses the

bug#47018: core-updates: make check fails when guix-daemon is running

Hi Lars-Dominik and Maxim, Lars-Dominik, thank you for the quick reply! Maxim, do you have time to take a look at this bug? Lars-Dominik mentioned that it's possible that your recent changes to patch-and-repack might be related somehow. Lars-Dominik Braun writes: > I’m pretty sure it worked w

bug#47018: core-updates: make check fails when guix-daemon is running

Chris Marusich writes: > One specific test failure is test/guix-package.sh, which fails as > follows: I misspoke. The failing test is tests/builders.scm. The rest of my message should be correct. -- Chris signature.asc Description: PGP signature

bug#47018: core-updates: make check fails when guix-daemon is running

Hi, Lars-Dominik, I'm CCing you on this email because you introduced the code discussed below, so I'm hoping you might know something about it. If you could please take a look, I'd really appreciate it! Starting with commit 09448c0994390697e876db235a3b773311795238, "make check" fails when a guix-

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Hi, Chris Marusich writes: > Going forward, I'm not sure how best to investigate the inputs to find > out what's causing the differences. I just know I really, really, > really don't want to rebuild everything multiple times, since it takes > hours/days. If you have

bug#46253: powerpc64le: gcc-final: "configure: error: cannot compute sizeof (long long)"

Chris Marusich writes: > configure:6100: error: cannot compute sizeof (long long) It was mentioned on IRC that a better way to fix this would be to configure libstdc++ to install to /lib instead of /lib64, since in Guix we install libraries to /lib by convention, even on 64-bit systems.

bug#45578: gnutls 3.6.12 can consistently fail to build

Leo Famulari writes: > Is it ? > > That bug is about GnuTLS 3.6.12 being written to expire — there is not > really much we can do about it. > > It's happened more than once, too. Yes, upon closer investigation, that was indeed the cause. I can confirm that I was able

bug#46253: powerpc64le: gcc-final: "configure: error: cannot compute sizeof (long long)"

Hi, This is fixed in the following commit: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-ppc64le&id=ffcc950261c829e76f2faf6c8ea03d3fc56a20e1 The problem was in the config.log, but I didn't see it at first: "powerpc64le-guix-linux-gnu-ld: cannot find -lstdc++" Léo mentioned that it w

bug#46253: powerpc64le: gcc-final: "configure: error: cannot compute sizeof (long long)"

Hi, On powerpc64le-linux, using commit a1cdd9de3cffb5677fc1570d9a7992bf0cbd2f34 (which is on the wip-ppc64le branch), gcc-final fails to build with the following error: --8<---cut here---start->8--- checking size of long long... configure: error: in `/tmp/guix

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Hi Ludo, I hope you're doing well! If you can find the time to upload those "raw" binaries, too, we can continue trying to bootstrap. For details, please refer to my last message, here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669#128 Thank you for your help! -- Chris signature.asc

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

iscover that we store these four "raw" binaries in a totally separate place. That seems like it would make it easy for someone to accidentally forget to update the "raw" binaries when they update an architecture's bootstrap tarballs. In any case, for powerpc64le-linux,

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Chris Marusich writes: > If it's just for the sake of trying one last time, we could just add > --cores=1 to the Guix invocations, or run everything in a single-core > VM. Wouldn't that have the same effect? > > I think you'll probably agree, so I've proacti

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Hi Ludo, Ludovic Courtès writes: >>> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz >>> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.asc >>> https://media.marusich.info/guix-ppc64-bootstrap/bootst

bug#45578: gnutls 3.6.12 can consistently fail to build

Hi, While attempting to run... guix pull --cores=1 --max-jobs=1 --no-substitutes ...after installing Guix System in an x86_64 VM using... https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz ...I was unable to build gnutls 3.6.12. This prevented me from running "guix pul

bug#45574: Guile 3 fails to build non-deterministically

Hi, If you try to build Guile 3 without substitutes using any recent version of Guix, it can frequently fail. I had to try about 12 times in a row before it succeeded. The failure simply said "FAIL: check-guile" - I didn't save the build logs, which were lost once the build succeeded. If anyone

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Leo Le Bouter writes: > I want to have one last attempt at making the binaries reproducible. > > Could anyone help adjusting this patch so the package definition's hash > does not change on other architectures? So it can be proposed for merge > in master.. > > Thank you > > From e6931a7ebb9cc0681

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Hi all, It's great to see forward motion again! Efraim Flashner writes: > As far as powerpc64 vs powerpc64le, I'll let those with the hardware > have more of a say, they'll be the ones using it. As far as the > bootstrap binaries go, I don't remember having this much pushback with > my binaries

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

binaries is important, but simply having any bootstrap binaries at all is also important. I think I have done my due diligence to try making them reproducible. Most of them are, but I just can't figure out why GCC isn't. I think it would be best to proceed with the binaries we have.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

s, since it takes hours/days. If you have any creative ideas for how to speed up the investigation, I'm all ears. -- Chris From e3d1778a86dfd171d59d91eb01417faaf63dfa17 Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Sat, 19 Sep 2020 14:25:43 -0700 Subject: [PATCH] gnu: Disable libstdc+

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Hi everyone, Chris Marusich writes: > If you examine the derivations and their inputs, you'll find that they > depend upon each other in the following order: > > guix build --target=powerpc64-linux-gnu -d -e '(@ (gnu packages > make-bootstrap) %gcc-bootstr

bug#41498: sed fails to build on kernels with selinux

Hi, With the attached patch, sed builds on my Fedora machine. Yay! There was a small mistake in my prior email to this bug report, so you can ignore that patch. Chris Marusich writes: > diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm > index 279fe9e3d8..f075ee8f74 100644 &

bug#41498: sed fails to build on kernels with selinux

Chris Marusich writes: > There is actually a bug report for this here: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36150 > > I have submitted a patch upstream to fix the issue. Upstream hasn't replied yet, but it's only been a week and a few days. In the meantime,

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Hi Vincent and everyone, Vincent Legoll writes: > Is that showing the same (or a similar) problem : > > https://data.guix-patches.cbaines.net/gnu/store/0lcbxpw1vrca02dzpzw2rxhad7pn4zw7-gcc-objc-5.5.0 > > ? Can you clarify what you mean? I'm not sure what you're refe

bug#41607: Deleted store items are not actually deleted

Hi zimoun, zimoun writes: > On Sun, 7 Jun 2020 at 03:31, Chris Marusich wrote: > >> I have committed the fix in d445c30ea6 and updated the guix package >> definition in ecbde6505c to ensure that the next time "guix pull" is >> run, the new guix-daemon version

bug#41607: Deleted store items are not actually deleted

Hi everyone, I have committed the fix in d445c30ea6 and updated the guix package definition in ecbde6505c to ensure that the next time "guix pull" is run, the new guix-daemon version will be used. Ludovic Courtès writes: > For consistency with (most) of the code, I’d suggest a /* */ comment. O

bug#41607: Deleted store items are not actually deleted

Ludovic Courtès writes: >> Should Guix do anything about this? We could change guix-daemon to take >> correct action in the face of an XDEV error. We could also improve the >> logging, since currently it silently swallows the XDEV error. > > I guess we could delete recursively right away upon E

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Hi all, Chris Marusich writes: > The derivation that produced the differing output was: > > /gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv > > On my x86_64-linux system, twice I tried running "guix build --check" on > this derivation, b

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

Hi, As demonstrated in the following email thread, the powerpc64-linux bootstrap-tarballs are not reproducible when cross-compiled from an x86_64-linux system: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg3.html Four people attempted to invoke the following command using Guix com

bug#41499: /proc/filesystems impurity in build environment

Hi Ludo, Ludovic Courtès writes: > There’s /proc, but there are also syscalls that leak info, such as > uname(2). > > Fortunately these issues are quite rare in practice (it’s mentioned in > , > which references an earlier Ni

bug#41607: Deleted store items are not actually deleted

Hi Leo, Stephen, and others, I originally wrote a very detailed email describing my investigation of this issue and the results. However, I accidentally deleted it, so please bear with me as I write a rough summary instead. Leo Famulari writes: >>From the discussion "Guix Docker image inflatio

bug#41499: /proc/filesystems impurity in build environment

Hi Ludo, Ludovic Courtès writes: > The daemon mounts /proc in the build environment (see > libstore/build.cc): > > /* Bind a new instance of procfs on /proc to reflect our >private PID namespace. */ > createDirs(chrootRootDir + "/proc"); > if (mount("none", (chrootRootDir + "

bug#41498: sed fails to build on kernels with selinux

Chris Marusich writes: > It appears related to this issue: > > https://lists.gnu.org/archive/html/bug-sed/2019-06/msg00022.html There is actually a bug report for this here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36150 I have submitted a patch upstream to fix the issue.

bug#41499: /proc/filesystems impurity in build environment

Hi, The Linux kernel's /proc/filesystems is an impurity in the Guix build environment. Its contents can cause the same derivation to behave differently on different systems. For example, the default kernel on Fedora systems uses SELinux, so /proc/filesystems contains "selinuxfs". However, the d

bug#41498: sed fails to build on kernels with selinux

Hi, I noticed that sed fails to build on my Fedora machine, but it builds successfully on Guix System. The error is: --8<---cut here---start->8--- ERROR: testsuite/inplace-selinux inplace-selinux.sh: set-up failure: CONFIG_HEA

bug#36684: "View build log" - but it's empty (at first)!

Ludovic Courtès writes: > I’ve never experienced it. Is there a scenario that allows you to > reproduce it? I have not been able to reproduce this issue; maybe I was simply confused when I opened the bug report. Let's close this for now. -- Chris signature.asc Description: PGP signature

bug#36687: guix gc: error: executing SQLite statement: database disk image is malformed

Chris Marusich writes: > I wonder what has brought my installation into this state. I can't > think of a way to fix it since I don't even know what caused it, so I > will probably re-install Guix to work around the issue I re-installed Guix to work around the issue. -- Ch

bug#38175: configure: error: Guix requires zlib.

Efraim Flashner writes: > I'm pretty sure this parses (guix environment guix -- ad-hoc zlib -- > ./bootstrap) && ./configure --localstatedir=/var && make You're absolutely right. I can't believe I made such a silly mistake! Thank you for lending me a second pair of eyes. :-) I'm closing this

bug#38175: configure: error: Guix requires zlib.

Hi, I keep getting this error when trying to build Guix. I got it just today when invoking the following command from a clean checkout: guix environment --pure guix -- ./bootstrap && ./configure --localstatedir=/var && make My current guix version is 18a69803e2eea4f7555d6eafb6497a645c2d094f:

bug#36519: System frequently suspending after logout

Hi Josh, Josh Wheeler writes: > Problem: GuixSD frequently suspends on user logout or after selecting > "Log in as another user" from the lock screen. > > Occurs when returning to GDM from GNOME and i3 sessions on a fresh > GuixSD install. > > Expected: System should allow user logout / switchin

bug#36634: Virtual Machine Manager (virt-manager)

Hi Miguel, Miguel Arruga Vivas writes: > Hello again, > > The two patches attached create the cgroup directory needed and remove > the warning for the ip binary missing. Still the following errors > are emitted to the log. > > 8<--- > error : virConnectGetCP

bug#38045: Video Rendering Issues on IceCat

Hi Raghav, Are you actively working on this bug? If you are not, then as a matter of etiquette, I think it would be best not to change its severity. Raghav Gururajan writes: > Hello Guix and GNUzilla! > > I am currently using IceCat (68.2.0-guix0-preview3) on Guix System. > > Starting from ver

bug#36634: Virtual Machine Manager (virt-manager)

Chris Marusich writes: > I've updated the upstream bug report with information that hopefully > will be useful to them. We'll see how it goes. The original upstream bug report has been closed, but it seems likely it was for a different issue, since it didn't fix t

bug#36634: Virtual Machine Manager (virt-manager)

Chris Marusich writes: > This bug is consistently reproducible. I've found an upstream bug > report that is very similar to what we're seeing here, so I've left a > comment telling the libvirt maintainers that Guix is also seeing a > similar issue: > > https:/

bug#36634: Virtual Machine Manager (virt-manager)

Christopher Baines writes: > Raghav Gururajan writes: > >> libvirt.libvirtError: Unable to read from >> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or >> directory > > So, I've experienced this too. Even though this is a cgroup thing, I'm > pretty sure this isn't an issue w

bug#36855: guix system switch-generation doesn't

Hi Robert, Robert Vollmert writes: > On 8. Aug 2019, at 18:40, Chris Marusich wrote: >> zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes: >> >>> 'switch-to-system-generation' doesn't call out to >>> 'upgrade-shepherd-services'

bug#36855: guix system switch-generation doesn't

Hi Jakob, zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes: > 'switch-to-system-generation' doesn't call out to > 'upgrade-shepherd-services'. I'm not sure if this was an intentional > decision or not It is intentional, but only because there is currently no way to call upgrade-shepherd

bug#36687: guix gc: error: executing SQLite statement: database disk image is malformed

Ricardo Wurmus writes: > Chris Marusich writes: > >> is there anything we can check to understand why the database >> corruption has occurred? > […] >> For the record, I do sometimes abruptly power off my machine, and it >> does rarely abruptly crash (I think I

bug#36728: LibreOffice fails to open hyperlinks

Chris Marusich writes: > Chris Marusich writes: > >> I have a fix and will post it in a moment. > > I've verified that the attached patch fixes the issue. It took over 4 > hours to build libreoffice on 1 core on my x200 laptop (not including > the time it took to

bug#36706: "guix gc --verify" fails with "FOREIGN KEY constraint failed"

Ingo Ruhnke writes: > On Wed, Jul 17, 2019 at 10:02 PM Ricardo Wurmus wrote: > >> This is bad and you cannot recover from it. The store should *never* be >> edited manually as it will become inconsistent with the database (which >> I assume you have not edited). >> > > I recovered it just fine

bug#36667: crates-io.scm packages should build on master

Hi Giacomo, Thank you for taking the time to submit a patch! goodoldp...@autistici.org writes: > Rust libraries contained in gnu/packages/crates-io.scm are not > building anymore because cargo wants to download crate dependencies > inside the store. Curious! I wonder when this changed. > The

bug#36363: let's encrypt hash mismatch

Ludovic Courtès writes: > Julien Lepiller skribis: > >> expected hash: 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y >> actual hash: 0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac >> hash mismatch for store item >> '/gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem' b

bug#36687: guix gc: error: executing SQLite statement: database disk image is malformed

Ricardo Wurmus writes: > Chris Marusich writes: > >> My disk was filling up, so I tried to run "guix gc", but I got an error >> instead: >> >> --8<---cut here---start->8--- >> $ guix gc -C 25GiB >> ..

bug#36728: LibreOffice fails to open hyperlinks

Chris Marusich writes: > I have a fix and will post it in a moment. I've verified that the attached patch fixes the issue. It took over 4 hours to build libreoffice on 1 core on my x200 laptop (not including the time it took to build dependencies). I would normally push this dir

bug#36728: LibreOffice fails to open hyperlinks

Hi, LibreOffice cannot open hyperlinks on Guix System. This is because it attempts to invoke /usr/bin/xdg-open, which does not exist. For example, if you launch "libreoffice" on the command line and then attempt to open a hyperlink via Control + Left Click in Calc, you'll get the following messa

bug#36687: guix gc: error: executing SQLite statement: database disk image is malformed

Hi, My disk was filling up, so I tried to run "guix gc", but I got an error instead: --8<---cut here---start->8--- $ guix gc -C 25GiB ... deleting `/gnu/store/n0gyzfw77ik35ld9d0d4737w88f11m4b-profile.drv' deleting `/gnu/store/fl7w0dlki7c906isiiflf9ka4c49zcmi-ca

  1   2   3   >