bug#57005: Suggestion
Hello Lars, thanks for the patch! Concerning "Machine characteristics", I see it only in petscmachineinfo.h, so we can probably drop looking for petscconf.h in find-files. There is already the cleaning phase 'clean-install after 'install. So I would either suggest to keep the phase 'clean-local-references where it is, or to merge its content with 'clean-install (I do not see why one should be preferred over the other). Andreas
bug#69466: Wrong colours for QA
Hello, it looks like the dark green colour is wrongly chosen in QA, for instance here: https://qa.guix.gnu.org/issue/69441 The issue has been reviewed, but "Comparison unavailable Yet to process revision". I think dark green should only appear when the package is reviewed AND builds correctly (so would be light green without reviewing). Andreas
bug#69286: guix-build-coordinator-agent-only should not propagate guix
Hello, I installed guix-build-coordinator-agent-only into my user profile to try it out, and wondered today why "guix build" would build the wrong version of a software; then why "guix describe" showed a wrong date; until I realised that the package propagates guix, and that the thus propagated guix takes precedence over the one obtained via "guix pull". This looks like a bug to me, since it pulls the rug under the users' feet by surreptitiously swapping their consciously installed guix by a different one. Andreas
bug#65391: Close
After reading through the first tenth of what seems to be an interesting discussion and skimming through the remainder, I take the liberty to close this bug. Such a discussion had better take place on guix-devel; the report itself does not start with an actionable proposal: "People need to..." looks more like an infinite task to me that cannot be closed as finished if taken literally. I understand that certain concrete proposals coming from the discussion have been filed as separate issues, and would suggest that people interested in the topic continue to do so. Andreas
bug#68920: Issues with issues.guix.gnu.org (502 Bad Gateway)
Am Tue, Feb 06, 2024 at 09:22:43AM -0500 schrieb Maxim Cournoyer: > Thanks for the report. It occurred a few times in the past weeks, where > the 'mumi' service had to be restarted on Berlin. Let's keep this open > to see if it'll occur again. Otherwise I'll close it in a week or two. It has happened for me last evening, so it does not seem to be definitely fixed. Andreas
bug#67048: Acknowledgement (guix refresh -u -L does not work with relative path)
My mail client has secretly updated the file while I was carrying out
the experiment; the attached version should be the one before refreshing.
Andreas
(define-module (example)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix download)
#:use-module (guix packages)
#:use-module (guix build-system pyproject)
#:use-module (guix build-system python)
#:use-module (gnu packages python-xyz))
(define-public python-numpy-illustrated
(package
(name "python-numpy-illustrated")
(version "0.3")
(source
(origin
(method url-fetch)
(uri (pypi-uri "numpy-illustrated" version))
(sha256
(base32 "1x3gd19hhmlg51i5aj070y7w0lk47gx6yx3r3f45396bgdfnsw4i"
(build-system pyproject-build-system)
(propagated-inputs (list python-numpy))
(home-page "https://github.com/axil/numpy-illustrated;)
(synopsis "Helper functions from the NumPy Illustrated guide")
(description "This package provides helper functions for the
@url{https://betterprogramming.pub/numpy-illustrated-the-visual-guide-to-numpy-3b1d4976de1d?sk=57b908a77aa44075a49293fa1631dd9b,
NumPy Illustrated} programming guide.")
(license license:expat)))
bug#67048: guix refresh -u -L does not work with relative path
Hello,
to reproduce this weird (and very specific!) problem, do the following:
cd /tmp
mkdir proj
copy the attached example.scm into /tmp/proj
Now
guix refresh -u -L proj python-numpy-illustrated
yields the error
proj/example.scm:10:2: python-numpy-illustrated: updating from version 0.3 to
version 0.3.1...
proj/example.scm:10:2: warning: python-numpy-illustrated: no `version' field in
source; skipping
and does not update the package; whereas
guix refresh -u -L /tmp/proj python-numpy-illustrated
works as expected.
Without the "-u" things work with a relative path (as indicated by the
first line before the error message above), and I have not found other
guix commands that pose problems with relative paths.
Andreas
(define-module (example)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix download)
#:use-module (guix packages)
#:use-module (guix build-system pyproject)
#:use-module (guix build-system python)
#:use-module (gnu packages python-xyz))
(define-public python-numpy-illustrated
(package
(name "python-numpy-illustrated")
(version "0.3.1")
(source
(origin
(method url-fetch)
(uri (pypi-uri "numpy-illustrated" version))
(sha256
(base32 "0s7ki6lm9xwd4pj7rx6al230wbywqk11wjvgdk44lbdq2fz7kfxd"
(build-system pyproject-build-system)
(propagated-inputs (list python-numpy))
(home-page "https://github.com/axil/numpy-illustrated;)
(synopsis "Helper functions from the NumPy Illustrated guide")
(description "This package provides helper functions for the
@url{https://betterprogramming.pub/numpy-illustrated-the-visual-guide-to-numpy-3b1d4976de1d?sk=57b908a77aa44075a49293fa1631dd9b,
NumPy Illustrated} programming guide.")
(license license:expat)))
bug#57402: Reopening
reopen 57402 thanks Sorry, this was a mistake. Andreas
bug#57402: Closing
Hopefully really closing the bug this time. Andreas
bug#53028: Closing
Since we are at nextcloud@3.8.2 right now, the issue should have disappeared; closing it. Thanks for the report and the helpful comments! Andreas
bug#42166: Closing
Hello, this has most likely been solved by either the new monolithic texlive package, or the vastly expanded modular texlive. So I am closing the report, please reopen it if the problem persists. Thanks for the report, Andreas
bug#32691: Progress
Hello, has there been any progress on this? Is there a way forward, or should we close the issue? Andreas
bug#55130: Closing
Closing the bug, as the immediate problem appears to be solved, and handling of transient network failures is discussed in other issues. Thanks for your report, Andreas
bug#60364: Closing
Hello, the monolithic texlive package should not be mixed with additional texlive packages. With the recent remodelling of the texlive packages, it would be better to install something like texlive-scheme-medium instead. Eventually we aim for reaching a metapackage for a full texlive installation this way. So I am closing this bug report now, please reopen it if you still experience problems with the modular texlive system, or if I misunderstood the problem. Thanks for your report, Andreas
bug#37314: Closing
Hello, as far as I can tell, this report is not relevant any more to the current modular texlive build system, so I am closing it. Please reopen it if anything remains to be addressed. Andreas
bug#35358: Closing
This has probably been solved for a while, closing. Thanks for the report! Andreas
bug#55280: Closing
Hello, this bug has probably been addressed by the recent changes to texlive, so I am closing it. If you still experience problems, please come back to us, reopen the report or create a new one. Thanks for your report! Andreas
bug#65474: Reproducing a texlive bug
Hello, I can confirm that the same problem presents itself on guix 9896b37 Repository-URL: https://git.savannah.gnu.org/git/guix.git Branch: master Commit: 9896b37ac53e9b0504de55dd5ba4bfa2c241a7ed of August 17. A likely culprit is commit 3481a5cb37cacbb54f74a2b1fa52ffc5c972b09f Author: Nicolas Goaziou Date: Wed Aug 9 10:45:42 2023 +0200 guix: profiles: Do not raise error on incomplete TeX Live setups. * guix/profiles.scm (texlive-font-maps): Check if TEXLIVE-SCRIPTS is present in the manifest before trying to generate font maps. which was the last time the profile hook for font generation has been touched. Andreas
bug#53543: bug#64798: [PATCH 000/209] update kde package and add plasme desktop
Am Wed, Aug 09, 2023 at 05:54:07PM +0800 schrieb 宋文武: > Yes, kmessagelib build fine now. As this has been merged to master now, I am closing the bug. Thank you! Andreas
bug#64827: texlive is broken
Am Thu, Aug 17, 2023 at 03:17:55PM +0200 schrieb Nicolas Goaziou: > I think it is simpler to to use a new module, as there's currently much > work going on in "tex.scm". As nothing depends on it, I have just pushed the changes to master and deleted the wip branch. Thanks for your comments, Nicolas! As a last change, I have tried to use the current ruby instead of ruby@2.7 for building texlivebin, but it did not work. > Indeed, I'm currently in the process in packaging `texlive-scheme-full' > (and could use some help, as I might lose my sanity along the way). Once > this is done (if it is ever!), we will be able to remove monolithic Tex > Live completely. Something to be discussed in a separate forum; guix-devel? I am closing this bug now. Andreas
bug#64827: texlive is broken
Am Thu, Aug 17, 2023 at 01:54:58PM +0200 schrieb Andreas Enge: > Okay then, fine to remove biber again! Done in wip-texlive-mono. I also dropped disabling tests for mips64, as anyway we have no means of testing the architecture any more, so I see no point in complicating the build recipe. Where shall we go from here? Are you okay with me either pushing the package in its own texlive module where it is now, or moving the definition back into the tex module? In either case it would probably be a good idea to make the texlivebin and texlivetexmf variables private again. Andreas
bug#64827: texlive is broken
Am Sun, Aug 13, 2023 at 10:48:16PM +0200 schrieb Nicolas Goaziou: > I don't know if the monolithic texlive from the wip branch does, but the > current monolithic `texlive' can be installed without fuss alongside > `texlive-biber'. I don't expect additional issues with `texlive' from > the "wip" branch, tho. This was the starting point of the bug report; for instance guix shell texlive texlive-biber does not work, since having a package named "texlive-..." triggers the texlive font map creation profile hook, which does not work with the monolithic texlive. Interestingly, it does seem to work with my new monolithic texlive and texlive-biber. Hm, it also works on the master branch; so this has apparently been solved between commit 56667ee55cd7f3368cbff169352fe440f4f93da5 of ten days ago and now. Okay then, fine to remove biber again! Andreas
bug#64827: texlive is broken
Hello, Am Wed, Aug 09, 2023 at 06:35:22PM +0200 schrieb Nicolas Goaziou: > It would be nice to list what simplifications can be done on > `texlive-bin', so we can apply them on a new "texlive-team" branch. see the last commit on the wip-texlive-mono branch; the commit message and the diff should be quite clear. Concerning the branch itself, it can be directly applied to master once it is in shape, as nothing depends on the monolithic texlive. > On a different topic, it is now possible to install both `texlive' and > `texlive-biber' in a manifest, so re-instating the old `biber' package > may introduce code duplication without much benefit. WDYT? You mean the old/new monolithic texlive from the wip branch and texlive-biber work together? In that case we should indeed drop biber. Andreas
bug#52967: Close
Closing an old bug report, as it is unlikely we will receive more info. Andreas
bug#64827: texlive is broken
Am Mon, Aug 07, 2023 at 06:16:04PM +0200 schrieb Andreas Enge: > Two phases and the --with-system-libgs configure flag can be dropped > (which will also be the case for the modular package). And two more tests can also be dropped; I have compiled the package successfully on i686 and armhf without them. Andreas
bug#64827: texlive is broken
Hello, my suggestion for the monolithic texlive package is in the branch wip-texlive-mono. It is now updated to the latest version from 2023. Two phases and the --with-system-libgs configure flag can be dropped (which will also be the case for the modular package). So far, everything is in a separate module, texlive; I would be fine with leaving it there or moving it to the tex module. Also, it would probably be better to make the texlivebin and texlivetexmf packages non-public again. Apart from that, I think the commits can be applied on top of master. Andreas
bug#64827: texlive is broken
Am Thu, Jul 27, 2023 at 12:59:21PM +0200 schrieb Andreas Enge: > PS: While trying to push I noticed that there is a branch wip-texlive > from January 2022; I suppose this can be deleted now? Done. The branch appears to have been merged around that time. Andreas
bug#64827: texlive is broken
Hello, Am Thu, Jul 27, 2023 at 11:55:01AM +0200 schrieb Nicolas Goaziou: > I'm sorry as I have limited time and bandwidth right now to help you > solve this issue. It doesn't seem too bad, tho. no problem, this is also my last day before vacations. > I think this may be fixed by tweaking `texlive-font-maps' function in > "profiles.scm". This function should only be used for modular TeX Live, > and the criteria used for it is very gross: it checks the presence of > a "texlive-" prefixed package among the entries. > Unfortunately, when using "guix shell -D texlive", `texlive-libkpathsea' > is among the entries, and `texlive-font-maps' is activated. Well, I also just saw this and solved it by calling the packages "texlivebin" and "texlivetexmf" without a dash... Primitive, but working. > I don't think you can do away with the dichotomy between > `texlive-bin-full' (previously texlive-bin) and `texlive-texmf'. The > former is used to build the executables and the latter contains > everything else. I don't think there exists a way to merge these two > steps into one. No, I agree. But I think the current texlive-bin-full inherits lots of things needed only for the modular system. Thus my suggestion to start it from scratch again without inheritance. > Meanwhile, fixing `texlive' should not be too hard, and monolithic and > modular TeX Live are still pretty much independent from each other. > In particular, `texlive-libkpathsea' is not indispensable for > `texlive-bin-full'; it was introduced, along with inheritance from > `texlive-bin', to reduce code duplication. IOW, it should possible to > partly revert 19fd1004138b60c4479d7516aa0cee261c0b6b57 — i.e., make > `texlive-bin-full' a copy of previous `texlive-bin', barring the update, > and some related fixes such as disabling parallel tests — should fix > monolithic's issue. > Would you have some time to try it? Yes, I am on it! The first commit is in the branch wip-texlive-mono It drops everything monolithic from tex.scm, un-deprecates biber there, and essentially reinstates commit ad457d01147b8d6fcb4ee64b2dc2d699caa1d1ee in a new file texlive.scm, including the biber package. In particular, it reverts the monolithic package back to 2021. I have tested it by compiling my current favourite latex file (very fast again) and "guix shell -C --pure -D texlive" (which works due to the dirty trick above). I have not tested biber, which I normally do not need and do not even know how it works (I happened to just have to use it blindly in a project with other people through a Makefile or latexmk or so). The next step I would like to try is to simplify the package by dropping things introduced for the modular system. And eventually update it to 2023. But given that each run easily takes an hour (unfortunately texlivetexmf suffers from a graft, which takes a long time to go through more than 3GB!), this can take a while. Definitely longer than today. But since we seem to be on the same page and your suggestion above corresponds to what I had already started on my side, the work will not be for nothing, and I am motivated to hopefully finish it over the summer. All the best, Andreas PS: While trying to push I noticed that there is a branch wip-texlive from January 2022; I suppose this can be deleted now?
bug#64827: texlive is broken
Hello again, Am Wed, Jul 26, 2023 at 09:51:49PM +0200 schrieb Andreas Enge: > Would it be feasible to revert these commits, or is everything too > mixed now? I confirm that going back to commit 0561616a3208aa17fe5b1f9c425c44fe00218b08 , which is one before 19fd1004138b60c4479d7516aa0cee261c0b6b57 results in a working monolithic texlive, with texmf-dist in the user profile being a symlink to the corresponding directory of texlive, itself a symlink to the corresponding directory of texlive-texmf; and similarly for texmf-var. However, ./pre-inst-env guix shell --container --pure -D texlive still does not work any more. It prints building TeX Live font maps... (which looks like something a monolithic texlive should not do), and it shows conflicts such as between /gnu/store/y72v93b7f12nx8xq0ljwlzj9yn5b07vk-texlive-bin-20230313/share/texmf-dist/scripts/chktex/deweb.pl /gnu/store/l8g23z46mpzzbq7isnjk65vcx47i2cgf-texlive-texmf-20230313/share/texmf-dist/scripts/chktex/deweb.pl I will go back in time (without exactly bisecting, just by gut feeling) to find a commit where this command works. Andreas
bug#64827: texlive is broken
Am Wed, Jul 26, 2023 at 08:17:02PM +0200 schrieb Andreas Enge:
> Oh wait...
> Before:
> $ ll $HOME/.guix-profile/share/texmf-dist/ls-R
> -r--r--r-- 5 root root 4812162 1. Jan 1970
> /home/andreas/.guix-profile/share/texmf-dist/ls-R
> After:
> lrwxrwxrwx 1 root root 82 1. Jan 1970
> /home/andreas/.guix-profile/share/texmf-dist/ls-R ->
> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/ls-R
>
> Notice the difference in size. The latter gives only the names of the
> subdirectories, the former all files.
No, I was wrong here. 82 is the size of the symlink, the file itself does
contain all the file names.
But there is also this now as part of the texlive package:
+(propagated-inputs (list texlive-libkpathsea))
texlive-libkpathsea contains
/gnu/store/h8vmxcbvk8n25y6zjj17qsq0fncansxs-texlive-libkpathsea-20230313/share/texmf-dist/web2c/texmf.cnf
texlive (as a symlink to texlive-texmf) contains
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c/texmf.cnf
They are not the same:
$ diff
/gnu/store/h8vmxcbvk8n25y6zjj17qsq0fncansxs-texlive-libkpathsea-20230313/share/texmf-dist/web2c/texmf.cnf
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c/texmf.cnf
62c62
< TEXMFROOT = {$GUIX_TEXMF}/..
---
> TEXMFROOT = $SELFAUTOPARENT
111c111
< TEXMF = {$GUIX_TEXMF}
---
> TEXMF =
> {$TEXMFAUXTREES$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDIST}
575c575
<
/gnu/store/h8vmxcbvk8n25y6zjj17qsq0fncansxs-texlive-libkpathsea-20230313/share/texmf-dist/web2c,\
---
> $SELFAUTOLOC/share/texmf-dist/web2c,\
872,874c872,874
< error_line = 254
< half_error_line = 238
< max_print_line = 1000
---
> error_line = 79
> half_error_line = 50
> max_print_line = 79
I think with the propagation of texlive-libkpathsea, there is a conflict
in the profile, which appears to be resolved in favour of texlive;
however, this probably explains why texmf-dist in the profile is no more
just a symlink. In principle it could contain files from two distinct
packages, those just happen to be in conflict.
By the way, the following also fails:
$ guix shell --container --pure -D texlive
The following derivation will be built:
/gnu/store/rdrqavbga5rg9l20vpr1ac79psdndj4d-profile.drv
building TeX Live font maps...
/builder for
`/gnu/store/bnyjd9vgyqniarynlvcia5vnm36pik9i-texlive-font-maps.drv' failed with
exit code 1
build of /gnu/store/bnyjd9vgyqniarynlvcia5vnm36pik9i-texlive-font-maps.drv
failed
View build log at
'/var/log/guix/drvs/bn/yjd9vgyqniarynlvcia5vnm36pik9i-texlive-font-maps.drv.gz'.
cannot build derivation
`/gnu/store/rdrqavbga5rg9l20vpr1ac79psdndj4d-profile.drv': 1 dependencies
couldn't be built
guix shell: error: build of
`/gnu/store/rdrqavbga5rg9l20vpr1ac79psdndj4d-profile.drv' failed
The log file contains lots of messages of the form:
warning: collision encountered:
/gnu/store/yzsq1dykjv96h88pcja0hcjbagn2vjxv-texlive-bin-full-20230313/share/texmf-dist/scripts/l3build/l3build.lua
/gnu/store/s6w8r5q3aql1bhasv0nmwr5xgjv6qnhh-texlive-texmf-20230313/share/texmf-dist/scripts/l3build/l3build.lua
warning: choosing
/gnu/store/yzsq1dykjv96h88pcja0hcjbagn2vjxv-texlive-bin-full-20230313/share/texmf-dist/scripts/l3build/l3build.lua
So here the conflicts are made directly visible.
With the propagation of texlive-libkpathsea, texlive is clearly not just
the composition of (the former) texlive-bin and texlive-texmf any more,
where nothing was propagated as far as I can remember. Also, ls-R is now
created as part of texlive instead of texlive-texmf, which may make a
difference. And texmf-var has disappeared, and I have not yet understood
where it has gone. These are a lot of subtle changes, and they do break
the monolithic texlive.
What could be a way forward to restore the texlive package?
Would it be feasible to revert these commits, or is everything too
mixed now?
If the merge cannot be reverted, how about creating the two packages
(texlive-bin and texlive-texmf) required for the monolithic
texlive completely separately as before and reinstating texlive to be
built from scratch without links with the modular texlive?
Andreas
bug#64827: Texlive-biber not installable
Am Wed, Jul 26, 2023 at 06:33:51PM +0200 schrieb Andreas Enge:
> > You seem to have some clues about the slowness; you reported there are
> > too many symlinks in monolithic TeX Live. This is not intended and
> > should be fixed.
> Clues, yes, but not a full understanding yet.
To clear things up, I have removed biber from my profile.
So now there is only texlive@2021, which contains this in
.guix-profile/share/ related to tex:
$ ll .guix-profile/share/ | grep texlive
lrwxrwxrwx 1 root root77 1. Jan 1970 texmf-dist ->
/gnu/store/31rs3m4fzdbal1v81qg1mvl29p39cyrp-texlive-20210325/share/texmf-dist
lrwxrwxrwx 1 root root76 1. Jan 1970 texmf-var ->
/gnu/store/31rs3m4fzdbal1v81qg1mvl29p39cyrp-texlive-20210325/share/texmf-var
lrwxrwxrwx 1 root root72 1. Jan 1970 tlpkg ->
/gnu/store/31rs3m4fzdbal1v81qg1mvl29p39cyrp-texlive-20210325/share/tlpkg
If I update to texlive@2023:
dr-xr-xr-x 3 root root 4096 1. Jan 1970 texmf-dist/
lrwxrwxrwx 1 root root72 1. Jan 1970 tlpkg ->
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/tlpkg
And as mentioned before, texmf-dist contains symlinks of the kind
tex ->
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/tex
as well as a "physical" subdirectory web2c with symlinks such as
xetex ->
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c/xetex
Whereas strangely, the texlive package itself has only this:
texmf-dist ->
/gnu/store/s6w8r5q3aql1bhasv0nmwr5xgjv6qnhh-texlive-texmf-20230313/share/texmf-dist
Weird, where does the split come from?
Note that we also lost texmf-var compared to the previous release.
Actually things that used to be in texmf-var - the format file
texmf-var/web2c/xetex/xetex-fmt, for instance, can now be found in
texmf-dist.
This is another clue, since the split of the links happens along web2c
(but I still do not understand why).
>From https://www.tug.org/texlive/doc/texlive-en/texlive-en.html section 2.3
I surmise that we need the texmf-var directory back; this is where the
formats are supposed to reside.
It probably disappeared in commit 19fd1004138b60c4479d7516aa0cee261c0b6b57:
...
(texlive-texmf)[build-system]: Use COPY-BUILD-SYSTEM.
[arguments]: Set #:INSTALL-PLAN accordingly. Replace TEXLIVE-BIN with
TEXLIVE-BIN-FULL.
...
+ #:install-plan #~'(("texmf-dist/" "share/texmf-dist"))
...
+ (web2c (string-append texmf-dist "/web2c"))
...
-(invoke "fmtutil-sys" "--all")))
+(invoke (string-append texlive-bin "/bin/fmtutil-sys")
+"--cnffile" fmtutil.cnf
+"--all"
+"--fmtdir" web2c)))
I suspect these to be the main difference between the old and the new
texlive-texmf.
There is also a somewhat suspicious
+(setenv "GUIX_TEXMF" texmf-dist)
and
-(setenv "TEXMFCNF" texmfroot)
of which I do not know what the results are.
And a lacking
-(invoke "mktexlsr")
which is probably not very important.
Oh wait...
Before:
$ ll $HOME/.guix-profile/share/texmf-dist/ls-R
-r--r--r-- 5 root root 4812162 1. Jan 1970
/home/andreas/.guix-profile/share/texmf-dist/ls-R
After:
lrwxrwxrwx 1 root root 82 1. Jan 1970
/home/andreas/.guix-profile/share/texmf-dist/ls-R ->
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/ls-R
Notice the difference in size. The latter gives only the names of the
subdirectories, the former all files.
I think the slowness comes from the fact that now with the monolithic
texlive every file needs to be searched for, instead of being just
picked up from the list in ls-R.
So I would suggest to revert dropping texmf-var by adding it to the
#:install-plan and not putting '"--fmtdir" web2c', and to re-add
running mktexlsr.
Now the question is, will this mktexlsr run disturb the modular texlive?
I suppose not.
In the worst case, we would need separate texlive-texmf for the two
texlive versions.
Andreas
bug#64827: Texlive-biber not installable
Hello! Am Wed, Jul 26, 2023 at 05:25:59PM +0200 schrieb Nicolas Goaziou: > This should still be the same. The main difference is that `texlive-bin' > was renamed `texlive-bin-full'. Any other change was probably not intended. Okay, I understand. It looks like there was another change, but I do not see what it was... > I think the issue here may be that you are conflating the two TeX Live > systems currently provided by Guix, i.e., you both install `texlive' and > some "texlive-" package. Okay. In my profile, I only have texlive and biber. Since biber is deprecated by texlive-biber, updating the profile leads to texlive and texlive-biber being there, which causes this conflict. I think the solution will simply be to reinstate the previous biber package to go with the monolithic texlive and keep it next to texlive-biber. > Coming from modular TeX Live, `texlive-biber' is certainly incompatible > with monolithic TeX Live, which, being monolithic, is expected to > include "biber" executable anyway. No, biber was not part of the monolithic texlive. Probably because it is an additional binary which is not part of texlive-bin. Or maybe it was not part of the texlive distribution in the past? We used to download it separately from CPAN. Re-adding the biber package will be an easy fix, I think; indeed maybe it should be added by default to the monolithic texlive, assuming that its source code is part of the texlive distribution. Apart from that, I have no strong opinion either way. > Monolithic TeX Live is (and always was) unrelated to profiles. Well, these symlinks to files or directories in the store are created when the profile is put together. And for efficiency, the links are to the highest level directory that is not merged from two different packages. So what is linked depends on what is in the profile, and for instance splitting a package in two can lead to files being linked rather than directories. But this does not seem to be the case here, I do not quite understand yet what is happening. > You seem to have some clues about the slowness; you reported there are > too many symlinks in monolithic TeX Live. This is not intended and > should be fixed. Clues, yes, but not a full understanding yet. Thanks for the explanations, Andreas
bug#64827: Acknowledgement (Texlive-biber not installable)
Am Wed, Jul 26, 2023 at 04:51:06PM +0200 schrieb Nicolas Goaziou: > Would it be possible to remove the ".texlive2023" directory? Yes. Compilation works now, but I still cannot install texlive and texlive-biber concurrently, and the incredible slowness also remains. Andreas
bug#64827: Texlive has become slow
Hello, Am Tue, Jul 25, 2023 at 12:09:06AM +0200 schrieb Ricardo Wurmus: > > I can't find the format file `pdflatex.fmt'! > This sounds like a sibling of https://issues.guix.gnu.org/64729 it looks similar indeed. But notice that I use the monolithic package "texlive". And I just tried it again and - it just works! In the meantime, I have rebooted. And while I thought I had done it, I must have forgotten to include $GUIX_PROFILE/etc/profile for updating environment variables. However, it has become extremely slow. When compiling a 42 page document: real0m22,757s user0m7,243s sys 0m15,370s Before it even outputs the first page of the document, I get pages and pages of screen output looking like lisp code: (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amstext.sty (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) ... This is compared to before: real0m1,426s user0m1,191s sys 0m0,113s Where the lisp style lines look like this: (/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf -dist/tex/latex/amsmath/amstext.sty (/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf -dist/tex/latex/amsmath/amsgen.sty)) The difference is that before, /home/enge/.guix-profile/share/texmf-dist was directly a symbolic link into the store. Now it is a directory, and each file in it is its own symbolic link to a file in the store, and resolving them apparently takes a lot of time. I am confused as to why this happens. /home/enge/.guix-profile/share/texmf-dist contains 28 symbolic links, 26 of which point to directories and 2 to files (ls-R and README) in /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/ Then there is the "physical" directory web2c. It contains 47 separate symbolic links to files and directories in /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c. I do not understand why not the complete texmf-dist is a symbolic link as before, as the content seems to be the same, which should be handled during the profile creation. Maybe because of this in the definition of the texlive package: ;; Build the union of texlive-bin-full and texlive-texmf, but take the ;; conflicting subdirectory share/texmf-dist from texlive-texmf. What is the role of texlive-bin-full? Why does it contain share/texmf-dist? The basic architecture was to separate the binaries in texlive-bin (which needed compilation) from the tex files in texlive-texmf (which mainly needed copying, plus the black tex magic of format and font map creation), and their union was texlive. My impression is that commit 19fd1004138b60c4479d7516aa0cee261c0b6b57 Author: Nicolas Goaziou Date: Mon Jun 26 12:00:51 2023 +0200 gnu: Externalize libkpathsea in texlive and texlive-bin. poses problems. Which problem is it supposed to solve? What is the idea of the new architecture? Having texlive-libkpathsea, texlive-bin and texlive-bin-full, all the three with very long package definitions, looks very complex to me. Would it be possible and make sense to revert this commit? I considered opening a new bug, since this one looked distinct from not being able to install texlive-biber; but I wonder if texlive-biber is not simply a symptom of the same problem. The error message is updmap: open() failed: No such file or directory at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2159. updmap [ERROR]: The following map file(s) couldn't be found: updmap [ERROR]: dvips35.map (in builtin) updmap [ERROR]: pdftex35.map (in builtin) updmap [ERROR]: ps2pk35.map (in builtin) updmap [ERROR]: Did you run mktexlsr? Notice the location of the updmap script. The one in my profile points to /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/bin/updmap of the texlive package and the missing .map files are there at /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/fonts/map/dvips/tetex/dvips35.mapand so on. So my impression is that the new way of packaging breaks the monolithic texlive package, and that the texlive-biber package by using the texlive-build-system has become incompatible with the monolithic texlive. This comes from commit commit 3aeca58073eff8b7a835f6492e735dd152d9dc99 Author: Nicolas Goaziou Date: Mon Jun 19 14:43:56 2023 +0200 gnu: biber -> texlive-biber. which moves from perl-build-system to texlive-build-system. Andreas
bug#64832: Acknowledgement (Update wget)
This patch updates wget to the latest release version and replaces the self-hosted tarball we introduced to enable the core-updates merge. I built a few random dependent packages. "guix refresh -l" shows 974 dependent packages; nevertheless, if QA is not too busy, it would be nice to build it out to get rid of the non-standard tarball. Andreas
bug#64832: Update wget
Patch attached. Andreas >From 12e010849549aa6810fd57dacd566d7ff9b8662c Mon Sep 17 00:00:00 2001 Message-ID: <12e010849549aa6810fd57dacd566d7ff9b8662c.1690199971.git.andr...@enge.fr> From: Andreas Enge Date: Mon, 24 Jul 2023 13:58:14 +0200 Subject: [PATCH] gnu: wget: Update to 1.21.4. * gnu/packages/wget.scm (wget): Update to 1.21.4. --- gnu/packages/wget.scm | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/gnu/packages/wget.scm b/gnu/packages/wget.scm index 17459344c0..59503a5d61 100644 --- a/gnu/packages/wget.scm +++ b/gnu/packages/wget.scm @@ -46,16 +46,15 @@ (define-module (gnu packages wget) (define-public wget (package (name "wget") -(version "1.21.3.24") +(version "1.21.4") (source (origin (method url-fetch) - ;;(uri (string-append "mirror://gnu/wget/wget-" - ;;version ".tar.lz")) - (uri "https://www.multiprecision.org/wget-1.21.3.24-2b723.tar.lz;) + (uri (string-append "mirror://gnu/wget/wget-" + version ".tar.lz")) (sha256 (base32 -"17ip94mvax83h0gh4905jqc64g5qf3vgxr3bj9gn02pijjm5lzbp" +"1nabhxx3rg28h2scba2mlawzjyx3dw07j2kjn76cpvahbyd630rn" (build-system gnu-build-system) (inputs (list gnutls libidn2 libpsl)) base-commit: cf9904bcc8dd03e73675475bb4d8746dc434e415 -- 2.41.0
bug#57143: Test failure in python-dolfin-adjoint
Hello,
below are more details on the current test failure of python-dolfin-adjoint
version 2019.1.0. Maybe an option would be to try to update to a newer
version? There is 2019.1.2.
Andreas
=== FAILURES ===
_ test_read_checkpoint _
def test_read_checkpoint():
with stop_annotating():
N = 15
mesh = UnitSquareMesh(N, N)
V = FunctionSpace(mesh, "CG", 1)
x = SpatialCoordinate(mesh)
v = project(x[0]*x[1]*cos(x[1]), V)
out = XDMFFile(file_from_curr_dir("scalar.xdmf"))
out.write_checkpoint(v, "u", 0.0)
out.close()
exact = assemble(v*dx)
mesh = UnitSquareMesh(N, N)
V = FunctionSpace(mesh, "CG", 1)
v = Function(V)
c = Control(v)
J = assemble(v*dx)
infile = XDMFFile(file_from_curr_dir("scalar.xdmf"))
u = Function(V)
> infile.read_checkpoint(u,'u', -1)
tests/fenics_adjoint/test_io.py:38:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
args = (Coefficient(FunctionSpace(Mesh(VectorElement(FiniteElement('Lagrange',
triangle, 1), dim=2), 38754), FiniteElement('Lagrange', triangle, 1)), 38769),
'u', -1)
kwargs = {}, annotate = True
def XDMFFile_read_checkpoint(self, *args, **kwargs):
annotate = annotate_tape(kwargs)
> output = __XDMFFile_read_checkpoint__(self, *args, **kwargs)
E RuntimeError: basic_string::_M_construct null not valid
/gnu/store/p7hjddizapgmdk62dpvmrdkac0d4l3r9-python-dolfin-adjoint-2019.1.0/lib/python3.10/site-packages/fenics_adjoint/types/io.py:48:
RuntimeError
- Captured stdout call -
Calling FFC just-in-time (JIT) compiler, this may take some time.
-- Captured log call ---
Level 25 FFC:log.py:127 Calling FFC just-in-time (JIT) compiler, this may take
some time.
INFO FFC:log.py:127 Compiling form
ffc_form_e905624fad7a62b101d5d4bc784070d31ec0cc46
INFO FFC:log.py:127 Compiler stage 1: Analyzing form(s)
INFO FFC:log.py:127 ---
DEBUGFFC:log.py:127 Preprocessing form using 'uflacs' representation
family.
INFO FFC:log.py:127
INFO FFC:log.py:127 Geometric dimension: 2
Number of cell subdomains: 0
Rank: 1
Arguments: '(v_0)'
Number of coefficients:0
Coefficients: '[]'
Unique elements: 'CG1(?,?), Vector<2 x CG1(?,?)>'
Unique sub elements: 'CG1(?,?), Vector<2 x CG1(?,?)>'
INFO FFC:log.py:127 representation:auto --> uflacs
INFO FFC:log.py:127 quadrature_rule: auto --> default
INFO FFC:log.py:127 quadrature_degree: auto --> 6
INFO FFC:log.py:127 quadrature_degree: 6
INFO FFC:log.py:127
INFO FFC:log.py:127 Compiler stage 1 finished in 0.00596237 seconds.
INFO FFC:log.py:127 Compiler stage 2: Computing intermediate representation
INFO FFC:log.py:127 ---
INFO FFC:log.py:127 Computing representation of 0 elements
INFO FFC:log.py:127 Computing representation of 0 dofmaps
INFO FFC:log.py:127 Computing representation of 0 coordinate mappings
INFO FFC:log.py:127 Computing representation of integrals
INFO FFC:log.py:127 Computing uflacs representation
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGFFC:log.py:127 Reusing element from cache
DEBUGUFL:log.py:127 Blocks of each mode:
1 full
INFO FFC:log.py:127 Computing representation of forms
INFO FFC:log.py:127
INFO FFC:log.py:127 Compiler stage 2 finished in 0.0164835 seconds.
INFO FFC:log.py:127 Compiler stage 3: Optimizing intermediate representation
INFO FFC:log.py:127
INFO FFC:log.py:127 Optimizing uflacs representation
INFO FFC:log.py:127
INFO FFC:log.py:127 Compiler stage 3 finished in 0.000202894 seconds.
INFO FFC:log.py:127 Compiler stage 4: Generating code
INFO FFC:log.py:127 -
INFO FFC:log.py:127 Generating code for 0 finite_element(s)
INFO FFC:log.py:127
bug#64827: Acknowledgement (Texlive-biber not installable)
Well, it looks like all of texlive broke for me. In a profile with texlive, I now get this: $ pdflatex xyz.tex This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/GNU Guix) (preloaded format=pdflatex) restricted \write18 enabled. kpathsea: Running mktexfmt pdflatex.fmt mktexfmt: mktexfmt is using the following fmtutil.cnf files (in precedence order): mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing changes: mktexfmt: /home/enge/.texlive2023/texmf-config/web2c/fmtutil.cnf mktexfmt [INFO]: writing formats under /home/enge/.texlive2023/texmf-var/web2c mktexfmt [INFO]: Did not find entry for byfmt=pdflatex skipped mktexfmt [INFO]: total formats: 0 mktexfmt [INFO]: exiting with status 0 I can't find the format file `pdflatex.fmt'! Andreas
bug#64827: Texlive-biber not installable
Hello,
the latest texlive update (cudos!) has left texlive-biber broken, at least
in conjunction with the monolithic texlive:
$ guix shell texlive texlive-biber
The following derivation will be built:
/gnu/store/b2dzc8ayda5dp53s5dq40v0f41290b4c-profile.drv
building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
building directory of Info manuals...
building TeX Live font maps...
/builder for
`/gnu/store/07yvc85w6piyggplfmmb211ljfp4kvqp-texlive-font-maps.drv' failed with
exit code 1
build of /gnu/store/07yvc85w6piyggplfmmb211ljfp4kvqp-texlive-font-maps.drv
failed
View build log at
'/var/log/guix/drvs/07/yvc85w6piyggplfmmb211ljfp4kvqp-texlive-font-maps.drv.gz'.
cannot build derivation
`/gnu/store/b2dzc8ayda5dp53s5dq40v0f41290b4c-profile.drv': 1 dependencies
couldn't be built
guix shell: error: build of
`/gnu/store/b2dzc8ayda5dp53s5dq40v0f41290b4c-profile.drv' failed
Here is the end of
/var/log/guix/drvs/07/yvc85w6piyggplfmmb211ljfp4kvqp-texlive-font-maps.drv.gz
(not reproducing all the warnings at the beginning of the file):
Use of uninitialized value $fn in concatenation (.) or string at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2158.
Use of uninitialized value $fn in concatenation (.) or string at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2159.
updmap: open() failed: No such file or directory at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2159.
Use of uninitialized value $fn in concatenation (.) or string at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2158.
Use of uninitialized value $fn in concatenation (.) or string at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2159.
updmap: open() failed: No such file or directory at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2159.
Use of uninitialized value $fn in concatenation (.) or string at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2158.
Use of uninitialized value $fn in concatenation (.) or string at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2159.
updmap: open() failed: No such file or directory at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2159.
updmap [ERROR]: The following map file(s) couldn't be found:
updmap [ERROR]: dvips35.map (in builtin)
updmap [ERROR]: pdftex35.map (in builtin)
updmap [ERROR]: ps2pk35.map (in builtin)
updmap [ERROR]: Did you run mktexlsr?
You can disable non-existent map entries using the option
--syncwithtrees.
Backtrace:
2 (primitive-load "/gnu/store/zdmcg1a44zijbcf5a1p4bd030lc?")
In ice-9/eval.scm:
619:8 1 (_ #(#(#(# #) #) #))
In guix/build/utils.scm:
812:6 0 (invoke "/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-t?" ?)
guix/build/utils.scm:812:6: In procedure invoke:
ERROR:
1. :
program:
"/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap-sys"
arguments:
("--cnffile=/gnu/store/m8pgn9zabl8h3pgaqs7hxj8y9z4mvxhs-texlive-font-maps/share/texmf-dist/web2c/updmap.cfg"
"--dvipdfmxoutputdir=/gnu/store/m8pgn9zabl8h3pgaqs7hxj8y9z4mvxhs-texlive-font-maps/share/texmf-dist/fonts/map/dvipdfmx/updmap"
"--dvipsoutputdir=/gnu/store/m8pgn9zabl8h3pgaqs7hxj8y9z4mvxhs-texlive-font-maps/share/texmf-dist/fonts/map/dvips/updmap"
"--pdftexoutputdir=/gnu/store/m8pgn9zabl8h3pgaqs7hxj8y9z4mvxhs-texlive-font-maps/share/texmf-dist/fonts/map/pdftex/updmap")
exit-status: 1
term-signal: #f
stop-signal: #f
Andreas
bug#63938: Missing propagated (?) inputs
I get a text box with a similar, but not the same error: Traceback (most recent call last): File "/gnu/store/zjc4ijkrrp1b9v1va40a3fki0gkgcp6w-inkscape-1.2.1/share/inkscape/extensions/inkex/gui/__init__.py", line 38, in import gi ModuleNotFoundError: No module named 'gi' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/gnu/store/zjc4ijkrrp1b9v1va40a3fki0gkgcp6w-inkscape-1.2.1/share/inkscape/extensions/inkman/inkman/manage_extensions.py", line 29, in from inkex import gui File "/gnu/store/zjc4ijkrrp1b9v1va40a3fki0gkgcp6w-inkscape-1.2.1/share/inkscape/extensions/inkex/gui/__init__.py", line 42, in raise DependencyError( inkex.utils.DependencyError: You are missing the required libraries for Gtk. Please report this problem to the Inkscape developers. Maybe we are missing propagated inputs or wrapping with some environment variable? Andreas
bug#50300: Close
In current master, webrtc-for-telegram-desktop-0-328.5098730 builds. Closing. Andreas
bug#64302: Guix derivation cannot be computed during pull
Hello, Am Mon, Jul 10, 2023 at 11:38:47PM +0200 schrieb Ludovic Courtès: > Is there any more data you can grab? Perhaps in > /var/log/guix-daemon.log or similar if that’s on a foreign distro? it is a GNU system virtual machine. And I have this in /var/log/messages: Jul 19 11:57:51 localhost vmunix: [4619013.095327] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=69h614ii57kpgn5,pid=16408,uid=1000 Jul 19 11:57:51 localhost vmunix: [4619013.095350] Out of memory: Killed process 16408 (69h614ii57kpgn5) total-vm:54kB, anon-rss:433096kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:952kB oom_score_adj:0 > And as a last resort, ‘strace -f -o /tmp/log -s 500 guix pull’, so we > can get an idea of what happens. While this appears in the strace log: 16408 +++ killed by SIGKILL +++ So we have the culprit; not a Guix bug per se. $ cat /proc/meminfo MemTotal: 997864 kB MemFree: 679044 kB MemAvailable: 817052 kB It looks like 1GB of memory is not enough for "guix pull", which is not nice. Has this been addressed in later commits? Is there a known lower memory limit for using Guix? Andreas
bug#64302: Guix derivation cannot be computed during pull
Am Fri, Jul 07, 2023 at 04:09:13PM +0200 schrieb Ludovic Courtès: > Is it reproducible for you? Could it be a transient failure? It is not transient, it happens consistently. Can I do anything myself to trick it into working? Andreas
bug#64302: Guix derivation cannot be computed during pull
Hello,
here is what happens on a server I do not manage to update for about a year now:
$ guix pull
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 1bc878d (1,055 new commits)...
Building from this channel:
guix https://git.savannah.gnu.org/git/guix.git 1bc878d
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
building /gnu/store/a2zzynwqii5j84gg9zn2brkh0hiqrh6n-module-import.drv...
building /gnu/store/s8bj7c9nd85ng871h4440w7jw6p0hxpq-module-import.drv...
building
/gnu/store/3m2pndmnxj91s80ad1kvjw7kjsgpf733-module-import-compiled.drv...
building
/gnu/store/fg3r0s0r1sbljjdvgsnjkkziskn3fagp-module-import-compiled.drv...
building
/gnu/store/a2lgmyr95d3nr0snp31662rygf5g7cz7-compute-guix-derivation.drv...
Computing Guix derivation for 'x86_64-linux'... /guix pull: error: You found a
bug: the program
'/gnu/store/wvni7k3g4wnf0k782zgfv4gya9bnw8gg-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"1bc878ded2ea349384da6a72d4b8326c63c794b4"; system: "x86_64-linux";
host version: "35b176daf1a466f136f0b77c03de78f482a30702"; pull-version: 1).
Please report the COMPLETE output above by email to .
Here is the content of the compute-guix-derivation script:
#!/gnu/store/1kws5vkl0glvpxg7arabsv6q9vazp0hx-guile-3.0.7/bin/guile
--no-auto-compile
!#
(eval-when (expand load eval) (set! %load-path (cons
"/gnu/store/ic6dz76n6kax93q32b3356dvpl19iv5w-module-import" %load-path)) (set!
%load-compiled-path (cons
"/gnu/store/hkmx7wwwzdycj5q76j08ffn479vmvdax-module-import-compiled"
%load-compiled-path)))(begin (use-modules (ice-9 match)) (eval-when (expand
load eval) (match (command-line) ((_ source _ ...) (match %load-path ((front _
...) (unless (string=? front source) (set! %load-path (list source
(string-append "/gnu/store/60jl4xry9c93j9l0rr7nkvbw7dihjz4k-guile-gcrypt-0.3.0"
"/share/guile/site/" (effective-version)) front))) (set!
%load-compiled-path (cons (string-append
"/gnu/store/60jl4xry9c93j9l0rr7nkvbw7dihjz4k-guile-gcrypt-0.3.0" "/lib/guile/"
(effective-version) "/site-ccache") %load-compiled-path)) (read-disable (quote
positions))) (use-modules (guix store) (guix self) (guix derivations) (srfi
srfi-1)) (match (command-line) ((_ source system version protocol-version
build-output) (let* ((proto (string->number protocol-version)) (store (if
(integer? proto) (port->connection (duplicate-port (current-input-port) "w+0")
#:version proto) (open-connection))) (sock (socket AF_UNIX SOCK_STREAM 0)))
(connect sock AF_UNIX build-output) (display (and=> (parameterize
((current-warning-port (%make-void-port "w")) (current-build-output-port sock))
(run-with-store store (guix-derivation source version "3.0" #:channel-metadata
(quote (repository (version 0) (url
"https://git.savannah.gnu.org/git/guix.git;) (branch "master") (commit
"1bc878ded2ea349384da6a72d4b8326c63c794b4") (name guix) (introduction
(channel-introduction (version 0) (commit
"9edb3f66fd807b096b48283debdcddccfea34bad") (signer "BBB0 2DDF 2CEA F6A8 0D1D
E643 A2A0 6DF2 A33A 54FA") #:pull-version 1) #:system system))
derivation-file-name))
If I remember well, in the past I tried to update with a guix from guix
(obtained with "guix install guix") and also with one from git
("./pre-inst-env guix pull"), and the result was always the same.
So here is the sad outdated state:
$ guix describe
Generation 10 Aug 26 2022 15:29:35(current)
guix 35b176d
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 35b176daf1a466f136f0b77c03de78f482a30702
Andreas
bug#63526: ping on a build fix for a build failure (main branch)
Hello Andy,
Am Tue, May 30, 2023 at 10:54:20AM -0700 schrieb Andy Tai:
> Hi, following previous comments (thanks) I have submitted a patch to
> correctly fix a build failure due to compiler warnings, instead of
> avoiding not building tests, on this Guix bug issue:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
> Please review the patch (which shall be a simple and low risk fix). Thanks!
I have reworked a bit the punctuation of the commit message, shortened
the patch file name and pushed. By this I am closing the two corresponding
bug reports (it would have been enough to send a second version of the
patch to the first bug).
Did you contact upstream? Looking at the test, it looked wrong before and
after your patch...
if (len < token->data.character.len) {
hubbub_token t = { 0 };
t.type = HUBBUB_TOKEN_CHARACTER;
t.data.character.ptr += len;
t.data.character.len -= len;
...
Adding to a previously undefined, now 0 pointer .ptr raised a warning
for a reason, I think; and it looks like the t.data maybe should be
token->data. But it is quite possible that this branch is not even
reached by the test.
Andreas
bug#63050: "guix pull" requires graphical libraries
Am Sat, May 20, 2023 at 06:12:47PM +0200 schrieb Ludovic Courtès: > > The closure size reduction is substantial: > > $ ./pre-inst-env guix size graphviz | tail -1 > > total: 183.6 MiB > > $ guix size graphviz | tail -1 > > total: 242.3 MiB > > But I suspect we’d still need the full-blown variant for things like > > xdot. > Here’s a proposal: > https://issues.guix.gnu.org/63610 Typo? The issue is not found. Note that I do not care so much about the closure size, but about the number of packages that are needed to just build guix (although of course the two are related). Or otherwise said, the dependencies for "guix pull". On "exotic" architectures, each dependency is a potential cause of failure, and all in all it may take hours (days?) to run "guix pull" without substitutes, with a high chance of failure. Andreas
bug#63414: Evaluation comparison on cuirass
When working on a branch and deciding whether to merge it, we need a way of comparing its status with that of the master branch. As far as I can see, there is currently no way in cuirass to compare arbitrary evaluations and get a list (or a dashboard) of builds that fail in one, but not the other. Andreas
bug#63413: Stop and restart builds in cuirass
Stopping and starting builds in cuirass is not very comfortable. When working on core-updates, I stopped builds for some old evaluations on aarch64, where our build power would not be enough, assuming that many of the old builds were made obsolete by newer changes. (For instance, these could be builds in branches that were already merged to master.) However, this also stopped the builds that were not obsolete. And if the derivation was unchanged in a later evaluation (or a different branch), it would be kept as failed and not be restarted. I would argue that the desirable behaviour would be to try all derivations in a new evaluation, regardless of whether they were stopped in a previous evaluation. A use case are feature branches: Assume x-team and y-team are branches that are developed simultaneously; now x-team is ready first and gets merged to master. All builds of y-team are stopped (since there is no point in continuing with builds made obsolete by changes in x-team), the branch is rebased on master, and now all builds need to be restarted on the rebuilt branch. There is a button for this, but it also restarts genuinely failed builds, if I remember correctly. (In any case it did not solve the problem, but I have forgotten the details.) Restarting builds manually requires to take the dependency order into account. If x->y->z is a dependency chain, x has been stopped, and y or z are restarted, they will immediately fail since x is not available; otherwise said, restarting manually requires a manual traversal of the dependency graph, which should be automated. It would also be a useful feature to restart all builds of dependent packages: If x is "repaired" and manually started, it would be nice to be able to start all its dependents (ordered automatically by cuirass) to see whether they now succeed, instead of forcing us to manually traverse the graph again. For instance, we recently got a report on guix-devel of "no space left on device" for icedtea@3. This would be easy to solve by a "guix gc" on the build machines, but we currently have no way of restarting the many builds dependent on icedtea@3 other than restarting all packages. Andreas
bug#63412: Topological sorting in cuirass
This is a wishlist bug, but it is important for architectures where we are currently short on build power, and where this issue can stall builds and waste an arbitrary amount of build power. Cuirass should sort builds and only offload derivations for which all inputs are available. In my current understanding, cuirass offloads arbitrary derivations, and the machine to which they are offloaded then starts building recursively all inputs. If this is true, then it is possible that at some point in time, all build slots are taken by the same package built as many times as there are machines; I have seen something like this when working on core-updates, where several machines were building the main gcc compiler at the same time. At worse, if cuirass asks every machine to build a leaf package, this may result in a simultaneous full bootstrap on all of them. The situation becomes worse when the package in question fails. Then as I understand it, each machine may receive a request to build something depending on the failing package and try the failing build and thus waste build power that will not be available to build other packages successfully. Solving this problem may also make reports of build failures more accurate and legible. For instance, doxygen currently fails to build on aarch64: https://ci.guix.gnu.org/build/969427/details and is reported as "Failed", and not as "Failed (dependency)". However, looking at the build log https://ci.guix.gnu.org/build/969427/log/raw shows this: ... building path(s) `/gnu/store/p5vqrwywz053r1vkiyw54dp9gj7vw9xd-ninja-1.11.1' ... builder for `/gnu/store/0zf7fqndzf2k595r4s6wblmpccdwr3nx-ninja-1.11.1.drv' failed with exit code 1 @ build-failed /gnu/store/0zf7fqndzf2k595r4s6wblmpccdwr3nx-ninja-1.11.1.drv - 1 builder for `/gnu/store/0zf7fqndzf2k595r4s6wblmpccdwr3nx-ninja-1.11.1.drv' failed with exit code 1 cannot build derivation `/gnu/store/hlscqram59id51hxg0fj15041v52h1kw-meson-1.1.0.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/w8qxkrwpffd9qs5w1jggy1yi27ycm0xr-jsoncpp-1.9.5.drv': 2 dependencies couldn't be built cannot build derivation `/gnu/store/mss4yv015cil1vnjnglq506m83b7n3dy-cmake-bootstrap-3.24.2.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/w0irp6xn30nlmpizhcbjnvhqmsba41jn-cmake-minimal-3.24.2.drv': 2 dependencies couldn't be built cannot build derivation `/gnu/store/rqk2rbnpjpcnqswz8hqari1rnw6r8v1m-doxygen-1.9.5.drv': 1 dependencies couldn't be built So it is indeed a different package that fails (and the last few lines give a list of dependencies between ninja and doxygen, each of which may or may not fail once ninja is fixed). Notice that this could be solved without a topological sorting of the dependency graph: It would be enough to keep an array deriv in which deriv[i] contains a list of derivations requiring i more inputs to be built, together with the list of inputs; elements in deriv[0] are ready to be sent to a build machine, and upon completion of a build, all derivations depending on it should be moved from deriv[i] to deriv[i-1] if the input has been built successfully, or marked as "Failed (dependency)" if the input has failed. (But this could be expensive, and may require appropriate data structures.) Alternatively, build jobs could be sorted topologically and then be kept in a list; then before sending out a job, all its inputs have been tried to be built; the job should then be sent if all inputs are available, or be marked as "Failed (dependency)" if any of them has failed. Andreas
bug#63050: "guix pull" requires graphical libraries
Am Wed, Apr 26, 2023 at 08:39:59PM +0200 schrieb Josselin Poiret: > This would check the store path's references, but not necessarily all of > its inputs! I would hope that no package with docs ever keeps > references to texlive. Indeed! But here these are also the (native) inputs. Andreas
bug#63050: "guix pull" requires graphical libraries
Hello, Am Wed, Apr 26, 2023 at 06:59:44PM +0200 schrieb Liliana Marie Prikler: > Having built glib from scratch more often than is fun, I am quite > certain that the package pulling in our graphics stack is texinfo with > its reference to texlive. where do you see this? $ guix gc --references `guix build texinfo` /gnu/store/5j85qqflgx8nnzk86i43mxn0rjm8h2gv-perl-archive-zip-1.68 /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib /gnu/store/a5i8avx826brw5grn3n4qv40g514505c-coreutils-9.1 /gnu/store/bcc053jvsbspdjr17gnnd9dg85b3a0gy-ncurses-6.2.20210619 /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35 /gnu/store/hc05d76f1j3iz3v2bs5jz4fpljl1r4dj-gawk-5.2.1 /gnu/store/lj75fc25zx2y9pqvfp95la84rdhlj4f8-perl-5.36.0 /gnu/store/m8waimifhdjm8slb85jfihsm18jp1vc8-texinfo-7.0.3 /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16 So texinfo should be fine. It is this explicit inclusion of graphviz that poses problems (glib is then pulled in also). Andreas
bug#63050: "guix pull" requires graphical libraries
Am Tue, Apr 25, 2023 at 11:48:05PM +0200 schrieb Ludovic Courtès:
> This is apparently coming from Graphviz
> Surprising to me, but apparently it’s been this way from the start,
> commit b1b07d72c755ea314fb0c8333cd88293ee504ce4 (2013!).
> Maybe these are optional dependencies?
So "guix pull" builds what is defined as the guix package, but with the
current checkout as source?
The package definition of guix has this among the native inputs:
;; XXX: Keep the development inputs here even though
;; they're unnecessary, just so that 'guix environment
;; guix' always contains them.
("autoconf" ,autoconf)
("automake" ,automake)
("gettext" ,gettext-minimal)
("texinfo" ,texinfo)
("graphviz" ,graphviz)
("help2man" ,help2man)
("po4a" ,po4a)))
Maybe these could be dropped then, and we could have an expanded package
guix-devel that would add these inputs for "guix shell -D guix-devel"?
Or is it needed for "guix graph"?
$ guix graph --list-backends
- graphviz: Generate graph in DOT format for use with Graphviz.
...
But for this we do not need any graphical output, it is just text file
creation; could we have a graphviz-minimal in console mode?
Andreas
bug#63073: News entry for ‘core-updates’
Am Tue, Apr 25, 2023 at 08:23:22PM +0200 schrieb Ludovic Courtès: > I probably missed important items, maybe build system changes? Honestly, I do not know... Version updates all over the place. But I do not know earth shattering ones. These should come in the feature branches now. Andreas
bug#62954: Valgrind blocks R on powerpc64le
Closing this bug, the topic is treated through the patches in https://issues.guix.gnu.org/62967 Andreas
bug#61364: Close
Core-updates has been merged, and hopefully addresses all your problems. If some remain, please feel free to open new issues and submit corresponding patches. Thanks! Andreas
bug#62176: Close
Mesa has been updated in the latest core-updates merge. Andreas
bug#63050: "guix pull" requires graphical libraries
While trying out a "guix pull" on an aarch64 machine, for which many packages are currently not available as substitutes, I notice an extra- ordinary amount of dependencies, see below (and since I interrupted and restarted it, there are even more dependencies in reality; I remember X11 libraries such as libxi and libxt). Many of them are related to graphical environments, which should not happen for a command line program. Chances are they are pulled in for building documentation (not necessarily of Guix, but of packages that are needed for pulling); but this is still undesirable and should be sorted out. Actually there is a relatively high risk that on non-x86 machines "guix pull" will fail due to one of the packages not building. And then if the packages are fixed, they cannot be pulled... (but substitutes would still work then). Andreas The following derivations will be built: /gnu/store/vrzlz31xgsmz05m294maxvkwld98yvwp-profile.drv /gnu/store/bmk0f4b0ia9vvm9djkhjp5yiibgiwqkv-guix-827df9d1d.drv /gnu/store/75051kjkpqyk63jfcc21jxx6blh1v6xj-guix-command.drv /gnu/store/4mpya4wbmid6rxszs6qrlr56hgxpsmzx-guix-module-union.drv /gnu/store/81vk2gf0qfz325wk0rdfabpjxkwgnlcx-guile-git-0.5.2.drv /gnu/store/k8pg7wpmhzkip9h4x6vw958i81p9rrxd-libgit2-1.3.2.drv /gnu/store/w0irp6xn30nlmpizhcbjnvhqmsba41jn-cmake-minimal-3.24.2.drv /gnu/store/cqw34xafh837ikspy26787spipggx158-curl-7.85.0.drv /gnu/store/mss4yv015cil1vnjnglq506m83b7n3dy-cmake-bootstrap-3.24.2.drv /gnu/store/w8qxkrwpffd9qs5w1jggy1yi27ycm0xr-jsoncpp-1.9.5.drv /gnu/store/hlscqram59id51hxg0fj15041v52h1kw-meson-1.1.0.drv /gnu/store/97ghaxk1q09aqi92x9qg3nwb5vjm22hv-guile-gnutls-3.7.11.drv /gnu/store/n1rv809j9jwmax12057l0lcphz4bzi7s-gnulib-2022-12-06-1.440b528.drv /gnu/store/0nhbmnck41rl3i8hipkxfcvzyi36wgnr-git-minimal-2.33.1.drv /gnu/store/jhi11h8m8i86ivzrmvfhyj4h99rpqb4y-guix-827df9d1d-modules.drv /gnu/store/0sivy14wkr7g1wsn2jgyz6dh53883k0h-guix-config-modules.drv /gnu/store/1bwjqypxjn3671xmc9b9wh9bfg85nwra-guix-config-source.drv /gnu/store/0047yrla9lddhb9c1b4kl4bpd5v9d7ly-config.scm.drv /gnu/store/d11yp292a29g2m07xn12s6g2hs6w5rq2-guix-config.drv /gnu/store/1qwajh2vs8gmvm882zcw6np48fh7xva8-guix-packages-modules.drv /gnu/store/v2790dmh2savq6ddgq0ics8yz9y8ysvq-guix-packages.drv /gnu/store/034h41xz3m57gms9mx7yydssa66ns6xa-guix-extra.drv /gnu/store/lxanzzz28qk7ypdib5hz8xmibi73g6nv-guile-avahi-0.4.1.drv /gnu/store/s2vi6njxmxv4ng78rfdb9xkdiy40fngb-avahi-0.8.drv /gnu/store/1liwcy87b3cafm2wwfza5jl9c3xfh3k7-glib-2.72.3.drv /gnu/store/7yfb32ngiyx6gsky8ccmaq06qvg9qi8f-dbus-1.14.0.drv /gnu/store/0f25lrmw7yc1k9rxxq6af7bjr4kxpi7c-itstool-2.0.7.drv /gnu/store/sjj9z6kchsbmzskp5i23blpkj2b9v1na-python-libxml2-2.9.14.drv /gnu/store/4axvv1sli67w1jx0c5fxi4369pklby8p-yelp-tools-3.32.2.drv /gnu/store/a1y2z3nh0lmbyiddnc5qq92p991vc6fl-yelp-xsl-41.0.drv /gnu/store/mzial98cazz0wmigjd0by59ympr62zmv-xmlto-0.0.28.drv /gnu/store/r33mnrmy08757czq7x19lbawmngkswb8-docbook-xsl-1.79.2-0.fe16c90.drv /gnu/store/ywxvva73z0gmnjbdac9ml3fld4agy7ll-perl-xml-xpath-1.44.drv /gnu/store/744pph8mif8911dij1gw838slmgsplr4-perl-path-tiny-0.118.drv /gnu/store/nlrv7ll0gdf2k7g0v1g0d2c1sz2ff9pa-perl-unicode-utf8-0.62.drv /gnu/store/r84snp03sqlmvssfsa6f3wank4249dbm-perl-test-fatal-0.016.drv /gnu/store/rqk2rbnpjpcnqswz8hqari1rnw6r8v1m-doxygen-1.9.5.drv /gnu/store/zs50rf9mqd77lf7f7ycwj98mdvm3nwc1-guile-ssh-0.16.3.drv /gnu/store/cysfj5rhcnlwnd0skpb8x5cvh320qcpx-libssh-0.10.4.drv /gnu/store/kfqkj69hxgdl2yhn27l1cx3v4b83438k-guix-packages-base.drv /gnu/store/24bwa2hmiydpjjv58kbnszc67d0063w8-guix-extra-modules.drv /gnu/store/cl6757qxk66kpwhhwscwd3z3ir9ylfxy-guix-cli-core-modules.drv /gnu/store/fb71xmnmdi506sjjfqvvhk2n4q5nw9b5-guix-cli-core.drv /gnu/store/f5p7zbpi3f8bbc1bsdbr293r4p4qlr6k-guix-packages-base-modules.drv /gnu/store/gyncf7k5kvwcfbw1dx3jc73n9jmdw3ml-guix-home-modules.drv /gnu/store/9m9iiqd2yvlbjnpxzfwfk94bi9i2gj13-guix-home.drv /gnu/store/dqjb6lb1m8kaam2klgc44j1g040pr1h4-guix-system.drv /gnu/store/i2vpbmmyywk9sd11hl02zfg1nigq0k24-guix-system-tests-modules.drv /gnu/store/zm9yhv95zs1j68ypl9kr4gm4bbymgw3m-guix-system-tests.drv /gnu/store/ca9k2x3z22dn489g976p31fw8cr05p6s-guix-cli.drv /gnu/store/rk24641w60fqddyj0b4lizndcxvrpl45-guix-cli-modules.drv /gnu/store/wd94xqha92w7wj75704j48yh17pghv48-guix-system-modules.drv /gnu/store/sgyi2j6333mv08r8xxyxhaj47886q3hs-guix-daemon.drv /gnu/store/r80zify247zcsxdw1dm6aacr456zqxyf-guix-daemon-1.4.0-5.286cdf0.drv /gnu/store/w0ssgndl2aq7xzc3ibbkgg4dpgyf2mxb-guix-manual.drv /gnu/store/44l2hp82lmrhmsam320020pvf0wx79gb-guix-translated-texinfo.drv /gnu/store/hx8pv27k6r1q5gmdb0zmp9pqqadqp8gh-po4a-0.68.drv /gnu/store/04kfwmpg17hxxzq13b9s06zl63zcc706-texlive-fonts-latex-59745.drv /gnu/store/2lk5x3aw5vi59dkvf1qd0696fdmirgb7-texlive-bin-20210325.drv /gnu/store/1liwcy87b3cafm2wwfza5jl9c3xfh3k7-glib-2.72.3.drv /gnu/store/2l7j29ck29dcaaffi659pkpxr9bmp64f-gd-2.3.2.drv
bug#62956: Fail to update gajim
Am Mon, Apr 24, 2023 at 10:51:31AM +0200 schrieb Simon Tournier: > Please note #62956 reporting the failure and proposing a patch. Thanks for the notice! On core-updates, the current gajim requires python-gssapi, which fails to build; so this would have to be repaired additionally to the above patch. Andreas
bug#62992: Stray po.go file
This is not related to the dancefloor. Someone on IRC mentioned that "make clean-go" leaves a stray file guix/build/po.go. I suppose that it should be added to Makefile.am in the line that currently reads: GOBJECTS = $(MODULES:%.scm=%.go) guix/config.go $(dist_noinst_DATA:%.scm=%.go) but would like to leave it to the experts. Actually further above we have this: MODULES_NOT_COMPILED = \ guix/build/po.scm \ guix/man-db.scm So maybe a better fix would be to move guix/build/po.scm to MODULES instead, since apparently it is compiled. Andreas
bug#62954: Valgrind blocks R on powerpc64le
Am Fri, Apr 21, 2023 at 09:59:37AM +0200 schrieb Simon Tournier: > Because it is two “mailing lists“ under the hood: guix-patches and bug-guix. > Last, on the pragmatic side, I do not know if the CI is following > bug-guix and if it tries to extract patches from it. Ah indeed, I suppose it does not, thanks for the explanation. Andreas
bug#62954: Valgrind blocks R on powerpc64le
Am Thu, Apr 20, 2023 at 03:25:17PM +0200 schrieb Simon Tournier: > See #62967 [1] for an attempt. I am rebuilding to detect the potential > problem. Not sure why we need a second issue... All this should work, let us wait till after the core-updates merge. Andreas
bug#62954: Valgrind blocks R on powerpc64le
Am Thu, Apr 20, 2023 at 01:26:37PM +0200 schrieb Simon Tournier: > shows that most of the paths do not involve texlive-ms. Instead, it > seems related to lz4 or openmpi or jq. So I start to understand. lz4 depends on valgrind. I do not know why. It is given as a native input, so probably the tests require valgrind? If yes, that looks a bit excessive to me - the developers of lz4 are very welcome to check for memory leaks from time to time, but doing this at every compilation is excessive. What do you think of dropping the valgrind input (at the same time as updating valgrind, say)? It does not seem to be necessary, as it is already dropped on architectures that do not provide it, without further ado. Maybe this is what hides it from "guix refresh" and "guix graph"? Then texlive-ms depends on lz4 and indirectly on valgrind: $ ./pre-inst-env guix build --system=powerpc64le-linux texlive-ms -n /gnu/store/j0wzdc36vvgvj4zh49a71sc115m6m76b-texlive-ms-59745.drv /gnu/store/jl6p6m1zngi1rjl2808zvnb9wpiphhjf-texlive-ms-59745-checkout.drv /gnu/store/gfkdb5pys2b8dr2mqgs5gbwfflwlc4kh-subversion-1.14.2.drv /gnu/store/xw5kdli3i92iwd7wpplcb0p89g1p3a29-lz4-1.9.3.drv /gnu/store/z6kf2pg48b9a87angabkfyfv4knhhwjy-valgrind-3.17.0.drv More precisely: texlive-ms is downloaded via subversion via simple-texlive-package in (gnu packages texlive), which relies on texlive-origin from (guix build-system texlive). $ ./pre-inst-env guix build --system=powerpc64le-linux subversion -n The following derivations would be built: /gnu/store/gfkdb5pys2b8dr2mqgs5gbwfflwlc4kh-subversion-1.14.2.drv /gnu/store/xw5kdli3i92iwd7wpplcb0p89g1p3a29-lz4-1.9.3.drv /gnu/store/z6kf2pg48b9a87angabkfyfv4knhhwjy-valgrind-3.17.0.drv So subversion depends on valgrind! And all new simplex-texlive-packages are concerned. I think the solution is to indeed remove valgrind from the native inputs of lz4. And I think there is a shortcoming in "guix refresh" that it does not take the source code of packages into account. What do you think? Andreas
bug#62954: Valgrind blocks R on powerpc64le
Currently r-minimal depends on texlive-latex-xkeyval, which depends on texlive-ms, which for a reason I do not see pulls in the valgrind variable. This is at version 3.17, which fails on powerpc64le. The user facing variable valgrind/interactive, however, is at 3.20, and it builds. After the impending core-updates merge, we should update valgrind to 3.20. I am opening a bug so that this is not forgotten. Andreas
bug#62949: libgcrypt version in core-updates
Am Wed, Apr 19, 2023 at 06:37:08PM +0200 schrieb Ludovic Courtès: > Given that the ‘guix’ package builds fine on ‘core-updates’, it’s most > likely a build environment issue. > What does ‘config.log’ say? My environment is Debian on aarch64, with Guix as the package manager. So it is possible that the Debian environment disturbs what is happening; but I see the problem depending on whether I install the new or the old libgcrypt from Guix. Here are lines from config.log with things related to crypto in them: configure:8987: checking whether Guile-Gcrypt is available and recent enough configure:9005: result: yes ... configure:9062: WARNING: The Guile-Lib requirement was not satisfied (>= 0.2.7); Some features such as the Go importer will not be usable. (not crypto related, but suspicious) ... configure:9435: checking for libgcrypt-config configure:9458: found /home/andreas/.guix-profile/bin/libgcrypt-config configure:9470: result: /home/andreas/.guix-profile/bin/libgcrypt-config configure:9478: checking libgcrypt's library directory configure:9490: result: /gnu/store/2xsdih7m18d0f2kiicxrh9pwinjfwzkj-libgcrypt-1.10.1/lib configure:10900: checking for gcry_md_open in -lgcrypt configure:10922: g++ -o conftest -g -O2conftest.cpp -lgcrypt >&5 ld: /home/andreas/.guix-profile/lib/libgpg-error.so.0: undefined reference to `pthread_mutex_trylock@GLIBC_2.34' collect2: error: ld returned 1 exit status configure:10922: $? = 1 configure: failed program was: ... configure:10932: result: no configure:10941: checking for gcrypt.h configure:10941: g++ -c -g -O2 conftest.cpp >&5 configure:10941: $? = 0 configure:10941: result: yes configure:10950: error: GNU libgcrypt not found; please install it. So this is not related to libgcrypt, but to libgpg-error.so linked with an old glibc; we should be at 2.35 in core-updates, no? Strangely enough, when I do ldd on /home/andreas/.guix-profile/lib/libgpg-error.so.0 then it is linked with /gnu/store/...-glibc-2.35/lib/libc.so. Where does this pthread_mutex_trylock@GLIBC_2.34 come from? I tried "guix shell --pure -D guix" and then "./configure", but the result is the same. I will try again on my pure Guix machine. Andreas
bug#62936: libgcrypt version in core-updates
Hello, this looks to me like it could be a duplicate of #62936, but since this bug is closed, I am simply opening a new one. The libgcrypt version was updated from 1.8.8 to 1.10.1 from master to core-updates. This causes ./configure to fail like so: ... checking for gcry_md_open in -lgcrypt... no checking for gcrypt.h... yes configure: error: GNU libgcrypt not found; please install it I suppose that the same problem occurred in #62936, but did not manifest itself as clearly since one usually does not rerun configure. It looks as if the API changed incompatibly between the two versions. Andreas
bug#36077: Close
Current mesa builds on master (@21) and core-updates (@22), so the problem has apparently been solved. Andreas
bug#48214: Close
Closing the bug, feel free to open a new one if the problem persists with newer versions. Andreas
bug#61879: Patch
Am Fri, Apr 14, 2023 at 11:37:05AM +0100 schrieb Christopher Baines: > I've made those changes to the commit you pushed earlier and pushed to > core-updates now. That did it, lots of green dots in the dashboard. Thanks! Closing the bug now. Andreas
bug#61879: Patch
Am Fri, Apr 14, 2023 at 09:20:03AM +0100 schrieb Christopher Baines: > I haven't tried this yet, but I've had a quick look. I'm not sure > search-patches will work where it is, since that'll be running in the > build environment, without any access to the patches in the Guix git > repository. Good point. But is this not exactly like your previous commit, which I understood you had tested? But you are right: https://ci.guix.gnu.org/build/909454/log/raw error: in phase 'patch-powerpc': uncaught exception: unbound-variable #f "Unbound variable: ~S" (search-patch) #f phase `patch-powerpc' failed after 0.0 seconds I will revert (the good news: it indeed did not break any other architecture). If we do not have access to the patch during build, we would need to replace it by an invocation of substitute*, with a lot of escaping of special characters like line ends, which would be annoying to test (well, one could test on x86_64 on a dummy package with the same source as gcc-11). Andreas
bug#61879: Patch
Am Thu, Apr 13, 2023 at 06:57:41PM +0200 schrieb Andreas Enge: > attached is a new commit in old syntax, mixing both our commits. > I have confirmed that it does not change the gcc-11 build on x86_64 and i686. > But do we need "--force" for patching? > Could you maybe check again whether this builds gcc-11 on powerpc? I just pushed it, since it cannot break much... If CI shows it does not work, we can still revert it. Andreas
bug#61879: Patch
Hello,
attached is a new commit in old syntax, mixing both our commits.
I have confirmed that it does not change the gcc-11 build on x86_64 and i686.
But do we need "--force" for patching?
Could you maybe check again whether this builds gcc-11 on powerpc?
If yes, we can push it, and feel free to gexpify it in a separate commit.
Andreas
>From 9900f9e9b86550e7d336b04ad46fba088e28cbd6 Mon Sep 17 00:00:00 2001
From: Andreas Enge
Date: Thu, 13 Apr 2023 11:46:47 +0200
Subject: [PATCH] gnu: gcc-11: Fix build on powerpc64le.
* gnu/packages/patches/gcc-11-libstdc++-powerpc.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
* gnu/packages/gcc.scm (make-libstdc++): Apply patch for gcc versions >= 11
and < 12 on ppc64le.
Co-authored-by: Christopher Baines
---
gnu/local.mk | 1 +
gnu/packages/gcc.scm | 11 ++-
.../patches/gcc-11-libstdc++-powerpc.patch | 18 ++
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index b07811f1cb..1255846462 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1184,6 +1184,7 @@ dist_patch_DATA =
\
%D%/packages/patches/gcc-11-libstdc++-hurd-libpthread.patch \
%D%/packages/patches/gcc-12-cross-environment-variables.patch \
%D%/packages/patches/gcc-10-tree-sra-union-handling.patch\
+ %D%/packages/patches/gcc-11-libstdc++-powerpc.patch \
%D%/packages/patches/gcolor3-update-libportal-usage.patch\
%D%/packages/patches/gd-fix-tests-on-i686.patch \
%D%/packages/patches/gd-brect-bounds.patch \
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index a511cdbc45..ae324219d3 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -2,7 +2,7 @@
;;; Copyright © 2012-2023 Ludovic Courtès
;;; Copyright © 2014, 2015, 2018 Mark H Weaver
;;; Copyright © 2014, 2015, 2016, 2017, 2019, 2021 Ricardo Wurmus
-;;; Copyright © 2015 Andreas Enge
+;;; Copyright © 2015, 2023 Andreas Enge
;;; Copyright © 2015-2018, 2020-2023 Efraim Flashner
;;; Copyright © 2016 Carlos Sánchez de La Lama
;;; Copyright © 2018 Tobias Geerinckx-Rice
@@ -889,6 +889,15 @@ (define-public (make-libstdc++ gcc)
":")
"\nAM_CXXFLAGS = ")))
'())
+ ,@(let ((version (package-version gcc)))
+(if (and (target-ppc64le?)
+(version>=? version "11")
+(not (version>=? version "12")))
+ `((add-after 'unpack 'patch-powerpc
+ (lambda _
+(invoke "patch" "--force" "-p1" "-i"
+(search-patch "gcc-11-libstdc++-powerpc.patch")
+ '()))
;; Force rs6000 (i.e., powerpc) libdir to be /lib and not /lib64.
(add-before 'chdir 'fix-rs6000-libdir
(lambda _
diff --git a/gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
b/gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
new file mode 100644
index 00..aff2ef16f1
--- /dev/null
+++ b/gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
@@ -0,0 +1,18 @@
+diff -u -r gcc-11.3.0.alt/libstdc++-v3/src/c++17/floating_from_chars.cc
gcc-11.3.0/libstdc++-v3/src/c++17/floating_from_chars.cc
+--- gcc-11.3.0.alt/libstdc++-v3/src/c++17/floating_from_chars.cc
2023-04-13 11:36:08.169841428 +0200
gcc-11.3.0/libstdc++-v3/src/c++17/floating_from_chars.cc 2023-04-13
11:36:54.825827304 +0200
+@@ -495,8 +495,14 @@
+ from_chars(const char* first, const char* last, __ieee128& value,
+ chars_format fmt) noexcept
+ {
++#if _GLIBCXX_USE_CXX11_ABI
+ buffer_resource mr;
+ pmr::string buf();
++#else
++ string buf;
++ if (!reserve_string(buf))
++return make_result(first, 0, {}, ec);
++#endif
+ size_t len = 0;
+ errc ec = errc::invalid_argument;
+ __try
--
2.39.2
bug#61879: Powerpc on core-updates
Am Thu, Apr 13, 2023 at 02:46:00PM +0100 schrieb Christopher Baines: > Thanks for figuring this out Andreas! I've managed to apply this change > in the relevant place, and it appears to work. Good news, thanks! > + #$@(if (and (target-ppc64le?) > + (version>=? (package-version gcc) "11")) The file changed a lot on master, and the patch will not apply and should not be needed there. I did not check, but I think it is already not needed for gcc@12 any more. So we should probably check for the major version being equal to 11. It should be easy to check that it does not cause any rebuilds on the other architectures, and we cannot break powerpc more than it already is, so feel free to push something along these lines to core-updates. Andreas
bug#61879: Powerpc on core-updates
I may as well try to provide a patch. It is untested even on x86_64,
since it requires quite a few rebuilds. If it works on powerpc, it should
probably be made conditional on the architecture to avoid a world rebuild.
I do not know whether this is possible in the patches field in an origin.
Andreas
>From 5eb50bdc34759d4c917f2143e037fad62bc08ed7 Mon Sep 17 00:00:00 2001
From: Andreas Enge
Date: Thu, 13 Apr 2023 11:46:47 +0200
Subject: [PATCH] gnu: gcc-11: Fix build on powerpc64le.
* gnu/packages/patches/gcc-11-libstdc++-powerpc.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
* gnu/packages/gcc.scm (gcc-11)[origin]: Use patch.
---
gnu/local.mk | 1 +
gnu/packages/gcc.scm | 5 +++--
.../patches/gcc-11-libstdc++-powerpc.patch | 18 ++
3 files changed, 22 insertions(+), 2 deletions(-)
create mode 100644 gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index b07811f1cb..1255846462 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1184,6 +1184,7 @@ dist_patch_DATA =
\
%D%/packages/patches/gcc-11-libstdc++-hurd-libpthread.patch \
%D%/packages/patches/gcc-12-cross-environment-variables.patch \
%D%/packages/patches/gcc-10-tree-sra-union-handling.patch\
+ %D%/packages/patches/gcc-11-libstdc++-powerpc.patch \
%D%/packages/patches/gcolor3-update-libportal-usage.patch\
%D%/packages/patches/gd-fix-tests-on-i686.patch \
%D%/packages/patches/gd-brect-bounds.patch \
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index a511cdbc45..631e08db25 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -2,7 +2,7 @@
;;; Copyright © 2012-2023 Ludovic Courtès
;;; Copyright © 2014, 2015, 2018 Mark H Weaver
;;; Copyright © 2014, 2015, 2016, 2017, 2019, 2021 Ricardo Wurmus
-;;; Copyright © 2015 Andreas Enge
+;;; Copyright © 2015, 2023 Andreas Enge
;;; Copyright © 2015-2018, 2020-2023 Efraim Flashner
;;; Copyright © 2016 Carlos Sánchez de La Lama
;;; Copyright © 2018 Tobias Geerinckx-Rice
@@ -703,7 +703,8 @@ (define-public gcc-11
"0fdclcwf728wbq52vphfcjywzhpsjp3kifzj3pib3xcihs0z4z5l"))
(patches (search-patches "gcc-9-strmov-store-file-names.patch"
"gcc-5.0-libvtv-runpath.patch"
- "gcc-10-tree-sra-union-handling.patch"))
+ "gcc-10-tree-sra-union-handling.patch"
+ "gcc-11-libstdc++-powerpc.patch"))
(modules '((guix build utils)))
(snippet gcc-canadian-cross-objdump-snippet)))
(arguments
diff --git a/gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
b/gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
new file mode 100644
index 00..aff2ef16f1
--- /dev/null
+++ b/gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
@@ -0,0 +1,18 @@
+diff -u -r gcc-11.3.0.alt/libstdc++-v3/src/c++17/floating_from_chars.cc
gcc-11.3.0/libstdc++-v3/src/c++17/floating_from_chars.cc
+--- gcc-11.3.0.alt/libstdc++-v3/src/c++17/floating_from_chars.cc
2023-04-13 11:36:08.169841428 +0200
gcc-11.3.0/libstdc++-v3/src/c++17/floating_from_chars.cc 2023-04-13
11:36:54.825827304 +0200
+@@ -495,8 +495,14 @@
+ from_chars(const char* first, const char* last, __ieee128& value,
+ chars_format fmt) noexcept
+ {
++#if _GLIBCXX_USE_CXX11_ABI
+ buffer_resource mr;
+ pmr::string buf();
++#else
++ string buf;
++ if (!reserve_string(buf))
++return make_result(first, 0, {}, ec);
++#endif
+ size_t len = 0;
+ errc ec = errc::invalid_argument;
+ __try
--
2.39.2
bug#61879: Powerpc on core-updates
Hello,
recently I claimed that powerpc was repaired, but I must have made a mistake.
It is still completely broken:
https://ci.guix.gnu.org/eval/391720/dashboard?system=powerpc64le-linux
due to this:
https://issues.guix.gnu.org/61879
It does not look easy to fix, but might be *the* blocker for a core-updates
merge...
The error is this:
../../../libstdc++-v3/src/c++17/floating_from_chars.cc: In function
'std::from_chars_result std::from_chars(const char*, const char*, __ieee128&,
std::chars_format)':
../../../libstdc++-v3/src/c++17/floating_from_chars.cc:499:8: error: 'string'
is not a member of 'std::pmr'; did you mean 'std::string'?
499 | pmr::string buf();
|^~
In file included from
/tmp/guix-build-libstdc++-11.3.0.drv-0/gcc-11.3.0/build/include/string:39,
from ../../../libstdc++-v3/src/c++17/floating_from_chars.cc:34:
/tmp/guix-build-libstdc++-11.3.0.drv-0/gcc-11.3.0/build/include/bits/stringfwd.h:79:33:
note: 'std::string' declared here
79 | typedef basic_stringstring;
| ^~
../../../libstdc++-v3/src/c++17/floating_from_chars.cc:504:55: error: 'buf' was
not declared in this scope
504 | if (const char* pat = pattern(first, last, fmt, buf)) [[likely]]
In the file
libstdc++-v3/src/c++17/floating_from_chars.cc
previous functions have code like this:
#if _GLIBCXX_USE_CXX11_ABI
buffer_resource mr;
pmr::string buf();
#else
string buf;
if (!reserve_string(buf))
return make_result(first, 0, {}, ec);
#endif
while here we only have:
buffer_resource mr;
pmr::string buf();
So my guess would be that we should simply replace this snippet with the
one above.
Could someone with access to a powerpc machine try out this change?
Andreas
bug#62723: Fix for librsvg 2.40 on core-updates
Am Mon, Apr 10, 2023 at 07:00:16PM + schrieb Kaelyn: > I just mailed https://issues.guix.gnu.org/62758 to add a snippet to fix the > build error. I used a similar approach as the existing snippet for fixing a > format overflow error. (I also forgot to set the subject prefix to "PATCH > core-updates" on the git send-mail command line.). Thanks a lot, this looks like a good fix. I have just pushed it. Andreas
bug#62723: autogen fails to build on i686-linux
Hello, autogen fails to build on i686-linux like so, for instance on master commit c9af27d4ca733b20f09019f1465d3e5fdc1ec724: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -DPKGDATADIR=\"/gnu/store/n29inqv3rnwix1jqsxc1gd2yw0q8jkr0-autogen-5.18.16/share/autogen\" -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra -Wno-cast-qual -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -c libopts.c -fPIC -DPIC -o .libs/libopts_la-libopts.o In file included from libopts.c:48: usage.c: In function ‘prt_extd_usage.isra’: usage.c:736:38: error: ‘s ’ directive output may be truncated writing 2 bytes into a region of size between 0 and 9 [-Werror=format-truncation=] 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); | ^~~ usage.c:736:9: note: ‘snprintf’ output between 9 and 18 bytes into a destination of size 12 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); | ^~ cc1: all warnings being treated as errors The version we package from https://ftp.gnu.org/pub/gnu/autogen/ dates from 2018. The website https://www.gnu.org/software/autogen/ has apparently not been updated since 2015. I wonder if we had not better drop this apparently unmaintained software, but it has quite a lot of dependents: Building the following 1275 packages would ensure 2489 dependent packages are rebuilt Andreas
bug#61839: Offloading problems on berlin
Am Thu, Mar 16, 2023 at 02:50:53PM +0100 schrieb Ludovic Courtès: > I occasionally offload from my laptop to machines at work but didn’t hit > this bug, so we’ll have to see if it’s specific to berlin or not. My impression is that in my case, the problem is not with ssh, but somehow with the guix daemon. I tend to observe this: guix offload: sending 1 store item (6,490 MiB) to '141.80.167.169'... exporting path `/gnu/store/y4ipvkapf1gninaabwdl6pcz46c1frak-texlive-texmf-20210325' Then jnettop shows data transfer of about 100 to 120MB/s during a bit over a minute, which makes me think that the actual data transfer succeeds, but that somehow the data is not registered in the store. Then nothing tangible happens and offloading times out. Since I am apparently not able to connect to the machines via ssh, I cannot have a closer look at the receiving end. Andreas
bug#62097: Spurious error
I do not know which error I made, but libaio *does* build with the current core-updates HEAD. Sorry for the noise. Andreas
bug#62097: Libaio on core-updates
Libaio has started to fail on core-updates; this is very annoying since:
Building the following 1068 packages would ensure 2078 dependent packages are
rebuilt,
among which qt@5 and gnome.
Here is the result of "git bisect":
0ad86e94f518c70690641c1d6f3a04037974a25b is the first bad commit
commit 0ad86e94f518c70690641c1d6f3a04037974a25b
Author: Ludovic Courtès
Date: Thu Mar 9 13:08:53 2023 +0100
gnu: libstdc++: Fix cross-compilation.
* gnu/packages/gcc.scm (make-libstdc++): Adjust 'hide-gcc-headers' for
cross-compiled libstdc++.
Hm, that is supposed to only affect cross compilation, but apparently it broke
something on native compilation for x86_64.
Andreas
In file included from main.c:24:
cases/23.t: In function ‘thrproc2’:
cases/23.t:82:35: error: passing argument 2 of ‘splice’ from incompatible
pointer type [-Werror=incompatible-pointer-types]
82 | if (splice(tmpfd, , pipefds[1], NULL, 1, 0) != 1)
| ^~~
| |
| off_t * {aka long int *}
In file included from
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/bits/fcntl.h:61,
from
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/fcntl.h:35,
from main.c:9:
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/bits/fcntl-linux.h:398:49:
note: expected ‘__off64_t *’ {aka ‘long long int *’} but argument is of type
‘off_t *’ {aka ‘long int *’}
398 | extern __ssize_t splice (int __fdin, __off64_t *__offin, int __fdout,
| ~~~^~~
In file included from main.c:24:
cases/23.t: In function ‘thrproc3’:
cases/23.t:106:35: error: passing argument 2 of ‘splice’ from incompatible
pointer type [-Werror=incompatible-pointer-types]
106 | if (splice(tmpfd, , pipefds[1], NULL, 1, 0) != 1)
| ^~~
| |
| off_t * {aka long int *}
In file included from
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/bits/fcntl.h:61,
from
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/fcntl.h:35,
from main.c:9:
/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/include/bits/fcntl-linux.h:398:49:
note: expected ‘__off64_t *’ {aka ‘long long int *’} but argument is of type
‘off_t *’ {aka ‘long int *’}
398 | extern __ssize_t splice (int __fdin, __off64_t *__offin, int __fdout,
| ~~~^~~
cc1: all warnings being treated as errors
make[1]: *** [Makefile:24: cases/23.p] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory
'/tmp/guix-build-libaio-0.3.113.drv-0/libaio-0.3.113/harness'
make: *** [Makefile:23: partcheck] Error 2
Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("partcheck" "-j" "4"
"prefix=/gnu/store/xr6s773c3d62g9aynydp1h6231p42ixn-libaio-0.3.113" "CC=gcc")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 1.1 seconds
command "make" "partcheck" "-j" "4"
"prefix=/gnu/store/xr6s773c3d62g9aynydp1h6231p42ixn-libaio-0.3.113" "CC=gcc"
failed with status 2
builder for `/gnu/store/yqgy73rhzmi0n0yfdlarj9g1w8rvgpwy-libaio-0.3.113.drv'
failed with exit code 1
build of /gnu/store/yqgy73rhzmi0n0yfdlarj9g1w8rvgpwy-libaio-0.3.113.drv failed
View build log at
'/var/log/guix/drvs/yq/gy73rhzmi0n0yfdlarj9g1w8rvgpwy-libaio-0.3.113.drv.gz'.
bug#49985: Merging core-updates?
Am Thu, Feb 16, 2023 at 04:03:15PM +0100 schrieb Janneke Nieuwenhuizen: > Great, thanks so much for checking! Are you using any of tmpfs or btrfs > on /tmp? No, it is all on SSD, so we probably cannot conclude for the bugs, unfortunately. Andreas
bug#61475: Staging branch (was: Moving forward with teams and feature branches)
Am Sun, Feb 12, 2023 at 10:13:35PM +0100 schrieb Josselin Poiret:
> 4. staging merge happens, and the branch gets deleted.
I tried to build staging for my profile on x86_64, but it failed with
a dependency of ffmpeg, rust-rav1e-0.5.1. There is a newer version 0.6.3,
but I did not simply update it, since the package looks particularly
complicated, containing a phase:
(add-after 'configure 'force-rust-edition-2018
(lambda* (#:key vendor-dir #:allow-other-keys)
;; Force all the dependencies to not be higher than edition 2018.
(with-fluids ((%default-port-encoding #f))
(substitute* (find-files vendor-dir "Cargo.toml")
(("edition = \\\"2021\\\"") "edition = \"2018\"")
and many other changes.
If someone who knows rust could have a look and make a suggestion, that
would be great.
Andreas
bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.
Am Wed, Sep 07, 2022 at 01:13:25PM +0200 schrieb Maxime Devos: > Also, we _do_ have concrete evidence that the curves are flawed -- the website > on the link mentions many issues in the process The website (you mean the blog by D. Bernstein?) also mentions the use of a hash function to arrive at the parameters. Maybe I overlooked something, but I did not find other mentions of the curves (but I did not read the page from A to Z). > past that the NSA is in the habit of subverting communications. But this is not concrete evidence that these curves are flawed. As far as is publicly known, there are a few weak (and sparse) classes of insecure elliptic curves, and the NIST curves do not belong to them. So the only way these curves could be flawed is that there is an unknown class of insecure curves, where the insecurity is known by the NSA. Then if this class is sufficiently dense, one could start with a random seed, hash the seed, and repeat until one obtains a weak instance; see this link by a well-known cryptologist https://miracl.com/blog/backdoors-in-nist-elliptic-curves/ and the link given there (to another post by Bernstein). This is possible, but speculation instead of evidence. Newer constructions are better, but not perfect; optimally one would want a process of "generation of public random numbers" as described here: https://eprint.iacr.org/2015/366 > Channels are for sharing things between multiple people. The keys are for > authenticating channels. As multiple people are involved for a channel, this > seems be be a non-personal decision by definition. I said "political", which fits well the setting of multiple people involved. And I meant this in opposition to "scientific", given the lack of evidence against the NIST curves. Andreas
bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.
Hello, Am Tue, Sep 06, 2022 at 10:02:55PM +0200 schrieb Ludovic Courtès: > (Cc’ing Andreas for extra advice.) well, I agree with your analysis. There is no concrete evidence that the NIST curves may be flawed, and a general belief that not all crypto standards of NIST are flawed or backdoored... So it makes sense to accept the curves, but ultimately this is a political decision (and a personal decision about which type of key a user creates). Andreas
bug#57143: python-dolfin-adjoint / FEniCS fails to build
Hello, when updating python-sympy, I noticed that its dependent python-dolfin-adjoint fails to build. Probably this was also true before, since we do not have a substitute. I think the problem was in FEniCS, with an assertion failure, so my impression was that the code computed a wrong solution. It would be nice if someone with special knowledge could have a look; some of the packages in the family also have updates available (but not dolfin itself if I saw correctly). Andreas
bug#57077: guix-jupyter fails a test
Hello,
guix-jupyter currently fails to build with the error message below. While I
noticed it when updating python-sympy, the problem was already present
before.
Andreas
test-name: execute_request
location: /tmp/guix-build-guix-jupyter-0.2.2.drv-0/source/tests/kernels.scm:100
source:
+ (test-equal
+ "execute_request"
+ 42
+ (let ((request
+ (message
+ (header "execute_request" "luser" "12345")
+ (scm->json-string
+ (execute-request->json
+ (execute-request (code "40 + 2\n")))
+ (send-message %kernel request)
+ (let* ((replies
+ (unfold
+(cut > <> 4)
+(lambda (_) (read-message %kernel 1))
+#{1+}#
+0)))
+ (define (type-predicate type)
+ (lambda (message)
+ (string=? (message-type message) type)))
+ (and (every message? (pk 'replies replies))
+(match (filter (type-predicate "status") replies)
+ ((busy idle)
+(and (eq? 'busy
+ (kernel-status-execution-state
+(json->kernel-status (message-content busy
+ (eq? 'idle
+ (kernel-status-execution-state
+(json->kernel-status (message-content idle
+ (equal?
+ (message-parent-header busy)
+ (message-header request))
+ (equal?
+ (message-parent-header idle)
+ (message-header request)
+(let ((input (find (type-predicate "execute_input") replies)))
+ (equal?
+(message-parent-header input)
+(message-header request)))
+(let ((reply (find (type-predicate "execute_reply") replies)))
+ (equal?
+(message-parent-header reply)
+(message-header request)))
+(let ((result
+(find (type-predicate "execute_result") replies)))
+ (and (equal?
+ (message-parent-header result)
+ (message-header request))
+ (let* ((content
+(json-string->scm (message-content result)))
+ (data (assoc-ref content "data"))
+ (text (assoc-ref data "text/plain")))
+ (string->number text
;;; (replies (#< header: #< id:
"5103841f-98e1ea45964e58d9ba214dc5_900_3" user: "username" session:
"5103841f-98e1ea45964e58d9ba214dc5" date: "2022-08-09T13:21:24.436017Z" type:
"kernel_info_reply" version: "5.3" sender: #f> parent-header: #< id:
"7b136e32ddcbe2e226edffb116a4fca9" user: "luser" session: "12345" date:
"2022-08-09T13:21:24.298532000" type: "kernel_info_request" version: "5.0"
sender: #f> metadata: "{}" content: "{\"status\": \"ok\", \"protocol_version\":
\"5.3\", \"implementation\": \"ipython\", \"implementation_version\":
\"8.2.0\", \"language_info\": {\"name\": \"python\", \"version\": \"3.9.9\",
\"mimetype\": \"text/x-python\", \"codemirror_mode\": {\"name\": \"ipython\",
\"version\": 3}, \"pygments_lexer\": \"ipython3\", \"nbconvert_exporter\":
\"python\", \"file_extension\": \".py\"}, \"banner\": \"Python 3.9.9 (main, Jan
1 1970, 00:00:01) \\nType 'copyright', 'credits' or 'license' for more
information\\nIPython 8.2.0 -- An enhanced Interactive Python. Type '?' for
help.\\n\", \"help_links\": [{\"text\": \"Python Reference\", \"url\":
\"https://docs.python.org/3.9\"}, {\"text\": \"IPython Reference\", \"url\":
\"https://ipython.org/documentation.html\"}, {\"text\": \"NumPy Reference\",
\"url\": \"https://docs.scipy.org/doc/numpy/reference/\"}, {\"text\": \"SciPy
Reference\", \"url\": \"https://docs.scipy.org/doc/scipy/reference/\"},
{\"text\": \"Matplotlib Reference\", \"url\":
\"https://matplotlib.org/contents.html\"}, {\"text\": \"SymPy Reference\",
\"url\": \"http://docs.sympy.org/latest/index.html\"}, {\"text\": \"pandas
Reference\", \"url\": \"https://pandas.pydata.org/pandas-docs/stable/\"}]};
buffers: ()> #< header: #< id:
"5103841f-98e1ea45964e58d9ba214dc5_900_4" user: "username" session:
"5103841f-98e1ea45964e58d9ba214dc5" date: "2022-08-09T13:21:24.438407Z" type:
"status" version: "5.3" sender: #vu8(107 101 114 110 101 108 46 100 53 55 102
102 101 102 53 45 48 98 102 50 45 52 97 57 102 45 97 99 50 52 45 53 53 100 54
97 97 100 102 53 56 52 97 46 115 116 97 116 117 115)> parent-header: #<
id: "7b136e32ddcbe2e226edffb116a4fca9" user: "luser" session: "12345" date:
"2022-08-09T13:21:24.298532000" type: "kernel_info_request" version: "5.0"
sender: #f> metadata: "{}" content: "{\"execution_state\": \"idle\"}" buffers:
()> #< header: #< id:
"5103841f-98e1ea45964e58d9ba214dc5_900_5" user: "username" session:
bug#43579: Problem still present
After removing the patch that works around this problem in fplll
with commit 5dec5f65ec3c7371dde309a101b85b930e423a46, I noticed that it
actually still does occur.
We used to have the problem with gcc-toolchain@10.2 that with test.cpp equal to
#include
int main() {
std::fesetround (FE_TONEAREST);
return 1;
}
the compilation "g++ test.cpp" fails. With gcc-toolchain@10.3 it actually
succeeds.
But with gcc-toolchain@11.3 or @12.1 it fails again.
Indeed,
/gnu/store/bxh206gz379wkn8cvb2ghlkvpqgwfd2v-gcc-toolchain-10.3.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h
contains in line 1572:
#define _GLIBCXX_USE_C99_FENV_TR1 1
whereas
/gnu/store/c17nwiafb01pig2r3mjm1jznfpas61np-gcc-toolchain-12.1.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h
contains in line 1759:
/* #undef _GLIBCXX_USE_C99_FENV_TR1 */
Did we change anything between 10.2 and 10.3, and then revert it with
11.3? Or is it a transient thing that depends on some random ordering of
include files? The latter looks more plausible, since the change from
10.2 and 10.3 really just changes the version and the hash.
What can we do?
Andreas
bug#54929: Acknowledgement (./pre-inst-env recompiling files)
The mysterious problem disappeared mysteriously after making a new git checkout and bootstrapping. Closing the bug. Andreas
bug#54928: Libtool 2.4.6 vs. 2.4.7
Am Thu, Apr 14, 2022 at 02:07:02PM +0200 schrieb Andreas Enge: > I had already removed it, and the problem persisted. I suppose that > autoreconf or configure created it again in version 2.4.6, and during > make my version 2.4.7 was used instead. Actually it is "configure", in my case by calling config/ltmain.sh. The solution is to remove config/ltmain.sh (actually I removed the complete config/ subdirectory) and to call "autoreconf -fi" to recreate it (which also overwrites INSTALL...). So these are indeed stale files from autotools, somewhat difficult to spot, since "make distclean" is not enough to remove them. Anyway, this is not related to Guix, and I am closing the bug. Andreas
bug#54928: Libtool 2.4.6 vs. 2.4.7
Am Thu, Apr 14, 2022 at 01:29:46PM +0200 schrieb Liliana Marie Prikler: > libtool causes at least 13802 (mere two thirds of all our packages), so > one might want to ensure that there are no gratuitous bumps when making > new versions of it available :) Quite understandable, but if then the new version is added, but unusable, it can also not be tested. > > I have installed libtool@2.4.7 into my profile > That is a mistake. > > as well as a number of other development tools > Probably also a mistake. Could you elaborate why? If you work on a project, it seems necessary to install development tools (gcc-toolchain, autoconf, automake, make, texinfo, ...). > I think the problem is caused in the ../libtool symlink, which is > probably not updated to reflect your installation. This is a known > issue with stale build files, which also happens if you garbage-collect > stuff. distclean or maintainerclean should solve your issue. Or you > might just as well delete the symlink manually :) I had already removed it, and the problem persisted. I suppose that autoreconf or configure created it again in version 2.4.6, and during make my version 2.4.7 was used instead. Andreas
bug#54929: ./pre-inst-env recompiling files
Recently even after a ./bootstrap ./configure --localstatedir=/var --prefix=/usr/local/guix make any command prefixed by ./pre-inst-env starts by recompiling a bunch of scheme files with the following messages: ;;; WARNING: loading compiled file /home/andreas/Programme/guix/guix/build/utils.go failed: ;;; In procedure load-thunk-from-memory: incompatible bytecode version ;;; note: source file /home/andreas/Programme/guix/guix/build/utils.scm ;;; newer than compiled /run/current-system/profile/lib/guile/3.0/site-ccache/guix/build/and so on. Then it used to fail, but on my last run it succeeded in the end. However, the next ./pre-inst-env executes the same recompilation dance. Andreas
bug#54928: Libtool 2.4.6 vs. 2.4.7
Hello, is there a good reason to have added libtool-2.4.7 without it replacing the libtool variable (at version 2.4.6)? I have installed libtool@2.4.7 into my profile, as well as a number of other development tools, and apparently both libtool versions are now used and are colliding when doing autoreconf -vf && ./configure && make in my project: make[2]: Verzeichnis „/home/enge/Programme/paritwine/git/src“ wird betreten /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -g -O2 -MT conversions.lo -MD -MP -MF .deps/conversions.Tpo -c -o conversions.lo conversions.c libtool: Version mismatch error. This is libtool 2.4.6, but the libtool: definition of this LT_INIT comes from libtool 2.4.7. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6 libtool: and run autoconf again. I can solve the problem by downgrading to libtool@2.4.6 in my profile, but would argue that this defeats the purpose of adding the new variable at all. Andreas
bug#36389: Nginx and certbot
Hello, I am also experiencing problems with setting up nginx and certbot, but I think it is more nginx that is to blame. After reconfiguring and restarting nginx, it is still running with the old configuration. Only rebooting solves the problem for me. Here is what it looks like (everything as root): $ ps -ef | grep nginx root 2821 1 0 17:03 ?00:00:00 nginx: master process /gnu/store/bdhfqs7sx3mal6pzz8z00hw4cpn5dj7x-nginx-1.21.4/sbin/nginx -c /gnu/store/q7bwm828r8y88sfs395n04bi8s6b7zwl-nginx.conf -p /var/run/nginx $ guix system reconfigure ... nginx: configuration file /gnu/store/clq2yshkq3gxpcqa6d54m8qif8i37kl9-nginx.conf test is successful $ herd restart nginx; ps -ef | grep nginx root 2835 1 0 17:12 ?00:00:00 nginx: master process /gnu/store/bdhfqs7sx3mal6pzz8z00hw4cpn5dj7x-nginx-1.21.4/sbin/nginx -c /gnu/store/q7bwm828r8y88sfs395n04bi8s6b7zwl-nginx.conf -p /var/run/nginx Notice that it is still running the old, q7b... config file! $ reboot $ ps -ef | grep nginx root 188 1 0 17:13 ?00:00:00 nginx: master process /gnu/store/bdhfqs7sx3mal6pzz8z00hw4cpn5dj7x-nginx-1.21.4/sbin/nginx -c /gnu/store/clq2yshkq3gxpcqa6d54m8qif8i37kl9-nginx.conf -p /var/run/nginx Now the new, clq... config file is used! So somehow nginx appears to memorise its previous configuration file even when the service is stopped. The problem can be solved by rebooting after each web server reconfiguration, but this is of course not very comfortable. Andreas
bug#36389: Nginx and certbot
Actually this seems to be a thing of the service, not nginx itself. When I stop the service with the old configuration file, manually run /gnu/store/bdhfqs7sx3mal6pzz8z00hw4cpn5dj7x-nginx-1.21.4/sbin/nginx -p /var/run/nginx -c new_configuration_file kill the process, and "herd restart nginx", the herd service uses the old configuration file again. Andreas
bug#31719: icedtea-3 binaries contain references to icedtea-2
Am Tue, Apr 20, 2021 at 11:24:59AM +0200 schrieb Ludovic Courtès: > I think we can close it. I have the attached improvements that I can > commit to ‘staging’ (or ‘core-updates’?) to avoid another rebuild. I think they can easily go to master; the time for rebuilds is not very high, I just ran into trouble since I had little space left on the device so some manual intervention was required to gc intermediate packages. There also seem to be very few dependencies if "guix refresh -l openjdk" is to be trusted. Andreas
bug#31719: Chains of dependencies getting longer
Hello, Am Mon, Apr 19, 2021 at 08:18:03PM +0200 schrieb Ricardo Wurmus: > I just looked over the patch, and while I’m not sure it’s the best way to do > things (matching “openjdk” or “icedtea” in the package name seems a little > error prone in the presence of packages whose names might include these > strings), but I think it’s a definite improvement. I just pushed the patch to master. Thanks a lot, Carlo! It has definitely solved my problem: I can now compile an Android project after downloading a single openjdk package. It would be nice if someone else could close the bug if you feel the problem is solved, or otherwise leave it open to discuss further possible improvements. Andreas
bug#31719: Chains of dependencies getting longer
Hello Carlo, Am Sat, Apr 17, 2021 at 07:38:11PM +1000 schrieb Carlo Zancanaro: > On Sat, Apr 17 2021, Carlo Zancanaro wrote: > > I'm in the process of rebuilding Java from icedtea-8 upwards to check, > > I've now built and checked the JRE/JDKs from 10 to 14, and none of them > retain a reference to any other JRE/JDK according to "guix gc --references". thanks a lot for your patch! I am not very knowledgeable on this matter, but after updating my system am right now once again bitten by the problem: The following derivations would be built: /gnu/store/0bxpgqps79007jky37dwzgm08wlsgj02-openjdk-10.46.drv /gnu/store/2xwsm2plrbk7l4510hrqp9y7b5vv9v5j-module-import-compiled.drv 1683.5 MB would be downloaded: /gnu/store/0gzv5208m2prqbnsqdffcnz7mwfqa684-openjdk-10.46.tar.xz /gnu/store/5g6ng9a2ifgrv57mzdaysf2lq9rkixxk-make-4.2.1 /gnu/store/243algr6h60j46spn5dqhjc4mhkd0a0p-libelf-0.8.13 /gnu/store/crc4cgsdls10isy8prjdddvsp21wafx6-openjdk-9.181-jdk /gnu/store/6amc3php7qyqxagak5xnmv2k81wm7w26-openjdk-9.181 /gnu/store/bms6jg5qwn927qmbh9xi30ifhsxxdazq-openjdk-11.28-jdk /gnu/store/lylv6ng5gwqpi930c6y7sglh2k8byjn6-openjdk-11.28 /gnu/store/z27mhqpylrbmwkcgrb100p6jbflxhq5h-openjdk-12.33-jdk /gnu/store/xz500ry11dihwn9kij1kmzkci1lmnqjf-openjdk-13.0-jdk /gnu/store/a1s66hlj10nkkcxlk6s2dzq4iip4mh4k-openjdk-14.0-doc /gnu/store/cyssia0a5lh8mb5czd7155y7sl31aryl-openjdk-14.0-jdk /gnu/store/630lvja8vak1bkf9vsbbh29cp79j4pwp-openjdk-14.0 guix build: warning: at least 5922.4 MB needed but only 3539.4 MB available in /gnu/store So I would have to download lots of openjdk and even build one in the middle of the chain myself. So unless someone else objects, I intend to apply the patch, build the latest openjdk, and push it if everything goes well. Notice that the original problem reported by Ricardo seems to have been fixed independently - "guix build icedtea" only downloads icedtea@3, and not @2 on current master. Thanks, Andreas
bug#47448: lualatex doesn't find libzzip-0.so.13 (easy bug?)
Hello Sergiu, Am Sat, Mar 27, 2021 at 08:22:30PM +0100 schrieb Sergiu Ivanov: > I have trouble running lualatex from the TeX Live distribution (package > texlive) : > $ lualatex > /home/scolobb/.guix-profile/bin/lualatex: error while loading shared > libraries: libzzip-0.so.13: cannot open shared object file: No such file or > directory I confirm the bug, and am forwarding it to the bugtracker. lualatex is a wrapped binary, and the following shows the problem: $ ldd $(guix build texlive-bin)/bin/luatex ... libzzip-0.so.13 => not found > I installed the zziplib package which brings in libzzip.so.13, but not > libzzip-0.so.13. Indeed this seems to be the problem, and I suspect it is happening in the zziplib package. Its version is 0.13.72, but the soname versions are 13.0.72, which already suggests that there is some confusion happening. Regardless, part of the version number should not appear before the "so" in libzzip-0.so.13. Hm, the following looks correct, issued from a profile containing zziplib: $ pkg-config --libs zziplib -L/gnu/store/fx0cdzzppd8jc09sianbq6gl1h7mxx3x-zziplib-0.13.72/lib -L/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11/lib -lzzip -lz So it might be a problem with texlive-bin instead. Andreas
bug#47315: Inkscape is missing imagemagick
Am Mon, Mar 22, 2021 at 07:16:28AM -0400 schrieb Julien Lepiller: > I think this has already been fixed a few days ago on master. Have you tried > pulling and upgrading inkscape again? Indeed, closing this bug, thanks! The discussion on grafts and version numbers is continued here: https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00432.html Andreas
bug#47315: Inkscape is missing imagemagick
Hello, $ guix environment --ad-hoc inkscape [env]$ inkscape /tmp/guixtile.svg /gnu/store/7bs616gpgnmj4g5d0g88dkphd1gqbicy-inkscape-1.0.2/bin/.inkscape-real: error while loading shared libraries: libMagickCore-6.Q16.so.6: cannot open shared object file: No such file or directory The same happens when I add imagemagick of imagemagick@6.9.11-48 or imagemagick@6.9.12-2g to the environment. But maybe the older imagemagick is not even built? $ guix build imagemagick@6.9.11-48 /gnu/store/m794l5c82clc3xa1lkg30pr96y9a60m3-imagemagick-6.9.12-2g-doc /gnu/store/nnw0jnxpcf5bfaxbc3c5dkw87j13bq94-imagemagick-6.9.12-2g Notice the version mismatch! $ guix build imagemagick@6.9.11 guix build: error: imagemagick: package not found for version 6.9.11 It should work to just specify a version prefix, right? $ guix describe Generation 29 Mar 11 2021 12:17:47(current) guix 500189b repository URL: https://git.savannah.gnu.org/git/guix.git commit: 500189b4d2f1e3a2d4ee8ab73d889e3d8ac70632 This is probably due to commit 82e887ba48c2ba91b17aa9b6b17501e3e0ef4aef Author: Léo Le Bouter Date: Tue Mar 9 23:02:51 2021 +0100 gnu: imagemagick: Update to 6.9.12-2 [security fixes]. * gnu/packages/imagemagick.scm (imagemagick/fixed): New variable. (imagemagick)[replacement]: Graft. I am not familiar with replacements, but it appears they force an update. This should not happen together with a library soname change; effectively, the result is a removal of the previous imagemagick package from Guix together with the addition of an unrelated new one, that cannot replace the previous one, but just happens to be a different program sharing the same name. So in this case, the only option is to upgrade the imagemagick package and to recompile all its dependents. Andreas
bug#47007: dcb640f02b broke guix environment --container
Hello, Am Wed, Mar 10, 2021 at 12:25:05PM +0100 schrieb Ludovic Courtès: > Could you instead try the latest patch? > https://issues.guix.gnu.org/47007#6 it looks like my reply was missed, I tried this patch, and it solves the problem for me, as for Jelle. So please push. Thanks! Andreas
