IRC channel logs


back to list of logs

<jonsger>lfam: yes, I'll. but he didn't send it through the list
<lfam>It was patch ticket #45570 jonsger
<jonsger>leoprikler: I reported a bug still waiting on the bug number
<roptat>so I was wrong, because we read the body until the end; I tried from the repl and it doesn't cause any issue
<jonsger>lfam: I doesn't have that one in my mails
<jonsger>ah I only follow guix-patches and this went to bug-guix...
<roptat>weird, (get-u8 port) gives me a backtrace...
<roptat>In procedure =: Wrong type argument in position 1: #f
<raingloom>quick q: i need to extend user-homes because Reasons (TM), how do i modify it to do that?
<raingloom>(specifically: i wanna run a short script that converts all homes to BTRFS subvols if they aren't already converted)
<raingloom>(it's not entirely well documented how the compose and extend functions are called.)
<leoprikler>aren't btrfs subvolumes handled in the file-systems section anyway?
<leoprikler>so you'd have to inherit the os, fetch the users, construct the subvolumes, and then add them to file systems
<raingloom>leoprikler: uuuuh, maaybe? damn, that's way more complicated then i thought.
<leoprikler>tbf it's a very non-trivial use case tho
<raingloom>...i'll go look a bit more into how NixOS does Snapper...
<lispmacs[work]>hi, I'm no python programmer, but was trying to run somebody elses script, which seems to be dependent on python-pyserial
<lispmacs[work]>I ran `guix environment --ad-hoc python2 python-pyserial' but that does seem to be enough to get it loaded into the import path...?
<lispmacs[work]>*doesn't seem
<lispmacs[work]>anyone able to give me some guidance?
<lfam>lispmacs[work]: I don't know how to make it work, but python-pyserial will be based on python 3, not python 2
<lfam>The default python in Guix is python 3
<lispmacs[work]>lfam: the script is written for python 2.7, but makes a call to "import serial". Is there a serial package for python2 that had not been packaged yet?
<lfam>I don't know
<lfam>I'm just pointing out that "python2" and "python-pyserial" are using different languages
<lfam>There is a python2-pyserial package you could try
<lispmacs[work]>lfam: okay, thanks, I didn't see that
<lispmacs[work]>that worked, thanks
<lfam>You might look to updating the script to use Python 3, as Python 2 is going to be removed from guix in the next couple years
***daviid is now known as Guest96134
<lfam>Unless a new source of upstream support emerges
<lispmacs[work]>lfam: I'll keep that in mind, but probably I would just use a special profile instead
<lfam>Okay :)
<lispmacs[work]>thanks to our wonderful profile capabilities here in guix-land
***Guest96134 is now known as daviid
<leoprikler>guix time-machine --2020
<lispmacs[work]>I tried guix time-machine --2320 but got an error
<lispmacs[work]>something about no code for module (capacitor flux)
<leoprikler>we're working on it, but there seems to be a weird dependency on (einstein twin), that we can't completely resolve yet
<User-73399>jonsger: Many thanks. Seems too fix it for me as well :D
<leoprikler>User-73399: friendly reminder to fix your config regardless
<User-73399>I did try to look in to it, however the problem persisted even if I removed all groups related to cups(lp and lpadmin)
<User-73399>leoprikler: I doublechecked after with $ grep lp /etc/config.scm
<User-73399>is there a tool too check config.scm?
<User-73399>leoprikler: or is there samething other then what the error say, I need too fix?
<User-73399>In wich case I belive that would be a bug :p
<User-73399>only other lp was in cups-pk-he*lp*er extension in cups config :p
<leoprikler>If you find a minimal configuration, that adds two lp groups, then please do report it.
<User-73399>how do I check if it ads 2 lp groups?
<User-73399>only one in /etc/group
<leoprikler>nvm, I found it
<User-73399>Good, good. One problem less :D
<User-73399>Love Guix, it's awsume :D
<DynastyMic>Do any of you know why IceCat is not rendering numbers in EXWM?
<leoprikler>not sure if specific to EXWM, but a lot of users report icecat missing fonts
<leoprikler>you'd need to install a font with good glyph coverage and then refresh the fc-cache
*leoprikler reported the lp stuff, now going to bed.
***iyzsong-- is now known as iyzsong-w
<sundbry>Hey guix friends i have a novel new go-download method for Guix. It implements `go get` to download all of the transitive dependencies of a go project. I am not sure if it is worth submitting as a patch since golang dependencies are inherently unstable. The hashes are subject to change at any time because golang dependencies always point at "master" so a commit on any single project can throw the go-get-download method hash
<sundbry> off.
<sundbry>This allows a go program to be packaged without porting each of its myriad dependencies first.
<PotentialUser-91>How do I install a font in Guix System? (Not installed in graphical environment)
<efraim>lfam: I can try sbcl on aarch64 native
<efraim>libxcb is broken on core-updates
<jlicht>silly question, but what is the 'easiest' way to run wayland on top of a Guix system?
<jlicht>I'm open to using pretty much any WM/DE
<iyzsong-w>jlicht: install sway, and run it from tty
<efraim>I hear people use sway launched from a TTY. I'm using enlightenment/wayland launched from sddm
<iyzsong-w>I recently switched to cagebreak (ratpoision like wayland compositor)
<jlicht>thanks iyzsong-w, efraim :-)
<sturm>I've just installed a new Guix System, but after running `guix pull` and `reconfigure` as root, running `guix describe` complains "guix describe: error: failed to determine origin" - any thoughts?
<efraim>sturm: what's the output from 'which guix'
<sturm>efraim: /run/current-system/profile/bin/guix
<efraim>if it's not the one from $HOME/.config then guix describe doesn't like it
<efraim>try $HOME/.config/guix/current/bin/guix describe
<sturm>yep, that's better - does that mean I'm missing an environment variable or something?
<sturm>(as far as I'm aware, the files under /root are clean from the installer)
<efraim>looks like it. if it's for root I wouldn't bother with it though
<sturm>ah ok, so when I run `guix pull` and `guix system reconfigure` that will be using the latest guix, even though my root profile is misconfigured somehow?
<iyzsong-w>no, make sure 'which guix' is the right one (under ~/.config/guix/current)
<iyzsong-w>'guix system reconfigure' use guix in PATH, which should be the pulled one (guix pull update the one in ~/.config/guix/current)
<sturm>ok, thanks so much for your help efraim and iyzsong-w :)
<iyzsong-w>glad to help
<profmakx>anyone here use any of the stumpwm contrib packages with guix? I cannot for the life of me figure out how to load any of the modules (stumpwm-pass in this case)
<malaclyps>I thought this was an interesting article on traditional packaging vs e.g. javascript packages with hundreds of node dependencies
***apteryx_ is now known as apteryx
<leoprikler>sundbry: I don't think moving tarballs and unstable hashes will do you any favor. Guix also has a rather firm stance against bundled libraries.
***sorki is now known as srk
<sundbry>leoprikler: I figured as much. I suppose it might be more useful if it was ported into a tool that extracts the dependencies from the go package and then bundles packages for each of the dependencies individually? I have heard there is such a tool for ruby deps that generates guix packages for dependencies?
<sundbry>I would like to eventually take the same approach for npm + maven as well, since I am building some polyglot apps on guix using all of these languages.
<efraim>python on core-updates is fixed
<leoprikler>sundbry: you might want to take a look at/improve `guix import`
<leoprikler>writing a polyglot app with all those language-specific package managers sounds like a huge pain in the butt
<sundbry>Interesting, I have never seen `guix import` before, I missed that in the manual. Thanks
***daviid is now known as Guest36452
***iyzsong- is now known as iyzsong
<jlicht>sundbry: check out the wip-node-14 branch for the current state of npm story
<jlicht>s/of/of the/
<sundbry>jlicht: will do. <Shudders in fear of npm packages that require compiling native code>
<abcdw>Is it possible to use a local git repository as a source for the package?
<abcdw>file:///home/blablabla doesn't work :/
<PurpleSym>abcdw: Works using `--with-source=`, but not in a package definition. (The build daemon does not have access to local files.)
<cbaines>abcdw, you can use local-file + git-predicate to fetch the Git working tree in an origin
<abcdw>cbaines: ok, thank you.
<efraim>sneek: later tell lfam sbcl builds on aarch64 no problem on staging
<sneek>Got it.
<efraim>sneek: botsnack
<profmakx>sbcl works on aarch64, i got stump working from it on my pinebook
<profmakx>(but on that note, how do I load sbcl-stumpwm-pass into my stumpwmrc?)
<raghavgururajan>Hello Guix!
<raghavgururajan>Does "collect2: fatal error: ld terminated with signal 15 [Terminated]" mean termination due to out of memory/cpu?
<profmakx>raghavgururajan:this can mean all kins of things
<raghavgururajan>profmakx: I see.
<profmakx>just means it's been sent a SIGTERM
<profmakx>(I believe OOM is usually SIGKILL, ut I can't say for sure)
<PotentialUser-11>What is the answer to this question?
<iyzsong>For local font files, I think you can put them into ~/.local/share/fonts, and then update the font cache.
<davidl>Whats up with this new thing Im seeing on multiple machines: guix-command substitute died unexpectedly
<davidl>substitute: Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
<davidl>it happens when I try to install or upgrade packages
<davidl>but then works again on a second attempt
<mothacehe>davidl: it's reported here:
<davidl>mothacehe: thx
<mothacehe>(I'm also having this issue)
<PotentialUser-38>also happens when doing a guix pull
<civodul>mothacehe: looks like an issue on berlin, right?
<mothacehe>civodul: yes I just posted a backtrace found in "/var/log/guix-publish.log" on berlin.
<mothacehe>render-narinfo/cached fails for some reason
<civodul>i've restarted guix-publish
<mothacehe>I also observed some deadlocking during publish tests:
<civodul>the EPIPE in render-narinfo/cached comes from the daemon: the daemon closed the connection
<civodul>maybe due to a protocol violation
<abcdw>what the difference between search-paths and native-search-paths in package record?
<civodul>native-search-paths is for native compilation, whereas search-paths is for cross-compilation
<civodul>usually you only care about the former
<abcdw> is kind lacking almost any information
<abcdw>civodul: thank you) It seems that I used native-search-paths intuitively correct for my use-case, but still not sure how it works.
<abcdw>Is there a doc/article about search-paths in package record?
<civodul>abcdw: i don't think it's well-documented as you found out
<civodul>well, (guix search-paths) has some info
<abcdw>civodul: thank you, will read it
<civodul>hmm i don't see in emacs-debbugs
<mothacehe>strange, I do
<civodul>i think it has to do with the "grave" severity
<civodul>mine won't display it by default
<civodul>anyway, i think (hope?) it was a transient failure
<civodul>problem is that guix-publish doesn't stop when the connection the guix-daemon is broken
<abcdw>civodul: Seems search-paths works in following way. If defined for a packageA then guix environment --ad-hoc packageA will autmatically set respective environment variables to paths relative to this environment's profile.
<mothacehe>civodul: I agree about the transient failure, yesterday I had to restart the guix-daemon multiple times because evaluations where stuck, maybe it's the cause
<mothacehe>but I also think guix-publish should stop when the connection is lost
<roptat>and guix substitutes should not crash when receiving a 500 :)
<PotentialUser-11>iyzsong, Thank you very much
<aecepoglu[m]>is there an easy way to write a guix package where the source is a local file/directory?
<roptat>civodul, amin would like to see a license notice in CODE-OF-CONDUCT:
<roptat>I copied the file from the Guix repo itself, so there's no license there either
***Diagon_ is now known as Diagon
<leoprikler>Why is the Expat licensed stored under ?
<cbaines>leoprikler, that's probably just someone putting in a misleading redirect
<cbaines>looks to have happened recently
<civodul>roptat: it's like asking for a licence on the GPL
<civodul>mothacehe: "herd restart guix-daemon" restarts everything that depends on it, including guix-publish, but if guix-daemon restarts independently (as in "killall guix-daemon"), we can end up in that situation
<civodul>roptat: apparently it's CC-BY 4.0:
<Ikosit>How can i use a local repository in the package definition?
<abcdw>Ikosit: (source (local-file "/home/bob/path-to-your-repo" #:recursive? #t))
<Ikosit>abcdw: Thanks
<apteryx>I'm probably late in the game; but we can stop ending phases by #t on core-updates, correct?
<apteryx>we'll suddenly have long lines ending with more )))))) breaking the 80 chars limit ;-)
<apteryx>answering myself: yes, no more #t at the end of phases on core-updates
<DivanSantana>hmm. Trying running X in guix system vm. After I launch xinit, it seems to freeze. Can't control keyboard or mouse.
<DivanSantana>let me try with the file in the guix repo 'lightweight-desktop.tmpl'
<civodul>apteryx: yup, the end of #t! :-)
<apteryx>efraim: thanks for fixing some python 3.9 breakage on core-updates :-)
<efraim>apteryx: I was going to test if any of the tests no longer broke on aarch64 but didn't make it that far :)
<apteryx>any thing still getting in your way?
<efraim>network went down, now I can't connect to my pine64 again. I'll roll across the room later and mess with the power supply for it
<apteryx>OK :-)
<dustyweb> good news, $150 risc-v beaglebone board coming
<efraim>wow, with 8GB of RAM
<tribals>Hi there!
<tribals>I'm trying to use time-machine to grab specific version of package - gnupg in my case - according to this:
<civodul>dustyweb: woow nice
<tribals>I found that last commit where gpg 2.0 defined is d407dd84e498240279b3cb15ed3889d7a31ff919:
<tribals>Now I'm trying to spawn an environment with such a version: $ guix time-machine --commit=d407dd84e498240279b3cb15ed3889d7a31ff919 -- environment --ad-hoc gnupg@2.0.30
<tribals>Unfortunately, I've gnupg version 2.2.23 it spawned environment
<tribals>guix environment: package 'gnupg' has been superseded by 'gnupg'
<tribals>bash-5.0$ gpg --version
<tribals>gpg (GnuPG) 2.2.23
<tribals>What I'm doing wrong?
<DivanSantana>OK, got guix system vm working.
<DivanSantana>Helps to read the docs. Increased the memory.
<dustyweb>civodul: yeah! It's exciting
<civodul>tribals: see commit f173dbe42f51256960f61b3681b1860a0de25683: gnupg@2.0 was marked as superseded by 2.2 at that time
<civodul>so it was already gone in practice
<civodul>you can bypass deprecation with: <command you typed> -e '(@ (gnu packages gnupg) gnupg-2)'
<tribals>civodul: Can I just use commit f173dbe42f51256960f61b3681b1860a0de25683 or earlier?
<civodul>tribals: you can use the commit you mentioned, but pass -e as i wrote instead of gnupg@2.0
<tribals>$ guix time-machine --commit=d407dd84e498240279b3cb15ed3889d7a31ff919 -- environment --ad-hoc gnupg -e '(@ (gnu packages gnupg) gnupg-2)'
<tribals>Updating channel 'guix' from Git repository at ''...
<tribals>guix environment: error: failed to evaluate expression '(@ (gnu packages gnupg) gnupg-2)':
<tribals>In procedure module-lookup: Unbound variable: gnupg-2
<civodul>tribals: it should be gnupg-2.0 instead of gnupg-2
<tribals>Ok, thanks!
<tribals>civodul: It worked! Thank you!
<abcdw>How to set an environment variable before cmake call to the path of the one of the inputs?
<nefix>hello! Does someone have an example of the spice-vdagent service? When I add it to a service, it is disabled
<nefix>(I add it like all the other services)
<nefix>Also, is there a way to write some contents to a file in the system configuration? e.g. to have a /home/nefix/test file with some contents
<civodul>abcdw: environment variables that correspond to search paths are automatically set
<civodul>for other variables, you can add a phase that calls 'setenv'
<mothacehe>cbaines: Cuirass now uses PostgreSQL and I would like the Cuirass service to create the database at activation. Have you ever tried to do that with the Data Service?
<civodul>oh nice
<cbaines>mothacehe, hmm, I think the database setup needs to be done manually at the moment
<cbaines>there's some automation for the system test
<mothacehe>ok, thanks! I guess running "createuser" & "createdb" at shepherd activation could work.
<nefix>mothacehe: I'm having a similar issue, could you share your code? Thanks!
<mothacehe>nefix: I have just started thinking about it but I'll let you know.
<apteryx>civodul: the gnu build system still understand a #f-ending phase as a failed phase, is that expected?
<apteryx>(on core updates)
<apteryx>if it doesn't care about #t, I'd expect it shouldn't care about #f too.
<rekado_>apteryx: it shouldn’t
<rekado_>for a while now the gnu build system would warn you that although the value is not #t this doesn’t cause the build to abort.
<abcdw>civodul: Thank you. Greping setenv helped!)
<mroh>dustyweb: I think, you are working on updating blender, right?
<civodul>apteryx: the return value of phases should be ignored on core-updates
<civodul>but perhaps i forgot a few places?
<civodul>oooh i see
<civodul>apteryx: in the for-each at the bottom, i left the message unchanged
<civodul>so it says "phase failed" but then keeps going
***sneek_ is now known as sneek
<morgansmith>so I'm packaging a packet that has a few origins in its input. This works great as I can just point it to the folder for it to find the files. However, on one of my origins I added a little substitute snippet that I needed. Suddenly my origin was built in the store as a tar.xz and now everything is ruined :/. I think my woes are possibly caused by the patch-and-repack function at guix/packages.scm:583.
<morgansmith>Any ideas on how to not pack my origin?
<civodul>morgansmith: origins are always re-packed after applying a patch or snippet
<civodul>which in hindsight is questionable
<morgansmith>re-pack isn't even the right work in my situation as it's packing it for the first time :/
<roptat>I think re-packing makes sense if the origin was a tarball, less so if it wasn't
<morgansmith>is this for distribution or disk space or something? Why do I want my created origins to ever be compressed? I only use them uncompressed
<civodul>initially origins were always compressed tarballs
<civodul>so the idea was to make patching transparent in the sense that "guix build -S" would give you a compressed tarball no matter what
<ekaitz[m]>hi all, I trying to code the service for redshift ( and I'm not sure where to start, can someone point me to a simple service to use as a reference?
<civodul>ekaitz[m]: hi! FWIW i run redshift as a user, and i think it has to run as the user who's running Xorg
<civodul>so it prolly cannot be a system service
<ekaitz[m]><civodul "ekaitz: hi! FWIW i run redshift "> yes, but how do you manage to have it running in the background all the time then?
<ekaitz[m]>using the shepherd? I don't know it very well
<civodul>i run shepherd as a user
<civodul>so for now it's not Guix-managed
<morgansmith>relevant link:
<ekaitz[m]>thank you both
<ekaitz[m]>now the extra question (i'm sorry haha) IF I WANTED to start with a simple service for guix that is not redshift, what piece of the code is the best entry point?
<ekaitz[m]>there are soooo many services I feel a little bit overwhelmed and a little bit of guidance can help me overcome that
<morgansmith>what you already know. When I wanted to learn some service stuff I looked at the mpd service because I already knew what the programs objective is
<morgansmith>I do recommend the mpd service, but I actually haven't looked at any other services :P
<ekaitz[m]>haha ok I'll try with that then
<ekaitz[m]>also civodul: do you have your configuration in public or in a place I can read?
<apteryx>civodul: yes, that's what I'm seeing
<civodul>ekaitz[m]: openssh (sshd) is also a good example: it has a config file, a privilege-separation user account, and a shepherd service
<ekaitz[m]><civodul "ekaitz: openssh (sshd) is also a"> Great! thank you I'll read it too
<apteryx>morgansmith, civodul there's a 'Allow patch-and-repack to work with plain files.' patch on guix-patches, that allows fetching more kind of files as origins (
<ekaitz[m]>I just read the article morgansmith sent me, pretty clear and straight to the point, but it makes me wonder: why don't we provide those configurations as part of the packages?
<ekaitz[m]>some packages provide udev rules, others provide their own configuration files, desktop files... why do users need to configure their own user services from scratch if the package is know to run as a service?
<apteryx>morgansmith: it doesn't get rid of the repacking though; I considered it but the gexp would need to know the file name ahead of time, which is currently done after unpacking... Not impossible but need to be refactored.
<apteryx>feel free to improve it :-)
<civodul>like roptat suggested above, it could simply skip repacking if the source was not a tarball
<civodul>apteryx: BTW are you taking care of the issue with phases returning #f on core-updates?
<apteryx>no I am not (enough rebuilding the world for a couple hours here ;-)
<apteryx>I can later if you don't beat me to it
<civodul>alright :-)
<dustyweb>mroh: oh, I did update it
<dustyweb>but didn't push it :)
<dustyweb>mroh: I can get my patches to the list, one sec
<dustyweb>(sadly the blender update didn't fix my graphics issues)
<dongcarl>Hey all, any way to figure out how many workers my guix-daemon has in a script?
<doctor_rodik>Hi! I wanted to add Hunspell dictionary for Russian to packages, but found a number of places where dictionaries are declared: gnu/packages/aspell.scm, gnu/packages/libreoffice.scm, gnu/packages/hunspell.scm (dictionary for Italian). What is preferred place? It seems to me that libreoffice.scm is the most suitable one, as Russian hunspell dictionaly I want to add originates from Libreoffice.
<Ikosit>ekaitz: Such a server would be better placed in the guix-home-manager
<Ikosit>ekaitz: You may also want to look how the redshift deamon is defined in home-manager
<jgart[m]>what is preventing guix-home-manager from being packaged upstream? Is there a way to simplify the installation of guix-home-manager so that it could be installed similarly to nix's home-manager?
<roptat>jgart[m], the way it works, it wouldn't be "packaged", it would be integrated :)
<roptat>i think I need to re-work the definition of services, then the system and the home-manager could both use the same service types
<roptat>or at least share most of their infrastructure
<ekaitz[m]><Ikosit "ekaitz: Such a server would be b"> Interesting! should be solved with that for sure
<apteryx>is there something different between the copy-build-system and the gnu-build-system w.r.t. what inputs end up in %build-inputs?
<andre_>hello, i'm really new to this whole guix and scheme concept (and guix system in general). I'm trying to reconfigure my system to enable printing and when i try to `sudo guix reconfigure /etc/config.scm` i get the following error: guix system: error: the following groups appear more than once: scanner lp
<andre_>i've added "lp" to supplementary-groups of my user
<andre_>the first reconfigure worked... now it seems it doesn't work because i'm in the lp group already?
<lfam>Can you clarify what is not working andre_?
<sneek>Welcome back lfam, you have 1 message!
<sneek>lfam, efraim says: sbcl builds on aarch64 no problem on staging
<andre_>i get the error "guix system: error: the following groups appear more than once: scanner lp
<lfam>efraim: Thanks. I wonder... what the problem is
<Sharlatan>Hi folks
<lfam>andre_: Does it block anything? Or is it just a warning message?
<andre_>its blocking
<Sharlatan>I have intersting question on how to pack CommonLisp package which requires forign-library?
<lfam>andre_: We were dealing with this bug yesterday, but I think the error was changed to a warning so that nothing would be blocked. When is the last time you did `guix pull`? What is the commit from `guix describe`?
<andre_>The Commit is b8c3fa315a4140524d71bb12961ac83f300f1e17
<andre_>i'll try a pull :)
<lfam>andre_: Yes, try that. Your commit precedes the "fix"
<andre_>ahh, it seems to work. Thanks :)
<lfam>Great :)
<lfam>The underlying "problem" (that these groups appear more than once) has always existed, but it was briefly made an error before being demoted to a warning
<lfam>Now we know about the problem and can decide what to do about it
<civodul>cbaines: hi! should i go ahead with the zstd patches, after all?
<civodul>it's just two lines in substitute.scm, the merge conflict should be easy to handle
<cbaines>civodul, sure, I just haven't got around to testing the narinfo module patch and whatever the other patch was in isolation yet
<andre_>thanks for the info lfam. Its really fun using guix so far :)
<lfam>We're glad to hear it andre_
<lfam>We hope you find it useful and stick around
<civodul>cbaines: ok!
<civodul>BTW, let me know if you'd like to discuss the narinfo/substitutes patches
<civodul>sometimes it's easier to discuss live
<lfam>civodul: Do you have a few minutes to discuss the staging branch?
<dustyweb>mroh: patches sent to patch-guix
***andre is now known as Guest15824
***Guest15824 is now known as korve
<civodul>lfam: yup, what's the status?
<civodul>i didn't follow anything over the past week or so
<lfam>civodul: Based on "manual testing", it's working well on x86_64 and aarch64. I consider these to be the important platforms. However, Cuirass keeps having major problems building things, with many failures that can't be reproduced locally. So, the branch seems to be okay, but substitute availability is poor
<lfam>For example, it seems that all SBCL / Common Lisp packages fail to build on aarch64 on berlin, but efraim was able to build them fine on his hardware
<civodul>lfam: did you try "guix weather -c 10 -s aarch64-linux" and similar to see what the major blockers are on these other arches?
<lfam>No, I haven't tried this. I'm doing it now
<civodul>to see if it's "just" non-deterministic failures
<lfam>We did identify several "real" failures early on, and have fixed those
<lfam>Mostly related to Qt upgrades
<civodul>oh yeah, that rings a bell
<civodul>great you managed to fix it!
<lfam>Thankfully, other distros had already done the work
<lfam>The way that the Cuirass web UI displays logs could be improved. For example:
<lfam>The log file contains the build logs of several different packages, so it's not easy to find the problem
<lfam>It appears that several different build logs have been mixed together, like what you'd get from `guix build foo --max-jobs=10 --keep-going`
<lfam>I'm going to file a bug about this
<cbaines>Cuirass doesn't check for prerequsites when it starts a build, so builds for one derivation can start building prerequsites instead
<lfam>I've been building packages and derivations "by hand" on berlin, and doing sql queries to retry spuriously failed builds
<cbaines>At least that's what I've always thought was happening
<lfam>It would be great if there was some higher-level controls, like with hydra
<lfam>cbaines: Yes, it appears that way
<civodul>cbaines: but probably what we're seeing here relates to the new remote builds feature mothacehe has been working on no?
<civodul>until now, the log would be fetched from the build daemon
<civodul>but here, there's no such log anymore AIUI
<cbaines>I think I remember this behaviour from a while back, but it could have been something else
<civodul>or hmm do i get it right?
<civodul>it can't happen using guix-daemon + offload because it always checks for prerequisites
<civodul>but here, the build machine is downloading substitutes
<civodul>anyway, i need to catch up on what mothacehe has been doing :-)
<lfam>By the way, regarding aarch64 and the build farm, there are some serious workstations available for sale:
<lfam>It might be useful for us
<lfam>I estimate the total cost to be about $1250 when you buy the case, storage, etc
<lfam>I don't think anything else approaches this value
<dustyweb>new version of dcss out
*dustyweb makes a patch
<jackhill>lfam: will networkign work on that without non-free blobs? I suppose a different NIC can be put in the PCIe slot.
<lfam>I don't know jackhill. Are there any serious NICs that don't require some firmware?
<civodul>on x86 it's rare for Ethernet NICs to require non-free firmware
<civodul>even on low-end ARM devices
<jackhill>lfam: perhaps not :/ I was scared away by the openness section of which I believe uses the same networking archetecture from NXP.
<civodul>FWIW the OverDrive does not require non-free firmware either
<jackhill>lfam: absent any firmware questions, I agree that looks like a nice computer.
<lfam>I think these SFP / 10g NICs usually require something special
<apteryx>any one liner equivalent to shell's $(command) in Guile?
<apteryx>I think (call-with-input-pipe "command" get-string-all) could have been close, except it doesn't exist
<apteryx>the shortest seems to be: (let ((port (open-input-pipe "echo something"))) (read-line port) (close port))
<apteryx>well, closing the port later other the return value becomes #t
<civodul>apteryx: replace that command with a Scheme procedure? :-)
<civodul>but otherwise yeah, something like you write
<lfam>I'm running `guix weather` from berlin and it crashes with "X.509 certificate of '' could not be verified:"
<lfam>SSL_CERT_FILE and SSL_CERT_DIR are defined
<lfam>Any ideas?
<civodul>what follows the colon?
<lfam>"signer-not-found" and "invalid"
<civodul>that's on a foreign distro?
<lfam>That's on
<civodul>oh, is nss-certs even installed there?
<lfam>Well, there is some certificate bundle. I don't know if it's from nss-certs or another source
<lfam>I'll try it again locally
<lfam>I had moved to berlin since it was slow from my location
<civodul>fun: i found that *unsetting* SSL_CERT_DIR (on berlin) solves the problem
<civodul>it was: SSL_CERT_DIR=/run/current-system/profile/etc/ssl/certs:/etc/ssl/certs
<civodul>and i suppose the first one is a problem
<lfam>sneek: later ask efraim: Can you try building certbot from the staging branch on your aarch64 hardware?
<sneek>Got it.
<lfam>Hm, `guix weather` also crashes like this:
<lfam>At least, it shows the percentage
<civodul>ouch! we're missing just the last line :-)
<civodul>showing the exception
<lfam>Throw to key `gnutls-error' with args `(#<gnutls-error-enum Error in the push function.> write_to_session_record_port)'.
<apteryx>civodul: yes; I just feel it should be provided by Guile already ;-)
<civodul>lfam: weird; could be that the server hung up early, dunno
<aecepoglu[m]>Can I have a guix package pull its source from a local file path?
<apteryx>file:// with url-fetch is one way
<aecepoglu[m]>oh url-fetch does file://?
<apteryx>(with the current caveats: it needs to be a directory or a tar/zip archive)
<aecepoglu[m]>oh that's awesome. Would it accept a path to a directory or should I tar my package first?
<aecepoglu[m]>oh you answered as I was typing it. Cheers
<apteryx>a directory should be fine
<apteryx>phew! docbook-utils building the doc of fontconfig. What a rabbit hole that was.
<civodul>aecepoglu[m]: even nicer is to use (local-file "/path/to/file-or-directory")
<aecepoglu[m]>I was reading up on "local-file" but felt like its usage wouldn't be this trivial.
<aecepoglu[m]>because I couldn't wrap my head around g-expressions yet
<apteryx>rekado_: I've managed to have composable texlive trees without unions! Made possible via kpathsea brace expansion and good defaults in our texmf.cnf config (shipped with our texlive-bin package).
<lfam>Substitute availability for the staging branch, compared to the master branch, ranges between 58% (armhf) and 86% (x86_64)
<lfam>Absolute values, for example, 51% availablity for armhf on master vs 30% availability on staging
<lfam>And for x86_64: 93% vs 80%
<rekado_>apteryx: wow!
<rekado_>apteryx: I tried getting there for a long time until I admitted defeat and used unions. It’s exciting that you figured out an alternative!
<civodul>lfam: good, thanks for checking
<civodul>did "-c 10" reveal any important missing substitutes?
<civodul>that we could focus on
<lfam>The command always crashed before giving that report
<lfam>I'm running it again locally, hoping it works here
<apteryx>rekado_: standing on shoulders of giant, as the saying goes :-). Thanks for having provided foundations.
<lfam>civodul: I did get a useful report for x86_64-linux while running locally. Fingers crossed that it works for the other platforms
<lfam>java-snappy is the "top" failure for x86_64-linux, and it builds fine for me locally
<lfam>I'll try restarting it on berlin
<lfam>It failed there :/
<lfam>Is it okay to clear cached failures on berlin?
<cbaines>I believe so
<lfam>I know that garbage collecting store items has a big impact on the server
<lfam>It seems like unregistering a cached failure shouldn't require many resources
<cbaines>I think it's only there to stop Cuirass repeatly building things that repeatedly fail to build
<lfam>I just don't want to make the server lock up
<lfam>I suspect this test failure is flaky
<lfam>Maybe it should be run with fewer cores
<civodul>lfam: only clear selected cached failures
<civodul>don't clear them all
<civodul>otherwise we could end up spending time rebuilding lots of things that are bound to fail
<lfam>It does seem to fail reliably
<cbaines>What's the derivation?
<lfam>It is /gnu/store/m09gsa09ng8w8kn88ziw8z0qavyj8bac-java-snappy-
<lfam>I realized that this was the top failure on the master branch, but it also fails on staging, and all the top failures for x86_64 staging are java
<lfam>It's fishy
<cbaines>Looks like it can be build
<lfam>Yes, I know :) I've built it locally
<lfam>This is one of ... many failures that can't be reproduced anywhere besides the build farm
<lfam>I built it with rounds=4 locally
<lfam>I'm going to try getting `guix weather` reports for all the platforms and I'll send them to the staging thread on guix-devel
<civodul>lfam: also fails with --no-offload on berlin
<civodul>(yeah, i tried that, who knows :-))
<lfam>Yes, I tried that as well. So I don't think it's a specific hardware bug
*civodul tries locally
<cbaines>I put through a few high priority builds to see what happens
<cbaines>one has already passed
<civodul>cbaines: substituting .drvs is now much faster
<lfam>Does Cuirass handle non-public packages properly?
<cbaines>civodul, I'm still running some quite old Guix'es in places, but yeah, that should always be good :)
<civodul>java-snappy built locally just fine
<lfam>I notice that the non-public packages in (gnu packages java) are not getting built
<civodul>if the variable is private, Cuirass doesn't see it
<civodul>but if the package is referenced somewhere by a public package, which it surely gets built indirectly
<civodul>er, syntax error
<lfam>`guix weather` does see this packages and reports them as missing
<civodul>ah yes
<civodul>they should have been built indirectly no?
<civodul>i mean if they're private and unused, we can remove them right? :-)
<lfam>They are used!
<lfam>I don't know yet if they didn't get built, or if the builds failed
<lfam>I'm trying it locally
<civodul>oh i see
<cbaines>Cuirass only builds intentionally builds the edge of the graph, so non-exported packages that are not tracked, but might be built as part of other builds
<lfam>Well, java-guava has a substitute, but its private dependencies are reported as missing by `guix weather`
<civodul>and are those substitutes actually missing?
<lfam>So, the dependencies must have been built
<lfam>Tries `build -e ...`
<civodul>but given the cache-bypass thing in 'guix publish', it's possible that you get substitutes for a package but not (yet) for its dependencies