<podiki[m]>would one expect (should?) that guix shell ffmpeg@4 ffmpeg@5 or with the versions swapped would be different? <podiki[m]>in other words, order matters in the package list, the last one "winning" in this conflict <podiki[m]>ls -la $(which ffmpeg) will show the last listed one <podiki[m]>this is a silly example, but say you are using the --development option and the inputs are different versions than other packages specified <nckhexen>I think that's a good example, because with the previous one it would be obvious what's happening (and one could more easily defend it as ‘user-controlled’), but the latter is just confusing. <nckhexen>That said, the whole ‘pick an arbitrary (if not technically random) winner’ behaviour has always been a bit of a good-enough stopgap. I don't think anyone considers it ideal. It's not hard to prick holes in it. <nckhexen>podiki[m]: Actually, I think this behaviour is fine, but Guix should warn about it (by name—so it's clear if different versions are smuggled in through -D). <podiki[m]>nckhexen: sorry, you meant the --development example (which I should find an actual packages) is the potentially confusing one since it is more implicit? <podiki[m]>as in you don't see the conflict from what you typed in the command <podiki[m]>I have to check this is what happens, but I believe so. the manifest is ordered by the packages/options given, so I think the last one wins <nckhexen>Yes. Because the conflict isn't as obvious as ‘guix shell foo@1 … foo@2’ (even if there's a lot in between, it's still explicit). <podiki[m]>for a real world example right now, guix shell -CFD hello is different than guix shell -CD hello -F (the glibc package, look at /lib/ld*) <podiki[m]>nckhexen: okay, yes agreed. would you happen to know some packages with different input versions? I was trying to find some simple example that's not like llvm versions or something <nckhexen>I'm not familiar with how -F is implemented. So it's positional, almost like an alias for ‘SOME EXTRA PACKAGES --also-symlink-stuff’? <podiki[m]>but I made it smuggle in the glibc-for-fhs package to have one that reads the global ld cache <podiki[m]>but that led me to seeing that more generally package order matters <podiki[m]>here I would opt for just making glibc-for-fhs the last package to ensure it is the one in the container for fhs <podiki[m]>so the problem is that -F alters the package list and options are parsed in order (or at least in relation to package list) <nckhexen>I think embracing the strength of ordered lists over sets (like Nix—so then they retrofit cardinality as numeric ‘priorities’, and it's as horrible as it sounds) is fine. Just being a bit more explicit about ‘hey, you know element 5 shadows element 2, right? OK just checking enjoy’ to help users. <nckhexen>podiki[m]: Right. That's what I expected (after you pointed that out :) <podiki[m]>I was surprised, I expected there to be a profile conflict giving two packages with different versions <nckhexen>I don't think Guix is entirely consistent about those. <nckhexen>Had you asked me before ‘will this throw an error’, I wouldn't have bet moneys. <podiki[m]>perhaps it is a union-build thing, where conflicts can be ignored <jab>podiki[m]: thanks for trying the rust import bit. I had forgotten that we have a rust importer. <podiki[m]>jab: sadly it didn't do much for that package but i do think the rust one is pretty decent? seems to get usage <jab>podiki[m]: I am fairly excited for our guile written alternative to cargo. That's pretty freaking awesome if you ask me. :) <podiki[m]>nckhexen: thanks for discussing. so there is an improvement to be made with shadowing (for lack of a better word) packages in shell, documenting/warning <podiki[m]>and then an actual bug that the FHS container won't work as expected based on order of arguments <nckhexen>That sounds like a good summary of what I've understood. <podiki[m]>the FHS adding a package code was moved in a later commit due to some profile caching bug, which I don't understand well enough to have a concrete fix here <nckhexen>Moved to work around a bug or moved because it was a bug? <podiki[m]>the argument handling happening in guix environment rather than guix shell was leading to a profile caching bug (after profile cached it would error the next time) <podiki[m]>but makes me realize I don't know what is going on there exactly (Ludo made the fix) <podiki[m]>perhaps some work to be done in the general realm of profile making from guix shell <podiki[m]>I'm also not sure why I never hit that bug when I was using the same profiles for guix shell with FHS a lot in my testing <podiki[m]>(oh maybe it was when you use the -p option explicitly? don't remember) <nckhexen>I'm surprised Ludo' didn't write a test case for it :) <podiki[m]>but no, it didn't come up in our discussions, just to test the things FHS does <nckhexen>Oh, I just meant for that specific bug after it was discovered. <podiki[m]>though maybe shouldhave done all the container tests with -F as well... <nckhexen>I didn't mean to imply you didn't thoroughly test things. <podiki[m]>the commit in question did mention what to do that caused the bug and I thought I would have hit it...hopefully not something more mysterious in there <podiki[m]>no worries nckhexen, I can see the value of more tests even if I haven't done formal tests before; i'm always worried I will break something unexpected <piethesailor>Anyone familiar with an error during an install (nyxt) that results in this /gnu/store/xxxxxxxxxxxxx-inkscape-1.1.1.drv 49%[####### ] <piethesailor> guix install:error corrupt input while restoring archive from <nckhexen>Or that, depending on the answer, indeed. <nckhexen>piethesailor: Can you paste(.debian.net) the exact output? <nckhexen>It might be a truncated nar on the server. Or another bug that can't just be retried around. <piethesailor>That is the exact output, unless you want me to list the other two build processes before it <nckhexen>Er, pardon my language, but I like that game. <nckhexen>piethesailor: There's nothing more? No URLs? No downloads? ☹ <nckhexen>unmatched-paren: But I don't see any overlap with wesnoth committers… (didn't look far back). <piethesailor>I just run, guix install nyxt. it then goes on to list a bunch of /gnu/store/xxxxxxxxxxxxxx/whatever.drv's.. after "the following derivations will be built:. then it successfully gets through, building libsoup, then building fcitx, and then <piethesailor>/gnu/store/xxxxxxxxxxxxx-inkscape-1.1.1.drv 49%[####### ] <piethesailor> guix install:error corrupt input while restoring archive from <nckhexen>Fair warning, if you paste just one or two more lines the bot'll get ya. 😉 <nckhexen>piethesailor: Still, could you paste the entire output there? This isn't something we can work with. <unmatched-paren>fortunately it doesn't look to be far on in development, so we can ignore it for now... <nckhexen>unmatched-paren: Hm… I'm still ‘optimistic’, something about this doesn't feel like it has critical mass. See also who's filing issues. But I don't follow Wesnoth development, don't know who's who, might be wrong. <nckhexen>And then there's the usual mortality rate of second-system rewrites. <nckhexen>piethesailor: Well, or at least enough actual hashes (no xxxxx) and information to reproduce this ourselves. But ideally everything, so you don't have to care what's what :) <nckhexen>unmatched-paren: We're both doing it, or presumably you are too, because we *like* it. <nckhexen>If their blog tomorrow posts ‘Exciting news! We're being aquired by Valve! 🚀❤️’ I'll happily wish them worse without feeling bad about it. <nckhexen>I think I might call it an early night. Sweet dreams, all. <nckhexen>(piethesailor: Your paste is still appreciated. If it's a server issue, I'll fix it tomorrow.) <piethesailor>Too long to describe but I'll get the pate bin here in a moment <piethesailor>Same issue as I have previously mentioned. I am getting an error trying to guix install nyxt <podiki[m]>Can you paste the output of guix describe? (And have you done guix pull recently?) <podiki[m]>hrm, guix weather says substitute for nyxt, but trying in guix shell it is downloading a ton of stuff.... <podiki[m]>I do have bordeaux as my first substitute server, so you could try with --substitute-urls option maybe? <podiki[m]>though it didn't have a sub for nyxt itself...odd <podiki[m]>you can add the standard htts://ci.guix.gnu.org in there as well <podiki[m]>welcome! though recent installs should have that server enabled already, if you put it first in the list maybe it prioritizes <podiki[m]>but I am confused a bit, maybe a bad nar on ci or some bad network somewhere <piethesailor>I've never used that command before, so let me try to describe what I get <podiki[m]>what commit are you on for guix? I get sub showing with guix weather (on ci.guix, not for bordeaux) <podiki[m]>if you pulled a few days ago that could be why, I see new builds with a staging merge a few days ago <piethesailor>I've tried guix install nyxt 10's of times with the same failure <piethesailor>I also loaded nyxt just fine a bout a month and a half ago <piethesailor>again it has worked, ran nyxt without issue. I also have loaded a number of other softwares without issue from guix <podiki[m]>there were some issues with rust updates and many other things I think in motion; I would file a bug and/or email guix-devel since there is conversation there about getting set for 1.4.0 and what is supported well <podiki[m]>(maybe read the recent threads to see where it is at) <podiki[m]>but I'm sure your experiences and failures/successes will be helpful to improve <podiki[m]>and I see some waiting builds for aarch64 on the CI so maybe some updates/prodding needed there too <piethesailor>we'll see what happens. Nyxt renders webpages really well on the phone so hopefully this gets working soon! <podiki[m]>I think they don't get as much feedback on non x86_64 breakages <podiki[m]>you might consider using inferiors (pinning to a commit) when you have something that works well, if there is frequent breakage <piethesailor>that sounds like a good idea. Any recources on doing that? <zpiro>IRC is banned at CERN, one of the only ways is from a hostname that includes ali-gw, and ali for ALICE with cern.ch, and I did this because it felt important to bitch and complain for RDMA support in Ceph. <zpiro>Somebody here may be a little bit paranoid, as windows IT guy being sent the right way, loving the rabit hole of good things to know. <apteryx>mcron update sent; if someone would like to get fancier job logging <Korven[m]>anyone know why my foreign distro can't see the fonts I installed using guix? <ghostarchist[m]><piethesailor> "anyone here run agate?" <- I haven't yet, I've been looking into both gemini and rust, so I figured that was a good project for both <Korven[m]>Can I use `local-file` for directories too? I have set `#:recursive #t`, but the files inside the directory don't seem to be symlinked, but rather just copied <Korven[m]>well they are read-only, so I guess that's that? <Korven[m]>mhm, that's true. I thought since it copied the thing to store, the contents of the dircetory would be symlinked as well <unmatched-paren>Korven[m]: i think symlinked directories don't treat their contents as symlinked <VesselWave>Hello, is there any way to shutdown or reboot without sudo in shepherd distro? <madage>echo "shutdown" > /sys/power/disk <madage>-rw-r--r-- 1 root root 4096 out 29 05:15 /sys/power/disk <cbaines>hmm, issues.guix.gnu.org isn't working for me <VesselWave>unmatched-paren: `loginctl reboot` works, but shutdown doesn't <unmatched-paren>VesselWave: i'm not using elogind, i'm using seatd, so i don't have loginctl <jeko>anyone using guix home to configure emacs with use-package extension ? <jeko>oh no, it's not only use-package 's fault <VesselWave>VesselWave: seatd isn't even in manual, but it is in guix system search. Wow, I thought no systemd is hard, but even no elogind <phodina[m]>unmatched-paren: Any tips what to check out? I can run the Sway WM there so I guess it's something in the GDM and it's setting of the wayland env. <VesselWave>`dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 "org.freedesktop.login1.Manager.PowerOff" boolean:true` <VesselWave>`dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 "org.freedesktop.login1.Manager.Reboot" boolean:true` <Korven[m]>Anyone using `starship` around here? I'm wondering if you have a package for it, or did you just build the binary from source <phodina[m]><Korven[m]> "Anyone using `starship` around..." <- Yes, it's not yet packaged besides the `rust-starship-module-config-derive`. Would you be interested in checking and testing the patches? https://github.com/phodina/guix/tree/patch/starship-1 They've been gathering dust so I could refresh the versions of those packages as well. <Korven[m]>phodina[m]: Yes, I'd be glad to! I was actually thinking of building a package myself (local) since I didn't find one XD <phodina[m]>Okay, I'll try to rebase the package on latest master, refresh the packages (as some might be merged already) and send patches to guix upstream - which you can also test <phodina[m]>Korven[m]: Either checkout the commit or rebase - but there will be definitely conflicts :-) <Korven[m]>Like checkout a commit for guix? as in a channel commit right? <Korven[m]>oh were you going around adding the various packages required for building starship first? <phodina[m]><Korven[m]> "Like checkout a commit for guix?..." <- I guess you can add the channel, haven't done that. I just use it for upstreaming packages. So clone and checkout the branch, build it locally. <phodina[m]><Korven[m]> "oh were you going around..." <- Yes, it should have all the required Rust packages. But it needs some more work like formatting and fixing the desc/synopsis. <Korven[m]><phodina[m]> "Yes, it should have all the..." <- I tried using import crate, and that is *alot* of dependencies it has lmao <phodina[m]>Korven[m]: I used this approach also and then went step by step to fix all the dependencies and commit them separately <Korven[m]>lemme know when you think it's ready to be tested! (ping or DM, either is fine) <jeko>Hey Guix ! I wonder why I have a process .emacs-28.2-rea still alive after I closed Emacs ? <jeko>Oh right… Gnome has two emacs options in its laucher and I used the one that spawn the daemon <unmatched-paren>so that you can use emacsclient -c to start windows without reloading it... <jeko>I ended up with 4 daemons running and no idea how to kill them, so I rebooted and I am paying attention now <jeko>Haha, actually, I am trying to setup the home-emacs-service-type from guixrus. <jeko>Right now, I reconfigured and then I can see there is one daemon running (+ a flaky one) <jeko>but running emacsclient does not get it <jeko>Yup, that's what I mimic haha <jeko>(service home-emacs-service-type <jeko> (home-emacs-configuration <jeko> (packages jeko/emacs-packages) <jeko> (init-file (local-file "../etc/emacs.d/init.el")) <jeko>`ls .em*` does not find anything <Korven[m]>I wonder how code blocks on matrix show up on IRC <Korven[m]>*i'm also guessing this Matrix room is bridged to the official IRC channel <Korven[m]> * *i'm also guessing this Matrix room is bridged to the official IRC channel* <nckhexen>Yes. See logs.guix.gnu.org for how it appeared. <unmatched-paren>kori: I think they show as links to some raw matrix text hosting service, most of the time... <nckhexen>Korven[m]: The long answer is, when using this bridged channel, try to remember not to use them if you can, they serve no purpose here & just add formatting noise. <nckhexen>And frankly, I often don't click those ‘foo[m] has sent a long message, quick, click here to learn more about this exciting event!’ things. <nckhexen>jeko: Heyo! Ooh, emacs.d fun. Not getting involved in that… <jeko>nckhexen what do you mean? <jeko>unmatched-paren if i remove the home-emacs-service-type from the configuration and reconfigure my home, the daemon still appears to be alive while not consuming any gpu <nckhexen>jeko: Just that despite being an emacs user its whims confuse & frighten me. And this looks very whimsical. <jeko>(I can see that with the system monitoring from Gnome) <nckhexen>I'm kind of surprised you can run 4 daemons without some socket being fought over. <jeko>nckhexen i think the socket is somewhere but emacsclient does not find it, neither do I <jeko>As it works for someone else, I assume there is something wrong with my system haha <unmatched-paren>jeko: Hmmm... I think I actually may have had this issue before, idk... <Korven[m]>Migrating profile generations to '/var/guix/profiles/per-user/karan'... <Korven[m]>guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/karan/current-guix" <Korven[m]>any ideas what's up? it was working fine yesterday <nckhexen>Grr, that's a bug in some one-time migration code. <nckhexen>I don't remember the work-around, but running ‘realpath "/var/guix/profiles/per-user/karan/current-guix"’, then removing it, then invoking ‘$THAT_REALPATH pull’ should work IIRC. ***Dynom_ is now known as Guest2841
<Korven[m]>wdym by removing it? /gnu/store is Read Only right? <nckhexen>I meant removing the /var/guix… symlink, sorry. <nckhexen>…or maybe not symlink. I really don't remember :) <nckhexen>But it's safe to remove, you can't delete your last copy of guix this way. <Michal_Atlas[m]>Thank you very much.... Interesting, this makes sense, and would be what I wanted to settle for if i didn't find another solution, however it doesn't make sense to me then why ext4 worked <nckhexen>That's why I'm not sure it's your issue. I thought perhaps you meant you recreated the container (using new defaults, so LUKS2) but manually specificied the old UUIDs. <nckhexen>I stopped using LUKS well in the v1 days, so I'm not much help. <Michal_Atlas[m]>Nono, I wiped everything, I mentioned the old setup because it feels like the most likely culprit would usually be a typo or accidentally putting in the wrong uuid and things like that <Michal_Atlas[m]>Hmm, and you don't use disc-encryption at all, or do you use the inbuilt features of other filesystems? <nckhexen>Hm, OK, so you mean it definitely worked with ext4 and LUKS2? <Michal_Atlas[m]>I did have to input the password 3 times, Grub prompted me for decrypting the main boot partition before going to the grub prompt, after which it booted a system and that asked again but it did boot <nckhexen>Michal_Atlas[m]: I'm currently using built-in file system encryption, but it's more for ‘fun’, I'd be fine with no encryption and did that for a while. <nckhexen>And 2 is ‘expected’, 3 is not, unless you mount other LUKS volumes during Linux boot. <Michal_Atlas[m]>Actually 4 times but, twice before grub but you can just press enter since the home partition doesn't matter if it fails to mount for grub to work <nckhexen>It's frustrating when people refuse to, but it's normal to forget, there are so many variables. <Michal_Atlas[m]>Okay, Imma probably just create a separate non-Luks boot partition then, that should resolve the issue shouldn't it? <nckhexen>It is equally frustrating that I can't help you beyond ‘try LUKS1 first, it's still sufficiently secure’ to exclude the most likely issue. <nckhexen>Michal_Atlas[m]: Mmm. Then you have to manually copy the kernel & initrd to it, there's no automated service for that yet. <nckhexen>I can point you to one we use on the Guix build farm, but it's pretty hacky. <nckhexen>And then you'll have to debug that if it breaks… <nckhexen>A lot of this ‘non-standard’ stuff is just TODO in Guix, that's just the way things are. <nckhexen>To recap, I still recommend using LUKS1 for now, it's not broken. But a separate /boot can work *if* you manually manage it, too. /me AFK. <Michal_Atlas[m]>Okay, I've read through the post you sent and will try LUKS1 didn't know that was an option, thank you again. <yarl>I am playing with `guix system container` <yarl>I don't understand why I can't bind to port 80? <yarl>As I am running the container as root (via sudo) ***kraai_ is now known as kraai
<civodul>yarl: hi! did you run "guix system container --network"? <sneek>civodul, you have 1 message! <sneek>civodul, cwebber says: omg thanks for putting the scheme primer on top of the learning guile page! amazing *cwebber working on getting terminal phase ported to guile again today <cwebber>soon terminal phase will be packaged in guix I hope :> <nckhexen>Hmm: ‘while setting up the build environment: a `powerpc64le-linux' is required to build $tuff, but I am a `x86_64-linux'’. Certainly true, but why does this not apply to aarch64? Is this because the Nix system (powerpc64le) doesn't match the qemu platform (ppc64), or is there some long-forgotten place where I added aarch64 once? (I grepped but found not.) <nckhexen>…asking public questions sure is a great way to spot typoes. <civodul>nckhexen: you need "ppc64le" for qemu-binfmt-service-type <piethesailor>Okay, last things I'll bring up for awhile lol. I have followed these insrtuctions to the T. I am getting an unbound variable for "agate-service-type" in step '- Use "guix system reconfigure /etc/config.scm' to install agate. Any tips? <piethesailor>Also tried 'guix install agate' but getting the unbound variable error still <piethesailor>of course running 'agate --content /x/x/x --key /x/x/x --cert /x/x/x' works fine. Just tring to learn guix <civodul>piethesailor: hi! re "unbound variable", i think you need to add (use-modules (gnu services web)) at the top of your config <Korven[m]>Anyone know how I'd create essentially a new guile project? I want to have modules like `(core main)`, `(core pkgs)` etc. for my home config, but don't really know how *nckhexen couldn't find the Guix 0.1 release announcement… because it's on nix-dev. ☺ Oh, those changing times. <Korven[m]>So an Emacsc question, I installed a package, `(emacs-vterm)` using guix. Now I can't figure out how to actually load it into emacs so i can do `(require 'vterm)` <yarl>How did you (who?) choose what to enable for php configuration? Here for example, I need --with-soap. I know that in some distros, there are packages like "php-soap" that gives you this as a module, I see no such module in guix packages. Is it a decision to not package php-something? <Korven[m]><Korven[m]> "So an Emacsc question, I..." <- ok so the solutin was logout login XD <gyps>Anyone have an idea why linux (5.19) as well as ubuntu (5.14) do recognize the intel-backlight of my X1 while linux-lts (5.15) does not? <WatchmanGee[m]>ubuntu might be patched so even though it's a previous version than lts (whose lts is that?) it has the hardware support <gyps>Ups. Wrong channel. ( nongnu ) <oknw>where can i find documentation for the configuration options of certain services? wpa-supplicant-service for example <klavul>Anybody uses clojure on GuixSD? On fresh system or in guix shell can't get lein repl to run. <ghostarchist[m]><klavul> "Anybody uses clojure on GuixSD..." <- I think you're going to have to go to nonguix chat for that since lein in the nonguix repo <nckhexen>yarl: It's going to end up being some variant of ‘nobody needed PHP SOAP yet’. Modular PHP packages would probably require some work adding search paths, whilst adding configure flags when one needs them is relatively easy. <rekado>why is leiningen in nonguix? It’s free software. <antipode>100% (after rounding) of antioxidated packages build (albeit with a few TODOs)! <piethesailor>civodul, I tried your suggestion and now I am getting a use-service-modules unbound variable error <civodul>antipode: thumbs up for antioxidant! <antipode>Next step: "guix style"-fu to move it outside the channel, as direct source code stuff, integrating it in Guix proper. <nckhexen>Heh: ‘If the [rsync] --version option is repeated (e.g. -VV) then the information is output in a (still readable) JSON format.’ <jeko>Just because Gnome system monitor does not find my swap, I run `blkid` as root and it returns `/dev/sda2: UUID="7fd62cc0-5f54-49b1-b740-bd5f98233978" TYPE="swsuspend" PARTUUID="c2f7657f-577d-4b17-b378-49ec1ffacea5"` why is it suspended ? <nckhexen>We can't really know. You hibernated… somehow. <two[m]>jeko: i think it means it's used for saving whole ram contents in suspend to disk mode <nckhexen>You'll want to mkswap it to prevent any nasty (*nasty*) surprises if your next bould would try to resume from it. <nckhexen>Have you been playing with hibernation? /sys/power/disk? Specifically, test_resume? <nckhexen>(Or hibernating without a resume= parameter?) <jeko>I did not play with anything related to that. i might have hibernated but don't remember exactly <jeko>the silliest thing that could have happened is I hibernated and let the battery running out of power. <nckhexen>There's ‘hybrid sleep’, which hibernates but then stays awake to resume quickly, but the point of that is exactly to protect against the battery draining, so that's not it either. <jeko>so I could "reset" the swap partition ? that's what you meant ? with mkswap ? <nckhexen>So your system is set up to resume from hibernation? (resume= kernel argument?) <jeko>I can't answer as I don't know where to look for haha '=D <nckhexen>But it's not something Guix ever does for you. <jeko>indeed, in my case, it's not <jeko>ok so i will look for a mkswap <jeko>thank you for your guidance nckhexen and two[m] <nckhexen>The fact that Linux lets you hibernate without having a resume device set up (+ some escape hatch, fine) is madness. <lilyp>pfft, setting up a resume device is for the weak <nckhexen>Resume device? This is Spaar—hm no that doesn't work. <lilyp>More like "What am I? Your parent?" <nckhexen>I have played with the idea (& some code) to just scan all swap-devices for the swsusp header instead of relying on a hard-coded resume=, but that assumes you run only Guix System. More importantly, it turns ‘yeah, the kernel is stupid and fragile, sorry’ into actually our problem, which is probably a deal-breaker. <cwebber>I did fix a memory leak bug in fibers once also... unless in fixing it, I created the one you're now experiencing ;) <cwebber>it was a fun debugging situation to figure it out I remember <civodul>cwebber: looking at the compiler at this point... <civodul>i have a reduced test case that triggers the problem at -O2 but not -O1 <lilyp>digging into compiler optimizations is always fun :)