bug#63982: Shepherd wrong-type-arg

[nils]

Hello,

I am affected by this as well, but with slightly different symptoms.
Using guix home on a foreign system (Debian 12), I tried different shepherd 
versions with

(service home-shepherd-service-type
 (home-shepherd-configuration
   (shepherd (specification->package "shepherd@0.9")))

, and guix home describe --list-installed shows me that this works (in the 
sense that a different shepherd version is installed).
None of the versions I tried got me a functional shepherd service.

These are the error messages by shepherd version:

0.8.1:
Service root has been started.
WARNING: Use of `load' in declarative module (#{ g91}#).  Add #:declarative? #f 
to your define-module invocation.
Loading /gnu/store/w6rlja8v65dwv16ivcqx513q7827n6aq-shepherd.conf.
herd: exception caught while executing 'load' on service 'root':
In procedure string-append: Wrong type (expecting string): #f

No /run/user/1000/shepherd/socket is created. 

0.9.3:
Service root has been started.
WARNING: Use of `load' in declarative module (#{ g117}#).  Add #:declarative? 
#f to your define-module invocation.
wrong-type-arg("string-append" "Wrong type (expecting ~A): ~S" ("string" #f) 
(#f))

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.

No /run/user/1000/shepherd/socket is created.

0.10.1:
Starting service root...
Service root started.
Service root running with value #t.
Service root has been started.
WARNING: Use of `load' in declarative module (#{ g107}#).  Add #:declarative? 
#f to your define-module invocation.
wrong-type-arg("string-append" "Wrong type (expecting ~A): ~S" ("string" #f) 
(#f))

No /run/user/1000/shepherd/socket is created.

0.10.99:
Starting service root...
Service root started.
Service root running with value #t.
Service root has been started.
WARNING: Use of `load' in declarative module (#{ g119}#).  Add #:declarative? 
#f to your define-module invocation.
Uncaught exception while loading configuration file 
'/gnu/store/w6rlja8v65dwv16ivcqx513q7827n6aq-shepherd.conf': (wrong-type-arg 
"string-append" "Wrong type (expecting ~A): ~S"
 ("string" #f) (#f))

, and then the reconfiguration hangs. /run/user/1000/shepherd/socket is 
created, and herd status shows that root is started, other services are not 
shown, and are not started.


Content of config (/gnu/store/w6rlja8v65dwv16ivcqx513q7827n6aq-shepherd.conf):
(begin (use-modules (srfi srfi-34) (system repl error-handling)) (apply 
register-services (map (lambda (file) (load file)) (quote 
("/gnu/store/71n4r0hccps574aqcks7zyk5rz5zardq-
shepherd-eww.scm" 
"/gnu/store/0r14z4psnf9h2nfqiflm0nv6m2bv04si-shepherd-eww-open-lockscreen-like-background.scm"
 "/gnu/store/ylidynn5akvk3lmqrxbgqkz0c8hn3y8c-shepherd-syncthing
.scm" "/gnu/store/9igwbpbwavl6r94ph7qss7i5cqq9d8nj-shepherd-mcron.scm" 
(action (quote root) (quote daemonize)) (format #t "Starting services...~%") 
(let ((services-to-start
(quote (eww eww-open-lockscreen-like-background syncthing mcron (if 
(defined? (quote start-in-the-background)) (start-in-the-background 
services-to-start) (for-each start
services-to-start)) (redirect-port (open-input-file "/dev/null") 
(current-input-port

~/.local/state/log/shepherd.log does not contain anything that's not already in 
the messages above.

Is there anything else I can provide? Without a running shepherd, my system 
doesn't work super well.

bug#63982: Shepherd can crash when a user service fails to start

[nils]

> Ludovic Courtès  hat am 22.06.2023 22:08 CEST geschrieben:
> This suggests a problem in the config file: one of the shepherd-*.scm
> files listed above ends up calling (string-append #f …).
> 
> We’d need to see those files to understand what’s happening but it looks
> different from what Maxim reported.

Indeed I misdiagnosed the issue because it happened after a guix upgrade.
I used $XDG_LOG_HOME in my shepherd services, and as of 
f74df2ab879fc5457982bbc85b7455a90e82317d this is no longer set by default. 
Thanks for your help!

bug#65522: Documentation for some home services disappeared from 1.4 manual

[nils]

Hello,

I noticed some help nodes under 
https://guix.gnu.org/en/manual/en/html_node/Home-Services.html disappeared 
fairly recently.
They are still available in the devel docs under 
https://guix.gnu.org/en/manual/devel/en/html_node/Home-Services.html

The following topics are missing:
* GPG: GNU Privacy Guard.   Setting up GPG and related tools.
* Fonts: Fonts Home Services.   Services for managing User's fonts.
* Sound: Sound Home Services.   Dealing with audio.
* Mail: Mail Home Services. Services for managing mail.
* Messaging: Messaging Home Services.  Services for managing messaging.
* Media: Media Home Services.   Services for managing media.
* Networking: Networking Home Services.  Networking services.
* Miscellaneous: Miscellaneous Home Services.  More services.

This makes sense when looking at the 1.4.0 git tag, but I had a browser tab 
open, and https://guix.gnu.org/manual/en/html_node/Mail-Home-Services.html was 
definitely available just a day or two ago.

I don't know if this is actually an issue or an intended change, but it seemed 
better to report it than to ignore it.

bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

[nils]

Hello,
 
when using the home-mcron-service, PATH is set to 
/run/current-system/profile/bin . This directory is empty when using guix home 
on a foreign distro, meaning all executable paths would need to be absolute. 
This includes stuff like /usr/bin/ssh, /usr/bin/nice etc..
 
My guess for the culprit was 1c30d5a6bfc5d48137f4bdcc271189a06fdc6ed3 , which 
replaced the custom home-mcron-service-type with mapping it to 
mcron-service-type. 
The mcron shepherd service in old service type did not mess with the 
environment variables, the inherited one does:
#:environment-variables
(cons* "GUILE_AUTO_COMPILE=0"
"PATH=/run/current-system/profile/bin"
(remove (cut string-prefix? "PATH=" <>)
(environ)))
 
Strange thing is that the commit is from 2023-08-06, and I update guix almost 
every day, but did not run into the issue until today. But the commit seems to 
fit the issue perfectly, so I'm not sure what's going on at all.

bug#65522: Documentation for some home services disappeared from 1.4 manual

[nils]

> Simon Tournier  hat am 05.09.2023 17:18 CEST 
> geschrieben:
> This webpage
>  points
> to the manual as it was for the last release.  It means, this manual
> wepage is frozen and is only updated at each release.  If you have seen
> something different, it is an artifact that should not be possible.

Note: I just searched for "guix search-input-file" on duckduckgo (and startpage 
/ google to doublecheck) and the second hit was pointing to 
https://guix.gnu.org/manual/en/html_node/File-Search-Services.html which is 
404. https://guix.gnu.org/manual/devel/en/html_node/File-Search-Services.html 
works.
So it appears the manual was wrong (=showing the "latest" version instead of 
1.4.0) long enough to be indexed by search engines.
Of course this does not really change anything, if the current manual is 
correct then let's close this bug report!

bug#65522: Documentation for some home services disappeared from 1.4 manual

[nils]

> Simon Tournier  hat am 05.09.2023 17:18 CEST 
> geschrieben:
> 
>  
> Hi,
> 
> On Fri, 25 Aug 2023 at 08:16, nils@landt.email wrote:
> 
> > I noticed some help nodes under 
> > https://guix.gnu.org/en/manual/en/html_node/Home-Services.html disappeared 
> > fairly recently.
> > They are still available in the devel docs under 
> > https://guix.gnu.org/en/manual/devel/en/html_node/Home-Services.html
> >
> > The following topics are missing:
> > * GPG: GNU Privacy Guard.   Setting up GPG and related tools.
> > * Fonts: Fonts Home Services.   Services for managing User's fonts.
> > * Sound: Sound Home Services.   Dealing with audio.
> > * Mail: Mail Home Services. Services for managing mail.
> > * Messaging: Messaging Home Services.  Services for managing messaging.
> > * Media: Media Home Services.   Services for managing media.
> > * Networking: Networking Home Services.  Networking services.
> > * Miscellaneous: Miscellaneous Home Services.  More services.
> >
> > This makes sense when looking at the 1.4.0 git tag, but I had a browser tab 
> > open, and https://guix.gnu.org/manual/en/html_node/Mail-Home-Services.html 
> > was definitely available just a day or two ago.
> >
> > I don't know if this is actually an issue or an intended change, but it 
> > seemed better to report it than to ignore it.
> 
> I am sorry, I am not sure to understand what the bug is about. :-)
> 
> This webpage
> <https://guix.gnu.org/en/manual/en/html_node/Home-Services.html> points
> to the manual as it was for the last release.  It means, this manual
> wepage is frozen and is only updated at each release.  If you have seen
> something different, it is an artifact that should not be possible.
> 
> For instance, the service
> 
> * GPG: GNU Privacy Guard.   Setting up GPG and related tools.
> 
> had been added on Sat Apr 8 22:56:19 2023 +0200 which is after the
> release 1.4.0.
> 
> There is no bug and I am favor to close it.  WDYT?

If this is intended and expected, then feel free to close it, sure.
But it's certainly changed behaviour. I had 
https://guix.gnu.org/manual/en/html_node/Mail-Home-Services.html open in a 
browser tab for more than a month, and on 2023-08-23 it was suddenly 404 
¯\_(ツ)_/¯

bug#22543: 404 in Manualpage

[Nils Gillmann]

The manual page
https://www.gnu.org/software/guix/manual/html_node/Requirements.html#Requirements

contains a link to

https://www.gnu.org/software/guix/manual/gnutls-guile/Guile-Preparations.html#Guile-Preparations

which give a 404. I am not familiar with what's supposed to be there, a
quick search for "gnutls-guile/Guile-Preparations.html" in duckduckgo gives me
http://www.gnutls.org/manual/gnutls-guile/Guile-Preparations.html as one
of 2 results.

Should I fix the link to this one and send in a patch?

Thanks,
-- 
ng/ni*
vcard: http://krosos.sdf.org

bug#22573: critical error during 'guix pull'

[Nils Gillmann]

Hi, today 15:30 EU/Berlin Timezone I started guix pull and got this output:

Starting download of /tmp/guix-file.bHtiW7
>From http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 master.tar.gz  1KiB2.5MiB/s 00:00 [] 100.0%
unpacking '/gnu/store/ig37bb33y7vnpay722b541ljlqvmyjbm-guix-latest.tar.gz'...

gzip: stdin: not in gzip format
/gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Child returned 
status 1
/gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Error is not 
recoverable: exiting now
guix pull: error: failed to unpack source code

-- 
ng/ni*
vcard: http://krosos.sdf.org

bug#22573: critical error during 'guix pull'

[Nils Gillmann]

Leo Famulari  writes:

> On Sat, Feb 06, 2016 at 03:33:56PM +0100, Nils Gillmann wrote:
>> Hi, today 15:30 EU/Berlin Timezone I started guix pull and got this output:
>> 
>> Starting download of /tmp/guix-file.bHtiW7
>> From http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
>>  master.tar.gz  1KiB2.5MiB/s 00:00 [] 
>> 100.0%
>> unpacking '/gnu/store/ig37bb33y7vnpay722b541ljlqvmyjbm-guix-latest.tar.gz'...
>> 
>> gzip: stdin: not in gzip format
>> /gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Child returned 
>> status 1
>> /gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Error is not 
>> recoverable: exiting now
>> guix pull: error: failed to unpack source code
>
> Since the capabilities of hydra.gnu.org are sometimes outstripped by
> user demand, users sometimes experience repeatable network failures
> while downloading. We have raised the funds to buy a more powerful
> machine for hydra.gnu.org and to host it.
>

I tend to forget this, thanks for the reminder.

> Do you know if this succeeded for you during the period while the Guix
> git repository's HEAD was unchanged? Althought, I don't see how state of
> HEAD could make a difference to whether or not the gzip encoding was
> successful.
>

I'm not sure, and maybe I should raise my personal level for reporting
things hydra related. I tried 5-8 times with failures, and minutes later
it succeeded. I can't point anymore what was going on, the logs tell me
the only commit ~7 hours ago was icecat.

As this is not really a bug it could be closed if there's nothing more I
could provide?

-- 
ng/ni*
vcard: http://krosos.sdf.org

bug#22573: closed

[Nils Gillmann]

Problem solved,
problem wasn't really a problem and details couldn't be provided.

-- 
ng/ni*
vcard: http://krosos.sdf.org

bug#22546: Download-Page is "hiding" what the options actually are

[Nils Gillmann]

l...@gnu.org (Ludovic Courtès) writes:

> Robin Vobruba  skribis:
>
>> Being new to Guix, i went to the Download page:
>> https://www.gnu.org/software/guix/download/
>>
>> immediately saw the 3 big options
>> read their title/names
>> was confused what the difference might be between "GuixSD" and "Guix Binary"
>> could not find anything inside these 3 option's boxes that would help me
>> read the text below them
>> read the text above them
>> finally understood that the first option is the OS, and the second is only
>> the packag-manager
>
> I think I’ll have to disagree.  :-)
>
> For each option there’s a line right below the title saying what this
> is.  I’m no expert in “information architecture” but I’m under the
> impression that there’s little margin for improvement.
>

SD has a different Symbol than Guix, which works okay for me with
no colorblindness and no other visual problems.
But maybe it could help to highlight the 'System Distribution'
and to visually (with colors in accordance to w3 disability
standards) set apart GUIX from GUIXSD boxes?
Or, like fr example TAILS who now have some kind of questionaire
tour to the right download.

There are some things I am collection thoughts on, where the
actual output of them is slowed down by working on too many texts
at the same time.

> More importantly, I think that someone who cannot be bothered to read
> this will not install the thing at all since installing requires you to
> read the much longer installation instructions.  Of course we want them
> to be as small as possible, but I don’t think that’ll be a single line
> anytime soon.
>
> I hope this makes sense!
>
> Thanks for your feedback,
> Ludo’.
>
>
>

-- 
ng

bug#22543: 404 in Manualpage

[Nils Gillmann]

Leo Famulari  writes:

> On Wed, Feb 03, 2016 at 02:41:04PM +0100, Nils Gillmann wrote:
>> The manual page
>> https://www.gnu.org/software/guix/manual/html_node/Requirements.html#Requirements
>> 
>> contains a link to
>> 
>> https://www.gnu.org/software/guix/manual/gnutls-guile/Guile-Preparations.html#Guile-Preparations
>> 
>> which give a 404. I am not familiar with what's supposed to be there, a
>> quick search for "gnutls-guile/Guile-Preparations.html" in duckduckgo gives 
>> me
>> http://www.gnutls.org/manual/gnutls-guile/Guile-Preparations.html as one
>> of 2 results.
>> 
>> Should I fix the link to this one and send in a patch?
>
> Yes, please!

So you think I should (and can?) fix it, while alex replies:

>> I don't think you can send a patch for this.  According to
>> <https://www.gnu.org/software/guix/manual/>:
>>
>>  (This page generated by the gendocs.sh¹ script.)

>> This "gendocs.sh" uses "texi2html" to convert our texinfo documentation
>> (see "doc/guix.texi" in the guix git repo) to the html page.  In
>> "guix.texi" the link you are talking about is a usual link to the
>> "gnutls-guile" manual.  I didn't look at "texi2html" but I believe by
>> default it just assumes that all the manuals are placed at
>> "www.gnu.org/software//manual/", so for "external" manuals the
>> generated links are false.  For example, there are also wrong links to
>> Geiser and Magit-Popup manuals.
>>
>> So I think it's a general thing for all generated manuals that are
>> placed on "gnu.org".
>>
>> ¹ http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/gendocs.sh
>>
>> -- 
>> Alex

Okay, so I guess it's related to #22651 and it#s not fixable the
way I want to (edit the source), or at least what I would want to
do is not optimal and it should be fixed in some other way.

Didn't look into it yet, but should we follow #22651 for the 404s?
-- 
ng

bug#22732: lispf4: broken

[Nils Gillmann]

I packaged lispf4 for Guix, tried to debug it alone for a while
now, got other peoples input, tested different GNU systems, still
can't reproduce the errors I get on Guix and other GNU systems.

This is a bit vague but the actual error output is just too long
for this email.
TL;DR is SYSATOMS even when in the same directory with any
permission I tried fails to get opened. SYSATOMS is essential for
lispf4 to work.

I contacted the author of the port (Blake McBride), it will take
some weeks until he can help, but he'll definitely help to
debug the issue.
I will update and later close this issue as soon as we are done
fixing it.

thanks,
-- 
ng

bug#22848: xrandr installation (probably) stales with ftp downloads

[Nils Gillmann]

Various download errors during `guix package -i xrandr`, might be
related to another ftp related bug. It is still in process, but
not responding for some time now:

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From ftp://xorg.mirrors.pair.com/individual/app/xrandr-1.5.0.tar.bz2...
ERROR: In procedure connect: Connection timed out

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From 
>http://mirror.csclub.uwaterloo.ca/x.org/individual/app/xrandr-1.5.0.tar.bz2...
ERROR: download failed 
"http://mirror.csclub.uwaterloo.ca/x.org/individual/app/xrandr-1.5.0.tar.bz2"; 
404 "Not Found"

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From http://xorg.mirrors.pair.com/individual/app/xrandr-1.5.0.tar.bz2...
ERROR: download failed 
"http://xorg.mirrors.pair.com/individual/app/xrandr-1.5.0.tar.bz2"; 404 "Not 
Found"

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From http://mirror.us.leaseweb.net/xorg/individual/app/xrandr-1.5.0.tar.bz2...
ERROR: download failed 
"http://mirror.us.leaseweb.net/xorg/individual/app/xrandr-1.5.0.tar.bz2"; 404 
"Not Found"

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From ftp://artfiles.org/x.org/individual/app/xrandr-1.5.0.tar.bz2...
ERROR: Throw to key `ftp-error' with args `(# "CWD 
individual" 550 "individual: No such file or directory\r")'.

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From ftp://ftp.chg.ru/pub/X11/x.org/individual/app/xrandr-1.5.0.tar.bz2...

-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
http://loupsycedyglgamf.onion/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22848: xrandr installation (probably) stales with ftp downloads

[Nils Gillmann]

(continuation of first output posted) and it fails:

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From ftp://ftp.kaist.ac.kr/x.org/individual/app/xrandr-1.5.0.tar.bz2...
ERROR: Throw to key `ftp-error' with args `(# "RETR 
xrandr-1.5.0.tar.bz2" 550 "Failed to open file.\r")'.

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From ftp://mirrors.go-part.com/xorg/individual/app/xrandr-1.5.0.tar.bz2...
ERROR: In procedure connect: Connection refused

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From http://x.cs.pu.edu.tw/individual/app/xrandr-1.5.0.tar.bz2...
ERROR: download failed 
"http://x.cs.pu.edu.tw/individual/app/xrandr-1.5.0.tar.bz2"; 404 "Not Found"

Starting download of 
/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2
>From ftp://ftp.is.co.za/pub/x.org/individual/app/xrandr-1.5.0.tar.bz2...
ERROR: Throw to key `ftp-error' with args `(# "CWD 
x.org" 550 "x.org: No such file or directory\r")'.
failed to download 
"/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2" from 
"mirror://xorg/individual/app/xrandr-1.5.0.tar.bz2"
builder for 
`/gnu/store/wxl9dc6pr9dly5jla93b6kdqbzncf9n2-xrandr-1.5.0.tar.bz2.drv' failed 
to produce output path 
`/gnu/store/dhkrdvf1smm3976h2z1f8gvjni47b51y-xrandr-1.5.0.tar.bz2'
cannot build derivation 
`/gnu/store/2rv5crp1pypfflbfqhvlr8kgd0kihdsv-xrandr-1.5.0.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/3ndqhddqp56xq70fqxq4kh392xg9fb9k-profile.drv': 1 dependencies 
couldn't be built
guix package: error: build failed: build of 
`/gnu/store/3ndqhddqp56xq70fqxq4kh392xg9fb9k-profile.drv' failed

-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
http://loupsycedyglgamf.onion/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22848: xrandr installation (probably) stales with ftp downloads

[Nils Gillmann]

This can be closed, or will be closed by myself in the next 2
days when I remember to check how to close it.



thanks,
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22848: xrandr installation (probably) stales with ftp downloads

[Nils Gillmann]

It's possible that I just ran into a temporary problem.
I got these errors, I changed location that day (another ISP,
another city) and the error while trying to install xrandr was
gone.
Bad closing description, but that's as detailed as it can get
this time.
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22907: `guix package -u` fails

[Nils Gillmann]

guix package -u (and also the variation below) fails after a
successful guix pull and succesfull grafting and reboot:

niasterisk@khazad-dum ~$ time guix package --substitute-urls=hydra.gnunet.org 
--dry-run -u
^C

real26m0.898s
user15m35.916s
sys 3m39.380s


-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22908: guix download choices (unfonts -> upstream, archive.org bugged) and my alternatives.

[Nils Gillmann]

This references thread
"fonts.scm -> packaging "un-fonts", download isses"
on guix-devel and it classifies as a bug.
It's a bug upstream, replicated by archive.org and preventing me
from finishing my work.

Long story short, I try to package un-fonts, which sits on a
server which is configured in a way that it gives us a mime type
for the package which is invalid (.gz). Now somebody could make
guix download function to simply ignore that, but as I don't like
to do that with only this one known case at hand, my ideas are:

- download the file to sdf.org where it will sit until something
  happens to the entire internet and sdf.org disappears (they
  have been around since 84/87).
- upload the individual file to archive.org as the simple
  waybackmachine is not smart enough to fix the mime issue of the
  original server.

This is a bug, because it prevents me from using guix download,
and guix download from functioning in a way where it must be
altered to adopt to the incompetence of some domain/server
admin.


what do you think?
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22907: `guix package -u` fails

[Nils Gillmann]

niasterisk@khazad-dum ~$ time guix package --substitute-urls=hydra.gnu.org 
--dry-run -u *.*

real0m1.779s
user0m1.824s
sys 0m0.060s
niasterisk@khazad-dum ~$ time guix package --substitute-urls=hydra.gnunet.org 
--dry-run -u *.*

real0m1.763s
user0m1.808s
sys 0m0.056s
niasterisk@khazad-dum ~$ guix package --substitute-urls=hydra.gnunet.org 
--dry-run -u *.*
niasterisk@khazad-dum ~$ guix package --substitute-urls=hydra.gnunet.org -u *.*
niasterisk@khazad-dum ~$ 

so yes, it works but still nothing happens. Could be that there's
just no updates, but I should not have to provide *.* as it
worked before with just `guix package -u`

Although... does graffting after guix pull rebuild and update the
packages in the profile? current gen is after the update:

Generation 85   Mar 04 2016 12:30:38(current)

-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22908: guix download choices (unfonts -> upstream, archive.org bugged) and my alternatives.

[Nils Gillmann]

l...@gnu.org (Ludovic Courtès) writes:

> retitle 22908 HTTP client rejects invalid 'Content-Type' headers
> thanks

I can retitle open bugs? If so, how? Or is there a "help"
function of the debuggs?

> (Please make sure the title of your messages to bug-guix clearly
> describes the problem with phrases like “Guix fails to …”, “Failure to
> download from …”, etc.)
>
> Nils Gillmann  skribis:
>
>> Long story short, I try to package un-fonts, which sits on a
>> server which is configured in a way that it gives us a mime type
>> for the package which is invalid (.gz).
>
> As Ricardo noted in
> <https://lists.gnu.org/archive/html/guix-devel/2016-02/msg01359.html>,
> the problem is that Guile’s HTTP client is (too) strict and rejects this
> invalid ‘Content-Type’ header from kldp.net:
>
>   Content-Type: .gz

I noticed, that's why I packaged and submitted (see more recent
version of the patch, new thread) the font with a location on
sdf.org. I commented inside why and what I intend to do.

> There are two courses of actions that can be taken in parallel:
>
>   1. Get the kldp.net admins to adjust the Web server.  Did you get
>  feedback from them?

Not yet. They are behind a privacywhois, I am not sure how long
reaction will get delayed due to that factor. The bug has been
reported to them, now it's just waiting and maybe getting a
response later this year.

>   2. Make Guile’s HTTP client more permissive.

I vote against that, because it is just one package so far. Let's
say we package KDE Plasma and there are more than 1 package which
is not a font, that is a reason to make changes to the http client.

> In the meantime, we could work around the issue by using a copy hosted
> on another server, if possible, such as archive.org or sdf.org as you
> note, or fossies.org (it mirrors a number of things.)
>
> Thoughts?

Archive.org replicates every wrong and right including mime
types. -> same issue, different domain.

I did not upload the font itself to archive.org but to sdf.org ,
I should also get a reply from in-berlin.org (an ISP, fast
datacenters) if they have a public download host and would like
to host this font outside of the kldp.net domain, explaining the
reasons etc.


> Thanks,
> Ludo’.

thanks,
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22985: using gnune-gtk with ratpoison (gnunet-fs in -gtk nonfunctional) -> needs participation and input

[Nils Gillmann]

This describes a bug with our gnunet-gtk package I am tracking
now in gnu/packages/gnunet.scm and will include it to refer to in
the patch I will send in as soon as I have enough time on this
conference to rebase my (big) patch of gnunet.scm

Description/Problem:

- Using ratpoison as WM, running gnunet-gtk (svn) gives GSettings
  related errors when opening gnunet-fs (filesharing) tab.
  The error gets more specific when installing gsettings into
  your profile (see irc log, 10.03.2016, grep for "gnunet"
  "gsettings"). I can't be more precise at the moment due to the
  lack of time. I provided some details on IRC on thursday, if I
  have the time this weekend I'll add the exact error messages
  you'll experience, though they are obvious in the terminal
  output.

- Reconfiguring the system with xfce in the desktop profile seems
  to provide more than ratpoison, the bug is gone. I have to
  assume that xfce provides gsettings on its own, and that this
  error is specific to minimal window managers without certain
  X11/gtk profiles or otherwise configuration settings which get
  delivered with xfce and the like.

The output (from memory) is visible when you kill/close
gnunet-gtk, look for something related to gnunet-fs ... GIO
 GSettings  and later: org.gtk.FileChooser (or something
like that), also in relation to gnunet-fs.

I want people to do the following:
- Install gnunet and gnunet-gtk (both 0.10.1), skip over
  gnunet-setup, and see in gnunet-gtk after running "gnunet-arm
  --start" if the tab for filesharing / publishing is just
  black. In either case of positive or negative confirmation I
  want to know about the used desktop/window manager and
  environment variables to nail down the problem.
- Do the exact same for gnunet-gtk-svn + gnunet-svn.


This bug is published before gnunet-svn, gnunet-gtk-svn and other
changes to gnu/packages/gnunet.scm are send in as patches. I am
currently not in reach of a permanent connection and will provide
rebase and create a patch as soon as I can. Time and too much
input in talks is another factor keeping me from currently
rebasing the patch against master.
Just know that the patch is functional and this bug is considered
something people using windowmanagers equal to ratposion should
help me in solving, as this is caused by an external factor I
have to pin and optimize the gnunet package on or provide a note
for certain environments. In itself, based on a work I
co-authored with Jookia, it is functional.


Sorry if this might read verbose or confusing but I write this
based on something I have written between yesterday, this morning
and in between rushing to the next talk :)

Thanks for your patience,
-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22985: using gnune-gtk with ratpoison (gnunet-fs in -gtk nonfunctional) -> needs participation and input

[Nils Gillmann]

Experienced same behavior when I added gnome to my profile and
launched it today, steps to replicate:

gnunet-arm -s &
gnunet-gtk

expected error:

(gnunet-fs-gtk:32585): GLib-GIO-ERROR **: Settings schema 
'org.gtk.Settings.FileChooser' is not installed

in terminal, and gnunet-fs tab is black.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

bug#22985: using gnune-gtk with ratpoison (gnunet-fs in -gtk nonfunctional) -> needs participation and input

[Nils Gillmann]

Previously reported GNOME bug solved after reconfiguring the
system with (services (gnome-desktop-service)).

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

bug#22985: using gnune-gtk with ratpoison (gnunet-fs in -gtk nonfunctional) -> needs participation and input

[Nils Gillmann]

Leo Famulari  writes:

> On Sun, Mar 20, 2016 at 03:05:25PM +0100, Nils Gillmann wrote:
>> Previously reported GNOME bug solved after reconfiguring the
>> system with (services (gnome-desktop-service)).
>
> Okay, so the problem is solved then?

No, please read the full initial bug.

It is not a GNOME bug, it is a bug where I need input from other
people about issues with the gnunet.scm I did send in and
eventually with the 0.10.1 gnunet as well.
And also somebody to apply the gnunet.scm patchset to master, but
I give it one more day until I try to draw attention to that
patch again.

I don't have the resources to figure out every possible
windows/desktop manager issues, which is what the initial bug
report said.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

bug#23106: rxvt-unicode is missing .desktop file(s)

[Nils Gillmann]

urxvt / rxvt-unicode has no .desktop files in Guix and therefore
does not show up in application menus like GNOME provides.


Whoever wants to fix it faster than I do (currently occupied with
psyced related packages), here is my work in progress part of the
rxvt-unicode package.

.desktop files can be found in the source dir of gentoo and
archlinux
(https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/rxvt-unicode)

Code below has not been tested, it may need some fixes, and we
need at least 3 like in archlinux.

(arguments
 ;; This sets the destination when installing the necessary terminal
 ;; capability data, which are not provided by 'ncurses'.  See
 ;; https://lists.gnu.org/archive/html/bug-ncurses/2009-10/msg00031.html
 '(#:make-flags
   (list (string-append "TERMINFO="
(assoc-ref %outputs "out")
"/share/terminfo"))
   #:phases
   (modify-phases %standard-phases
 (add-after
 'install 'install-desktop
   (lambda _
 (let ((desktop (string-append %output "/share/applications")))
   (mkdir-p desktop)
   (call-with-output-file
   (string-append desktop "/urxvt.desktop")
 (lambda (port)
   (format port "~
 [Desktop Entry]~@
 Name=~a~@
 Comment=~a~@
 TryExec=~a/bin/urxvt~@
 Exec=~a/bin/urxvt~@
 Icon=terminal~@
 Type=Application~@
 Categories=GNOME;GTK;Utility;TerminalEmulator;System;~@
 StartupNotify=true~%" ,name ,synopsis %output)

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

bug#27284: ‘guix pull’ builds using multiple derivations

[Nils Gillmann]

Awesome news!

Ludovic Courtès transcribed 3.1K bytes:
> Hello Guix!
> 
> News from the front!  I’ve pushed a new ‘wip-pull-multiple-derivations’
> branch that keeps the same approach as previously proposed (building
> Guix using multiple derivation, one for each group of modules: core,
> CLI, packages, etc.), but does not attempt to reload modules in the
> running Guile process, which proved to be too tricky.
> 
> You can already test with:
> 
>   guix pull --branch=wip-pull-multiple-derivations
>
> Feedback welcome!

I think you forgot to push it or you are on a very slow connection :)
 
> This patch set actually addresses a bootstrapping issue: you need Guix
> to build Guix.  So far ‘guix pull’ would sidestep the bootstrapping
> issue by building Guix with whatever is available in the currently
> deployed Guix; for instance, it would use the ‘guile’, ‘guile-json’,
> etc. packages from the current Guix.  The problem of that approach was
> that it’s stateful: the result depends on what you currently have.
> Sometimes what you have is too old, or lacks some package definition,
> and you can’t really go forward.
> 
> The code in ‘wip-pull-multiple-derivations’ works like this:
> 
>   1. Assume we have Guile and Guix already installed, but not
>  necessarily the latest versions thereof.
> 
>   2. Using the (guix …) modules that we have, build a program—a
>  “trampoline”—that will use the modules of the target Guix (the
>  commit we want to pull) to compute the derivation of that Guix.
> 
>   3. Run that trampoline, which returns /gnu/store/…-guix.drv.  The
>  result should be the same regardless of the initial Guix because
>  the trampoline uses exclusively modules from the target Guix.
> 
>   4. ‘guix pull’ builds that derivation (actually the branch does not
>  modify (guix scripts pull) at all; everything is in
>  build-aux/build-self.scm.)
> 
> In step #4, we should be able to get substitutes for at least some of
> the derivations.
> 
> To build the trampoline in step #2, we first need to build a bunch of
> modules from the target Guix.  Hopefully you don’t have to rebuild them
> at each pull, but it can take a minute or so, and you may not have
> substitutes for that (because this part is stateful.)
> 
> In step #3, the trampoline has compiled code for the core modules, but
> it still has to interpret (gnu packages guile) and related modules,
> because these are not compiled.  The program runs in ~40s on my laptop.
> To make it faster, we could reduce the closure of (gnu packages guile)¹,
> but that can be tricky.  Or we could optimize Guile itself; I’m sure the
> compiler and/or interpreter could do better.
> 
> In that branch, you can also run:
> 
>   make as-derivation
> 
> and it will build Guix from $srcdir in the way described above.
> 
> To summarize, performance is not great, but hopefully it’ll be slightly
> better than what we have now, especially with substitutes.
> Correctness/reproducibility are greatly improved.
> 
> Ludo’.
> 
> ¹ The closure of (gnu packages guile) contains python, haskell-check,
>   music, and many other surprising things:
>   .
> 
> 
> 

bug#22629: Towards a new 'guix pull'

[Nils Gillmann]

Ludovic Courtès transcribed 2.0K bytes:
> Hello Guix!
> 
> l...@gnu.org (Ludovic Courtès) skribis:
> 
> > Here’s a series of improvements that I think we should make in ‘guix
> > pull’:
> >
> >   • Use Git instead of downloading a whole snapshot every time.  The Git
> > checkout would be kept in ~/.cache/guix/pull/checkouts, say.
> 
> That was done a while back.   :-)
> 
> >   • Build & install not only Scheme code, but also locales and the Info
> > manual.
> 
> … and also the C++ bits.
> 
> With the work done in , we can build all of
> Guix and its dependencies when doing ‘guix pull’, which brings us closer
> to what the ‘guix’ package provides.
> 
> Thus we can at least partly address the issue described in
> , i.e., have
> ‘guix pull’ install not just a bunch of .go files but also guile-git,
> guile-ssh, gnutls, and Guile itself.
> 
> To do that, we need a “paradigm shift” (sounds cute, no? :-)).
> Currently, ‘scripts/guix’ fiddles with its %load-path and adds
> ~/.config/guix/latest if it exists.  The new ‘guix pull’ should provide
> not just .go files but also a ‘guix’ command referring to the latest
> Guile, Guile-Git, etc.
> 
> To achieve this, I think the new approach would be to have:
> 
>   export PATH=$HOME/.config/guix/current/bin:$PATH
>   export INFOPATH=$HOME/.config/guix/current/share/info:$INFOPATH
>   …
> 
> ‘guix pull’ would update ~/.config/guix/current, which would contain the
> ‘guix’ command, all the .go files, locales, the Info manual, and ideally
> ‘guix-daemon’ as well.
> 
> ~/.config/guix/current could be a profile, or something that resembles a
> profile.
> 
> For a while ‘guix pull’ will have to keep updating ~/.config/guix/latest
> as well, for users running an old ‘guix’ command.
> 
> Thoughts?

First thought: Woo! Good progress!
On your propossed steps, sounds good to me.

> Ludo’.
> 
> 
> 

bug#31337: Unable to use gnuk usb smartcard token on GuixSD

[Nils Gillmann]

Vagrant Cascadian transcribed 3.3K bytes:
> I've been unable to use my gnuk usb smartcard token with gnupg on
> GuixSD, and it appears this is because scdaemon is built without libusb
> support:
> 
>   $ gpg --card-status
>   gpg: selecting openpgp failed: No such device
>   gpg: OpenPGP card not available: No such device
> 
> Attached is a patch that gets scdaemon working for me and a gnuk...
> 
> Unfortunately, enabling libusb causes one of the tets to hang
> indefinitely:
> 
>   PASS: tests/openpgp/decrypt-session-key.scm
>   Checking unwrapping the encryption.
>   > encsig-2-keys-3 encsig-2-keys-4 <
>   PASS: tests/openpgp/decrypt-unwrap-verify.scm
>   Checking signing with the default hash algorithm
>   >

There should be a test-suite.log in some location in the build chroot,
have you checked that? You might need to build with -K.

> So far, I've only been able to get it to work by disabling the
> tests... so it's obviously not a good idea to enable without further
> troubleshooting.
> 
> Another option might be to use pcsc-lite and ccid, but I had even less
> luck getting that to work.
> 
> 
> live well,
>   vagrant
> 
> 
> diff --git a/gnu/packages/gnupg.scm b/gnu/packages/gnupg.scm
> index f397482ab..0e9e72784 100644
> --- a/gnu/packages/gnupg.scm
> +++ b/gnu/packages/gnupg.scm
> @@ -39,6 +39,7 @@
>#:use-module (gnu packages curl)
>#:use-module (gnu packages crypto)
>#:use-module (gnu packages emacs)
> +  #:use-module (gnu packages libusb)
>#:use-module (gnu packages openldap)
>#:use-module (gnu packages perl)
>#:use-module (gnu packages perl-check)
> @@ -232,6 +233,7 @@ compatible to GNU Pth.")
> ("libgcrypt" ,libgcrypt)
> ("libgpg-error" ,libgpg-error)
> ("libksba" ,libksba)
> +   ("libusb" ,libusb)
> ("npth" ,npth)
> ("openldap" ,openldap)
> ("pcsc-lite" ,pcsc-lite)
> @@ -246,12 +248,17 @@ compatible to GNU Pth.")
>"--enable-all-tests")
>#:phases
>(modify-phases %standard-phases
> + ;; (delete 'check)
>  (add-before 'configure 'patch-paths
>(lambda* (#:key inputs #:allow-other-keys)
>  (substitute* "scd/scdaemon.c"
>(("\"(libpcsclite\\.so[^\"]*)\"" _ name)
> (string-append "\"" (assoc-ref inputs "pcsc-lite")
>"/lib/" name "\"")))
> +(substitute* "configure"
> +  (("/usr/include/libusb-1.0")
> +   (string-append (assoc-ref inputs "libusb")
> +  "/include/libusb-1.0")))
>  #t))
>  (add-after 'build 'patch-scheme-tests
>(lambda _

bug#31356: Some videos don't work with recent Icecat

[Nils Gillmann]

Clément Lassieur transcribed 409 bytes:
> Hi,
> 
> Recent Icecat can't play some videos, like this one:
> 
> https://www.radioradicale.it/scheda/540252/operazione-black-job-illustrazione-dei-dettagli-del-blitz-contro-la-corruzione
> (thank you catonano for the link and for reporting it on IRC).
> 
> Whereas an older one (say,
> /gnu/store/s85ykg7ggz8vlc0rf7ccjyz1af9n1q73-icecat-52.3.0-gnu1/bin/icecat)
> can play them.
> 
> It should be bisectable.
> 
> Cheers,
> Clément
> 

Hi, thanks for reporting it.

This is not a bug, however it has been reported multiple times in the past.
This is a not so obvious reminder that you need to install the some of the
codecs into your global or user profile.

bug#31356: Some videos don't work with recent Icecat

[Nils Gillmann]

Clément Lassieur transcribed 475 bytes:
> Nils Gillmann  writes:
> 
> > Hi, thanks for reporting it.
> >
> > This is not a bug, however it has been reported multiple times in the past.
> > This is a not so obvious reminder that you need to install the some of the
> > codecs into your global or user profile.
> 
> Hi ng0,
> 
> I'd be happy to know about codecs that can be installed in one's profile
> (and thus aren't shipped with the Icecat package) and would improve
> Icecat user experience.
> 
> Thanks,
> Clément

Hm... usually I would've replied "the gstreamer ones, -ugly, -base, -good"
but I don't have them installed. I am not using icecat and for my aurora esr
package I think videos just work.

I'm running an update here so I can't install anything right now, but in
the past the gst plugins would've been my definite reply if something was
missing.

Sorry for assuming I had this. I have over 270 profile generations, nothing
showed up indicating that this time I have this.

bug#31786: 'pre-inst-env guix --version' is not updated by new commits"

[Nils Gillmann]

George Clemmer transcribed 3.9K bytes:
> 
> Ludovic Courtès  writes:
> 
> > Hi George,
> >
> > George Clemmer  skribis:
> >
> >> Leo Famulari  writes:
> >>
> >>> On Wed, Jun 13, 2018 at 08:54:49AM +0200, Ludovic Courtès wrote:
>  The other aspect, from a maintenance and readability viewpoint, is that
>  we could quickly add up lots of explanations that we’ll have to keep
>  up-to-date and that may make more important information harder to find.
> >>>
> >>> Yeah, I'm worried about this too. It's tough to strike the correct
> >>> balance.
> >>
> >> IMO Guix is great for hackers, maintainers and sysops. The doc is
> >> appropriate for such users, well done, spare, and already voluminous.
> >>
> >> This footnote suggestion, and others rejected in the past, are motivated
> >> by my assumption that you will want to make Guix attractive to less
> >> sophisticated users.
> >>
> >> Maybe my assumption is wrong? Maybe you want only "elite" users?
> >
> > No, definitely not; I’m sorry if this is the impression this gave.
> >
> > Like I wrote, my main concern is about keeping the documentation focused
> > and maintainable.  Sometimes we have to document things that are
> > technically outside of Guix because there’s no real canonical
> > documentation and because users would be impaired without it—I’m
> > thinking for instance of bits in the “Preparing for Installation”
> > section.
> >
> > In this case, we’d be documenting something that’s both outside of Guix
> > and not vital for routine usage, and that’s mostly covered by the
> > Autoconf manual.  Hence my reluctance.
> >
> > I hope that makes sense.
> 
> Hi Ludo’,
> 
> I see the situation this way:
> 
> The current doc reflects the needs and sensibilities of the hackers,
> maintainers, and sysops that have built Guix. These "elite" users have
> different needs and judge what is important quite differently from end
> users. This guarantees that the current doc is inadequate for end users.
> So, if, as you say, you want to make Guix accessible to end users, you
> need to make changes in the doc.  The questions: How? What?

I understand where you are coming from, and I understand the trouble Ludovic
(probably) has to find the right balance of content.
Before I comment more below: I'm trying to adjust to a wide range of
people with the least possible knowledge too in the new GNUnet documentation.
Some documentations I looked at had this introductionary style for elements
when they were first used. Texinfo has this element which seems to be less
used because it renders terrible (or did not try with custom output definitions
so far). It's sort of a box element. It would be good to extend this, at least
that's my current idea, to eventually contribute to Texinfo when I have a better
view on what we want.
Long text short nonsense: you end up with lots of work and long books if you
do it right. It should be done this way. Maybe if not directly applied we
could collect the proposals somewhere in the repository? I've recently
started to strip out a whole chapter with repetive installation instructions
in GNUnet. A while back I would've argued for keeping it, that we really
need to cover and guide every case.
Some projects have written "An introduction to..." books to lead up to
the manual.
In my opinion access to knowledge should be easy and without much 'rough
edges' to get it.
Do we keep it selfcontained? Reference other books? A middle path? It's
difficult to get it right if you don't have the time to think about this
as a fulltime job.

> May I suggest ...
> 
> a) Adopt a less defensive posture when responding to user questions,
>comments, and bug reports.
> 
> b) Be pro-active about capturing support resolutions in the doc.
> 
> This thread presents a nice example of what I am talking about. To
> recap:
> 
> I said: I use 'pre-inst-env guix' this way and this is a bug.
> 
> You said: Developers expect this, so it's not a bug.
> 
> A less defensive response: Hmm, You are using 'pre-inst-env guix' in a
> way we didn't anticipate. What are the benefits of using it this way? I
> see how this is a bug for your use case.
> 
> We discussed a workaround. I suggested adding it to the doc.
> 
> You said: I’m not comfortable documenting this because it’s nothing
> specific to Guix.
> 
> I said: I urge you to reconsider.
> 
> You said: This part of the manual targets developers... they know where
> to look things up. [The more we write the more we have to maintain.]

Do we really have to assume that everyone has the same skilset who wants
to get involved? Not about this topic, but in general? I think the assumption
that we share the same knowledge is difficult. Part of the excercise is to
reach out, actively, in person. Another part is to try and do it in text (be
it on a website or a (new) chapter in a manual).

> And Clément Lassieur  added:
> 
> > But non-hacker users can use Guix pull!  Running Guix before it is
> > installed (with pre-inst-env) is described in

bug#26353: GuixSD /tmp cleaner fails to clean when Umlauts like "ä" are used in filenames

[Nils Gillmann]

Danny Milosavljevic transcribed 249 bytes:
> > The problem of how to deal with file name encoding has been discussed on
> > the Guile side so hopefully the next release in the 2.2 series will have
> > a solution for this.
> 
> Hmm, any news on this?  I've again got some immortal files in /tmp ...

Did it ever work for you? I can't recall a single time in my years with
GuixSD when /tmp was cleaned. It was only when I started reading more
system specific code that I found out that the lack of /tmp cleaning
on shutdown is not a default.

bug#32057: gnucash on d88b29d6b78482cdb05ac714984f6a27195e3d37 fails its testsuite

[Nils Gillmann]

gnucash with guix version d88b29d6b78482cdb05ac714984f6a27195e3d37
fails its testsuite. On the record since this version, off the record
for at least a couple of weeks.

last (relevant) part of the log appended.
 85/102 Test  #85: test-tokenizer ...***Failed
0.06 sec
Running main() from gtest_main.cc
[==] Running 7 tests from 1 test case.
[--] Global test environment set-up.
[--] 7 tests from GncTokenizerTest
[ RUN  ] GncTokenizerTest.load_file_nonexisting
/tmp/guix-build-gnucash-3.0.drv-0/gnucash-3.0/gnucash/import-export/csv-imp/test/test-tokenizer.cpp:93:
 Failure
Expected: fw_tok->load_file (file1) throws an exception of type 
std::ios_base::failure.
  Actual: it throws a different type.
/tmp/guix-build-gnucash-3.0.drv-0/gnucash-3.0/gnucash/import-export/csv-imp/test/test-tokenizer.cpp:94:
 Failure
Expected: csv_tok->load_file (file1) throws an exception of type 
std::ios_base::failure.
  Actual: it throws a different type.
[  FAILED  ] GncTokenizerTest.load_file_nonexisting (0 ms)
[ RUN  ] GncTokenizerTest.load_file_existing
[   OK ] GncTokenizerTest.load_file_existing (5 ms)
[ RUN  ] GncTokenizerTest.tokenize_from_csv_file
[   OK ] GncTokenizerTest.tokenize_from_csv_file (0 ms)
[ RUN  ] GncTokenizerTest.tokenize_binary_data
[   OK ] GncTokenizerTest.tokenize_binary_data (1 ms)
[ RUN  ] GncTokenizerTest.tokenize_comma_sep
[   OK ] GncTokenizerTest.tokenize_comma_sep (0 ms)
[ RUN  ] GncTokenizerTest.tokenize_semicolon_sep
[   OK ] GncTokenizerTest.tokenize_semicolon_sep (0 ms)
[ RUN  ] GncTokenizerTest.tokenize_fw
[   OK ] GncTokenizerTest.tokenize_fw (0 ms)
[--] 7 tests from GncTokenizerTest (6 ms total)

[--] Global test environment tear-down
[==] 7 tests from 1 test case ran. (6 ms total)
[  PASSED  ] 6 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] GncTokenizerTest.load_file_nonexisting

 1 FAILED TEST

Start  86: test-tx_import
 86/102 Test  #86: test-tx_import ...   Passed
0.03 sec
Start  87: test-link-qif-imp
 87/102 Test  #87: test-link-qif-imp    Passed
0.00 sec
Start  88: test-link-module-ledger-core
 88/102 Test  #88: test-link-module-ledger-core .   Passed
0.00 sec
Start  89: test-link-module-register-core
 89/102 Test  #89: test-link-module-register-core ...   Passed
0.00 sec
Start  90: test-link-module-register-gnome
 90/102 Test  #90: test-link-module-register-gnome ..   Passed
0.00 sec
Start  91: test-link-module-report-locale-specific-us
 91/102 Test  #91: test-link-module-report-locale-specific-us ...   Passed
0.00 sec
Start  92: test-link-module-report-gnome
 92/102 Test  #92: test-link-module-report-gnome    Passed
4.88 sec
Start  93: test-load-report-gnome-module
 93/102 Test  #93: test-load-report-gnome-module    Passed
4.72 sec
Start  94: test-link-module-report-system
 94/102 Test  #94: test-link-module-report-system ...   Passed
0.83 sec
Start  95: test-load-report-system-module
 95/102 Test  #95: test-load-report-system-module ...   Passed
0.81 sec
Start  96: test-transaction
 96/102 Test  #96: test-transaction .   Passed
5.12 sec
Start  97: test-cash-flow
 97/102 Test  #97: test-cash-flow ...   Passed
0.86 sec
Start  98: test-cashflow-barchart
 98/102 Test  #98: test-cashflow-barchart ...   Passed
1.78 sec
Start  99: test-standard-category-report
 99/102 Test  #99: test-standard-category-report    Passed
2.20 sec
Start 100: test-standard-net-barchart
100/102 Test #100: test-standard-net-barchart ...   Passed
1.73 sec
Start 101: test-standard-net-linechart
101/102 Test #101: test-standard-net-linechart ..   Passed
1.47 sec
Start 102: test-load-report-stylesheets-module
102/102 Test #102: test-load-report-stylesheets-module ..   Passed
1.48 sec

96% tests passed, 4 tests failed out of 102

Total Test time (real) =  77.33 sec

The following tests FAILED:
 22 - test-real-data (Failed)
 34 - test-qof (Child aborted)
 58 - test-gnc-timezone (Failed)
 85 - test-tokenizer (Failed)
Errors while running CTest
make[3]: *** [CMakeFiles/check.dir/build.make:60: CMakeFiles/check] Error 8
make[3]: Leaving directory '/tmp/guix-build-gnucash-3.0.drv-0/build'
make[2]: *** [CMakeFiles/Makefile2:242: CMakeFiles/check.dir/all] Error 2
make[2]: Leaving directory '/tmp/guix-build-gnucash-3.0.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:249: CMakeFiles/check.dir/rule] Error 2
make[1]: Leaving directory '/tmp/guix-build-gnucash-3.0.drv-0/build'
make:

bug#32058: mysql build fails on d88b29d6b78482cdb05ac714984f6a27195e3d37

[Nils Gillmann]

Since I do not have the time to work on this, but there seems to be no open bug:

mysql started a couple of commits ago (since last core-updates merge?) to fail
its build.

[ 62%] Linking CXX shared module group_replication.so
cd /tmp/guix-build-mysql-5.7.21.drv-0/build/rapid/plugin/group_replication && 
/gnu/store/g85ikfjxs2d7aydvg5w06jn2h9xrjmpc-cmake-3.11.0/bin/cmake -E 
cmake_link_script CMakeFiles/group_replication.dir/link.txt --verbose=1
/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/c++ -fPIC  -fPIC 
-Wall -Wextra -Wformat-security -Wvla -Woverloaded-virtual 
-Wno-unused-parameter -O3 -g -fabi-version=2 -fno-omit-frame-pointer 
-fno-strict-aliasing -DDBUG_OFF -fPIC   -shared  -o group_replication.so 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/pax_msg.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_memory.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_vp_str.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_cfg.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_cache.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/node_address.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_msg_queue.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_statistics.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/app_data.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/site_def.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_ssl_transport.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_recover.c.o
 CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/task.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/bitset.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/simset.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/node_set.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_interface.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/node_list.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/task_debug.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/sock_probe.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/task_net.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/synode_no.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_detector.c.o
 CMakeFiles/group_replication.dir/xdr_gen/xcom_vp_xdr.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_logging.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/xplatform/my_xp_cond.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/xplatform/my_xp_thread.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/xplatform/my_xp_mutex.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/xplatform/my_xp_util.cc.o
 CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_view.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_types.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_message.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_member_identifier.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_group_identifier.cc.o
 CMakeFiles/group_replication.dir/libmysqlgcs/src/gcs_interface_factory.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_communication_interface.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_control_interface.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_group_management.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_internal_message.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_networking.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_utils.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_state_exchange.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_group_member_information.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_message_stages.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_view_identifier.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_interface.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_notification.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xc

bug#32058: mysql build fails on d88b29d6b78482cdb05ac714984f6a27195e3d37

[Nils Gillmann]

Tobias Geerinckx-Rice transcribed 5.0K bytes:
> ng0,
> 
> Thanks!
> 
> Nils Gillmann wrote:
> > Since I do not have the time to work on this, but there seems to be no
> > open bug:
> > 
> > mysql started a couple of commits ago (since last core-updates merge?)
> > to fail
> > its build.
> 
> I noticed this yesterday, too. In the meantime, I've tried updating MySQL to
> 5.7.22 (one never knows) and poking at some random bits but that didn't
> help.
> 
> > [build output snipped]
> 
> There's actually an error message[0]. Did it not show up in your logs? I'd
> consider that a bug too.

Odd. I think this was by accident. Here it is:

[ 72%] Building CXX object 
rapid/plugin/x/CMakeFiles/mysqlx.dir/src/expr_generator.cc.o


cd /tmp/guix-build-mysql-5.7.21.drv-0/build/rapid/plugin/x && 
/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/c++  
-DBOOST_ALL_NO_LIB -DBOOST_NO_AUTO_PTR 
-DHAVE_CONFIG_H -DHAVE_LIBEVENT1 -DHAVE_OPENSSL -DMYSQL_DYNAMIC_PLUGIN -DXP
LUGIN_LOG_PROTOBUF -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Dmysqlx_EXPORTS 
-I/tmp/guix-build-mysql-5.7.21.drv-0/build/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/extra/rapidjson/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/buil
d/libbinlogevents/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/libbinlogevents/export 
-isystem 
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/extra/protobuf/protobuf-2.6.1/src
 
-I/tmp/guix-build-mysql-5.7.21.drv-0/build/rapid/
plugin/x 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/protocol/errors
 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/src 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x -I/tmp/guix-bui
ld-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/ngs/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/include/mysql 
-I/tmp/guix-build-mysql-5.7.21.drv-0/bui
ld/rapid/plugin/x/generated 
-I/gnu/store/4n6v2zp5mslq2784j878dmfzzj4vvmza-openssl-1.0.2o/include 
-I/gnu/store/fxiwj2wpp11sif613axdax7gmwzsg6kp-zlib-1.2.11/include -isystem 
/gnu/store/l6hqfwr1hcbn9rg56bwn2d41g2ai36h2-boost-1.66.0/include -i
system /tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/libevent 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/libbinlogevents/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.
21/sql/auth -I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/regex 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/mysqlxtest_src/common
  -fPIC -Wall -Wextra 
-Wformat-security -Wvla -Woverloaded-virtual -Wno-unused-parame
ter -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing 
-DDBUG_OFF -fPIC   
-I/tmp/guix-build-mysql-5.7.21.drv-0/build/rapid/plugin/x/generated/protobuf_lite
 -o 
CMakeFiles/mysqlx.dir/src/expr_generator.cc.o -c /tmp/guix-buil
d-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/src/expr_generator.cc  

   
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc: 
In function ‘void 
handle_gis_exception(const char*)’: 
   
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
 error: expected 
unqualified-id before ‘&’ token 
   
   catch (const 
boost::geometry::detail::self_get_turn_points::self_ip_exception &) 

   

 ^  
   
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
 error: expected ‘)’ before 
‘&’ token   

/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
 error: expected ‘{’ before 
‘&’ token   

/tmp/guix-bu

bug#32058: mysql build fails on d88b29d6b78482cdb05ac714984f6a27195e3d37

[Nils Gillmann]

Ricardo Wurmus transcribed 1.7K bytes:
> 
> Nils Gillmann  writes:
> 
> > Tobias Geerinckx-Rice transcribed 5.0K bytes:
> >> ng0,
> >>
> >> Thanks!
> >>
> >> Nils Gillmann wrote:
> >> > Since I do not have the time to work on this, but there seems to be no
> >> > open bug:
> >> >
> >> > mysql started a couple of commits ago (since last core-updates merge?)
> >> > to fail
> >> > its build.
> >>
> >> I noticed this yesterday, too. In the meantime, I've tried updating MySQL 
> >> to
> >> 5.7.22 (one never knows) and poking at some random bits but that didn't
> >> help.
> >>
> >> > [build output snipped]
> >>
> >> There's actually an error message[0]. Did it not show up in your logs? I'd
> >> consider that a bug too.
> >
> > Odd. I think this was by accident. Here it is:
> 
> This happens when building in parallel; the actual error that caused the
> build to terminate could have occurred hundreds of lines earlier when
> another independent make processes is still running.
> 
> Anyway, thanks for providing the error message.
> 
> > /tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:
> >  In function ‘void
> > handle_gis_exception(const char*)’:
> > /tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
> >  error: expected
> > unqualified-id before ‘&’ token
> >catch (const 
> > boost::geometry::detail::self_get_turn_points::self_ip_exception &)
> 
> The Internet tells me that mysql is very picky about which versions of
> boost it build with.  We use boost 1.66.0 now.
> 
> The mysql package definition contains this comment:
> 
>;; Mysql wants boost-1.59.0 specifically
> 
> and then we proceed to just replace 59 for whatever minor version it is
> we are using.
> 
> Should we just upgrade to the latest version 8.0.11?

It's worth a try. Given that we just have 4 dependent packages for mysql
it could simply be applied.
Since mariadb usually just works in place of
mysql (https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/),
could we attempt to replace and support mysql in kodi with mariadb?

They seem to support mariadb (https://kodi.wiki/view/MySQL):

  MySQL Protocol & MariaDB
  When setting up shared Library databases either MySQL or Maria DB can be used 
as they both use the same MySQL protocol. Since many Linux distributions have 
dropped including MySQL and now instead now ship MariaDB it is being more 
common to use MariaDB for shared Library databases.

> --
> Ricardo
> 

bug#32067: Doc issue

[Nils Gillmann]

Hi Oleg,

Oleg.bocharov transcribed 2.7K bytes:
> Hi,
> 
> Link in documentation is not valid, not pointing to actual image

This is correct, as it is meant to be an example, system should
be substituted by hand.
But the fact that you report it as a problem shows that maybe we
should insert links to correct download locations.

> Does not work:
> "ftp://alpha.gnu.org/guix/guixsd-vm-image-0.14.0.system.tar.xz";
> 
> Works:
> ftp://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz
> 
> Prefix:
> [ftp://alpha.gnu.org/gnu/guix/](ftp://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz)
> 
> Link to documentation page
> https://www.gnu.org/software/guix/manual/html_node/Running-GuixSD-in-a-VM.html
> 
> Regards,
> Oleg
> 
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

bug#32167: Kernel 'build' directory in the store is a broken symbolic link

[Nils Gillmann]

pki...@runbox.com transcribed 94 bytes:
> /run/booted-system/kernel/lib/modules//build is a broken 
> symbolic link.

Yep. This is not a bug until it comes to what you are possibly trying to 
attempt,
build a software which relies on your *current* kernel sources.

For a solution I can point to the Nix package for linux, where they deal with 
this
within the kernel package, for firmware and more. Because I'm short on time 
these
days I haven't sent a patch yet but I can confirm the issues you probably ran 
into
as I had them many months back already.

Mark, you are mostly responsible for the linux module in Guix.

Besides my own notes, this was relevant:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/manual-config.nix#L161

bug#32261: guix packages website: add mechanism to link to individual packages

[Nils Gillmann]

Paul Wise transcribed 1.8K bytes:
> Hi all,
> 
> It used to be possible to link to individual Guix packages like this:
> 
> https://www.gnu.org/software/guix/packages/m.html#myrepos
> 
> Since the recent change to the packages website the packages pages are
> paginated and have no anchors, which means they will break as more
> packages are added and also I cannot link directly to a package,
> only to a location that contains lots of other packages too.
> 
> https://www.gnu.org/software/guix/packages/M/page/3/
> 
> Fixing this would be useful for the Repology support of GNU Guix,
> which currently cannot link to GNU Guix packages:
> 
> https://repology.org/repository/gnuguix
> https://repology.org/metapackage/myrepos/versions
> 
> -- 
> bye,
> pabs
> 
> https://bonedaddy.net/pabs3/

It is not just repology, but easy linking to details for external
parties/downstreams we need to point to somewhere.

I think there were some remaining ideas for the new websites,
where a package gets detail page on its own.


The pages are statically generated, the old "useful" page format
was taking a very long time to load, with each release and increase
of package count we got k more seconds. Nothing I'd like to go back
to.

bug#32310: Not having much luck with running guix of phone and limbo emulator.

[Nils Gillmann]

Gary Hayes transcribed 509 bytes:
> Tried to run vm of guix in limbo but did not work.  Now deleted.  May have
> to stick with iso image live boots in future.

Hi Gary,

I'm sorry for your bad experiences. Can you tell us a bit more about
your problems?

Thanks

bug#32310: [Fwd: Re: bug#32310: Not having much luck with running guix of phone and limbo emulator.]

[Nils Gillmann]

- Forwarded message from Gary Hayes -

> Date: Tue, 31 Jul 2018 12:11:11 +1000
> From: Gary Hayes
> To: Nils Gillmann
> Subject: Re: bug#32310: Not having much luck with running guix of phone and 
> limbo emulator.
> 
> Had issues getting the vm file working in a qemu program limbo.
> Decided to give up at moment and deleted the vm files.  Have been
> experementing with damn small linux now.  Which kind of works but not quite
> well enough yet, but i still need to practice more.
> I am only running qemu on a 1.3ghz 4 core samsung phone so i dont expect
> much to run quickly.
> Best to simulate low end pentiums and 486 machines i think.  Not sure.
> Maybe incompatibilities between programs.  Also tried to find your help
> files on vm files being run and had difficulties geting enough info.
> 
> On 30 Jul 2018 7:49 pm, "Nils Gillmann" wrote:
> 
> Gary Hayes transcribed 509 bytes:
> > Tried to run vm of guix in limbo but did not work.  Now deleted.  May have
> > to stick with iso image live boots in future.
> 
> Hi Gary,
> 
> I'm sorry for your bad experiences. Can you tell us a bit more about
> your problems?
> 
> Thanks

- End forwarded message -

bug#32339: "nix import" fails

[Nils Gillmann]

Hooray, a bad subject line!

* nixpkgs is on commit d817ccbf832419abdd82bc617e058b8a196f6e98
* guix is on commit 6915d20f05363f61cef9c4ed7ebda3fe5a19325d
* GUIX_PACKAGE_PATH is unset

FWIW, this was while running the Nix daemon with my "service", but it
is not required for the imports.


abyayala$ guix import nix ~/re-src/nixpkgs curl
;;; SSAX warning: Skipping PI: xml

trace: stdenv.isArm is deprecated after 18.03
trace: lib.zip is deprecated, use lib.zipAttrsWith instead
trace: Warning: `showVal` is deprecated and will be removed in the next 
release, please use `traceSeqN`
trace: `mkStrict' is obsolete; use `mkOverride 0' instead.
trace: `lib.nixpkgsVersion` is deprecated, use `lib.version` instead!
error: stack overflow (possible infinite recursion)
Backtrace:
In guix/import/snix.scm:
191:9 19 (loop # () #f _)
191:9 18 (loop # () #f _)
191:9 17 (loop # () #f _)
191:9 16 (loop # () #f _)
191:9 15 (loop # () #f _)
191:9 14 (loop # () #f _)
191:9 13 (loop # () #f _)
191:9 12 (loop # () #f _)
191:9 11 (loop # () #f _)
191:9 10 (loop # () #f _)
191:9  9 (loop # () #f _)
191:9  8 (loop # () #f _)
191:9  7 (loop # () #f _)
191:9  6 (loop # () #f _)
191:9  5 (loop # () #f _)
191:9  4 (loop # () #f _)
191:9  3 (loop # () #f _)
191:9  2 (loop # () #f _)
191:9  1 (loop # () #f _)
In sxml/upstream/SSAX.scm:
  1896:21  0 (_ # #f # …)

sxml/upstream/SSAX.scm:1896:21: Throw to key `parser-error' with args 
`(# "EOF while 
reading a token " "reading char data")'.

bug#30680: [racket-users] Using Racket's raco on on Guix(SD)

[Nils Gillmann]

Christopher Lemmer Webber transcribed 3.3K bytes:
> Timothy Sample writes:
> 
> > Christopher Lemmer Webber  writes:
> >
> >> Konrad Hinsen writes:
> >>
> >>> In my tests, all packages ended up working, but performance is indeed
> >>> worse than with a Racket installation outside of Guix.
> >>>
> >>> It would be nice if someone with more knowledge of Racket internals
> >>> could give a hint or two for debugging this issue!
> >>>
> >>> Konrad.
> >>
> >> I'm posting a bug bounty on this issue: if someone can fix this I will
> >> pay them $250 USD.  I don't have the time or knowledge enough of Racket
> >> internals to do so myself.
> >
> > I have discovered a few things, but I’m not sure how to fix the
> > underlying problem(s).
> >
> > The reason Racket is trying to recompile the OpenSSL files is because of
> > a hash mismatch.  This can be seen by enabling debugging output:
> >
> > $ PLTSTDERR=debug raco setup openssl
> >
> > Which says a lot of things, but most interestingly it says:
> >
> > 
> > ...
> > compiler/cm: checking: 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > compiler/cm: different src hash... 
> > (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 
> > 4d21ac412723fbf33f97669c2f73f0e9367f4510)
> > compiler/cm: maybe-compile-zo starting 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > compiler/cm:   start-compile: 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > compiler/cm:   compiling 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > open-output-file: cannot open output file
> >   path: 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570
> >   system error: Read-only file system; errno=30
> >   context...:
> > ...
> > 
> >
> > This hash mismatch is caused by grafting.  When the package is built,
> > the path to OpenSSL gets hard-coded in a source file.  The SHA-1 hash
> > for this file is stored in its “.dep” file.  When the output is
> > grafted, the source file gets updated with a new OpenSSL path, but the
> > hash does not get updated.  This makes Racket think that the cached
> > bytecode file is incorrect (even though it was likely grafted too),
> > and it tries to recompile it.  It fails because it tries to write this
> > new bytecode file to the store.
> 
> Interesting... I hadn't even considered grafting.  (I still wonder why
> it's even trying to open *any* file in the store for output though...)
> 
> > I double checked this by trying with an ungrafted Racket, and got better
> > results.  (There was still a warning about writing to the store, but it
> > seemed less significant.)
> 
> Cool!
> 
> > The only thing I can think of for a fix would be to patch Racket to be
> > more lenient with bytecode files in the store.  That is, ignore hash
> > mismatches in store-files.  I might give this a try later tonight if
> > nobody has any better ideas.
> >
> > -- Tim
> 
> BTW, some examples of packages where I've had trouble, in case it helps
> with testing:
> 
>  - Raart
>  - Gregor
>  - crypto (seemed to work last time, not sure why it wasn't working before)
> 
> Though at this point I also can't do just "raco setup" on a local
> package either, but maybe resolving this issue will fix that.
> 
From what I've learned in the last couple of hours, the last problem could
be due to leftovers in your raco / dotRacket folder from an older installation.

bug#32840: linux-libre 4.18.9: shpchp is no longer a module (now: built-in)

[Nils Gillmann]

Hi,

at taler we need shpchp as a module in the initrd.

Before version 4.18.x, shpchp was a module we've build in guix' linux-libre,
you were able to just specify it for the initrd.

With 4.18.9, this module became a compile-in/built-in (see linux
commit log).  I want to avoid maintaining yet another kernel
definition for future complications if I can.  Can we get this module
built in by default?

I consider it a bug as the functionality was given before and
disappeared now, leaving our system unable to upgrade unless I write
some code around it.

Thanks.

bug#32836: emacs-magit is broken (and probably others) due to package renaming

[Nils Gillmann]

Alex Kost transcribed 331 bytes:
> Pierre Neidhardt (2018-09-25 17:04 +0200) wrote:
> 
> > Oopsy, missed that indeed! xD
> > Sorry for the trouble, will fix as soon as possible.
> >
> > By the way, I think using "name" for URLs is a bad practice, we only need
> > "version" there.  What do you people think?
> 
> I totally agree!  I don't like this practice very much.
> 
> -- 
> Alex
> 
> 
> 

Very often the name we use, except for language specific packages, is the same
as upstream uses. "name" can be shorter than "whatever-long-name".

bug#32840: linux-libre 4.18.9: shpchp is no longer a module (now: built-in)

[Nils Gillmann]

Ricardo Wurmus transcribed 808 bytes:
> 
> Mark H Weaver  writes:
> 
> > Nils Gillmann  writes:
> >
> >> at taler we need shpchp as a module in the initrd.
> >>
> >> Before version 4.18.x, shpchp was a module we've build in guix' 
> >> linux-libre,
> >> you were able to just specify it for the initrd.
> >>
> >> With 4.18.9, this module became a compile-in/built-in (see linux
> >> commit log).  I want to avoid maintaining yet another kernel
> >> definition for future complications if I can.  Can we get this module
> >> built in by default?
> >
> > Done in commit fe73352e8073ea0a0e6f6b5591f24395671998ab on master.
> > Closing this bug now, but please reopen if appropriate.

Thanks! I'll get back if this didn't fix upgrading the server.

> I don’t understand why building it as a module is needed when upstream
> decided to turn it into a built-in feature.
> 
> Could you please explain?

There are modules [M] and boolean y/n "builtins" in Linux. We don't need
to build it as a module now, since upstream changed it to be a builtin.
It is not covered by whatever selection we have in the kernel config as
builtins. Since the module disappeared, users of the module were left
with the choice to remove it and either build their own kernel variation
or ask for it as a feature.

I asked for it, since Taler wanted as little reliance on third-party
repositories as possible, no matter how reliable the repositories are.

> -- 
> Ricardo
> 
> 
> 
> 

bug#71870: Some broken Go packages (including Podman)

[Nils Landt]

Building the new Podman package fails because building a depdency 
(gvisor-tap-vsock) fails:
 
The following derivation will be built:
/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv
building 
/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv...
WARNING: (guile-user): imported module (guix build utils) overrides core 
binding `delete'
Backtrace:
16 (primitive-load "/gnu/store/2a9k7v2qhydivh63xv921gr6kp9?")
In ice-9/eval.scm:
214:21 15 (_ #f)
217:50 14 (lp (# ?))
217:50 13 (lp (# ?))
217:50 12 (lp (# ?))
217:50 11 (lp (# ?))
217:50 10 (lp (# ?))
217:50 9 (lp (# ?))
217:50 8 (lp (# ?))
217:50 7 (lp (# ?))
217:50 6 (lp (# ?))
217:50 5 (lp (# ?))
217:33 4 (lp (# ?))
293:34 3 (_ #(#(#(#(#(# ?) ?) ?) ?) ?))
173:55 2 (_ #(#(#(#(#(# ?) ?) ?) ?) ?))
223:20 1 (proc #(#(#(#(#(# ?) ?) ?) ?) ?))
In unknown file:
0 (%resolve-variable (5 (guix build go-build-system) . #) #)
ERROR: In procedure %resolve-variable:
In procedure module-lookup: Unbound variable: remove-go-references
builder for 
`/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv' failed 
with exit code 1
build of /gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv 
failed
View build log at 
'/var/log/guix/drvs/4l/zcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv.gz'.
guix build: error: build of 
`/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv' failed
error: Recipe `guix` failed on line 13 with exit code 1
 
It looks to me like 0df957eecc536e1d0a5722b47dda1563439bbe04 removed 
remove-go-references, but it is still used by podman, gvisor-tap-vsock, and 
buildah.
 
--
Nils Landt

bug#71870: Some broken Go packages (including Podman)

[Nils Landt]

> jgart  hat am 01.07.2024 16:35 CEST geschrieben:
> 
>  
> > Building the new Podman package fails because building a depdency
> > (gvisor-tap-vsock) fails:
> 
> Hi Nils,
> 
> Would you be interested in sending patches to fix these failures?

No, the patch submission process is too annoying for me.

bug#71870: Some broken Go packages (including Podman)

[Nils Landt]

> jgart  hat am 01.07.2024 19:04 CEST geschrieben:
> 
>  
> > No, the patch submission process is too annoying for me.
> >
> 
> Hi Nils,
> 
> Sorry to hear that. I can relate to that as I've also been annoyed by aspects 
> of the process.
> 
> Can you share some of the pain points that you've experienced with the patch 
> submission process?
> 
> This will help us potentially address that and open discussion around it.
>
> How do you think that the patch submission process can be improved?
 
Nothing that hasn't been talked about for years, really.

- Patch submission workflow without email
- Code review tool with threaded at-code conversations
- Code formatter that I can make work for vim (i.e. guix style for non-packages)
- Useful commit messages instead of GNU ChangeLog

My previous attempt at contribution (https://issues.guix.gnu.org/66557) was 
quite unpleasant.
I don't know how to phrase my critique of the reviewers in a constructive 
manner, given that I respect we're all human beings volunteering time for this 
hobby.
 
> I'm going to give a talk in August at the Guix London meetup on patch review, 
> the mumi CLI tool, and my current personal workflow.

I will be watching the recording, but I don't see how it would address my 
wishlist :)

bug#71870: Some broken Go packages (including Podman)

[Nils Landt]

> Jean-Pierre De Jesus Diaz  hat am 03.07.2024 18:40 CEST 
> geschrieben:
> 
>  
> Hello,
> 
> I've sent a few patches in  to fix
> the build of these
> packages and also updates podman to latest version.
> 
> Cheers,

Thank you very much Jean-Pierre.

bug#66659: (home-)on-first-login script broken when no gexps are added

[Nils Landt]

Error message:

ice-9/psyntax.scm:2824:12: In procedure syntax-violation:
Syntax error:
/home/nl/.guix-home/on-first-login:3:1233: source expression failed to match 
any pattern in form (when (claim-first-run flag-file-path))

As you can see, there is no body in the "when" expression.

Code in gnu/home/services.scm:438 :

  (if (file-exists? xdg-runtime-dir)
  (when (claim-first-run flag-file-path)
#$@gexps)

In my case, it appears that gexps is empty, resulting in the invalid syntax.

Broken by b92235ea8b06e304072bad55ae006593ea673568

bug#66659: closed (Re: bug#66659: (home-)on-first-login script broken when no gexps are added)

[Nils Landt]

> help-debb...@gnu.org hat am 21.10.2023 16:16 CEST geschrieben:
> 
>  
> Your bug report
> 
> #66659: (home-)on-first-login script broken when no gexps are added
> 
> which was filed against the guix package, has been closed.
> 
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 66...@debbugs.gnu.org.
> 
> -- 
> 66659: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66659
> GNU Bug Tracking System
> Contact help-debb...@gnu.org with problems
> Hi Carlo & Nils,
> 

> I’ve just pushed something similar to what you provided, Carlo, in
> commit e098ba2f499bbddfea50c85058e4077e39b85513.
> 
> We should be good now.

I'm afraid this did not fix the issue. It results in
(when (claim-first-run flag-file-path) (begin))

which leads to the new error message "Syntax error:
/home/nl/.guix-home/on-first-login:3:1272: sequence of zero expressions in form 
(begin)"

bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

[Nils Landt]

> Ludovic Courtès  hat am 20.11.2023 23:10 CET geschrieben:

> nils@landt.email skribis:
> 
> > when using the home-mcron-service, PATH is set to 
> > /run/current-system/profile/bin . This directory is empty when using guix 
> > home on a foreign distro, meaning all executable paths would need to be 
> > absolute. This includes stuff like /usr/bin/ssh, /usr/bin/nice etc..
> >  
> > My guess for the culprit was 1c30d5a6bfc5d48137f4bdcc271189a06fdc6ed3 , 
> > which replaced the custom home-mcron-service-type with mapping it to 
> > mcron-service-type. 
> > The mcron shepherd service in old service type did not mess with the 
> > environment variables, the inherited one does:
> > #:environment-variables
> > (cons* "GUILE_AUTO_COMPILE=0"
> > "PATH=/run/current-system/profile/bin"
> > (remove (cut string-prefix? "PATH=" <>)
> > (environ)))
> 
> As a rule of thumb, I personally always provide absolute file names, as
> in #~(job … #$(file-append coreutils "/bin/ls") …).

I do the same, but occasionally a program I call expects something to be 
available in PATH. For me (guix home in Debian 12), this includes Guix itself.
Running 
/home/nl/.config/guix/current/bin/guix pull 
in a terminal works perfectly fine, but
unset PATH
/home/nl/.config/guix/current/bin/guix pull 
results in a stacktrace that ends in:
In guix/scripts/pull.scm:
453:4  4 (_)
In guix/build/utils.scm:
625:6  3 (which "guix")
In unknown file:
   2 (string-tokenize #f # …)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure string-tokenize: Wrong type argument in position 1 (expecting 
string): #f

> I wonder what the preferred behavior would be.  Restore PATH to whatever
> value it had when the user ‘shepherd’ process was started, at the
> expense of making things harder to track/less reproducible?  Should we
> leave it unset, possibly breaking programs that expect it to be set?
> Should we set it to “/run/current-system/profile/bin:/usr/bin” or
> similar?

I think the previous behaviour was fine for a user level service. I'm guessing 
this was inheriting the environment variables from the shepherd process that 
started mcron?

Otherwise, adding /usr/local/bin:/usr/bin:/bin should be a good default I think.

I'm not emotionally invested either way, I have moved away from shepherd / 
mcron.

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

[Nils Landt]

Hello,

I use guix home for almost everything, but I have installed glibc-locales in my 
"regular" guix (just by running guix package install glibc-locales).
Now, running guix package --upgrade fails with:
guix package: error: package glibc-locales@2.37 does not support x86_64-linux

But from my reading of (gnu packages base), glibc-locales version should be the 
same as glibc version. This is not the case for me though:
guix repl
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use (gnu packages)
scheme@(guix-user)> (specification->package "glibc-locales")
$1 = #
scheme@(guix-user)> (specification->package "glibc")
$2 = #

In my home profile, I was able to fix it by using (make-glibc-locales glibc) 
instead of (specification->package "glibc-locales").

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

[Nils Landt]

> Ludovic Courtès  hat am 06.12.2023 23:58 CET geschrieben:
> 
>  
> Hi,
> 
> Nils Landt  skribis:
> 
> > I use guix home for almost everything, but I have installed glibc-locales 
> > in my "regular" guix (just by running guix package install glibc-locales).
> > Now, running guix package --upgrade fails with:
> > guix package: error: package glibc-locales@2.37 does not support 
> > x86_64-linux
> 
> Fixed with 4a6cef9d66ff26e96d63f2f1f886b8212154ca00.
> 
> The problem was that glibc-locales@2.37 is marked as supported for
> i586-gnu only (that’s GNU/Hurd).

Thank you for the quick fix! 
But isn't the the real bug that guix package (--install, --upgrade) consider an 
unsupported package as the version to install / upgrade to? Expected behaviour 
for me would be that it checks for the newest version that can actually be 
installed on the architecture.

> The workaround on GNU/Linux would have been to run:
> 
>   guix install glibc-locales@2.35

Is this version pin persisted anywhere? Because I executed that, and --upgrade 
still tried tried to install 2.37.