IRC channel logs


back to list of logs

<vagrantc>ACTION waves
<oriansj>any reason why userv ( is not yet packaged in guix?
<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
<peanuts>"debian Pastezone"
<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"
<miaomiao>have i done something funky?
<cancername>miaomiao: perhaps these can help:
<cancername>left already :/
<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?
<madeleine-sydney>yep; on top of debian
<futurile>madeleine-sydney: are you trying to compile the other software, or use it?
<madeleine-sydney>both. sometimes it fails to build, sometimes it fails to run
<madeleine-sydney>my particular struggle at the moment is libgmp10
<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>what about run-time linker errors?
<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
<madeleine-sydney>i'll move forward with that attitude then, ta.
<futurile>fingers crossed :-)
<Franciman>hi, is there any public explaination of why DRM is not included in ungoogled-chromium and other libre browsers?
<cancername>Franciman: I think it requires some widevine blobs. also, DRM in general is not great <>
<madeleine-sydney>okay `guix import` made this way easier lmfao
<Franciman>oh, thanks cancername
<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
<Franciman>i'm really in awe, futurile
<Franciman>sadly atm i don't have my phone, i broke it
<futurile>ah yeah that sucks
<Franciman>have you tried spotify-tui by chance?
<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 ??
<Franciman>thanks futurile
<cancername>futurile: I wasn't able to install it, it didn't find the package.
<cancername>And yes, seems like it
<jakef>any python folks around? how do you plot things? :<
<peanuts>"Python Matplotlib with MPLBACKEND TkAgg"
<cancername>the /gnu/store path ends in linux-libre-module-builder-6.8.6
<cancername>jakef: it seems you're in the wrong channel
<cancername>try #python
<jakef>i don't think so cancername
<cancername>oh wait my bad
<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>sorry, I can't read
<jakef>all g
<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.
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<Franciman>i'm trying to generate a gpg key, and even if i installed pinentry, gpg keeps saying that pinentry is not installed
<Franciman>do i need to explicitly install gnupg?
<lilyp>stupid question, which GCC/libc version has std::format?
<Franciman>still failing
<apteryx>cbaines: for me git branch --contains f29f80c194d0c534a92354b2bc19022a9b70ecf8 says its only on core-updates, not master
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<apteryx>ah, '--all'
<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
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<cbaines>it's the related 28d14130953d868d4848540d9de8e1ae4a01a467, which is just on core-updates that's the issue
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<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.
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<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>as far as I understand
<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>and getting rid of the merge commit
<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>*we'd be
<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 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
<peanuts>"[PATCH 0/4] Even Better ZFS Support on Guix"
<peanuts>"[PATCH 0/4] Even Better ZFS Support on Guix"
<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
<apteryx>welcome to z572 as a new committer!
<cancername>oh I'm stoopid
<Franciman>very often nscd redirects hosts to and i have to invalidate its cache
<Franciman>is this happening to you as well?
<Franciman>redirects some hostnames*
<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>yep understood
<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>yeah, I used arduino-cli from Emacs
<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?
<Kabouik>I used the wrong word, sorry!
<Kabouik>I meant Go program indeed.
<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
<futurile>profile not problem heh
<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