# IRC channel logs

## 2020-05-06.log

back to list of logs

<Blackbeard>Hello guix (:
<bav[m]>hi Blackbeard
<rekado>mbakke: I played with 186 to build icedove more quickly, but it should work just fine.
<rekado>I’m running an ambitious ‘guix gc -F7T’ on ci.guix.gnu.org
<rekado>feel free to kill it when necessary
<rekado>I’m just worried about running out of space when I’m not around
<rekado>plymouth works on my booted system, but it doesn’t work correctly in the initrd yet
<rekado>it can’t find a graphical display, so it just prints text
<rekado>the testing loop is pretty slow as I need to wait for the initrd and VM to be rebuilt every time.
<rndd>hi everyone! i'am trying to run .jar app on guixsd, but there some errors which i didn't have on debian.
<usney>is it say to stop a pull from doing an upgrade if my cpu is getting too hot?
<usney>I am going to get some new thermal paste for it later on today.
<bav[m]>That's fine, yes. The action is atomic.
***catonano_ is now known as catonano
<butterypancake>I'd like to get the latest version of emacs, tracked straight the dev git reposity. Has anyone already done this and created a guix package like that?
<butterypancake>I'm a guix noob that hasn't done any packaging yet
<butterypancake>whatever, I guess emacs-next will do for now
<apteryx>butterypancake: guix environment --ad-hoc emacs-next --with-git-url=emacs-next=https://git.savannah.gnu.org/git/emacs.git
<Blackbeard>apteryx: that's pretty cool
<mmdev>emacs-next need emacs-next-no-x. :)
<apteryx>mmdev: does it?
<butterypancake>thank you so much apteryx!!
<apteryx>yw!
<mroh>time for coffee: building /gnu/store/w1l1fp1nfn05qy2pyvrm9qm0j3l7yl76-guix-translated-texinfo.drv...
<apteryx>ah!
<Afront>Hi, I have a fresh install of Guix on VirtualBox, but it hangs whenever I try to log in, and I'm not sure why. I have awesome-wm and i3 on my machine.
<apteryx>Afront: do you have SSH access? You could try to sniff /var/log/messages or /var/log/Xorg.0
<apteryx>if if doesn't hang completely, you could try moving to a pseudo TTY (Alt-F2) and login without the graphical environment
<Afront>Okay, thanks! Pretty much everything worked until I enter the correct password. Logging in through ssh seems to fix the problem.
<apteryx>the passwords are left blank for users on a fresh install. You must run 'passwd your-user' as root to define on.
<apteryx>s/on/one/
<Afront>I think I set the password during the installation since it allowed you to create users (with passwords).
<apteryx>I see, you used the graphical installer?
<Afront>Yeah
<usney>do motherboards have a max temperature? It appears my new cpu can run at a higher maximum than my older one according to wikichip.
<usney>whoops wrong channel
<apteryx>usney: no problem
<apteryx>usney: using lm-sensors 'sensors' command, on my desktop, I can see a line: MB Temperature: +48.0 C (high = +45.0 C, crit = +95.0 C)
<apteryx>I would trust the manufacturer specs more than lm-sensors for the max value, but it gives you a first metric of what's OK.
<usney>I am using a gui lm-sensors
<usney>xsensors
<usney>I looked on intel for the cpu and I don't see anything about max temp
<usney>maybe they call it something else?
<butterypancake>what cpu we talking about? I'm pretty sure for most modern, consumer chips you don't have to worry about this stuff a lot. They got hardware throttling and saftey features baked in
<usney>yes I have those baked in
<usney>I am just seeing if I need to get new thermal paste or not
<usney>I just upgraded recently to a new cpu on my laptop so seeing if it is operating at safe temps
<butterypancake>ah, there we go. Was wondering what the oddity was. You're in a laptop. Your worry is justified and I now understand
<usney>wikichip says the TJmax is 100 C and lm-sensors is reporting 96 C
<usney>temp1: +72.5°C (crit = +96.0°C)
<usney>critical is +96 C
<usney>my single board computer with heatsink and fat runs a lot cooler than my laptop runs at normal
<usney>fan*
<butterypancake>does thermal paste even make a big difference? I remeber Linus Tech Tips using liquid metal in laptops and only getting a few degrees. Also liquid metal is expensive and scary
<usney>I read liquid metal isn't safe to use especially for beginners
<usney>I have been doing research on that too.
<usney>also it doesn't last as long and it is expensive
<butterypancake>but it's in theory the best compound out there I think. And LTT found a tiny difference if I remeber properly. Meaning that unless you're currently using toothpaste, I don't think you have much more improvment you can gain
<usney>yes but my thermal paste is an unknown age it is just a tube I have that I haven't used in a long time
<usney>thermal paste has a very short shelf life
<butterypancake>Meh. I throw whatever crap I can find in my computers. You do you man. I won't stop you for actually doing the right thing unlike me I guess
<usney>It needs to be changed at least every three years but some can last as long as 8 years.
<butterypancake>15 years. take it or leave it
<usney>it just loses the ability to reduce heat after that
<usney>effectively reduce heat*
<butterypancake>well the cpu tends to lose the ability to keep up with modern stuff anyways after 5 years so maybe I don't notice. Please don't convince me to run around repasting all my electronics every 3 years. You make a convincing argument but ignorance is bliss
<usney>but maybe it is good to not too also because I read if you don't clean it properly it can create even more problems of not reducing heat properly from microtears on the surface of the cpu.
<butterypancake>that sounds like houey. Just 99% alcohol + non-pilling cloth + time and care = perfect thermal job.
<usney>I guess it your computer ever has issues and it is old probably repasting the cpu or gpu would be a good step to try
<usney>yes that is how it is recommended butterypancake
<butterypancake>I would never do a gpu. first off they're cheap. second off they are a bitch to take apart with all their thermal pads and crap
<usney>however I didn't use a cloth I used cotton qtips dipped in rubbing alcohol to clean it off.
<butterypancake>i dunno if cotten qtips leave anything behind or not... I use coffee filters because they are made to not leave any particles behind
<usney>my gpu I think is soldered on the motherboard so I'd have to either buy a new motherboard or desolder and get a new one and resoldered it on.
<usney>but it runs at a very low temperature anyways so I am not concerned about that.
<butterypancake>meh, gpus are so finicky I make sure my laptops just don't have them :P
<usney>even integrated graphics?
<butterypancake>although changing the thermal compound on a laptop gpu is probably not as bad as a dedicated gpu
<butterypancake>well you need graphics so yes i use integrated graphics. mainly I stay away from anything with a dedicated gpu because that usually means you now have 2 gpus and that is a mega pain in linux
<usney>I am not sure if my laptop is capable of a dedicated gpu but I never looked into it but probably one you connect to it from the outside would work though.
<butterypancake>they got fancy thunderbolt docks these days. they look pretty cool
<butterypancake>the docks can contain gpus
<butterypancake>how come guix tells me source my guix profile after I install stuff? is this something I should be doing? isn't it done for me? I'm running guix system btw
<butterypancake>meh, I'll read the manual later. Good night everyone!
<pkill9>sneek later tell butterypancake it's only necessary until you re-login, it just means it didn't detect that environment variable set to that profile, which it won't be if it's a new environment variable that didn't exist before, so guix warns you
<sneek>Okay.
<usney>can you just run pull as regular user only when it is on a foreign distro or do you have to do both root user and regular?
<usney>I just don't want extra files so I can limit the space it takes up.
<ryanprior>running pull as a regular user is fine, no need to run it as root
<usney>cool
<ryanprior>the guix daemon runs as root in any case
<usney>so it will update the guix daemon?
<ryanprior>yes pull will update the daemon and the core guix profile, but not affect other users' guix profiles
<usney>cool
<usney>thank you so much
<usney>guix is great software
<usney>I will be trying it out on arm processor soon
<usney>I'll let everyone know how well it works on arm64
<ryanprior>I saw it work great on Manjuro on the Pinebook Pro.
<usney>yes that is what I am getting lol
<ryanprior>I also have a Pinebook Pro and have yet to install Guix on it but I want to.
<usney>cool
<usney>maybe some day it can run with no proprietary code at least from the OS and have everything work
<usney>is the board's firmware free?
<ryanprior>I'm not sure, but I feel like it would be a bigger deal if it were fully free firmware & people would be blasting that, so I'm guessing it probably requires mainline Linux.
<usney>I might test out jselfs famous baked libre kernels on it
<usney>it shouldn't break it but i can always go back to the old kernel
<lfam>Doing ./pre-inst-env guix build --no-grafts gtk+ is using 6 GB of RAM and climbing for me
<lfam>And it's not actually building yet, just creating the derivation and that early stuff
<lfam>Can anyone else reproduce this on current master?
<lfam>I have a feeling it's caused by my WIP Inkscape upgrade, which changes Inkscape to use GTK+@3 instead of version 2. The problem goes away without that patch
<guix-vits>lfam: if you have many free RAM, then this behavior is rather logical, aren't it (not used RAM is wasted one)?
<lfam>Sure, but it doesn't take 6 GB RAM to do this task
<lfam>It means something is broken
<lfam>It actually passed 8 GB and started swapping
<lfam>I suspect there is a circular dependency between inkscape and GTK or something like that
<guix-vits>lfam: (IDK): if you disable swap? Maybe system is just "stop to distinguish", and happily use swap..
<lfam>No, it was all used by Guix
<guix-vits>lfam: can you share the patch that causes troubles?
<guix-vits>make check on cur-master: "Wide character in warn at /gnu/store/dbqv8adnx51hgj7103lib2lx4q6pfcrm-profile/bin/makeinfo line 656.
<guix-vits>./doc/guix.ru.texi:4013: warning: .' or ,' must follow @xref, not д"
<guix-vits>and "./doc/guix.ru.texi:955: warning: accent command @,' must not be followed by whitespace"
<lfam>The patch: https://paste.debian.net/1145255/
<guix-vits>thanks
<guix-vits>actually, you're also upade python to 3-rd
<apteryx>lfam: yeah, circular dep. I have an uncompleted patch series for inkscape 1.0, that fixes that
<apteryx>would you like me to upload it to guix-patches?
<apteryx>I had started the big task of attempting to unbundle everything, which isn't exactly easy.
<guix-vits>apteryx: Do programs respond "it's just a scratch" upon the every hack?
<lfam>apteryx: Yeah, that would be great! I only just got started
<lfam>apteryx: Do you mean the unbundling the circular dependency graph, or does inkscape bundle stuff?
<apteryx>lfam: I'll try posting it soon, will ping you when it's done
<lfam>Sure apteryx, no rush. I just picked it up for something to do
<lfam>Yeah, python 3 also, guix-vits. But I didn't suspect a cycle with python, because python is already carefully bootstrapped to avoid that sort of problem
<guix-vits>lfam: cool.
<apteryx>sneek later tell lfam the unbundling of deps is an inkscape problem, orthogonal to the circular dependency problem
<sneek>Will do.
*guix-vits guix pack -RR -S /bin=bin wesnoth
*guix-vits "guix pack is RAM-demanding..."
<sasaw>How do you use bash_completion.d in the guix-profile directory?
<sasaw>Does it have variables like MANPATH or INFOPATH?
<sammich>I've made a guix pack of emacs (with -RR) however it doesnt load my init.el, any idea why/how i can make it do this?
<raghavgururajan>Hello Guix!
<sasaw>Can you open init.el in emacs?
<sammich>Yeah
<sasaw>Take a look at what environment variables emacs is running.
***apteryx is now known as Guest182
***apteryx_ is now known as apteryx
<tho1efx><leoprikler "tho1efx: how exactly does the in"> I can try re-running it, I have guix at least mostly installed right now though.
<sammich><sasaw "Take a look at what environment "> Turns out id accidentially made a .emacs file but my config is in .config/emacs so it wasnt getting loaded
<sasaw>oh.
<efraim>rakudo update to 2020.05 put on hold, I can't get zef to not install into its own prefix :/
<olivuser>Hello guix!
<olivuser>So this morning I tried setting my login/session manager to slim. Is it necessary to manually remove (via (remove ...) in services)?
<olivuser>sorry, the remove-question is related to gdm: do I have to manually disable/remove gdm for it to be replaced by slim? Gdm eats just so much more ram...
<olivuser>Also, if I understand correctly, changing the keyboard configuration, the whole configuration form for slim is (service slim-service-type (slim-configuration (xorg-configuration (keyboard-layout ...)))). But when I input (keyboard-layout keyboard-layout) (as is specified in the beginning of the system config), it throws an error, even though it works fine for the bootloader. Why?
<lprndn>Hello guix!
<olivuser>Also, for some reason I cant try sddm. When I place a minimal (service sddm-service-type), it asks whether I have forgotten a use-modules form, even though it is the same for slim and sddm. Why?
<lprndn>oliver: for gdm, yes you have to remove it if you use %desktop-services.
<lprndn>for sddm, the sddm service is defined in gnu/services/sddm.scm so you have to add sddm to the (use-service-modules ...) of your configuration
<lprndn>(slim and gdm *services* are defined in gnu/services/display-managers.scm , I think)
<lprndn>* gnu/packages/xorg.scm, sorry
<lprndn>(indeed slim and sddm *packages* are defined in the same file, but here you need their service definition)
<olivuser>lprndn: thanks!
<lprndn>olivuser: for slim, i'm not sure but I think that now, the prefered way to set the xorg-configuration of a display manager is through set-xorg-xonfiguration (see manual). Hope it helps ;)
<guix-vits>lprndn: "do I have to manually disable/remove gdm?"
<lprndn>guix-vits: yes.
<guix-vits>Thanks, lprndn.
<rekado_>lprndn: re your LightDM service: there are a few things that I’d like to see comments for, e.g. the removal of Python and the addition of the lightdm-disable-python-tests.patch
<lprndn>rekado_: ok! i'll do into that. Anything else? Thanks again for your time.
<rekado_>lprndn: patch 8/10 adds "--disable-indicator-services-command" to the greeter’s configure flags. It would be good to add a comment in the code why this is needed.
<rekado_>in the wonderful documention additions I see ‘lightDM’ and ‘LightDM’; better to be consistent
<rekado_>there’s a missing space after the colon in the documentation of sessions-directory
<rekado_>and for ‘type’ the colon is missing after ‘default’
<rekado_>the documentation for ‘lightdm-gtk-greeter-service-type’ should wrap ‘lightdm-gtk-greeter’ in @code{}
<rekado_>same for ‘ligtdm-gtk-greeter’ (typo!) and ‘lightdm-gtk-greeter-configuration-file’ in the documentation of ‘lightdm-gtk-greeter-configuration’
<rekado_>I could fix up all of these things, but for the comments on the patch and the added configure flag I’d need your help
<rekado_>I’m not a fan of the many spaces in lightdm-seat-configuration->list; I think we could use ‘format’ with a format string that does padding for us.
<rekado_>sometimes there are uses of ‘string-append’ with two string literals. I think it’s better to just use one plain string and break it with an escape when necessary.
<rekado_>I would also remove ,(if (null? extra-config) "" …), because (string-join '() "\n") does the right thing
<lprndn>rekado_: Don't worry, i'll fix up it all! ;) Do you have examples for the format/string escape? I'm not sure to see what you mean. (didn't know for string-join, nice!)
<rekado_>all of this is nothing big and I’d be happy to make these changes myself when applying the patches.
<rekado_>lprndn: format from (ice-9 format) allows you to specify a minimum width and padding characters
<rekado_>(format #f "~5a" 'abc) —> "abc "
<rekado_>re string escape: (string-append "foo" "bar") is equivalent to "foobar". If you’re using string-append only for cosmetic reasons so that you can put ‘foo’ on one line and ‘bar’ on the next you could also write "foo\bar” with a line break after the \
<lprndn>rekado_: ok thanks! I'll do as much as I can (specially for comments). I might leave onething or two if i'm not sure how to deal with it and send a new set of patches. is it ok for you?
<rekado_>thank you so much for working on this.
<lprndn>I'm happy to participate! I learned a lot. also bricewge really was of good advices for the rework of the service.
<raghavgururajan>sneek, later tell bricewge: I have sent new patch-set to #40994, whose first patch also adds new module to local.mk. :-)
<sneek>Will do.
<rekado_>lprndn: the “format” stuff is probably least important. If it turns out to be too much work or if it would make everything look ugly then feel free to ignore it.
<rekado_>civodul: that Build Systems à la Carte paper is really interesting
<rekado_>it never occurred to me that Excel and Make work in similar problem spaces
<rekado_>aborts/suspends for dealing with dynamic dependencies maps to prompts and continuations in Scheme
<rekado_>I wonder if the GWL may need to deal with dynamic dependencies
<leoprikler>GWL needs to deal with UTF-8 filenames.
<leoprikler>dynamic dependencies should be encodable in lisp/wisp
<mbakke>I wonder what Cuirass is struggling with: https://ci.guix.gnu.org/jobset/guix-master
<rekado_>leoprikler: GWL has no problem with UTF-8 filenames AFAIK
<rekado_>leoprikler: the question is if expressing dynamic dependencies would at all be useful in GWL workflows
<leoprikler>well, you get reproducible dynamic workflows ;)
<rekado_>mbakke: I bet it’s the GC lock
<rekado_>it’s currently in the deletion phase
<mbakke>rekado_: it's no longer locking, but there is some contention on the sqlite db lock
<leoprikler>rekado_: also yes, it does. cache.scm hardcodes ISO-8859-1 for hash computation
<leoprikler>if your name is encoded as UTF-8 (as it should be on sane platforms), that will fail
<leoprikler>unless of course you happen to restrict yourself to the set of characters both support, which need not necessarily be
<rekado_>leoprikler: I think this is a misunderstanding
<rekado_>we’re treating the file name as a series of bytes
<leoprikler>perhaps, but that's not what string->bytevector appears to do
<rekado_>yeah, I see that's not behaving as intended
<leoprikler>particularly string->bytevector does an encoding as per the (ice-9 bytevector) module
<leoprikler>* (ice-9 iconv)
<rekado_>strings in Guile are UTF8-encoded anyway, so this should work
<leoprikler>I just looked it up in the manual and that also advocates ->utf8 for such conversions
<leoprikler>kinda weird w.r.t. naming, but okay
<civodul>rekado_: yes, that paper is insightful
<civodul>almost enlightening, but for me the Haskell code tends to get in the way :-/
<civodul>which always saddens me because i feel i'm missing out
<civodul>and yes, abort/suspend reminds us of continuation, though i'm not entirely clear on the difference between Excel and Shake
<civodul>i've pushed an update to the article
<civodul>i'll publish it this afternoon if there are no objections
<mbakke>rekado_: berlin can no longer access guix-x15 and guix-x15b
<rekado_>so … it worked for a few hours?
<mbakke>indeed
*mbakke sets up new tunnels
<mbakke>rekado_: weird, the build nodes can not access them either
<rndd>hi everyone! does anybody tried to run .jar app on guixsd? have some problems
<mbakke>rekado_: nope, I can access them just fine o_O
<mbakke>it's as if the firewall rule has been inverted to block access from all machines
<rekado_>rndd: what problems do you have?
<mbakke>I guess I can tunnel them through one of the external build nodes meanwhile... do you know any with good bandwidth?
<rekado_>I just sent an email to the network support team.
<mbakke>great
<mbakke>rekado_: they are now accessible again :P
<sirmacik>anybody using clojure package? how can I start clj? Can't see such command after installation
***deesix_ is now known as deesix
<sammich>sirmacik: I think guix doesnt install the clj scripts so it might be something like java -cp ~/.guix-profile/share/java/clojure-1.9.0.jar clojure.main
<sirmacik>thanks!
<guix-vits>I'd guix pack -RR -S /bin=bin wesnoth, but ./bin/wesnoth --data-path returns "_/_gnu/...". Can someone reproduce that?
<civodul>guix-vits: and what does that command return normally?
<guix-vits>civodul: i'm expexted it to return "gnu/", but probably i'm not understanded how pack works. Logically it should be as it is, /gnu. I'm sorry for noise.
<str1ngs>guix-vits: what does --data-path do? maybe prints XDG_DATA_DIR?
<guix-vits>str1ngs: it shows where the main game data is stored.
<guix-vits>--config-path shows the "user-data" with add-ons.
<str1ngs>and it outputs "_/_gnu/..." exactly? also what does it output when not using guix pack?
<mmdev>You may be able to use strace to see what the program is doing
<guix-vits>str1ngs: "/gnu/" + path to out/share. It is normal, due to chroot or something alike that used by guix pack -RR. That dir is correct and is inside of tarball.
<str1ngs>guix-vits: I think though in the of -R it uses user-namespaces so paths prefixed with /gnu will still resolve. I guess the main thing is does wesnoth still work with -R?
<guix-vits>all is working
<sirmacik>hm, weridly enough after installing clojure I don't get any java command
<str1ngs>guix-vits: can you paste the complete output of --data-path verbatim please
<guix-vits>"/gnu/store/shiwwqd6p2inpwbmhgzkwkbn7dqgzn6f-wesnoth-1.14.11/share/wesnoth"
<guix-vits>of ./bin/wesnoth --data-path
<str1ngs>guix-vits: ah that's okay as long as your kernel/distro supports user namespaces. then that should still resolve properly. also use -R not -RR . -RR is a last resort
<str1ngs>I'm not sure if -RR uses name spaces then falls back to proot. names spaces are preferred IMHO
<civodul>str1ngs: i'd say always use -RR since it'll use user namespaces if they're available
<civodul>so -RR is the safe way
<civodul>-R saves a tiny bit of space compared to -RR
<sammich>sirmacik: you might need to guix install icedtea, based off of this issue discussion https://issues.guix.gnu.org/issue/32709
<str1ngs>civodul: thanks for clarifying that. I thought that might be the case but I was not sure.
<sirmacik>sammich: it was installed to build clojure package
<sirmacik>I'm now trying with openjdk
<str1ngs>civodul: on a side note, I did abuse guix pack to run guix daemon on server I can not install guix on. and now and again build packages with it. :)
<civodul>str1ngs: ah, i'm interested!
<civodul>how did you do that?
<str1ngs>basically a rootless guix-daemon :)
<civodul>yup, i tried that before but it's inconvenient
<civodul>so i'm happy you managed to get it to work
<civodul>did you fiddle with the env vars and all?
<str1ngs>the trick is a have rootless name space that I run guix-daemon in.
<str1ngs>it's like runc but the binary is custom. when I have more time I plan to try switching to runc so it's more portable for others.
<str1ngs>or replicate it using guile right now the code is in go
<str1ngs>here's the custom namespace code. https://github.com/mrosset/via/blob/master/contain.go#L212 . it's a basically a self "containing" binary
<str1ngs>though I could used guix pack to create the whole container. need to think more on this.
<civodul>ah ok
<civodul>i tried with "guix pack -RR guix" and thought you did something similar
<civodul>the custom code is nice too
<str1ngs>I did not use -RR i just use guix package with var data. and then ran guix inside the rootless container.
<civodul>i'd like us to ship a -RR tarball for some future release, with simple instructions for non-root install
<str1ngs>with out var data it will gc which was funny :)
<civodul>heh :-)
<str1ngs>basically the daemon GC it's self lol
<str1ngs>my custom code is tailored towards via, but I think I can port it to guile. though I might need guix syscall package.
<str1ngs>or instructions with runc might be an interm solution.\
<civodul>it'd be ideal if we just used -RR: no new code to write (or almost)
*civodul publishes https://guix.gnu.org/blog/2020/grafts-continued/
<str1ngs>the draw back with -RR is you can't use package you build. need to think on this.
<civodul>yes, you need a wrapped shell as well
<str1ngs>with via if I invoke via shell. I'm container so its like running guix proper
<str1ngs>contained*
<apteryx>mbakke: is it just me, or php is failing its test suite again on core-updates?
<str1ngs>civodul: what if we had a helper program to populate the root file system and isolate the daemon. this could be used to enter the root filesystem as well. or is this too niche?
<civodul>str1ngs: in the experiment above, you just run ./bin/sh to enter the environment
<apteryx>mbakke: ah, nevermind, this was on a really old commit of core-updates
<mbakke>apteryx: I think something has gone wrong with php when merging the updates from master with the update on core-updates; it fails early because it can't delete a test
<apteryx>mbakke: I've fixed this locally, but then it still fails its test suite :-(
<apteryx>the file that no longer exists is "ext/standard/tests/file/lstat_stat_variation9.phpt"
<mbakke>apteryx: maybe we need to reintroduce 'gd-for-php'
<raghav-gururajan>Hello Guix!
<str1ngs>civodul: I will experiment with this more. for me it's useful for machines I don't have root access too.
<str1ngs>civodul: thanks for the link, I think I can streamline this without the need for via which is not as portable.
<apteryx>raghav-gururajan: o/
<raghav-gururajan>apteryx o/
<mbakke>civodul: do you think these will ever finish, or should we restart cuirass? https://ci.guix.gnu.org/jobset/guix-master
<apteryx>mbakke: core-updates can still be built with just within a 'guix environment guix' environment, correct? Or must I now add guile-3.0?
<raghav-gururajan>apteryx Are you available to review and push #41064 (Twinke)?
<mbakke>apteryx: you can build it with Guile 2.2
<apteryx>raghav-gururajan: my hands are caught in something else at the moment (inkscape 1.0), but I can try to take a look later. Guix lint looks good? Reproducible? No fat directory that should be move to doc/ elsewhere (I like to use du -sh (guix build package)/*) for that
<raghav-gururajan>apteryx Thanks so much! Yes, guix lint is good. Btw, I did not package Twinkle, I just made some tinkering. :-)
<civodul>mbakke: dunno, we can always restart Cuirass...
<apteryx>raghav-gururajan: ah, OK, I thought it was new :-) I've never tried it.
<raghav-gururajan>apteryx: I see. I was comparing it with linphone.
<apteryx>mbakke: sorry, that file is not present in current core-updates, ah. Will investigate.
<apteryx>(I mean, in the current package def on core-updates of php)
<apteryx>arg... was stuck on some other branch still. sorry. :-) I need a coffee.
*apteryx sometimes confuses themselves using git worktrees and then using 'guix-edit' to land at the wrong place ;-)
<dustyweb>hi #guix!
<apteryx>hello!
<dustyweb>the new blogpost is nice
<rekado_>we’re *still* at 2.7T free space on ci.guix.gnu.org
<rekado_>GC has been running since yesterday evening.
<apteryx>civodul: by the way, how did you end up with inkscape 1.0 for your blog post? do you have a local copy?
<rekado_>apteryx: I see both 1.0 and 0.92.4 in the examples
<apteryx>rekado_: how is the file system laid out? is there any smaller part of it that we could experiment migrating to a compressed Btrfs version? If there's no extraneous garbage root, and if 'guix gc' doesn't help much, I don't see another path (buying disks is one but it's slower to go through that path)
<apteryx>alternatively we could try finding really expensive store items and mark these as "non-substitutables", but that's sub-optimal.
<rekado_>yeah, I don’t want to mark anything as non-substitutable
<rekado_>37T ought to be enough with deduplication
<rekado_>but we’re eating it all up very quickly
<rekado_>the external storage appears as one big disk
<rekado_>it’s configured as RAID 6, I think, so we’re losing a bit of storage before the server even sees it.
<rekado_>only /gnu lies on the external storage device
<rekado_>and /var/cache is bind-mounted to /gnu/cache because we ran out of space on the root fs
*guix-vits "io-ho-ho"
<rekado_>apteryx: once we have enough space on ci.guix.gnu.org to feel comfortable we should disable deduplication
<rekado_>this would speed up “guix gc” as it no longer needs to search /gnu/store/.links
<apteryx>rekado_: interesting, but wouldn't turning off deduplication entails a big size increase of the store?
*apteryx is curious as to whether 'guix gc' leaks items over time
<apteryx>rekado_: do you have a good understanding of what Cuirass persists in the store?
<mbakke>so the PULSE_CONFIG and PULSE_CLIENTCONFIG variables appears to be ineffective, despite what https://www.freedesktop.org/wiki/Software/PulseAudio/FAQ/ says
<mbakke>hmm, looks like they should still be read according to the source
<apteryx>rekado_: I'd think core-updates would be pretty expensive to persist, given that commits made against it often retrigger massive rebuilds
<mbakke>maybe pulseaudio does nt inherit the shell environment
<mbakke>apteryx: outside the "freeze" cycles, it only builds a small subset of core-updates
<rekado>apteryx: disabling deduplication would have the upside that we could delete more quickly
<rekado>right now I see that we’re down to 2.7T and it takes more than a day for my clean up efforts to have any effect
<rekado>this means that if we run out of space we may have to be stuck in that state for much longer than we’d like
<rekado>apteryx: I don’t know how cuirass records its roots; I’d have to look at the code
<rekado>but it would be nice, I guess, if cuirass would include the specification name in the name of the roots.
<rekado>so that we could easily purge stuff we deem less valuable
<apteryx>mbakke: interesting. Can you elaborate on what is meant by 'small subset'?
<lprndn>rekado: sent a new set of patches for the lightdm services if you happen to have some more time. :)
*apteryx needs to take a look at the sources of Cuirass
<rekado>apteryx: we have a core subset
<civodul>rekado, apteryx: right, i don't have 1.0, i just edited the examples :-)
<lprndn>I didn't touch the lightdm-seat-configuration->list procedure nor the format thing as I'm not really sure that I understood everything.
<rekado>you can take a look at cuirass/examples/gnu-system.scm
<civodul>apteryx: and i'm glad you're working on it!
<civodul>janneke: with a 24hr delay, i replied to your message re (guix build syscalls)!
<rekado>lprndn: thank you! I’ll try to take a look at it later tonight and merge it.
<janneke>civodul: you're catching up! ;-)
<janneke>i'm amazed at all that you do, no worries
<apteryx>mbakke: e98689f8632 partially fixes php
<apteryx>now only the test suites failures remain
<civodul>janneke: heh, so what's that errno? :-)
<janneke>we caught nothing!
<janneke>:-(
<janneke>pretty much the same error: https://paste.debian.net/1145325/
<janneke>wait...something is not right
<janneke>why does the trace say (test) when we use 'test' as a thunk
<janneke>oh, guile is being smart
<apteryx>rekado: OK, the commit d4623d5 instaured registration of gc roots in Cuirass. It adds a --ttl command line argument that determines how long the GC roots are kept (defaults to 30 days).
<reepca>so I've discovered some interesting behavior: http://paste.debian.net/1145330
<reepca>that produces the following output: http://paste.debian.net/1145331
<raghavgururajan>civodul: Regarding #41083, is my updated patch OK?
<reepca>is a server process gc'ing its own temproots file expected behavior?
<reepca>it happens because readTempRoots thinks that "nonblocking write lock acquisition succeeded" means "temproots file is stale". But of course that's not true when considering its own temproots file.
<apteryx>mbakke: the failures indeed seem related to gd: https://paste.debian.net/1145335/
<apteryx>mbakke: what was special about gd-for-php? I fail to see it.
<apteryx>it seems the current 'gd' uses the same patches as those gd-for-php was using.
<civodul>janneke: and what if you catch #t and print the exception args?
<civodul>reepca: weird!
<civodul>reepca: is it like https://issues.guix.gnu.org/issue/25018 ?
<civodul>reepca: BTW, if you're implementing temp roots, i'm interested in using them on master so we can remove with-store from (guix nar)
<civodul>raghavgururajan: the latest patch looks great, thanks!
<reepca>civodul: aye, that sums it up exactly. Although the patch listed there would introduce another problem, namely that when the fd gets closed it will clobber any read lock it has on its own temproots file. So then it would be seen as stale by every other process.
<reepca>it's nice to see that I'm not the only one struggling to deal with posix locks' design flaws
<civodul>it's terrible
<civodul>it's great you're looking into all this
*janneke boots another hurd
<pkill9>have any interesting things been done with the hurd, apart from creating a chain of translaters from ftp -> filesystem -> iso or something, which is pretty damn sweet :)
<pkill9>and booting guix on it
<janneke>civodul: ...yeah ;;; ("caught args=" (out-of-range #f "Value out of range ~S to ~S: ~S" (0 4294967295 -1) (-1)))
<mbakke>apteryx: just that PHP is very sensitive to the version of gd, and sometimes has custom patches
<apteryx>mbakke: OK. Indeed gd was bumped recently (end of March)
<apteryx>I'll just delete the test files for now... There's still be a zillion tests remaining.
*mbakke sets out to fix the WebKitGTK+ sandbox issue
<g_bor[m]>Hello guix!
<g_bor[m]>janneke: where does that come from?
<g_bor[m]>I have seen in one of the pastes you linked, but I miss the context
<janneke>g_bor[m]: from trying to reproduce the loopback device crash on the hurd
<janneke>g_bor[m]: => https://paste.debian.net/1145341/
<janneke>cross-building (guix build syscalls) or something else...
<g_bor[m]>Oh.
<mbakke>apteryx: can you check which version of gd php bundles? maybe try applying their patches to "our" gd?
<g_bor[m]>Do you know which call fails?
<civodul>janneke: oooh, waiiiit
<civodul>did you see the "FIXME: GNU/Hurd?" comment in there? :-)
<civodul>silly me
<civodul>looks like i started collecting the constants and then got lazy
<janneke>civodul: eh ... no?...
<reepca>I've got a I-think-it-works file-locking interface that *should* work with fibers, which I've used to implement add-temp-root. It comes with quite a few warts currently, though, so I'm debating whether to redesign it. For example, all i/o to ports corresponding to locked files has to be done with pread() and pwrite(), and since custom-binary-ports are implemented in C in guile 2.2 we can't suspend from them, so we have to use special
<reepca>put-bytevector and get-bytevector procedures directly...
<janneke>civodul: doh' :-)
<civodul>janneke: you feel like feeling in the blanks? :-)
<reepca>oh, and speaking of (guix nar), I've noticed a few issues in there. One is that the with-store form should be around the (let loop ...) instead of inside it, as it prevents the loop from being a tail call and opens a new connection for every retry (without closing the old one).
<janneke>civodul: certainly!
<janneke>thanks for actually looking
<reepca>The other is that finalize-store-file doesn't follow the proper store-file-lock-acquiring protocol. It doesn't check for the deletion token and retry when acquiring, and it doesn't write the deletion token or delete the file when releasing.
<sirmacik>did we just get an update to kernel 5.6?
<mbakke>sirmacik: the 'linux-libre' variable still refers to 5.4, but 5.6 is available as 'linux-libre-5.6'
<civodul>reepca: oh, good catch!
<mbakke>the configuration file for 5.6 does not include all the new goodies though, which I believe is why 'linux-libre' is still at 5.4
<civodul>reepca: would you mind sending patches for these two issues, while you're into it?
<mbakke>our trusty kernel maintainer has stated that he no longer wants to maintain the kernel configurations, volunteers needed
<civodul>mbakke: oh
<civodul>looks like there's a handful of people well versed into this
<reepca>civodul: hmm, well the way that I've fixed finalize-store-file locally uses my 784-line (guix store locks) module, which also depends on guile-fibers and quite a few other changes. Would it be better to try getting that ready for merging or to just write some standalone inline code for finalize-store-file?
<mbakke>civodul: I guess we should bring the kernel maintenance issue to guix-devel for visibility
<raghavgururajan>civodul: Thank you!
<civodul>mbakke: definitely
<civodul>reepca: ah ah! both would be great: a short-term fix for that in master, and resuming work on getting the whole branch merged
<civodul>784 lines?
<civodul>i was hoping with-file-lock would be enough
<civodul>also, can we use Fibers in the daemon? the dameon should be single-threaded because it forks
<civodul>i guess we can tell Fibers to use a single thread
<civodul>or we could have a "safe" spawn primitive in C
<raghavgururajan>civodul: I have made a similar patch to fix fhs paths in claws-mail (#41111). If you could push that as well, that would be great. :-)
<reepca>the 784 lines are part of a more general solution for multiplexing process-associated file locks across fibers/threads. Handling reuse of ports, synchronizing opening and closing of ports, etc.
<cyclopsian>Is there any interest in having signalfd/pidfd/timerfd support in shepherd? or would these be too linux-specific?
<mbakke>rekado, civodul: do you think we should restart cuirass? ref https://ci.guix.gnu.org/jobset/guix-master
<janneke>civodul: a lot better! ==> ("caught args=" (system-error "set-network-interface-address" "set-network-interface-address on ~A: ~A" ("lo" "Invalid argument") (1073741846)))
<janneke>...i think
<janneke>hmm, or the flags i found are wrong
<krusnus>Whenever i do "sudo guix system reconfigure" i get the error "guix system: error: exception caught while executing 'eval' on service 'root': Unrecognized keyword: #:file-creation-mask" does anyone know how tofix this?
<mbakke>krusnus: can you file a bug report? multiple people have reported this on IRC, but there is no bug about it.
<mbakke>IIRC from earlier discussions it has to do with an incompatibility between old shepherd and new service definition
<mbakke>we should probably revert the commit, but it would be good to have an issue to refer to
<apteryx>mbakke: I can't see special patching to php's gd that'd fix those tests, but it's hard to track given they don't use a clean git submodule + separate patches for it.
<apteryx>I'm testing a quick fix
<mbakke>apteryx: right :/
*mbakke goes for dinner while waiting for WebKitGTK
<apteryx>Bon appétit!
<bricewge>krusnus Just reboot you'll then use the new shepherd which support this keyword
<sneek>Welcome back bricewge, you have 1 message!
<sneek>bricewge, raghavgururajan says: I have sent new patch-set to #40994, whose first patch also adds new module to local.mk. :-)
<bricewge>sneek later tell raghavgururajan So you managed to tame git rebase interactive?
<sneek>Got it.
<bricewge>seek: botsnack
***langdon_ is now known as langdon
<butterypancake>when packages are installed, should their services also be installed? I installed syncthing, but guix system search syncthing yeilds no results. Has no one created the service?
<sneek>butterypancake, you have 1 message!
<sneek>butterypancake, pkill9 says: it's only necessary until you re-login, it just means it didn't detect that environment variable set to that profile, which it won't be if it's a new environment variable that didn't exist before, so guix warns you
<raghavgururajan>bricewge Nah! I opened new branch just to re-create the first patch.
<sneek>Welcome back raghavgururajan, you have 1 message!
<sneek>raghavgururajan, bricewge says: So you managed to tame git rebase interactive?
<bricewge>raghavgururajan I encourage you to try again some time, this is really useful to edit commits.
<bricewge>Do I keep or revert the switches to url-fetch?
<raghavgururajan>bricewge Yeah, I am gonna practice it.
<raghavgururajan>bricewge I would like to keep url-fetch, to be consistent with other pwmt packages. :-)
<apteryx>mbakke: I pushed a dirty fix as 3b7f3108e0, in the spirit of PHP.
<civodul>janneke: the patch looks good, esp. if the values come from printf
<civodul>as for the EINVAL, could you rpctrace guile?
<janneke>civodul: right!
<janneke> 173<--170(pid209)->iioctl_siocsifaddr ("lo\0\0\0\0\0\0\0\0\0\0\0\0\0\0" "\x02\0\0\0\x7f\0\0\x01\0\0\0\0\0\0\0\0") = 0x40000016 (Invalid argument)
<civodul>hmm
<civodul>PID 209 is pfinet, right?
<janneke>i think it's guile
<janneke>hard to tell, but ps -ef had "ps 210"
<janneke> root 166 5 - 0:01.49 /hurd/pfinet --interface eth0 --address 10.0.2.15 --netmask 255.255.255.0 --gat
<janneke>hmm, that's not what you're looking for; right
<janneke>yeah, pid209 is guile
<jackhill>raghavgururajan: congrats on being accepted for Outreachy!
<jackhill>are there more details about what you plan to work on somewhere? (I guess I could wait for the blog post, but I'm impatient :))
<efraim>I need to figure something out for go and aarch64, it seems to think it's still GOARCH arm and not arm64
<pkill9>hello guix
<raghavgururajan>jackhill: Thank you!
<raghavgururajan>jackhill: I will sending another email outlining that.
<raghavgururajan>*will be
<jackhill>raghavgururajan: cool :)
*mbakke restarts Cuirass hoping that it will fix the stale evaluations at https://ci.guix.gnu.org/jobset/guix-master
<jackhill>mbakke: I'm testing the webkitgtk patch now (thanks!). I too, am waiting on it to build :)
<mbakke>jackhill: great, thanks. I tested a popular video streaming site in Epiphany with those patches and it seemed fine. :-)
<mbakke>'herd stop cuirass' did not actually stop cuirass, hmm
<jackhill>mbakke: great, I optimistic it will good enough to not block the core-updates merge then. I think to improve on sharing the whole store, webkitgtk would have to be taught how to ask Guix for what its closure is.
<mbakke>rekado: Berlin's clock seems to be 10 minutes off.
<jackhill>I'll follow up on the issue once I've finished building/testing.
<jackhill>terpri: ^ it looks like I may not have to fix the webkit bug. At least in the short term :)
<jackhill>thanks for the encuragement last night.
<mbakke>jackhill: indeed, sharing only the closure is requires a more intrusive patch
<efraim>if I try to build an installation image for an arm board do I need to pass it --system=aarch64-linux?
<mbakke>rekado: it looks like Berlin is unable to access any NTP servers (UDP port 123).
<mbakke>efraim: do you mean cross-compiling from x86_64?
<efraim>mbakke: I mean if I run "guix system disk-image -e '(@@ (gnu system install) firefly-rk3399-installation-os)'"
<mbakke>efraim: if you run it on AArch64 --system should be unnecessary
<efraim>mbakke: yeah I think that's what I'm going to do
<mbakke>efraim: in theory you can use --target=aarch64-linux-gnu from an x86_64 machine (on the core-updates branch) :-)
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<civodul>janneke: if i "apt-get install inetutils-tools" and then "rpctrace ifconfig lo 127.0.0.1 up", i get this: https://paste.debian.net/1145401/
<civodul>it looks like in your case we're missing the 1st byte of the 2nd argument
<rekado>mbakke: ah, that’s why the time is off
<rekado>I’m going to ask them to open yet another firewall port … :)
<civodul>:-)
<civodul>rekado is making friends in the IT dept
<NieDzejkob>I'm trying to run an aarch64-linux build on bayfront, it's 1. building everything starting from guile-bootstrap, 2. erroring with "while setting up the build environment: a aarch64-linux' is required to build /gnu/store/lnhrw8cwmb5qpfgldrfzbxcq8v8xskq9-guile-bootstrap-2.0.drv', but I am a x86_64-linux'". A quick look at /etc/guix/machines.scm shows that there *are* aarch64-linux machines it could offload to. What gives?
<rekado>I should gift them eye drops to grease those ever rolling eyeballs.
<NieDzejkob>oh, the command I tried to use is "./pre-inst-env guix build --system=aarch64-linux unicorn", maybe there's something wrong with that
<civodul>NieDzejkob: not related, but the load on that machine is 62, so...
<civodul>cbaines: ↑
<civodul>NieDzejkob: ah, if you look at the bottom of machines.scm, you'll see that it actually returns an empty list
<civodul>that's why
<cbaines>I think the load is mostly related to I/O
<civodul>so i guess it won't be helpful here :-/
<civodul>cbaines: oh?
<janneke>civodul: "great!"
<cbaines>Particularly the red portion of the CPU Basic panel, that's time spent waiting on I/O I think
<cbaines>I remember something about load not just being about the CPU scheduler, I think it takes in to account I/O as well
<civodul>janneke: so prolly our ifreq is kinda wrong, we should debug it natively
<civodul>cbaines: i can see it's all red, but what's causing this?
<janneke>civodul: good; we're /almost/ there
<civodul>hmm there are many qemu processes there
<civodul>janneke: yup!
<cbaines>Looking at iotop, the guix-daemon processes seem to be doing lots of I/O
<cbaines>Then, yeah, the qemu processes
<civodul>which is expected at the end of builds
<civodul>but maybe --max-jobs is too high?
<cbaines>It's 4 at the moment
<civodul>right, should be fine
<civodul>dunno
<cbaines>looking at guix processes, quite a few are Cuirass
<NieDzejkob>huh, I just realized that bayfront is not what runs the CI, and yet there's cuirass running on there. So, is it duplicating what berlin does? What is the goal here? Reproducibility checking?
<cbaines>at least one of the cuirass evaluate processes seems to have escaped
<civodul>NieDzejkob: yes, reproducibility testing mostly (see data.guix.gnu.org)
<civodul>cbaines: escaped?
<lfam>NieDzejkob: Originally, Bayfront was supposed to run the build farm, so we made the effort of setting up Cuirass. But, the hardware was too unreliable, so we set it up as a secondary build farm while building the primary one at Berlin MDC
<sneek>lfam, you have 3 messages!
<sneek>lfam, apteryx says: the unbundling of deps is an inkscape problem, orthogonal to the circular dependency problem
<sneek>lfam, guix-vits says: (apteryx->orc post-above) "The dependencies of inkscape (either boundled or unboundled) are monop****ual matter for the circular dependency problem."
<sneek>lfam, guix-vits says: IDK, though :)
<cbaines>civodul, well, it's not a child of cuirass like the other processes
<cbaines>Cuirass looks to have multiple connections open to the daemon, all building things
<cbaines>Yeah, counting them all, the single cuirass process has 16 connections to the daemon
<rekado>hmm, commit c26146881ac826ec0f1a49d86bfe874be8d355e6 includes a patch that has a dubious justification.
<ik1>Sorry for interrupting guys. Im in the middle of my first installation right now. And I stucked at "building /gnu/store/bla-bla-gcc-7.4.0.drv..." So does it *build* compiler right now? To be honest I thought its gonna be a *binary* installation. How long does it take to build x86-64 system on Core 2 Duo CPU? Where in the GNU Guix Reference Manual I could understand about this (binary vs building from source)? Section 2 says about making
<ik1> Guix in foreign distro and Section 3 has only "Once you’re done, the installer produces an operating system configuration and displays it (see Using the Configuration System). At that point you can hit “OK” and installation will proceed. On success, you can reboot into the new system and enjoy. See After System Installation, for what’s next! " I am aware of the project goals and written software, so you may not lecturing about
<ik1>this. I was not prepared for compiling from source every aspect of the system, thats why I use Arch instead of Gentoo on a notebook (Thinkpad X200). And I wanted to switch to GuixSD. Thanks for replies.
<lfam>ik1: You shouldn't need to build things here
<lfam>ik1: What section of the manual are you following for your installation?
<raghavgururajan>What package provides "ps" command?
<lfam>procps
<lfam>ik1: Or, are you just using the guided installer to install Guix System?
<ik1>3 System Installation > 3.3 USB stick and DVD Installation > 3.5 Guided Graphical Installation
<bav[m]>rekado: the "I prefer the older interface"?
<lfam>ik1: Can you ping <ci.guix.gnu.org>? If you don't have the ping command (not sure if it's available in the installer image), you can try guix download https://ci.guix.gnu.org to test the connection
<lfam>Aha
<rekado>the firewall dose not permit it
<lfam>ik1: In that case, you'll need to test the connection with my second suggestion
<rekado>bav[m]: yes, I think that’s not a good reason to apply a patch that reverts another commit.
<NieDzejkob>I personally like testing my connection with ping 1.1
<lfam>Sure, but that doesn't test the connection the build farm
<ik1>From what I see in the console it has alredy downloaded packages and now it is building gcc.
<bav[m]>rekado: agreed, I don't think that's in good taste.
<lfam>ik1: It's definitely not expected that you'd have to build things. Maybe you can stop it and start it again
<NieDzejkob>ik1: What's in /etc/guix/acl ?
<lfam>ik1: It would be helpful if you could share the exact name of the drv being built. Without the bla-bla shorthand
<NieDzejkob>could it be a graft?
<lfam>ik1: And also, if you could share the drv file itself
<lfam>I suppose, but that should be really quick
<lfam>It shouldn't give a sense of being "stuck" unless something is really wrong with the I/O
<ik1>Guys easy. Im starring on the black screen of installation. Probably I cant answer your questions. The package it tries to build is b1r8ij432dnn2qxm6xkg7kxyz2z6iyjr-gcc-7.4.0.drv
<lfam>ik1: To answer your question about whether or not Guix is a binary distro, it's actually a build-from-source distro with transparent binary substitution. So, Guix decides what must be built, then checks if those things have already been built on the build farm, and "substitutes" them if they have.
<ik1>So should restart installation?
<NieDzejkob>hold on...
<lfam>I don't know what the interface is like in the installer at this point, so I can't offer specific advice about what steps to take
<raghavgururajan>lfam Thanks!
<NieDzejkob>ik1: what architeccture is that?
<NieDzejkob>huh, neither x86 nor x64 give me that hash...
<lfam>NieDzejkob: I have it on x86_64-linux
<NieDzejkob>oh, really? what command did you use?
<lfam>guix build /gnu/store/bla-bla....drv
<lfam>It was already built for me, so I think it's the primary compiler for this system
<lfam>I haven't been building custom compilers
<katco>what's the recommendation for authoring packages with large numbers of configurable features specified at compile-time? compile them all in? multiple packages for each feature?
<NieDzejkob>katco: if there's something particularily, like vim with gtk support, you can split it into a basic and full package
<lfam>katco: In general, we aim to offer fully-featured packages. Sometimes it's convenient to split the built package into multiple "outputs", but that's only really worthwhile if the outputs don't contain store references to each other, or if it's typical to not want certain features
<NieDzejkob>ik1: FYI, there's a shell at alt+f3 and alt+f4, so you can check the output commands while the installer does stuff
<katco>lfam: ok. working on rsyslogd, and its modules explode the graph bringing in inputs like postgresql
<katco>NieDzejkob: that's an example, but more of a binary situation. this package has ~90 options
<mbakke>o_O what's with the 4000 rebuilds on https://ci.guix.gnu.org/jobset/guix-master
<ik1>Ok. Looks like something wrong, alt + F3/F4 doesnt do the job. I will admit defeat and reboot and try again next time. hank you for your time.
<lfam>mbakke: AFAICT, it's mainly updates to SBCL packages?
<lfam>Could that really cause so many rebuilds?
<NieDzejkob>ik1: maybe try with ctrl next time
<mbakke>lfam: not sure, looking at the packages it seems like Cuirass perhaps "forgot" some of its cached failures (i.e. trying to build java stuff on armhf)
<mbakke>they should fail soon enough, for better or worse :P
<katco>lfam: i dunno, the more dependencies i pull into this package, the more uncomfortable i get. multiple entire databases (because those packages don't have split outputs).
<civodul>rekado: looks like the disk space issue hasn't really improved, right?
<civodul>still, i think we should stop running the gc loops because they take the big lock for too long
<civodul>an annoying situation :-/
<NieDzejkob>looks like we need a concurrent GC :P
<civodul>heh :-)
<civodul>the GC is okay if you give it a lot of garbage to deal with at once
<civodul>but it's very inefficient if you ask it to delete just one item
<civodul>well, that's ok on my laptop but not on berlin :-)
<happycorsair>Sorry, why does network-manager-service need wpa-supplicant-service?
<happycorsair>I got no Wi-Fi in my PC, is there a way not to use it?
<lfam>katco: If you can limit it to a single database implementation, that's probably good
<katco>lfam: well, the issue there is that the functionality of rsyslog is to write things out to many different databases/endpoints
<lfam>Oh, I see
<lfam>I think it's okay to depend on multiple databases. Some packages are just really big
<katco>it's just not known at packaging time which of the ins/outs a user would want
<apteryx>lfam: I'm running a last build of (hopefully) succeeding Inkscape 1.0. I managed to clean up some things on the way, so the remaining effort will be to externalize more bundled libraries (there's 3 packages missing to do so).
<apteryx>I should be able to send the patches within the next 2 hours
<katco>what would be ideal is build once with outputs for each of the plug-ins, and then somehow associate inputs with the plug-ins
<katco>i enjoy guix pack so i am sensitive to a package's overall size.
<rekado>civodul: I’m not running a loop any more
<rekado>yesterday I started a GC to give us 7T free space
<rekado>this hadn’t completed an hour ago, so I aborted it and ran “guix gc -C0”
<rekado>when I loop I usually do 100 deletions at once
<mbakke>rekado: deleting unused links to not claim the big GC lock though, not sure why C0 takes so much time
<rekado>this usually results in errors because I include items that are not dead, so we end up deleting without running the expensive links phase
*mbakke really does not want to restart 4202 timed out builds
<rekado>the previous GC invalidated a lot of stuff: “deleted or invalidated more than 4_701_737_623_552 bytes”
<rekado>so we probably have a lot of stuff in /gnu/store/trash right now
<mbakke>oh, the reason why evaluation 13283 has so many build jobs is probably because some items have been GC'd
<rekado>I don’t get it: we have GC roots for the past months
<cbaines>I don't think that can be it. I think Cuirass bases what derivations to look at only on what outputs it doesn't know about, not what's in the store
<rekado>so /gnu/store/trash currently contains 46757 items
<cbaines>However, there are things that Cuirass is building that don't appear to have changed between those revisions http://data.guix.gnu.org/compare/derivations?base_commit=c5b6a67e5ac2c424e8a912178b0e44d6d0198bb3&target_commit=758f32afdbc6cf6018a2e76eef5085f6b693c15a
<cbaines>I can't see java-biojava-phylo on the Guix Data Service comparison page
<lfam>I wonder if the reason that ik1 was building GCC was that the substituted was GC-ed?
<lfam>s/substituted/substitute
*mbakke pushes a hopefully final merge of master into core-updates
<mbakke>let's make the next merge the other way around :-)
<mbakke>lfam: could be, weird if it wasn't in the nginx binary cache though
<mbakke>I guess most users have it already and never asks for a substitute
<lfam>I'm building the derivation with --check now, to test
<mbakke>lfam: --check will do that
<civodul>mbakke: yay!
<mbakke>use 'guix weather' to check substitute status
<lfam>Okay
<civodul>mbakke, cbaines: i've posted patches for https://issues.guix.gnu.org/issue/41028
<lfam>The tricky part is finding out what package this is
<lfam>Right, it doesn't even exist in the UI
<civodul>rekado: so you're saying it's now taking a day to GC?
<civodul>it used to be that we just wouldn't notice, no?
<civodul>that's terrible
<lfam>guix weather doesn't accept --expression. Is there another way to test it against hidden packages?
<cbaines>lfam, are you trying to look for a single package/output?
<lfam>I'm trying to check if GCC is still available
<lfam>We just had a user who didn't get substitutes for it
<cbaines>If you know the hash /gnu/store/HASH-gcc bit, just go to https://ci.guix.gnu.org/HASH.narinfo
<cbaines>If you get a narinfo file back, it should be available
<lfam>Okay, there are narinfos for both the "out" and lib outputs
<lfam>It's this derivation: /gnu/store/b1r8ij432dnn2qxm6xkg7kxyz2z6iyjr-gcc-7.4.0.drv
<apteryx>lfam: If IIRC 'guix size' can be abused for that purpose
<mbakke>civodul: yaaaay, LGTM :-)
<katco>lfam: re. rsyslogd, how do you feel about moving the module dependencies to native-inputs so that users would have to install packages relevant to the modules they're using? that way, postgres wouldn't come along for the ride if you want to install rsyslog for use with say, kafka.
<cbaines>civodul, indeed, that sounds great :)
<lfam>katco: 'native-inputs' can still be referenced by built packages. It's not determined by the package definition what gets referenced (and thus carried along)
<lfam>That happens after building, when we scan the built package for store references, and register them in a sqlite db
<katco>oh, darn.
<katco>debian seems to have split rsyslog modules out somehow. i'm not familiar with their packaging system.
<civodul>mbakke, cbaines: cool, i'll let us sleep on it and apply tomorrow then!
<civodul>sounds good?
<mbakke>civodul: excellent :-) I think this is the last remaining core-updates blocker
<civodul>yes, so i won't delay it further than that
<civodul>until then...
*civodul -> zZz
<civodul>night!
<mbakke>gn :)
<mbakke>apteryx: looks like you have some competition wrt the Inkscape upgrade (see guix-devel) :-)