bug#50883: Suckless packages marked as 'x11' instead of 'expat'

Hello Guix, It seems like some packages in suckless.scm are listed as having an 'x11' license when they are in fact 'expat' (as listed on directory.fsf.org and confirmed by visual inspection). I only checked three: dwm, dmenu, and st; but I suspect there are many more. (Perhaps at some point w

bug#50871: Stackage importer change breaks tests/lint, build

Xinglu, Xinglu Chen 写道： On Tue, Sep 28 2021, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote: Guix, Oops, sorry for forgetting to address you… Guix doesn't currently build because of a ‘lint’ test failure (log attached). Reverting commit 9c5e5ca1c0de56a0d5b2b924de10548172095b5

bug#50871: Stackage importer change breaks tests/lint, build

On Tue, Sep 28 2021, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote: > Guix, > > Guix doesn't currently build because of a ‘lint’ test failure (log > attached). Reverting commit > 9c5e5ca1c0de56a0d5b2b924de10548172095b58 makes it pass. Thanks for catching this! The attached patch sh

bug#50872: Prosody service + letsencrypt certs improvements

I finally got prosody working on my server using Guix. However, the manual says: Prosodyctl will also help you to import certificates from the ‘letsencrypt’ directory so that the ‘prosody’ user can access them. See . prosodyctl --root cert impor

bug#46242: Guix System is not listed in GNOME Boxes

Hello, > However, we only propose an xzipped iso (and not a raw iso file), so > the data does not provide information on downloading. Either we have > an outdated osinfo-db, or the lack of download option prevents boxes > from showing it as a choice. The reason for GNU Guix not showing up in GN

bug#50871: Stackage importer change breaks tests/lint, build

Guix, Guix doesn't currently build because of a ‘lint’ test failure (log attached). Reverting commit 9c5e5ca1c0de56a0d5b2b924de10548172095b58 makes it pass. Kind regards, T G-R test-suite.log Description: Binary data signature.asc Description: PGP signature

bug#50856: Unbound variables in Guix Home

Andrew Tropin writes: […] > From 634e6cbb7153ea02fb2ace6d39dae4055ed0c73c Mon Sep 17 00:00:00 2001 > From: Andrew Tropin > Date: Tue, 28 Sep 2021 12:30:55 +0300 > Subject: [PATCH] home-services: Add missing imports and function definition. > > * gnu/home-services/configuration.scm: Add missing

bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

Ludovic Courtès skribis: > Conversely, IIUC what the “normative parts of the output contents” (info > "(ld) Options") really are, build IDs are computed on the code, not on > debug info. > > But the problems remains the same I think: if you have > /gnu/store/abc…/libfoo.so and /gnu/store/xyz…/lib

bug#50771: guix system search doesn't show system services from channels

On 2021-09-27 15:27, zimoun wrote: > Hi, > > On Fri, 24 Sept 2021 at 08:59, Andrew Tropin wrote: >> >> Declared system service in (gnu services tmp) in my channel, did guix >> pull with the apropriate channels configuration. >> >> System service from (gnu services tmp) can be used in my >> operat

bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

Hi, Maxim Cournoyer skribis: > Ludovic Courtès writes: > > [...] > >>> Yikes! This means that debugging with grafts (with the aid of debugging >>> symbols) is no longer possible, right? >> >> It depends on whether the separate “debug” output gets grafted or not, >> but yeah, if a dependency tr

bug#50856: Unbound variables in Guix Home

On 2021-09-28 00:15, Oleg Pykhalov wrote: > Hi Guix, > > We have unbound variables in some Guix Home files: > --8<---cut here---start->8--- > gnu/home-services/configuration.scm:56:6: warning: possibly unbound variable > `formatted-message' > gnu/home-services/

bug#50830: [core-updates-frozen] glibc looks for $sysconfdir/etc/localtime rather than /etc/localtime

Leo Famulari skribis: > On Mon, Sep 27, 2021 at 11:08:58PM +0200, Ludovic Courtès wrote: >> So here’s a patch to fix it, and another one to do a minor cleanup >> operation. > > I created a "tracking bug" to coordinate rebuilding the world: > > There was already

bug#50672: python-pytorch is not reproducible

Hi, zimoun skribis: > On Fri, 24 Sept 2021 at 16:11, Ludovic Courtès > wrote: > >> Having unbundled NNPACK in d326dec8115cf5e2cac9497633dc11ecc970361b, I >> can confirm that PyTorch itself is now reproducible, but NNPACK isn’t. > > I reproduce: "guix build nnpack --no-grafts --check" differs.