bug#65240: pdfarranger can't be installed
pdfarranger can't be installed ## Steps to reproduce The following steps assume you are using Guix System with GNOME desktop. $ guix package -i pdfarranger ## Expected result pdfarranger can be installed ## Unexpected result pdfarranger can't be installed $ guix package -i pdfarranger Le paquet suivant sera installé : pdfarranger 1.9.2 substitute: mise à jour des substituts depuis « https://ci.guix.gnu.org »... 100.0 % substitute: mise à jour des substituts depuis « https://bordeaux.guix.gnu.org »... 100.0 % La dérivation suivante sera compilée : /gnu/store/zmm6wgj12ap7qjqmjw0ji1xpmr27wa4m-pdfarranger-1.9.2.drv construction de /gnu/store/zmm6wgj12ap7qjqmjw0ji1xpmr27wa4m- pdfarranger-1.9.2.drv... | phase « sanity-check »builder for `/gnu/store/zmm6wgj12ap7qjqmjw0ji1xpmr27wa4m-pdfarranger-1.9.2.drv' failed with exit code 1 la compilation de /gnu/store/zmm6wgj12ap7qjqmjw0ji1xpmr27wa4m- pdfarranger-1.9.2.drv a échoué Vous trouverez le journal de compilation dans « /var/log/guix/drvs/zm/m6wgj12ap7qjqmjw0ji1xpmr27wa4m-pdfarranger- 1.9.2.drv.gz ». guix package: erreur : build of `/gnu/store/zmm6wgj12ap7qjqmjw0ji1xpmr27wa4m-pdfarranger-1.9.2.drv' failed full log in attachment ## System information GNOME 42.4 Guix system 64 bit / X11 guix 4547bc6 URL du dépôt : https://git.savannah.gnu.org/git/guix.git branche : master commit : 4547bc6fa3142dca77f7fc912368aeff31bd6e53 m6wgj12ap7qjqmjw0ji1xpmr27wa4m-pdfarranger-1.9.2.drv.gz Description: application/gzip
bug#65236: package/inherit records lack location for version field
Hello Guix, In the current code base, if you do: --8<---cut here---start->8--- (use-modules (guix package) (gnu packages qt)) (package-field-location qtbase 'version) => #f --8<---cut here---end--->8--- It returns #f. This means 'guix refresh -u base' fails like: --8<---cut here---start->8--- qtbase: updating from version 6.3.2 to version 6.5.2... --8<---cut here---end--->8--- Now, package/inherit is bogus here, but the problems remains for other packages, such as zxing-cpp-1.2. -- Thanks, Maxim
bug#65231: refresh: Exception in manifest is silenced, cause all packages to be selected
Hi Guix, Consider the following manifest: --8<---cut here---start->8--- (use-modules (guix packages) (guix profiles) (guix utils) (gnu packages)) (define %qt-major-version "6") (manifest (map package->manifest-entry (fold-packages (lambda (package lst) (let ((uri (and=> (package-source package) (lambda (x) (and (origin? x) (origin-uri x)) (if (and uri (string? uri) (string-prefix? "mirror://qt/" uri) (= %qt-major-version (version-major (package-version package (cons package lst) lst))) '( --8<---cut here---end--->8--- There's a subtle bug in it, which is the '=' function which is used instead of 'string=?'. I'd expect 'guix refresh -m qt-manifest.scm' to let this exception interrupt execution, but instead it proceeds to refresh all (?) the packages (taking a long time to compute). At the REPL, the error is reported as: --8<---cut here---start->8--- ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure =: Wrong type argument in position 1: "6" --8<---cut here---end--->8--- -- Thanks, Maxim
bug#31611: Add a property in packages to refresh to a specific version
Hi Hartmut, Hartmut Goebel writes: > `guix refresh` always fetches the newest version of packages. This might > not be desired in all cases. E.g. one might want to keep some still > supported "major" upstream-version and not yet update to the next > "major" version. > > Ludo suggested to add a property in packages that would instruct > updaters to restrict the version search space to a given regexp. > > Rational: Example: KDE Plasma 5 has 5.12 as long-term-support (LTS) > version, while 5.14 has already being released. Do easy maintenance of > dependent packages, sticking to 5.12.x micht be desired. > > Original discussion: > https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00055.html It's now possible to refresh to a specific version with the '=' syntax, as documented in 'info "(guix)Invoking guix refresh"': E.g.: --8<---cut here---start->8--- guix refresh qtbase@5=5.15.10 -> qtbase would be upgraded from 5.15.8 to 5.15.10 --8<---cut here---end--->8--- Closing! -- Thanks, Maxim
bug#65225: ‘guix shell --system=ALIEN’ builds for both systems
Oh OK. the code that's injecting a spurious extra ‘(system . (%current-system))’ that's causing these double builds is not actually the problem. Instead, the profile hooks are unconditionally built for the host's (%current-system). Forcing them to match ‘--system=’ does the trick. Simple™! Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
bug#65225: [PATCH] environment: Build the profile for the requested system.
Previously, ‘--system=’ did not affect profile hooks, meaning that all packages would be built for both the host and requested systems. * guix/scripts/environment.scm (guix-environment*): Parameterize %current-system to match the requested ‘--system=’. Reported by ekaitz in #guix. --- guix/scripts/environment.scm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm index 9712389842..27f7e53549 100644 --- a/guix/scripts/environment.scm +++ b/guix/scripts/environment.scm @@ -1146,7 +1146,8 @@ (define (guix-environment* opts) (warning (G_ "no packages specified; creating an empty environment~%"))) ;; Use the bootstrap Guile when requested. -(parameterize ((%graft? (assoc-ref opts 'graft?)) +(parameterize ((%current-system system) + (%graft? (assoc-ref opts 'graft?)) (%guile-for-build (and store-needed? (package-derivation base-commit: 9e71d4fd6b3893ae87cb079b57d7a8fe6e9e7914 -- 2.41.0
bug#63726: time-machine without options does not get the latest commit
Hi Konrad & Simon, I had forgotten about this issue (my apologies…) and stumbled upon it again recently, which led me to approach it a bit differently: https://issues.guix.gnu.org/65229 Let me know what you think! Thanks, Ludo’.
bug#26877: building fonts: fontcache must be updated regulary
Hello, 宋文武 writes: [...] > Hello, I think we can close this now, since this commit: > > commit 6f12880a76a6c91058718d15845f8b9d9b529a5a > Author: Sarah Morgensen mgsn.dev> > Date: Fri Jun 18 17:52:05 2021 -0700 > > gnu: fontconfig: Use (locally) deterministic caching > > Make fontconfig use directory contents rather than modification time to > determine cache validity (by pretending that mtime is broken). > > There is no need to run 'fc-cache' manually, and applications just need > close/restart to use newly install fonts (also manual run here doesn't > remove the need of restart). Excellent, I had forgotten about that commit. Thanks to Sarah for fixing the issue! Closing. -- Thanks, Maxim
bug#64760: make check fails on 182be30fb1a8b847c30492462ec22c08ec7a9849
Ludovic Courtès writes:
Hey!
> Janneke Nieuwenhuizen skribis:
>
>> test-name: gc-roots, initial
>> location: /home/janneke/src/guix/master/tests/store-roots.scm:33
>> source:
>> + (test-equal
>> + "gc-roots, initial"
>> + (list (string-append %state-directory "/profiles"))
>> + (begin
>> + (delete-file-recursively
>> + (string-append %state-directory "/profiles"))
>> + (gc-roots)))
>> expected-value: ("/home/janneke/src/guix/master/test-tmp/var/9734/profiles")
>> actual-value: #f
>> actual-error:
>> + (system-error
>> + "lstat"
>> + "~A: ~S"
>> + ("No such file or directory"
>> +"/home/janneke/src/guix/master/test-tmp/var/9734/profiles")
>> + (2))
>> result: FAIL
>
> Hmm, this test passes for me.
Well, what would you know, it passes for me too...
> Could you get a backtrace so we see where the ‘lstat’ exception comes
> from? (To get the backtrace, you can raise (begin …) out of
> ‘test-equal’ and then “make check TESTS=tests/store-root.scm”.)
...as I found out after trying this. I had my source tree configured
using --disable-daemon --disable-nls (a nifty feature that I encountered
only recently)...and then this (patched) test fails. After
reconfiguring, all is well.
Greetings,
Janneke
--
Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
bug#65225: ‘guix shell --system=ALIEN’ builds for both systems
Oh, OK.
Parts of scripts/shell.scm (and perhaps environment.scm) assume that
$ guix build --system={x86_64,riscv64}-linux foo
is equivalent to
$ guix build --system=riscv64-linux foo
It's not. This includes and causes things like commit
9c513303156b418567b9d2cde9f8df66190051ac. There's a lot of fast & loose
assoc-reffing going on here that makes me nervous.
Anyway, I'll get me to a PC and then fix the code that's injecting a
spurious extra ‘(system . (%current-system))’ that's causing these
double builds. Simple™.
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
bug#65225: ‘guix shell --system=ALIEN’ builds for both systems
Hi, ekaitz noticed this when building a mes-derived package that fails on x86_64. Here's a reproducer that uses upstream Guix: $ guix shell --system=riscv64-linux drawterm --no-grafts --rebuild-cache --dry-run | grep drv$ /gnu/store/4c02fgswkbldys93w4vgj0gwax2ly4bh-profile.drv $ guix build --dry-run /gnu/store/4c02fgswkbldys93w4vgj0gwax2ly4bh-profile.drv | grep drawterm /gnu/store/mkxyhjq117wdalc0gbz4468blqxih1kn-drawterm-20210628-1.c97fe46 /gnu/store/h8dk35aw2n8rj1hki6dkdrknfly26vq8-drawterm-20210628-1.c97fe46 /gnu/store/fl4iimlcdnlkarjm8m6z3392wss6b8yr-drawterm-20210628-1.c97fe46.drv → /gnu/store/mkxyhjq117wdalc0gbz4468blqxih1kn-drawterm-20210628-1.c97fe46 is riscv64-linux. /gnu/store/9a1pji59hzacrmpb65nk3pp3m01niqf3-drawterm-20210628-1.c97fe46.drv → /gnu/store/h8dk35aw2n8rj1hki6dkdrknfly26vq8-drawterm-20210628-1.c97fe46 is x86_64-linux. Eventually the ‘correct’ riscv64 drawterm ends up in the shell, but Guix should never have built the x86_64 version. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
bug#25865: xinit does not allow non-root startx
Alex Vestgaard writes:
> Hi,
>
> xinit suffers from an upstream bug, which does not allow non-root X to be run
> without a display manager via startx or xinitrc. Several
> people have reported this on #guix.
>
> Currently if one runs startx as non-root, X reports:
> (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)
>
> This bug is further discussed in [1]. Redhat seems to have a patch [2], but
> it is unclear to me whether this has been applied upstream.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/xinit/+bug/1562219
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1203780
Hello, for 'xinit', you can create a '~/.xserverrc` file with:
tty=$(tty)
tty=${tty#/dev/tty}
X vt${tty}
then it will run a non-root X from current tty. Also 'sx' works fine.
Closing now..
bug#26877: building fonts: fontcache must be updated regulary
Maxim Cournoyer writes: > Hello, > > l...@gnu.org (Ludovic Courtès) writes: > >> Hi, >> >> Mark H Weaver skribis: >> >>> The usual Guix way to handle things like this is to arrange for the font >>> cache to be part of the profile, and to create a profile hook that >>> creates the cache from all of the built packages included within. >> >> The problem is that the cache should be mutable so that one can run >> “fc-cache -f” after having dropped files in ~/.local/share/fonts, for >> instance. >> >> That said, quite surprisingly, I think I never had to run ‘fc-cache’ >> except in the situation above. > > I've never had to do this in years, although I don't use "loose" fonts > manually installed under ~/.local/share/fonts. > > Should we close the issue? Our fontconfig package now honors fonts > found under XDG_DATA_DIRS, and it seems to just work. Hello, I think we can close this now, since this commit: commit 6f12880a76a6c91058718d15845f8b9d9b529a5a Author: Sarah Morgensen mgsn.dev> Date: Fri Jun 18 17:52:05 2021 -0700 gnu: fontconfig: Use (locally) deterministic caching Make fontconfig use directory contents rather than modification time to determine cache validity (by pretending that mtime is broken). There is no need to run 'fc-cache' manually, and applications just need close/restart to use newly install fonts (also manual run here doesn't remove the need of restart).
bug#18640: fontconfig's cache is not refreshed automatically
Hello, I believe this issue had been fixed by: commit 6f12880a76a6c91058718d15845f8b9d9b529a5a Author: Sarah Morgensen Date: Fri Jun 18 17:52:05 2021 -0700 gnu: fontconfig: Use (locally) deterministic caching Make fontconfig use directory contents rather than modification time to determine cache validity (by pretending that mtime is broken). Closing.
bug#65219: OpenFOAM is not reproducible
The ‘openfoam-org’ and ‘openfoam-com’ packages are not reproducible:
--8<---cut here---start->8---
$ ./pre-inst-env guix challenge openfoam-{org,com}
/gnu/store/nqv35ydmqmxazv33m84gf1130m10n8ig-openfoam-com-2212 contents differ:
no local build for
'/gnu/store/nqv35ydmqmxazv33m84gf1130m10n8ig-openfoam-com-2212'
https://ci.guix.gnu.org/nar/lzip/nqv35ydmqmxazv33m84gf1130m10n8ig-openfoam-com-2212:
1wbs1acacshi4swhrxjkwm4jppc0bavsz97vi7y2vkn7nv8rj0bl
https://bordeaux.guix.gnu.org/nar/lzip/nqv35ydmqmxazv33m84gf1130m10n8ig-openfoam-com-2212:
033jd4y456jfnxz9mavybg520y6ix0fmd7a10k5l97mnljkclzwc
differing files:
/share/OpenFOAM/build/linux64GccDPInt32Opt/applications/solvers/heatTransfer/chtMultiRegionFoam/chtMultiRegionTwoPhaseEulerFoam/chtMultiRegionTwoPhaseEulerFoam.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/applications/solvers/multiphase/reactingMultiphaseEulerFoam/reactingMultiphaseEulerFoam.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/applications/solvers/multiphase/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/src/functionObjects/phaseSystems/sizeDistribution/sizeDistribution.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseCompressibleTurbulenceModels/kineticTheoryModels/kineticTheoryModel/kineticTheoryModel.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseCompressibleTurbulenceModels/phasePressureModel/phasePressureModel.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseCompressibleTurbulenceModels/twoPhaseCompressibleTurbulenceModels.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseSystem/diameterModels/IATE/IATE.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseSystem/diameterModels/IATE/IATEsources/phaseChange/phaseChange.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseSystem/twoPhaseSystem.C.dep
/share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseSystem/twoPhaseSystems.C.dep
/share/OpenFOAM/src/phaseSystemModels/reactingEuler/multiphaseSystem/lnInclude/exponential.C
/share/OpenFOAM/src/phaseSystemModels/reactingEuler/multiphaseSystem/lnInclude/exponential.H
/share/OpenFOAM/src/phaseSystemModels/reactingEuler/multiphaseSystem/lnInclude/linear.C
/share/OpenFOAM/src/phaseSystemModels/reactingEuler/multiphaseSystem/lnInclude/linear.H
/gnu/store/bsllqx0zbv9353psmfildnvblg619kz3-openfoam-org-10.20230119 contents
differ:
no local build for
'/gnu/store/bsllqx0zbv9353psmfildnvblg619kz3-openfoam-org-10.20230119'
https://ci.guix.gnu.org/nar/lzip/bsllqx0zbv9353psmfildnvblg619kz3-openfoam-org-10.20230119:
0x7q256p489y5hnlq5i44qbl59bj1bwhnyzbm616nrqq95l3qasz
https://bordeaux.guix.gnu.org/nar/lzip/bsllqx0zbv9353psmfildnvblg619kz3-openfoam-org-10.20230119:
1yc4sfakn5n78lgdaa4jds6bg2mhhblw15p6j2z1269hb8jz8wvg
differing files:
/share/OpenFOAM/applications/utilities/postProcessing/graphics/PVReaders/Make/linux64GccDPInt32Opt/CMakeCache.txt
/share/OpenFOAM/applications/utilities/postProcessing/graphics/PVReaders/Make/linux64GccDPInt32Opt/CMakeFiles/3.24.2/CMakeSystem.cmake
/share/OpenFOAM/applications/utilities/postProcessing/graphics/PVReaders/Make/linux64GccDPInt32Opt/CMakeFiles/CMakeOutput.log
/share/OpenFOAM/test/IO/fileHandler/log.blockMesh
/share/OpenFOAM/test/IO/fileHandler/log.decomposePar
/share/OpenFOAM/test/IO/fileHandler/log.decomposePar.collated
/share/OpenFOAM/test/IO/fileHandler/log.decomposePar.uncollated
/share/OpenFOAM/test/IO/fileHandler/log.foamFormatConvert
/share/OpenFOAM/test/IO/fileHandler/log.foamFormatConvert.uncollated
/share/OpenFOAM/test/IO/fileHandler/log.particleFoam
/share/OpenFOAM/test/IO/fileHandler/log.particleFoam.collated
/share/OpenFOAM/test/IO/fileHandler/log.particleFoam.multiCollated
/share/OpenFOAM/test/IO/fileHandler/log.particleFoam.uncollated
/share/OpenFOAM/test/IO/fileHandler/log.particleFoam.uncollated_from_multiCollated
/share/OpenFOAM/test/IO/fileHandler/log.reconstructPar
/share/OpenFOAM/test/IO/fileHandler/log.reconstructPar.collated
/share/OpenFOAM/test/IO/fileHandler/log.reconstructPar.multiCollated
/share/OpenFOAM/test/IO/fileHandler/machineA/fileHandler/log.particleFoam.distributed_multiCollated
/share/OpenFOAM/test/fvMeshTools/cavity/0.005/polyMesh/faces
/share/OpenFOAM/test/fvMeshTools/cavity/0.005/polyMesh/neighbour
/share/OpenFOAM/test/fvMeshTools/cavity/0.005/polyMesh/owner
/share/OpenFOAM/test/fvMeshTools/cavity/0.005/polyMesh/points
/share/OpenFOAM/test/fvMeshTools/cavity/0.01/polyMesh/faces
/share/OpenFOAM/test/fvMeshTools/cavity/0.01/polyMesh/neighbour
