IRC channel logs


back to list of logs

<nckx>euouae: I am sorry that I ever this would be simple or clean. 🤡 <>
<nckx>That I ever, indeed.
<nckx>And there's probably some obvious deal-breaker I missed, but it was fun to write horrible regexp code.
<somenickname>euouae: No, I just wanted to know if someone can approve that it works or requires additional stuff.  Guess I need to enable debug and do some testing for something that should work out of the box but not for me...
<mirai>huh, just spotted this while building something in c-u: <>
<ganesh-birthday>"Untitled - Pastebin Service"
<somenickname>Also, what should be the intended behavior of booting from NVIDIA GPU but without nouveau on.  Probably low resolution but I should see output?
<euouae>nckx: oh yay! you fixed it?!
<nckx>I expect it to get (not unjustifiably) murdered in review, but maybe someone has a better idea.
<euouae>I don't understand though, you seem to be editing version.texi
<nckx>Or there's a better way to READ without making any assumptions about future read syntax.
<euouae>but are all version strings from that file? because my man pages work fine, it's only the info manual that misses the version strings
<nckx>Did you read the whole patch.
<nckx>There are two commits.
<euouae>I read it all, I'm just not understanding it very well
<euouae>It looks to me like you're regexing the version string from package-management.scm into version.texi
<nckx>People still use man pages? Wild.
<ulfvonbelow>well they sure beat "visit the online documentation"
<euouae>right, but why are they okay? and is your patch syncing the two versions correctly? or will info manual show different version string to man pages?
<euouae>err nvermind, I'm asking, why do the man pages work?
<nckx>Hmm, I wonder why we're not squeamish about rebuilding those, while explicitly not wanting to rebuild the info manual. Is it that much more expensive?
<euouae>Ah because those get rebuilt? got it
<nckx>euouae: Because the current code deliberately doesn't want to rebuild the info pages for each commit, indeed.
<euouae>nckx, can't the package force the output of info pages to be built locally?
<euouae>to lessen strain on server?
<nckx>euouae: <is your patch syncing the two versions> [deliberately dropping ‘correctly’] In a way. It replaces 0.0-git with 1.4.0,, but not 1.4.0-10.4dfdd82.
<euouae>Ah got it.
<nckx>euouae: I'd say straining people's computers is far worse than straining the build server.
<nckx>Anyway, I guess I have to research why we're yeeting out fresh man pages for every single guix pull, and if those are really that much cheaper. (Info *is* expensive, that's not in question.)
<euouae>man pages are superior, face the truth
<euouae>ACTION is kidding, they likes info better 
<euouae>especially within emacs
<euouae>Good job on that patch, that is certainly nothing I would be able to dish out
<pinoaffe>hi folks, is there a way to actually do `guix package -m "(@ (whatever module) manifest)"`?
<nckx>OK, so the man pages are not built by ‘guix pull’ (guix self) at all.
<pinoaffe>aka, to specify a manifest on the command line using a guile expression rather than a path to a file
<nckx>The ‘1.4.0-10.4dfdd82’ in my ‘guix-build’ man page is pretty, sure, but my pulled Guix is actually newer.
<pinoaffe>also, for whatever reason specifications->manifest is *extremely* slow when I add stuff to the load path, does anyone know why?
<euouae>pinoaffe: echo "(@ (whatever module) manifest)" | guix package -m -
<euouae>pinoaffe: does that work?
<euouae>nckx: whoops!
<nckx>pinoaffe: It might fail because you can't seek, but there's always guix package --manifest=<(echo 'hello i am become manifest')
<nckx>Ah, basically what euouae wrote in the meantime, with extra shellsanity.
<pinoaffe>euouae: no
<pinoaffe>nckx: ah yes, the sad part is that y shell of choice doesn't do input redirection
<nckx>(There is no magic special handling of the ‘-’ token, that's why it won't work.)
<nckx>(Not because it can't handle stdin.)
<nckx>pinoaffe: Can't you use -m /dev/stdin then?
<pinoaffe>nckx: ah yes, that works!
<pinoaffe>thanks a bunch :)
<pinoaffe>also I like that - isn't treated differently, since it is a valid filename
<jaeme>Rust packaging is pain. But `guix import crate <name>` helps so much.
<jaeme>Is rust packaging supposed to be very tedious?
<nckx>From the Guix side, the antioxidant-build-system should reduce the pain a bit. From the Rust side, I dunno how interested they are in improving packaging outside their walled garden.
<jaeme>Wdym by "walled garden"?
<jaeme>I see
<chipb>jaeme: I'd guess they mean anything existing outside the scope of cargo as The One True Rust Build Tool.
<jaeme>I'm trying to package a wallpaper daemon called 'swww' for wayland compositors and it has led me to writing like 30+ crate definitions
<jaeme>This is normal right?
<bjc>if it's only 30, you're getting away easy
<bjc>last time i dabbled in rust, i got over 200 deep before i gave up
<jaeme>haha (in dread)
<jaeme>But a lot of them are just older definitions of upstream crates so far
<jaeme>except for stuff like the CUDA rust libraries
<jaeme>ACTION shivers
<drewjose>Packaged and I only had to add 10 :)
<apteryx>curious; has anyone else changed from dvorak to something else like colemak or even QFMLWY?
<apteryx>and if you did, did it improve things (comfort, efficiency or otherwise?)
<lilyp>drewjose: just 10 dependencies for a barebones make!
<adanska>just seeing if theres anyone working on porting auto-cpufreq to guix? otherwise i'll give it a shot, doesnt look too complex
<adanska>i think.
<adanska>ACTION touches wood
<civodul>Hello Guix!
<janneke>ACTION is afk for a bit
<fnat>Hi, I sent an email to that I suspect might have caught by the antispam. That was yesterday morning, around 8am BST. There's no sign of the email here
<the-hobbit>"guix-patches (date)"
<fnat>Now, not that the email is particularly important to be honest, but who should I reach out to to have a quick look?
<fnat>*might have been caught
<janneke>fnat: if it is your first mail to a guix list it, will await human moderation
<fnat>I see, thanks janneke. It's not my first email, but it might have been flagged for human moderation anyway (misteriously, it was flagged as spam on my end). I'll wait a few days and see. Thanks!
<janneke>what was the title of your mail?
<janneke>ACTION won't be able to look, but others here will
<fnat>janneke: [PATCH] home: msmtp's password field to accept strings and G-expressions.
<civodul>friends, Cuirass should be able to make *cough* better use of the available resources:
<the-hobbit>"guix/guix-cuirass.git - Cuirass continuous integration tool"
<adanska>hi guix!
<adanska>going to try writing a package and service for auto-cpufreq. `tlp`'s decl. is in linux.scm, would it be a good idea to put `auto-cpufreq` there too?
<adanska>also, when it comes to sending my patches, should i have seperate ones for the package and for the service?
<jpoiret>adanska: yes
<adanska>to both questions?
<jpoiret>no to the second one sorry
<jpoiret>for the first, i don't really know
<jpoiret>if it's entirely linux-specific, then yes
<adanska>it is, its a linux only tool
<minima>when creating a system image, is there a way to copy files over to a given path within the image? context: i'd like to inject a specific set of SSH server keys into the image, in /etc/ssh
<minima>i suppose this should be done "via the store", i.e. having the keys as artefacts in the store
<jpoiret>yes, you should extend the etc-service-type
<jpoiret>maybe there's already a service specific to ssh though
<minima>oh! super interesting!!
<minima>brilliant, thanks jpoiret i'll look at etc-service-type
<jpoiret>note that the keys will end up in your store though, which is world-readable
<minima>i wasn't able to find anything very specific to ssh, but i don't know, maybe i missed it - anyway etc-service-type sounds like a good unmatched-paren
<minima>sorry, a good match - darn completion :)
<minima>jpoiret: ... hm ... that's a good point ... what's the threat model, whoever has access to my system, the one where the image gets created, correct?
<minima>i think it's fine in my context but that's a great point
<minima>also, just to avoid the xy problem scenario, the broader context and objective would be to create an image that i can SSH into knowing what the SSH fingerprint will be
<minima>in other words, i thought of dictating what the SSH key is (or what the keys are) so that when i connect to the image (or machine should i say) i know what SSH fingerprint to expect
<minima>the only way that came to mind was to create the keys separately and manually with ssh-keygen and have them added to /etc/ssh
<parnikkapore>Hi Guix! I'm running a Cuirass instance to build and serve substitutes for my own channel. I'd like to pin the packages in the latest evaluations so that they won't be deleted by guix gc, even after >30 days. What's the best way to do this?
<janneke>that was quick...
<janneke>sneek: later tell parnikkapore: if it's about 30days, you could postpone deletion to two months by running guix gc -d 2m, for example
<janneke>sneek: botsnack
<adanska>sneek: botsnack
<parnikkapore_xm>janneke: (had to switch devices) afaik cuirass evaluations aren't affected by -d, unlike profiles and pulls?
<parnikkapore_xm>(also, afaik -d never makes you delete _less_ stuff?)
<janneke>sure it does
<janneke>if it's not about a time period, see the --root option to many comands, like guix build
<parnikkapore_xm>hm, might need to check
<parnikkapore_xm>my current idea is to gather the derivations in those specifications and pass them to `guix build --root`, but I want to ask first, in case there's an easier way
<parnikkapore_xm>ACTION needs to check if cuirass registers profiles for the evaluations; if it does, then only changing the cleanup script is needed
<adanska>ok, so i've run into the first roadblock. auto-cpufreq depends on the `power` module on pypi which essentially provides a cross-platform method of obtaining power info on your system. my issue is precisely that: it's cross platform, and depends on an objectivec interop library. since guix is really exclusively linux (not including hurd), is it ok if i patch out everything except linux support? how do you guys typically deal with these
<adanska>cross-platform modules in guix?
<adanska>ok, upon a further look, it doesnt seem like there will be any issues if i just dont package the macos stuff.
<adanska>just to confirm: it's ok for me to write packages that dont work cross platform? even if they advertise as such?
<nckx>sneek: later tell adanska Absolutely. We also remove 'cross-platform' from descriptions more often than not as low-value noise.
<nckx>apteryx: No, but after a few years of Colemak I switched to Dvorak for ergonomic reasons. I got sold on Colemak's 'easy transition' from Qwerty and regret it now.
<janneke>yay for dvorak!
<janneke>ACTION does prefer maltron, but that needs a custom keyboard that doesn't really make for great traveling
<nckx>I have yet to try that...
<bjc>i've never understood the "easy transition" thing. it sounds like something that would only make sense to someone who's never changed layouts before
<bjc>ie: none of them are easy unless they're also, simultaneously, basically pointless
<efraim>I'm feeling stumped on this error and I'm not really sure what's happened here
<efraim>/gnu/store/7vgsy4gmwpmpgvh33g6yr5cjys9jpd0b-vg-1.50.0/bin/vg: error: depends on 'lib/', which cannot be found in RUNPATH ("/gnu/store/7vgsy4gmwpmpgvh33g6yr5cjys9jpd0b-vg-1.50.0/lib"
<bjc>likewise, the "cut/copy/paste" keys are in the same place is such a weird selling point
<efraim>for some reason the library seems to be named 'lib/'
<janneke>looks to me like a bug in the build system
<efraim>it's a hand written makefile, so lots of fun :/
<janneke>yeah, that figures
<efraim>I'll try changing the line that creates the binary to use lib/ instead of $(LIB_DIR)/libvg.$(SHARED_SUFFIX) and see if that gets me anywhere
<janneke>surely you mean something like: -L lib -lvg?
<janneke>(or possibly $(LIBDIR) -l vg, depending)
<efraim>janneke: thanks, I think my brain is fried
<janneke>it's the linker's repsonsibility to choose the extension
<efraim>sounds good to me. I've already removed the options for building the static library
<radio>When using define-configuration to serialize something, no predicate to test if something is a valid configuration is produced?
<radio>I'm writting a simple configuration for fish abbreviations, since the current alist structure is limitating about which kind of abbreviations you can declare within guix (actually you can just put the flags in the key string of each association, but it's ugly)
<radio>And I used define-configuration to do so
<radio>But then now I need to write a predicate to test if something is a list of abbreviations, and I have no predicate to test if something is an abbreviation
<radio>I wouldn't like to rewrite it as a record because configurations have types and documentation strings
<radio>What to do?
<radio>If someone want to take a look:
<civodul>friends of the Hurd, friends of the VM: this is huge 👉
<the-hobbit>"[PATCH 00/12] Introducing Smart Hurdloading"
<civodul>no less
<janneke>"Ludovic Courtès (12):" -- oh my
<civodul>to be fair, it’s called Smart Hurdloading™, but the patches themselves aren’t so smart
<zimoun>Aside the good marketing, the cover letter is appealing! :-)
<civodul>marketing is everything
<civodul>i spent like 10x more time than i expected on this damn patch series
<civodul>i have to love it now
<dthompson>I am so behind on hurd stuff that I don't know what this means :)
<dthompson>boosting it on the fediverse anyway
<civodul>that’s the point of marketing, especially when there’s “smart” in the name: that one cannot guess what this is about!
<lechner>civodul / yay!
<ulfvonbelow>I wish we had a (catch* thunk cont handler) that was like (call-with-values thunk cont) except that handler is active during thunk
<lechner>Hurd is a hard name to market since it sounds so much like "hurt"
<ulfvonbelow>it can be implemented manually, but it causes an argument list to be consed
<lechner>Hoard, on the hand, would be a totally different story
<ulfvonbelow>hurdful compuding
<lechner>also, "onboarding" would sound better than offloading, although I realize it makes little sense
<civodul>indeed :-)
<lechner>maybe one day someone will rename user-space microservices to "coins", so Hoard can make sense
<lechner>but then i am not sure that hollow marketing is compatible with the free software movement
<lechner>or maybe that's exactly what we need
<lechner>why do people use winblows again?
<dlowe>games with anti-cheat
<nckx>Because it's free.
<dlowe>it's default
<dlowe>comes with the package
<ulfvonbelow>man, remember when bunding a browser with an OS was crazy monopolistic behavior/
<lechner>was it?
<lechner>also, instead of childhurd, which sounds a lot like childhood, i would use "baby hurd"
<lechner>Hi, by which logic does the Guix daemon prevent kernels and initrds from being garbage collected, please? is it the mention of either in "/parameters" is the system profiles?
<mirai>civodul: ohh, you beat me earlier to it (the hurdloading) <>
<mirai>def will have to check it out
<mirai>lechner: “we” may shit on Windows as much as we want but IMO we shouldn't completely dismiss it. There are things that Windows has an advantage and it would be profitable to learn from those parts
<lechner>ACTION shudders
<mirai>nckx: ackschully, “gratis”
<mirai>Are C-U build failure logs of interest to anyone?
<mirai>I see that gawk isn't too happy <>
<andrea-bocelli>"Untitled - Pastebin Service"
<zamfofex>mirai: I feel like regarding proprietary software, although it’s wrong for being proprietary, it’s not like it doesn’t have any value or anything that can be taken from it. Ideally it wouldn’t be proprietary, but that doesn’t mean everything that it does is wrong and should be disregarded. (Though, of course, I wouldn’t endorse it as a whole either in any way.)
<zamfofex>As in, of course being ethical is more important than most other aspects, but that doesn’t mean other aspects (like technical merit, aesthetics, etc.) don’t exist, and so certain things can be learned from some proprietary software.
<janneke>civodul: reconfiguring to test smart hurdloading!
<lechner>Hi, I switched to Guix in April of last year, and just want to say thank you to all contributors. After losing hope in another Linux distro, Guix provided a great technical perspective of what could be. Plus, I like Scheme and no longer use shell scripts or Perl. I think we are the forefront of free software development
<janneke>lechner: sweet
<nckx>And actually, let me second that. Thank you all. You are disturbingly competent for a bunch of weirdoes on the Internet.
<janneke>ACTION has been using guix system for 7y4 or so and is also very grateful for all you lot!
<zamfofex>+1 💖
<Gooberpatrol66>so is the purpose of that Smart Hurdloading^TM patch to build packages natively in vms to obviate explicit cross-compilation support?
<nckx>Sigh. Recent(?) K-9 versions default to 'Reply' over 'Reply all'. Enjoy the duplicate mail, civodul.
<janneke>Gooberpatrol66: yes
<janneke>we've been already doing that, but (short summary) it was still pretty hard to setup, there were bugs, there were problems running childhurds on the buildfarm
<nckx>civodul: I had my goofy fun, which was the point, but '@set GUIX-RELEASE 1.4.0' is probably the simplest way forward.
<ulfvonbelow>civodul: random catch scrolling through the patches, s/offlading/offloading/
<stocastico>hello guixers! does anyone have any exeperience with guix on the pinebook pro? I'm having problems booting the system, not really sure why :( . I rightly get from towboot to uboot but after uboot loads the kernel the screen goes black forever. here is both the configs i tried and here the flashing script i run from an armbian installed on the emmc
<andrea-bocelli>"debian Pastezone"
<andrea-bocelli>"debian Pastezone"
<civodul>nckx: heh sure :-)
<elevenkb>Hey there how does one get the dependency graph of a guix home profile?
<elevenkb>I mean the package dependency graph, not the service dependency graph.
<janneke>hm psautohint fails to build
<janneke>guix refresh --list-dependent psautohint makes it seem real harmless, but that can't be true
<civodul>elevenkb: hi! you can approximate it with “guix graph -t references $(readlink -f ~/.guix-home) >”
<civodul>it’s going to be crowded though
<janneke>font-abattis-cantarell depends on it and isn't listed?
<elevenkb>Thanks civodul!
<lechner>Hi, what does "lowering" an item mean in the context of the Guix store, please?
<ulfvonbelow>for some items it means producing a derivation, for others it means producing a store item
<ulfvonbelow>e.g. a <computed-file>, <package>, <bag>, etc will result in a derivation, while a <plain-file> will result in a store item filename string.
<ulfvonbelow>at least, that's what my experiments with (guix monad-repl) tell me
<lechner>okay, thanks! I am just checking my own understanding.
<lechner>and what is a "derivation" please?
<ulfvonbelow>the lowest-level representation of a "build unit" we have. Usually it refers to a regular file plain text store item of a certain format with a filename ending in ".drv", though it can also refer to the in-memory representation in guile, a <derivation> object
<lechner>okay, and how are derivations used in Guix, please? What is their purpose?
<ulfvonbelow>a derivation includes the complete list of input derivations and the output names from each of those that are used, a list of its own output names, a builder, sources (non-derivation inputs), environment variables (some of which are treated specially and interpreted by the daemon), the host system name, and other stuff
<ulfvonbelow>some derivations (like ones that download source code) are "fixed-output", and are consequently allowed access to the network because all non-reproducibility can be detected due to the included content hash
<ulfvonbelow>basically, a derivation is a file that sits in the store, and it's also a node in the directed acyclic graph of derivations that describes how to produce certain outputs
<nckx>Their high-level ‘purpose’ is to serve as the object you ask the build daemon to build, because it has absolutely no concept of ‘packages’, ‘git checkouts’, ‘file-like objects’, and any of that silly abstract nonsense.
<nckx>That's why Guix can use the Nix daemon despite the two projects not having *that* much in common TBH.
<zamfofex>nckx: I wonder how sensible it would would be to just have a Guixy approach that doesn’t use the Nix daemon (or a fork thereof). Something that just directly build Guix objects like packages and operating system records in an environment without needing to go through derivations.
<ulfvonbelow>if you're okay with losing the ability to allow multiple users to share the same store, that would work.
<mwette>guix is a functional package manager; the derivations are definitions for the functions that generate outputs (e.g., executable binary software packages) given the inputs (e.g., software source packages, dependencies, env variable)
<zamfofex>Well, I imagine still having a daemon, though one with Guix‐specific concerns in mind only.
<nckx>There's always too.
<andrea-bocelli>"Derivations - Nix Reference Manual"
<Rovanion>Anybody knows why I'm getting error: symbol 'grub_file_filters' not found. when trying to boot the LiveCD?
<Rovanion>I've tried burning it using two different programs to the USB.
<nckx>Rovanion: I'm not sure, but could this be related to UEFI ‘secure boot’?
<Rovanion>nckx: The machine is too old for that I'm afraid. Intel i5 2500K inside.
<nckx>I'll have to admit I've never burnt the ISO to CD, ever.
<nckx>Oh, you said ‘burning to USB’.
<Rovanion>Sorry, I wrote unclearnly.
<nckx>A special choice of words, but OK, it does increase the odds that something went wrong when writing.
<nckx>Which command(s) did you use, exactly?
<Rovanion>I wrote it from the Windows PC I was sitting by, trying both Balana Etcher and Rufus. Rufus had two modes (copy and dd) so I'll try dd next.
<nckx>The fact that they offer that choice implies that ‘copy is not dd’, and we definitely want something akin to dd.
<nckx>It probably unpacked the *contents* of the ISO into the USB drives' FAT file system, which would cause exactly that error message.
<nckx>IM(second-hand)E these kind of GUI tools need careful hand-holding to prevent them from being too clever and breaking things.
<nckx>Not just with Guix; in general.
<lechner>zamfofex /
<andrea-bocelli>"Implementing the guix-dameon in Guile"
<nckx>Oh, right, sorry zamfofex.
<nckx>That addresses the ‘Guile’ part. I don't see any advantages to ‘raising’ the daemon protocol to higher-level objects, only disadvantages, so you'll have to explain that part further.
<nckx>Having a ‘parse this Aterm file, with these inputs, and build whatever comes out the other side’ is a pretty solid base IMO.
<zamfofex>nckx: I don’t know much to say either way, it just felt it would be a reasonable thing. I don’t see these “disadvantages”, though it’s probably because I’m not as familiar with it in general.
<nckx>I think we've broken the package ABI a good number of times in the past, for example. It's an *extremely* high level of abstraction for what we need and currently have, which is a dumb thing-builder that is very, very good at building things. Dumbly.
<nckx>I don't have a well-articulated response ready though. I've never answered this question before.
<zamfofex>nckx: It is fine. I feel like the daemon being usable across multiple versions of Guix is a very significant advantage! And being able to change the package record definition (and for other things like operating system records too) is also important.
<nckx>Rovanion: Any success?
<lechner>ACTION has never heard of GRUB being too new
<lechner>Rovanion / i believe that error relates to grub-install having a different notion of devices from GRUB during boot (perhaps caused by an older BIOS). i would explore the available devices with 'c' if needed and then correct the boot menu in-memory with 'e'. It's probably obvious
<lechner>if you are in the grub rescue shell, you have to find the GRUB files first and then run 'insmod normal'
<nckx>I respectfully disagree with your sincerely held belief.
<nckx>Where do you get this ‘too new’ concept?
<lechner>i thought the equipment was old
<lechner>but so is mine
<nckx>This GRUB was not installed with grub-install, and doesn't care about device names.
<nckx>You won't be able to find the GRUB files because the file system driver is missing, hence the error about ‘filters’.
<nckx>This is not a general-purpose GRUB.
<nckx>It can boot the ISO it came with, nothing more. If you unpack that ISO, things break.
<lechner>okay, fine. it's a CD, but your theory has holes, too. How can Grub show any messages when the ISO is burned as a FAT filesystem?
<nckx>WDYM by ‘burned as a FAT filesystem’?
<nckx>Y'all a bunch of pyromaniacs >:(
<lechner>wasn't that the "copy" conclusion?
<nckx>I cannot say for sure since the nearest Windows machine is several miles away, but I expect this Balufus tool to be doing what it considers copying the boot sector to the start of the drive. I don't know, but I don't think that counts as a hole. I understand GRUB quite well.
<lechner>yes, but rufus?
<nckx>Not a shred.
<mirai>is it feasible to start building core-updates in CI
<nckx>I don't see why not.
<mirai>can anybody schedule it or is it a “members-only” thing
<nckx>The latter.
<nckx>‘Specification core-updates already exists.’
<mirai>building c-u with a single 6c computer here is… slow
<nckx>ACTION has 2/3rds of that…
<lechner>i think oil helps
<mirai>nckx: can you get CI to start churning out c-u substitutes or is this a ML-worthy topic
<nckx>I'm looking.
<nckx>504 Gateway Time-out ♪
<degauss>Hi all! I'm following Ludo's blog article "From development environments to continuous integration", "guix build -f guix.scm" works fine, but as soon as I move "guix.scm" into ".guix/modules", change the 1st arg of "local-file" to "../.." and symlink back to "guix.scm", the recursive copy done by "local-file" becomes totally empty. Has anyone come across the same issue or have any hints? Thanks a lot! :)
<nckx>It's weird, even using the psql CLI directly I can't seem to operate on specifications. It just hangs.
<nckx>sneek: seen mothacehe?
<sneek>mothacehe was in #guix one day and 8 hours ago, saying: civodul: what's the duplicated part?.
<nckx>sneek: later ask mothacehe Any idea why a query like this would hang? psql -d cuirass → delete from Specifications where name = 'core-updates';
<sneek>Got it.
<apteryx>nckx: interesting! so colemak's finger rolls fared worst for you than dvorak's alternating hands in terms of comfort?
<Rovanion>nckx: Unfortunately a dd'd image from Linux had the same result.
<nckx>Now that's interesting.
<nckx>apteryx: Yes.
<nckx>Rovanion: At least you can share the exact dd command you used now :)
<Rovanion>dd if=Downloads/guix-some.iso of=/dev/sdb bs=8M
<nckx>Is this an official ISO?
<nckx>ACTION goes to look for a USB drive and some metal.
<nckx>Did you happen to verify the GPG signature already? (Unlikely to be corruption, but still.)
<Rovanion>Nah, but downloaded it twice and tried with both.
<nckx>The sha1sum is 46bcc9c5ea04515b4a3bd37c8efff790512612da, just in case.
<Rovanion>Checks out.
<apteryx>nckx: great, thanks for giving me a good reason to stick with dvorak
<nckx>It's one person's experience but I'm not impressed with heatmaps and seemingly-logical stories about finger movement anymore, and nobody does actual studies of long-term use AFAIK.
<ulfvonbelow>I'm using workman right now, so far it's been... whelming. It seems that, like with battery life, race-to-idle tends to overwhelm all efficiency concerns, and it's hard to compete with experience since youth in qwerty for speed.
<nckx>Meanwhile, I killed my entire desktop with ‘pkill -USR1 dd’ because I am very smart.
<ulfvonbelow>I get the sense that I should've skipped alternative keyboard layouts and gone straight to stenography systems
<ulfvonbelow>but I guess this way I'll be the first to know when our gdm finally has a working layout switcher or on screen keyboard
<Rovanion>I started learning stenography and got a fair bit, but then realised that each language has its own system.
<ulfvonbelow>yeah, the reliance on phonetic mapping makes it inherently inconsistent in that way
<ulfvonbelow>it's probably still worth it if you're all-in on english
<nckx>Rovanion: Any other USB drives around? (Or, hell, CDs?)
<nckx>lechner: I cannot find a workable hypothesis where the BIOS finds the USB device to load GRUB, only to then lose track of it completely.
<nckx>Older machines that can't boot from USB are a dime a dozen, but this…
<Rovanion>nckx: Just tried to boot a Ubuntu image and got the same issue so yeah, I'll try some other USB stick.
<Rovanion>nckx: Funnily enough this computer actually has a DVD drive.
<nckx>Oh right, we outgrew CDs again.
<degauss>I think I found the bug in the "Level 2: The repository as a channel" section: the "vcs-predicate?" should be updated to have "(git-predicate (dirname (dirname (current-source-directory))))". I think I'll ping Ludo about this, as the post may need fixing.
<nckx>degauss: Yep.
<nckx>Unfortunately inelegant, though.
<nckx>Any real-world drawbacks to using (getcwd)?
<nckx>(With OR.)
<nckx>This isn't a workflow I personally use.
<nckx>degauss: Now I've actually tried it out, and take it back: I don't think there's a bug.
<nckx>The blog post suggests using a .guix/modules subdirectory of the Guile git checkout, so why would (GIT-PREDICATE? ".guix/modules") return false?
<degauss>nckx, I'm actually practicing on another package to learn, and it failed regardless of whether "guix.scm" and ".guix/modules/my-package.scm" were include in a git commit or not. While "guix.scm" existed as a file (not symlink) in the project's root (with "(local-file "." ...)"), "guix build -f guix.scm" worked even if "guix.scm" didn't yet belong in a commit. Anyway, no reason to worry about the Guile package, I didn't use it for my tests. ;)
<nckx>If I read your original message correctly, that's not what you expected.
<degauss>nckx, I don't know, maybe "(local-file "../.." ...)" still passes "./" as ".../.guix/modules/" to "vcs-file?" instead of ".../.guix/modules/../../" or ".../"? I'm not familiar enough with Guix to check that myself, however the "(dirname (dirname (current-source-directory)))" seems to work.
<nckx>Yeah, maybe. I'll have to try the full example (which is a bit too much right now).
<degauss>nckx, think I figured it out: "(git-predicate "X")" creates a predicate which is #t for files *under X*. In your example, "((git-predicate ".") "/home/nckx/guile/README" (lstat "/home/nckx/guile/README"))" should be #f. So my "(dn (dn (c-s-d))" works because it creates a predicate for the root of the source directory.
<degauss>(In other words, "X" should be the root of the Git checkout, the dir having the ".git" subdir.)
<degauss>(That is, for "." being ".../.git/modules".)
<degauss>I'll send a patch to Ludo. Thanks nckx for your help!
<nckx>degauss: You're welcome, but that's not what GIT-PREDICATE means (otherwise there would be little use for a dedicated procedure). It should work *anywhere* inside a git repository, and in my example it does.
<nckx>So yes, there is a bug, but I think you might be blaming an ‘incorrect’ usage that is actually a bug elsewhere.
<nckx>But regardless what it turns out to be: thanks for spotting & reporting it :)
<degauss>nckx, glad it was helpful! :)
<degauss>Gotta leave now, cheers!
<zamfofex>Hmm, maybe “KDE is currently missing” ought to be removed from <> now.
<andrea-bocelli>"Limitations (GNU Guix Reference Manual)"
<nckx>Oh, I guess so!
<nckx>The last version of KDE I used was 3, but I assume ‘KDE + Plasma = the KDE desktop’ now?
<zamfofex>As far as I know, it is now said that “KDE Plasma” is the *desktop environment* and “KDE” is the group of people behind it (and other software).
<nckx>Right. I'd written ‘KDE Plasma’ because that's what Wikipedia told me to do.
<zamfofex>“I’d like to interject for a moment. What you’re referring to as KDE is, in fact, KDE Plasma.” 😄
<nckx>‘The desktop environments in Guix use the Xorg display server by default’ — is that still true?
<nckx>The wall of absolute text of paragraph 5 needs to be subjugated as well:
<andrea-bocelli>"Desktop Services (GNU Guix Reference Manual)"
<nckx>…I guess not, re: Wayland. That's on other distroes.
<mirai>what's the right way to describe the following “snippet”: (define (foo a) #~(lambda (x) …))
<mirai>I've got "Return a G-Exp containing a procedure that returns a XML Catalog for Docbook-XSL in SXML representation."
<ulfvonbelow>that describes what calling the procedure defined by that snippet does, not the snippet itself, which would add a "define a procedure foo of one argument which when called with that argument will..." to the front of the description
<mirai>oh right, let me refine the question then: does the above work as a docstring for `foo' ?
<ulfvonbelow>aside from the fact that it doesn't mention what foo's sole argument is supposed to be or how it's used
<ulfvonbelow>but I imagine that's clearer in context
<jaeme>Is there a specific reason for why gnome is not upstream in Guix?
<jaeme>Does something change between 42.4 and future versions
<jaeme>GNOME 45 has released already
<jaeme>I'm just wondering if there's something blocking guix specifically for gnome
<zamfofex>“Contributions are welcome!” 😄
<zamfofex>More seriously: It just takes time to update packages and make sure they work.
<jaeme>Okay good
<zamfofex>And GNOME is fairly complicated.
<jaeme>I see
<ulfvonbelow>has something changed between 42.4 and future versions that's a big improvement?
<nckx>I don't know if there is anything blocking GNOME 44.2. <>.
<andrea-bocelli>"guix.git - GNU Guix and GNU Guix System"
<jaeme>Thank you, I'll check it out. :)
<lilyp>nckx: there's quite a number of packages still left to update; gnome-team is currently experimental
<lilyp>help is much welcome
<nckx>jaeme: ☝ u help yes da.