bug#47716: gio mount broken, again.

2022-07-14 Thread Maxim Cournoyer
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

2022-07-14 Thread Thorsten Wilms
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

2022-07-14 Thread Michael Gorlick
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

2022-07-14 Thread Maxim Cournoyer
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

2022-07-14 Thread Remco van 't Veer
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))
  

bug#42553: python-gevent is broken on i686-linux (tests fail)

2022-07-14 Thread Maxim Cournoyer
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

2022-07-14 Thread Csepp


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

2022-07-14 Thread Csepp


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.

2022-07-14 Thread Csepp


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)

2022-07-14 Thread Jakub Kądziołka
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