<pkill9>would it be accepted to add a build system that creates a wrapper for love files? Or would that just be unneccessary complexity? <jmarsden[m]>love files? Who left letters to their girlfriend in the source tarball?? :) <pkill9>if you're actually unsure, I mean .love files for the love game engine <jmarsden[m]>I hadn't heard of that file type,but figured there must be one. <pkill9>then again it might be better just to create a function <pkill9>that's what's done for other packages actually, like the chromium addons i think <pkill9>i already made a love build system :) <pkill9>as in packages that use the love build system <pkill9>it tries to automagically do stuff according to the source <fnstudio>hi all, a couple of questions around the use of a `guix.scm` or `environment.scm` file within a software project <fnstudio>i understand that's good practice as it helps with reproducibility <fnstudio>what i'm not sure about, though, is how to exactly handle the `source` section <fnstudio>i understand that the `source` section is not needed if the objective is just to recreate the package dev environment <fnstudio>but i like the idea, if possible, to provide a `guix.scm` file that doubles as an env file as well as a way to install the file locally, in this case the `source` needs to be populated for the build to happen, am i right <fnstudio>in many cases, the `source` section contains a url to the project repo <leoprikler>there are multiple ways of setting up the `source` section <leoprikler>most just use everything in the current directory that's managed by git <fnstudio>leoprikler: yes, i noticed that can be based on a remote url but there's also the option to pass a `local-file`? <leoprikler>in other cases, you might get away with a few local files (assume e.g. everything lives in "src") <leoprikler>yep, repo-managed guix.scm mostly contains local-file <pkill9>what is this setup you are using for software? <fnstudio>leoprikler: that's exactly the core of my question... i don't think i like the idea of adding a remote url where to go and fetch my project as it feels... circular... to me <pkill9>I'd quite like to use environment.scm <fnstudio>leoprikler: oh ok, that answers my question <pkill9>for building manually from source <pkill9>does it gcroot the dependencies? <pkill9>so I could install the project to a directory and the deps will always be there <fnstudio>leoprikler: may i ask if you have a project or two from the top of your head that i could look at as an example? <fnstudio>although i suppose i can do a web search for guix source local-file ***capnick is now known as cap
***cap is now known as 18WABN2ZY
<fnstudio>leoprikler: cool, i'll go and check that out then ***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
<pkill9>how do I set guix system to switch to tty2 on boot? ***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
<xelxebar>Surprising, guix doesn't have ipvsadm yet <mroh>pkill9: maybe a oneshot-service which does `chvt 1`. <fnstudio>it seems it works as an environment file but i must be doing something wrong as it doesn't install anything <dftxbs3e>sneek later tell about libstdc++, I remember that nckx told me everything had to go in /lib so we should rather patch gcc to lookup libstdc++ in /lib instead of /lib64, I remember starting to patch that but never committed anything. <dftxbs3e> sneek later tell marusich about libstdc++, I remember that nckx told me everything had to go in /lib so we should rather patch gcc to lookup libstdc++ in /lib instead of /lib64, I remember starting to patch that but never committed anything. ***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
<icedog>I am running Guix package manager on arm64. I encountered this error when querying the weather of the warzone2100 package. Is this a bug? <lfam>Can you report it by sending a message to <bug-guix@gnu.org>? <lfam>icedog: Also, I don't think that warzone2100 is currently possible on arm64 (we call it aarch64, btw) for guix <lfam>When I do `guix show warzone2100` on a 64-bit ARM machine, the output includes "systems: x86_64-linux i686-linux" <lfam>So, some part of the dependency graph is not available on anything besides Intel-compatible systems <lfam>But, this shouldn't crash `guix weather <lfam>It may be that we could add support, but it depends <icedog>Another question, I want to use tftp to send the kernel and use nfs to start guix, is there a blog about this? <lfam>Dunno! Hopefully someone else has some advice <vagrantc>someone else was working on network booted guix a few months back <vagrantc>there were some developments from it as late as august of 2020 <apteryx>lfam: do you happen to know why rust is limited to the x86_64 architecture? <pkill9>mroh: that worked, but it did it too soon D: <vagrantc>apteryx: probably just realistic with the other architectures taking forever to re-bootstrap the whole rust chain :) <apteryx>but big chunks of GNOME is about to depend on rust <apteryx>seems by 'big chunks of gnome' I really meant the gnome package itself ;-) <apteryx>looking at 'guix refresh -l librsvg' <apteryx>oh, it's the GNOME image viewer which pulls it in <vagrantc>other arches could perhaps suffer without eog :) <vagrantc>but it's only a matter of time before huge numbers of software is dependent on rust... <mroh>pkill9: maybe add a requirement '(virtual-terminal) <mroh>mingetty has this, which seems to be a good idea: `(requirement '(user-processes host-name udev virtual-terminal))` ***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
<lfam>apteryx: Not exactly but it's basically us, not rust <lfam>Already a lot of other "media" applications depend on rust via ffmpeg / rav1e <lfam>We should make it work somehow <vagrantc>was there some recent work in mrustc to skip a few more old rust versions? <pkill9>mroh: it worked! thanks for suggesting :) <pkill9>does anyone have plymouth set up? <Anonymous_>someone can downgrade libotr used by profanity to version 4? <Anonymous_>the packge is being installed sucessful but profanity dont work with libotr5 it just work right with version 3 and 4 <vagrantc>Anonymous_: as far as i can see, profanity only pulls in libotr which is currently version 4.1.1 ***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
<Anonymous_>but their manual shows that its compatible just with 3 and 4 <Anonymous_>Maybe the package of libotr use a link which download last version (idk) <vagrantc>are you using custom channels or something? (e.g. something other than guix master?) <Anonymous_>Even if i force the directory of the package libotr4 <vagrantc>you might want to paste the ldd output of your command to paste.debian.net or something <Anonymous_>$ LD_LIBRARY_PATH="/gnu/store/fwn3ndlx2356aqln1h21pzb3z361kc5l-libotr-4.1.1/lib:$LD_LIBRARY_PATH" ldd /gnu/store/5k64z2xvhvx9sqlj7rvgf2qs1004s9dc-profanity-0.10.0/bin/.profanity-real <Anonymous_>| grep otr libotr.so.5 => /gnu/store/fwn3ndlx2356aqln1h21pzb3z361kc5l-libotr-4.1.1/lib/libotr.so.5 (0x00007febd9a3e000) <vagrantc>the .so version is not the same as the software version <vagrantc>e.g. glib has provided libc.so.6 for ages across many versions ***iyzsong-- is now known as iyzsong-w
<vagrantc>Anonymous_: according to the link you provided, otr is supported by 3.2.x and 4.0.x ... so maybe 4.1.x bumped the .so version <Anonymous_>Idk... the otr just stoped for some reason here.. i cant start otr sessions anymore <vagrantc>i'd guess it was more likely the upgrade of profanity from 0.9.5 to 0.10.0 ... <Anonymous_>the worst part is the omemo donst woks also haha <vagrantc>looks like was updated a couple weeks ago ~20th of january ... maybe from the staging merge <Anonymous_>well it have pgp (which is very good) but most of people dont use it in instant chats <Anonymous_>there is a great chance that my client was opened since befoer the upgrade <Anonymous_>$ uptime 01:12:43 ligado por 24 dias 22:44, 1 usuário, carga média: 1,44, 0,73, 0,59 <vagrantc>have you restarted your user session or rebooted or something? <Anonymous_>reconfigure also.. my kernel is probably outdated <vagrantc>simply restarting the specific application might work, or logging out and back in ... but rebooting is of course a more thorough option :) ***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
<timmydo>when i try to do guix system reconfigure i get an error: build of /gnu/store/fzyxcnxsn8f7n141yb17y6pvsi694zn6-grub-keymap.us.drv failed. the build log is an empty file. anyone know what i should do? <lfam>Are you trying to set a custom keyboard layout? <timmydo>grub-keymap seems to be requested by grub <lfam>I'm not really sure what's up <lfam>Hopefully someone else has an idea <timmydo>is there a way to "clean" everything? <timmydo>huh. it seemed to work after that (after downloading 500mb and doing everything) ***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
<janneke>i just found that the breadcrumbs Home → Blog → Meet Guix at FOSDEM are broken ***18WABN2ZY is now known as cap
***cap is now known as 18WABN2ZY
<civodul>janneke: the link also works without /en <janneke>on that page; the "breadcrumbs"; in eww looks like this: Home → Blog → Meet Guix at FOSDEM <civodul>it's the lack of a trailing slash that makes a difference <rekado_>pkill9: I had some WIP for plymouth but couldn’t quite get graphics to work. <rekado_>it would show the log via plymouth, but that’s no fun ***rekado_ is now known as rekado
<leoprikler>fnstudio: was your problem solved in the meantime? <paulj>Morning all! I am reviewing a setup from David Wilson, and I see he has some user level services defined in a file called .config/shepherd/init.scm. These are not started automatically, at least not the way I have set them up. How do I install these services so they start when I log in? Also, under these circumstances, where would any error messages go? Still to /var/log/messages? Thanks! ***18WABN2ZY is now known as cap
<paulj>can confirm - the instructions in the link work very well. Not clear why my original code didn't run, but hey ho! ***sorki is now known as srk
<fnstudio>hey leoprikler thanks for asking, i haven't spent any more time on it, i think there might be something wrong in how i use the `guile-build-system` <fnstudio>i suppose there's some step i'm missing there <fnstudio>my next step would be to look for examples of how the `guile-build-system` is supposed to be used <fnstudio>i'm very naively assuming that i just need to specify a source (local folder) and then the build system builds and copies over all .go/.scm files for me <civodul>i think we'll need to help Manolis and Pjotr structure our Monday event a bit :-) <leoprikler>fnstudio: That file looks like it might work, but try `guix build -f file -S` to check what actually lands in the package source <leoprikler>Particularly, guile-build-system will also build guix.scm, which might not be what you want <fnstudio>leoprikler: cool, very good to know, let me try :) <avalenn>is there a way to drop in a Guile REPL at the moment where build fails ? ***chrislck_ is now known as chrislck
<fnstudio>leoprikler: `guix package --install-from-file=guix.scm` works (as in "it terminates w/o errors") but `guix build --file=guix.scm --source` fails <fnstudio>it says something about: Throw to key `match-error' with args `("match" "no matching pattern" "... <fnstudio>which i suppose might be a bit obscure to debug from remote with me giving so little detail? :) <avalenn>leoprikler: I did `guix build -K` but I don't know how to launch the build from there. <avalenn>Even using only env from /tmp/$buildir/environment-variables I cannot reproduce the problem. <avalenn>I lack some knowledge about the build-system and try to find a way to learn it by reproducing step-by-step <avalenn>Ok. Found it. It is a problem of current path. I did not execute the build commands in same path as guix. <pkill9> are there any web browsers other than qutebrowser packaged that use qtwebengine? <leoprikler>fnstudio: that seems to be a display error, the third thing should be a path in /gnu/store, that you can ls <leoprikler>pkill9: doesn't seem like it, but there are other packages that depend on it <fnstudio>leoprikler: yes, right, it's a copy of my local folder! :) wait... except it doesn't have any .go/.scm file, only the README, LICENSE, etc... <fnstudio>i might have an extra `not` in my `keep-file?` proc <fnstudio>ok, after fixing the `keep-file?`, `guix package` and `guix build` both fail - although i suppose i'm getting closer to the solution <fnstudio>ah! found this in the logs `no code for module (ncurses curses)` - it might be the culprit! the plot thickens... :D <fnstudio>i guess i need to add ncurses to the inputs... it might be `native-inputs`? checking the docs now <fnstudio>if i add (inputs `(("guile-ncurses" ,guile-ncurses))) to the package definition then i get `error: guile-ncurses: unbound variable` <fnstudio>as it requires some initial import as a prerequisite <fnstudio>i added this in at the top, then, `#:use-module (gnu packages ncurses)` but that doesn't seem to help <fnstudio>i'm now looking up online for packages that are also based on guile-ncurses <pinoaffe>hi guix! so I have a guix-system up-and-running, and I'd like to use it to install guix system on a hard drive attached to said system, is this sensible? the service `cow-store' does not seem to be available on my system, will that be a problem? <civodul>pinoaffe: you don't need cow-store; you could mount that hard drive and then do "guix system init config.scm /mnt/the-hard-drive" <apteryx>In a pure environment, it won't let me enter accentuated characters such as é à, etc. Is this locale related? I've preserved 'GUIX_LOCPATH' but it didn't help. <wonko_the_sane>can you just redefine (bootloader ...) (file-system ... ) sections of config.csm <apteryx>I guess the env is different enough that I should give it its own glibc-locales and glibc so that GUIX_LOCPATH is defined <apteryx>ah, it was related to my ~/.bashrc somehow <apteryx>launching the env's shell via 'bash --norc' fixed it <apteryx>the funny thing, is that even after mv ~/.bashrc{,.bak}, the --norc is still required to get accentuated chars in the pure guix envioronment <cbaines>woo, I'm finally spending some time reviewing patches again, and I think the Guix Data Service + Guix Build Coordinator is actually providing value! <civodul>it's extremely valuable in particular for big patch series, or patch series that touch package with many dependents <cbaines>civodul, indeed, that's where I'm hoping the time saving plus additional rigour from the automation will really pay off <apteryx>actually, the --norc is for nothing. What helps regaining accentuated characters is running with '-- bash' in the env, as in 'guix environment --pure hello -- bash'. The locale is then POSIX but chars such as é can be input. <apteryx>If I drop 'bash', cannot input anymore. Weird, no? <civodul>cbaines: no, i was hoping mothacehe would have an idea of where this is coming from <civodul>problem is that it's hard to "clean up" <cbaines>civodul, would garbage collecting the affected store items be sufficient? <civodul>we could update 'guix' and reconfigure berlin so that these things never get into the store <cbaines>I guess that might require finding and removing the relevant gcroots, and then deleting relevant cached narinfos <civodul>cbaines: no, because (1) they're in /var/cache/guix/publish, and (2) they may not be in the store of berlin itself <sneek>I think I remember mothacehe in #guix 7 days ago, saying: I ran "ifconfig eno1 multicast" as a cheap fix. <cbaines>ah, I don't have a good mental model of how things currently get served from ci.guix.gnu.org... I'd assumed guix publish was still in use, serving from the big store <Rovanion>How do I set up a build environment using an older glibc? If it is allowed, I can link to Stackoverflow where I've formulated the question with more words, an example, and what I've tried so far. <apteryx>apparently /bin/sh doesn't have the same behavior as bash <apteryx>and that would be POSIX mode vs non-POSIX mode <cbaines>apteryx, how it's invokved affects the behaviour, there's a bit in the man page about this, search for "bash is invoked with the name sh" <cbaines>Rovanion, please go ahead and post the link <cbaines>Rovanion, I'd look at make-gcc-toolchain in (gnu packages commencement), that takes an optional libc argument <cbaines>Rovanion, I'm guessing here, but if you setup and environment with a custom gcc toolchain, using your intended version of glibc, hopefully that would work <civodul>cbaines: frankly, i don't have a good mental model either :-) <civodul>'guix publish' is still used, but i admit i don't know how its cache is populated <jsoo>I think the nix service might be misconfigured. The nix build sandbox needs a /bin/sh mounted. There is one provided by nixos. Would it be ok to make a wrapper package for it to use in the configuration? <civodul>jsoo: hi! not sure what you mean by "wrapper package", but fixing this issue would be welcome, sure :-) <apteryx>I mean, checking if the commit already exists in a previously cached git checkout corresponding to the channel <civodul>commit 7cfd789150f448cf5256b88915bae4163cc9db03 <civodul>now, if you specify a branch rather than a commit, there's no way around it <civodul>apteryx: there's two things: in this case, "guix time-machine" will execute the inferior right away *if* the inferior is cached <civodul>if the inferior is not cached, it does the whole thing: pull, intern, build <civodul>the commit above improved behavior on inferior cache hit, not on cache miss <apteryx>OK, so perhaps the message is jut misleading ('Updating channel 'guix from Git repository...' leaves me to believe some git fetch is occuring') <apteryx>the inferior should be cached, I'm reusing the same channels file over and over <civodul>we'd need to check whether the "guix" you're running includes the commit above *apteryx gives up trying to have accentuated chars in a --pure env made from a manifest <apteryx>weird thing is 'guix environment --pure hello -- bash' does work, but when using a different set of inputs from my manifest it doesn't anymore. <apteryx>I wonder if it's tied to my use of ibus or if it's reproducible for anyone <apteryx>civodul: ah, it depends on the Guix running... right. It must be older! <jsoo>civodul: oh, by "wrapper" I mean directly getting the outputs from nix' outputs <jsoo>The shell they use is a static binary *apteryx just pushed the new Rust bootstrap to core-updates <jsoo>Also I'm not sure we have the tools to build it ourselves yet. It uses musl and company <jsoo>Whoa apteryx what's in the new bootstrap? <apteryx>It's using mrust 0.9 to start from rust 1.29 instead of 1.19 <jsoo>Niiiice! That's very welcome :) <apteryx>I have another commit that needs some more testing but it'll reduce it by another 30%. <apteryx>In total the new rust bootstrap should be in ~8 hours instead of 16 after the next commit lands <jsoo>I have a couple patches for rust to add the wasm32 target and some more tools as outputs. I hope they don't increase the time too much <apteryx>civodul: to follow on cached inferiors; works as advertised after guix pull. Thank you :-) <civodul>i had grown tired of waiting 3s for nothing <roptat>just noticed my work machine has 20 cores and 64 GB of ram... I should find a way to use it as an offload machine ^^ <roptat>zimoun, generally idle means "doing nothing" <roptat>but in this context, it could be "not building anything" but still doing something (downloading dependencies, uploading a result, ...)? <zimoun>because it is often idle and often a long time. :-) <apteryx>roptat: there's an autossh service. You can reverse forward the port 8080 at home using something like "-R" "8080:localhost:80". <apteryx>if you want to keep your machine at work (I'm assuming it's in a different location?) available locally, for offloading purposes for example. <roptat>I don't understand, I have ssh access to that machine, but it's not reachable outside the local network. I can use the VPN, but it's a pain in the ass to setup properly <apteryx>you need to establish the SSH tunnel *from* work to home <apteryx>it'll bind to a port on your home computer that you can use to talk to it <roptat>oh, but I don't have a computer that's always on at home <apteryx>you could configure some dynamic dns service to always point to your laptop or whatever. But yeah, that gets more difficult then <apteryx>the autossh service would periodically retry the dynamic IP so it could still work <apteryx>IPv6 would probably help if you are in various network, but I have no experience with it. I set up a port forward on my home router to redirect the port I use for SSH to a given machine. <roptat>mh... and I'll have to check it works with policies <apteryx>(that's with IPv4/NAT). If you go IPv6 the problem would be moved to firewall configuratino. <apteryx>just got this: guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet. <apteryx>another one: guix offload: error: remote command 'guix repl -t machine' failed with status #f <apteryx>perhaps due to the offload machine being under high load *apteryx thinking why --rounds=2 couldn't be parallized <lfam>Good idea. It would be great to do --max-jobs=2 --rounds=2 <PotentialUser-31>My maven 3.6.1 got updated as a result of `guix package -u` and the version of maven itself is still the same (3.6.1), but I want to audit what changed in its dependencies. Is there a command that can help me visualize this? <PotentialUser-31>Otherwise I need to do guix graph maven, guix package --roll-back, guix graph maven <roptat>after the roll-back of your profile, it won't change the result of guix graph, because it relies on the maven package it knows about, not the store path that happens to correspond to maven, that's used in your profile <roptat>you'd have to roll-back "guix pull" instead, or simply use the time-machine <roptat>so, you'd compare the current "guix graph maven" with "guix time-machine <the-guix-commit-used-before> -- graph maven" <roptat>I don't think there's a good solution to your question <maxxcan[m]>and I need iceweasel because I want guix to be the one system in my laptop and I need to use jitsi <PotentialUser-31>roptat: That could work, I can wrap this in a what-changed-for.sh script, but how do I get the guix commit used before? <roptat>PotentialUser-31, I don't know :/ <roptat>if you're lucky and your profile is not too old, there's a provenance tracking feature, so you can get that info from the manifest file in the old profile <roptat>(/var/guix/profiles/per-user/<username>/guix-profile-<n>/manifest) where <n> is the second-to-last number you can see there (the previous generation of your profile) <lfam>I'm startings tests of linux-libre 4.4.256 and 4.9.256 <lfam>We'll want to make sure nothing breaks now that the minor version overflows an 8-bit integer representation <lfam>I'm building immutable VMs (`guix system vm`) with them. Does anyone want me to run other tests? Got any ideas? <jmarsden>lfam: I'd suggest testing any/all utilities that display kernel version. uname -a obviously. Maybe hwinfo too. cat /proc/version ... there must be more, ... <lfam>Wait an hour or two and there will be substitutes for the kernels for x86_64 <lfam>Realistically it will take less than an hour <pinoaffe>My new guix system installation fails to boot with "failed to start service 'file-systems'" and then "failed to start service 'file-system-/boot/efi" (and then basically all other services) - any tips as to how to debug this? <lfam>Hm, it sounds like some aspect of the filesystems / partitioning is set up incorrectly ***modula is now known as defaultxr
<lfam>I would compare the values entered in config.scm with what actually exists on the disk <lfam>Like, list the partitions with `fdisk -l`, see if there are filesystem where they should be, etc <Ashjkaell>Ops, I'm an idiot. That said I'm super impressed by guix. <Ashjkaell>Seafile let itself be packaged by just adding all correct inputs <civodul>pinoaffe: did you use UUIDs or labels to designate the source of your file systems? <dongcarl>My most satisfying commit message to date: "guix: Jump forwards in time-machine and adapt" <civodul>sometimes adapting is tricky, hopefully this wasn't the case <pinoaffe>civodul: I used device names at first, now I played with the partitions and the config a bit and now I'm using an FS label, now it works for whatever reason <civodul>pinoaffe: yeah i was going to say that labels and UUIDs are the safest way to refer to devices <pinoaffe>I mean, now that I've booted they're the same again :) <PotentialUser-31>roptat: I have the guix-profile-<n>/manifest file, but how do I parse it to extract the guix commit (for the maven package in my case)? Because it's guile scheme, it's just lists of lists, but I don't know how to parse it from my bash script <roptat>it'll be hard to parse from bash <zimoun>PotentialUser-31: guix-profile-<n>/manifest is readable, if you need just to extract one commit, open and scroll. Other “guix package -p guix-profile-<n> –export-manifest” or –export-channel maybe could help <dongcarl>civodul: After having switched from C{,PLUS}_INCLUDE_PATH to CPATH last time... Switching back was a bit easier :-) Hopefully we're sticking with this scheme though! <lfam>Does anyone know off-hand how long Guix caches a substitute cache miss? <cbaines>lfam, quite a while, an hour I think <lfam>roptat: Those substitutes are available now from ci.guix.gnu.org <lfam>These aren't "real" updates since nothing changed besides the version, but I'm still going to push them soonish <lfam>uname and /proc/version still work <atomsk298[m]>Hello. I am running into a weird issue on my computer. After reconfiguring my system, the newest generation does not appear in the grub menu. When I boot into the first item in the menu and run "guix system list-generations", it says that the new configuration is the latest generation. When I try to reconfigure, it logs me out and brings me back to a terminal login screen. Is there anything I can do besides re-installing <civodul>dongcarl: heh, i do hope we won't switch again! <civodul>though there are still issues with #include_next i'm afraid <vagrantc>atomsk298[m]: that sounds vaguely familiar ... from when i switched from a very barebones system to one using elogind, and the kernel didn't support all the features needed by elogind ... but don't remember much more than that <dongcarl>civodul: Yes, #include_next is very unfortunate... Probably 70% of my problems come from #include_next... I often times wonder if all gnu-build-system packages should have a phase that generates a working gcc specfile so that we can be more granular about the include paths... Not sure if it will help though :-/ <civodul>it's terrible that one has to do all this :-/ <PotentialUser-31>Can I run two `guix time-machine <commit> -- graph...` in parallel to pass their output to diff / meld using the <(command) notation ? Like so: <civodul>dongcarl: so you use the cross toolchain from outside Guix, right? <PotentialUser-31>meld --label "maven in gen-32" <(guix time-machine 8e7e414aa998fe8c0de8a491c91aab8b8d9c58f4 -- graph maven) --label "maven in gen-33" <(guix time-machine 838347207cdd96de1ad0127aaf4b2c378c7c2148 -- graph maven) <dongcarl>It's ugly, but it's explicit, which means it stands the test of time. <dongcarl>In the bump to v1.2, I just had to point the gcc lib dir to the new lib output for gcc, and everything worked. <dongcarl>One of these days I should probably upstream some of the procedures, might be useful for others :-) <apteryx>civodul: studied at length, but then swaped out promptly. I should get back to it. *raghavgururajan woke up so late <PotentialUser-31>dongcarl: i for one want to deploy a lowmem bitcoind onto buyvm, and guix is the only way for me to define the entire kvm iso image. I looked at your manifest, and it's quite intimidating. But it's for building bitcoin, not running it, I guess <civodul>apteryx: i know that feeling, it's the kind of horror story that i prefer to forget quickly :-) <lfam>atomsk298[m]: Are you on a graphical system? Sometimes it's more reliable to do reconfigures from a TTY, in case the display server is supposed to be restarted <dongcarl>PotentialUser-31: Yeah if you don't care about running our release builds you can just use the bitcoin-core package in Guix. <dongcarl>PotentialUser-31: Thanks for pointing me to buyvm though... Their storage boxes are almost on par with Hetzner! <pkill9>is anyone working on packaging hte latest release of qutebrowser? <PotentialUser-31>dongcarl: will have to look at hetzner, i thought storage slabs on buyvm were the cheapest around <civodul>apteryx: just noticed the Rust commit on core-updates, that's quite something, thanks you & dannym! <vagrantc>"guix pull -l" reports that all of my pull generations were the same commit. <lfam>Weird! It works as expected for me <apteryx>anyone else having problem running an NFS server? <civodul>must be 316fc2acbb112bfa572ae30f95a93bcd56621234 <lfam>civodul: Yes, likely. My latest pull is of the staging merge, which pre-dates that commit <vagrantc>this was to investigate why "guix pull" exploded on a recent attempt <apteryx>and Mutabah is working on unlocking rust 1.39 with their mrustc compiler <vagrantc>but made it hard to figure out where it went wrong :) <vagrantc>oh, that was from a bunch of local commits... <lfam>I was about to say, I don't see that variable in my tree <vagrantc>i swear the same things happens with my recent pull from guix master though <lfam>Oh, I git-pulled and now I see the reference <apteryx>rpcbind-daemon restarts spurriously and gets disabled since I rebooted... hm <lfam>ngz: Are you there? I think your push of the rust-skim patch contains an error <vagrantc>looks like 453f18db343cbad1892186b85c7eb07f364b399e <lfam>There's a reference to a variable "skim-0.7" but the variable is called rust-skim-0.7 <lfam>Are you able to push a followup? <lfam>Hm, I'm not exactly sure what's up <civodul>ngz: that's due to 453f18db343cbad1892186b85c7eb07f364b399e <lfam>I would try moving the new skim-0.7 package into crates-io.scm <civodul>so that the top-level reference to skim-0.7 is in the same module as skim-0.7 <ngz>But then, shouldn't it be renamed rust-skim-0.7? <lfam>I think that you could still keep that deprecation as it is <lfam>Like, it's preferable for it to be deprecated, right? We want users to update to the new package? <civodul>ngz: the name of the variable doesn't matter at all <lfam>I see that it does make sense for skim to exist in rust-apps.scm, but the deprecation complicates things. *vagrantc is busy finding bugs today <apteryx>Haha! the rpcbind exec has moved to sbin/ <apteryx>breaking the rpcbind-daemon service than nfs depends on <vagrantc>reverting the skim commit at least works around the issue for me <ngz>OK. So let's move skim-0.7 in crates-io.scm. <lfam>ngz: I think you'll need to move skim@0.9.3 as well <ngz>Yes, probably because inheritance. <lfam>Or, you could "de-inherit" the skim-0.7 package and let it stand on its own <ngz>It is disturbing to have variables without the rust- prefix in crates-io.scm. <civodul>inheritance plus the reference in (deprecated-package "xyz" skim) <lfam>Just put it in the middle. Nobody will notice it in that giant file :) <lfam>I'm glad for the Guile baseline compiler <ngz>Ah. I cannot push the move. <ngz>make: *** [Makefile:6234 : make-go] Erreur 1 <lfam>Try `make clean-go && make` <ngz>hmmm... skim-0.7 unbound variable. <ngz>I probably forgot a piece somewhere. <ngz>I guess (deprecated-package "rust-skim-0.7" skim-0.7) needs to be locate _after_ skim-0.7 definition? <civodul>and yes, (deprecated-package "rust-skim-0.7" skim-0.7) needs to be after the definition <civodul>the top level code of the module is evaluated sequentially, that's why <bqv>Theres a reason I didn't wanna put guix on my laptop <bqv>But I've forgotten it *vagrantc somehow read that as "the top level mountain of code" <ngz>bqv: All your co-workers and friends would be jealous? <bqv>Nonfree drivers is the best I can think of... <bqv>But heck imma just try it anyway. I literally don't use the box, so bricking it is not a disaster <civodul>vagrantc: pushed a fixed for 'guix pull -l'! <civodul>so if you pull, then you'll be able to list what you pulled <vagrantc>civodul: thanks! that was... surprising! <vagrantc>the first few i just glanced at them and though "wow, the first few characters of three commits in a row match ... wait a minute..." <civodul>silly bug was more likely than an accidental SHA1 collision <vagrantc>i'm finding guix time-machine way more easy to fiddle with than the building guix from a local git branch... <vagrantc>a bit slow, but ... honestly, building from git got slow pretty fast too <pkill9>another good package transformation would be --with-additional-inputs <ngz>Hmm, I hope I didn't break anything this time… <lfam>Got any reason you to think that you did? :) <ngz>Did some grunt job… might have missed something while my brains were on vacation :) <lfam>I find that `make` and pre-inst-env can hide problems with moving variables around. So I use `guix pull --url=/home/lfam/guix` when I'm not sure <pkill9>does guix packaged qtwebengine support h264/h265 playback? <bqv>That sounds nonfree :p <lfam>There are free implementations of both of those codecs <lfam>I don't know if qtwebengine supports them or not <lfam>I'd be surprised if it does not. h264 is crucial (h265 isn't really used anywhere) <pkill9>i can play youtube videos though <lfam>Our qtwebengine depends on ffmpeg, so technically it has the capability to decode those formats <lfam>Do you know for sure which codec is being used?