IRC channel logs
2024-04-20.log
back to list of logs
<JerseyJoe>I've been trying to get my emacs daemon service working for a while and it keeps failing to create the PID. I have it set in my emacs config to create the PID as suggested by examples I found but when I run herd start emacsd it says that the pid file fails to show up <JerseyJoe>I was able to verify it's not timing out too early by increasing the timeout wait period, and the pid files shows up in the correct place when I start emacs itself manually <miaomiao>config question: i have this like written for setting up a partition for swap space: (swap devices (list (swap-space (target "/dev/nvme0n1p4")))) <miaomiao>system reconfigure is throwing a warning: "guix system: warning: exception caught while executing 'start' on service 'swap-/dev/nvme0n1p4': In procedure swapon: "/dev/nvme0n1p4": Invalid argument" <cancername>Hi! the versions of linux-libre-module-builder (6.8.x) and linux-libre (6.7.x) I am using are mismatched. How can I make the linux-libre-module-builder version match the linux-libre version? I've searched the web and IRC logs. user tschilp seemed to have the same issue, but I don't know how they resolved it. <madeleine-sydney>what's the best way to get software not installed with guix to find libraries in my ~/.guix-profile/lib? <futurile>madeleine-sydney: are you using guix on another distribution? <futurile>madeleine-sydney: are you trying to compile the other software, or use it? <futurile>try using guix shell - if you're compiling it then guix shell should set the right environment variables so that the software will find the libs <madeleine-sydney>actually, i just checked with `ldd` and it's finding other guix-installed libraries just fine (lib{m,c,gcc,stdc++}). hmm... <futurile>madeleine-sydney: so you build it inside a guix environment fine - or at least one that had some guix locations set right <futurile>madeleine-sydney: that's why I like guix shell - becuase it's repeatable - makes it easier to debug stuff <madeleine-sydney>true :3. maybe i could just make a package for what i need with `guix import` and skip the issues with foreign software. <futurile>yeah I run guix on top of ubuntu, and keepin the two very separate has become my default for avoiding confusion <Franciman>hi, is there any public explaination of why DRM is not included in ungoogled-chromium and other libre browsers? <Franciman>probably i should just learn to use spotifyd <futurile>Franciman: spodifyd --backend pulseaudio --no-daemon --verbose works for me - then I control it with my phoen <futurile>not on guix - but I think I used it on Ubuntu once - fairly sure it worked well <cancername>Hello! I'M trying to "guix package install zfs" with Linux 6.7, I downgraded from 6.8, however "linux-libre-module-builder" is still 6.8. How can I specify the version to use? <futurile>do you have the earlier version in the archive - I guess linux-libre-module-builder@6.8 ?? <cancername>futurile: I wasn't able to install it, it didn't find the package. <cancername>the /gnu/store path ends in linux-libre-module-builder-6.8.6 <futurile>cancername: if you can do 'guix search linux-libre-module-builder@6.8" or 'guix edit xxx' then it can find it - so you should be able to do guix package --install package@version <cancername>futurile: "guix search linux-libre-module-builder" gives no results and "guix edit linux-libre-module-builder" says "unknown package" <nutcase>what do I need to do, if a "make" in guix's source tree tells me "note: source file foobar.scm newer than compiled foobar.go" ? <cancername>the guix manual has a section on build systems and it said something about being able to specify the version of the linux module build system but I don't know where I would apply that <futurile>nutcase: it's telling you that you've edited the .scm file since it was last built. If you are just building a single package in the source tree then you don't need to do anything - since it's just telling you what you already know. <futurile>nutcase: if you've updated the whole of the source tree (e.g. git pull) and want to rebuild the guix daemon: make clean ; make clean-go <futurile>cancername: yeah I don't see a linux-libre-module package, it must be known as something else - I don't know about this area - you should ask on the mailing list - or maybe someone will come online who will know <nutcase>futurile: thank you, I hoped that I could avoid a full rebuild. And yes, I did a "git pull" after my last build <oriansj>it appears that ath9k-htc-firmware has been split in half and the guix reconfigure message is misleading. <oriansj>this appears to be done in 9f8e92cc7d8cbcb2709dda5f3f0287215441d939 and there is no news related to it. I am guessing everyone was assumed to be using %base-firmware rather than manually setting anything. <Franciman>i'm trying to generate a gpg key, and even if i installed pinentry, gpg keeps saying that pinentry is not installed <lilyp>stupid question, which GCC/libc version has std::format? <apteryx>cbaines: for me git branch --contains f29f80c194d0c534a92354b2bc19022a9b70ecf8 says its only on core-updates, not master <apteryx>to see in the remote branches as well <cbaines>apteryx, I don't think anything is wrong with f29f80c194d0c534a92354b2bc19022a9b70ecf8, it'll appear on core-updates since master has been merged in <cbaines>it's the related 28d14130953d868d4848540d9de8e1ae4a01a467, which is just on core-updates that's the issue <cbaines>and it's also not really about that commit, one or two odd commits wouldn't be a big deal, but over 5000 odd commits is a big deal <cbaines>it's good that they're not on master, just on core-updates, but them being on core-updates still poses a challenge <apteryx>if you diff both you'll see the change is tiny <apteryx>so it seems the 5000 commits were rebased on top of core-updates or something <cbaines>normally if you rebase some commits that make changes that have already been made, Git will help/force you to skip them <apteryx>I think as I said, what happened was that I was in the middle of a merge, and something got updated on core-updates, then I had to rebase my 'merge commit', which rebased the whole series <cbaines>that potentially explains pushing lots of commits from master, as different commits to core-updates <apteryx>while I agree the history is uglified by that, 'git diff f29f80c194d0c534a92354b2bc19022a9b70ecf8 28d14130953d868d4848540d9de8e1ae4a01a467' shows not much has changed. <apteryx>*something got updated on the core-updates remote <cbaines>right, but what about the other 5000+ pairs of "matching" commits? <apteryx>for example you are working on merging master, resolved 10s of conflicts, then someone has pushed a new commit to core-updates, preventing pushing your merge directly. Then you are faced with either: a) cancel it all and redo it all or b) rebase and have an ugly history <apteryx>cbaines: the only difference in these commits is that their hash is different, and they were resigned by me, right? <cbaines>apteryx, both of those things are different, and as you showed above, for 1 at least the content of the commit is different <apteryx>that happens for rebased commits that had conflicts resolved, I believe <cbaines>the other approach to getting a merge on to a branch where someone has pushed new commits would be another merge, but this time with the updated branch <cbaines>so you'd merge your updated core-updates with the core-updates on the remote <apteryx>I believe the history from that would be similarly ugly (but different) <cbaines>I think the 5000+ extra commits speak volumes, at least to me (over 1 or more merges) <cbaines>I don't really like merges, but they're so much better than having duplicate commits on the same branch <cbaines>while we're not in that situation yet, that's what I'd like to see avoided <apteryx>OK, I should try it next time and see what it looks like. Instead of having a long flat history of rewritten (duplicated commits), you'd have a long parallel branch with the merge commit in the graph. That does seem clearer for someone reviewing history, and has the benefit of preserving the original signatures, I think. <apteryx>I'm still not sure why the commits are *duplicated* though. <apteryx>they could be different (hash/signature), but git should be smart enough to avoid duplicating them on a subsequent merge of master to core-updates <cancername>hi #guix. I eventually "fixed" my mismatched linux module builder by defining a new ZFS package with #:linux linux-libre-myinstalledversion . I still wonder why it doesn't use the linux in the operating-system definition though. <cbaines>in the example you give above of rebasing over a merge commit, Git would take all those commits that were merged in and rebase them on core-updates <cbaines>given all the merged in commits were from master, you effectively take a bunch of commits (thousands in this case) and replay them on core-updates, changing the signature and commit hash, so while they're similar to those on master, they are different commits <apteryx>in my scenario the merge commit is local to my branch (I've just produced it). Maybe if two people try to push a merge commit around the same time and one has to rebase on it it could explain it. <cbaines>I don't think you can really rebase merge commits, and I think if you try you may get something like this, rebasing all the commits that the merge brought in <cbaines>which is fine if those commits aren't public, but these ones on master were/are <cbaines>separating the signal from the noise should be possible I think, it's just we need to come up with an approach <cbaines>it's not trivial given I think there's around ~700 proper commits on core-updates <cbaines>my attempt at trying to replicate what's on the branch just minus the ~5000 duplicate commits wasn't very successful <cbaines>so maybe rewriting it more would be better, starting a "core-updates-fixed" from master, then applying commits from core-updates to it, rewriting them as necessary <apteryx>seems a lot of work for little return <apteryx>perhaps we can drop a range of commit? <apteryx>well, we'll be rewriting other merge commits in the process that are on top I guess... <apteryx>I'm also concerned that rewriting the branch could lead to lost work (forgotten commits) <cbaines>the duplicate commits from master would need replacing with a merge from master, and yes, the multiple merges of master in to core-updates complicates things <cancername>the custom package did fix the issue, but now "modprobe zfs" doesn't work :/ <jpoiret>cbaines: that's roughly why core-updates stalled recently, sorry if I went radio silent on this <jpoiret>i noticed the same and at some point couldn't untangle anything given the scale <jpoiret>i'm not even sure how that came to be and whether i'm the culprit tbh <WyvernH>Has anyone here had any luck in getting OpenZFS to work on a /home partition of a guix system? <janneke>fwiw, in smaller project i try to never ever merge but that may not be feasible for guix <WyvernH>There's an issue #45692 https://issues.guix.gnu.org/45692 that people were saying would make ZFS a whole lot easier once it was merged. It looks like it was merged, but I can't really figure out how to use it <apteryx>janneke: rebase is the way to go for personal branches; but for shared branches you can't rewrite the public history so you must use merge <Kabouik>What do we have in Guix for Arduino/ESP32 coding and compiling? I see we have an emacs-platformio-mode, but no arduino-cli nor platformio-cli, which I think would be required. <janneke>apteryx: for master, i agree; but for any other branch it's just a question of policy afaic <apteryx>for core-updates e.g., which is long lasting, we're often multiple folks pushing to it <apteryx>so its history shouldn't be rewritten, as that'd cause problems to other contributors <WyvernH>is adding the zfs-service-type to services really all that's required? <janneke>yeah, that would have to be coordinated <Franciman>very often nscd redirects hosts to 127.0.0.1 and i have to invalidate its cache <Franciman>I think this happens when some hosts are a bit slow in answering <wakyct>Kabouik, have you found any more info on arduino/esp and Guix? I haven't looked into it yet but it's on my todo list. I just an open patch from a few years ago re: arduino <apteryx>WyvernH``: I know nothing about ZFS, but in case you're interested about CoW file system, I think there are more of us using Btrfs here. <WyvernH``>apteryx: Yes, I've been considering using Btrfs instead of ext4 for / <WyvernH``>I know a lot of people are into Btrfs and it's probably got a lot of good features I haven't looked into yet <apteryx>OK; if you have particular questions, feel free to ask, otherwise it's covered a bit in the Guix manual <apteryx>and there are system tests for it, and actual machines in use in the build farms using it (see the guix-maintenance repo) <Kabouik>wakyct: No I haven't found anything, I can just see packages for Emacs and Arduino and Platformio, either in the official channel or in the babariviere/guix-emacs channel, but I think we'd be missing the binaries for compiling and adding boards to a board manager (which I have no idea how to do in Emacs). <Kabouik>I don't have much experience with that stuff, only used Arduino IDE a few times before I moved to Guix, but now that I found a way to do some ESP32 stuff for work, I'd like a better editor and environment to do so, and now I'm in Guix so I can't use Arduino IDE anyway, so I'll need to find a solution. <Kabouik>The least wanted solution will be to use another computer for that part. <Kabouik>Edit: "Packages for Emacs and Arduino and Platformio" -> I meant emacs-platformio and emacs-arduino packages, but none for platformio-cli and arduino-cli. <wakyct78>from the open patch I saw it looks a little complicated but probably worthwhile <wakyct78>I've used arduino-cli on another OS but not sure if perhaps there's a lower-level way to do the same thing that might be easier to package? dunno <Kabouik>My knowledge is limited on that front, but everything I read about using other editors as replacements to Arduino IDE mentioned at least having arduino-cli/platformio-cli installed for the other editor and extension to use them for compilation. <wakyct78>I don't know what's involved with esp, I'd like to get into that platform though <Kabouik>Maybe the person who compiled emacs-arduino-mmode and emacs-platformio-mode would know better, but I'm afraid they may have been packaged just for syntax highlighting, not for compiling and sending sketches to the actual boards. <wakyct78>it looks like the avr toolchain is on Guix so maybe that's a good jumping off point <Kabouik>From what I understood (but never tried), ESP32 boards can be added to Arduino IDE's board manager, and then dealt with just like the Arduino boards. A colleague also uses Visual Studio, but I think that's with an extension that bundles arduino-cli too, or with Arduino IDE installed on the system so that the cli is available to other editors too. <wakyct78>I think you can install just arduino-cli w/o the IDE? Hard to remember from the mess of my old install ;) <wakyct78>then you just put the board info in the right directory that the cli can find it <Kabouik>I guess if they ship arduino-cli pre-compiled I could try that, but then finding how to configure Emacs for it may not be too straightforward. Worth a shot anyway indeed. <wakyct78>yeah that makes sense. From what i remember it's not difficult <Kabouik>Yeah they do ship pre-compiled binaries apparently. I'll give it a go next week hopefully. Not as cool as a real package but hey. <Kabouik>But from what I remember, packaging Go binaries for Guix can be a rabbit hole sometimes. <wakyct78>if you make notes on anything tricky in setting it up I'd be interested in seeing them, maybe post a link here or to the ML <oriansj>Kabouik: well ideally, no binaries would be included in guix. perhaps you mean go programs/libraries? <wakyct78>it's funny, switching to Guix has really amplified my aversion to large tarpits like Go, node, where before I would just it up and <pkgmanager> Install them. Maybe I'll get over it... <wakyct78>I might also be wrong about Go, maybe it's not that bad <PotentialUser-92>Hey. I'm new to guix and I switched to some profile accidentally. How to switch back to the main profile? Sorry for the noob question <futurile>you 'switch' to a problem by sourcing it - so the default profile is under ~/.guix-profile - you can source ~/.guix_profile/etc/profile <futurile>or just log out and in again if you changed bashrc to automatically source that <wakyct>futurile, sourcing it adds to previous profiles? I saw in the cookbook the notion of opening a fresh shell with env -i to switch to a fresh profile but wasn't sure if that was current info <futurile>wakyct: yes - you can source multiple profiles - all it's doing is changing PATH and similar items. If you want a completely clean env then that makes sense