bug#56667: test failures tests/channels.scm and tests/texlive.scm
Ludovic Courtès writes: > Hi, > > Chris Keschnat skribis: > >> FAIL: tests/texlive >> === >> >> (package (inherit (simple-texlive-package "texlive-texsis" (list >> "bibtex/bst/texsis/" "doc/man/man1/" "doc/otherformats/texsis/base/" >> "tex/texsis/base/" "tex/texsis/config/") (base32 >> "17ckkii656y2g1h5h8lc1bsy10a0bfgnsakhxii4hxfmvrfvc097") #:trivial? >> #t)) (version "59745") (propagated-inputs (list texlive-cm >> texlive-hyphen-base texlive-knuth-lib texlive-plain texlive-tex)) >> (home-page "https://www.tug.org/texlive/;) (synopsis "Plain TeX >> macros for Physicists") (description "TeXsis is a TeX macro package >> which provides useful features for typesetting\nresearch papers and >> related documents. For example, it includes support\nspecifically >> for: Automatic numbering of equations, figures, tables >> and\nreferences; Simplified control of type sizes, line spacing, >> footnotes, running\nheadlines and footlines, and tables of contents, >> figures and tables; Specialized\ndocument formats for research >> papers, preprints and \"e-prints\", conference\nproceedings, theses, >> books, referee reports, letters, and memoranda; Simplified\nmeans of >> constructing an index for a book or thesis; Easy to use double >> column\nformatting; Specialized environments for lists, theorems and >> proofs, centered or\nnon-justified text, and listing computer code; >> Specialized macros for easily\nconstructing ruled tables. TeXsis >> was originally developed for physicists, but\nothers may also find >> it useful. It is completely compatible with Plain TeX.") (license >> lppl)) >> >> ;;; (fail (package (inherit (simple-texlive-package "texlive-texsis" >> (list "bibtex/bst/texsis/" "doc/man/man1/" >> "doc/otherformats/texsis/base/" "tex/texsis/base/" >> "tex/texsis/config/") (base32 >> "17ckkii656y2g1h5h8lc1bsy10a0bfgnsakhxii4hxfmvrfvc097") #:trivial? >> #t)) (version "59745") (propagated-inputs (list texlive-cm >> texlive-hyphen-base texlive-knuth-lib texlive-plain texlive-tex)) >> (home-page "https://www.tug.org/texlive/;) (synopsis "Plain TeX >> macros for Physicists") (description "TeXsis is a TeX macro package >> which provides useful features for typesetting\nresearch papers and >> related documents. For example, it includes support\nspecifically >> for: Automatic numbering of equations, figures, tables >> and\nreferences; Simplified control of type sizes, line spacing, >> footnotes, running\nheadlines and footlines, and tables of contents, >> figures and tables; Specialized\ndocument formats for research >> papers, preprints and \"e-prints\", conference\nproceedings, theses, >> books, referee reports, letters, and memoranda; Simplified\nmeans of >> constructing an index for a book or thesis; Easy to use double >> column\nformatting; Specialized environments for lists, theorems and >> proofs, centered or\nnon-justified text, and listing computer code; >> Specialized macros for easily\nconstructing ruled tables. TeXsis >> was originally developed for physicists, but\nothers may also find >> it useful. It is completely compatible with Plain TeX.") (license >> lppl)) #f) >> test-name: texlive->guix-package >> location: /home/ck/tmp/guix/tests/texlive.scm:161 > > Actually I’m now experiencing it, and I think it’s caused by commit > be7b314f3fe22273e935accac22f313e44d3d970, which changes the ‘texlive’ > importer. My apologies. Fixed with commit c9a37f57cbb18be01436a709cbdd96ffea41caf5. -- Ricardo
bug#56667: test failures tests/channels.scm and tests/texlive.scm
Hi, Chris Keschnat skribis: > FAIL: tests/texlive > === > > (package (inherit (simple-texlive-package "texlive-texsis" (list > "bibtex/bst/texsis/" "doc/man/man1/" "doc/otherformats/texsis/base/" > "tex/texsis/base/" "tex/texsis/config/") (base32 > "17ckkii656y2g1h5h8lc1bsy10a0bfgnsakhxii4hxfmvrfvc097") #:trivial? #t)) > (version "59745") (propagated-inputs (list texlive-cm texlive-hyphen-base > texlive-knuth-lib texlive-plain texlive-tex)) (home-page > "https://www.tug.org/texlive/;) (synopsis "Plain TeX macros for Physicists") > (description "TeXsis is a TeX macro package which provides useful features > for typesetting\nresearch papers and related documents. For example, it > includes support\nspecifically for: Automatic numbering of equations, > figures, tables and\nreferences; Simplified control of type sizes, line > spacing, footnotes, running\nheadlines and footlines, and tables of contents, > figures and tables; Specialized\ndocument formats for research papers, > preprints and \"e-prints\", conference\nproceedings, theses, books, referee > reports, letters, and memoranda; Simplified\nmeans of constructing an index > for a book or thesis; Easy to use double column\nformatting; Specialized > environments for lists, theorems and proofs, centered or\nnon-justified text, > and listing computer code; Specialized macros for easily\nconstructing ruled > tables. TeXsis was originally developed for physicists, but\nothers may also > find it useful. It is completely compatible with Plain TeX.") (license lppl)) > > ;;; (fail (package (inherit (simple-texlive-package "texlive-texsis" (list > "bibtex/bst/texsis/" "doc/man/man1/" "doc/otherformats/texsis/base/" > "tex/texsis/base/" "tex/texsis/config/") (base32 > "17ckkii656y2g1h5h8lc1bsy10a0bfgnsakhxii4hxfmvrfvc097") #:trivial? #t)) > (version "59745") (propagated-inputs (list texlive-cm texlive-hyphen-base > texlive-knuth-lib texlive-plain texlive-tex)) (home-page > "https://www.tug.org/texlive/;) (synopsis "Plain TeX macros for Physicists") > (description "TeXsis is a TeX macro package which provides useful features > for typesetting\nresearch papers and related documents. For example, it > includes support\nspecifically for: Automatic numbering of equations, > figures, tables and\nreferences; Simplified control of type sizes, line > spacing, footnotes, running\nheadlines and footlines, and tables of contents, > figures and tables; Specialized\ndocument formats for research papers, > preprints and \"e-prints\", conference\nproceedings, theses, books, referee > reports, letters, and memoranda; Simplified\nmeans of constructing an index > for a book or thesis; Easy to use double column\nformatting; Specialized > environments for lists, theorems and proofs, centered or\nnon-justified text, > and listing computer code; Specialized macros for easily\nconstructing ruled > tables. TeXsis was originally developed for physicists, but\nothers may also > find it useful. It is completely compatible with Plain TeX.") (license > lppl)) #f) > test-name: texlive->guix-package > location: /home/ck/tmp/guix/tests/texlive.scm:161 Actually I’m now experiencing it, and I think it’s caused by commit be7b314f3fe22273e935accac22f313e44d3d970, which changes the ‘texlive’ importer. Ricardo, WDYT? Thanks, Ludo’.
bug#56711: libunwind-julia fails to build on aarch64
I've been trying to get julia working on aarch64 but I was running into a linker error when guix was trying to build libunwind-julia. I tracked it down to the libunwind-julia-fix-GCC10-fno-common.patch not including a fix for aarch64 which is included in the upstream commit [1] which fixed this in libunwind 1.5.0. I gather libunwind-julia is at 1.3.1 due to julia 1.6.3 only building against that version, and checking the more recent julia versions, it seems julia is only updating it's dependency on libunwind to 1.5.0 with julia version 1.8.0 which is only a release candidate at this point. So perhaps in the meantime, libunwind-julia-fix-GCC10-fno-common.patch could be easily updated so julia can start building on aarch64? [1] https://github.com/libunwind/libunwind/commit/29e17d8d2ccbca07c423e3089a6d5ae8a1c9cb6e Thanks! Akira
bug#56709: Channel opening failure with guix deploy
Hi,
I use 'guix deploy' to deploy on a machine on the local network. There
is no problem using ssh as standard, but 'guix deploy' fails. Machine
configuration:
https://paste.sr.ht/~akagi/04c11305b19b1b25d0e61a88f6892057dee01b67
So far, I do not understand how to approach this problem, I would be
very grateful for any advice.
Log:
-*- mode: compilation; default-directory: "~/dotfiles/" -*-
Compilation started at Fri Jul 22 19:46:59
make deploy
guix deploy magi/system/remote/deploy.scm
The following 1 machine will be deployed:
home-server
guix deploy: deploying to home-server...
guix deploy: sending 0 store items (0 MiB) to '192.168.1.103'...
guix deploy: sending 0 store items (0 MiB) to '192.168.1.103'...
substitute: updating substitutes from 'http://ci.guix.trop.in'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://substitutes.nonguix.org'...
100.0%
The following derivations will be built:
/gnu/store/fjychria4fq95iy5m1zasxnirk0y6v48-remote-exp.scm.drv
/gnu/store/nlx7rql98r2vmcp3vsh8iyza84idygrs-switch-to-system.scm.drv
/gnu/store/hnrjnbqgzn664zqs2wvcsvm8ld5y0vf3-system.drv
/gnu/store/4p6q4l0ya16z0vahfp6i52r1gps82642-profile.drv
/gnu/store/835gjdjaclznrpymk8f5ir6c259pg4xy-provenance.drv
building /gnu/store/835gjdjaclznrpymk8f5ir6c259pg4xy-provenance.drv...
building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
building directory of Info manuals...
building database for manual pages...
building profile with 51 packages...
building /gnu/store/hnrjnbqgzn664zqs2wvcsvm8ld5y0vf3-system.drv...
building /gnu/store/nlx7rql98r2vmcp3vsh8iyza84idygrs-switch-to-system.scm.drv...
building /gnu/store/fjychria4fq95iy5m1zasxnirk0y6v48-remote-exp.scm.drv...
guix deploy: sending 11 store items (2 MiB) to '192.168.1.103'...
guix deploy: sending 0 store items (0 MiB) to '192.168.1.103'...
The following derivations will be built:
/gnu/store/p6hxcnb7drm1yhcsmhicziv1mmad1p7y-remote-exp.scm.drv
/gnu/store/z2p4a8zq70vqcx9lk7mn0rravy6nw46r-upgrade-shepherd-services.scm.drv
building
/gnu/store/z2p4a8zq70vqcx9lk7mn0rravy6nw46r-upgrade-shepherd-services.scm.drv...
building /gnu/store/p6hxcnb7drm1yhcsmhicziv1mmad1p7y-remote-exp.scm.drv...
;;; [2022/07/22 19:47:46.682720, 0] [GSSH ERROR] Channel opening failure:
channel 63 error (2) open failed: #
Backtrace:
In guix/store.scm:
1380:11 19 (map/accumulate-builds # …)
1298:8 18 (call-with-build-handler # …)
In ice-9/boot-9.scm:
1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/deploy.scm:
159:6 16 (_)
In guix/store.scm:
2168:25 15 (run-with-store # …)
In gnu/machine/ssh.scm:
498:10 14 (_ _)
499:39 13 (_ _)
In ice-9/boot-9.scm:
1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In gnu/machine/ssh.scm:
499:39 11 (_)
In guix/store.scm:
2168:25 10 (run-with-store # …)
In guix/remote.scm:
138:10 9 (_ _)
In guix/store.scm:
2040:38 8 (_ #)
In guix/ssh.scm:
372:2 7 (send-files # _ # …)
218:5 6 (remote-run (begin (use-modules (guix) (srfi #) # #) …) #)
In ssh/popen.scm:
64:4 5 (open-remote-pipe* _ "r+" _ . _)
In unknown file:
4 (channel-open-session #)
In ice-9/boot-9.scm:
1685:16 3 (raise-exception _ #:continuable? _)
1683:16 2 (raise-exception _ #:continuable? _)
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel
opening failure: channel 63 error (2) open failed" # #f)'.
make: *** [Makefile:32: deploy] Error 1
--
Best regards,
Aleksandr Vityazev
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SDDM + Mate
On 2022-07-22 12:44, Maxime Devos wrote: > On 22-07-2022 12:24, Maxime Devos wrote: >> retitle 56661 SDDM does not do the equivalent of 'login shell >> --login', unlike other login managers >> thanks >> >> A digged a little, and found that: >> >> For GDM, things work, for SDDM, they don't. >> >> There is a 'xinitrc' procedure in gnu/services/xorg.scm that generates >> a configuration file that has a fallback .xsession that does a >> --login. This is used by gdm-wayland-session-wrapper, >> and slim-shepherd-service. However, nothing >> similar appears to be done for SDDM. So it appears that the SDDM >> service needs to be tweaked to use xinitrc or such. The idea looks good to me. > > It appears that SDDM supports xinitrc files, but it looks for them > (see data/scripts/Xsession) in $HOME/.xsessionrc and > /etc/X11/xinit/xinitrc.d, which do not exist in Guix. There is no > option for overriding the xinitrc. However, it is possible to > override the Xsession script used, so we can give SDDM a modified > Xsession script that uses Guix' xinitrc. I'll give that a try. Just a note: .xsessionrc is debian-specific IIRC -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56661: SDDM does not do the equivalent of 'login shell --login', unlike other login managers
On 22-07-2022 15:03, Andrew Tropin wrote: It's a tricky question, because it's a case on the edge of Home/System. From one point of view it should be handled by some home service, which will create a proper ~/.xsession or extend it and generic mechanism, Such a mechanism already exists for GDM and SLiM, see later (though it doesn't create ~/.xessionrc, it's more stateless, and it is independent of Guix Home). I don't see why Guix Home should handle things, it doesn't seem to have anything to handle (unless you go for the alternative, more stateful, solution you are proposing?). from some display managers will automatically source it, but on the other hand maybe adjusting system services for other DMs, which doesn't work "out of the box" yet is a way to go. I don't have much experience with X11, and don't see a whole picture, so it's hard to tell which option is better. I think I've found a solution that works for Guix System, independent of Guix Home (doesn't depend on Guix Home and doesn't interfere with Guix Home and doesn't require Guix System and Guix Home to interact), as written in another response (thread is getting a bit long!): On 22-07-2022 12:24, Maxime Devos wrote: retitle 56661 SDDM does not do the equivalent of 'login shell --login', unlike other login managers thanks A digged a little, and found that: For GDM, things work, for SDDM, they don't. There is a 'xinitrc' procedure in gnu/services/xorg.scm that generates a configuration file that has a fallback .xsession that does a --login. This is used by gdm-wayland-session-wrapper, and slim-shepherd-service. However, nothing similar appears to be done for SDDM. So it appears that the SDDM service needs to be tweaked to use xinitrc or such. It appears that SDDM supports xinitrc files, but it looks for them (see data/scripts/Xsession) in $HOME/.xsessionrc and /etc/X11/xinit/xinitrc.d, which do not exist in Guix. There is no option for overriding the xinitrc. However, it is possible to override the Xsession script used, so we can give SDDM a modified Xsession script that uses Guix' xinitrc. TBC: the 'xinitrc' that Guix generates does not override the ~/.xinitrc written by the user (if any) -- IIUC, the generated wrapper looks for ~/.xinitrc and if it exists, it runs that, but if it doesn't exist, it has a fallback. Also, TBC, it doesn't create ~/.xsessionrc (unlike what you seem to be proposing), the relevant code just tells the login manager to look at /gnu/store/...-the-generated-xinitrc. It seems to work for GDM and presumably also for SLiM, which has similar code. As such, I would expect it to work without problems for SDDM as well (please write SDDM in the subject line, the original SLiM is incorrect, I actually used SDDM). Greetings, Maxime OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SLIM + Mate
On 2022-07-22 11:32, Maxime Devos wrote: > On 20-07-2022 19:47, Andrew Tropin wrote: > >> I'm not sure how your login/display manager works, but for X11 session >> sourcing ~/.profile from ~/.xsession should do the trick. > Me neither, and I don't particularly care. > > If this is something that needs to be done, shouldn't _Guix System_ > create that file by default, for the same reason that Guix System > creates a ~/.profile and ~/.bash_profile by default? I don't see why I > would have to do that myself. It's a tricky question, because it's a case on the edge of Home/System. From one point of view it should be handled by some home service, which will create a proper ~/.xsession or extend it and generic mechanism, from some display managers will automatically source it, but on the other hand maybe adjusting system services for other DMs, which doesn't work "out of the box" yet is a way to go. I don't have much experience with X11, and don't see a whole picture, so it's hard to tell which option is better. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56595: failed to compute derivation for Guix f6904c0
I finally found out that it's caused by external channels, sorry for the inconvenience.
bug#56661: SDDM does not do the equivalent of 'login shell --login', unlike other login managers
On 22-07-2022 12:44, Maxime Devos wrote: On 22-07-2022 12:24, Maxime Devos wrote: retitle 56661 SDDM does not do the equivalent of 'login shell --login', unlike other login managers thanks A digged a little, and found that: For GDM, things work, for SDDM, they don't. There is a 'xinitrc' procedure in gnu/services/xorg.scm that generates a configuration file that has a fallback .xsession that does a --login. This is used by gdm-wayland-session-wrapper, and slim-shepherd-service. However, nothing similar appears to be done for SDDM. So it appears that the SDDM service needs to be tweaked to use xinitrc or such. It appears that SDDM supports xinitrc files, but it looks for them (see data/scripts/Xsession) in $HOME/.xsessionrc and /etc/X11/xinit/xinitrc.d, which do not exist in Guix. There is no option for overriding the xinitrc. However, it is possible to override the Xsession script used, so we can give SDDM a modified Xsession script that uses Guix' xinitrc. I'll give that a try. Actually, I'll be doing other things first, but for anyone interested, this sounds like a likely solution to me. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SDDM + Mate
On 22-07-2022 12:24, Maxime Devos wrote: retitle 56661 SDDM does not do the equivalent of 'login shell --login', unlike other login managers thanks A digged a little, and found that: For GDM, things work, for SDDM, they don't. There is a 'xinitrc' procedure in gnu/services/xorg.scm that generates a configuration file that has a fallback .xsession that does a --login. This is used by gdm-wayland-session-wrapper, and slim-shepherd-service. However, nothing similar appears to be done for SDDM. So it appears that the SDDM service needs to be tweaked to use xinitrc or such. It appears that SDDM supports xinitrc files, but it looks for them (see data/scripts/Xsession) in $HOME/.xsessionrc and /etc/X11/xinit/xinitrc.d, which do not exist in Guix. There is no option for overriding the xinitrc. However, it is possible to override the Xsession script used, so we can give SDDM a modified Xsession script that uses Guix' xinitrc. I'll give that a try. Greetings, Maxime OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SDDM + Mate
retitle 56661 SDDM does not do the equivalent of 'login shell --login', unlike other login managers thanks A digged a little, and found that: For GDM, things work, for SDDM, they don't. There is a 'xinitrc' procedure in gnu/services/xorg.scm that generates a configuration file that has a fallback .xsession that does a --login. This is used by gdm-wayland-session-wrapper, and slim-shepherd-service. However, nothing similar appears to be done for SDDM. So it appears that the SDDM service needs to be tweaked to use xinitrc or such. Greetings, Maxime OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SDDM + Mate
On 22-07-2022 11:28, Maxime Devos wrote: However, possibly this is a bug in the setup of the login manager I used (previously I used another one), so I will try a different login manager as possibly Guix Home is not related here. For GDM, the issue does not occur (and I don't have to create ~/.xsession). Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SLIM + Mate
On 20-07-2022 19:47, Andrew Tropin wrote: I'm not sure how your login/display manager works, but for X11 session sourcing ~/.profile from ~/.xsession should do the trick. Me neither, and I don't particularly care. If this is something that needs to be done, shouldn't _Guix System_ create that file by default, for the same reason that Guix System creates a ~/.profile and ~/.bash_profile by default? I don't see why I would have to do that myself. Greetings, Maxime OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SDDM + Mate
On 20-07-2022 19:47, Andrew Tropin wrote:
I'm not sure how your login/display manager works, but for X11 session
sourcing ~/.profile from ~/.xsession should do the trick.
Put the following content to your ~/.xsession:
--8<---cut here---start->8---
. ~/.profile
--8<---cut here---end--->8---
Or add the following service to your home environment:
--8<---cut here---start->8---
(simple-service
'xsession-init-file
home-files-service-type
`((".xsession" ,(plain-file "xsession" ". ~/.profile"
--8<---cut here---end--->8---
Tweaking .xsession was not necessary in my previous Guix System without
Home setup, so this seems like a work-around to me, not a solution.
However, possibly this is a bug in the setup of the login manager I used
(previously I used another one), so I will try a different login manager
as possibly Guix Home is not related here.
They do. Also, shouldn't ~/.bash_profile point to
~/.guix-home/files/.bash_profile instead of directly to the store, to be
more atomic (unrelated to #56661 though), like done for symlinks in /etc
in Guix System?
No.
Activation is not atomic process anyway.
I know it is not atomic. That's the issue I noted, an issue that seems
to have a partial solution I also noted.
With current file system APIs, it cannot be made fully atomic, but as
done for Guix System things, it can at least be made _partially_ atomic
-- i.e., when no files are added or removed relative to the previous
generation, the symlink switching is atomic.
(A form of 'Perfect enemy of the good' -- if perfect (= 100% atomic)
cannot be found, then that's no reason to throw away good (= mostly
atomic).)
(Also an instance of is-ought: it is not atomic, but that doesn't mean
it should be non-atomic.)
Greetings,
Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
