IRC channel logs
2024-12-05.log
back to list of logs
<homo>when project's license is MIT, do I specify it as license:expat? <homo>"guix download --commit" and "guix hash -S git" combination are inconsistent with "guix build", which gives me error sha256 hash mismatch <mange>That has not been my experience. I've recently been working on an importer that writes package definitions by calling "guix download --git --commit=$revision" and I haven't had any issues with hash mismatches. <sneek>Welcome back mange, you have 1 message! <sneek>mange, apteryx says: ah, so it's 'abused' in some way :-). Could have been called more generally proc or something <homo>"guix build" says hash is 0mb87zycmmz6xsslrnnf16ivd4s2jfblmickai422srdil3vysxg, but "guix hash -S git" says hash is 1h6wcpjcyzk0fi522mh3z5qdnkjd428q2npakk5dzkh9gy9wdb0f <mange>Without knowing the inputs to those calls I can't say more than "it works for me". Can you put your package definition in a paste? <homo>where can I upload without non-free scripts blocked by librejs? <homo>$ guix hash -S git /gnu/store/w76r600lsf1s8qjw8nlzgnpjx293208h-inferno-os-67e70be <homo>originally it was rejected because of LPL license and non-free fonts, but recently LPL was changed to MIT, what's left to be done is removing fonts from inferno source and instead using whatever fonts are available in guix <mange>Okay, so I get "guix hash -S git $store_path" is the same as "guix hash -x -S git $manual_clone", but that is different to what "guix download --git --commit=$revision $remote_url" returns. <mange>However I am confident that using the hash from the "guix download" call works in a package definition, because I do that frequently. <homo>well, I'm just following what I find in manual and cookbook <homo>btw, I don't see output being different with "-x" <mange>On a manual clone? It doesn't make a difference if you're calling it on the store path that "guix download" created. <homo>well then, no idea how to make "guix hash" produce what "guix build" expects <oriansj>homo: the easiest way is to do guix build -f and note the checksums it complains about <Kolev>Is Wireguard hard to use on Guix System? <homo>to me it looks like same wireguard config, just in guile language <mange>The learning curve for me was how to use Wireguard. Once I knew what I wanted, doing it in Guix was pretty straightforward. <freakingpenguin>Agreed, wireguard wasn't too hard to set up. I had a harder time stopping it from starting automatically then anything else. <efraim>I figured out how to fix cross-building rust packages, just need to add gcc-14 to native-inputs <efraim>problem is I'm already not happy about the native-inputs in make-rust-sysroot <Rutherther>hm, why does rust need native gcc when cross building? does it build some build tools first? <efraim>it's like building a cross compiler, but its using native gcc and a cross-gcc in the build environment, and we want them to be the same <efraim>technically I could force it all to use gcc-11 since make-rust-sysroot currently doesn't support x86_64-pc-gnu yet, but using gcc-14 is probably the better solution <efraim>I'm not sure exactly where, but it seems like one of those --host vs --target vs --build autotools things, and it ends up using both and being upset <jakef>can i pick your brains: could a shepherd service trigger after the default user profile changes? (i.e. after install, remove, upgrade commands)? <Rutherther>jakef: one way would be using inotify, ie. with inotifywatch on the profile symlink, but it would not be a service that starts on that one, rather, a service would be started and constantly waiting for the event and doing something when it gets the event <jakef>cool, I'll check it out, thanks Rutherther <efraim>*** Configuration aarch64-w64-mingw32 not supported <Kimapr_>is it possible to set a certain locale in operating-system but only for datetime formatting? <Kimapr_>like the equivalent of setting LC_TIME <Kimapr_>it'd be enough to just set LC_TIME directly (and add a locale-definition), if i knew how to do that via guix. <efraim>so, uh, if aarch64-w64-mingw32, what compiler would I use? <efraim>I was expecting to have to figure out actually getting cross llvm/clang to work <efraim>that's actually not a lot of lines of change <efraim>If I had a real use for it (or a way to test it) I might jump in <efraim>so I think I'll just get some of the stuff ready now and wait (for now) for gcc-15 <taeaad>When using Guix on a foreign distro, is there a rule of thumb for GUI settings? For example, if I install Calibre via Apt, then the theme settings can be set to system, but via Guix I can't seem to do it. <janneke>9th round of automakes...and the scope keeps increasing... <janneke>because i only have 1/20 future-sight? <janneke>but in short: switch automake to 1.17, try removing test workarounds, bring them back, need extra test workaround, find that bdb doesn't work with automake-1.17 so bring 1.16.5 back, etc :) <janneke>hmm, building gcc-11 with gcc-14, is that what we want? <janneke>ACTION looks if that can be reverted <janneke>ACTION removes gcc-11 from automake-16.5 again and just disables tests for now <Kimapr>mpv seems to be unable to open .mod files ... <Kimapr>Is there a convenient way to modify the (arguments ...) of a package? i want to add --enable-libopenmpt to my ffmpeg <Rutherther>Kimapr: there is substitute-keyword-arguments and ensure-keyword-arguments <Kimapr>Wow that thing i did actually worked. this is so epic <janneke>phasebuilding of `/gnu/store/if88a4xg6qipnsrx50rbapmk1s0c8ycr-bison-3.8.2.drv' timed out after 3600 seconds of silence <Kimapr>Rutherther: thanks! that is a lot more elegant <weary-traveler>there's a recent discussion on emacs-devel on how best to share info packages for things other than emacs. <https://yhetil.org/emacs/86y10uy780.fsf@gnu.org/T/#t>. it got me thinking that guix may make for an excellent distribution system for these. especially for info manuals of libraries/tools that don't always ship with texinfo source (e.g. python) <weary-traveler>thinking some more about it, i suppose specific discussion would benefit from looking at a specific patch proposal <weary-traveler>but in any case, for any unaware, but interested in the topic, the linked discussion above may be of some interest <raghavgururajan>[: Regarding your question, I was suggested to try/use librewolf when I reported that IceCat crashes out of the blue (very frequently) with the error "Exiting due to channel error" for past few weeks. <janneke>headsup: resetting core-packages-team branch, keeping core-packages-team-old <Deltafire>xwayland dumps its core everytime i shutdown the computer <podiki>anyone aware of pending mesa/etc. stuff? about to do a new mesa-updates branch <podiki>i'll do libdrm, wayland-protocols, mesa <yelninei>finally rebootstrapped gcc-final in my little childhurd , I hope the missing substitute issue can be fixed <ekaitz>simendsjo: that one looks ok i think <simendsjo>Great! Lot's of work for a one byte change when I'm not used to the tooling ;) <ekaitz>simendsjo: i'm reviewing the patch <reedm45>Is there a way to set a guix container shell user group? I want to expose the serial port at /dev/ttyUSB0 to the shell, but to actually use it as a serial port requires the user to be part of the "dialout" group <reedm45>I can change the permissions of the device, but I <reedm45>*but I'd rather not, if I don't need to <vagrantc>hrm. rust 1.82.0 not building on aarch64-linux <vagrantc>built all the way up to that version though... after a long time :/ <Rutherther>reedm45: no, there is no way to do that. Guix shell container is just a simple container without configuration. If you are using elogind, udev rules uaccess that will give the permissions to your user automatically could help here <reedm>Rutherther: Thanks! I'll look into that