*rekado starts writing a cookbook section on containers
<pkill9>rekado: i dunno if you saw my message earlier, but i was wondering if you know what might be causing gnome on wayland to flicker the screen black, which I think you mentioned on one of the mailing lists
<brendyn>im trying to migrate to a new drive and use efi, but im getting this error with the root of the drive as the target
<brendyn>gnu/store/kdc2...-grub-efi-2.06/sbin/grub-install: error: /gnu/store/kdc2...-grub-efi-2.06/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory.
<brendyn>i notice the i386-pc directory doesnt exist, only x86_64-pc
<unmatched-paren>PSA: Framework laptop gen 12 Alder Lake integrated Xe GPU will *not* work with linux-libre
<singpolyma>git send-email will do the right thing for you. But with guix you need to send a cover letter email first to get the bug number then use send-email to that address
<johnabs[m]>brendyn: aww dang :( I'm a full time academic, any suggestions for alternatives? Maybe there's a good enough emacs package or something...
<brendyn>johnabs[m], you would always install if via another package manager like nix or flatpak if it is available. i just find when i do that i cant display non-latin fonts and xdg-open often doesnt work
<johnabs[m]>brendyn: There is a tarball, but I'm unsure how to write a guix package...maybe it'll be somewhat easy just following the install instructions on the website? Alternatively, there's a .deb file if it works. I don't really need non-latin fonts or xdg-open, as I only use it to ingest things from the web and organize them, the rest is accessed via emacs
<brendyn>johnabs[m], to learn you need to look at examples. i suggest starting by looking at what build-system the package will likely need
<johnabs[m]>brendyn: I'm unsure, but it looks like the tarball should "just work"? The install instructions just say "pop it in a bin folder somewhere and run it". I'll see what I can figure out, but I'm brand new to this whole guix thing, so fingers crossed
<johnabs[m]>I'll report back if I get it working or get stuck
<brendyn>johnabs[m], that means the tar is prebuilt, but usually such things dont work on guix due to the filesystem layout
<johnabs[m]>I figured as much, but give me a sec and I'll let you know what cosmic horror pollutes my terminal when I try to run it lmao
<johnabs[m]>Strangely, I'm getting a "no such file or directory" from bash when trying to run a file that I can both see with ls and open with vim...so bash is being a bit wacky it seems
<johnabs[m]>Hmm, I know this is built on firefox, maybe I can get the firefox package and try recycling it
<nckhexen>singpolyma: How's your AMD GPU performance without firmware?
<brendyn>johnabs[m], that no such file refers to the linker i think
<nckhexen>lechner: No reason beyond humans are weak and fallibre meat-hunks.
<singpolyma>nckhexen: for what kind of task? For desktop operation etc it's plenty fine. Obviously if you're gaming much or similar GPU load tasks you'll want the Accel to work but that's just like normal
<nckhexen>Oh, I dunno. I've had wildly different reports from (newish) users about how unusable an AMD is without firmware, and I don't have any myself.
<johnabs[m]>brendyn: It seems to break at the point of trying to access the zotero-bin file, which is strange. But before I continue, is there a way to get guix package to pull the .scm file but not build the package? I just checked the man page and don't see it as an option
<singpolyma>I have a beast CPU and discrete GPU so comparing that to a cheap AMD laptop it's not gonna be the same
<nckhexen>So… less that desktop cards are less firmware-crippled but that they limp better than some mobile chipsets run? Would that be a fair oversimplification?
<brendyn>johnabs[m], not sure what .scm file you are refering to
<johnabs[m]>Oh, I was trying to use the firefox.scm file from the nonguix channel to get some inspiration, since zotero is derived from firefox IIRC
<podiki[m]>in my experience (amd 6xxx series card) linux-libre will boto with nomodeset but only gave basic support (1024x768 res?), though I did not try more, I think maybe that was also due to old mesa at the time
<nckhexen>The only interpretation I can find for ‘pull but not build’ an .scm file is ‘guix build -d -f …’. But that's a wild guess.
<johnabs[m]>To use the plugin, you need the app, which is basically a firefox re-write
<nckhexen>Even if we offer a work-around it'll probably be manual (selecting the ‘oops I bought an AMD/modern computer/non-2010-era ThinkPad’ GRUB menu option) if it needs nomodeset from the start. And then the resulting system will be… unideal.
<nckhexen>Ah you typed the thing whilst I was typing also the thing never mind.
<podiki[m]>yeah, it is probably indicative of poor hardware support
<podiki[m]>I would want to make some live images (or point to how you can do that with guix system) for someone to try as an easy ytest
<nckhexen>It's pretty easy, no? Or what are you missing?
<nckhexen>johnabs[m]: The ‘plugin’… comes with a huge proprietary (in the literal sense) other thing that's the only thing it'll plug into? That's nice.
<podiki[m]>yeah, it has the info you need and sorta says it if I remember, but not sure someone looking to try guix would put it together
<podiki[m]>plus there's already the system config templates that will work as a configuration to try without changes
<johnabs[m]><nckhexen> "johnabs: The ‘plugin’… comes..." <- Why is it proprietary? It's the best current option that is open source, and uses the GNU AFFERO general license
<nckhexen>Right. Maybe a specific ‘live’ configuration could be added? If the existing .tmpls aren't a good fit.
<nckhexen>Proprietary != non-free. I said nothing about licencing.
<nckhexen>lechner: Seems so, yeah. curl | gunzip has no issue with it in the same (Guix System) terminal that prints â, so it's not a system locale issue.
<nckhexen>* that prints â when running ‘guix import’.
<podiki[m]>I think it is a cool feature of guix that could get more attention: easy live images, from existing system configuration or as a way of making one to install later
<nckhexen>Yes. Whilst there are rough edges, making a live (or vm, or…) system is *mostly* the case of typing one guix command and, oh, oh I guess that's it, there it is. Often not what people expect.
<nckhexen>It's not perfect but it's actually quite remarkable when you learn how it's done elsewhere.
*nckhexen was recently told to ‘just’ make an Arch live ISO. Gave up; used Guix.
<johnabs[m]>Okay, so I still don't understand why it's proprietary? The software stores the files in an easily accessible format that's readable by emacs, for example, and other editors, has a freedom respecting license. The only possible complaint is that the plugin slots into the app, and that's really just a convenience. Also, according to most definitions, proprietary software is directly in contract to free sotware, so I'm not getting the
<brendyn>it feel embarrassed that the only way i know how to reply to people on the list is to fish through the mbox archives files until i find them and copy-paste their email out
<lechner>Hi, I'm having a super tough time figuring out the right Rust prerequisites for sequoia-pgp. I thought it was supposed to be super easy. Does our Rust setup introduces fuzz around the version strings to limit the number of releases we distribute?
<brendyn>how would i turn "C-u M-x debbugs-gnu RET RET guix-patches RET n y" in to a single function in emacs?
<lechner>Hi, why would this not find version 2.3, please? guix import go firstname.lastname@example.org
<FlaminWalrus>Anyone know how to tell GHC to find Guix-installed Haskell libraries correctly? I'm getting "ld: cannot find -lHSsafe-0.3.19-Bkx7Obebf6Y5ev72SyoL0z" et. al. when trying to build a very basic program. I do have gcc-toolchain installed, but for whatever reason, it seems the filtering doesn't make it on to GHC's invocation.
<lechner>unmatched-paren: thanks! i tried that but guix import: error: version v2.3 of github.com/rfjakob/gocryptfs is not available hint: Pick one of the following available versions: 1.8.0 1.4.2 0.7.2 1.4.3 1.1.1 1.7.1 1.4.1 0.5.1 1.4.4 1.2.1 0.3.1 0.7.1 1.6.1.
<sneek>antipode, nckhexen says: We do, through litharge, which is a bot (oh! vile bots!) that remembers to unban the person. Unlike, say, me. That's as high-tech as it gets. That and prodding sneek's owner in #guile.
<itd_>(To clarify: the missing file is "H-H1_GWOSC_4KHZ_R1-1126257415-4096.txt".)
<FlaminWalrus>itd_: well, looks like my Haskell needs some work; it started thrashing and wouldn't stop for anything but SIGKILL. In any case, use of "ghc" rather than "runghc" was the issue, thanks for the help.
<itd_>lechner: IIRC, the importer asks https://pkg.go.dev/github.com/rfjakob/gocryptfs ; notice, at the top of the page: "The highest tagged major version is v2.". And indeed, "guix import go email@example.com" finds different versions, alas, not 2.3 (for reasons I do not know, it is not present on go.dev).
<itd_>FlaminWalrus: Glad it compiles. :) (#haskell isn't that far, maybe they can help out)
<Kabouik>Hey unmatched-paren, thanks for the review of cobib! May I ask you a simple workflow question for v2?
<Kabouik>Currently I have two commits in my branch for cobib, the first one is for the dep, and the second for cobib. I know how I could rebase to the last commit (cobib) and avoid adding a third one, but I don't know how to do add the requested changes within the first commit, so that in the end I keep only two clean commits for v2.
<Kabouik>For my previous packages I simply restarted my changes from scratch every time, but that's not a sustainable workflow in my opinion.
<Kabouik>I would like to add the changes you requested for the dependency and have them under the first commit, and same for the changes in cobib under the second commit. If I had only one existing commit I would use rebase, but don't know if I can do that for commits earlier than the last.
<unmatched-paren>hnhx[m]: so, what you'll want is two sexps in the file: (use-modules) and (package)
<zpiro>unmatched-paren: console is different from a terminal! the latter doesn't come with guarantees of access to kernel, a console does. A terminal traces itself to time shared system, a console doesn't require an interrupt, it is one.
<zpiro>unmatched-paren: it is more, than serial console is the purest form, and your frame buffer tty is less so. and you can run xterm, generally speaking that can be set up, screen certainly support serial consoles.
<zpiro>but, at the stage of, "I can boot the board over console" -- yes, you have a real console.
<unmatched-paren>i see. anyway: hnhx[m]: so what you'll want to do is inherit your own package from the existing dwm package
<unmatched-paren>because that's a thing you can do with guix records: (package (inherit dwm))
<unmatched-paren>now you'll need to give it a name and version: (package ... (name "my-dwm") (version (package-version dwm))
<Kabouik>Woops I forgot a change in my v3 unmatched-paren, sorry. Working on it.
<antipode>Though for future people updating the package, I recommend adding the PGP fingerprint in a comment (for TOFU)
<zpiro>a terminal wait to be served, a console have real cpu cycle interrupts. Both can be physical, and for terminal, one expected physically attachement involved in the sentiment, but it can be remote. such that it is a matter of knowing degrees of separation, as a terminal running a console on your little machine over usb serial console can confuse things.
<antipode>'(guix)Invoking guix refresh' has some information on upstream keys
<zpiro>across the bored, "I have console", implies at least the level of the terminal prvoded to access the bios to the server, mainframe or whatever it is.
<lechner>itd_ antipode: thanks for hints regarding the imported. as for go.dev, i'll contact upstream
<zpiro>"console" doesn't require that you have ability to cut power to the system, but often it does. anyways, it falls off into trouble. and the very least the most important part of the system you can have access to.
<zpiro>anyways, difference between console and terminal in a fuzzy and muddled world :) you are welcome.
<zpiro>but be warned, and I am done with a small rant over the conceptual difference, the difference may matter more in politics and power hierachies over questions and matters you want a personal and emotional distance from.
<zpiro>unmatched-paren: to trail it off, common convention is that console is the highest priviledged interface to the machine, and generally considered to be prior to peripherals like a graphics card.
<unmatched-paren>and then, since we can't assume that dwm hasn't itself modified the default phases, we can't override the phases entirely, so we modify our ``phases'' variable bound by ``substitute-keyword-arguments''
<unmatched-paren>instead of modifying ``%standard-phases'', which contains the default phases for the build system in use
<unmatched-paren>and inside ``modify-phases'', we add a new ``patch-config-h'' phase after ``unpack'', which is simply a lambda that ignores its arguments
<unmatched-paren>although this might lead to a hash mismatch, in which case add a ``sha256'' field to ``origin'' and set it to ``(base32 "HASH")'', where HASH is the ``actual hash: '' given in the error
<antipode>unmatched-paren: The hash is computed over the unmodified source code, so no hash mismatch
<antipode>(for the same reasons no hash mismatch is created when you modify 'arguments' -- if you add a snippet or patch, a new (non-fixed-output) derivation is made that takes the original source as input)
<unmatched-paren>hnhx[m]: you could also just use ``git diff'' to turn your config.h edits into a patch
<kraai>Hi. I've packaged doctl 1.73.0. When I try to package the latest version, 1.83.0, it fails, I think because it requires a Go 1.18 or 1.19. Is there a way to build it using one of those versions?
<unmatched-paren>kraai: the ``go'' variable is defined as equivalent to ``go-1.17'', as changing it would trigger mass rebuilds, but we do have a ``go-1.19'' package
<dthompson>unmatched-paren: if that's true, it's a bug because wayland and wayland-protocols are inputs to the sdl2 package.
<sneek>Welcome back dthompson, you have 5 messages!
<sneek>dthompson, ArneBab says: When using chickadee play, I got chickadee/image/png.scm:354:31: ERROR:
<sneek>dthompson, ArneBab says: 1. &message: "PNG images using color palettes are not supported" at In chickadee/graphics/texture.scm: 404:20 2 (call-with-loaded-image "walking_dragon-ari.png" #f #t #)
<sneek>dthompson, ArneBab says: The way I found to start a script with the lowest possible latency is to define a module and then run it with guile -L . -e '(module name)'
<sneek>dthompson, ArneBab says: Please tell me once you have a new chickadee release so I can link it on the wisp page!
<kitzman>funny. i've had issues in the past with gnutls having invalid opcodes. first on amd64 hyperv under qemu. changing the processor fixed it. now on gentoo under xen as dom0. tried recompiling with different flags, no success. however, running a daemon i have in the guix store works with no issues.
<dthompson>when wayland-shared is enabled, it adds a video mode "wayland(dynamic)" which I think means that it will dlopen wayland. with wayland-shared disabled, it adds the wayland libraies to LDFLAGS. so without actually running this build, it seems that were are opting to link against the wayland libs.
<ArneBab>unmatched-paren: I don’t consider it ironic — it’s just the consequence of following their principle
<ArneBab>unmatched-paren: the fun part is that both for drew and me Python 3 is what caused that way of thinking. I lost a tool for several years that I did not have the time to finish fixing, because it was not essential enough to warrant being put first. I expect the same to happen when wayland becomes effectively mandatory.
<ArneBab>When that happened, I just stopped doing the things that needed it. And when pulseaudio broke audacity and interaction with my external sound card, I stopped recording music for several years.
<unmatched-paren>Hmm, apparently I need to recompile the kernel with HID_MULTITOUCH=m to get my touchpad working right...
<hnhx[m]>i mean ye i get that xorg is abandonware and whatnot but its still better than running nonfree stuff
<lechner>Hi, I am trying to package Gocryptfs. Why would the golang build system say package github.com/jacobsa/crypto: no Go files in /tmp/... for one of the included source packages, please? https://paste.debian.net/1256472/
<djeis>I'm running into a rather strange issue with guix home- it's complaining I have two different versions of a package in my home profile, one I'm pulling in explicitly and the other propagated from a package, but I cannot identify difference between those versions of the package would be.
<hnhx[m]><unmatched-paren> "i just use a blobby kernel" <- also does guix have optional non free repos? or are these repos that you use 3rd party?
<djeis>The package is password-store, I'm pulling it in explicitly using specification->package in the packages list of the home config and I have a home service putting emacs-password-store into the profile elsewhere. guix home tells me they're two different store locations, but when I try to guix build password-store the one I get matches the one home says propagated from emacs-password-store (not the unlabeled one which, presumably, is the one coming from
<djeis>Yeah, makes sense. I suspect that'd be nontrivial though, since you'd have a heck of a time identifying which uses of "pass" are the binary and which are the prefix in front of every function in the elisp.
<djeis>And you couldn't do that as a diff, right? Since the thing you're replacing it with is a store path.
<unmatched-paren>surely you could just replace every "pass" in double-quotes, though?
<djeis>As for grafting weirdness... That's the really odd bit, when I ran guix build password-store it actually had to do the grafting right then. But the source path for the graft was a third path entirely.
*unmatched-paren has literally just opened a new wip-emacs-password-store-no-propagated
<unmatched-paren>Try looking at the ungoogled-chromium package, I believe it requires clang to build.
<djeis>And (for my own sanity, if nothing else) I used guix repl both to build the result of calling specification->package and to extract the input to emacs-password-store and build that- both matched the guix build password-store result and what guix home said was propogated from emacs-password-store...
<djeis>I have no idea where this other version of the package is coming from.
<djeis>The recommendation from guix home was "upgrade both password-store and emacs-password-store", but I feel like that's actually the profile machinery where upgrading individual packages is a thing... In this case I'm pretty sure all of the references already are to the latest versions of the package defs...
<djeis>I don't think the guix home profile is, like, stateful in the same way the plain user profile is, right?
<djeis>Clearly guix home is getting this package from somewhere, but... the only thing that would've been pulling it in before is the (map specification->package (list ... "password-store" ...)) in my home config.
<djeis>It's something to do with package transformations all right. My emacs packages optionally go through a package transform which replaces emacs-minimal with my custom emacs build, so I get native comp. I just turned that off for emacs-password-store, and now it's propagated password-store isn't giving trouble anymore.
<djeis>But... password-store itself doesn't depend on emacs-minimal. So... my only explanation is, I was blocking some package transform that is being applied to the other packages in my profile?
<djeis>That would explain why the path in my guix home profile doesn't match the one from guix build.
<djeis>So... do package transforms not stack? And... why would the other packages in my guix home be getting transformed...
<unmatched-paren>Now to deal with the others in the surprisingly large set of pass-related emacs packages...
<djeis>The other headache is that emacs-password-store has elisp deps in common with another one of my emacs packages that I would like native-comp'd, so if I turn off comp for emacs-password-store I get a similar "multiple package versions" error but for the propogated elisp deps... So I can't reallu just turn it off.
<lilyp>djeis: the trick would be to only apply native-comp to the inputs of password-store, but not password-store itself
<lilyp>that's a slightly more complex transformation, though, which isn't easily supported by the CLI
<lilyp>in other words, you'd have to write Scheme code
<djeis>Yeah, but I'm not doing any of this with the CLI anyway and I've got plenty of scheme machinery in this already.
<djeis>It might not be a bad idea to make my emacs packaging home service a little cleverer about which packages need native comp and which don't.
<djeis>Plus the problem seems to just be that I'm applying a transform to the password-store dep at all, and that... I guess blocking? blocking some outer transform happening to the other packages in my home profile.
<djeis>Okay, so... my guix home profile has a version of password-store which isn't just the result of guix build password-store, and I don't know why. I'm grabbing it with specification->package, and nothing in my guix home config seems to indicate a package transformation (apart from what I'm doing with emacs packages).
<djeis>Does guix home implicitly apply any package transforms?
<djeis>So, I've managed to reproduce the guix home profile having a different password-store even with just a home config that's empty but for putting password-store in the packages list. I'm now testing with all of my channels off and a recent pull of guix master.
<unmatched-paren>Hmm, I should make another attempt at supporting application of patches to Guix channels...
<djeis>But yeah, I have https://paste.debian.net/1256477/ as a minimal guix home config. I run it in guix home container and "ls -al .guix-home/profile/bin/pass" to see pass' store path and compare that with just running guix build password-store.
<unmatched-paren>I think i'll give it a shot, and if it's rejected, then, well, I tried :)
<unmatched-paren>Oh, lovely, there's already a guile-email library that can read mboxen :)
<Kabouik>How can I know which package provides libwayland-client.so.0?
<unmatched-paren>Kabouik: I believe you can look it up on the Guix Data Service somewhere... But it's in ``wayland''.
<Kabouik>You know it is in `wayland` just because you are used to it, but is there a way to search which guix packages provides a file? Like for eopkg file manager, there is a search-file option for instance
<Kabouik>(But thanks, knowing it is in Wayland will help already, the reason I missed it is because an appimage is complaining about it: I have Wayland installed, but perhaps not in the fhs thingie that pkill9 cooked)
<unmatched-paren>There's no such command right now, but it'd likely be possible to write one.
<unmatched-paren>Kabouik: There's a third-party Nix extension that implements it, so it should be possible with Guix.
<unmatched-paren>sneek: later tell cbaines: sorry for the long delay, but I've finally sent a rebased and slightly amended version of the greetd-wlgreet-sway-session patch to its issue :) Thanks for reviewing it!
<djeis>If I guix shell password-store and look at $GUIX_ENVIRONMENT I get one password-store, if I guix shell password-store fontconfig and look at $GUIX_ENVIRONMENT/bin I have a different path to the pass binary.
<djeis>And guix home implicitly puts fontconfig on your profile.
<unmatched-paren>If I typed exactly what I'm thinking about that you'd just see a whole flood of "disbelief" ellipsises.
<djeis>I don't really understand it myself, it doesn't make any sense to me.
<jpoiret>are you sure you're using exactly the above command to get the canonical path?
<jpoiret>if you are, and you're still getting mismatched paths there's definitely an issue
<djeis>Allow me to be a touch more rigorous, one second.
<djeis>jpoiret: So, I can't quite seem to reproduce this with guix shell all of a sudden, and I don't really know why... But I have a scheme expressions which build one profile that has both password-store and fontconfig and the other which only has password-store and sure enough they disagree on the cannonical path to the pass script
<jpoiret>djeis: well, at least i get the same output as you do
<podiki[m]>something something fontconfig has grafts.....?
<djeis>The weirdest thing is how I discovered this- I applied a package transform to emacs-password-store and put that in my home config profile, and all of a sudden guix home complains that I have two different versions of password-store in the profile.
<djeis>emacs-password-store propagates the password-store dep, at least until the patch for that is merged. But, the version of password-store it was propagating to the profile is the one I get from guix build.
<djeis>At least, it was until I stopped applying the transform.
<jpoiret>so what I'm thinking is that the grafts caching somehow influences the order in which grafts are performed, and so building two packages with the same store connection will lead to this inconsistency above
<jpoiret>but it's just a hunch for now, I don't have anything to base it on
<old>nckhexen: Right. Is this the intended behavior?
<jpoiret>I've isolated the issue: `(with-store store (run-with-store store (package->derivation (specification->package "password-store"))))` doesn't give the same derivation as `(with-store store (run-with-store store (mbegin %store-monad (package->derivation (specification->package "fontconfig")) (package->derivation (specification->package