bug#68415: User's shepherd services defined in guix home config can not start after guix pull.
After I guix pull, services defined in guix home config can no start:
-
服务 root 已启动。
WARNING: Use of `load' in declarative module (#{ g117}#). Add #:declarative?
#f to your define-module invocation.
unbound-variable(#f "Unbound variable: ~S" (service) #f)
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
Creating XDG user directories... done
Comparing /gnu/store/bfkgfz1sm9q75jyn56pav2kmwl48i7w8-home/profile/share/fonts
and
/gnu/store/bfkgfz1sm9q75jyn56pav2kmwl48i7w8-home/profile/share/fonts... done
(same)
Evaluating on-change gexps.
---
When I run command: herd status, show error:
feng@Guix ~$ herd status
error: connect: /run/user/1000/shepherd/socket: No such file or directory
--
bug#68413: Ungexp doesn't work on deep lists
Hi, I've been using G-expressions for some time and have always been hindered by `ungexp` not working on deeper lists. For instance, when I want to embed in a G-expression a list of packages, it works >(define packages (list coreutils gnu-make ...)) > > #~(for-each >(lambda (f) > ... do-something) >'#$packages) But as soon as I use an object in which the file-like objects are deeper, it fails > (define packages > (list > (cons "coreutils" coreutils) > (cons "make" gnu-make) > ...)) > > #~(for-each >(lambda (f) > ... do-something) >'#$packages) If I send a patch to "fix" this, will it be usefull or is there a reason for this behavior? Thanks.
bug#68411: Timezone not detected from /etc/localtime
Apps such as Icecat or ungoogled-chromium are not able to get the correct timezone from /etc/localtime when `/etc/localtime` is a realpath maybe because it expect /etc/share/zoneinfo, with readlink partially works fine some apps, maybe related with an icu bug.[1] I just removed manually `/etc/localtime` and crate an symlink `sudo ln -s $TZDIR/$(cat /etc/timezone) /etc/localtime` and ungoogled-chromium works fine. Icecat in other hand has an additional bug related with icu[2][3] and folder policy where `/gnu` is not allowed so in order to make it work is necessary disable sandbox `MOZ_DISABLE_CONTENT_SANDBOX=1 icecat` or set manually TZ env `TZ=$(cat /etc/timezone) icecat`, btw I have `privacy.resistFingerprinting` false. The weird thing is that in almost all of those reported the error is the opposite where having a realpath solves it but in guix it is the problem, perhaps it could be because these apps have updated their code to make it work with `icu` v72 and guix has v71. Steps to reproduce it: - guix pull && guix package -u - Install last icecat or ungoogled-chromium version - Verify that you don't have $TZ set, unset it. - If it's Icecat open `about:config` and set `privacy.resistFingerprinting` to false - Open https://webbrowsertools.com/timezone/ in the browser - Check the timezone - sudo rm -r /etc/localtime && sudo ln -s $TZDIR/$(cat /etc/timezone) /etc/localtime - Open chromium or `MOZ_DISABLE_CONTENT_SANDBOX=1 icecat` - Visit https://webbrowsertools.com/timezone/ again, check the timezone. See also: - https://github.com/NixOS/nixpkgs/issues/238025 - https://github.com/NixOS/nixpkgs/pull/238700 Footnotes: [1] https://github.com/unicode-org/icu/pull/2323 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1848615 [3] https://hg.mozilla.org/releases/mozilla-esr115/rev/d7948b142f43
bug#47919: Sourcing environment-variables may send to wrong directory
Ni! I see. Thanks for the explanation. .~´
bug#62890: StumpWM with --no-grafts and System/Home mismatches
I've noticed the same behavior and was able to resolve it by adding --no-grafts whenever I reconfigure my system and home profiles. Likely just the former is necessary, but I haven't tested it. I've also noticed this behavior (SBCL trying to place .fasl in /gnu/store) once when I pulled, reconfigured system, and didn't reconfigure home. I have my setup configured such that StumpWM is installed at the system level, while contrib packages are installed via guix home. I ran a git bisect and continually reconfigured my system to try and narrow down what commit it was, and was able to isolate it to either an xorgproto or Mesa update. Home was built before (49a7a95ba4) the commit, System after (d55a4431f3). The offending commit in this particular case lies somewhere between d55a4431f3 and 17c3a3bfff. (This probably isn't actually a bug, but I'm posting it in case anyone else runs into a similar issue in the future.) If anyone else has a similar setup, encounters this issue, and already uses --no-grafts, be sure both the system and home profiles are built with the same version of Guix. Richard Sent
bug#67796: Automake is not compatible with older Autoconfs we provide
Hi, On 2024-01-12 19:38, Giovanni Biscuolo wrote: It's not a big deal if we just remove the older versions. but if they are needed for bootstrapping they should be kept around, no? No, because they are not needed for the bootstrapping itself. We build stuff from scratch for it, I needed them to rebuild the configure scripts on GCC, which I don't need to rebuild anymore (GCC's codebase includes the configure scripts prebuilt). That's where I realized. The problem I wanted to make us notice is we were keeping the 2.64 version and we didn't really provide any compatible automake, so the autoconf@2.64 was almost useless. I'm not very familiar with Autoconf and Automake (nor with bootstrapping): is there a "compatibility table" around? I quickly had a look to the respective manuals but I was not able to find one. I don't know either. I tried to use the 2.64 one and that told me the Automake wasn't compatible. If no package uses those, it's ok to remove. I can always time-machine around the problem. OK old packages can always (almost) be time-machined back but if they are needed for bootstrapping (for sexample if your work on GCC bootstrapping is succesful) they should be in Guix proper, no? is this a bug? :-) The problem in my opinion is including a 2.64 autoconf that we can't run actually use for the lack of a compatible automake. Not providing it is a better option. I don't need it for bootstrapping recipes, and if I need it in the future I'll remake the package. If Autoconf 2.64 is not needed by any package my proposal is to remove it from Guix and let the people interested on it to `time-machine`, as that's going to probably have the correct automake with it. Thanks for your work! Gio' Thank you!
bug#67546: You found a bug: the program failed to compute the derivation for Guix
Hi,
On Thu, 30 Nov 2023 at 14:09, Tomas Volf <~@wolfsden.cz> wrote:
> $ guix time-machine --no-offload -q
> --commit=97a5819643a045b7cc68e80fd2fc05ed4eabf0d0 -- describe
[...]
> ./guix/store.scm:1421:15: In procedure loop:
> ERROR:
> 1. :
> message: "build of
> `/gnu/store/rprhfhdq4wqhq30wqzkps481s7v516ci-git-minimal-2.34.1.drv' failed"
> status: 100
> guix time-machine: error: You found a bug: the program
> '/gnu/store/pgknv6235znk5d08lyifx3xvxl5fxszi-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "97a5819643a045b7cc68e80fd2fc05ed4eabf0d0"; system: "x86_64-linux";
> host version: "1237c9dda87f8d8259b43b5ee4510ecd01d0b71b"; pull-version: 1).
> Please report the COMPLETE output above by email to .
First, please note that 97a5819643a045b7cc68e80fd2fc05ed4eabf0d0 is from:
CommitDate: Sat Mar 19 13:33:06 2022 -0600
Second, the failure leads to:
--8<---cut here---start->8---
$ guix build /gnu/store/rprhfhdq4wqhq30wqzkps481s7v516ci-git-minimal-2.34.1.drv
[...]
Test Summary Report
---
../test/recipes/80-test_cms.t(Wstat: 1280 Tests: 6 Failed:
5)
Failed tests: 1-5
Non-zero exit status: 5
../test/recipes/80-test_ssl_new.t(Wstat: 256 Tests: 29 Failed:
1)
Failed test: 12
Non-zero exit status: 1
Files=158, Tests=2636, 84 wallclock secs ( 1.39 usr 0.12 sys + 78.30 cusr
15.69 csys = 95.50 CPU)
Result: FAIL
make[1]: *** [Makefile:208: _tests] Error 1
make[1]: Leaving directory '/tmp/guix-build-openssl-1.1.1l.drv-0/openssl-1.1.1l'
make: *** [Makefile:205: tests] Error 2
Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("test") exit-status: 2
term-signal: #f stop-signal: #f>
phase `check' failed after 84.5 seconds
command "make" "test" failed with status 2
builder for `/gnu/store/vhp1m48jlgqq2dg8pjnv1krj9f608f94-openssl-1.1.1l.drv'
failed with exit code 1
build of /gnu/store/vhp1m48jlgqq2dg8pjnv1krj9f608f94-openssl-1.1.1l.drv failed
View build log at
'/var/log/guix/drvs/vh/p1m48jlgqq2dg8pjnv1krj9f608f94-openssl-1.1.1l.drv.gz'.
cannot build derivation
`/gnu/store/rprhfhdq4wqhq30wqzkps481s7v516ci-git-minimal-2.34.1.drv': 1
dependencies couldn't be built
guix build: error: build of
`/gnu/store/rprhfhdq4wqhq30wqzkps481s7v516ci-git-minimal-2.34.1.drv' failed
--8<---cut here---end--->8---
It is a known time-bomb. For now we do not have better other than
hard-code the time. On my machine, I do:
--8<---cut here---start->8---
$ sudo timedatectl set-ntp false
$ sudo timedatectl set-time '2022-03-18 00:00:00'
$ guix build /gnu/store/rprhfhdq4wqhq30wqzkps481s7v516ci-git-minimal-2.34.1.drv
[...]
successfully built
/gnu/store/rprhfhdq4wqhq30wqzkps481s7v516ci-git-minimal-2.34.1.drv
/gnu/store/jdn2j1v9n16kzzhcvkpb7cm3n8i8j8rz-git-minimal-2.34.1
--8<---cut here---end--->8---
Although not fully visible, this time-bomb is already documented in the
manual:
Note: Although it should technically be possible to travel to such
an old commit, the ease to do so will largely depend on the
availability of binary substitutes. When traveling to a distant
past, some packages may not easily build from source anymore. One
such example are old versions of Python 2 which had time bombs in
its test suite, in the form of expiring SSL certificates. This
particular problem can be worked around by setting the hardware
clock to a value in the past before attempting the build.
https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-time_002dmachine
Well, I agree that the situation is currently poor. For now, it means
some tricks.
Cheers,
simon
bug#67461: build of /gnu/store/xnwy976yzkvxh2virzf2yrhr28c04075-python-matplotlib-3.5.2.drv failed
Hi, On Mon, 04 Dec 2023 at 18:19, francismb via Bug reports for GNU Guix wrote: > Here problem seems to have disappeared. You may want to close the issue. > (on my side I neither have time trying to trace down the cause nor where > to start to search, ... may be something to do with the > non-deterministic message below ? ) Thanks. So I am closing. Feel free to reopen if you have more details about the failure. Cheers, simon
bug#67796: Automake is not compatible with older Autoconfs we provide
Hi, Ekaitz Zarraga writes: [...] >>> We have automake packaged, but it's not compatible with older autoconf >>> versions so autoconf is not very usable at this point. >>> >>> ``` >>> Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv)$ guix shell >>> automake autoconf@2.64 >> >> is there a reason you need to "pin" to the 2.64 version? > > I had one, I was working on GCC bootstrapping... oh OK :-) > It's not a big deal if we just remove the older versions. but if they are needed for bootstrapping they should be kept around, no? > The problem I wanted to make us notice is we were keeping the 2.64 > version and we didn't really provide any compatible automake, so the > autoconf@2.64 was almost useless. I'm not very familiar with Autoconf and Automake (nor with bootstrapping): is there a "compatibility table" around? I quickly had a look to the respective manuals but I was not able to find one. > If no package uses those, it's ok to remove. I can always time-machine > around the problem. OK old packages can always (almost) be time-machined back but if they are needed for bootstrapping (for sexample if your work on GCC bootstrapping is succesful) they should be in Guix proper, no? is this a bug? :-) Thanks for your work! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#67290: (current-profile) only works when invoked as a process named "guix"
Hi, On Sun, 19 Nov 2023 at 13:24, Ian Eure wrote: > The issue seems to be that current-profile checks the name of the > program which was invoked, and always returns #f unless the name ends > with "bin/guix". Since "guile" doesn’t, they don’t work as expected. > See: > https://git.savannah.gnu.org/cgit/guix.git/tree/guix/describe.scm#n64 About current-profile, maybe this patch: diff --git a/guix/describe.scm b/guix/describe.scm index 65cd79094b..4147d5db1f 100644 --- a/guix/describe.scm +++ b/guix/describe.scm @@ -61,14 +61,18 @@ (define current-profile or #f if this is not applicable." (match initial-program-arguments ((program . _) - (and (string-suffix? "/bin/guix" program) -;; Note: We want to do _lexical dot-dot resolution_. Using ".." -;; for real would instead take us into the /gnu/store directory -;; that ~/.config/guix/current/bin points to, whereas we want to -;; obtain ~/.config/guix/current. -(let ((candidate (dirname (dirname program - (and (file-exists? (string-append candidate "/manifest")) - candidate))) + (or (and (string-suffix? "/bin/guix" program) +;; Note: We want to do _lexical dot-dot resolution_. Using ".." +;; for real would instead take us into the /gnu/store directory +;; that ~/.config/guix/current/bin points to, whereas we want to +;; obtain ~/.config/guix/current. +(let ((candidate (dirname (dirname program + (and (file-exists? (string-append candidate "/manifest")) + candidate))) + (let ((current (string-append + (config-directory #:ensure? #f) "/current/manifest"))) + (and (file-exists? current) + current))) (define (current-profile-date) "Return the creation date of the current profile (produced by 'guix pull'), ? Well, I do not know exactly if fixing your issue does not introduce regression. About emacs-guix, instead of launching Guile, why not start “guix repl” instead? The command “guix repl” had been improved – and maybe even introduced after the release of emacs-guix. Somehow, I am not very happy with the current integration between Geiser and Guix. :-) Cheers, simon
bug#67221: Package identity transformation produces different derivation
Hi,
On Wed, 15 Nov 2023 at 21:56, Ulf Herrman wrote:
> $ guix build --no-grafts --derivations -e \
> '(begin
>(use-modules (guix packages) (gnu packages gtk))
>((package-mapping identity) cairo-sans-poppler))' \
>-e '(@ (gnu packages gtk) cairo-sans-poppler)'
> =>
> /gnu/store/51hwf2mc2ig76a3nm86msv4z9az3s0j3-cairo-1.16.0.drv
> /gnu/store/q78ziqcg2dvi2lzj18hzdld85bcydzwk-cairo-1.16.0.drv
The only difference is from the builder: %build-inputs contains
("util-linux" .
"/gnu/store/gwx2sf5wl9bsl21lwv35g5la63bwyy95-util-linux-2.37.4-lib")
for the non-transformed ’(@ (gnu packages gtk) cairo-sans-poppler)’
package, only.
Hum, is ’package-mapping’ removing it?
> 1. (package-mapping identity #:deep? #t) *does* produce the same
>derivation.
Well, it means that #:deep? #t adds “util-linux” in the builder.
Cheers,
simon
bug#63068: Apache mirrors are not available anymore
Hi, On Sun, 10 Dec 2023 at 10:52, glaz--- via Bug reports for GNU Guix wrote: > I did some minor research on my patch. Looks like I was wrong. There are > more than one package, that is not available via DLCDN, but only on > archive.apache.org. So the best solutions seems to be to change the list > of mirrors in download.scm as described earlier. > > - (apache ; from > http://www.apache.org/mirrors/dist.html > - "http://www.eu.apache.org/dist/; > - "http://www.us.apache.org/dist/; > - "https://ftp.nluug.nl/internet/apache/; > - "http://apache.mirror.iweb.ca/; > - "http://mirrors.ircam.fr/pub/apache/; > - "http://apache.mirrors.ovh.net/ftp.apache.org/dist/; > - "http://apache-mirror.rbc.ru/pub/apache/; > - "ftp://ftp.osuosl.org/pub/apache/; > - "http://mirrors.ibiblio.org/apache/; > - > + (apache ; see https://apache.org/history/mirror-history.html > + "https://dlcdn.apache.org/; I think it is best to tweak the list of mirrors as you suggest here. However, why remove all the others? Are they officially down? What I would suggest is the list: (apache ; see https://apache.org/history/mirror-history.html "https://dlcdn.apache.org/; "http://www.eu.apache.org/dist/; "http://www.us.apache.org/dist/; "https://ftp.nluug.nl/internet/apache/; "http://apache.mirror.iweb.ca/; "http://mirrors.ircam.fr/pub/apache/; "http://apache.mirrors.ovh.net/ftp.apache.org/dist/; "http://apache-mirror.rbc.ru/pub/apache/; "ftp://ftp.osuosl.org/pub/apache/; "http://mirrors.ibiblio.org/apache/; Hence the first item will be tried first. And if it fails, the other will be checked. Then if it still fails, Guix will try other sources as Webarchive, Software Heritage, etc. Cheers, simon
bug#66647: Installation of RPMs produced by ‘guix pack’ is super slow
Hi Inria’s folks, :-) On Sat, 02 Dec 2023 at 18:13, Maxim Cournoyer wrote: > I'd rather we try it with a few more software such as 'dnf' to narrow it > down to just 'yum', or some other issues in our Guix-generated RPM. have you tried with ’dnf’? Is it similarly slow as ’yum’? Cheers, simon
bug#39885: Bioconductor URI, fallback and time-machine
Hi, On Mon, 08 Jan 2024 at 16:34, Ricardo Wurmus wrote: > The WIP commit is here: > > https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-r=e81a75a7b28c633a658ceeb0a728255674f56c58 IIRC, the main feedback [1] of this approach is: - the repositories at https://git.bioconductor.org/package/NAME do not tag package versions. The only method of organization is branches that are named after *Bioconductor releases* (not package releases), e.g. RELEASE_3_15. We can only determine the package version by reading its DESCRIPTION file or by looking up the version index for all Bioconductor packages (we do that already). This means that there could be different commits for the same package version in the same release branch — so we have to include the commit hash and a revision counter in the version string. Have you tried the wip commit at scale? Cheers, simon 1:bug#39885: Bioconductor URI, fallback and time-machine Ricardo Wurmus Wed, 10 Aug 2022 20:25:00 +0200 id:878rnwuemq@elephly.net https://issues.guix.gnu.org/39885 https://issues.guix.gnu.org/msgid/878rnwuemq@elephly.net https://yhetil.org/guix/878rnwuemq@elephly.net
bug#68059: Mismatching defconfig options
Hi Lars, Lars Rustand writes: > This issue can be closed. You can close issues by replying to -d...@debbugs.gnu.org instead of @, as I'm doing here. Best, -- Josselin Poiret signature.asc Description: PGP signature
