IRC channel logs


back to list of logs

<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’?
<nckhexen>podiki[m]: Not off the top of my head.
<podiki[m]>well it shouldn't be :-)
<nckhexen>I agree that's a bit too surprising.
<podiki[m]>but I made it smuggle in the glibc-for-fhs package to have one that reads the global ld cache
<podiki[m]>yeah, it shouldn't be like that
<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]>great, will file, as separate bugs I think
<nckhexen>Thank you!
<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]>so, causing a bug it seemed like
<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]>....I wrote the tests for -F....
<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.
<nckhexen>You clearly did.
<podiki[m]>you didn't need to imply, it is true :)
<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
<piethesailor> socket
<unmatched-paren>piethesailor: that's just a transient network error
<nckhexen>Is it consistent, piethesailor?
<nckhexen>Or that, depending on the answer, indeed.
<piethesailor>Yes I have tried 10's of times
<piethesailor>it is always on inkscape
<nckhexen>piethesailor: Can you paste( the exact output?
<nckhexen>It might be a truncated nar on the server. Or another bug that can't just be retried around.
<unmatched-paren>oh no. wesnoth appears to be being rewritten in c#.
<nckhexen>What the shit.
<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.
<unmatched-paren>and the repo has been recently updated :s
<nckhexen>piethesailor: There's nothing more? No URLs? No downloads? ☹
<unmatched-paren>so it's not an abandoned project...
<nckhexen>Oh, so it's more of a fork?
<unmatched-paren>nckhexen: it appears to be version 2.0
<unmatched-paren>so, it's being rewritten in C# with godot for 2.0...
<unmatched-paren>this will be another mindustry, i suppose.
<nckhexen>unmatched-paren: But I don't see any overlap with wesnoth committers… (didn't look far back).
<unmatched-paren>it seems to be developed under Byteron/ now
<unmatched-paren>but it does look official...
<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
<piethesailor> socket
<piethesailor>sorry for multi line. wont post again
<nckhexen>Fair warning, if you paste just one or two more lines the bot'll get ya. 😉
<nckhexen>(Not now; chat away. I meant at once.)
<piethesailor>Good to know. thanks nckhexen
<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.
<unmatched-paren>nckhexen: Yes, I kind of hope it stalls...
<piethesailor>Thats going to take 20-30 minutes
<unmatched-paren>Kind of.
<piethesailor>will be back
<piethesailor>The Librem 5 is a little slow
<unmatched-paren>Seems a bit cruel to wish death on a project, but...
<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.
<unmatched-paren>bye \o
<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>your help is also much appreciated
<podiki[m]>nckhexen: night!
<piethesailor>Okay I am back
<piethesailor>Same issue as I have previously mentioned. I am getting an error trying to guix install nyxt
<piethesailor>The install always fails when trying to load inkscape
<podiki[m]>Can you paste the output of guix describe? (And have you done guix pull recently?)
<piethesailor>yes guix pulled yesterday
<piethesailor>One moment on the other paste
<piethesailor>Generation 13 oct 26 2022 17:03:42 (current) guix c07b55e repository branch master commit: xxxxxxxxxxx
<podiki[m]>hrm, guix weather says substitute for nyxt, but trying in guix shell it is downloading a ton of stuff....
<podiki[m]>but it did download and ran just fine
<podiki[m]>I do have bordeaux as my first substitute server, so you could try with --substitute-urls option maybe?
<piethesailor>so guix install nyxt --substitue-urls?
<piethesailor>should I add something after the --substitute-urls?
<podiki[m]> --substitute-urls=""
<podiki[m]>though it didn't have a sub for nyxt itself...odd
<podiki[m]>you can add the standard htts:// in there as well
<podiki[m]>just put a space between them
<piethesailor>okay, booting up the Librem 5 and will give it a try
<piethesailor>i'll report back soon
<piethesailor>thanks for the tip!
<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]>you can check with guix weather nyxt
<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
<piethesailor> 0% substitutes available (0 out of 1)
<piethesailor>and 100% substitutes available(1 out of 1)
<podiki[m]>what commit are you on for guix? I get sub showing with guix weather (on ci.guix, not for bordeaux)
<podiki[m]>yeah the opposite here :-P
<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 have had this problem for weeks
<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>it only started failing on an update
<podiki[m]>on x86_64 right?
<podiki[m]>well then
<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]>possibly non-deterministic failures too
<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>oops aacrh64 typo
<piethesailor>not aarm64 lol
<piethesailor>aarch* yeah just sent an email
<piethesailor>we'll see what happens. Nyxt renders webpages really well on the phone so hopefully this gets working soon!
<podiki[m]>great, thanks
<podiki[m]>I think they don't get as much feedback on non x86_64 breakages
<piethesailor>Thank you for your help
<podiki[m]>wish I could do more
<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?
<piethesailor>Though I can look it up honestly lol
<podiki[m]>and the cookbook has info about manifests to reproduce a given state (and earlier in that section)
<zpiro>IRC is banned at CERN, one of the only ways is from a hostname that includes ali-gw, and ali for ALICE with, 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.
<piethesailor>anyone here run agate?
<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?
<jamesw>Hi, 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?
<unmatched-paren>Korven[m]: local-file copies the thing to the store
<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
<Korven[m]>but I guess that's not really needed
<unmatched-paren>Korven[m]: i think symlinked directories don't treat their contents as symlinked
<Korven[m]>fair :)
<VesselWave>Hello, is there any way to shutdown or reboot without sudo in shepherd distro?
<unmatched-paren>VesselWave: i've wondered the same for a while
<madage>echo "shutdown" > /sys/power/disk
<madage>echo "reboot" > /sys/power/disk
<madage>-rw-r--r-- 1 root root 4096 out 29 05:15 /sys/power/disk
<cbaines>hmm, isn't working for me
<VesselWave>unmatched-paren: `loginctl reboot` works, but shutdown doesn't
<cbaines>ah, no, just Icecat playing up
<unmatched-paren>VesselWave: i'm not using elogind, i'm using seatd, so i don't have loginctl
<jeko>Hey Guixters !
<jeko>anyone using guix home to configure emacs with use-package extension ?
<jeko>oh no, it's not only use-package 's fault
<jeko>never mind
<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
<VesselWave>* unmatched-paren: ^
<unmatched-paren>VesselWave: it is in the manual
<unmatched-paren>ah, you must be using the ancient "release" manual
<unmatched-paren>you need to use the "devel" manual
<phodina[m]>Does somebody run Gnome Shell on wayland on their desktop?... (full message at <>)
<unmatched-paren>phodina[m]: i used to
<unmatched-paren>phodina[m]: that didn't happen to me
<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.
<unmatched-paren>phodina[m]: sorry, i have no idea
<VesselWave>unmatched-paren: Thanks now I use devel manual. I've tried solution from reddit about sudoers: . It doesn't work.
<VesselWave>Try this
<VesselWave>`dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 "org.freedesktop.login1.Manager.PowerOff" boolean:true`
<VesselWave>and this for reboot
<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? 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
<Korven[m]>how do I test it tho? just build and go?
<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.
<jeko>Yo Guixters !
<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 ?
<unmatched-paren>jeko: are you using it in daemon mode?
<jeko>Oh right… Gnome has two emacs options in its laucher and I used the one that spawn the daemon
<unmatched-paren>the daemon should almost always be used anyway :)
<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
<unmatched-paren>jeko: emacsclient --eval "(kill-emacs)"
<unmatched-paren>or use this ;)
<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
<unmatched-paren>jeko: Ah, I added that one.
<unmatched-paren>Odd that it doesn't work.
<unmatched-paren>Works For Me(R)... :)
<unmatched-paren>jeko: here:
<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>             (debug? #t)))
<unmatched-paren>jeko: please use for code :)
<unmatched-paren>do you have a ~/.emacs.d?
<unmatched-paren>and/or a ~/.emacs?
<jeko>`ls .em*` does not find anything
<unmatched-paren>really? ``test -f ~/.emacs && echo it exists''?
<unmatched-paren>and same for emacs.d
<Korven[m]>I wonder how code blocks on matrix show up on IRC
<Korven[m]>(define (hello) "Hi there")
<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*
<Korven[m]>* IRC channel*
<nckhexen>Yes. See 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>Morning, Guix.
<jeko>nckhexen o/
<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?
<Korven[m]>okay they just appear raw
<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.
<nckhexen>jeko: They're not zombies, right?
<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...
<unmatched-paren>have a look at ~/.local/var/log/emacs.log
<Korven[m]>I'm getting this when trying to `guix pull`
<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.
<nckhexen>$THAT_REALPATH/bin/guix or whatever.
***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.
<test1234sa[m]>try to guix gc, maybe help
<Korven[m]>will do
<Michal_Atlas[m]>Hello, I've been trying to `system init` a Luks+Btrfs setup but grub ends up with "error: no such device: <uuid of physical luks partition>" and "error:unknown filesystem.".... (full message at <>)
<nckhexen>Michal_Atlas[m]: Could it be ?
<nckhexen>Using LUKS2 is known to be problematic.
<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
<Michal_Atlas[m]>Sorry by boot I mean the one required for that, so the root one
<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>Michal_Atlas[m]: 3 times? Not 2?
<Michal_Atlas[m]>Yeah, tbh, this is mostly for educational purposes
<nckhexen>(You only listed 2 IIUC.)
<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>The odd number was throwing me off :)
<Michal_Atlas[m]>I'm so sorry, I keep forgetting to mention details like that
<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>Hi guix!
<yarl>I am playing with `guix system container`
<yarl>For example
<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>hi civodul !
*cwebber working on getting terminal phase ported to guile again today
<cwebber>which means
<cwebber>soon terminal phase will be packaged in guix I hope :>
<civodul>hi cwebber :-)
<civodul>that's exciting
*civodul is debugging a nasty Fibers issue:
<cwebber>civodul: yeeeeeek
<cwebber>civodul: good luck
<civodul>yup, i'll need luck :-)
<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>s/qemu/&-binfmt/ but you get the gist.
<nckhexen>…asking public questions sure is a great way to spot typoes.
<civodul>nckhexen: you need "ppc64le" for qemu-binfmt-service-type
<civodul>& hi! :-)
<yarl>civodul: yes :)
<nckhexen>civodul: That was the typo.
<nckhexen>I mean, thanks :)
<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>Here is the 'services section in my config.scm,
<piethesailor>of course running 'agate --content /x/x/x --key /x/x/x --cert /x/x/x' works fine. Just tring to learn guix
<piethesailor>side of things
<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.
<antipode>The doesn't seem to be fully working, there are lots of unstarted scheduled builds at even though almost all hydras are idle (
<rekado>why is leiningen in nonguix? It’s free software.
<rekado>is this a bootstrap problem?
<ghostarchist[m]>rekado: that's what I gathered from the open issue about it
<antipode>100% (after rounding) of antioxidated packages build (albeit with a few TODOs)!
<antipode>I've sent a small update to guix-devel
<rekado>antipode: exciting!
<unmatched-paren>antipode: wonderful, i can't wait for rust packaging to be sane :D
<piethesailor>civodul, I tried your suggestion and now I am getting a use-service-modules unbound variable error
<nckhexen>(use-modules (gnu)) ?
<nckhexen>Before it.
<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>antipode: I've restarted the nodes.
<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>Hibernating powers off the machine.
<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?)
<nckhexen>jeko: Yes.
<jeko>I can't answer as I don't know where to look for haha '=D
<nckhexen>That's a no :)
<two[m]>in /proc/cmdline?
<nckhexen>But it's not something Guix ever does for you.
<nckhexen>If you don't know, it's not there.
<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]
<jeko>see you !
<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>civodul: how'd it go so far?
<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
<civodul>so i guess it's getting... fun?
<lilyp>digging into compiler optimizations is always fun :)