<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 <maximed_>cbaines: For navigatability and some additional discoverability, I'd recommend putting a link from the revision-specific package page to the history page of that package or something <maximed_>Though nice that's it's already possible <cbaines>maximed_, there's the possibility that one revision (commit) sits on multiple branches, so that would need to be taken in to account, but I think it would be possible <cbaines>not something I'm going to get around to adding soon though, it shouldn't be that difficult though <maximed_>silly substitution of the day: (("\\bnum_days\\(\\)") "num_days()") <unmatched-paren>and you can reply to any thread if you're subscribed with a Real Mail Client :) <silicius[m]>It's kinda a mess and I'm just using a roundcube instance atm. I got the mails and I think I need the -in-reply-to header, but I can't see if its being used by roundcube <unmatched-paren>tangonov: one that allows you to manually edit headers and quotations, and uses plain text by default :P <unmatched-paren>although aerc isn't available from guix yet, though i've sent a patch <silicius[m]>Ok, I got it. After saving the reply as a draft and then inspecting its headers I can see it uses the in-reply-to header <tangonov>Ah, I think I have a real client with Emacs & Mu4e <tangonov>Nothing is the "real deal" unless it's potentially destructive <justkdng>I gave a try the .scm file someone here recommended <justkdng>and I'm getting undefined reference errors <justkdng>or probably I should just wait until nss is updated to 3.78 officially <nckx>gnucode, tangonov: I was away, but thanks for both of your updates (and work)! <apteryx>nckx: not really, outside of my ignorance of UEFI and how it would be handled for a soft raid setup. *tangonov[m] adds a package. Entire dependency chain needs updating <tangonov[m]>But heck, I got it to work and I *think* I haven't broken anything <jgibbons[m]>I want to make some money off it. Either I crowdfund and keep it digital or I find a publisher. <oriansj>we love works in progress, we can help make them better <jgibbons[m]>Still on chapter 2 of possibly 30. There's a lot to do with guix. <the_tubular>I personnally like my books digital specially for computer related stuff <jgibbons[m]>Just because it's physical doesn't mean it isn't also published digital. See Clojure for the Brave and True and Get You a Haskell for Great Good for examples. <jgibbons[m]>Anyway, what about my problem setting up guix in docker? <jgibbons[m]>I'll see if it's also a problem when I build from non-alpine distro like Debian <apteryx>jgibbons[m]: perhaps try to run the docker container with --privileged <jgibbons[m]>BusyBox expects mktemp templates to have at least 6 X's. Does alpine always use BusyBox or is that just a Docker thing? <jgibbons[m]>Then I'll send a patch that makes the install script work with Alpine. Very trivial change. <apteryx>sneek: later tell civodul I'm not sure what the outdated jami variables/procedures used in tests/services/telephony.scm were, but if you have more details, I'm interested <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 <tangonov[m]>So I could probably submit this as 1 commit: Add package H and supporting dependencies, or break it up into probably 4 contextual commits leading up to adding the package. <nckx>Rust has raised the bar for insanity :) <nckx>It sounds like 4 simple upgrades from here. <tangonov[m]>Oh, I bet it could get worse, I may contribute NPM packages. <nckx>‘Add foo and 3 dependencies’ is never acceptable. <nckx>You can always turn those into 4 commits. <tangonov[m]>Ok...now to wrap my head around submitting mail patches and "changelog formatting" <nckx>It's not as daunting as it seems. For the changelogs, browsing the git history will give you ready-made examples for the most common changes. <roptat>I think I used git send-email wrong, sending to <Hi,> and <Guix!> ^^' <trevdev>If I have installed git:send-email, but git send-email is still not valid, what should I do? <roptat>install git in the same profile as git:send-email <roptat>if you have it, then reload the etc/profile script from that profile <roptat>git needs an environment variable to know where to find its plugins, and guix will generate it in etc/profile if it has git and a package that defines a git plugin in that profile <roptat>but it's not loaded automatically for your user profile for instance, only at login (that's just how shells work) <trevdev>Theoretically re-logging in should have fixed this then? I'm pretty sure I only have the defalt profile <roptat>do you reall have both git and git:send-email in your default profile? <roptat>then what does "echo $GIT_EXEC_PATH" tell you? <roptat>(you can check with "guix package -l") <trevdev>/home/trevdev/.guix-home/profile/libexec/git-core <- EXEC_PATH <trevdev>Maybe .guix-home is where my divergence stems from? <roptat>so do you have git:send-email in your guix home profile? <roptat>mh actually I also have it in my guix home profile with the same EXEC_PATH as you, but the profile doesn't have the file in it at all <trevdev>If I try to `find -name "email"` or `find -name "git"` I see no references to send-email, if one could be found <roptat>I don't think find goes through symlinks by default <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. <roptat>I have git:send-email in my guix home declaration, but even after reconfiguring to make sure it was that declaration I was using, I still don't see it in the profile <roptat>oh specification->package+output doesn't work as expected <roptat>and I think that's what "guix home" generates when you first use it? <unmatched-paren>oh, you'd need to apply (map (lambda (pkg) (if (list? pkg) pkg (list pkg "out"))) PACKAGES) to make it convenient to use variables <unmatched-paren>you can always cons the variabled package onto your final list of packages created with specifications, anyway <roptat>I mean the most annoying part is to figure out which module to import <unmatched-paren>(I have no idea whether the above actually makes supertuxkart run faster :P) <roptat>nope, tuned-package is a no-op for most packages <unmatched-paren>yeah, that's what i thought. although it still makes it build from source using the skylake compiler... <roptat>I learned from ludo it's a placebo ^^ <unmatched-paren>i think the bottleneck is my integrated Intel GPU, not the CPU, anyway <roptat>well at least I figured it out, used let-values to capture the pckage and its output <roptat>otherwise it only returns the package and discards the output <roptat>trevdev, so maybe the issue is you're using specification->package in your guix home configuration? <roptat>need to go but others will be able to help :) <jpoiret>does anyone know if having at least one --to argument to `git send-email` overrides the default sendemail.to configuration value? <jpoiret>well, it does override :) wasn't too long to test <PotentialUser-11>Hello everyone. Does anyone managed to package electron or yarn application, if not what was the problem? <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 guix-devel@gnu.org or guix-help@gnu.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 <jpoiret>does anyone use custom fontconfig settings? <gabber>what does "the source file name should contain the package name" mean (output from `guix lint`)? the source the package in question is a tagged git commit. <jpoiret>gabber: did you use (file-name (git-file-name ...)) in your origin record? <gabber>no i didn't! and yes, that was it! thanks! <gabber>should revisions start at 0 or 1? <nckx>jpoiret: Yes, but not on that machine right now. <jpoiret>in the end, i wrote some of mine and they work properly (if by properly i mean "not as well as i'd like but maybe a bit better") <nckx>What font configs are lacking in your life? <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: Are you on a Guix System? <nckx>If that file exists, it probably hard-codes /lib/ld-linux-x86-64.so.2, which doesn't exist there. <nckx>You could add (extra-special-file* "/lib/ld-linux-x86-64.so.2" glibc) to create it. <nckx>But there might be many other libraries that it needs. You can check with ldd (provided by the glibc package, I believe). <nckx>kaelyn: OK, I thought you meant menu entries for things that weren't GRUB commands. No, unfortunately that's not exposed by the (extremely limiting) {grub-,}boot-loader interface. <nckx>What I'd do, I think, is manually maintain a grub.cfg that ‘configfile’s the one generated by Guix instead. <tex_milan>libnativewindow_awt.so doesn't exists at that location <nckx>This might not be a Guix issue? I'm not very familiar with Java, but why is it looking in a specific subdirectory of your ~? <nckx>What's this natives/linux-amd64 business? <nckx>(I'm too hesitant to download & run what looks like a binary myself, sorry.) <tex_milan>don't know. it works on nixos... I thought it is something in openjdk... maybe it really needs different JRE.... <nckx>It runs under NixOS with ‘java -jar ~/Downloads/SweetHome3D-6.6.jar’, nothing more? <nckx>Does NixOS have /lib/ld-linux-x86-64.so.2 or some FHS compatibility layer? <tex_milan>i was just using it in nixos couple months ago <nckx>That's a very different way of running it. <nckx>As I expected (I was playing around with the .jar here), the .so blobs are bundled in the .jar, and Nix extracts the .jar, patche(lf)s the libraries, and recompresses the result. <tex_milan>(facepalm) and I was expecting java's jar is platform independent <tex_milan>will probably have to use inkscape to create my floor plan. ugh. ***Tracnac_ is now known as Tracnac
<nckx>Despite my hesitations above I have downloaded the jar anyway. Their home page is too adorbs to be a scam. /s <nckx>The native/linux-amd64 .so's are missing at least libjawt.so, libX11.so.6, libXrender.so.1, libXxf86vm.so.1. <nckx>I've added those as extra-special-files, let's see… <tex_milan>i noticed. you're brave ;-) their page is like straight from 2000s. thanks! <nckx>(Reconfiguring will take a little while, I've postponed too many updates.) <tex_milan>going out, will be back in hour or so. will keep it open, if you get something (good or bad) please post it here, I'll check it later. thanks nckx! <djeis>So I've heard deduplication thrown around a little in reference to the store and daemon, what does that mean in this context specifically? Is it file level, and if so when/how does that happen? <nckx>tex_milan: OK! I'm building a kernel so it'll be a bit. <nckx>djeis: It is, and it's implemented ‘explicitly’ (no file-system extent magic, …) using hard links. See the /gnu/store/.links directory (ls will take a while). ***meow is now known as jess
<nckx>Each file's content is hashed, and if it matches the daemon creates a hard link etc. You get the picture. <djeis>And that happens against every file in an output of a derivation against every other file in the store? <nckx>Recently some limits were added to skip deduplication entirely for tiny files. <nckx>djeis: No, that's the use of the hashes. <djeis>I guess I mean, is every file inside of every derivation output hashed? <nckx>If /gnu/store/.links didn't exist you'd have to do that. But now you just hash(NewFile), hard link it to /gnu/store/.links/$hash, done. <djeis>Okay, that makes a lot of sense. Neat! <nckx>Cfr. guix gc --verify=contents to be correct. Without that option it checks only for existence. <apteryx>should we color our PS1 prompt? debian does it. seems it'd help to differiential outputs from commands <the_tubular>I like the root one to be plain boring white. And the one I always use with colors and stuff, to differentiate <nckx>Adding ‘fun’ features sounds like a good time to make it easily customisable. I don't think it currently is(?). <nckx>Looks like a hard-coded string blarted out in etc-service. <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>(I'm sure this is better than those.) <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 <Haider>I have before, I might test it again. <unmatched-paren>I do C without the ++, so i have no idea why it might choke on iostream, sorry. (I had some issue with clangd that caused me to switch but can't recall what it was) <Haider>Clangd has always anoyyed me :(. Luckily CCLS is working again in my VM. <nckx>Trailing / works, but let's fix this at the source. <nckx>Aside, however: I think /etc/os-release should point to the devel manual for reasons I can't formally argue at the moment but it just makes more sense? *unmatched-paren still thinks we should get rid of the release manual and adjust the devel manual to document both the release and nightly installation procedures... <nckx>At least swap the default: /manual → master, /manual/1.3.0 → release. <jpoiret>unmatched-paren: but then what about the 1.3 images? <nckx>What exactly about them? <jpoiret>ah right. but then, what if some things change in eg system configuration? <jpoiret>although i agree that people should `guix pull` before doing anything else <nckx>The official workflow currently doesn't AFAIK. <nckx>Install, reboot, then pull, it whispers. <unmatched-paren>like "if you're on the devel image, ..., if you're on the release image, ..." <jpoiret>nckx: yeah, that has the upside of being able to use all the installer store instead of fetching substitutes <jpoiret>but if you're going to be pulling and reconfiguring soon anyways 🤡 <nckx>It's significantly more comfy to do so with a working desktop/browser/cat video enjoyment environment. <jpoiret>unmatched-paren: i don't think it'd be manageable, for example think of an hypothetical wayland? default switch from #f to #t <jpoiret>or even a change in a some service's configuration record <unmatched-paren>since you pull after rebooting, there's no point in documenting 1.3 beyond installation <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 <jpoiret>in any case, I agree that we should get rid of the latest vs stable manual distinction <unmatched-paren>then you just set up a default system (maybe with gnome removed) and reboot, and THEN set up your services and stuff <nckx>At least swap the default: /manual → master, /manual/1.3.0 → release. <jpoiret>but I'd rather only keep latest, and say that "if you're running something other than master, use `info`" <nckx>Didn't mean to be rude, but it was just as apt as the first time 😉 <nckx>Anywoz, the /en/manual 404ing is fixed now, in case log lurkers would wonder what mysterious UX funtimes were being referred to above. <unmatched-paren>we probably also need to make it clearer that guix is rolling-release <bjc>i'm going to be brutally honest and say that if the answer is "use info" then it is not an answer at all for most people <nckx>Now we know that literally nobody uses the os-release URLs. <bjc>info is terrible. it was bad in the 90s before html documentation, and it's absolutely awful now <unmatched-paren>and if you object to the texinfo system itself, fair enough, but that's like getting bad at someone for using a specific library even if you're not a developer of the program <nckx>Yes, much better to find a second device on which to view a German Web site with the same information. <nckx>This is the convenience people demand. <bjc>i think most of us who install machines have a second device handy <nckx>I wasn't denying that, just pointing out the absurdity. <bjc>i will absolutely reach for my phone to search for html documentation over wrangling info <tex_milan>nckx: this starts it and works. without the 3d view. 503lsi-libx11-1.7.3.1/lib: java -Dcom.eteks.sweethome3d.no3D=true -jar SweetHome3D-6.6.jar <nckx>tex_milan: Ah! Progress. <bjc>the keybindings are bad. the layout and structure is more complex than it needs to be for most of the things you're going to want it for in a pinch <bjc>on the command line, man is better than info for 95% of sysadmin tasks <bjc>i use info in emacs, and it's the only place it's at all ok, and even there it's awkward <nckx>Shipping a graphical environment with a HTML browser so people can do stuff like check the cat^Wmanual included on the CD that way is a better way forward than this digression, I think. <tex_milan>nckx: can't get rid of that error with 3d, same as you <bjc>i'm saying don't get rid of the online manual for non-devel versions, because "info" isn't the answer to that problem <nckx>tex_milan: I wonder which part of the Nix package makes it just work there. <nckx>No, shipping various formats on the CD is. <nckx>But the release manuals won't be deleted, at least I don't see a good reason to do so. <nckx>What's expensive, in user time and support time, is the choice to put them at /en/manual instead of /en/manual/old.as.heck. <bjc>honestly, if it were more obvious how to move around between different versions of the documentation (like how rust does its reference manual), i think that'd be ideal <nckx>bjc: Can you explain a bit more so I don't have to expose myself? <bjc>it's prominent in the sidebar that you're reading "version x" of the manual, and it's quick to go to the latest, or use a drop down to select another version <nckx>That should be extremely doable. <bjc>of course, now that i go look, it seems like they completely redid their documentation front end since i last looked and now its terrible <nckx>Once you insist on rewriting the world, you just can't stop. <bjc>trust me, it *used* to be nice! <nckx>I was worried for a moment you meant something more complex with, I dunno, version-dependent mark-up or something. <nckx>Which sounds nice but ends up like #ifdefs. <bjc>just a reasonably easy "this is version x. here's a link to the latest. here's a drop down for other versions we've published" <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. <bjc>yeah, i wish i'd known about the "dev" manual earlier <bjc>too much to do, not enough people*time to do it in <bjc>is the source for the doc website in guix? <nckx>It's also, frankly, boring. Figuring out how to add a trivial banner to older versions will probably take more time than expected (yay Texinfo), then making sure old URLs are redirected, etc. <bjc>do i want to know why it's called ‘guix artwork’? <bjc>the repo is ‘guix-artwork.git’ <nckx>But I don't get the question. <nckx>It's Guix, it's artwork, it's git. <bjc>it's also got the website source in there <nckx>I guess you disagree that the Web site is artwork. OK. <bjc>well, in an abstract sense, no i don't. but on a more practical level i guess i find it a surprising name <nckx>The ol' caching & naming things I guess :) <Gooberpatrol66>when I run guix gc I get "guix gc: error: stat: No such file or directory: "/var/guix/profiles/per-user/root/current-guix-1-link" <unmatched-paren>the only reason i can possibly think of is that you've never guix pulled, which is unlikely <nckx>Gooberpatrol66: Does that file exist as a broken link or something? <nckx>unmatched-paren: …*as root*, which is quite likely (I don't have that file). <nckx>Just delete the symlink. <nckx>There's nothing magical about /var/guix/profile. I always clean up my generations with rm, not with guix gc --delete…. <nckx>Did you move it out of /var/guix? <nckx>I wonder how that link got broken. It, as you have probably surmised, shouldn't®. <nckx>Guix considers those very links to be GC roots and their targets protected. <tex_milan>nickx: mesa is missing in your script and path. with it I get further to another error <nckx>I mentioned that earlier. <nckx>I added mesa, then got that godawfully long error above. <nckx>But if I disable 3d it ‘works’. <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. <tex_milan>module java.desktop does not "exports sun.awt" to unnamed module <nckx>But then why does it work on NixOS? <nckx># sweethome3d 6.5.2 does not yet fully build&run with jdk 9 and later? <nckx>Is ‘jdk 9’ == our openjdk@9? <nckx>all-packages.nix still exists and won't even load in the GitHub Web UI :) <nckx>However, icedtea@3 should correspond with jdk8. <tex_milan>yeah, that's why I switched from nix to guix. more readable and writable and understandable. <nckx>MESA_GL_VERSION_OVERRIDE=2.1 LD_LIBRARY_PATH="$(printf '%s/lib:' $(guix build --no-grafts libx{11,xf86vm,render} mesa icedtea@3))$LD_LIBRARY_PATH" java -Dsun.java2d.opengl=true -jar /tmp/SweetHome3D-6.6.jar <nckx>still gives me that unexported awt whatsit error. <nckx>Works great without 3d but then so do newer JDKs. <nckx>Are we missing some Sun JDK 8 magic (and possibly non-free, but I don't know the story) sauce? ***dongcarl9 is now known as dongcarl
<tex_milan>if there is something stripped from guix package then that error message would make sense. something named sun.awt is not there so it can't be exported to the application...? <nckx>I don't know much about Java proper. <tex_milan>thanks nckx! perhaps we or someone else find out the solution! <nckx>I don't see anything obvious in the Nixpkgs openjdk. <nckx>they build with "--enable-unlimited-crypto" <nckx>This is why we are all poor. <nckx>Alas, nothing actually relevant jumps out. <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. <nckx>I'm sorry your experience was suboptimal. I also don't fault Sweet Home 3D upstream, because I don't think they're doing anything that isn't common in Javaland. <tex_milan>no problem. I am satisfied with guix. Steam works :) and I even got used to herd (although I still have a love relation with systemd :D) <nckx>Sure, we're not an anti-systemd distro. I certainly won't defend the Shepherd over systemd at all costs. <elb[m]>I am really enjoying `guix environment --container` on a foreign distro <maximed>elb[m]: FWIW "guix shell" is nowadays recommended instead of 'guix environment' <maximed>It does practically the same thing, but the CLI interface is supposed to be a little nicer <elb[m]>you know, I saw that guix shell said something about that, but the guix environment documentation didn't, so I was a bit confused <elb[m]>I was left with the impression that guix environment was deprecated for interactive use <nckx>Deprecation warning: The ‘guix environment’ command is deprecated in favor of ‘guix shell’. <elb[m]>(which is not what I'm using it for) <maximed>elb[m]: For non-interactive too, I thought? <nckx>Being deprecated, ‘guix environment’ is slated for eventual removal. <nckx>(End quote) No mercy for the non-interactive. <elb[m]>yeah, I see that `guix help environment` actually says that it's deprecated <elb[m]>I'm not sure what I was reading where I was left with a different impression <elb[m]>I definitely saw that this was a Thing, but as I said, I took away "environment -> non-interactive", "shell ->interactive" <maximed>Didn't know that "guix help COMMAND" existed <oriansj>please tell me guix is printing the equivalent guix shell command so that the transistion is smooth <elb[m]>anyway, it looks like I can just change `environment` to `shell` in my startup script with zero other changes <maximed>TBC, sometimes changes are required. <maximed>E.g., "guix environment hello" -> "guix shell -D hello" <maximed>"guix environment --ad-hoc hello" -> "guix shell hello" <nckx>If you're not using --ad-hoc, you're probably assuming the behaviour now performed by --development, elb[m]. <nckx>*guix shell --development. <elb[m]>sure, but in my case I just checked the documentation and it seems to require nothing in my case <nckx>What's you guix environment command? <nckx>Assuming you drop it of course. <elb[m]>`guix shell --container --network --no-cwd -P -m $MANIFEST --share=$SHAREPATH=/home/elb -- /bin/sh -c 'SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs" syncthing' <elb[m]>(it was that, but s/shell/environment/, before) <elb[m]>wait -- I'm not using ad-hoc, sorry, I used to be <elb[m]> * `guix shell --container --network --no-cwd -P -m $MANIFEST --share=$SHAREPATH=/home/elb -- /bin/sh -c 'SSL\_CERT\_DIR="$HOME/.guix-profile/etc/ssl/certs" syncthing'` <nckx>Yeah, --manifest should be unchanged, I forgot about that common usage. <elb[m]>I should note that I did have trouble with `--pure`, when I used `--pure`, syncthing did not appear either in /gnu/store or in profile bin directory, no matter how I invoked it <elb[m]>but I honestly can't tell the difference with or without pure except for that issue <nckx>You mean when you changed environment → shell? <oriansj>so guix environment --ad-hoc $package --fallback just becomes guix shell $package --fallback? <elb[m]>no, with environment, sorry; I haven't tried with shell <oriansj>and guix environment guix becomes guix shell --development guix <maximed>guix shell --pure --container --no-cwd -P syncthing -- syncthing <nckx>But note that --development applies only to the subsequent package, --ad-hoc applies to the entire command line. <elb[m]>maximed: yeah, it works with --shell <elb[m]>good thing environment is deprecated ;-) <nckx>s/line/line following it/ <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) <oriansj>nckx: well a couple years after environment is gone, a superior version of shell can be made and take the name environment <nckx>Probably unintentional, but fun. <nckx>oriansj: I suggested that and it was rightly rejected, and I agree now. <nckx>It's just too weird historically. <elb[m]>incidentally, it's not clear to me how this plays with `guix gc`, so I created an environment using the same manifest <elb[m]>I don't want to have to redownload a bunch of crap for my containers because I gc'd <nckx>‘environment’ is a retired number, to be admired but never used again. <nckx>elb[m]: You can use --root. <oriansj>nckx: so is there going to be a list of retired keywords? <nckx>elb[m]: --root=FILE will create FILE, and as long as FILE exist your entire ‘environment’ is safe from GC. You take on the responsibility for deleting that file manually of course. <nckx>And it's not magic; renaming it will break the connection too. <nckx>Rename in the broad sense including moving. <elb[m]>oh, that reminds me of another thing I found weird; -P and that --share that creates a home dir don't interact super great <elb[m]>because the home dir then persists (which I want), but -P will fail because the profile link already exists <nckx>I'm not convinced that's intentional, although it could be. <elb[m]>I think maybe I'm abusing --share <elb[m]>but I didn't see another way to get what I was looking for with this level of isolation <oriansj>nckx: so in 2070 when people completely forget about guix environment, it'll still be retired but only if it'll break things? <elb[m]>(specifically, I'm not sure it was "expected" that I would --share the shell's home directory in its entirety) <nckx>oriansj: Bring it up in 2070 and I promise I'll reconsider. *nckx makes a note in their government-mandated Neuralink implant. <elb[m]>to where would I best report this <oriansj>nckx: we we are both kicking in 2070, I'll probably more likely to buy a round of drinking to talk about the old days <nckx>oriansj: My treat, since you'll probably be working on freeing our horrGENEROUS NEURAL GIFTS. <nckx>elb[m]: bug-guix at gnu dot org! <oriansj>nckx: That'll be for the next generation of bootstrappers as they need things to make a name for themselves <nckx>elb[m]: Sorry, I missed that. <elb[m]>I had to click contacts and expand it to find that <nckx>oriansj: That makes me curious: would you say the effort is attracting young whipperstrappers at a reassuring rate? Does it attract many new people at all? <nckx>I can imagine it being intimidating. <oriansj>nckx: I would pray that I am not intimidating to new people <oriansj>and have created a warm and supportive environment <oriansj>as good documentation and encouraging questions is the only way to ensure new people understand everything involved <nckx>elb[m]: I've never been entirely happy with the ‘About’ menu, FWIW. <elb[m]>I didn't even use the about menu, I scrolled to the bottom (looking for a bug link) <nckx>I wondered where you got ‘Contact’ as the top level. <elb[m]>Personally, I think I would expect to find "issue tracker" or even "report a bug" under Help <nckx>I think the second is more clear. ‘Issue tracker’ is still quite obscure to non-jargonists. <elb[m]>obviously I found it, but ... I have almost 30 years of experience in open source software, it was a LOT easier than FTPing a HOWTO from sunsite.unc.edu <elb[m]>agreed, although the issue tracker link isn't quite "report a bug" (although it does have that information at the top) <elb[m]>yeah, bug reports is probably a good middle ground <nckx>My mother wouldn't immediately know what an ‘issue’ is. She knows bugs. *nckx adds to-do item to their to-do list in ~ , which will do until the free-as-in-mandatory implant arrives. <nckx>elb[m]: Oh, you got bit! <elb[m]>(issue filed for `guix shell -P`) <nckx>/en/manual is ‘stable’, read ancient, /en/manual/devel is up-to-date. <elb[m]>I just did Help -> Gnu Guix Manual 1.3.0 -> ... <elb[m]>well, maybe not, but I mean I didn't use any URLs ;-) <nckx>True, you at least missed (latest) right beneath it 😉 Still. <nckx>It's like putting a rake outside the front door and a ‘you might prefer the back door’ sign inside. <elb[m]>I just didn't click it, because I'm not _intentionally_ running "devel" <elb[m]>and maybe that's what you mean ;-) <elb[m]>I installed 1.3.0 and then `guix pull`'d <nckx>Since there's no such thing called ‘devel’. <elb[m]>anyway, so, since you seem to be very receptive to this sort of experience report <elb[m]>(and don't get me wrong, I'm quite happy with Guix, I'm using it and have been using it for some time for several mission-critical programs for me, such as Emacs) <elb[m]>the "how should I actually _do_ this?" for buying into guix on a foreign distro is ... a little bit daunting <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’. <elb[m]>well that might have been a little dramatic <elb[m]>but like, I did have to create a way to identify the profiles that I want to update automatically, and then iterate through them to `guix package -m` <nckx>The lack of a ‘what even profiles?’ chapter at the start of the manual was totally expected, for example. <elb[m]>also that ... just fails sometimes, and re-running fixes it, for whatever reason