<tangonov>nckx: Just a quick follow-up. If I disable the tests, the builds for the dependencies I mentioned before work out fine. I don't know what the problem is with this particular set of tests for the package in question, but I have forwarded my logs onto their git repository as an issue.
<cbaines>maximed_, regarding the versions of efivar, you want to use the "Latest processed revision" link on the relevant branch page, then search for the package
<jgibbons[m]>Only 21 chapters planned so far. I've never been good at estimation.
***Xenguy_ is now known as Xenguy
<apteryx>rekado_: what are the specs for the SAN device?
<jgibbons[m]>apteryx: --privileged works on guix. I suspect it's a kernel issue on the other system.
<tangonov[m]>There are btrfs misadventures? I'm running btrfs, I hope it has a nice adventure
<tangonov[m]>How granular should patch submissions be? I have a handful of package changes that are related to one package addition, but for various reasons, collateral changes needed to be made. Mostly version compatibility stuff.
<tangonov[m]>Should I break them up into smaller, focused commits?
<nckx>tangonov[m]: The mis- were not primarily due to btrfs. Now only adventures remain.
<nckx>tangonov[m]: If you mean you upgraded packages A, B, C in order to upgrade D, then they sound like separate patches. Otherwise, too vague to say.
<nckx>General rules: patches should do only one logical thing, and nothing should be broken between patches that wasn't broken before.
<tangonov[m]>More like I had to add packages A B C which depended on packages D E F but package E was too old, but package G can't have E at a version so high, so I had to create a variation of E just so I could add the main package I was concerned with: H
<ulfvonbe`>also with -name if you just want to see if a substring matches you'd do it like: -name '*email*' -o -name '*git*'. And if you want to check only for a substring and do so case-insensitively, replace -name with -iname.
<rekado_>jgibbons[m]: if you can figure it out it may be better to work around it in Guix instead of writing about a workaround in a book.
<PotentialUser-11>unmatched-paren: Thanks, Iam trying to package FreeTube. As I see there is no way to install yarn correctly locally. I've run build using scm and last error is 'npm ERR! code ENOTCACHED' so it is hard for npm to run offline and I even don't how to install yarn using scm. Maybe someone from community could help me.
<unmatched-paren>PotentialUser-11: electron in particular has been discussed before. maybe try looking through email@example.com or firstname.lastname@example.org or something?
<PotentialUser-11>unmatched-paren:Thanks I've searched through these mail lists. I've discovered: node-build-system is work in progress, but it can build as long as
<gabber>i found an issue and have created a fix (which adds a new package and propagates that package to the build of another one). should i first open an issue (with the patches attached) or should i only mention the issue when i send the patches directly?
***jess is now known as meow
<kaelyn>Hi guix, is there a way to add grub menu entries that aren't for a linux or multiboot kernel (or other grub commands/options) to the bootloader of an operating-system config?
***chexum_ is now known as chexum
<tex_milan>hello, downloaded SweetHome3d.jar, trying to run it with java -jar and got this error: .... Caused by: java.lang.UnsatisfiedLinkError: Can't load library: /home/milan/Downloads/natives/linux-amd64/libnativewindow_awt.so Any idea what to do with it?
<nckx>kaelyn: …‘menu entries that aren't for […or] other grub commands/options’?
<nckx>gabber: Just send the patches to guix-patches, describing the issue they fix.
<kaelyn>nckx: currently a menu-entry is either for "linux" or "multiboot" but there's no way to specify other grub commands in a menu entry like "set root=(hdX,gptY)" or "chainloader"
<nckx>tex_milan: Hm, I can't get rid of that ‘…device null’ error even with MESA_GL_VERSION_OVERRIDE=2.1 set and java -Dsun.java2d.opengl=true :-/
<nckx>tex_milan: Let me know if you see what I'm missing or have any other ideas. I might give it another go later. I unironically have a nostalgic soft spot for consumer home-design CAD products from the early 2000s, believe it or not.
<nckx>On a lark I added mesa and it went away (or I'm sinking deeper into library mismatch hell, who's to say). Now *this* is an error worthy of Java: Caused by: java.lang.IllegalAccessException: class javax.media.j3d.JoglPipeline cannot access class sun.awt.X11GraphicsDevice (in module java.desktop) because module java.desktop does not export sun.awt to unnamed module @5a2e4553
<Haider>I have been having this issue ever since I have been using Guix, which is clangd (part of my current Emacs LSP setup) gets mad on the iostream library and spits out: "clang: In included file: expected ')' " and then "clang: Too many errors emitted, stopping now". This is iostream from the GCC 12.1.0 package.
<unmatched-paren>Haider: have you tried using ccls? i don't know the cause of your issue, but maybe you'll have better luck with it. i'm using it with neovim and it works fine
<jpoiret>but you're installing a whole system, so you may want to use all of guix system's features
<unmatched-paren>i would set that all up after the initial installation, but okay, i see the point.
<jpoiret>think about this other use-case: you're a Guix expert, you've managed 10k machines with Guix on it, you've contributed millions of packages, then you need to install Guix through the fixed release because for some reason the latest installer doesn't work
<jpoiret>although you could say two things about that: 1) the local `info` manual should be exactly up to date 2) you could guix pull before installing
<nckx>Yeah, I'm not defending the status quo at all, it's horrible that the ancient manual doesn't even have a ‘yo this is ancient’ banner, which is why it's doubly bad that the URL isn't explicit about it either.
<nckx><nckx> On a lark I added mesa and it went away (or I'm sinking deeper into library mismatch hell, who's to say). Now *this* is an error worthy of Java: Caused by: java.lang.IllegalAccessException: class javax.media.j3d.JoglPipeline cannot access class sun.awt.X11GraphicsDevice (in module java.desktop) because module java.desktop does not export sun.awt to unnamed module @5a2e4553
<nckx>I tried a few different openjdk versions (up to icedtea@2, IIRC, when it broke for other reasons) but no difference.
<nckx>tex_milan: You could also try help-guix at gnu dot org. I hesitate to say bug-guix because it's not a Guix package, but OTOH it is Guix's JDK not doing something that Nix's apparently can… I'll let you choose.
<elb[m]>anyway, I just switched my container startups to shell
<nckx>So ‘guix environment foo bar biz’ → ‘guix shell -D foo -D bar -D biz’.
<elb[m]>my appreciation for this feature remains, whatever it is called ;-)
<elb[m]>(in particular it seems to have MUCH higher isolation than the other methods of trivially starting a command in a namespace that I have previously tried, and is MUCH easier than the similarly thoroughly isolated methods)
<nckx>I'll miss the (IMO superior) environment name, but the behaviour of shell is an improvement.
<elb[m]>yeah, shell seems a little strange for the use case I'm using, since the environment literally doesn't even contain a shell ;-)
<nckx>Although I guess shell being a kind of synonym for container is a very GNU kind of wit.
<elb[m]>(well, that may not be true, I'd have to walk the profile, but I'm certainly not running one)
<nckx>(I can think of many things but don't want to influence your story.)
<elb[m]>although I'm not sure I have specific advice on how to make it less so, in particular, it takes a little bit of reading and playing to wrap one's head around how profiles, manifests, etc. can actually be best used, and what the implications are of the "root" guix versus the "user" guix profiles and environments, etc.
<elb[m]>for example, I've basically landed on entirely ignoring the fact that any root guix environment exists at all, because why would I care (except insomuch as it has to be there to give me a guix daemon and friends), and actively maintaining two guix profiles in my home directory, only one of which gets much air time in the documentation
<elb[m]>on a foreign distro, `guix` is probably /usr/local/bin/guix, which is "root's" guix
<elb[m]>but I don't want that guix unless I want to mess with updating as root, which I don't
<elb[m]>so the guix I really want is ~/.config/guix/current/bin/guix
<nckx>< I've basically landed on entirely ignoring the fact that any root guix environment exists at all> is correct by the way. Most people should never use it.
<elb[m]>so my guix init routine in my shell .profile sucks in that, then sucks in ~/.guix-profile
<elb[m]>which gets me "my" guix that I can `guix pull` easily
<nckx>Foreign distros complicate that a bit but your intuition was better than that of some others (through no fault of their own).
<elb[m]>I'm not sure I would call it "intuition", so much as thirty years of experience with Unix systems in general plus a year or two of using guix and being annoyed, then sitting down and saying "now how SHOULD I be doing this?"
<elb[m]>and yeah -- I'm sure some of this is entirely because foreign distro
<elb[m]>so anyway, what I now have as my "normal" config on every machine I use is 2 + n guix profiles: ~/.config/guix/current, ~/.guix-profile, and several profiles in ~/.guix-local/
<elb[m]>the profiles in ~/.guix-local are "named" in a file in ~/.guix-local, have manifests, and are used to a) install a bunch of stuff I know I want everywhere (like Emacs), b) track container and such profiles to give them a gc root, and c) let me isolate particular tasks for the local machine with known manifests
<elb[m]>then I have a script in ~/.guix-local that grovels through all this crap and updates everything after it `guix pull`'s ~/.config/guix/current
<elb[m]>so that's my brain dump on the matter, dunno if any of that is helpful for you, but it's worth what you paid for it or your money back :-)
*nckx reminds self that when you see a bizarre domain name that can't be anything but spam, ‘HAM radio enthusiast’ is always an alternative.
<elb[m]>it took me a fair amount of documentation reading an dplaying to figure all of that out
<elb[m]>I think the things that took me time to figure out that I find "important" are: 1) don't mess with root guix, 2) add the guix current config to your shell environment, 3) create some manifests so you don't have to grub around in your profile to spin up a new install, and 4) updating everything is ... a multi-step process
<elb[m]>also I do wonder how that jives with what you "expected" ;-)
<nckx>Erm. Well. Ideally we'd aim for user experiences that don't contain the substring ‘grovel through all this crap’.