IRC channel logs
2024-07-11.log
back to list of logs
<spenc>ok, adding 'N' worked, i will suggest that it get added to the manual or else clarify which commands are to be run in guix shell and which outside of shell <spenc>also got most of the failed tests to pass, so i suspect? that either their build machine has some sort of networking or a mock version <madeleine-sydney>i'm running guix from HEAD with `pre-inst-env`. for some reason, it claims `import` is not a command, before asking if i meant `import` (exactly what i typed). what's going wrong? <PuercoPop>Is there a herd command to view the logs of a related to a service? <lfam>madeleine-sydney: It's likely that the error message is misleading about what is missing, and then the hint just doubles down on the wrongness <lfam>When you run the command, are you inside of a guix development environment? That is, `guix shell -D guix`? <madeleine-sydney>i was. i've got it working now, though. i was using a broken guix installed by debian, instead of a up-to-date binary from guix pull. <lfam>Ah, okay, glad to hear it's working <PuercoPop>How do I combine define-public with define* form ice-9 optargs? I want to use keyword arguments <spenc>1. is there any equivalent to git-fetch for fossil? I couldn't find one though there was talk in an email thread about such a thing <spenc>& 2. is there any way to keep up-to-date automatically when a repo puts out a new version, or is it done on an 'as-needed' basis <spenc>(there is no three, miscounted) <z572>I think the kde-team is ready and just need to wait for the core-updates <allana>Hi #guix! I am using "guix pack -f docker" to bundle some software, and I am curious to know if there is a way to set setuid/setgid for programs in the store that become part of the container image. I am also trying to tinker with ways to set these properties at runtime but I am running into some difficulties. Anyone have ideas for me? <rickame>o/ im trying to learn guix and i gotta question. there are derivations, and then our config of those derivations. but is our config also a derivation or can we make it 1? reason i ask is i want to share sections of my config with ppl like any other derivation so they can just reuse my config in their config and maybe customize it a bit <cbaines>morning, I'm going to attempt to rebase core-updates and add in some of the patches that are waiting <PotentialUser-34>Hey! I've read parts of the manual and tried Guix (foreign distro) a bit on my current machine, but I'm still very new. I want to know what the "packaging philosophy" of Guix is. For example: Arch tries to be bleeding edge and packages the latest version possible, Debian tries to be super stable and backports bugfixes to keep that. I understand <PotentialUser-34>that the big focus is on reproducibility, but how is it decided when a new version of the software should be packaged or not? <erty>I was trying to install guix as my 3rd OS on my system. The installation was going on fine but in the end, an error occured: "this GPT partition tool contains no BIOS boot partition....blocklist are discouraged..blah..blah". So how can I proceed with the installation? Thanks! <erty>I have windows dual booted with ubuntu. I have created a partition on windows <Deltafire>PotentialUser-34: from my experience, it's not quite bleeding edge but also not keeping old packages around like Debian would (since you can always rollback if a new package breaks something) <futurile>PotentialUser-34: Guix is a rolling release, so there's the potential that it can have the most up to date versions. In reality, what version is available is determined by someone maintaining the package (Guix is a much smaller project than both of those), and how disruptive the change is. Consequently, you'll find pretty current versions of packages like Vim (not many dependents and tends to be <futurile>stable), but big alterations to something like the compiler are done on branches and merged in. <futurile>PotentialUser-34: the main difference - if you're reasonably technical and interested - is that it's fairly easy to maintain your own 'channel' with your own package builds in them - so some users will be using a later version of $PACKAGE than are in the main channel - and these user channels can be shared <PotentialUser-34>Deltafire and futurile thanks a lot! I'm looking forward to experimenting with trying to maintaining some package builds over the summer. :-) <PotentialUser-34>Feels like it should be a good opportunity to learn more about the software I use. Thanks, and bye for now! <rhuijzer>erty: You've probably booted the installation media as BIOS instead of UEFI mode. I would just start the installation again making sure it's booted as UEFI <Guest85>I updated guix recently and it broke xorg... it no longer reads ~/.xinitrc... I use the slim display manager... do you guys have a config that reads ~/.xinitrc? <Guest85>I've tried (and failed) to get a working startx-command-service-type <rhuijzer>I think you can just use the slim-service-type and create .xinitrc manually or with a simple service <Guest85>rhuijzer maybe?... I script that gives a dmenu prompt for a window manager, but now it just starts awesome (one of the options) and none of the ~/.xinitrc seems to be executed <Guest85>rhuijzer I don't want anything to create an xinitrc, I already have one, it's just not read <rhuijzer>Awesome probably created an entry in /usr/share/xsessions/ ( /run/current-system/profile) which slim gives priority above xinitrc <rhuijzer>So you should look into omitting that or setting the auto-login-session in the slim-service-type <Guest85>I've tried setting the auto-login-session but it just breaks... hard to debug... should (file-append bspwm "/bin/bspwm") work? <rickame>im trying to learn guix and i gotta question. there are derivations, and then our config of those derivations. but is our config also a derivation or can we make it 1? reason i ask is i want to share sections of my config with ppl like any other derivation so they can just reuse my config without having to duplicate it in their config, and maybe <cbaines>rickame, there are derivations, but that's not really how you'd go about sharing configuration. You'd just use a Guile module and share that. <rickame>cbaines so i turn some of my config into a guile module then use it myself as well as share it with others? <rickame>cbaines cool can i publish them to the guix channel or is it all out of band? <cbaines>for configuration you probably don't even need a guix channel, although maybe that would be convinient <rickame>to turn my block of config that i wanna share into a module, does it need to be changed? <Guest85>every time I try to specify the wm it doesn't load <rickame>cbaines to turn my block of config that i wanna share into a module, does it need to be changed? <cbaines>rickame, well, you'll need to put it in a module and export it <Guest85>rickame look at the guile manual for defining modules... the guix modules typically have 3 levels of namespace (e.g. (gnu packages linux)), you can have just 1 if it's very simple... and the use-modules manual... and figure out what dependencies the config block has, since it might use guix services or packages or util modules, etc. <allana>I am bundling software as docker containers (guix pack -f docker) and some of those packages would benefit from having setuid/setgid file modes. How could this be done in the right way? Right now I am thinking of inheriting the package and adding a build phase that sets setuid/setgid, but then that ends up in my guix store. How have others approached this issue, if anyone? Any ideas or suggestions? <civodul>allana: hi! files in the store cannot be setuid/setgid, as this would be a security risk <civodul>and consequently, images produced by ‘guix pack’ cannot have that either <civodul>so support it, we’d need a special mechanism to create those files in the image <attila_lendvai>i wanted to have a quick look at `make check-system`, and i'm staring at a local build of ganeti... :/ <apteryx>ACTION is closing the machine for some time; see you later, friends :-) <reyman>i'm packaging mkdocs in python into guix. This package search "theme" installed using pip. I also package "mkdoc-material" but i need to reference it into pip <reyman>i use the pyproject-build-system <attila_lendvai>the ganeti test failure is due to the openssh fix (tries to generate a dsa key) <attila_lendvai>i'm testing a fix but i need to leave soon. if a comitter has time, then the fix is (probably) to also disable this test: test/py/ganeti.ssh_unittest.py <dale>Any rustaceans in? Which packages do I need for 'cargo clippy' to work? I'm already pulling rust-cargo and rust-clippy. <Guest85>can guix gc delete anything thats a part of a system or user profile? I think the answer is no but I'm having issues and if it does then it might be the reason <Deltafire>no, it retains anything that's linked to current or past generations which haven't been deleted <Deltafire>although it may delete items which have been used for building <Guest85>what login managers and window managers do you guys use? have you got any desktop environments working? <Guest85>I've used several X window managers (currently switch between bspwm, awesome, EXWM, stumpwm)... <Guest85>GDM didn't work well when I started using guix so I tried the other login managers & slim was the only one that worked... <Guest85>Now I'm having issues getting any to work so I wanna see some working configurations... <Guest85>are you meant to be able to just run bspwm or startx from the tty in guix? afaik that's never worked... it always wants to go through the login screen... <Deltafire>Guest85: i stuck with the default gdm/gnome, seems to work well <Guest85>Deltafire did you configure gnome much? I haven't gotten any of the desktop environments to work <Guest85>(configure guix system to work with gnome) <Deltafire>no, it just worked from the start.. i went back and forth with X/Wayland for a bit <Deltafire>using mostly the default configuration that the installer generated <civodul>anyone on x86_64-linux willing to try this and report the result: guix time-machine -q --commit=0ff72d105 -- build avahi -d <dale>Hello Guixers. Anyone able to answer my question about packages needed for 'cargo clippy' apart from rust-cargo and rust-clippy? <Deltafire>civodul: error: #{ %make-platform-procedure/abi-check}#: unbound variable <Deltafire>/gnu/store/fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv <efraim>dale: there's a cargo-clippy binary in rust:tools <efraim>or do you mean you know it's there and don't know why it's not working? <dale>That's what I needed, thanks. It does not show up with 'guix search clippy'; how do you search for things like this? <freakingpenguin>Has anyone done X11 forwarding with $ guix home container? Seems the process might be a little different since --preserve isn't an option. <efraim>it would probably show up if we added clippy to the description of rust, not sure how you'd know it was there otherwise. <efraim>'guix locate cargo-clippy' didn't have it show up on my machine <dale>Yeh, I think maybe there ought to be something in the standards that all packages list out their binary outputs in their descriptions. <dale>But I'm good now, thanks for your help. <dariqq>civodul: abi-check unbound variable and /gnu/store/fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv <efraim>I got it also, testing it on berlin <vagrantc>going to wander off and find some breakfast :) <rhuijzer>Can someone eli5 why you can have a lot of build errors on a guix package on a foreign distro but the same package works/builds correctly on guix (the distro)? Does guix on foreign distro's use the included GCC or something? <rhuijzer>Both on same hardware so I'm a bit puzzled about the reproducability aspect <anadon>I recall Guix having some really interesting uses of `gdb` for it's runtime throughout various points of it's lifetime. Can someone tell me more about those? I'm trying to write a blog post about interesting `gdb` usage. <rhuijzer>freakingpenguin: So this theoretically shoudn't happen, right? <freakingpenguin>My understanding is the isolation mechanisms are pretty robust. What errors are you seeing? <ieure>Yeah, builds happen in a separate cgroup and don't see anything from the host system (whether GuixSD or foreign). I'm not sure what would be wrong, but it's unexpected and surprising for the same build at the same Guix commit to produce a different result, no matter where you run the builds. <rhuijzer>Oke thanks guys. I dont have time to debug this further as I'm going to make dinner, but will probably dive deeper into it in the weekend to try and create a coherent bug report <elevenkb>Hey there everyone, is there any way to `guix pack` a whole home environment? <ieure>elevenkb, I don't think so, `guix pack' only gives you a set of packages; the home environment has more stuff. <elevenkb>I'm posting this from my rde based laptop as we speak! <dariqq>i think my systemd-userdb/selinux errors are related to the user lookup of the guixbuild users. is there a way i can verify this? <dariqq>removing all but files from /etc/nssswitch seems to "solve" the problem , but i dont understand why this isnt a problem when using the install script <erty>I was finally able to setup and use guix as my 3rd operating system 😎. And to my surprise, it only consumed around 500MB of RAM. <erty>But Ihave some questions, Is there a shutdown/reboot CLI command in guix? How to remap L-CTRL to capslock? <erty>should I be installing Xmodmap for that? <lfam>erty: `halt` and `reboot` are the commands <lfam>Not sure about the other question <efraim>civodul: I also got the avahi error on aarch64-linux <erty>lfam: thanks for that, I think I would eventually solve other problems by following online guides. <spenc>what's the best way to edit the source code of a package? It seems like Guix would be very helpful for developement, especially in a repo that doesn't have a dockerfile <spenc>i see that you can pull the latest version with --with-source , but after that is there something like guix edit that opens the source inputs in an editor? <singpolyma>You mean a package that's in guix proper? Are you wanting to send a patch or maintain a fork? <singpolyma>Yes guix edit exists but you can't actually edit in there because the store is immutable <spenc>im hoping to send a patch to a github repo, and I could follow their steps to build, <spenc>but guix makes building so nice and easy <spenc>i guess I could clone the repo and open a development shell based on the package and then run the build commands from there <spenc>speaking of, if I build with --no-substitutes does that store the source on the computer, or is it only temporary whil it's building <lfam>spenc: The source will remain in your /gnu/store until you delete it with `guix gc` <spenc>is it a bad idea to edit it while it's in there? <PotentialUser-63>hello, how could someone prevent guix upgrade from updating the linux-libre kernel above a specific version e.g: i would like to stay at 6.1.x is there something like (kernel linux-libre@6.1.0) in /etc/config.scm.. I have been runing in circle for weeks trying to find a way out to no avail.. <lfam>spenc: Well, you can't alter any files in /gnu/store. So, you can copy it out of /gnu/store and edit the copy <lfam>PotentialUser-63: In your config.scm, add (kernel linux-libre-6.1) <lfam>You'll probably have to import the (gnu packages linux) module as well <lfam>spenc: The Guix command line interface "composes" nicely in a Unix way. So you can do things like `tar xf $(guix build -S rxvt-unicode --no-grafts)` <lfam>For Git sources, it's a copy instead of a tar <lfam>Let us know how it goes PotentialUser-63 <spenc>seems useful for making local changes that you don't plan on upstreaming, since it wouldnt have the git history or anything <spenc>i assume once you've dont that the move would be to do another build with --with-source pointing to the folder that it's been extracted to? <PotentialUser-63>wow it's working, only got the blinking cursor instead of sway but at least i can start it from another console.. Thanks a lot! that helped a huge time.. <lfam>spenc: Yeah, not amazing for upstreaming. But great for looking at exactly the source code that is used to build the Guix package <lfam>You know, I started with Guix long before '--with-source' was invented. So I still do it the hard way. Generating diffs, moving them into 'gnu/packages/patches', building altering the source origin of the package to include the patch, etc <lfam>with-source seems waaaay better but I'm an old dog <lfam>If I get really busy with Guix contributions again, I'll probably start using with-source and the like <spenc>oh, didn't know avout the /packages/patches folder <lfam>That's where package patches live in the Guix code base <lfam>I've added many a file in that directory... lol <spenc>right, I forgot that all the packages were part of guix source <spenc>this actually relates to something i was meaning to ask, but didnt because it seems like something i should definitely know already <spenc>but i have three versions of guix sitting around, the first one was through the shell script, the second from a guix pull (so presumably lives in the store), and the third from following the tutoral building from source (so it lives in source in a folder, but the binary is somewhere? following make install) <spenc>and after building, i'm not really sure which version my 'guix' command is pointing at <lfam>Right, there's a few tools to figure out "what is FOO when I run FOO"? <spenc>this is my .profile, added based on a hint <spenc>GUIX_PROFILE="$HOME/.config/guix/current" <spenc>. "$GUIX_PROFILE/etc/profile" <spenc>'which guix' gives which guix <spenc>/home/me/.config/guix/current/bin/guix <lfam>In general (with some exceptions), typical use of Guix executes '~/.config/guix/current/bin/guix'. This program is your user's copy of Guix (remember allowing users to administer their own packages is one of Guix's selling points). This Guix is upgraded, downgraded, etc with `guix pull` <spenc>right, ok thats what i thought, so not the source version <lfam>The source version, when you build it, lives at ~/$GUIX_SOURCE_TREE/scripts/guix <lfam>And when you run it with the 'pre-inst-env' script, it's executing that file <lfam>I'm not sure which shell script you mentioned above. Was it pre-inst-env, or the installer shell script? <spenc>after building guix from source, I ran make install, since it seemed at the time like a good idea <spenc>though thinking more, i assume the standard method is to not do that, and use only the ./pre-inst-env version? <lfam>Yeah, it's recommended to use pre-inst-env if you want to run the Guix that you've built from source <lfam>There are sometimes other Guix commands that you might run, especially after installing Guix, before you run `guix pull`. In that case, your user does not yet have their own copy of Guix, so they use something provided by the system. But the first time they run `guix pull`, they get a copy at ~/.config/guix/current/bin/guix <lfam>It's a bit much to take in all at once so let us know if you have more questions <lfam>By "other Guix commands", I mean other copies of the Guix executable <spenc>right, it was super easy to build the guix source from inside a guix shell <spenc>not havig to worry about looking up what to apt get for 20 depenencies is so so nice <lfam>Alright, gotta go AFK for a while. Time to clean up after the plumbres <dthompson>I look forward to watching the recording! can't make it today, unfortunately. <sneek>dthompson, you have 1 message! <sneek>dthompson, j12i says: Hey, the signing key for the Goblins tarball still isn't on a keyserver. :) <lfam>Does anyone know about Boost version compatibility between dependent packages? Like, can package FOO depend on Boost 1.84 while package BAR depend on Boost 1.83, if BAR also depends on FOO? <weary-traveler>guix seems to provide nix. is that the recommended way of using nix with guix (either on guix sd or foreign distribution)? or is the recommendation to install nix package manage via its own installer? <lfam>weary-traveler: I haven't used nix on guix, but I have a loose sense that it's better to install nix on its own, rather than through guix. We'd recommend the same if it was the other way around <craigbro>I would suggest installing nix via guix in your case <craigbro>if you are on another host OS, then installing nix distinct from guix is easier <weary-traveler>bigbookofbug: interesting. on guix sd or foreign distro? any issues you've encountered? <bigbookofbug>the main issue i encountered was the per-user nix directory not being created automatically, but that's because i have a btrfs partition, which nix interacts with weirdly on any foreign distro <bigbookofbug>i beleive if you use something like ext4 or btrfs w/o a seperate home subvolume, it does that part automatically :) <vagrantc>hah! i forgot to mention "guix build --rounds=X" ... although honestly i have found that to be a bit tricky to actually use <vagrantc>weary-traveler: it is useful to find that there is some issue ... but not to produce a result to run diffoscope against or other comparison <vagrantc>unless "guix build --rounds=5 --no-grafts --check" maybe would work <vagrantc>unless "guix build --rounds=5 --no-grafts --check --keep-failed" maybe would work <weary-traveler>bigbookofbug: yeah i'm on btrfs as well, on tumbleweed. i have a new machine that i want to setup, so am organizing my config scripts. it's a bit of a mess with different installers etc <vagrantc>weary-traveler: i haven't used --rounds much as i think i had some confusing experiences early o <vagrantc>it probably also predates challenge and --check ... from a reproducible builds perspective ... but i am just speculating <erty>After guix installation, my grub menu has been replaced with guix one. Is it possible to restore the previous grub menu and also possibly add guix entry to the same? Thanks <weary-traveler>the guix CLI could certainly benefit from a refactor or two to organize the commands. saving past invocations in org-mode has been a saving grace <bigbookofbug>erty: as in the theme, or there's missing entries from grub? <erty>bigbookofbug: Previosuly when I booted, ubuntu grub menu was shown. Now it shows guix grub menu with only guix as an option <ieure>weary-traveler, Agree, I wrote up some stuff about this on guix-devel a while back, don't think anything came of it. <erty>bigbookofbug: This happened after I installed guix system <bigbookofbug>if you have additional OS's installed, you will want to install os-prober <erty>bigbookofbug: Although Ubuntu grub menu can be accessed from hidden menu (repeatedly pressing ESC on boot) <weary-traveler>ieure: is there an existing bug number? i'm curious what the next steps are <erty>yes I have triple boot system now <ieure>weary-traveler, No, there was supposed to be some in-person discussion, never heard anything else about it. <erty>bigbookofbug: I executed it and it showed me a single line output. <erty>"/dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi" <bigbookofbug>i believe so. i think grub enables os-prober by default, but let me check <erty>let me restart my pc and check <bigbookofbug>if not, there's a grub argument, GRUB_DISABLE_OS_PROBER, that needs to be set to "false". that being said, idk how that would be done in guix <erty>bigbookofbug: Running os-prober did not worked for me <erty>It still shows guix grub menu <bigbookofbug>it will show the guix-themed grub menu, but it's not listing other installations? <panosalevro>could someone point me to a super simple shepherd service? i'd like to create a service that simply runs a command with root privileges on startup <bigbookofbug>erty`: if you want the ubuntu menu to the be one that pops up, that's in your computer BIOS. you should see the ability in the bios menu to change the boot order <erty`>bigbookofbug: yes, it's not listing other installation <erty`>bigbookofbug: ok I'will do that <bigbookofbug>it might be best to use the other menu in this case via changing the boot order. i know there are ways to add additional boot options in grub via guix, but i'm unsure of what they are <erty`>bigbookofbug: I will find a way to add guix to ubuntu grub menu, so that it will provide me 3 OS options to choose from. Thanks for the help. I;ll go and try that <vagrantc>heh. now that i finally did the presentation, i can actually risk upgrading guix again :) <freakingpenguin>Looks like a similar thing is also done in gnu/tests/networking.scm with openvswitch-configuration-service. <attila_lendvai>re ganeti failure: yet another test, py_compat_types is also failing. it's some serialization discrepancy, i assume between python and haskell (TEST_DELAY(3.338214845516507e-2) vs. TEST_DELAY(0.03338214845516507)) <efraim>do we have a go package which produces a binary which can be cross-compiled? <efraim>looks like edirect-go-programs work <efraim>well, I figured out how to cross-compile edirect-go-programs for windows, but I also found something to fix in the package, so that's something <lfam>Interesting that countless Rust packages depend on Boost somehow <lfam>At least, if I change the Boost package, then I have to recompile all this Rust stuff <efraim>in that case I'd guess maybe its rust itself <efraim>rust -> gdb -> source-highlight -> boost <efraim>does non-interactive gdb need source-highlight? <lfam>I guess it's not feasible to "just try out" this Boost patch, then <efraim>what if you used the "old" boost for source-highlight and the new boost for everything else <efraim>if it works then we can try gdb without source-highlight <efraim>on master the only instance of gdb/pinned is in rust.scm <lfam>efraim: The derivation of ((gnu packages rust) rust) does not change when I do the source-highlight with custom boost surgery. But still I need to recompile a lot of Rust stuff. There must be other dependency path <lfam>Either that or I'm holding it wrong <lfam>Like, I see from boost to librsvg <lfam>I see I also will need to recompile llvm, which is probably easier to inspect <lfam>Wow, changing Boost and then building Libreoffice means rebuilding approx 1000 Rust packages <efraim>boost -> swig -> graphviz -> vala -> librsvg <vagrantc>huh. when i set my default shell to fish ... i can no longer push to guix.git on that machine. <vagrantc>hadn't noticed any other problems with it so far ... but also hadn't tried pushing from another machine to that machine since switching it to fish <vagrantc>switching back to the default (presumably bash) and everything worked again. <vagrantc>i'll go back to defaulting to bash and just setting fish as the default shell in tmux configuration ... as i basically am almost always running in tmux <lfam>vagrantc: Maybe a problem with our Git hooks, or maybe a problem with GIT_EXEC_PATH, which is how the Git components find each other <vagrantc>it is the first machine i played with setting fish as a default shell (guix or otherwise) ... i was expecting more challenges but that is not too bad <vagrantc>lfam: yeah, i suspected something with the .git/hooks possibly <lfam>efraim: Could be that I interpreted the dry-run messages incorrectly, not sure. At least, Rust itself and LLVM don't change, although I do have to download them. So maybe I "only" have to build the crates <vagrantc>i guess a way to test would be to try to push to a repository without the hooks ... <vagrantc>i wish guix challenge ... would cache the stuff it downloads somehow <spenc>just want to double check my understanding of this- when a package in Guix is made and submitted, it is ponting to the latest (at the time) version of its input dependencies. But if one of those dependencies us updated later the package you made doesnt change until someone expliitly refreshes it <lfam>spenc: Your package's dependency versions are explicitly defined in the Guix codebase. Each Git commit of the Guix codebase is like its own version of Guix and all the packages <vagrantc>lfam: it does not ... re-running guix challenge over and over will keep re-downloading things <lfam>spenc: Try `guix describe`. It will tell you the Git commit that you are currently using for commands run with Guix <lfam>If you check out that commit and read the package definitions, you will see all the versions defined <vagrantc>at least one of the copies from guix challenge could be put into the store, at least <lfam>vagrantc: Yes, at least the one that is assumed to be "correct" <vagrantc>and if it is downloading other copies, maybe with a -challenge extension, much like the way --check does <lfam>I suppose it's typical in Guix that downloads that do not match their expected value are discarded <vagrantc>i have to equally valid substitute servers, both signed, both trusted ... there is no expected value <lfam>I think the current behaviour is generally useful, in that it avoids having to keep a database of "good" and "bad" store objects, avoiding mistakes later on <lfam>It doesn't, but you're not asking it to, right? <lfam>Anyways, I don't think the status quo in this area is necessarily designed with every use case in mind. I think that store operations have evolved since the original design <lfam>There could be room for improvement <vagrantc>lfam: in fact, if i already have the valid build in the store, it actually re-downloads it from the substitute server for "guix challenge" <vagrantc>guess i ought to file a feature request ... and the details can shake out in there ... or not. :) <lfam>Well then... what is to be done? :) <lfam>It still challenges the server? <vagrantc>does the store item not store it's provenence information ... e.g. the signatures from the substitute server? <lfam>I don't know these technical details well enough <lfam>But even if you already downloaded the store item from the server once, don't you want to download it again, if you are challenging the server? <vagrantc>to detect if the server is now sending malformed/malicious junk? <lfam>I thought the point of the command was to challenge the servers <lfam>And compare their output <lfam>Of course it's annoying to download the same things over and over again <lfam>ACTION `guix gc && guix shell -D guix` <vagrantc>but it also means re-challenging the same things multiple times downloads stuff needlessly... :) <vagrantc>though maybe i am a rare bird that runs guix challenge all the time :) <lfam>I think the idea is that the server is a "black box" that we don't control and can't inspect, so we have to challenge it continuously and make a judgment based on what we observe <lfam>It would be great if there was a project similar to Certificate Transparency, where the results of `guix challenge` could be collected and analyzed automatically <vagrantc>at least being able to cache the results somehow would be useful ... weather that is in the store or elsewhere, i do not know <vagrantc>lfam: mind if i dump this conversation into a bug report? <spenc>ok i feel like i must be missing something really obvious, i promise i've been reading the docs as much as i can <spenc>but if every package in the current build of guix has a unique name (ie version dependencies are named things like sdl vs sdl2, etc) then what is the benefit of all the tooling like storing with a hash of inputs to allow for many possible versions of the same package <freakingpenguin>As in the point of the hashes in /gnu/store/<hash-here>-library-1.0.0? <spenc>yeah, i know that in general it's so that you can have multiple versions of a package <spenc>but i dont see how that actually happens if al dependencies are updated at once with a guix pull <spenc>also: does this mean that if someone updates say the sdl package, that every package that depends n sdl would have to get tested? <spenc>(maybe pick one less dependable than SDL, bad example) <freakingpenguin>One advantage is it lets you differentiate identical package versions built with different dependencies. Diffoscope, for instance, failed to build on v269 when openssh updated to 9.8p1, which was reflected in different diffoscope hashes. <spenc>right, but it's not like diffoscope can pick what version it wants right? since everything is using packages from a global namespace <spenc>thats i guess whats confusing me. im from npm land where things are silly and nobody cares about compatability, so like, you'd say exactly percisely what dependency you'd like and it seems like guix the idea is the opposite where when somethings updated all the packages that reference it get updated too before its pushed <freakingpenguin>There is a mechanism (inferiors) for you to mix and match packages from different guix revisions, but you are correct. A commit in guix is a snapshot of every package at that point. <spenc>ok, wait - maybe this is why <spenc>so packages you've installed on an older version of guix stay old until you've refreshed? <lfam>spenc: When you say "refresh", are you talking about the command `guix refresh`? I ask because that command is just for package maintenance and not something that is used for package management <spenc>oh, yes thats what i was talking about <lfam>Okay, that's for working as a package maintainer / Guix contributor, but it has nothing to do with using Guix to install packages <spenc>do does guix pull auto update every package thats currently installed <lfam>No, it updates Guix, which includes the list of package definitions / recipes <lfam>Are you at all familiar with Debian / Ubuntu / apt? <freakingpenguin>guix pull only updates guix itself (it's analagous to apt update or pacman -Sy) <lfam>That's what I was going to say :) <lfam>And then `guix upgrade` actually updates your packages, like `apt upgrade` <spenc>right, and only barely. new to linux, most of my package managing is in npm <lfam>The point of the weird hashes everywhere is so that one could install two packages with different versions of the same dependencies <lfam>Like, package A and package B both depend on package C, but different versions of C <spenc>are the different versions because they are pulled from different guix versions and havent been upgraded yet? <lfam>There's a variety of reasons for it. Maybe A and B are only compatible with different versions of C <lfam>Or, you could install A from Guix of 3 months ago, but B from Guix of today <lfam>And, in the general case, it will work <lfam>(It won't work with some programming languages) <spenc>for A and B compatable with different versions of C, this is whats confusing me since as far as i can tell you cant specify versions right/ <spenc>they have different names if you want to use an older one, that has a dash at the end <spenc>is this somehow related to grafts? i've been puzzling over that for a little bit too <lfam>Correct, if you have two versions of C, in order to define them in our programming language (Scheme), one will be called C and the other will be called something else, such as C-with-feature <lfam>Personally, I find grafts hard to explain if you don't have a strong grasp of how Guix actually organizes and installs packages <lfam>I mean, a 'strong grasp' is not advanced or anything. But just understanding it at a basic level <freakingpenguin>I understanding the concept, but I've picked at the code to tackle #48907 and that gets confusing real fast haha <lfam>I see, I haven't dug in to that bug <efraim>lfam: `time guix build --no-grafts rust --with-input=source-highlight=hello` on master worked, so I assume we can at least drop source-highlight from gdb/pinned, although then we should probably rename it gdb-minimal/pinned <lfam>Is there a branch / team where that would belong? <lfam>Assuming we don't want to rebuild core-updates now <lfam>Maybe we still have to, dunno <lfam>Changing the subject, what do we think is the best "intro to how Guix organizes and installs packages" video these days? <lfam>It's helpful to grok the point of all the weird hashes <efraim>I assume I'm merging rust-team after core-updates, otherwise I could do it there <freakingpenguin>It probably complicates things conceptually that some packages are tracked with multiple versions, e.g. glibc <lfam>Gotcha. I'm out of the loop w/r/t what branches are deck, efraim. I just decided to try to upgrade and report bugs <spenc>im open to any sort of article, feel like I read a lot of them at this point :p always happy to have another <lfam>Yeah, it happens spenc :) <spenc>once (if) i get a decent handle on this i'd be happy to try writing a guix for npm devs type article or something <lfam>Do you have a sense of how Guix organizes packages and installs them into profiles? <efraim>I'd report the boost bit on guix-devel and tag it core-updates. not sure where to go after that. I can mess with gdb/pinned at some other point <lfam>Yeah, I reported it in the "test core-updates" thread. Do you think I should start a new thread? <spenc>the hashes themselves make a lot of sense, it's like a version number but more preceise since it includes all the inputs, i get why thats super handy since it means you can specify exactly everything that goes into a package <lfam>It's only one package, really (libreoffice), but it's an important one <lfam>And then you can precisely refer to the entire dependency graph that was used to build something <spenc>profiles i havent tried using yet, only been using guix shell so far, which has been great for development <spenc>it seems useful for putting things that you'd have insalled in though, like ive been calling guix shell appname -- appname which is kinda silly <lfam>Profiles come into play even with `guix shell`, although they are less visible. They really matter once you start doing `guix install`, `guix upgrade`, and other `guix package` operations. Kinda like a "normal" distro where you just install packages <lfam>We all do, it's nice to not "pollute" your profiles, and instead work ephemerally <lfam>It just depends on your goal. Like, I know that I always want my music player installed, so I did `guix install mpd` years ago, and now it's always there for me <lfam>But if I just want to try something out, I use `guix shell`. And then later, when I need to reclaim disk space with `guix gc`, the things I just tried out are deleted, whereas I can be more intentional about managing the history of my mpd installation <lfam>I lost track of what the question was :) <lfam>Well, the good news about libetonyek is that, even when we fix it, libreoffice still fails to build with "fatal error: crypt.h: No such file or directory" <spenc>me too :p, ok last question for a bit <spenc>so the reason I tried out guix in the first place was because I was having trouble trying to compile two different peices of software, each of which using some shell script i didnt want to edit that called g++ <spenc>one needed a new version of g++, and one needed g++ and gnat to be the same version, and gnat was lower <spenc>so it seemed like the best way forward was either docker or guix, to give each of them an environment where they could be happy <spenc>and guix is just so lovely and the philosophy and care behind it is inspiring <spenc>but is that something that guix is intended for? I had at first thought that it would be easy to whip up a manifest or guix.sc to bascially just say which versions each of them would need, like a python venv or dockerfile, but ive been having a lot of trouble piecing together the right way to do something like this <lfam>To clarify, you want to build two different programs, each depending on a different version of g++?