IRC channel logs

2020-04-17.log

back to list of logs

<marmulak>you rock
<civodul>sirgazil: for "guix upgrade" slowness before printing anything, a357849f5b1314c2a35efeee237645b9b08c39f5 could be the culprit
<civodul>at least, it means more work is needed before anything is printed
<civodul>(dated Mar. 30)
<mbakke>sirgazil: are you running a custom Guix fork ? 'guix build --no-grafts -d python-jedi' returns /gnu/store/0ajqwzb4xhhcbn2yfijxfqa0lyb0fyg6-python-jedi-0.17.0.drv
<sirgazil>mbakke: No custom forks.
<mbakke>I'm confused, it fails to build on the CI too, with yet another derivation: https://ci.guix.gnu.org/search?query=python-jedi+spec%3Aguix-master
<sirgazil>mbakke: I experienced these kinds of build errors with other packages before, where the check phase fails because some test failed, and wonder why packages whose check phase fail are merged into the master branch.
<mbakke>sirgazil: it's a classic case of 'works on the developers computer'
<nckx>Is it possible that there are 0 aarch64 CI builds at this time? Just want to make sure my load average bingo of 0.00 0.00 0.00 on both Overdrives today is expected…
<nckx>I'm not sure how to read <http://ci.guix.gnu.org/search?query=system:aarch64-linux>. Each refresh gives me a new and different list, but not brand new stuff.
<mbakke>nckx: weird, sounds like something is "stuck" on the CI, as I get queued if I try to build an aarch64 package
<nckx>mbakke: Yeah, I was sceptical considering the phase we're in. How do you query Cuirass? Still manual DB fiddling?
<nckx>I've started a pull && reconfigure on both machines to keep them happy.
<nckx>So new builds might legit be rejected.
<mbakke>nckx: I just ran './pre-inst-env guix build -s aarch64 gnome' and saw builds were waiting for locks
<nckx>OK 😃
<nckx>No magic sauce, good.
<mbakke>sirgazil: should be fixed now (commit bff70d93d22b049c0c4ea3bd234d39f05f794b28), thanks for reporting it!
<mbakke>(the python-jedi build failure)
<vagrantc>somedays, trying to use aarch64, it seems like there are no substitutes :)
<vagrantc>but that's a bit of a different issue :)
<vagrantc> https://ci.guix.gnu.org/search?query=openjdk returns precisely six items, all of which on staging from over a month ago
<vagrantc>no wonder there are no substitutes
<vagrantc>maybe ci.guix.gnu.org forgot a lot of packages?
<mbakke>vagrantc: try adding spec:guix-master to the search
<vagrantc>you have to specify master now?
<mbakke>well that's funny, I just tried it and got no results at all
<vagrantc> https://ci.guix.gnu.org/search?query=openjdk+spec%3Aguix-master
<vagrantc>yeah
<mbakke>none on core-updates either, even though it has a substitute
<vagrantc>hrm.
<vagrantc>building from git is also failing for me ...
<vagrantc>just not my day.
<vagrantc>so, "guix build --with-input=X=Y" allows you to dynmaically try a build with a new input ... but is there a way to simply add an input?
<pkill9>so it seems that jack can use the realtime priorities now *shrug* maybe due to a kernel update
<pkill9>guix is too good
<sturm1>Anyone had luck with Jitsi meet on Guix System? It loads up ok in Ungoogle Chromium, but I can't seem to get the microphone permission working
<ryanprior>I have Chromium installed as a Snap and it runs Jitsi Meet. Maybe irrelevant to you but it's a data point.
<sturm1>Thanks ryanprior, good to know
<sturm1>Seems to be something busted with Ungoogled Chromium - just won't let me toggle the selector from Mic: blocked to Mic: allow
<ryanprior>That exact thing happens when I run Jitsi Meet in Firefox, but not when I run it in Chromium.
<ryanprior>And when my friend tries to use it on their Chromebook it shows them my audio & video but doesn't broadcast at all.
<ryanprior>I'm researching a blog post about free software video communication tools for families staying in touch remotely, so this particular topic has been on my mind a lot lately =D
<bavier`>sturm1: that issue was present with an older version of our ungoogled-chromium
<bavier`>I recall some others needing to reset a configuration option that that older version set
<sturm1>ryanprior: I'd love to hear what you come up with - can you mention me if you come up with anything?
<sturm1>bavier`: thanks, I'm running a version that's under a week old, so maybe I'll try killing the config
<ryanprior>I'm installing ungoogled-chromium via guix right now to test
<sturm1>ryanprior: by the way, are you using snap packages on Guix System?
<ryanprior>I use Guix on a foreign distro (elementary OS)
<sturm1>ah
<ryanprior>I can mute & unmute my microphone in ungoogled-chromium freshly installed via guix
<ryanprior>if anybody wants to join https://meet.jit.si/HiGuixFreenode we can verify a/v
<ryanprior>Worked great on both ends, looks like the current ungoogled-chromium is ok
<sturm1>bavier`: you were spot on! Removing my Chromium settings fixed the issue immediately
<sturm1>that's super exciting, that's the first satisfactory videoconf I've had on free software, thanks ryanprior!
<ryanprior>Yay! Free software that delivers ✔️
<bavier`>sturm1: great!
<sturm1>Now I just need a haircut and we'll be all set
<bavier`>:)
<anadon>I'm having some trouble understanding how I need to modify the gnu-build-system for watchman (https://facebook.github.io/watchman/docs/install/#installing-from-source). It looks like `autogen.sh` needs to be added infront of `./configure.sh`, and to have `make check` deleted.
<lfam>anadon: To remove the check phase, add '#:tests? #f' to the arguments of the package definition
<lfam>The autogen.sh thing should be handled automatically
<ryanprior>Ooh, I hadn't seen Watchman before but it looks like something I've wanted for a long time.
<lfam>anadon: I would try letting the check phase run before disabling it. We always run them unless there is a good reason not to
<anadon>OK
<anadon>ryanprior: Right? Just last summer my work basically made a worse version of it.
<ryanprior>I mean there's basically a dozen crappy build tools I've used specifically because they offer the ability to trigger a process when a file changes, something that is inexplicably not trivial to do on a standard posix system.
<bavier`>I've heard good reviews of "entr"
<ryanprior>Looking at the repo.... bold choice of them to just put all the .cpp and .h files in the project root.
<ryanprior>entr looks nice too, I will play with it
<ryanprior>I wonder if it's expensive to run lots of entr processes, each with different rules, vs the watchman model which looks like it has a central daemon that is modified declaratively by subsequent cli calls
<rekado_>nckx: huh, looks like the search result isn’t sorted
<ryanprior>I'll have to look more at the architecture of each in order to compare fairly. But I've tried using inotifywait before and was never happy at all.
<anadon>Where's the documentation for git-download? I'm invoking it incorrectly with `(method git-fetch)
<anadon> (uri (git-reference
<anadon> "https://github.com/facebook/watchman"
<anadon> "8e0ba724d85de2c89f48161807e878667b9ed089"))`
<anadon>Right, IRC. Boy that's ugly.
<anadon>Looks like I got it figured out.
<lispmacs>is there a build system for godot games?
<ryanprior>🎉️
<anadon>Where is libtoolize? `guix seach` doesn't turn up anything and it isn't a directly named package.
<bavier`>anadon: in "libtool" package
<anadon>It errors that "libtool" is not a valid input
<anadon>`package `watchman@4.9.0' has an invalid input: "libtool"`
<guix-vits>Ihay Uixgay
***calher1 is now known as calher
***calher is now known as KE0VVT
<thelounge>how can I install and use guix with tor from pureos?
***modula2 is now known as defaultxr
<guix-vits>thelounge: you mean that the installation script should communicate with the Web only via tor?
<guix-vits>ah, (string-append 'nevermin' 'd')
<Veera>Hi
<cbaines>Hey o/
<guix-vits>which is correct: -0.1 = minus one "tenth", or
<guix-vits>"tenths"?
<guix-vits>Veera: Hi, is xplanet misses some .jpegs "venus", "moon"?
<cbaines>guix-vits, tenth
<cbaines>2/10 would be "two tenths"
<Veera>guix-vits: Hi
<guix-vits>cbaines: thanks. tested with 0.2, program outputs "tenths". So i need to substitute* the test that expect the 0.1 to be "tenth" (bsd-games).
<guix-vits>*to be "tenths"
<civodul>Hello Guix!
<cbaines>hey civodul :)
<Veera>guix-vits: Xplanet; did you try xplanet -window -body venus
<cbaines>congrats on getting the release out!
<guix-vits>+1
<Veera>guix-vits: I packaged all what was inside source.
<civodul>hey cbaines!
<civodul>i'm happy we made it :-)
<Veera>guix-vits: Additional maps have to be installed from outside sources!
<guix-vits>Veera: cool
<Veera>guix-vits: I see the warning about can't find venus.jpg in!
<Veera>guix-vits: am already finding to improve packages i submitted
<sirmacik>hey guix, does anyone use wireguard? I'm looking for some samples on how to use it
<guix-vits>Hi sirmacik; idk
<Veera>sirmacik: wiregaurd comes with linux-5.6 only
<sirmacik>no loadable module package?
<Veera>sirmacik: it has not been made default with current guix master
<guix-vits>Veera: i've no venus.jpg too, yes.
<sirmacik>how to switch to newer kernel while using master?
<Veera>sirmacik: though you can install the linux-5.6 by yourself; it is present in guix master source
<Veera>guix-vits: yes. the source does not ships all .jpg's
<sirmacik>:<
<sirmacik>hm, checking thx
<Veera>guix-vits: as I remember jpg's are for high fidelity images.
<sirmacik>Veera: what do I need to change in config.scm to have it from master?
<Veera>sirmacik: idk
<Veera>sirmacik: guix experts may help
<Veera>sirmacik: i am 1 month old user
<civodul>cbaines: hey, i realized we were already talking about a new release when we were at the RB summit
<cbaines>that's so long ago now, I forget what happened :)
<Veera>sirmacik: you can see guix mailing lists archives. vagrantc was saying he may enable 5.6 soon.
<Veera>sirmacik: i don't know but wireguard tools will be needed also. Whether packaged status not known?
<sirmacik>wireguard-tools are in repo
<sirmacik>I've got them installed, only module is missing
***reepca` is now known as reepca
<Veera>sirmacik: are you a new Guix user?
<sirmacik>just got back after few months, but this time I need wireguard for work ;f
<sirmacik>I can see there are some patches to explore on bugtracker
<rekado_>sirmacik: there is wireguard-linux-compat providing the kernel module for older kernels.
<rekado_>but I suggest to just “guix system reconfigure” after “guix pull” to a newer version.
<bricewge>rekado_: How do you use this package? It only contains the file wireguard.patch
<rekado_>the description says: This is an out-of-tree Linux kernel patch
<rekado_>so I suppose you’d build a kernel variant with that package.
<rekado_>(I haven’t used it.)
<rekado_>time to fix issues.guix.gnu.org!
<Veera>rekado_: how to use linux-5.6 with guix system reconfigure
<Veera>sirmacik: did rekado_ posted any way
<bricewge>rekado_: So like inheriting linux-libre and adding that file in patches?
<bricewge>I don't use it either, I'm just intrigued in how one can use it
<bricewge>Yay for a working issues.guix.gnu.org
<bricewge>Veera: I think the 5.6 kernel is limited for arm ATM, especially for the PineBook.
<Veera>bricewge: oh. that was posted by vagrantc.
<Veera>bricewge: the guix info pages don't document how to use a different kernel version. Any help page?
<bricewge>Veera: (kernel (specification->package "linux-libre@4.4.217")) as an OS field
<bricewge>It's untested
<Veera>bricewge: untested 4.4.217? or (kernel function?
<sirmacik>rekado_: rekado_: thanks!
<sirmacik>Veera: thank you! (:
<rekado_>“kernel” is a field in the operating-system declaration. It should be given a package value that provides the kernel you want to use.
<Veera>sirmacik: for my info did you specify version (kernel ?
<rekado_>(gnu packages linux) provides different versions of linux-libre
<Veera>rekado_: got it. was confused because info pages put it as "LINUX-LIBRE".
<rekado_>such as linux-libre (for the latest version), linux-libre-5.4, linux-libre-4.19, linux-libre-4.14, linux-libre-4.9, and linux-libre-4.4
<rekado_>capitalization is often used to indicate a Scheme value.
<Veera>rekado_: ok. thanks.
<sirmacik>hm, recado I've added that compat package to package list and did reconfigure, but after restart still no wireguard module found >:
<sirmacik>rekado_: sorry (: ^
<bricewge>Veera: No, as is I'm not sure if it works that way
<bricewge>sirmacik: It won't work that way the package, only contains a patch
<sirmacik>so what should I do to make it work now?
<sirmacik>I cannot find any docs to guide me through this process :<
<bricewge>There are none, you probably have to recompile the kernel with the patch that package provide
<bricewge> https://guix.gnu.org/cookbook/en/html_node/Customizing-the-Kernel.html#Customizing-the-Kernel
<bricewge>I'm looking into it. But probably the easiest way is to define a package with wireguard as a loadable module not just a patch to the kernel
<sirmacik>so I still need to compile the kernel?
<bricewge>Easiest as in no need to recompile the kernel
<sirmacik>bricewge: you mean that second snippet?
<bricewge>sirmacik: Yes, that is my understanding
<sirmacik>thx, I'll try
<sirmacik>but I think, for now I'll just swap disks in my laptop and wait it out till 5.6 >: thats overcomplicated way of doing things :<
<chiefgoat>Does Guix have a way of declaring Docker containers to run in the config.scm manifest?
<chiefgoat>From a registry like Docker Hub, for example.
<civodul>chiefgoat: no, there's no such thing currently
<chiefgoat>civodul: cool, just checking.
<civodul> https://www.heise.de/developer/meldung/Linux-GNU-Guix-1-1-ist-auf-dem-Weg-zu-minimalistischem-Bootstrapping-4703451.html
<leoprikler>Nett.
<rekado_>but the comments…
<rekado_>even the well-meaning ones are contributing to confusion
<rekado_>people seem to think that Guix is both a clone of Nix and that Guix System uses Nix as the package manager.
<leoprikler>Well, we do use a modified Nix core IIRC.
<leoprikler>but everything we build on top is guile, so it's not really the Nix package manager
<civodul>rekado_: uh
<civodul>leoprikler: the daemon's code come from Nix, and it's important, but... there's more than the daemon
<civodul> https://osf.io/fsd7t/ <- "best practices" for Dockerfiles
<civodul>an oxymoron
<leoprikler>oh, sure, the vast majority of our codebase is Guile
<leoprikler>Best practice #1: name it "manifest.scm"
<civodul>heh
<civodul>it's interesting how much activity that can generate
<NieDzejkob>it would be nice to write a paper that cites them, explains why the practices are insufficient, and shows how to achieve better reproducibility with Guxi
<NieDzejkob>Guix*
<civodul>yup
<efraim>civodul: replacing glibc-2.31 with 2.30 in the bootstrap-binaries seems to work for powerpc, I made it past guile-bootstrap
<civodul>i feel like we've been giving talks on that topic for maybe 3 years?
<civodul>efraim: oh "nice" (with quotes because downgrading is usually not a good sign :-))
<efraim>it's an abandoned architecture, I'm guessing there's a patch somewhere upstream like there is for libffi
<efraim>honestly I partly feel like best-case-scenario is having an official branch called ppc-master where these things can be fixed without impacting the rest of Guix
<efraim>"fixed"
<efraim>like how mips got deprecated when no one was around to fix show-stopper bugs on core-updates so everything else could go on
<ecbrown>just curious, is ppc the g5 and/or power series?
<efraim>I'm using a g4, g5 is 64-bit PPC, but mostly when people now refer to PPC64{le} they mean POWER8+
<leoprikler>"you should use indentation, new lines, and comments to make219yourDockerfiles well documented and readable" Thanks, I guess.
<civodul>heh
<leoprikler>I also like "if you don't have enough space, use more containers"
*guix-vits "yrffre guna, guerr"
<ecbrown>think i'm having a hard time with guile-emacs. wondering if anyone has actually got it built -- not expecting over a day on my 9900k.
<rekado_>ecbrown: no, there’s a regression that causes the build to take forever.
<rekado_>I’m still working on updating wip-elisp
<ecbrown>rekado_: thank you for this info! i can stop fretting
<ecbrown>well
<raghavgururajan>Hello Guix!
<bricewge>Hi raghavgururajan
<rekado_>civodul: we’re slowly running out of space on ci.guix.gnu.org and my trick of deleting disk images no longer frees up space.
<rekado_>I wonder if something has changed that keeps more big things alive
<rekado_>we’re down to 6.6TB free space.
<rekado_>previously I was always able to free up around 17TB.
<civodul>oooh, the search box on ci. is cute
<rekado_>10TB in just a few weeks looks wrong.
<civodul>rekado_: we still haven't changed the threshold for guix gc -F though?
<rekado_>I ran my command to list dead qemu-/disk-image and installation items, and then feed them to guix gc -D
<rekado_>and that used to give me about 17TB of free space
<rekado_>now it’s at 6.6TB and it pretty much stays there, even after gc
<civodul>that's super expensive tho
<rekado_>so something’s definitely off.
<civodul>oh
<rekado_>yeah, I’m just using this as an emergency fix to free up space
<civodul>we should check disk-image* in /var/cache/guix/publish
*civodul half on a conf call for work
***guix-vits is now known as thvk-ivgf
<mbakke>rekado_: the extra disk space usage could be from core-updates? I've been running 'guix weather' a lot so that there are pre-baked NARs for pretty much everything.
<civodul>$ du -hsc /var/cache/guix/publish/lzip/*qemu-image* | tail -1
<civodul>6.1G total
<civodul>+ 2G for *disk-image*
<civodul>roughly multipled by 3 if we account for /gzip
<civodul>that's less than 30G of disk images in 'guix publish' cache
<davexunit>if I have a guix.scm file in my project repo that can be built using `guix build -f guix.scm`, what's the easiest way to install that into a profile? I'm a bit rusty and `guix install` has no similar -f flag.
<thvk-ivgf>davexunit: `guix package -f`?
<rekado_>mbakke: but 10TB…?
<g_bor[m]>hello guix!
<g_bor[m]>Anyone has has a direct contact to Danny?
<thvk-ivgf>Uv t_obe[z] :)
<davexunit>thvk-ivgf: ah okay, going back to the old tool.
<anadon>Good morning all
<davexunit>guix install only does a subset of what guix package does
<davexunit>thvk-ivgf: thanks
<thvk-ivgf>np
<g_bor[m]>I guess I can just send a GSoC slot request 2/2 if I don't get a response.
<mbakke>rekado_: right, it should not take that much space
<mbakke>rekado_: on a related note, maybe we can delete some pre-1.0.1 GC roots?
<davexunit>I haven't yet pulled the 1.1.0 release. is guile 3 the default guile now?
<davexunit>as in 'guix install guile' will install 3.0.2?
<civodul>davexunit: that'll be after the core-updates merge, soonish
<civodul>in the meantime you can use guile-next with guile3.0-*
<anadon>There's an invoke that I want to change the directory a script is being invoked from. "tests/runtests.py" -> "./runtests.py". What is the correct way to do this? I take it adding a "cd" "tests" ";" as leading arguments is not good.
<usney>Hello guixers!
<usney>Hi Blackbeard
<usney>how are you doing pal?
<vagrantcish>cbaines: thanks for the catch on diffoscope! ... had finally gotten it to build after hours of local openjdk builds ... and then thought "oh, looks like there's a new tool available" and didn't think to test that...
<mbakke>anadon: you probably want 'with-directory-excursion'
<cbaines>vagrantcish, No problem, it was easy enough to fix :)
<mbakke>anadon: in most cases you can just call "./tests/runtests.py" directly though
<vagrantcish>cbaines: embarrasingly so, from there :)
<vagrantcish>er, from here
<anadon>mbakke: Not in python
***amiloradovsky1 is now known as amiloradovsky
<civodul>something's wrong with our tests: https://ci.guix.gnu.org/search?query=openssh+spec%3Aguix-master+system%3Ax86_64-linux
<mbakke>civodul: I accidentally clicked that link two times and got two different screens: one with all red and one with all green!!
<rekado_>I’m very confused about the search result.
<cbaines>I'm not sure what the ordering is on that page, sometimes when I press "First" I get them all green
<rekado_>yeah
<rekado_>super weird
<cbaines>othertimes they're all red
<civodul>mbakke: it's called A/B testing!
<vagrantcish>civodul: i also not been able to find recent derivations with the ci.guix.gnu.org search lately
<mbakke>lol
<civodul>heh, i can't tell if they're recent or not actually
<civodul>i just fixed a bug in Cuirass so that the year would be shown for builds >1 year-old
<rekado_>and sometimes the page stays empty
<civodul>(a bug i implemented all by myself)
<civodul>weirdness
<rekado_>when’s the cuirass hackathon?
<civodul>it's already began!
<rekado_>the database queries are much too big for me to understand
<civodul>ahem, some of us are late!
<civodul>yeah, the database queries need an expert
<rekado_>:)
*civodul looks at cbaines
<cbaines>Haha, don't look at me :) I mostly do PostgreSQL
<rekado_>close enough!
<cbaines>I have been hacking on something using SQLite for the past couple of weeks though: https://git.cbaines.net/guix/build-coordinator/about/
<vagrantcish> https://ci.guix.gnu.org/search?query=openjdk returns only 6 entries ...
<vagrantcish>but i'm fairly sure there are more openjdk substitutes than that
<vagrantcish>and more recent than october
<civodul>cbaines: look, it has "SQL" in it so it must be very similar :-)
<civodul>"guix-build-coordinate", oh!
<civodul>*coordinator
<cbaines>Just some hacks to build derivations, but hopefully in a way that works across multiple machines, and can be put to work to provide substitutes/test package builds
<civodul>sort of a scheduler that would work accross machines, right?
<civodul>in work-stealing fashion IIUC?
<pkill9>is it better to use guix's openvpn service, or the openvpn networkmanager plugin?
<cbaines>civodul, I'm not familiar with work-stealing, but probably. The coordinator/scheduler knows about the builds and does some allocating, then agent processes request builds to do.
<civodul>ok
<civodul>sounds really cool
<cbaines>Doing this outside the daemon should allow for playing around with things like prioritisation and working across multiple machines
<civodul>yeah
<civodul>Hydra did this outside the daemon, but it ended up duplicating scheduling functionality and sort of stepping on the daemon's toes
<civodul>so i thought: hey, let's be smart, let the daemon handle it all!
<civodul>but... it didn't work out that well
<civodul>but perhaps the coordinator could become part of the new daemon that reepca worked on
<cbaines>Yeah, I'm viewing this somewhat as a short term hack. Once there's a Guile implementation of the daemon (when, not if), maybe some of this kind of functionality could be incorporated somehow
<civodul>so that we don't have to make a binary choice
<civodul>yeah
<cbaines>One of the next things on my list is to see if I can hack guix-publish to take a nar file and generate a narinfo file, that would provide a way of using this to provide substitutes
<chiefgoat>I'm about to guix deploy to a Digital Ocean droplet and had a question: does (configuration (digital-ocean-configuration (ssh-key "$HOME/.ssh/id_rsa") authorize the droplet for passwordless ssh auth against my deploying machine?
<raingloom>is there a way to stop xorg/gdm gracefully? something like `systemctl stop lightdm`? i tried `herd stop xorg-server` but it also broke my vtty.
<efraim>I'm up to perl-boot0 after almost 4 hours
<cbaines>back to Cuirass though, is there a hackathon today? (I don't remember seeing anything about that)
<efraim>raingloom: how about display-manager?
<raingloom>efraim: there is no such service
<efraim>are you sure? I have a display manager service somehow
<efraim>raingloom: it's the name for sddm apparently
<efraim>we should probably change that so it conflicts with gdm
<efraim>and slim
<raingloom>efraim: yup, i looked at herd status and i can't see it. but there isn't anything named gdm either.
<efraim>apparently slim and gdm provision xorg-server
<efraim>slim also provisions vt7
<mbakke>perhaps they should have their own names and VT so you can run all at once :)
<civodul>cbaines: i think rekado_ was suggesting to have one, and the two of us hacked it a bit today
<efraim>I'll write up a patch to make sddm conflict with gdm/slim
<civodul>i think i added what i missed the most to the web UI
<civodul>now i'd add stuff to the JSON API
<civodul>and fix the /api/queue query
<civodul>what about you people? what would you like to improve in Cuirass?
<raingloom>efraim: then it looks like i was trying to stop the right one. welp, it's not a super important feature, but i wanted to free up some RAM for building things while I go outside.
<cbaines>I guess it should be possible to set Cuirass up in such a way that the evaluations stop occasionally failing due to lack of build slots on bayfront: http://bayfront.guix.gnu.org/jobset/guix-master
<cbaines>I think I looked at this before, limiting the number of concurrent builds that Cuirass does, but I didn't get very far.
<civodul>oh
<civodul>did you try increasing the number of build users?
<cbaines>I think I saw you do that
<cbaines>I think the issue is the actual number of builds happening.
<cbaines>The daemon runs with --max-jobs=4, and I think if Cuirass is using up those 4 jobs, when it goes to do an evaluation, it can just fail due to the lack of a slot
<anadon>When guix runs something "in a terminal", is it possible to see the equivelent invokation when a package is being built?
<civodul>cbaines: i don't see any such issue though on the front page
<anadon>In particular, some python tests are now automagically breaking now that they are being run from the correct directory.
<civodul>cbaines: max-jobs is the number of jobs per session, and Cuirass typically has 1 per "evaluate" process + 1 for all the builds
<civodul>maybe more
<cbaines>Ok, looks like bayfront has 16 build users, so maybe it just needs more
<efraim>ok, patch sent
<davexunit>civodul: thanks for the info!
<civodul>cbaines: yeah, berlin has 80 of them
<bricewge>What's up with ci.guix.gnu.org?
<vagrantcish>bricewge: that's a bit overly open-ended :)
<bricewge>It is awefully slow both from my landline and my connection. It tops to 50 KiB/s
<bricewge>vagrantcish: Sorry I'm a slow typer...
<efraim>local congestion? 50KiB/s is pretty slow
<bricewge>s/connection/mobile connection/
<bricewge>I mean, am I the only one with such a slow connection?
<anadon>Guys, django needs to install an instance of itself for its self-tests. How should I be handling this?
<vagrantcish>ci.guix.gnu.org is sometimes pretty slow to get results ... haven't specifically measured the bandwidth
<chiefgoat>Getting an error in my guix deploy:
<chiefgoat> guix deploy: error: failed to deploy mercy: Wrong type argument in position ~A: ~S
<chiefgoat>What does this mean?
<efraim>sometimes when it's really slow i'll download the sources when I don't need them so I can build locally
<efraim>'guix package -A | cut -f1 | sort -u | xargs ./pre-inst-env guix build --sources=transitive' and then I can 'guix package -u . --no-substitutes'
<anadon>django it trying to install to "/homeless-shelter" and failing because it doesn't have permissions.
<bricewge>Thanks for the tips efraim!
<davexunit>anadon: I don't know anything about django but what I can say is that /homeless-shelter is the default value of the $HOME environment variable inside the guix build container, so probably the django code is using that variable.
<davexunit>maybe making a new directory somewhere and setting that as $HOME would help you get past the issue
<chiefgoat>I feel like I am asking the wrong questions or my questions are in poor taste
<plstohelp>it might have something to do with the sometimes slow pace of the channel
<plstohelp>and
<plstohelp>dare i say it
<plstohelp>inheirent limitations of IRC
<plstohelp>things slip through for no appearent reason
<chiefgoat>Oh yes but I do love my Emacs interface into IRC
<plstohelp>it's why I'm more of a fan of forums than of IRC channels for this sort of tech support
<plstohelp>>emacs interface
<chiefgoat>Maybe I should just fire this one into the mailing list
<chiefgoat>though I'm sure one of our Scheme adepts must be able to decode Wrong type argument in position ~A: ~S
<plstohelp>I am fascinated by GUIX
<plstohelp>hopefully it represents the future of the whole community
<plstohelp>free us from the grim dark future of free software with google charictaristics
<plstohelp>my god, my clumsy fingers
<chiefgoat>"Kuberguix"
<cbaines>chiefgoat, ~A: ~S are placeholders, is there any output after that?
<chiefgoat>cbaines: I'm afraid not. Shall I post my config.scm?
<plstohelp>more like google fuchsia
<cbaines>chiefgoat, sure
<plstohelp>quiver in fear, the permissive liscence is here
<plstohelp>if i may ask a question
<chiefgoat>cbaines: https://gist.github.com/8c8978e5ba198c4b6984823ae6b417b5
<plstohelp>i haven't had time to set up a test machine fo guix, so i have just been reading the documentation
<plstohelp>i want to make sure I understand the purpose of pre-inst-env
<plstohelp>it is to run your "made" software, especially in the context of a guix environment, without installing it to your main machine? to help keep your development "in isolation" as it were?
<plstohelp>or rather to avoid installing it to the gnu/store outside of the environment
<anadon>davexunit: What I need is a place for `pip` to install django because django's built in tests require that django be installed.
<usney>what did guix packager for chromium do to degoogle it?
<mbakke>anadon: python-build-system runs tests after installing the package, but you might need to use (add-installed-pythonpath ...) to make the test runner find it.
<mbakke>usney: see https://github.com/Eloston/ungoogled-chromium
<usney>that was fast
<usney>are you sure you are not a bot?
<plstohelp>lol
<plstohelp>is my understanding of pre-inst-env accurate?
<cbaines>chiefgoat, I haven't used guix deploy, but the docs say the tags of the digital-ocean-configuration should be a list
<chiefgoat>cbaines: that must be it!
<vagrantcish>plstohelp: "./pre-inst-env guix" is used to build work-in-progress local builds of packages
<vagrantcish>plstohelp: which can eventually be submitted to guix for inclusion ... everything you do from there still ends up in the store
<plstohelp>good to know
<plstohelp>so what is different from simply doing a make install
<vagrantcish>it generates a recipie for building the package, and asks guix-daemon to build the package in a container
<plstohelp>gotcha
<vagrantcish>with only the dependencies available
<plstohelp>thanks
<vagrantcish>so whatever you have installed in your system or user profile won't change the build results
<plstohelp>i think, once i get a test machine set up, i will try packaging vscodium for guix
<vagrantcish>as opposed to make install, which will use all your installed this-and-that
<plstohelp>one more question for today
<plstohelp>at ci.guix.gnu. org
<plstohelp>what does "build failed" mean
<plstohelp>does that mean no reproducible build available? no brinary availably so you have to build localle?
<vagrantcish>that means no build at all
<plstohelp>so
<vagrantcish>yes, you'd have to build locally, though it might fail in the same way
<plstohelp>gnome-shell is... not available on guix? despite the homepage's claims?
<plstohelp>oh i see
<plstohelp>hmm
<vagrantcish>sometimes intermittant failures will cause a build to fail ... e.g. disk space, ram resource limitations
<plstohelp>isnt ci using the build farms to build?
<vagrantcish>yes
<chiefgoat>cbaines: That was it! Thank you.
<plstohelp>that is troubling
<vagrantcish>nothing is infinite :P
<plstohelp>i suppose
<plstohelp>someone is having network troubles
<vagrantcish>there may also be build timeouts ... some builds take an absurd amount of time
<vagrantcish>one of the interesting things with guix is ... local builds, substitute builds ... no real difference to the end-user (other than time it takes to build)
<plstohelp>well, that is a consideration
<vagrantcish>it's all the same commands to install/upgrade/etc
<plstohelp>after all, i remember always being glad when a package moved from AUR to community because no more build times
<plstohelp>but i appreaciate what guix does to make things simpler
<plstohelp>since even with helpers, AUR installs have extra sauce anyway
<vagrantcish>since guix rebuilds a package every time one of the dependencies change (more or less) ... it tends to trigger a lot of builds
<plstohelp>i might take a crack at making a more user friendly rollback utility
<plstohelp>take everything from guix rollback and put it in something like timeshift
<plstohelp>not a copy, but rather a gui wrapper
<plstohelp>i should donate to the build farm
<vagrantcish>maybe start by trying it out :)
<plstohelp>of course
<plstohelp>my problem is setting up a guix machine is impractical
<plstohelp>for now
<plstohelp>all the ethernet ports are occupied, and I dont have any hardware with free wifi drivers
<plstohelp>but i can move some stuff around
<vagrantcish>virtual machine?
<plstohelp>yeah but build times in a vm? surely they're bad
<plstohelp>that and i am stuck with 36 gb of vms for a class im taking so my space is tight rn
<plstohelp>but that class will be over in 2 weeks
<vagrantcish>VMs aren't really all that much slower these days ...
<plstohelp>thats reassuring
<plstohelp>then i will give that a try
<vagrantcish>if you have hardware virtualization (most modern CPUs do)
<plstohelp>i can spare 10gb if i clean up some stuff
<plstohelp>I'll probably do that today
<plstohelp>thanks for the help
<efraim>if anyone wants to check out my wip-ppc branch it's here: https://gitlab.com/Efraim/guix/-/tree/wip-ppc
*efraim goes AFK until tomorrow
<bricewge>sneek: Later tell sirmacik I have written https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40683 to easily use the wireguard module without having to recompile the kernel, there is a example in the patch.
<sneek>Okay.
<bricewge>sneek: Botsnack
<sneek>:)
<civodul>janneke: hey, there's no entry in etc/news.scm on core-updates for the reduced² binary seed bootstrap!
<civodul>R²BSB
<plstohelp>haha i've been looking at the wrong system arch on curiass
<plstohelp>amd64 availability is great
<janneke>civodul: oh! that's bad
<plstohelp>thank god
<civodul>janneke: would you like to add one like we need for RBSB? :-D
<civodul>s/need/did/
<janneke>civodul: yes!
<civodul>yay!
<civodul>so today i went deep down in a rabbit hole and now i can't find the exit
<vagrantcish>civodul: if you yell loud enough, maybe i can call back
*civodul .oO( hmm callback, inversion of control, is that a good idea? )
<vagrantcish>pretty sure i've been navigating a network of rabit holes for over a decade now...
<reepca>whenever I go deep in a rabbit hole I find myself going depth-first, which is awful considering how bad I am at remembering what's two stack frames above me
<civodul>yeah i think that's what happened to me
<civodul>oh well!
<g_bor[m]>Hello guix!
<civodul>hey ho, g_bor[m]!
<g_bor[m]>As of now we are all set for GSoC and Outreachy.
<civodul>yay, big thanks, g_bor[m]!
<raghavgururajan>The Syndicate
<g_bor[m]>civodul : should I ask around one more time in the spending comittee before approving the Outreachy selections? The funding is already approved.
<civodul>g_bor[m]: i think we approved it already, so it should be fine
<civodul>we can keep approving it, but... :-)
<g_bor[m]>Ok. Thanks.
<anadon>How does network isolation work when building a package? I'm wondering if some of django's failures are due to that.
<civodul>anadon: there's nothing but the loopback device and the "localhost" host name
<anadon>Thanks
<chiefgoat>A guix deploy to Digital Ocean hangs indefinitely with the deployed resource showing no activity. I'd be happy to submit a bug report but guix deploy isn't very verbose so I don't know what more I'd include other than my config.scm
<civodul>chiefgoat: can you log in on the Digital Ocean node and check its status?
<civodul>the first step is to install Guix there
<chiefgoat>civodul: yep! I did so and a droplet was created according to my manifest
<civodul>so you can check how far that went: did it create the "guixbuild" users, is /usr/local/bin/guix available, etc
<civodul>i mean "guix deploy" installs Guix for you on top of Debian 9, AFAICS
<chiefgoat>Yeah, I confirmed that
<anadon>Looks like tests are now failing when handling cli input related tests are run. I have bash and busybox installing as deps, but what else might it be expecting?
<chiefgoat>I didn't specify a password for my user: intention was to ssh in when guix deploy had finished
<civodul>did the droplet reboot into Guix System?
<chiefgoat>I'll try and set a hashed password, recreate and see if I can have a looksee
<chiefgoat>Going over the docs, it looks like root initially has an empty password?
<chiefgoat>But that must be for standard installs because it looks like it's not true for deploy invocations
<chiefgoat>Ok so it did auth the droplet against my ssh key
<chiefgoat>civodul: But there's no guix available in /usr/local/bin and no guixbuild user created
<chiefgoat>If I do a top command I don't see any guix related processes
<chiefgoat>So it doesn't look like it's attempting anything once it's got the vm up
<chiefgoat>It just creates a Debian 9 image and then backs off
<chiefgoat>And guix deploy hangs infinitely
<janneke>civodul: pushed a news entry
<janneke>i still have to update the documentation on this too!
<janneke>eh, about the further reduced binary seed bootstrap
<civodul>thanks, janneke!
<janneke>civodul: now running ./pre-inst-env guix build hello --no-offload --substitute-urls="http://192.168.178.22:8080 https://ci.guix.gnu.org"
<janneke>now to get rid of my amazing "env.sh" script
<cbaines>what does you env.sh script do?
<janneke>ah, it allows me to run `./bootstrap', ./configure and make in our Hurd VM
<janneke>i forgot to add packages for the gnu build system into the profile
<janneke>so, it scripts gcc-toolchain and sets PATH
<janneke>and then it hacks around a cross-build issue, i'm not sure which it is yet
<cbaines>right :)
<civodul>janneke: woow!
<ATuin>any idea why the #:phases are not modified here: https://pastebin.com/NcEqpaJc
<sirgazil>How do I indicate "guix system vm" how much RAM it should use? I forgot...
<nckx>ATuin: Did you mean to start from %standard-phases scratch again? Otherwise, (#:phases phases) `(modify-phases ,phases (add-before …
<nckx>'lo Guix.
<user_oreloznog>sigarzil: you can use 1024 or 2048
<user_oreloznog>MB ram
<ATuin>nckx: yep, i realized i was missing the quote :D
<ATuin>now it's triggering my custom error
<ATuin>i'm trying to debug some ASDF problems i found
<user_oreloznog>*sirgazil :-)
<sirgazil>user_oreloznog: without indicating any option like "-m" or something?
<user_oreloznog>Hmm... Don't remember...
<user_oreloznog>I have used virt-manager
<sirgazil>That's what I need to know :)
<user_oreloznog>I can't have a look now :/
<user_oreloznog>It was in graphical mode and I haven't need to indicate an option
<sirgazil>No problem, I'll see if there is an example in the manual.
<user_oreloznog>Ok ;-)
<sirgazil>Ah, silly me, you run "guix system vm" to create the VM, not to run it, I can pass "-m 1024" to the result.
<user_oreloznog>Ah, yes... I have see that somewere...
<janneke>civodul: yeah...too bad it starts rebuilding glibc-intermediate, python-boot0 and all that
<Blackbeard>Good day Guix :)
<janneke>oh well
<user_oreloznog>Hello Blackbeard!
<sirgazil>Buenas, Blackbeard :)
<pkill9>hello Blackbeard
<pkill9>im getting these errors in /var/log/messages when trying to start openvpn service:
<pkill9>Apr 17 19:46:03 localhost openvpn[1250]: Options error: --cert fails with '/etc/openvpn/client.crt': No such file or directory (errno=2)
<pkill9>Apr 17 19:46:03 localhost openvpn[1250]: WARNING: cannot stat file '/etc/openvpn/client.key': No such file or directory (errno=2)
<pkill9>Apr 17 19:46:03 localhost openvpn[1250]: Options error: --key fails with '/etc/openvpn/client.key': No such file or directory (errno=2)
<pkill9>y
<pkill9>do i need to generate these files? if so, how?
<Blackbeard>:)
*thvk-ivgf "Uv Oynpxorneq, Uv apxk."
<bandali>thvk-ivgf, why are you rot13'd?
<ATuin>pkill9: is not that a normal certificate? if so just use openssl
<nckx>thvk-ivgf: are you using a dark web
<nckx>pkill9: Or it's something your VPN provider, er, provides, perhaps embedded in another file (.ovpn?).
<pkill9>nckx: the vpn config they provide doesn't give a certificate file, and i could connect without specifying --cert
<pkill9>is it possible to just pass it an openvpn configuration file?
<nckx>pkill9: The default service configuration assumes those files exist and writes a .conf explicitly referring to them. That's… somewhat surprising. Can you manually set ‘cert’ and ‘key’ to #f in the service configuration?
<nckx>I dunno.
<pkill9>i tried setting cert to #f but it said it's invalid
<nckx>The service in its current state is rather inflexible.
<thvk-ivgf>bandali: orpnhfr v hfr Nepu'f CXTOHVYQ bs ofq-tnzrf naq vg'f n terng sha
<thvk-ivgf>nckx: https://paste.opensuse.org/94770761 :)
<nckx>Export-grade crypto that is.
<bandali>lol
<pkill9>i'm trying to use mullvad vpn
<ATuin>btw ... there isn't bsd-games in guix, right?
<Blackbeard>thvk-ivgf: is that some sort of pig latín?
<pkill9>i'll try settings key and cert to something empty
<bandali>Blackbeard, it's rot13
<thvk-ivgf>Blackbeard: rot13, all letters rotated +13
<Blackbeard>bandali: ahh I see
<bandali>:-)
*vagrantc wonders what rot-13 looks like in UTF-8
<null_radix[m]>anyone else having problem building off of master rn?
<null_radix[m]>make is crashing with `error: failed to load 'gnu/tests/docker.scm':`
<null_radix[m]>but it was working a couple of days ago
<thvk-ivgf>ATuin: Arch have a good config.params and a PKGBUILD, though.
<rekado_>I’m getting this now: rsync: This rsync lacks old-style --compress due to its external zlib. Try -zz.
<rekado_>I guess that’s fine because -zz works fine, but I’m so used to typing “rsync -azvhr”…
***rekado_ is now known as rekado
<nckx>rekado: It's a horrible UI choice.
<sammich>howdy, i accidentially submitted 2 patches rather than one (i made a small fix and meant to reply to the first), how can i close one?
<nckx>‘In the future this new-style compression will likely become the default’, but who knows when that will be.
<ATuin>thvk-ivgf: nice, i like bsd-games :D
<nckx>sammich: Send ‘close NNN’ to control@debbugs.gnu.org
<sammich>thank you nckx
<thvk-ivgf>ATuin: are score-files is important part of any of those games?
<dbdude>Noob here. Can anyone tell me where to find the system config file for GNU Guix 1-1.0? In 1.0 there was one in /etc
<mroh> dbdude: /run/current-system/configuration.scm
<thvk-ivgf>dbdude: if you mean the installation media, /etc/configuration/ (acc. to manual)
<dbdude>thvk-ivgf: I'm in a VM. I want to build a suitable system starting from there. No sign of configuration.scm under current-system
<thvk-ivgf>dbdude: /etc/configuration (idk, anyway :)?
<dbdude>thvk-ivgf: Also no /etc/configuration :-)
<dbdude>Should I try the disk image instead?
<thvk-ivgf>dbdude: there was some templates in Git...
<civodul>dbdude: perhaps the config is not in the VM image
<dbdude>thvk-ivgf: I'd kinda like o know that the template matches what I'm using. Finding *a* template is not the problem. Knowing that it's the basis for my current VM is where I'm failing
<dbdude>civodul: It does look a little like that.
<civodul>ah yes, it's a mistake
<civodul>dbdude: you can find it here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples/vm-image.tmpl
<dbdude>civodul: brilliant, thx
<rekado>a fix for issues.guix.gnu.org will take me a little while longer
<rekado>debbugs stores mails in a bit of an odd format, which needs to be parsed.
<rekado>but for the search we need one file per message
<rekado>I’m tempted to throw out our fork of mu and index these debbugs log files directly
<rekado>for the short term I’ll probably have to rsync repeatedly, then parse modified files and extract mboxes, then index those mboxes
<rekado>not great
<rekado>:-/
<civodul>it would extract one mbox per message?
<dissoc3>is there a global way to set the number of jobs a build will use for when guix builds packages? make -jN
<cbaines>dissoc3, most Guix commands accept --cores=N
<dissoc3>okay so that would work with sudo guix --cores=10 system reconfigure /etc/config.scm
<civodul>"guix system reconfigure --cores=10 /etc/config.scm"
<dissoc3>thank you
<bandali>hey folks, what's the program used to run and render logs.guix.gnu.org?
<rekado>bandali: it’s goggles.scm in maintenance.git
<bandali>thank rekado
<rekado>civodul: I need a maildir for mu.
<rekado>so one mail per file
<rekado>if I can get rid of this headache, get enough sleep, and the baby approves of my plans I think I’ll replace mu with guile-xapian and index the debbugs files directly.
<rekado>we would lose the ability to run mumi as a mere debbugs client
<rekado>I hope I can preserve that mode
*rekado –> zzZZ
<Blackbeard>rekado: good night :)
<nckx>civodul: Should you commit <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40689>? I think it best that not too many (more) people touch that file.
<nckx>Same for <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40565#27>.
<anadon>Anyone have the doc for invoke? I need to dig into why python's `sys.executable` might be returning None.
<nckx>Invoke PROGRAM with the given ARGS. Raise an exception if the exit code is non-zero; otherwise return #t.
<civodul>nckx: sure
<nckx>anadon: That's it. You'll have to read (guix build utils) if you want more than that.
<nckx>Thanks!
<civodul>nckx: i'm postponing the 2nd one, do ping me tomorrow if needed :-)
*civodul -> zZz
<anadon>nckx: I'm getting the nagging impression that argv[0] might be missing.
<nckx>anadon: Would (invoke "python" "the-script" …) do as a quick work-around?
<anadon>nckx: Already doing that: `(invoke "python" "./runtests.py" "-v" "3")`
<anadon>hang on, I'll post the package and maybe you'll see something off of that.
<nckx>Odd. I mean, not something I've encountered before (unlike many bugs posted here 🙂)
<anadon>nckx: https://dpaste.org/T36M
<nckx>The commented phase, rite?
<anadon>nckx: No, line 46
<anadon>I don't know of a way to make it interactive so I can dig in to what state is there.
<anadon>And I'm still not fluid enough to easily switch it over to a forked repo and edit things on there to figure it out.
<nckx>I'll poke at it inbetween work stuff.
<nckx>Do you happen to have a buildable copy (e.g. including python-asgiref) in whatever form you're using?
<anadon>nckx: Here are the failures -- they all look like they involved running a cli subprocess of python subshell or something: https://dpaste.org/Lvtb
<anadon>nckx: Hold on, I'll fork my guix copy and commit my changes to that.
<anadon>There were a large number of packages which needed to be added or changed.
<nckx>anadon: I certainly don't debug ‘interactively’ either. I presume you know about ‘guix build … --keep-failed’ already. Is there a log file left behind there? This output alone tells us nothing (I'm impressed you got as far as argv[0] suspicions).