IRC channel logs
2024-06-20.log
back to list of logs
<freakingpenguin>the_tubular: You can see the commit hash used in emacs-next in the version string. It's manually updated like any other package. At present it's on 170c655 (~3 months ago), so the update to 1.0.25 wouldn't be in emacs-next. <freakingpenguin>The web-based package search may not be the best at keeping up to date. <the_tubular>And what happens if let's say emacs-next would have 1.0.25 and emacs-jsonrpc 1.0.24 ? <the_tubular>When I guix install emacs-jsonrpc, will it give me latest ? <freakingpenguin>Emacs consults the load-path variable in order to find what package to load. My understanding is guix packages are added to the front of the list, so if guix packaged 1.0.24 and you install it, it'll hide the built-in 1.0.25. <noe>update the package to match the core version :P <eikcaz>did the make target for authenticate change? I tried running "make authenticate" and got "No rule to make target 'authenticate'" <eikcaz>Also, is there a light at the end of the tunnel with this patchset backlog? I see synapse (matrix homeserver) has had three working patch sets sent over the past year yet the package remains broken <eikcaz>I wrote an interface to make Syncthing completely configurable via guix, but I would be pretty upset if I did the work to submit a patch set for it, and it wasn't merged a year later... <freakingpenguin>I don't have commit access so I can't really help but I can say a syncthing config patch would be very interesting. <freakingpenguin>Ah, it was a hidden #ifdef requiring zlib that removed the library.h include. <rmnull>Hey, I'm trying to configure my guix packages and there's a conflict between my sqlite and gnome package. The gnome@44.10 requires sqlite 3.39.3 and the current sqlite is 3.45.1. I can downgrade sqlite but that version of sqlite is required by another package. <rmnull>Overall, I would like to ask, is there a way for me to upgrade gnome to a later release say gnome 45/46 <mange>rmnull: Mmm, this is the pain of propagated inputs, I'm afraid. My first solution would be to install them into different profiles, so they can be entirely independent. <rmnull>I see, I have both of them declared under my guix home config which is prolly what's causing this issue <rmnull>and would there be no conflict in loading libs say when both of the profiles are present in path <mange>I wouldn't be confident in saying "no conflicts". It looks like sqlite is pulled in by packagekit, which is just using the sqlite variable, whereas 3.45.1 is defined as "sqlite-next" and is used in exactly two places, neither of which are propagated. What's pulling in 3.45.1 for you? <jakef>could also try installing these packages with --no-grafts <rmnull>mange: not quite sure what package caused that issue, it seems to resolve conflict now,mmm strange. I have few packages commented out, probably one of them is culprit but its taking time to rebuild them and not complaining so idk what exactly caused the issue. <mange>Ah, okay. If you can isolate it a bit better than maybe we can work out a better solution. It might be possible to rewrite an input, or something, without having to rebuild a lot of stuff. <rmnull>this is good enough for now, thanks :) <rmnull>I had run guix gc operations last time so it needs to pull those packages, otherwise guix home reconfigure is usually quick <bost>Hi. `guix shell --emulate-fhs --container --expression='(@(gnu packages guile) guile-3.0)'` displays 'ldconfig: /lib/libguile-3.0.so.1.6.0-gdb.scm is not an ELF file - it has the wrong magic bytes at the start.'. Does anybody kown why? <msavoritias>hey. is it known the bug that guix git authenticate doesn't support ssh keys for signing? <msavoritias>since i am assuming it uses git to actually authenticate the commits. <bost>the guile-1.8 works fine, however any later version shows this warning. <bost>In fact the --expression parameter is not needed to reproduce it. `guix shell --emulate-fhs --container guile` also shows the 'ldconfig: /lib/libguile-3.0.so.1.6.0-gdb.scm is not an ELF file - it has the wrong magic bytes at the start.' <cbaines>I've fixed the logs.guix.gnu.org certificate issue <graywolf>sneek: later tell freakingpenguin regarding #71586, maybe it would be nice to adjust the documentation as well. You can probably just copy&paste from #71676. <Googulator>Is there a way to tell "guix system init" to transfer the entire store from the running system to the newly initialized one (i.e. including bootstrap stuff)? <podiki>regarding #64794, I think that can be safely ignored, as ldconfig is run for an FHS container, and I think it is just seeing non-library files in /lib from Guile. maybe there is an option to ldconfig to be quieter on that <Googulator>I've finally got the Guix-on-LiveBootstrap project to the stage where a "guix system init" generates a bootable system with an Xfce GUI - but if I then try to install a browser on the booted system (with --no-substitutes since the whole point of the project was to exclude external binaries), it starts running the whole bootstrap again from <Googulator>it seems that "guix system init" only transferred the bare minimum required to create the new system, instead of the entire store <ieure>Googulator, You can copy it over, but the profile Guix builds won't include them unless they're referenced in your operating-system config. <ieure>So they'll be on disk, but not in your $PATH. <Googulator>Is that sufficient to avoid rebuilding the universe when trying to install a browser? <freakingpenguin>What does XXX: mean in a comment? Is it just a easily-greppable alternative to "NOTE:"? <sneek>freakingpenguin, you have 1 message! <sneek>freakingpenguin, graywolf says: regarding #71586, maybe it would be nice to adjust the documentation as well. You can probably just copy&paste from #71676. <redacted>I'm trying to figure out the workflow for packaging software that a) I'll want to use myself right away and b) I'll want to contribute upstream eventually. <redacted>It looks like a good way to do that might be to fork the official channel and use that fork instead of the official one on my system. <redacted>How are others managing their custom packages? <ieure>redacted, I set up my own channel, wouldn't recommend forking guix/master unless you need to significantly hack up how it does things. <freakingpenguin>redacted: I don't have packages but I do have custom services in my own channel. Barring imports or potential name collisions nothing should be difficult to upstream even though it's not a Guix fork. <juli>I also have my own channel and would recommend it. <juli>Through the magic of Guile modules, there's little difference between a fork of the main repo and just importing from Guix in your files. <juli> xcept you may need to import more things. <juli>(because those things were already imported wherever you'd add the package) <redacted>Only reason I was considering forking was to make creating patches easier. What's your workflow for that? <graywolf>rekado: this is completely random, but thank you so much for packaging fillets-ng; takes me back to my childhood <graywolf>redacted: I personally have a fork of Guix proper, sometimes adjusting built-in services is a pain otherwise <glenneth>Hi o/ has anyone experienced their home profile not loading at login? <redacted>graywolf: I'm thinking of a scenario like "Okay, I've just packaged version 0.53.0 of fzf, I should probably send this upstream". If I have a fork of Guix, I know to `git send-email` or something. If not, I guess I copy-paste the package into a checked out Guix repo and *then* send the patch? <graywolf>Yeah, sounds about right. I want to avoid the copy&paste step, so fork is easier for me. <freakingpenguin>I suppose it's a trade off of "easily submit patches but need to put more effort into keeping my fork up to date" vs. "copy+paste code for patches but keep guix up to date automatically". <redacted>Yeah, only downside is that I guess you've got to git pull your fork before guix pull <graywolf>I just added ./etc/update-fork, so the effort is arguably quite minimal. Nevertheless that is a valid concern. <freakingpenguin>graywolf: What are your thoughts on standardizing nginx's extra-content fields as taking lists and lists alone? The code for strict backwards compatibility isn't exactly clean and I find it gums up the documentation. https://paste.debian.net/1320924/ <graywolf>The end result would be cleaner, I agree, but imho it would at least require a deprication period with warning being logged. But not a committer, so I am just like another guy with an opinion :) <freakingpenguin>Gotcha. Also looks like 71676 doesn't handle raw strings anymore since it tries mapping a string. <graywolf>Try to flip if, (if? list? (map ...) extra-content) <graywolf>(match extra-content ((? list? extra-content) (map ...)) (_ extra-content)) <graywolf>hm, 71676 was already doing the map though, I just changed the lambda body <graywolf>Oooh I see, yeah, documentation issue I believe <freakingpenguin>Oh, I think (flatten extra-content) wrapped it in a list if it was a raw string. <freakingpenguin>Unfortunately doing that now would mess up formatting each element of the list <graywolf>((@@ (gnu services web) flatten) "aa") --> ("aa") <graywolf>Well that is not semantics I would expect from something called "flatten" :/ <freakingpenguin>Maybe we should patch it to "flatten-sort-of-sometimes-but-also-not" <ieure>graywolf, Curious what Guile's tflatten transducer does in this case. I was just poking at that the other day. <graywolf>ieure: Well technically the same, it element is not a list, it just passes it through <graywolf>Sigh, I guess I will need to redo the patch. <ieure>I get: In procedure car: Wrong type argument in position 1 (expecting pair): "aa" <ieure>(list-transduce tflatten rcons '("aa" ("bb" ("cc")))) ;; -> $2 = ("aa" "bb" "cc") <ieure>(list-transduce tflatten rcons "aa") ;; -> In procedure car: Wrong type argument in position 1 (expecting pair): "aa" <graywolf>Well yeah but the error here is from list-transduce, not tflatten <simendsjo>freakingpenguin: Ref yesterdays StumpWM discussions. I tried --no-grafts and StumpWM no longer crashes! Commit e32e3d0a03, but I don't see any cl, sbcl or stumpwm related commits since the non-working commit. So it looks like grafts were the culprit. <freakingpenguin>simendsjo: Gotcha! Might be worht adding a comment to #62890 since your error was a bit different. Make it a bit more searchable. <JetpackJackson>just realized that the program i use for my drawing tablet is not in Guix, and i dont see any info about tablet configs in the manual, how do yall configure your tablets (on wayland, if you happen to have one)? <Lumine>JetpackJackson: wacom drivers are available for Guix, but I just configured my Wacom using CLI, there are some guides for that online <JetpackJackson>the most crucial thing for me is to be able to rotate the input surface so that i can use it comfortably with my left hand, otherwise the cable juts out where i rest my hand lol <eikcaz>I think that should be managed by your Desktop Environment <JetpackJackson>drat i found a driver package that someone packaged but i cant access it because i have to make an account on framasoft <ieure>Super do not understand the issue here. Linux, generally, almost never needs "driver" software. Tablets are supported by evdev. <JetpackJackson>sway only allows mapping the tablet to a monitor, but not the buttons, so other software is needed <simendsjo> I'm creating a qcow2 image, but even though I specify btrfs as the filesystem, I get ext4. cp gnu/system/examples/vm-image.tmpl /tmp; sed s/ext4/btrfs/g /tmp/vm-image.tmpl -i; guix system image --image-type=qcow2 /tmp/vm-image.tmpl. /dev/vda1 should be btrfs, but is instead EFI, and /dev/vda2 is ext4. Even though the definition is (file-system (mount-point "/") (device "/dev/vda1") (type "btrfs")). <freakingpenguin>I understand the code re. image generator, but I still don't fully understand how the image boots if the os record has a non-ext4 fs type for the root-fs. Seems like the os is overwritten a bit too. <simendsjo>freakingpenguin: Ah, thanks! I'm considering migrating to btrfs, but I want to test it first. A lot of other things I'd like to test though. <freakingpenguin>I ran into it trying to make a btrfs image for an SBC. It was definitely a surprise to find out system image silently ignores the root fs specified in the os. <ircenjoyer>Hello, In NixOS; I can configure all of my dotfiles (i3, NeoVim plugins and keybindings, VSCode extensions, Firefox extensions and settings, ...) with NixLang and Home-Manager. Can I also do this on Guix? <ircenjoyer>I heard about "guix home", but I can't understand is this what I'm looking for. Peoples generally put their config (ex. i3config) near to their home.scm than import from home.scm. While in my NixOS config; everything already coded in NixLang so I dont use other configuration languages. In short, I can configure my NeoVim without learning lua, just NixVim. <freakingpenguin>Some services are like that, where you can configure them in a more elegant manner than symlinking a raw config file (e.g. redshift). <freakingpenguin>Where "service" refers to "logical unit of your home configuration", often a specific program. <graywolf>22.13 of our manual commands to respond with "Reviewed-by: Your Name<your-email@example.com>" to mark that I reviewed a patch. Notice there is no space between the `e' and `<'. Is that intentional? Looks weird to me, but is used consistently across the section... <ircenjoyer>Nix parses configurations written in NixLang, than converts it to their native type of configuration; puts it to the Nix store and symlinks from Nix store to the true path. So I don't need to learn languages for different applications. <freakingpenguin>ircenjoyer: Yes, that's generally how it works. Services are configured in Scheme code and (if relevant) generate+symlink config file(s) based on that. The manual has a list of home services that currently exist. <JetpackJackson>drat i finally got into framasoft and the repo and user dont exist anymore so thats a dead end