IRC channel logs
2024-01-15.log
back to list of logs
<xiews>Hi, my guix pull emits an error: unknown option: cruft. How could I fix it? <xiews>Does it come from git repack? <vagrantc>hrm. where is guile-rsvg getting pulled in? grub-efi configuration? <civodul>vagrantc: yes, for the background image <civodul>xiews: weird, could you paste the complete output? <vagrantc>civodul: is it possible to disable? i don't even think the image displays on the serial console <vagrantc>and ... *how* is it pulling it in ... i did not use base-packages, which is what pulls in guix-icons <civodul>i think it’s the ‘theme’ bit in ‘bootloader-configuration’ <vagrantc>well, hopefully i don't break grub ... or if this does break grub, hopefully guix notices before making it the new generation <xiews>OK, I will try to install guix-minimal <noobly>my last attempt to guix system reconfigure froze during the build phase, where are the logs for this stored? <ulfvonbelow>sneek: later tell refurio: if you look at ~/.guix-profile/etc/profile, you'll see that $GUIX_PROFILE is treated specially if set. This is why the manual and hints always specify to first set GUIX_PROFILE, then source $GUIX_PROFILE/etc/profile <vagrantc>meh. i apparently ... i *still* have not successfully disabled the grub theme <freakingpenguin>noobly: if you know the package that froze you could try guix build --log-file perhaps, /var/log/guix/drvs/something <vagrantc>whew. finally. (bootloader (bootloader-configuration (theme (grub-theme (image #f))) ... no rust <vagrantc>atka: default grub theme requires rust (by way of librsvg) in order to transform the .svg into a .png <vagrantc>and... i am pretty sure i do not need a graphical theme. :) <atka>so if you have a grub theme (by default) you'll be building rust during reconfigure for no other reason than a grub image? <vagrantc>given grub.img is a thing ... figured was worth clarifying <atka>is there a way to track/graph these kinds of dependencies? I long wanted a guix-minimal that would be more akin to alpine. <vagrantc>yeah, since this is not simply a package, not sure guix graph can do the job ... <vagrantc>took me an embarrasing while, with my meagre guile skills ... to track down even where and how to do this <atka>yeah, I gave up on minimal systems with guix, went to the darkside with nixos <vagrantc>guix-icons is also in %base-packages ... so i guess that is what leads to it ... <vagrantc>have to use the bootloader-configuration i mention as well as not use %base-packages ... to avoid having to have rust <atka>good to know, you are building for embedded stuff? <vagrantc>a virtualized aarch64/arm64 machine ... not exactly embedded ... but no graphical console <vagrantc>oh, actually, it's a virtual machine running on a honeycomb lx2 ... <atka>ah, yeah. how's the lx2 these days? decent support? <apteryx>this-package usages in phase gexps doesn't play well with packages using inheritance, right? <vagrantc>atka: haven't tried running guix on it baremetal, although it's used in some guix infrastructure as i understand, so presumably ok. just running debian on the hardware. <atka>if you have your adventures documented somewhere, I'd like to check it out <vagrantc>documentation? what kind of person do you take me for. :/ :) <vagrantc>basically just running debian, but had to add a few boot arguments: arm-smmu.disable_bypass=0 iommu.passthrough=1 <vagrantc>disk. cpu. memory. networking. serial console. Done. <atka>vagrantc: are you working to strip down a base install? less moving parts/dependencies/compiling? <vagrantc>atka: i just knew i didn't want to compile 12 versions of rust just for a boot logo that this system doesn't even see <atka>vagrantc: ok, it'd be nice if we could have a list somewhere with things like this <atka>since they do seem to be timesinks when discovering them <vagrantc>debating weather calling this a bug or not <vagrantc>but yeah, should report it somehow ... guix-help? guix-devel? bug-guix? <vagrantc>that guix-icons is in %base-packages has quite a big dependency chain just even for the bare-bones.tmpl exampel system configuration <apteryx>that's just build time dependencies though[/ <vagrantc>i encountered this with guix system reconfigure ... <ulfvonbelow>while we're on the topic of things that aren't barebones, anything that uses bzr-fetch has a dependency graph that includes sdl, qtbase, gtk, and ffmpeg, and none of them can be rewritten using package-mapping. <vagrantc>didn't the first pass, probably just because substitutes were available back then <apteryx>this-package breaks for inherited packages (refers to parent package) <apteryx>did we have an issue opened for that <atka>vagrantc: thank you for your service o7 <apteryx>rekado: I've got a mail delivery failure to your email, status 5.1.1, diagnostic code smtp; 552 5.1.1 Mailbox delivery failure policy error <noobly>can i limit memory usage when building a package so that it doesn't fail? <atka>not sure, but have you tried to build with zram enabled? <noobly>atka: no, I've never heard of that. <atka>I can build Valve's kernel on my Deck 100% in ram with zram enabled <atka>zram allows you to compress pages and put them back into ram instead of swapping to disk <atka>might help if you need a bit more ram and don't want to back tmp with a disk <atka>not sure what guix default is <atka>check out zram-device-service-type <atka>if that sounds like what you need <noobly>atka: I'll give it a go, so just add zram-device-service-type to my config, in the services definition? <atka>I'd check the manual section on it, but basically yes <atka>you should specify a size <atka>100% of ram if you have 8G or less, ~50% of ram if you have more <atka>but it won't fix everything, like you still probably couldn't compile chromium with 8GB + zram <noobly>atki: i keep getting unbound variable errors when reconfiguring after adding that under services. am i supposed to be adding a module or anything esle? <atka>noobly: use-service-modules may need to have linux in the list <atka>noobly: were you able to build what you needed to build? <efraim>segfault generating the store-database on powerpc-linux :/ <ulfvonbelow>anyone else find that build logs are constantly getting cut off in the middle whenever using offloading? <h4>When doing `man`, it searches on `/gnu/store/3pxdjgx33vsn51yq8b07cci7p77hglqi-wireless-tools-30.pre9/share/man /gnu/store/64jd8xxqdnjpjx271dp78gvgf518c02r-profile/share/man /home/$USER/.guix-profile/share/man /run/current-system/profile/share/man` but not on `/gnu/store/8mya34wpkwplcfbsdwn4mxsmznqa0vzr-profile/share/man /gnu/store/qnngx068fyqiyxxw6f6gdpd62c5i19x3-catgirl-2.2/share/man /gnu/store/zn5ynkzisgzxr0c6838aa6m48hyv2bq6-cat <h4>girl-2.2/share/man` where is the manual of the software I try to read on the `guix shell` <efraim>you need to run 'guix shell foo man-db -- man foo' for 'man foo' to work inside the guix shell <efraim>there's a toss-up between adding man-db automatically to shell invocations so that 'man foo' just works or leaving it out as we have now so extra packages don't get pulled in and suprise people <h4>@efraim Yeah, you right. `guix shell $softWare -- man $softWare` returns nothing but `guix shell man-db $softWare -- man $softWare` returns the actual software. Thanks <efraim>definately a gotcha and tribal knowledge, not sure how to fix either the man-db vs no man-db or the tribal knowledge part <h4>@efraim it's confusing because one is used to add a package only if the environment complains not having it. Here `man` is functional but don't have access to manuals of the environment, it needs to be strapped to environment itself, misleading <efraim>I think man itself comes from %base-packages on Guix System. It would be interesting to change 'guix shell' to create an environment that takes the currently environment and add packages to it, then you'd have the man-db created automatically if it were already available. Although it'd be quite a bit slower to build <h4>@efraim I don't think people would ever learn to import such things naturally if it seems available in the environment. If you want to avoid to surprise people, delete `man` from environment altogether. People will rapidly figure out that they need to import it <h4>Yeah it could be really more natural to create from parent environment. Either that or a truly empty environment that needs to import all basic things <h4>%basic don't make really sense. Like yeah it have what is needed to work. But people wants to control the environment, maybe specify something like %basic in the command if they want a preset, otherwise giving something truly empty for adventurous people <efraim>there's always guix shell --container to start from nothing <h4>And something like %user to import everything already available in parent, making only an idsolated environment <h4>@efraim True, so people wanting nooothing at all can use container, otherwise you should integrate full user environment by default, and create a flag like `--basic` to get container+basic <h4>shell = user environment (with parent man configuration); shell --container=nothing; shell --basic=shell --container --basic=Actual default behaviour (with weird empty man) <h4>Wouldn't confuse normies with coherent default behaviour and adventurous can play with flags <efraim>currently it's not so bad, it adds in new packages unless you pass --container to start from 0 <h4>Even a --user can be made to mimic new default `shell` <h4>From my PoV that default man needs to be corrected. If the package wasn't there I could have figured out, but that state is confusing <efraim>ennoausberlin: armhf or aarch64? <ennoausberlin>aarch64. Its a vmware virtualized debian on m1 processor. But the former rust and openjdk versions are fine <efraim>this is likely partly a problem with jemalloc being compiled for 16k pages and not the 64k pages on apple silicon. the other part is the build infrastructure is catching up after the last large rebuilding merge <ennoausberlin>efraim: I tried to build both openjdk and rust local, because no substitutes were available and it fails after hours at some final step. Both have a LONG build chain of previous version <efraim>rust-1.64 is currently built by the build farm but there's still a ways to go to 1.73. I think on my single board computers I allow ~18 hours per version and about 8GB of ram, but I don't remember if the 8GB of ram is only needed for the first one or not <efraim>also, if you build it with fewer cores it might need less ram <futurile>Q: when a build fails and you --keep-failed, is there some clever invocation to source in the environment-variables with guix-shell? <efraim>can you share the part of teh build log where it fails? <efraim>futurile: there's an environment-variables file in /tmp/guix-build-foo/ that you can source <futurile>efraim: the problem I have is that it wipes out the existing PATH that I have from the shell: guix shell --development gnucash --container --network coreutils vim ; now if I plain ./source environment-variables I lose the PATH for coreutils;vim - I can't figure out how to source it but 'keep existing PATH and add to it' <futurile>I have to do some cut-n-paste that's just a bit annoying <efraim>i'd start with source environment-variables and then add 'guix shell coreutils vim --development gnucash' if you need more packages after that <ennoausberlin>efraim: Until rust 1.72 it builds, but fails for 1.73. Rust needs all the previous rust versions to build the current one :( <apoorv569>if I do `(define f (local-file "path_to_some_file"))` in the `guix repl` <apoorv569>I get ` #<<local-file> file: "path_to_some_file" absolute: #<promise #<procedure 24d2140 at <unknown port>:11:10 ()>> name:"path_to_some_file" recursive?: #f select?: #<procedure true (file stat)>>` <apoorv569>how do I get the value/contents of this file by `f`? <civodul>apoorv569: a “local file” record is meant to be inserted into a gexp, as in #~(… #$(local-file …) …) <civodul>from the outside, you can do: (local-file-absolute-file-name l) <gabber`>apoorv569: you can always make use of Guile's (with-input-from-file) and friends <gabber`>see Guile Reference section 6.12.10.1 <apoorv569>gabber: Yes, but I was wondering if I can, in some home-service-type's extra-content field do `(local-file` so it gets the extra content from a local file? <apoorv569>now I can do `(extra-content (string-append "stuff" "foo" "bar"))` <civodul>apoorv569: yes, ‘extra-content’ here must be a string <apoorv569>but can I do `(extra-content (local-file "path_to_file"))` <apoorv569>civodul: Yes, that's why I asked if I can get contents from a `local-file`.. <civodul>apoorv569: in that case you do not need ‘local-file’ at all: you can read the contents of a file with something like (call-with-input-file "my-file.conf" get-string-all) <civodul>(these two procedures are documented in the Guile manual, not in Guix) <h4>Modifying `(operating-system <h4> (crypt` deletes the user or only modify its password like `passwd` would do? <h4>I was a founder for a time? Neat <jpoiret>for multiline pastes please use paste.debian.net <h4>jpoiret: If founders are dead, then yeah, being one of them should be one of mute time <efraim>h4: it only sets the initial password when the user is created <h4>Modifying `(operating-system (users (cons (user-account (password (crypt` deletes the user or only modify its password like `passwd` would do? <h4>It's less spammy that way <h4>efraim: So those lines are kind of useless upon re compilation. I hoped it was like Nix where every modification was aknowledged and applied, smartly <h4>Like if my drive is now sdb instead of sda, it rebuilds fstab accordingly. And if the password changes, then the shadow line is modified like <gabber`>h4: so a reconfiguration would overwrite a user's password - even after they set their own? <h4>gabber`: Exactly, otherwise password wouldn't be explicitely defined in the configuration file <h4>Or maybe two different options for forced password and initial password <h4>Where I would personally use forced password for my usecase <jpoiret>I don't think we have an option for forced passwords <h4>jpoiret: It's reaaaally conter intuitive. I use a configuration file to have a static configuration at least on what is explicitely stated. If it's a one time use, maybe a simple command would be more relevant than an eternal writing on a file I re compile each time <h4>How does it figures if it has to apply that initial password? Like it checks if the user exist and if yes does nothing, if not, create it with stated password? <h4>It's a nice behaviour for initial password, but the option should be named as such and forced password should be implemented aswell <civodul>ACTION reconfigured berlin with updated Cuirass <apoorv569>civodul: Hey is get-string-all a procedure? where is it from? <gabber`>apoorv569: have a look at Guile Manual's section 6.12.4 ;) <civodul>you can get it from (ice-9 textual-ports) <ulfvonbelow>h4: it looks like the answers can be found in (gnu build accounts). passwd->shadow's docstring in particular may be of interest <h4>ulfvonbelow: Have to take a look... <ulfvonbelow>that's ~/.config/guix/current/share/guile/site/3.0/gnu/build/accounts.scm if you don't have a separate checkout <ulfvonbelow>if you want to add/rename any fields in the <user-account> record type, the place to do that would be (gnu system accounts) <apoorv569>I get error when I run `guix home -L ~/repos/guix-config container ~/repos/guix-config/apoorv/home/environment.scm --verbosity=3` <apoorv569>`guix home: error: failed to load '/home/apoorv/repos/guix-config/apoorv/home/environment.scm': No such file or directory` <gabber`>apoorv569: does the file exist under the stated location? <apoorv569>I have have imported `(ice-9 textual-ports)` <apoorv569>yes, I autocompleted that path, as I have geiser running and it shows completions.. <gabber`>i mean, does this path: '/home/apoorv/repos/guix-config/apoorv/home/environment.scm' exist? <gabber`>i wouldn't rely on auto-completion to know what context $(guix home reconfigure) uses <gabber`>an absolute path probably fixes your issue <apoorv569>Yes, ofcourse its the same command I run to test the (string-append thing I was doing before <apoorv569>perhaps `(call-with-input-file` needs absolute path? <apoorv569>but what if I clone this repo somewhere else? I can really hard-code this.. <apoorv569>the `files` directory will always be in same place though <apoorv569>Yes, absolute path works, `(call-with-input-file "/home/apoorv/repos/guix-config/apoorv/home/files/configs/ncmpcpp/config" get-string-all))))` <apoorv569>but I don't want to hard-code a path that might change on other systems.. <rekado>apteryx: yes, zoho blocked my account because they reset my mailbox size limit from 50G to 5G… <rekado>I’m waiting for their support team to acknowledge this <rekado>in the meantime all email goes to /dev/null <rekado>apoorv569: you can use (current-filename) <apoorv569>rekado: You mean like this? (call-with-input-file (string-append (current-filename) "/files/configs/ncmpcpp/config") get-string-all) <apoorv569>this is wrong BTW, this will return, `/home/apoorv/repos/guix-config/apoorv/home/environment.scm/files/config ..` <rekado>well then change it to the correct relative location and use canonicalize-path <apoorv569>Hmm.. I can use `(dirname (current-filename))` I think. <apoorv569>`(call-with-input-file (string-append (dirname (current-filename)) "/files/configs/ncmpcpp/config") get-string-all)` throws different error now, <apoorv569>ice-9/eval.scm:159:9: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f <rekado>you can use “../” just fine, as often as needed if the file is in fact relative to the current location <apoorv569>rekado: Yes, thats what I have been doing so far with (local-file... but I think (call-with-input-file needs an absolute path. <rekado>apoorv569: if you need an absolute file name use canonicalize-path <apoorv569>rekado: Like this, (call-with-input-file (canonicalize-path "/files/configs/ncmpcpp/config") get-string-all) <apoorv569>in the repl, `scheme@(guix-user)> (define f (call-with-input-file (canonicalize-path ".vimrc") get-string-all))` <apoorv569>`scheme@(guix-user)> (string? f)` says `$2 = #t` <apoorv569>`scheme@(guix-user)> f` prints the whole file <rekado>combine with string-append and (current-filename) <rekado>canonicalize-path only turns a meandering path into an absolute file name <apoorv569>From a script test.scm this works (call-with-input-file (string-append (dirname (canonicalize-path (current-filename))) "/.vimrc") get-string-all) <apoorv569>guix home throws this error, In procedure canonicalize-path: Wrong type argument in position 1 (expecting string): #f <apoorv569>tried `(format` instead of (string-append same error <apoorv569>moved this script to /home/apoorv/repos/guix-config/apoorv/home where the (current-filename) is, <apoorv569>(display (call-with-input-file (string-append (dirname (canonicalize-path (current-filename))) "/files/configs/ncmpcpp/config") get-string-all)) <rekado>> Expands to the current filename: the filename that the ‘(current-filename)’ form appears in. Expands to ‘#f’ if this information is unavailable. <darosior>Hey all, came across the recent merge of the rust-team branch with the new cross-compilation feature. That's awesome! I wonder if it can help target a specific version of glibc to link against? Or, better yet, musl? <efraim>/gnu/store/vr4xpibpr8ck43qyx1w52vskw9wfy9w3-rust-1.54.0/bin/.rustc-real: ELF 64-bit LSB pie executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), dynamically linked, interpreter /gnu/store/r6gm2il1kkyyb6k1881lwilcij2kmbcq-glibc-2.35/lib/ld64.so.2, for GNU/Linux 2.6.32, stripped <efraim>have to build out the rest of the chain but that's rust-bootstrap for ppc64le <civodul>peanuts: (setlocale LC_ALL "en_US.utf8") :-) <efraim>yay rust-1.55 built on ppc64le without any adjustments needed <efraim>`build phase was just under 20 minutes <futurile>does the reference manual get built somewhere - so is there a 'development' version of the manual - that's different from the one on th eGuix site? <qeqpep>only on flaky connections. Just pulled guix myself <futurile>qeqpep: ah brilliant - that's the link I was looking for - thank-you <qeqpep>my .guix-profile is removing packages randomly, breaks on guix gc. Can I fix it by just removing and reinstalling with a manifest? <gabber`>qeqpep: WDYM "removing packages randomly" ? <gabber`>what *exactly* do you do, what gets missing where, etc? <qeqpep>I installed guile-gnutls, but it removed direnv, xrandr, ... for some reason as well <qeqpep>and after gc it can't find libgcc_so.1 <gabber`>qeqpep: how did you install guile-gnutls? are you using `guix home` or did you do a $(guix package -i guile-gnutls)? <qeqpep>I use rde. Thought it doesn't touch guix-profile <futurile>qeqpep: --list-generations doesn't show anything interesting - like when those packages were removed? <qeqpep>There was some weird generation switching involved. Generation 74 and 76 have same time of creation, one that's before Gen73, and different changelogs. <qeqpep>the other issue was me using rust from nix P_P <futurile>civodul: I can whip up the text - happy to do so <civodul>the “hardest” part is collecting Guix-related talks for this year <futurile>civodul: OK - I'll look through FOSSDEM and email the lists so people can say any talks they are going to <efraim>I've spent a bunch of time staring at diffoscope outputs and micro-benchmarks <devmsv_web>How can I link nscd-congituration from store to /etc/nscd.conf programatically? <freakingpenguin>Is there an order defined for list of channels output by guix describe? A couple files I track after reconfigures swapped channel order and I'm not certain why. <PotentialUser-31>Is anyone able to use evdi module in guix? my reconfigure is failing. Not sure if there are any tricks to get display dock's working <makx>thank f*** to the person who re-added guix to nixos; this way i can try and build a rockpro image without too much faff <freakingpenguin>Is it possible to get the default value for a record field without creating that record and using a getter? <jpoiret>freakingpenguin: even using hacks I'm not sure that's doable <freakingpenguin>jpoiret: Gotcha, thanks. Yeah I'm doing some funky stuff in my configuration in my quest to make my code pretty. <sgibb>Hello, I am having problems sending a follow up patch series to guix. I tried `git send-email ... --to ISSUE_NUMBER@debbugs.gnu.org` but got "Mail delivery failed: returning message to sender; The following addresses failed: 67299@debbugs.gnu.org". The initial patch to guix-patches@debbugs.gnu.org worked flawless. Do I need some additional headers? <civodul>so, we have one ‘julia’ process with 25 GB resident <civodul>it’s building julia-reversediff-1.14.4 <civodul>we lost ~10% when ‘mesa-updates’ was merged, which i thought was due to the JDK time trap <noobly>is it normal for 'waiting for locks or build slots...' to take forever? doing a guix pull right now after updating my channels <civodul>noobly: this happens when several ‘guix’ commands are requesting the same build <civodul>one of them “wins” the other(s) just wait <noobly>civodul: ah, thanks. Found the other one. Am I safe to kill the one that's just waiting? <podiki>civodul: I think the coverage loss is mostly on e.g. aarch64 and powerpc64le no? bordeaux usually does much better there than berlin, but i never saw a QA page for mesa-updates this round <podiki>might want to check with efraim, I think last I heard aarch64 had about a week to go for rust, but that was...a week ago now? <podiki>so i'm not aware of any actual breaking ( efraim fixed a curl issue that cropped up on the update back then) but just builds being slow or "missing derivation" at the time <podiki>i think jdk was actually okay, at least on x86_64, probably built before timebomb. but maybe hit the other archs <civodul>at the time of merge, jdk was no longer ok on x86_64, which is why we rushed to fix it <civodul>but maybe some other thing caused a rebuild? <podiki>the rebuilds from mesa-updates were: xorgproto (this one hit basically all through python), curl, mesa <podiki>the libx11 ungraft last time and xorgproto this most recent were the big ones <podiki>unfortunately it is via python:tk that brings in xorg stuff and the answer i got on guix-devel was that it can't be easily separated <jpoiret>upstream has some faulty patches in mater, that combined with some guix quirks took me a long time <jpoiret>note to self (but also everyone): if you use `-K` and hack in the resulting directory, make sure you always remove it before retrying, otherwise once the build directory is moved out of the chroot it's renamed to /tmp/xxxxxx-1 but it still refers to /tmp/xxxxxx-0 everywhere inside because that's what it's named in the chroot <jpoiret>I was wondering why my patch wasn't working, but everything was still linking back to the first failed build :( <civodul>ACTION is hypnotized by the SWH badges <podiki>who doesn't like a nice badge :) <civodul>jpoiret: ah yes, the .drv-1 etc. thing is a trap! <jpoiret>a nice improvement would be to be able to see the whole tree of dependencies and whether they're also archived! <jpoiret>I guess I have to send a bug report for GHC master even though we're far from being able to build it :) <noobly>I'm having trouble getting a wireless connection up. I have my wpa_supplicant.conf, and after setting 'ifconfig wlp3s0 up', run 'wpa_supplicant -c /etc/wpa_supplicant.conf -i wlp3s0 -B'. But I get a bunch of 'nl80211: kernel reports: Match already configured' as output, and no connection. Some research lead me to believe this implies I have another network service running, but I'm not sure how to proceed here being that Guix uses <noobly>shepherd, the similar threads I found online weren't quite a drop in solution <jpoiret>noobly: do you use networkmanager? do you have %desktop-services in your config? <noobly>jpoiret: Yes, I use desktop-services and have Network Manager under /etc. <jpoiret>then it's probably interfering with your manual wpa_supplicant usage <jpoiret>you should use nmcli instead (or nmtui or nm-applet...) <noobly>jpoiret: ok, I'll look into that. The manual suggested wpa_supplicant so I was trying that <noobly>how do i stop network manager from interfering? <jpoiret>you can remove network manager from your config <jpoiret>is there any specific reason you want to avoid NM? apart from corner cases it works quite well <noobly>jpoiret: I've just never used it, and setting up wpa_supplicant is really easy (provided there isn't another service messing it up like right now) <jpoiret>alright! you can stop them in the meantime with `herd stop NetworkManager wpa-supplicant` <jpoiret>but you'll probably want to modify your config long term to 1) remove them or 2) just use %base-services instead <noobly>so in other words, remove 'networking' from my use-service-modules list? or desktop? I don't explicitly name network manager in my config <jpoiret>it's included in %desktop-services, you'll need (modify-services ...) to modify it <jpoiret>you can look it up in "(guix) Using the Configuration System" <civodul>so guix.gnu.org is not being updated since Dec. 13th <jpoiret>okay, let's see how close we can get to gnome now :) <rekado>re openjdk: versions 12 and above have not been patched yet <noobly>jpoiret: nmcli worked like a charm, thanks for the recommendation. <jpoiret>if you do end up using a graphical environment, nm-applet is really nice too <jpoiret>I can't remember the last time I used wpa_supplicant :) <jpoiret>well, at least used it manually (NM uses it under the hood) <freakingpenguin>Sanity checking, guix deploy doesn't support only deploying to /some/ of the machines in the provided list if one is down, right? --keep-going isn't it. <jpoiret>huh, `guix environment` is past its expiration date <jpoiret>maybe we can finally switch wayland? to #t too now? also get rid of the old swap syntax? <mange>freakingpenguin: I don't know of a way to limit what guix deploy tries to deploy to. I usually just comment out the machines in the list when I want to deploy to a subset. It doesn't look like it would be too hard to patch guix deploy to add something like that, though. <freakingpenguin>mange: Gotcha, maybe I'll take a shot at that sometime if nobody else gets to it first. Thanks. <jpoiret>ah, I was a tad too happy, I forgot gtk+ 2 doesn't build :(