bug#47716: gio mount broken, again.
Hi, raingloom writes: > ``` > $ gio mount sftp://whatever > $ ls /run/user/$UID/gvfs/ > ``` > prints nothing. Note that it seem to work if you are using the GNOME desktop. > Same thing happens if I mount it from the Nautilus file manager. > > This bug has appeared before and I still have no idea how it was fixed, > which is not great. I'll do a bisect soon. Should probably add a system > test for it so it doesn't break again. > > In the meantime, if whoever fixed it the last time could look into it > again, I'd be very thankful. Using sshfs manually works but isn't great. gvfs is now using fusermount3, but we were only adding 'fusermount' as a setuid-program by default. After adding fusermount3 from fuse@3 to /run/setuid-programs, it appears to work: $ guix shell glib:bin gvfs dbus fuse gnome-keyring [env] PATH=/run/setuid-programs:$PATH dbus-run-session bash [env] gio mount sftp://some-host:2345 ( prompts for credentials ) ls /run/user/1000/gvfs/sftp:host=some-host,port=2345/ bin/ dev/ gnu/ [...] I've pushed this as commit cbdfa54c77. Closing. Maxim
bug#52823: 3 gx*lv2 packages fail to build in the same manner
On Wed, 13 Jul 2022 23:59:49 -0400 Maxim Cournoyer wrote: > It looks like they need to be updated (if updates for them exist), as > they seem to rely on deprecated glib functions. > > Would you like to give it a try? Hi Maxim! Well, I may look into it in the coming days. -- Thorsten Wilms
bug#42989: Subtle Typo in guix-daemon.service installed by guix-install.sh
Agreed. It arose from a misunderstanding of guix and rightly deserves to be ignored and deep sixed. On Wed, Jul 13, 2022 at 7:18 PM Maxim Cournoyer wrote: > Hi, > > Leo Famulari writes: > > > On Sat, Aug 22, 2020 at 12:22:13PM -0700, Michael Gorlick wrote: > >> You are right and the confusion is mine. The reason the error messages > >> disappeared is that thanks to a "guix pull", a "guix upgrade", and a > "guix > >> install glibc-utf8-locales" on user "root" I now have the latest > version of > >> the utf8-locales, 2.31, installed at > >> */var/guix/profiles/per-user/root/guix-profile/lib/locale.* > >> > >> Sorry for the bother. However, judging by prior discussions not everyone > >> understands that the build daemons rely in this way on the guix-profile > of > >> the root. It would help if the documentation pointed out this common > >> misunderstanding and explicitly advised users on foreign distributions > to > >> pull and upgrade the root profile regularly. > > > > Yeah, locales are one of the bigger user experience problem with Guix :/ > > The warnings are a definite improvement over how it used to be, when > > glibc would simply ABORT any program that was using the wrong version of > > locales. > > > > We are still searching for a solid solution to the problem, as we've > > been tweaking the documentation for years now, but people still report > > the warnings all the time. > > I think the situation has improved a lot in recent years. I'll close > this since the title is misguided, and since it's very old :-). > > Thank you, > > Maxim >
bug#54691: fortune-mod propagates various non-nice things
Hi Csepp, Csepp writes: > Maxim Cournoyer writes: > >> Hi Maxime, >> >> Maxime Devos writes: >> >>> Hi guix, >>> >>> fortune-mod currently propagates (in the non-technical sense) various >>> non-nice things like objectification, misogeny, religious intolerance, >>> anti-mathematician-ism (?) and date rape. That is not an exhaustive >>> list, these are just the first few things I encountered with "fortune >>> off". >>> >>> To reproduce the issue, run "fortune off" a few times. Or just >>> "fortune", though then it can take a bit longer. >>> >>> There are also a few non-nice things in the non-off set. E.g.: >>> >>> $ fortune User n.: A programmer who will believe anything you tell him. >>> # ^ from 'definitions' >>> >>> As such, just removing 'off' doesn't seem sufficient. Unless Someone™ >>> volunteers to remove the anti-fortunes (*), I would just remove >>> 'fortune-mod', given that it seems to serve no practical purpose byond >>> being non-nice. WDYT? >> >> 'off' here apparently means the 'offensive' database, as explained by >> Liliana; seems it offends alright :-). >> >> The GNU FSDG has says nothing about what programs may or may not >> contain, for a good reason: the line to draw could get very subjective >> (similar to how the GPL ). >> >> I don't think we should judge our software on terms falling outside of >> the Free Software Distribution Guidelines, but a simple thing we could >> add here would be a note in the description to caution the user that >> running >> >> @example >> fortune off >> @end example >> >> is intended to be offensive. >> >> What do you think? >> >> Thanks, >> >> Maxim > > Honestly this is dumb, it's not even practically useful software. We > have no obligation to package something that jokes about date rape and > contributes nothing of practical value. > This is very different to the reasoning behind the lack of moral clauses > in the GPL. And again, just because something is free software, we don't have > to > package it. > It's a ticking PR timebomb and nothing of value would be lost if we got > rid of that file. If some snowflake gets triggered because we removed > their favorite date rape joke, they self identified as someone whose > opinion we should ignore. :P Thanks for the criticism. I admit I hadn't run 'fortune off' myself or researched much on what it contains; after reading more about it, especially considering these notes about the 'Offensive' database [0]: --8<---cut here---start->8--- [...] In another file in this directory (Notes), the original author(s) of the fortune distribution state that "racist, mysogynist [sic] (sexist), or homophobic ideas" should never be included in the fortune database. [...] --8<---cut here---end--->8--- --8<---cut here---start->8--- [...] I admit that I was strongly tempted to simply remove these fortunes, an action that I might have justified by pointing to the Notes of the original authors. However, it appears that over the course of time there have been those who find these sorts of prejudice amusing, and in America, at least, even Nazi rhetoric is a protected form of speech. So I include them, and leave the decision to individual system administrators. [...] --8<---cut here---end--->8--- But the most explicit recommendation is: --8<---cut here---start->8--- Those who respect women, gays, and people of color may prefer to either remove the .dat file (which keeps the strings, but makes them inaccessible via the fortune program), or to delete these files altogether. --8<---cut here---end--->8--- I now think we should act on it :-) Would you like to prepare a patch stripping out the offensive database file? Thanks, Maxim [0] https://github.com/shlomif/fortune-mod/blob/master/fortune-mod/Offensive
bug#56556: texlive-babel-dutch with and without texlive-hyphen-dutch: No hyphenation patterns were preloaded
Neither texlive-babel-dutch nor texlive-hyphen-dutch load hyphenation.
Test document:
\documentclass{article}
\usepackage[dutch]{babel}
\begin{document}
test
\end{document}
Running with texlive-babel-dutch only:
$ guix shell --pure texlive-base texlive-babel-dutch -- pdflatex test.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021/GNU Guix)
(preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-18>
(/gnu/store/1p55mddnasba5xq2vcnzyc8wjywn4cwn-profile/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/gnu/store/1p55mddnasba5xq2vcnzyc8wjywn4cwn-profile/share/texmf-dist/tex/latex/base/size10.clo))
(/gnu/store/1p55mddnasba5xq2vcnzyc8wjywn4cwn-profile/share/texmf-dist/tex/generic/babel/babel.sty
(/gnu/store/1p55mddnasba5xq2vcnzyc8wjywn4cwn-profile/share/texmf-dist/tex/generic/babel/babel.def
(/gnu/store/1p55mddnasba5xq2vcnzyc8wjywn4cwn-profile/share/texmf-dist/tex/generic/config/language.def)
(/gnu/store/1p55mddnasba5xq2vcnzyc8wjywn4cwn-profile/share/texmf-dist/tex/generic/babel/txtbabel.def))
(/gnu/store/1p55mddnasba5xq2vcnzyc8wjywn4cwn-profile/share/texmf-dist/tex/generic/babel-dutch/dutch.ldf
Package babel Warning: No hyphenation patterns were preloaded for
(babel)the language `Dutch' into the format.
(babel)Please, configure your TeX system to add them and
(babel)rebuild the format. Now I will use the patterns
(babel)preloaded for \language=0 instead on input line 49.
))
(/gnu/store/1p55mddnasba5xq2vcnzyc8wjywn4cwn-profile/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./test.aux)
[1{/gnu/store/1p55mddnasba5xq2vcnzyc8wjywn4cwn-profile/share/texmf-dist/fonts/map/pdftex/updmap/pdftex.map}]
(./test.aux) )
Output written on test.pdf (1 page, 2226 bytes).
Transcript written on test.log.
With texlive-hyphen-dutch included:
$ guix shell --pure texlive-base texlive-babel-dutch texlive-hyphen-dutch --
pdflatex test.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021/GNU Guix)
(preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-18>
(/gnu/store/c61c43w5c7dlz7ipxcqi4z385p3a4dzb-profile/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/gnu/store/c61c43w5c7dlz7ipxcqi4z385p3a4dzb-profile/share/texmf-dist/tex/latex/base/size10.clo))
(/gnu/store/c61c43w5c7dlz7ipxcqi4z385p3a4dzb-profile/share/texmf-dist/tex/generic/babel/babel.sty
(/gnu/store/c61c43w5c7dlz7ipxcqi4z385p3a4dzb-profile/share/texmf-dist/tex/generic/babel/babel.def
(/gnu/store/c61c43w5c7dlz7ipxcqi4z385p3a4dzb-profile/share/texmf-dist/tex/generic/config/language.def)
(/gnu/store/c61c43w5c7dlz7ipxcqi4z385p3a4dzb-profile/share/texmf-dist/tex/generic/babel/txtbabel.def))
(/gnu/store/c61c43w5c7dlz7ipxcqi4z385p3a4dzb-profile/share/texmf-dist/tex/generic/babel-dutch/dutch.ldf
Package babel Warning: No hyphenation patterns were preloaded for
(babel)the language `Dutch' into the format.
(babel)Please, configure your TeX system to add them and
(babel)rebuild the format. Now I will use the patterns
(babel)preloaded for \language=0 instead on input line 49.
))
(/gnu/store/c61c43w5c7dlz7ipxcqi4z385p3a4dzb-profile/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./test.aux)
[1{/gnu/store/c61c43w5c7dlz7ipxcqi4z385p3a4dzb-profile/share/texmf-dist/fonts/map/pdftex/updmap/pdftex.map}]
(./test.aux) )
Output written on test.pdf (1 page, 2226 bytes).
Transcript written on test.log.
Problem does not occur when using the complete TeX Live distribution:
$ guix shell --pure texlive -- pdflatex test.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021/GNU Guix)
(preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-18>
(/gnu/store/lgkfz7wg59sg81zlf3xy7i7dbvx1fvyp-texlive-texmf-20210325/share/texmf
-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/gnu/store/lgkfz7wg59sg81zlf3xy7i7dbvx1fvyp-texlive-texmf-20210325/share/texmf
-dist/tex/latex/base/size10.clo))
(/gnu/store/lgkfz7wg59sg81zlf3xy7i7dbvx1fvyp-texlive-texmf-20210325/share/texmf
-dist/tex/generic/babel/babel.sty
(/gnu/store/lgkfz7wg59sg81zlf3xy7i7dbvx1fvyp-texlive-texmf-20210325/share/texmf
-dist/tex/generic/babel/babel.def
(/gnu/store/lgkfz7wg59sg81zlf3xy7i7dbvx1fvyp-texlive-texmf-20210325/share/texmf
-dist/tex/generic/babel/txtbabel.def))
(/gnu/store/lgkfz7wg59sg81zlf3xy7i7d
bug#42553: python-gevent is broken on i686-linux (tests fail)
Hi Jakub, Jakub Kądziołka writes: > On Thu Jul 14, 2022 at 4:40 AM CEST, Maxim Cournoyer wrote: >> Finally disabled the test in 692c2ad327. >> >> Closing. > > Are we sure this is the appropriate course of action? It sounds like the > test is exposing a bug in our packaging that might affect users of > python-gevent. It might be better to have the package build than not, of > course, but still we might want to investigate why the test fails. The issue was reported and closed upstream many versions ago. I'm positive python-gevent works fine in Guix. It's just the test_unlink test that fails for unknown reasons on i686. I wouldn't loose sleep on it. Thanks, Maxim
bug#54691: fortune-mod propagates various non-nice things
Maxim Cournoyer writes: > Hi Maxime, > > Maxime Devos writes: > >> Hi guix, >> >> fortune-mod currently propagates (in the non-technical sense) various >> non-nice things like objectification, misogeny, religious intolerance, >> anti-mathematician-ism (?) and date rape. That is not an exhaustive >> list, these are just the first few things I encountered with "fortune >> off". >> >> To reproduce the issue, run "fortune off" a few times. Or just >> "fortune", though then it can take a bit longer. >> >> There are also a few non-nice things in the non-off set. E.g.: >> >> $ fortune >>> User n.: >>> A programmer who will believe anything you tell him. >> # ^ from 'definitions' >> >> As such, just removing 'off' doesn't seem sufficient. Unless Someone™ >> volunteers to remove the anti-fortunes (*), I would just remove >> 'fortune-mod', given that it seems to serve no practical purpose byond >> being non-nice. WDYT? > > 'off' here apparently means the 'offensive' database, as explained by > Liliana; seems it offends alright :-). > > The GNU FSDG has says nothing about what programs may or may not > contain, for a good reason: the line to draw could get very subjective > (similar to how the GPL ). > > I don't think we should judge our software on terms falling outside of > the Free Software Distribution Guidelines, but a simple thing we could > add here would be a note in the description to caution the user that > running > > @example > fortune off > @end example > > is intended to be offensive. > > What do you think? > > Thanks, > > Maxim Honestly this is dumb, it's not even practically useful software. We have no obligation to package something that jokes about date rape and contributes nothing of practical value. This is very different to the reasoning behind the lack of moral clauses in the GPL. And again, just because something is free software, we don't have to package it. It's a ticking PR timebomb and nothing of value would be lost if we got rid of that file. If some snowflake gets triggered because we removed their favorite date rape joke, they self identified as someone whose opinion we should ignore. :P
bug#39813: Running Guix in a Virtual Machine - says 1 GB RAM is enough, but it isn't for guix pull
Liliana Marie Prikler writes: > Am Mittwoch, dem 13.07.2022 um 19:21 +0200 schrieb Julien Lepiller: >> I've heard that theory before. From observation on my late armhf >> server >> (two cores): >> >> - it takes just below 2GB to build one of the derivations >> - It doesn't swap a single byte >> - whether with two or a single core, it takes roughly the same amount >> of memory >> - substitution is nice, it doesn't require lots of memory (and then - >> - >> cores is useless) >> >> I think it's because we load all the files in a batch before we build >> them. The biggest amount of memory required is not for running the >> compiler on a thread, but for loading files and keeping them in >> memory for the whole duration of the build. With more threads, we >> still don't load each file more than once (twice to build it), so >> there's no reason it should take more memory. >> >> Or maybe the process of loading and building is inherently single- >> threaded? I don't think so, but maybe? > Loading and building is implemented in build-aux/compile-all.scm, which > does use multiple parallel workers. However, since all compilation > appears to be done in the same Guile process, I don't think multi- > threading makes too big of an impact (it'll be the same garbage > collector regardless of ordering). > > Cheers Hmm, for some reason it finishes much faster on my i686 netbook with --cores=1. I'll try to look into it further. I enable swap on it but it doesn't use a lot of it. Maybe using an HDD matters too, since swapping is much more expensive on it. Disabling parallelism tends to help because it can halve the worst case memory usage. If foo.c and bar.c both require at most 1M during build, building them in parallel is 2M in the worst case, but only 1M when serialized. Oh and this is with channel-with-substitutes-available. So either that's broken or something still needs building. Anyways, I should take a looksie at build-aux/compile-all.scm, maybe I can decrease the memory usage.
bug#47716: gio mount broken, again.
Csepp writes: > Maxim Cournoyer writes: > >> Hi, >> >> raingloom writes: >> >>> ``` >>> $ gio mount sftp://whatever >>> $ ls /run/user/$UID/gvfs/ >>> ``` >>> prints nothing. >>> >>> Same thing happens if I mount it from the Nautilus file manager. >>> >>> This bug has appeared before and I still have no idea how it was fixed, >>> which is not great. I'll do a bisect soon. Should probably add a system >>> test for it so it doesn't break again. >>> >>> In the meantime, if whoever fixed it the last time could look into it >>> again, I'd be very thankful. Using sshfs manually works but isn't great. >> >> glib has seen 3 ugrades in Guix since you reported this issue (2.68.3 >> then 2.70 then 2.70.2). Do you still have the issue? >> >> How do you setup the server; is a running OpenSSH server sufficient? >> >> Thanks, >> >> Maxim > > I haven't done the bisect yet (ugh, why is time), but yes, the problem > still persists. Mostly same system config. gvfs is included in system > profile. > Yep, running OpenSSH is enough. > The system I'm currently writing from very much has the issue and is > about... okay, so it's from june 21, so not as fresh as I thought, but > relatively fresh. Upgraded system and user profiles and the issue is still present.
bug#42553: python-gevent is broken on i686-linux (tests fail)
On Thu Jul 14, 2022 at 4:40 AM CEST, Maxim Cournoyer wrote: > Finally disabled the test in 692c2ad327. > > Closing. Are we sure this is the appropriate course of action? It sounds like the test is exposing a bug in our packaging that might affect users of python-gevent. It might be better to have the package build than not, of course, but still we might want to investigate why the test fails. Regards, Kuba
