<apteryx>has anyone seen these kind of errors when offloading? guix offload: error: corrupt input while restoring '/gnu/store/guix-u9QjUv/lib/ruby/vendor_ruby/doc/chunky_png-1.3.12/ri/ChunkyPNG/Canvas/Adam7Interlacing/adam7_extract_pass-i.ri' from #<input: string 7f6573f86230>
<lfam>After you fix this, it will be helpful if you can report the failure by sending a message to <email@example.com> with a description of the problem and the contents of the log of the failed build. The command that fails will tell you where to find the log if something goes wrong
<apteryx>seth: could you please paste the linux-util build error you're seeing?
<lfam>I'm guessing it's the issue described in <https://issues.guix.gnu.org/issue/41384>. I don't know exactly what upstream kernel version "5.4.0-7634-generic" corresponds to, but it's probably within the range of "5.4.36 through 5.4.41" described in that bug report
*terpri fiddling with wrapping AppImages inside flatpaks to get them to run without huge amounts of package-specific hackery
<terpri>matryoshka containers, containers all the way down
<seth>lfam: I should have looked at `uname` sooner. Thank you. I don't want to downgrade my kernel, but I can always run guix in a VM.
<terpri>has anyone gotten pcie passthrough working under guix? that might be easier tbh
<apteryx>seth: if downgrading your kernel is not an option, you may be able to find a newer kernel for your Ubuntu
<seth>I think I will probably just give up on this particular machine. I don't want to change my kernel because I am not the only person who uses this computer. I will probably just experiment with Guix in a VM or another computer.
<seth>If I broke this computer by messing up the kernel, the consequences would be bad.
<seth>I will submit that bug report when I get a chance.
<lfam>I bet it will work but... yeah. A lot to read!
<terpri>tl;dr i'm trying to run a proprietary game development system (one of the big ones) as a prerequisite for porting a ~200-component game development framework to godot, with the core (a *large* fraction) to be released under a free license (though i need to double-check that $client really understands what makes a license free or non-free; she knows now that libre != gratis and libre != source-available, at least)
<terpri>the program is "supported" under gnu/linux but really, really doesn't want to run on a non-FHS system; i bit the bullet and packaged the minimal editor program for guix, instead of packaging their many-moving-parts launcher/updater/project manager/license manager/etc AppImage thingy
<terpri>only to hit a brick wall with license management garbage, renewing my visceral hatred for digital restrictions management
<terpri>well, goodbye w*ndows dual-boot, guix and my home dir need that terabyte
<terpri>i still might try the wrapping-appimages-in-flatpaks experiment, since some not-yet-packaged free programs distribute appimages
<terpri>i've got spare gpus, making it work under guix should just be a small matter of programming
***apteryx is now known as Guest8137
***apteryx_ is now known as apteryx
<abralek>Hi Guix, I am trying to package pigeonhole for dovecot to make sieve works, but the problem I am having is that pigeonhole also provide new settings, which doveconf has to find in moduledir/settings/ directory in particular: libmanagesieve_login_settings.so libmanagesieve_settings.so and few more.
<abralek>And if I define some settings, doveconf crashes with fatal error.
<abralek>Are there any examples/packages to solve such a use case?
<abralek>One solution would be just to bundle this in to one big package, but then I am not sure how I could build dovecot and then one of it's inputs with modified output
<nckx>jlicht: You could modify Guix to call tar with ‘--absolute-names’, but why? Such archives are at least unexpected (like tarbombs) and could be a security risk.
<nckx>(I'm just parroting rationales for the latter, you should always inspect strange tarballs anyway.)
<jlicht>nckx: because skopeo is one of the few tools that allow me to share guix-built docker images without needing docker, and it cannot deal with extracting "manifest.json" from a tarball if it actually located at "./manifest.json" :/
<jlicht>and since skopeo is a Golang project, that implies patching the upstream, hoping that at some point skopeo updates their vendored copy etc etc...
<jlicht>right now I'm untarring the guix packs and repacking them before I can upload them. It works, but the dream is of course to `skopeo copy docker-archive:$(guix pack -f docker hello) docker:amazing-docker-repo-of-jelle:hello'
<nckx>I think we should just call tar with -P in (only) the Docker case. If that's all that Skopeo's ever encountered and tested.
<nckx>jlicht: So you're repacking them with -P? Or is more needed?
<jlicht> `tar xf ../$OUTFILE; tar cf ../$OUTFILE *' in my hacky shell script
<jlicht>nckx: although that probably has some nasty implications if I were to do that to random tarballs :O
<jlicht>yeah, that is also what I ran into. I think the correct approach is to patch the peek-inside-the-tar library that skopeo uses to understand (and subsequently ignore) "./" prefixes
<nckx>I thought you wanted /gnu etc. (instead of ./gnu). I don't know the tar option to do what you want, if there is one, without specifying each file on the tar command line… It also feels nasty as you said.
<nckx>This is just what GNU tar does when you pass it ‘.’, it's not really ‘adding’ anything.
<nckx>(The ‘.’ I thought you meant, for ‘tar cf foo /etc’, is entirely synthetic.)
<nckx>jlicht: I do agree that the right fix is in Skopeo, but who knows who's stuck with an old version for how long. Do you know your way around Docker? We should probably just invoke tar however it does, warts & all.
<jlicht>I think docker uses a golang implementation of that all, but I already found the bug I think :-). They had a missing `path.Clean' somewhere. I'll report it upstream for now
<nckx>Yay, I ‘know’ just enough Russian to read that. Thanks. I'm very new to this waystuff. Is the ‘wm’ (compositor?) really the right place to configure this? Is this something Guix should handle, or precisely not try to?
<guix-vits>IDK. Doing this in sys config is too broad. Some sort of per-user configs?
<nckx>‘The preferred way to configure the keyboard is via the configuration file, see sway-input(5).’ — man sway
<nckx>It didn't occur to me that sway would handle this or I would've RTFM.
<nckx>guix-vits: It should be at least configurable for the SDDM password prompt.
<nckx>Typing ●●●s in an unfamiliar layout is mucho unfun.
<nckx>There's a dropdown that defaults to ‘us’ and you can choose between ‘us’.
<str1ngs>guix-vits: I need to follow up on that as well. it's a limitation with g-golf
<guix-vits>str1ngs: TBH, the tool wl-copy (same as xclip) glitches for me sometimes too. IDK why, and what affect this.
<str1ngs>yay clipboard with g-golf and Wayland has issue. I'll have to switch to sway for awhile to have a look at this. sorry for the Wayland neglect
<guix-vits>str1ngs: I can get scaling with those GDK variables, but the result is either slightly blurry, or i tired my eyes today; not sure. But that is better, as those possibly affect the other gapplications. Should be some mechanics to works with fixed-width fonts..
<bavier[m]1>leoprikler: I see your mineclone patch. I'll give it a try!
<brettgilio>Conversation I just had... My mom, a healthcare software company executive, on a conference call with the quality assurance people: We are reviewing employee feedback surveys, and somebody said "I'm a software engineer, and I shouldn't have to worry about patient safety in my job." Isn't that ridiculous? Me: No, they are right. We should have effectful and mathematically compositional proven type safe languages with good compilers and deterministic
<brettgilio>systems that won't let you do stupid stuff that might kill people. My mom: I don't think that's what they meant... Me: Yeah, probably not, but they aren't //wrong//. They just aren't right either. My mom: they should get a different job Me: yeah. They should go into theorem proving and pure type systems and stuff. My mom: *visibly annoyed*
<nckx>brettgilio: I admit to being naiv^W^Wreading it as positive/hopeful initially, but it's a needlessly ambiguous way to phrase it. Assuming you're not paraphrasing.
<apteryx>brettgilio: in my place, to have "Engineer" in your title is restricted to a professional association whose main purpose is to ensure public safety ;-)
<apteryx>restricters to members of a professional association*
<nckx>You can run a Web server (either a real one or one using canned responses) but it's overthinking it. Just disable the test. 🙂
<nckx>If a test tests whether gitlab.gnome.org is up, it might not be a great test.
<mroh>I've updated xfce to 4.15. How should I send the patches? A lot of small ones (for lots of pckgs) or is it ok to send one for everything?
<kamil_>I have a few questions. For the sake of clarity, let's assume that I have just issued '$ guix pull', but have forgotten to issue '$ guix system reconfigure' within the last two weeks. Will it be considered a bad practise to install a package for my user by issuing '$ guix install <package>' now? Will that package use now outdated libraries?
<brettgilio>kamil_: not bad practice unless you want some outdated software
<brettgilio>I keep my system purposefully a few weeks behind guix master, and use the time machine and inferiors for pieces I want that are newer than my machine
<brettgilio>I'll especially use inferiors to get CVE fixes and relevant patches
<efraim>I would have assumed 4.15 was a dev release