<lfam>Is it possible to roll back the Guix source tree? I tried `./bootstrap && ./configure --with-libgcrypt-prefix=/gnu/store/768cgiv2b8lhbx814d8yvsryq39bwjbb-libgcrypt-1.6.3 --localstatedir=/var && make`, but afterwards I get Guile error about the PKG_CONFIG_PATH
<lfam>Here's `git status` and `./pre-inst-env guix build hello`
<lfam>That's after rebuilding Guix from the checkout
<mark_weaver>lfam: you probably need to do "make clean-go && make"
<mark_weaver>every once in a while, we make changes that "make" by itself won't probably handle, because of missing dependencies in the makefiles.
<mark_weaver>also, better make sure that GUIX_PACKAGE_PATH is not set, because it might refer to a directory with packages that depend on some feature in Guix that's not available in the older version.
<mark_weaver>lfam: btw, I suspect you'll find that it takes a long time to build packages from such an old version of guix, because the binary substitutes from March are probably no longer available on hydra
<lfam>So, you think I should try `unset GUIX_PACKAGE_PATH && guix environment guix && git checkout e99f4211 && make clean-go && make`?
<lfam>Oh man, I didn't think about that. Hopefully it's not too much.
<mark_weaver>when we replace hydra.gnu.org, we'll have more disk space and won't need to GC it so aggressively.
<mark_weaver>depending on how fast your machine is, I guess it'll probably be on the order of 12-24 hours to build those old packages.
<fps>xfce's click to focus screwed me over there ;)
<digit>^_^ xterm i dont mind. i think i care more about my shell than my term (zsh was mildly nicer than bash in some conveniences, but fish takes completion to another level... and some day i'll make xiki my main interface)
<digit>terminology's nice, for a feature&graphical heavy term. ^_^
<digit>Matt Adereth's talk (the one that inspired me to buy a kinesis advantage, n ponder buying a 3d printer too) showed the keyboard emacs was developed on. ^_^ it made so much more sense for that keyboard. heh
<fps>and RMS probably still uses one of those keyboards
<amz3>anyway, the article question whether there should be more integration between compiler, build systems and packaging
<amz3>in the spirit of go and rust. That said, guix goes a step further in the sens that it can integrate many build systems
<amz3>there is also, IIRC a hint at how IDEs work hand in hand with the build system
<digit>ACTION check his .emacs, n is surprised to see it too is not under 1000 lines (including the vast amounts of it commented out), and wonders if he adds just a couple hundred more lines, he'll no longer be an emacs noob.
<anonymiss>I progressed a bit with gnunet-gtk, but I'm unsure if my issues are related to packages not yet existing or the way they were packages/build. in particular gnunet-gtk keeps complaining about gladeui-2.0 >= 3.10.0 not being found and that libunique would be nice to have.
<anonymiss>hm.. I'm used to portage, so I need to wrap my head around other systems first. comparing to my existing gnunet-* builds wasn't completely productive. gnunet is sort of pointless currently without gnunet-gtk
<fps>anonymiss: are you working from a guix git clone?
<fps>it seems imake, as xfig has that as native input and uses it via system*
<anonymiss>might take a bit longer since I forgot to install anything ssh-like on guix, but i'll just post the two files. fps: I use webchat for a reason (and separate machines for tasks), I don't really see much future in irc, but that's another story. could've used tor-laptop > ssh to server > irc-freenode though
<fps>anonymiss: no worries, but i thought seeing the code and the error might be useful
<anonymiss>before I'm afk for a while, what about experimental feature builds in gnunet? there's an marked as experimental subset of functions which provide conversation, qr, tex, functions. or maybe it's no longer experimental now.
<fps>just distributing the binaries, not talking about decentralizing the build yet
<anonymiss>fps: distributing through gnunet would have the added bonus that you don't need to rely on anything other than the gnunet-stack if you no longer want to use the old stack when gnunet is operational with applications on top of it.
<fps>anonymiss: i agree about a solution on top of gnunet or some other secure cryptographic distributed system would be better
<fps>i'm talking about a mid term load easening ad-hoc method :)
<anonymiss>so you mean to move from hydra-currently to $something-distributed to gnunet
<fps>oh ok, so it's overloaded with serving files already ;)
<fps>i might be missing quiete a few details though. authentication issues aside what would stop me from uploading an archive of the contents of a gnu store path to a torrent tracker and sharing the .torrent file?
<davexunit>whoa whoa whoa, we don't have nethack packaged!?
<anonymiss>could I just try and update glade3 for gnunet-gtk? I'm not sure about the outcomes of this. on gentoo/portage there are slots (3 and 3.10 for dev-util/glade).. I'm not yet sure if it would break some packages if I update glade on guix or if I haven't understood the full complexity of guix yet.
<davexunit>anonymiss: you can make your own special glade package to see if it works
<davexunit>without modifying any of the existing package variables
<anonymiss>okay. but just to understand guix a bit more, there aren't any hardcoded dependencies of packages depending on just this one version of glade you use, and by changing the version, one would have to deal with the resulting conflicts which could happen at build time?
<fps>easiest is probably to inherit frrom the original glade package?
<davexunit>yes that's usually what you'd want to do, but if you're just getting started it's OK to just copy/paste the entire thing
<anonymiss>I see. okay, I'll try if I can work some more on it later this day. as much as I dislike irc, I should setup weechat again on a laptop which isn't routing everything through tor. issues are solved faster :)
<fps>just give it a new name, variable and change the version. then use that as input to gnunet-gtk
<anonymiss>hm. interesting. it's interesting to learn a bit of scheme at the same time while packaging, I only learned about scheme because I looked at guix, I like it so much I'll just take my basic python knowledge and learn more about scheme/guile.
<mark_weaver>fps: do you need to enable the serial console within GRUB, or would it suffice to enable the serial console for linux-libre? if the latter, see section 7.2.2 ('operating-system' reference) of the Guix manual, specifically the 'kernel-arguments' field.
<mark_weaver>if you need the serial console within GRUB, then you'll probably need to hack the code that generates the grub.cfg. see 'grub-configuration-file' in gnu/system/grub.scm
<fps>mark_weaver: thanks. i was wishing i could get into my guixsd image on a remote server without vnc, since i have no vnc viewer here
<fps>mark_weaver: but it seems i'm out of luck and will have to try packaging another vnc viewer later..
<stack>hello, I'm new to guix, even if I saw nix some time ago, I'm searching on the list archives some rationale on why guix exists and the development wasn't focused on nix/nixos alone, was that because of the license, systemd "requirement", conf language or none of the above? I find this project amazing and I would like to give it more attention, maybe even hacking on it a bit, but when I see those
<stack>effort separations I need to figure out what is happening , can someone give me some hints? thanks
<davexunit>mark_weaver: there's also 'git merge --rebase' that may be useful in this scenario
<davexunit>this is how I merge all branches such that the history stays linear.
<mark_weaver>civodul: btw, it turns out that my video playing problems are kernel-related. it seems that linux-libre-4.2.x on the Libreboot X60 has issues where I often have to reboot to get video working again.
<mark_weaver>and the problem I had with "guix system build" was fixed by "make clean-go && make"
<mark_weaver>sometimes, we need to include the same package in both 'inputs' and 'native-inputs', for example, and it may be important for them to have different keys (the strings) so that they can be referenced unambiguously.
<fps>mark_weaver: yeah, i'm only intending to use this in cases where those special cases do not apply..
<mark_weaver>I guess the thing is, as we add more layers of macro sugar, the connection between what you see and what the resulting code becomes is more complex, and it can seem increasingly like magic.
<fps>but it kind of irks me to type the same string twice over and over..
<davexunit>I've thought this over several times and the only thing that would make sense to me would be to add bare packages to the list if you want to use the package's name verbatim and use the default output
<francis7><mark_weaver> civodul: btw, it turns out that my video playing problems are kernel-related. it seems that linux-libre-4.2.x on the Libreboot X60 has issues where I often have to reboot to get video working again.
<mark_weaver>my X60 also seems significantly less stable than it was with older kernels. often it seems to just freeze, and I can't get it to do anything at all and must reset it.
<mark_weaver>but I suppose the X60 is of less interest given that there's the Libreboot X200 that works much better in almost every respect. the only reason I'm using the X60 now is because of a hardware problem with my X200.
<vindarel>Hi all, last time I came here I asked if there is a debian package, and there is not. So I tried, and eventually encountered an error during the compilation which seems more related to guix than to the debian package. Would you like to have a look at it ? https://gitlab.com/vindarel/guix-debian/issues/1
<vindarel>it's somithing like "ice-9/boot-9.scm:106:20: no code for module (json)"
<vindarel>thanks for your comments that may help me understand.
<fps>especially across machines, etc.. branches are so useful, and fine grained commits, too.. hmm, sure one can squash them down to a single one once one's happy, but it seems to me people here live wihtout feature branches?
<davexunit>vindarel: you could apply just the patch that fixes the issue
<francis7><mark_weaver> but I suppose the X60 is of less interest given that there's the Libreboot X200 that works much better in almost every respect. the only reason I'm using the X60 now is because of a hardware problem with my X200.