<nckx>If you ever find out the cause, let me know. <nckx>I won't do anything, I'm just morbidly curious. *lilyp claims another prisoner in the pungeon. <lilyp>KarlJoad: jokes aside, there are two possible scenarios I can think of <lilyp>1. straight.el tries to write to read-only memory (haven't we all tried at some point?) <lilyp>2. You're not installing the latest commit; the release is not useful enough <nckx>cybersyn: I don't have an answer to your mail, but thank you for sharing your story. :) <KE0VVT>guix home: error: canonicalize-path: No such file or directory: "/home/caleb/Projects/guix-config/guix-config/.bash_logout" <KarlJoad>lilyp: straight.el is working fine. Package seems to start. But, it errors out on `guix-state-directory` because that variable is void. <KarlJoad>In fact, it does not even appear to be available in the environment, because I cannot introspect it with C-h v. <lilyp>Okay, I think I know the issue now <lilyp>guix-emacs has a Scheme part, which straight.el can not handle <lilyp>so yeah, use a better package manager, preferably Guix :) <KarlJoad>Hmmm... Why would straight not handle that correctly? It handles org-roam properly. <jackhill>ugh, I'd like to update java-log4j-core to 2.15.0 because of CVE-2021-44228 but that introduces a new depedency of java-jansi which introduces a loop ::sigh:: <lilyp>Packaging Java seems to be a fun rollercoaster <lilyp>Well, you have a big loop at the start and then all the smaller loops <jackhill>so, if I wanted to post more about what I've found to and ask for advice, would I do it on the bug tracker, guix-devel@ or ??? <lilyp>sure, after riding it for a while you may want to start vomiting, but that's part of the experience <raghavgururajan>nckx: Since `guix time-machine --commit=f3b64ad54ed7067094d752921f85341cdc0722fe -- build gajim` worked on my machine, I'll try to bisect. <lilyp>if you have a wip patch you might want to send that, otherwise guix-devel <jackhill>ok, nope all I have so far is something that will cause Guix to eat all your memory <lilyp>KarlJoad: how is org-roam a benchmark? <nckx>raghavgururajan: Bisection only makes sense for reproducible failures (the result of bisecting transient failures is simply random). But if failure/success are reproducible on your machine, great! <nckx>jackhill: We already have that package, it's called Chromium. <nckx>Sorry for the duplicated effort. <jackhill>I can always count on #guix to brighten my spirits when facing a frustrating situtation <KE0VVT>Mom: "Is your laptop OK?" Me: "Yeah, installing updates." <nckx>My partner always looks at me funny when the fan goes into Harrier jet^W^W -j8 mode. <nckx>‘Is that nor—’ ‘yes, yes it is’. <Aurora_v_kosmose>My laptop has unadjustable curves. So it doesn't spin up until much later than I'd have set it myself, as it kicks in just late-enough to throttle a bit. <nckx>Since I got corebooted, so does mine ☹ <KE0VVT>Not sure how to enter emoji into Terminal. <Aurora_v_kosmose>If it started like... 15 degrees sooner, it'd start accelerating before it reaches the point the CPU starts thermal throttling. <Aurora_v_kosmose>It's not a problem for longer-running high-usage, but for bursts it's annoying. <KE0VVT>I hope Telegram Desktop is in this update. <KE0VVT>nckx: Telegram broke old clients. <KE0VVT>Sucks that the only Yiddish learning community is on Discord. <nckx>All branches here have 2.5.9 but not all my checkouts might be up-to-date. <lilyp>you mean go, the language or any particular package written in it? <lilyp>nckx: I sent a WIP patch to update it to 3.2.5, meanwhile 3.3.0 was released <lilyp>It had a really ugly workaround for fenv and didn't link, hopefully things get easier with the bump <nckx>I don't have a Telegram myself btw. <KE0VVT>Telegram works with new updates. <lilyp>something something dlopen not found 🤷 <lilyp>KE0VVT: Do you have a patch or do you just --with-latest? <KE0VVT>lilyp: I just updated my installed packages from guix. <lilyp>what's your telegram version? <lilyp>doesn't it spam you at all about soon no longer being supported? <KarlJoad>lilyp: It isn't. It was just another package that has work to do before being usable, namely compiling the emacsql program. <lilyp>Can't wait for c-u-f to hit master with GNOME 42 :) <GNUtoo>roptat: the html and guix compile fine but I've not been able yet to build a vm of the template itself due to other unrelated issues like some pdf reader that doesn't compile <GNUtoo>About 42 I wonder if it was done on purpose somehow: <GNUtoo>ENOMSG 42 No message of desired type <GNUtoo>So that computer was probably running some posix-like OS <Aurora_v_kosmose>Regarding guix-publish. If a package is missing locally, will it fetch it for the client? <nckx>I think a separate proxy is better suited to that. <Aurora_v_kosmose>nckx: I'd kinda want the option, because some http->https proxy with no awareness of Guix features would be less smart about what it does and doesn't keep. <Aurora_v_kosmose>For example, a successful transfer from a given Guix address is content-addressed. There's no need to ever hit up the source again for that hash if the transfer didn't fail. <Aurora_v_kosmose>Which is impossible with Guix, as if it changed it wouldn't have the same hash anymore. <nckx>I'd say your proxy is misconfigured if it does that. <nckx>I actually did think of a thing that's annoying (and not due to simple operator error): synchronising cached nars & narinfos. <Aurora_v_kosmose>I also haven't managed to figure out how to get it to convert LAN http requests to query upstream via HTTPS <nckx>I don't think it's possible to do it right with a generic HTTP proxy. <nckx>Well, this is all very Squid-specific, I can't help you with that I'm afraid. <nckx>Anyway, that could be solved by a Guix-aware proxy that would arguably be better for being a separate piece of software from guix publish. Not that I drafted it out ☺ <nckx>Making guix publish do this without making trust transitive seems *hard*. <nckx>But maybe you want that. Anyway, yay, my build finished, back to work. <Aurora_v_kosmose>nckx: Basically the idea is that I trust the cache to fetch from Guix's servers & CI properly, but I don't necessarily trust the nodes querying the cache, so I giving them build offloading ability to effectively achieve the same effect is not an option, because there seems to be no way to restrict what you allow building if you allow offloads. <nckx>That's certainly correct. <Aurora_v_kosmose>The reason for using a cache is both limiting my impact on Guix servers... and my ISP being up to weird shenanigans that lead to an unstable connection. <nckx>Aurora_v_kosmose: I use & recommend nginx for that. <podiki[m]>anyone here use guix containers? any tips for exposing (or not) /tmp? <opalvaults>Anybody know how I can get sof-firmware added to guix? I'm new to this kind of packaging, thread here: <opalvaults>If anyone has any pointers for how I would go about getting this to work correctly in guix I'm down to try to get this firmware added for everyone out there with a newer thinkpad <KarlJoad>lilyp: Using your suggestion, I narrowed my issue down to 2 things. 1) When using straight, guix-mode cannot find guix-scheme-directory. 2) Prepending my configuration path to the load-path list causes everything to break. <raghavgururajan>nckx: Last known good commit is e5e307b6768088e35be0c7526f25a3e16d93c242. Right after that it fails. <opalvaults>Aurora_v_kosmose: is this the file to be run with guix build? <Aurora_v_kosmose>opalvaults: That file contains a number of definitions. Each define-public block is an individual firmware definition that can be called with guix build $name <Aurora_v_kosmose>It seems that firmware differs from other packages mainly by a different end-destination added in the latter build step. <opalvaults>Aurora_v_kosmose: okay cool. I found a packaging tutorial on the guix website cookbook thing. I guess i'll try to follow along to that <Aurora_v_kosmose>opalvaults: Good luck and don't hesitate to ask folks here if you find something confusing. <ns12>Question: how long does it take for a binary to be available for download from the official Substitutes server? <vagrantc>pretty package specific, some packages take a few minutes, some hours <ns12>vagrantc: I am using an x86_64-linux computer. I tried to install youtube-dl, but it is apparently not yet available as a substitute. The build status says "Scheduled". <vagrantc>it is pretty variable, though ... also depends on how many dependencies are being built in order to build the package itself <vagrantc>you can have a package be built because it's source or packaging changed, or any package that it depends on recursively ... so you could have 0 packages that need to be built first, or hundreds ... <vagrantc>the version alone also may not be specific enough; there are plausibly multiple builds of a given version <vagrantc>so it depends on if your current pulled version of guix is sufficiently similar to what was built on the build farm <kwjc>y'all hear about the log4j vulnerability? <ns12>vagrantc: Okay. I have now successfully installed youtube-dl by using the substitutes, whereas I had to build from source yesterday. Apparently, youtube-dl became available as a substitute sometime in the last ~10 hours. <ns12>Thanks for the explanation. <vagrantc>between 11 and 5 hours, depending on which branch you're using <vagrantc>ns12: happy to explain, hopefully i got it right :) <vagrantc>it's definitely surprising sometimes exactly what needs to be rebuilt based on some changes <ns12>vagrantc: I was definitely surprised by the large amount of rust packages that youtube-dl depends on. <ns12>I was using a low-spec computer, and rust-cargo-c took too long to build, so I gave up yesterday. <ns12>kwjc: Ah yes. Thanks. I didn't know about that command. <KarlJoad>What should I know before switching from NixOS to Guix System? <opalvaults>KarlJoad: definitely take a look at the hardware considerations in the reference manual <opalvaults>Otherwise, it's a fairly similar experience. It's probably not as polished as NixOS but it's certainly imo more fun. Aside from hardware, GUIX has tons of software packaged for it. Also, check the core-updates-frozen repo on the guix git repo if you find that a version of software you're using is a bit older (Gnome for example). <KarlJoad>With all the weird hardware I run, that support would be my biggest concern. <opalvaults>you can do a guix pull --branch=core-updates-frozen --allow-downgrade (or something like that) and grab software that's still not in stable. <KarlJoad>I would like to stay away from GNOME if I can. I am not a fan of it or its UI. <vivien>There’s no "stable" branch in guix, the difference between core-updates-frozen and master is that master does not accept udpates that make a lot of rebuilds. ***aya is now known as gyara
<ArneBab>KE0VVT: how noweb is included depends on the option you give for the :noweb header. <ArneBab>KE0VVT: my usual setting is :noweb no-export — that shows the macros instead of the finished code. <vivien>civodul, when I run "herd restart networking", I get "Throw to key `%exception' with args `("#<&netlink-response-error errno: 17>")'." <florhizome[m]><ns12> "Add it to the Guix wish list..." <- How? via the git repo or register somewhere? <f1refly>hello, i'm trying to set up guix on luks and lvm (in the luks volume). grub asks me for my password, for the right partition according to the uuid. but when i enter my password and press enter, it tells me "access denied. no such cryptdisk found." and then it tells me that it couldn't find "disk 'lvmid/XXXX..XXX" (which really does not exist, according to lvshow) <jpoiret>f1refly: are you using crypsetup to manually format the luks partition? <jpoiret>if so, please make sure to use luks1 for now <jpoiret>i wouldn't suggest using LVM if you use btrfs as well, take a look at the subvolumes feature <f1refly>jpoiret: normally i'd agree with you, but i use it for legacy reasons <jpoiret>do you have a different keyboard layout? <jpoiret>the keyboard layout when typing the luks passphrase is qwerty iiuc <f1refly>i normally use neo2, so "de" "neo", but i set it to just "de" until things are running <f1refly>I don't think I have any y or z in my passphrase, but i'll try to add a slot with a one letter pass <jpoiret>yes, but i don't think that the right keyboard layout is loaded until the cryptodisk is opened <f1refly>that might be useful for testing that <jpoiret>but I can help you with it if it doesn't at all <jpoiret>f1refly: if it happens again, do you think you could have irc open while in the grub rescue shell? <f1refly>i'll start the install when i'm done cleaning the bathroom <jpoiret>that should be okay, i'll go eat soon-ish but i'll be back afterwards <florhizome[m]>Somehow somewhat the second tuple in my list just gets appended to the plain-file function that consttucts the file of the first one <florhizome[m]>(quasiquote ("Firstfilename" ,(plain-file "firstfilenamethatdoesntmatter" "firstfileinput"))) <florhizome[m]>and then i get an Error where the second Part ends Up in the references field of plain-file that is optional afaik <f1refly>jpoiret: i rebooted, entered the new three-letter passphrase i set and it worked! <f1refly>it didn't find my logical volume group tho :/ <jpoiret>florhizome[m]: wouldn't it rather be (quasiquote ("xxx" (unquote variable-for-second-file)))? <f1refly>i'm in an emergency guile prompt now <jpoiret>oh, so the early initrd wasn't able to find it? <jpoiret>you forgot to add (dependencies mapped-devices) for both of your file systems <f1refly>that explains a lot, I must've missed it while reading the docs <f1refly>since i already ran guix system init, is there a way on guix to tell it to just re-apply the config.scm to the system on /mnt without installing everything all over again with init? <f1refly>(I don't think I'm there yet in the manual) <befalou>hey guix, in which package is the 'ldd' command included? <jpoiret>when testing my grub patches with `guix system init` I have to copy everything to /mnt again <jpoiret>although I don't think the store is copied if you use the cow-store service, but i'm not sure <f1refly>unfortunate, but hopefully this'll be the last time anyways <jpoiret>once you boot into the system you can just reconfigure <f1refly>yes, hopefully I won't have to alter the system definition from outside again <bricewge>Do we have a common pattern to assure a service state file (log, db, ...) is actually own by the running service UID and GID? <bricewge>Once again I got hit be a service not starting (postgresql) because a missmatch between UID and username <bricewge>in it's state files : /var/log/postgresql/pg_ctl.log, /var/lib/postgresql/data/PG_VERSION and probably other <jpoiret>looking at the .scm, all files should have the proper permissions <jpoiret>see postgresql-activation in gnu/services/databases.scm <jpoiret>you could try rebooting to make sure the activation script is really run <jpoiret>although it should also be run when reconfiguring the system, so it should already be ok <bricewge>jpoiret: Non not all the file have the proper permission, since the activation only modify the right for the directories <bricewge>I have fixed /var/log/postgresql/pg_ctl.log manualy <jpoiret>i assume that this is because the uids of postgresql have changed, right? <jpoiret>i think this is not the only place where this problem would crop up <bricewge>Yes, I configure postgresql, removed it form my configuration, added another service, then reconfigured my system again with postgresql <bricewge>Yes this issue is present in most services <jpoiret>i think this would benefit from having a generic `(ensure-directory-for-user "/abc/def/" user)`, maybe with optional rights <bricewge>That's why I asked if we have general pattern to handle this issue now, but I can't find it in any other service <jpoiret>I haven't looked much at non-desktop services in guix, but i don't think i've seen anything of the sort <f1refly>it still can't find the volume group :/ <f1refly>is that wrong? reading the documentation, I guessed dependencies expects a list <bricewge>jpoiret: `ensure-directory-for-user` seems right, I'll write it with an optional follow on symlink <jpoiret>you also need to put the luks mapped device in the dependencies <jpoiret>i don't think we have a way for mapped-devices to depend on other mapped devices right now (but there should be) <f1refly>I thought that would be deduced from the dependency of the volume group on the luks volume <jpoiret>so just put the whole mapped-devices list ***jonsger1 is now known as jonsger
<jpoiret>ps: with guix records, you can refer to fields that you've entered above in a subsequent field <jpoiret>hence, you can write (dependencies mapped-devices) <jpoiret>bricewge: you might want to look at (gnu build activation) <jpoiret>there are some similar helpers there <jpoiret>maybe a general procedure with specializations to (make-files-writeable) and friends would be nice <bricewge>jpoiret: It's probably the right module for it to go in or (guix utils) or (guix build utils) <bricewge>argh, `mkdir-p/perms` is still vulnerable to TOCTTOU race <f1refly>it still wouldn't find my volume group :/ <f1refly>i now have (dependencies mapped-devices) in my filesystem definitions <f1refly>it's supposed to be in each of them, both / and /home, right? <f1refly>well, better too many than to miss one <f1refly>I can't tell it that rootvg depends on the crypt_internal, so this is all I can do, right? *mbakke updated ruby-nokogiri to fix ruby-loofah, only to realize it has 5k dependents on 'core-updates' (and 144 on 'master', which is what I checked at first) <jpoiret>does it open your luks device at least? <f1refly>yes, grub loads and executes the kernel + initramfs <jpoiret>yes, but in the initramfs, it doesn't ask for a password again? <jpoiret>the initramfs needs to unlock the LUKS device itself <jpoiret>if there is one, right before dropping into the shell <f1refly>I'll wait for the current install to finish and report back ***jonsger1 is now known as jonsger
<oriansj>f1refly: just need to include cryptsetup in your packages list <jpoiret>oriansj: no, that should be taken care of by the gexp dependencies <jpoiret>I don't have cryptsetup anywhere in my configuration <f1refly>it's still executing guix pull currently, I'll try to include cryptsetup just in case. It's a handy thing to have around, even when no encrypted filesystem is present in the configuration <f1refly>now I'm missing a closing ) in my config <rekado>sneek: later tell civodul /gnu/store/trash is 2.6TB <ns12>florhizome[m]: But I don't know how long it will take for your "wish" to be fulfilled. <civodul>hi! GC on berlin at 11% of the main stage <sneek>civodul, you have 1 message! <sneek>civodul, rekado says: /gnu/store/trash is 2.6TB ***spk121_ is now known as spk121
<cehteh>i wrote down some notes/plan about deletion: https://github.com/cehteh/rmrfd ... question is only who/when/how this gets implemented. I picked that up because its some use case i eventually need to be fixed too, but its not high on my prio list <KE0VVT>My PS1 has been ruined since I moved to Guix Home. <efraim>civodul: about 25 minutes before your first message <efraim>I'm about 28 hours in on camlboot on aarch64 on c-u-f <efraim>didn't expect it to be that long <efraim>gsl I can adjust the test suite on powerpc, srt and apr on powerpc look like actual issues <f1refly>It's working! guix asked me for my passphrase and is now booting! <KE0VVT>Updating my entire system, just to add a user. <civodul>efraim: oh! 28h is more than the default max build time, no? <cehteh>is that still the deletion or some gc scanning now? <efraim>civodul: I'll report when it finishes the build phase <efraim>perhaps compiling it with -O2 isn't the best option <rekado>civodul: I started the du process yesterday night and it finished hours later. So... it's not clear how close this value is to the actual value now. <civodul>rekado: /gnu/store/trash was almost empty at the time i got your message, but it's filling up now <cehteh>rekado: any opinions about my rmrfd plan? i am just trying a small POC implementation in rust creating an inventory DB on my backups, wanna see how much ram that takes when just using std collections instead some disk based database <maxzor>Hello, any read for shepherd vs systemd? <efraim>Is our default go on c-u-f supposed to be 1.14? <tex_milan1>milan@t14s ~/guix-config.git$ guix home reconfigure ./home-config.scm <tex_milan1>guix home: error: gexp: source expression failed to match any pattern <notmaximed>‘gexp: source expression failed to match any pattern’ --> check if the G-exps in home-config.scm are of the right form <notmaximed>The following is bogus: (gexp this that). The following is bogus to: (some-procedure gexp). And the following is reasonable: #~(this that). ***Xenguy_ is now known as Xenguy
<bricewge>notmaximed: I saw your patch v2 about it, thank your for working on this. <sneek>bricewge, you have 1 message! <bricewge>Any chanche we patch it in Guix before it is upstreamed? <notmaximed>bricewge: It could be added to the patches of the 'guile' package. <notmaximed>Though to avoid rebuilds, it might be necessary to define a variant of the 'guile' package for booting (& shepherd maybe) <roptat>civodul, efraim that's quite long, but on a regular x86_64 machine, it takes ~10h <nckx>roptat: -ENOMUA, but from the Web interface: ‘This library implement’, I think changing from url-fetch to git-fetch should be logged, adding properties is also unlogged and should be separate, no point in trailing #t at this late point IMO. <civodul>nckx: your review is more detailed than mine :-) <nckx>I just looked at my browser for a while, didn't even run it. <notmaximed>roptat: cc-for-target + %current-target-system is necessary for cross-compilation <nckx>Oh how could I miss that. <notmaximed>(maven-build-system doesn't currently implement cross-compilation, but it should be easy to implement since compiled java things are architecture-independent, except for JNI things) <nckx>At least Meson will soon, which will unlock a great number of packages (and bugs). <notmaximed>Maybe it should check for target-x86-32?, target-x86-64? ... and not assume linux? (about libjansi.so). Presumably the Hurd is sufficiently linux-like for libjansi? <roptat>thanks! I'll fix that, check and push <notmaximed>Is invoking "echo" necessary? I.e., would (display "something") work? <roptat>notmaximed, to be honest I don't know what the JVM would say about the hurd <notmaximed>I guess assuming linux for java packages is fine for now <KE0VVT>What will happen to a user's home directory when I remove the user from config.scm? <nckx>It will remain, as a hopeful shrine to their inevitable return. <roptat>the echo was actually not necessary at all, I got rid of the whole phase <nckx>Hm, I think I just managed to reconfigure on c-u-f. I can't quite believe it. <roptat>it remains in jansi-1 though, I don't know what the correct code would be *nckx checks uname, guix system describe, pinches arm. <civodul>nckx: neat; and does it actually work? <nckx>Yes! libva acceleration and other generally problematic stuff seems to work too. *nckx testing obviously random stuff. <podiki[m]>woah...did we always have line number linking on issues.guix.gnu.org? <nckx>podiki[m]: …OK, it's not just me 😃 <nckx>I think rekado (finaly) updated it yesterday or so, that must be one of the new perks. <f1refly>can i define a keyfile in mapped-device so i don't have to enter my password twice on boot? it doesnt say anything in the manual about that <nckx>‘finally’ referring to the GC from hell, not rekado. <KE0VVT>Agh, UK Dvorak does not have curly quotes! <f1refly>just writing the passphrase in the config would work as well i suppose <KE0VVT>Or the copyright symbol, or the trademark symbol… <civodul>speaking of GC, it's still running, at 36%... <KE0VVT>nckx: I made the mistake of trying to add a user from GNOME Settings. <vivien>f1refly, every user can read the config file <nckx>Maybe that's my ‘misc:typo’ XKB option. I don't think I've ever booted without it. <nckx>civodul: Which one is ‘it’? <nckx>KE0VVT: Yeah, that might not work, but it would be best to disable that UI if we can. <opalvaults2>Is there a modern laptop that can run libre aside from the Purism Librem 14? <f1refly>but is it possible? if so, where can i read about it? it's not in the manual <nckx>civodul: Never mind; 10:35 local time it seems. <nckx>Started manually by Mathieu. <nckx>Well, the signed binaries. <rekado>opalvaults2: how about the Purism Librem 13v2? <nckx>Useless f'ing package >:( <rekado>opalvaults2: many other laptops will work, but often the included wireless LAN card won't work without firmware blobs. <opalvaults2>and newer laptops such as the x1 carbon need sof_firmware <opalvaults2>so I have to make sure that is not necessary as well <nckx>Hm, my graphics seem less than stable (few-second i915 freeze logged in dmesg, slight artefacts in Firefox). Of course that could be my kernel unrelated to Guix… <nckx>Anybody else seen anything similar on c-u{-f,}? <opalvaults2>i'll take a look rekado. do you have a link for the 13v2? <nckx>f1refly: There's no code to support key files. <vivien>f1refly, I think you won’t find much help with that, I remember there was a discussion about that some time ago here on IRC but I didn’t follow it, and from what I remember it’s complicated <opalvaults2>oh, if this thing can run PureOS it can run GUIX libre <f1refly>well, if keyfiles where supported I could just put the keyfile in the initrd and it'd work <f1refly>but I understand that it's probably hard to support <rekado>opalvaults2: oh, maybe it's no longer available. I'm using this laptop right now. <rekado>I've had a lot of problems with it and this might be the third replacement. <rekado>it actually works now, which is pretty great after all those years. (Except that the display freezes while booting, so I can't see that Linux awaits my passphrase...) <nckx>That sounds like a configuration problem? Unless you've already debugged it. <nckx>Like there's a DRM module on the encrypted disc that Linux needs to display the passphrase. It's happened before. <nckx>So the 3rd laptop would be blameless, at least 😛 <opalvaults2>rekado: i know POPOS has tons of proprietary blobs in it, but maybe their laptops can use free/libre firmware <opalvaults2>gotta check it out. I really didn't want to have to use "the thing that shant be named" with guix. <f1refly>I have some scripts that have the /bin/bash shebang, how would i convert those to guix? <civodul>f1refly: you can usually write "#!/bin/sh", or, if you really need Bash extensions, "#!/usr/bin/env bash" <nckx>Guix System has /usr/bin/env by default, I believe. <f1refly>i'll just change those, should be working with my arch as well <nckx>opalvaults2: I know, I just giggled. <opalvaults2>so wait do a lot of people just use non-guix? how does anyone use guix on a modern laptop? Do most of them not require sof-firmware?? <opalvaults2>is that something specific to post 2020 laptops or something? <nckx>You should come to a Guix Days meet-up and count the 2010-era Thinkpads (and rising number of Librems). I don't know how the rest deals. <rekado>nckx: it used to work before Purism updated their copy of coreboot, which replaced the VGA BIOS blob. <KE0VVT>nckx: I was almost tempted to get a laptop off the rack from Walmart. <KE0VVT>nckx: I'm holding out, to build a desktop PC with the Librebootable Asus board. <opalvaults2>nckx: well maybe the x1 carbon 2021s are still worth something so I can do a system76 or something lol <nckx>I use an (admittedly souped-up) X230. These machines are still quite capable. <rekado>I don't know how to debug things like this. And I don't enjoy rebooting. <opalvaults2>I do like powering 2 extra monitors large monitors with my laptop so I don't think the older x series or t series would cut it <rekado>I had the x200s. Until it completely fell apart. Was my fault though. The screen melted and I broke it some more when I tried to fix it. <rekado>nckx: thanks. I should note that I see only the GRUB background until *after* the passphrase has been accepted. <nckx>They are great machines if you don't care about a specific handful of things, like four kays, which I detest. <nckx>That sounds like what you'd expect unless I'm missing something. <nckx>(I didn't re-read the whole report.) <nckx>GRUB can drive the coreboot FB, then hands off to Linux, which can't, so GRUB's contents remain until Linux unlocks the / and can load the driver. <rekado>okay, I'll bookmark this for when I've got time to play with this. Thanks for the pointer! <nckx>I actually submitted a patch to include the coreboot FB driver in our linux-libre. <nckx>Must be a different bug #; didn't realise that. <nckx>KE0VVT: <I'm holding out, to build> I wish I hadn't fallen in love with laptops ~10 years ago or that's what I would've done. I couldn't go back but the libre laptop situation is deplorable. <KE0VVT>nckx: Wish I wasn't so poor all the time. <KE0VVT>nckx: Desktops are nice. I keep mine in an armoire, so all my technology stuff is hidden away when not in use. <opalvaults2>nckx: it truly is pretty bad. Using a desktop isn't so bad as newer intel/AMD cpu's have decent throughput with integrated graphics. <opalvaults2>however I do like having one thing to do everything, probably similar to a lot of people in the guix/emacs community. <opalvaults2>I've emailed system76 to see if their line has any laptops that do not require non-free firmware. I will report back when I get a response. *nckx lagging a bit; ‘until the screen melted’ WTF rekado? <rekado>the CCFL backlight just started to smoke and the thing caught fire. <cehteh>hah .. hours later: $ find backups/ | wc -l ; du -sh backups/ <nckx>KE0VVT: I used to love desktops but sitting inside got old. I can't enjoy it anymore. My desktop is now an offload node, so it still serves well. <opalvaults2>I might start doing that more often lmao with my laptop :D <KE0VVT>nckx: My X200 has terrible battery life, so I effectively only use it in my recliner chair. <nckx>I like to hack in random places. I feel like such a hipster, though I probably look like the opposite. <nckx>Several strangers have asked me about Guix (or whatever that sticker is :) which was nice. <nckx>Fewer have tried to get me to leave because terminals are clearly for hacking. <KE0VVT>I need a Guix sticker for my X200. <opalvaults2>Here's an interesting Linux laptop company using coreboot and open source firmware. <nckx>KE0VVT: Something could probably be arranged? <opalvaults2>nckx: where can I get a guix sticker? (or shirt for that matter) <KE0VVT>I don't do shirts. I wear traditional trousers and waistcoats. <nckx>There's no official Guix shoppe. But I suspect that starting an ‘I want Guix stickers’ thread on help-guix@ (I guess?) would gather some me-toos, and maybe something could be done. <nckx>Group buys, that sort of thing. <KE0VVT>People joke about me being Amish because I don't drive and I avoid most modern technologies, so I doubled down and got Amish clothing. <nckx>Well, you hide your computer, so for a moment I thought you were an undercover Amish hacker :) <nckx>Now I legit want a Guix-patterned waistcoat. <KE0VVT>"Giant beard, no driving cars, no cellphone, no electronic this or that… Are you Amish?" <nckx>DigitalKiwi: The Guix stickers are ‘nicer’ in that there's no background, it's just the logo. <KE0VVT>DigitalKiwi: Some even sell cellphones! <KE0VVT>DigitalKiwi: But cellphones are not allowed in the house. They have to be left outside at the door. <nckx>These don't seem to be the stickers that actually happened, though, they are many to an A4 page in all kinds of sizes, which is actually genius. <KE0VVT>DigitalKiwi: Would it be easy to make a Faraday chest for people to place their cellphones at the door? <opalvaults2>I mean so many companies are doing made to order prints that it might be fairly trivial to set up granted that there is support by others. <opalvaults2>It'd be nice to use an ethical company for shirt printing as well <nckx>KE0VVT: I have contemplated making one, but I'd actually want to test it, and… well, that would require a 'phone. <nckx>KE0VVT: One of the older ARM build nodes. <nckx>I'm sitting next to one right now, making an unreasonable amount of fan noise. <nckx>Testing the Faraday cage. <KE0VVT>nckx: Just ask your family to come over. <jpoiret>f1refly: i don't suggest using a keyfile at all for now, the initrd is in the store so readable by all <KE0VVT>I know, family sucks nckx, but it's almost Festivus! You can Air your Grievances! <jpoiret>so unless you modify a lot of code to add support for moving the initrd out of the store then customizing it, yyou'll still have that issue <KE0VVT>Man, those Guix stickers are sexy. <f1refly>jpoiret: I already accepted the fact that I'll have to type my password two times <nckx>jpoiret: You could provide it separately with appropriate permissions. No need to move the entire initrd out. <jpoiret>f1refly: it's become second nature for me <nckx>Hm. This doesn't seem to be common knowledge. <jpoiret>one thing I suggest: have your keyboard layout not be qwerty, so that you can type the same password in 2 different layouts <nckx>So initrds (initramfs, now stop correcting me) can be stacked, and the trees just get merged. <jpoiret>i wouldn't say it's entertaining but you don't have the feeling of typing the same thing twice <f1refly>I'd like it to be neo2, but when I try to set that it is set to qwerty :/ <jpoiret>initramfs in how the kernel mounts it, the file is still an initrd iiuc <KE0VVT>jpoiret: I Dvorak-encode my passwords, too. <nckx>So if Guix's initrd code provides a ‘good enough for now’ snippet that just looks for /luks.key, that file could be provided by a second initrd at boot time. <nckx>jpoiret: No, they are very different internally, but initrds are obsolete, so the word is free, and most importantly, shorter ☺ <nckx>And GRUB still calls it initrd so whatev. <jpoiret>yes yes, i read about the initramfs vs initrd rather recently <nckx>jpoiret: That sounds like something else? <jpoiret>i mean, both are just cpio archives no? <nckx>But the stacking feature is certainly not new at all. <nckx>But who knows, it's GRUB, maybe they only supported it much later. <nckx>jpoiret: I thought initrd was a real file system image. <jpoiret>old initrds were actually gzipped file system images <f1refly>what would be the best way of aliasing vim -> nvim? <jpoiret>by stacking initrds, do you mean concatenating them? or just having 2 separate initrds? *nckx sees moderated cock.li and opal.sh messages, sighs, but oh! they are both legit! happy days. <nckx>jpoiret: Just 2 separate ones. The trees are ‘merged’ together at extraction time by the kernel, which gets passed all compressed initramfs data in memory by GRUB. <nckx>Nothing fancy about the ‘merge’; it's just like tar xf a.tgz && tar xf b.tgz && … <nckx>Stacking is just what I call that. <nckx>f1refly: If you use guix home (but I don't), it has a shell alias interface. Otherwise, just as you would otherwise, in .bashrc. <jpoiret>nckx: I could possibly work on adding support for additional custom initrds <f1refly>okay, I just wondered if there was a cleaner way <jpoiret>to warm up for possibly bigger changes to the early userspace/initrd guix handling <nckx>Sure. I've started writing some helpers to create the key-only initrd, because curiosity. <jpoiret>oh, cool! too bad we can't use the daemon for that <nckx>Nice thing is this doesn't need Guix integration at all. <nckx>jpoiret: I think that's actually an advantage. <jpoiret>but that could mean code reuse for the existing initrd procedures <nckx>Your system.scm is a programme that runs as root, it can create the cpio image when it runs, no need to involve the daemon at all. <nckx>jpoiret: You already can reuse Guix's cpio support. <nckx>You can use any Guix code in system.scm. <jpoiret>oh but you're right, g{nu,uix}/build/ doesn't use gexps at all, duh <nckx>Watch me hit that wall, or not, I guess. <jpoiret>the one thing that would be annoying is actually using that properly in early userspace <nckx>That'll need patches, no way about it, but why annoying? <jpoiret>passing things to boot-system isn't very straightforward right now, especially for things like volume mount <nckx>I think you can write at least a PoC without passing anything. <jpoiret>although, here it could just be a matter of adding an optional (keyfile ) field to luks mapped-devices which would use that when opening <nckx>Just look for /luks.key (or whatever we call it) directly when invoking cryptsetup. <nckx>Oh, I'm not thinking about anything fancy like that just yet. <jpoiret>right. in that case it's pretty easy then <jpoiret>but in the end we'd want to make it easy for the end user :) <nckx>I'm all for doing things the right way, but this seems like a long-overdue feature that has suffered because of that, and delivering something to users is nice too… <KE0VVT>Does HandBrake pull in libdvdcss? <jpoiret>KE0VVT: you can use guix graph --path handbrake libdvdcss *nckx makes a note to call it /luks.<device>.key, duh. <jpoiret>thinking about mapped-device, isn't it a bit complicated to have luks and lvm-specific fields in the definition? seems like quite some things in guix are screaming *inheritance*, although there's no interface for that (except GOOPS) <jpoiret>also thinking about package/inferior-package <jpoiret>but seeing how goops handles inheritance using generics, i'm not too stoked about it either. has a very "impure" side effect feel to it <singpolyma>I love GOOPS but you can always model inheritance without it. With enough macros you might even reinvent GOOPS ;) <civodul>jpoiret: we could have record type inheritance without pullin in GOOPS <jpoiret>yes, I also think that'd be better than using the whole goops <nckx>I'm not going to participate in this discussion but I think e.g. <package> / <inferior-package> unification will lead to something like that being implemented anyway. <jpoiret>although i'm not too sure how that would work without a lot of global mutable state <jpoiret>civodul: well, i was saying how a (keyfile "") field would be good for luks devices. But that wouldn't make any sense for lvm for example 
