<lfam>Am I correct to think that `guix gc --references` works by scanning files looking for strings like '/gnu/store/...'? Basically like grep? <lfam>I'm trying to increase my understanding and also help explain something to Hartmut on guix-devel <emyles>fwiw I didn't manage to get offloading working but I am happy to wait for guile-ssh before I try again <lfam>The action seems to be in (list-relatives) from 'guix/scripts/gc.scm' <lfam>Dense function for a novice <jlicht>sneek: later tell civodul: it seems that if I want to include the (json) module in e.g. (guix build node-build-system), it will be part of the module-import derivation either way because of the modules that are imported by default via build-expression->derivation <lfam>Or, does `guix gc --references` just refer to store metadata, which was created by scanning the store item earlier? <lfam>I'm reading every search engine result for 'gc references' in the IRC logs :p <dpg23>So does 'guix package -i emacs' compile all dependences, and emacs itself, from source? <lfam>dpg23: If you have authorized the use of binary substitutes from hydra.gnu.org, and substitutes are available for the derivations you are trying to build, then you will download the binary substitutes instead of building. Otherwise, you will build from source. <lfam>It's not "all or nothing" if you've authorized substitutes. You might build some parts of the dependency graph that aren't available, and use substitutes for the rest <lfam>We try to make substitutes available for recent commits to our Git repository, but if your version of Guix is too old, we will have probably garbage collected them. We should try to make that tail as long as possible. <lfam>Yes, I think it's pretty cool, too. The binary substitutes are "referentially transparent" to building from source. <lfam>The UI typically first tells you what will be built and what will be substituted, but if there are grafts involved, the UI suffers a bit :( <lfam>And of course, there could be other substitute providers with their own signing key that you would have to authorize. I sometimes use this mechanism to transfer substitutes of private packages from my fast computer to my slow computer. <dpg23>That would be useful. Ideally I'd like my server to build for my laptop. <lfam>A CI server for Guix. It's a work in progress to replace the Hydra software we use now <dpg23>That's good news, I wish mthl luck! <lfam>So many emails on guix-devel... <dpg23>@emyles Did you ever get the (ssh-options '()) to function? <dpg23>Anyone have luck with openssh and the offload facility? Pretty sure I just need to specify (ssh-options '("-c" "aes256-ctr")) somehow. <dpg23>I've seem to almost have it working, for the record. ***Piece_Maker is now known as Acou_Bass
<amz3`>Is there any progress done regarding dual boot ubuntu and guix together? <amz3`>I'd like to be able to install ubuntu, guix and my home directory in different partitions so that I can boot guix when I need it and ubuntu when I want to play games <amz3`>janneke: you edit manually guix grub.cfg? <amz3`>janneke: your solution is straighforward thanks <sneek>civodul, you have 2 messages. <sneek>civodul, dsmith says: Are there any continuous integration servers for guile? For guix? <sneek>civodul, jlicht says: it seems that if I want to include the (json) module in e.g. (guix build node-build-system), it will be part of the module-import derivation either way because of the modules that are imported by default via build-expression->derivation <anthk_>gnome shell extension plugin is missing in both icecat and epiphany (Gnome Web) <jlicht>How do you fine folks manage the plethora of patches (own and guix-devel incoming) w.r.t. you git checkout? <jlicht>I currently have one checkout that is basicaly always at master, with sometimes an applied patch from the ML <jlicht>and another directory with my own development checkout <janneke>jlicht: i have guix-head (always master), guix (master or 0.10.0) + my patches, guix-mingw, and guix-hurd <rekado_>in xfce4-terminal hitting <TAB> at an empty prompt gives me this error: "bash: words: bad array subscript" <iyzsong>yes, my xterm has this issue too. I think it's from guix's bash completion script. <kyamashita>Hi all. I'm having trouble trying to push to the guix repo. Git keeps telling me that unpack fails. <kyamashita>I've tried repacking but it doesn't seem to help. <kyamashita>Hi lfam! Do you have time to help me with a git issue? <kyamashita>lfam: Git tells me that unpacking fails when I try to push to the Guix repo. <lfam>Can you paste the full output? <lfam>Also the output of `git --version`? <kyamashita>Connecting to git.savannah.gnu.org (port 9418) ... 208.118.235.72 done. <kyamashita>Writing objects: 100% (5/5), 1.53 KiB | 0 bytes/s, done. <kyamashita>error: unpack failed: unpack-objects abnormal exit <kyamashita> ! [remote rejected] 1c2f333d8a7463dee8454e0f366044aa09be72d3 -> master (n/a (unpacker error)) <kyamashita>error: failed to push some refs to 'git://git.savannah.gnu.org/guix.git' <lfam>Hm, not a lot of detail from the remote <lfam>I wonder if something is corrupted locally <kyamashita>Let's see. I'll pull a new copy and see if that works. <lfam>kyamashita: I think it's because you are trying to push to the git:// URL <lfam>ssh://git.sv.gnu.org/srv/git/guix.git <lfam>It's possible to use different URLs for fetch and push <lfam>IIRC the git:// protocol is unauthenticated, so it's not really suitable for this case. It's probably disabled on the remote end or something <lfam>I doubt your local repo is corrupted <kyamashita>I thought I had commit access, but maybe I was supposed to accept something and I didn't. <lfam>kyamashita: Are you sure the right SSH key is being used? <lfam>I ended up specifiying that in my ~/.ssh/config for the git.sv.gnu.org domain <kyamashita>How can I be sure? I only see one public SSH key in my ~/.ssh directory. <lfam>And you uploaded the public key to your Savannah account? <lfam>If you can use that key to connect to other servers, then it should be possible to make it work. I think that our project admins have to manually approve that key for access to the repo. I'm not sure who that is, but I'd guess it's the names that are underlined here: http://savannah.gnu.org/project/memberlist.php?group=guix <lfam>Maybe that step was forgotten <lfam>By the way, my personal method is to use a separate SSH key for Savannah, and to keep a strong passphrase on it. Since other people run code from the repo, I feel a strong responsibility to protect access to it. <kyamashita>I'll see about it a bit later. For now I have to go, but I'll be back later. <jlicht>are there any plans to move the build systems (but mostly, gnu-build-system) off of the deprecated `build-expression->derivation'? <jlicht>sneek: later tell adfeno: your quit message made me laugh :-) <rekado_>is core-updates open for commits again? <rekado_>I still have the pulseaudio+bluetooth commit here that should go to core-updates. <janneke>aargh, why are some things so opaque <janneke>** Message: Missing plugin: gstreamer|1.0|totem|H.264 (Main Profile) decoder|decoder-video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, level=(string)3, profile=(string)main, parsed=(boolean)true (H.264 (Main Profile) decoder) <lfam>janneke: Does your gstreamer have an h264 decoder? <lfam>Should totem be finding it in the gstreamer package? <janneke>lfam: gst-plugins-bad said: XXX: The following dependencies are mising: ... openh264 <lfam>I guess that's why they are bad ;) <janneke>*-bad depends on QT and Wayland (WTF?) so I commented those out and added openh264 <janneke>added openh264 to propagated-inputs... <janneke>set LD_LIBRARY_PATH pointing to ~/.config/guix/video/lib/[libopenh264.so.1] <janneke>Isn't anyone viewing videos on Guix? <dpg23>I don't use GuixSD, but I perfer mpv when it comes to video players. <lfam>Did you look at Nix's totem package? It sets the variables GST_PLUGIN_SYSTEM_PATH_1_0 and GRL_PLUGIN_PATH among other <janneke>lfam: no i didn't...that may help...THANKS <janneke>ACTION cries softly, wants things less opaque <jlicht>is there any ideological reason we are currently not packaging Mono? <janneke>lfam: the XXX: missing plugin openh264 was a red herring <janneke>installing gst-libav and ffmpeg fixes it... <rekado_>jlicht: I don't remember any discussion about Mono. I guess it just hadn't come up so far. <jlicht>I have a friend coming over in an hour. Sadly, he is a M$ dev. <jlicht>and we wanted to play around with some AI for card games, and I could not convince him to use guile (for now) <janneke>mark_weaver_alt: thanks...just found that installing gst-libav already fixes it <janneke>not sure why we have that XXX comment... <janneke>i'm now looking into if some package should install gst-libav <mark_weaver_alt>what does it mean for one package to install another package? you mean add a dependency? <janneke>yes...i'd expect totem, [or gstreamer, ] or gnome-desktop or something install such things <mark_weaver_alt>janneke: I don't think that every media application should depend on every plugin. I think that plugins, by definition, are optional things that the user should be able to choose. <mark_weaver_alt>and I don't think that we should force users to install plugins for patented codecs <mark_weaver_alt>someone should be able to install a video player without adding support for things like H.264 if they don't need it, IMO anyway <janneke>mark_weaver_alt: i can see that perspective...although it took me 3 hours to package openh264, nasm, debug only to find out i need gst-libav which i never heard of <janneke>mark_weaver_alt: because i looked at the gst-plugin-* packages and a comment sead openh264 was missing <mark_weaver_alt>janneke: hmm, yeah, I can see the problem, just not sure how best to fix it. <mark_weaver_alt>I guess maybe we need some sections in the manual for setting things like this up, but without specifically promoting non-freedom-friendly codecs. <janneke>:-) me neither. Possibly by adding documentation, although I only just now checked what the docs say <janneke>oh well, i didn't waste an evening watching a video, guess that's a good thing <janneke>lfam: ... so i have a working nasm and an (at least installing) openh264 package...shall i post those? <lfam>janneke: I think so. No reason to let them go to waste <efraim>rekado_: you're welcome for the work on modular qt :) <efraim>it looks like we still need webkit something to provide qtwebkitwidgets for some of the others that are still using qt-5.5.1 <wingo>what do i have to install to be able to run texi2dvi ? <wingo>i guess i need to update, blah <mark_weaver_alt>wingo: yeah, that's a hack to cope with the fact that texlive substitute requests were bringing hydra to its knees <mark_weaver_alt>wingo: no, it's not about updating. you just need to pass --fallback <wingo>i got an inscrutable error doing "make pdf" in guile's doc/ref with texlive-minimal <wingo>an "/gnu/store/sjdkagh349840mnbv9cdhg7fvswqavhp-profile/bin/texi2dvi: pdftex exited with bad status, quitting." but everything previous appeared to succeed <lfam>Do we have any graphical MPD clients? <daviid>wingo: fwiw, i could [never] build pdf(s) for any doc, including those of my own projects, using 'makeinfo <main doc.texi> --pdf', but in that same directory, texi2pdf ... [always] succeeds <wingo>daviid: i think this is unrelated as "make pdf" via automake will use texi2pdf <wingo>ACTION builds the full texlive; waiting on the damn thing to finish grafting <lfam>We had a WIP sonata on guix-devel. But it was abandoned <lfam>Faster than rebuilding :) <wingo>bah, and it finally finished with "suspicious ownership or permission on `/gnu/store/v649mlzl1cg0qapadsjscl5kh051bjak-texlive-texmf-2015'; rejecting this build output" <mark_weaver_alt>but, I can report that after installing 'texlive-minimal', "make dvi" in guile gets further but has some errors <wingo>mark_weaver_alt: i installed texlive-minimal but "make pdf" failed <lfam>efraim: empc has a convincing slogan! <efraim>wow, qtwebengine bundles chromium, which bundles sqlite, yasm, xdg-utils, mesa!!, etc <wingo>i was trying to build texlive when i had that error <wingo>it sat and grafted for like 30 minutes before giving me that error :(( <efraim>i was looking at building some of the enlightenment apps, most seem to build pretty quickly <mark_weaver_alt>wingo: if you cherry-pick commit b79cf93ff6d1588adf4a606800ff381d4af4e052 from the 'wip-graft-improvements' branch, grafting will be a lot faster <lfam>What are the rest of us waiting for? ;) <lfam>Besides grafting, that is <mark_weaver_alt>well, I wanted to verify that grafting worked properly before pushing it, but I found that there were problems. and then I found that the same problems seem to exist without my patch too, but anyway that's why I got stuck. <lfam>Ah, that's always a discouraging turn of events <wingo>it does look like a good patch :) <efraim>wow, what does chromium not bundle <wingo>chromium does not bundle libc :) <janneke>ACTION says chromium should bundle guile <efraim>without libc they're going to have to do some work to make it a snap/flatpack/whatever :) <wingo>by default when you build chromium from git it will download prebuilt clang binaries from ~~the cloud~~ <wingo>one nice thing about guix is that no pre-built FHS binary will work on it :) <wingo>welp, there goes my desire to make a guile release tonight <wingo>if anyone is able to "make -C doc/ref pdf" on guix let me know tomorrow :) <wingo>i think the error i got was "kpathsea: Running mktextfm ecrm1095 <wingo>but with tex it's hard to know what's an error and what's just conversation <wingo>the graft finished, and with "texlive" (not texlive-minimal) i have a pdf <wingo>maybe now my distcheck will succeed :)