IRC channel logs


back to list of logs

<dpg23>Hello. Is the offload facillity only supported by lsh and not openssh?
<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>dpg23: there was a discussion a few days ago:
<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
<dpg23>emyles: thanks!
<emyles>dpg23: you're welcome
<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, 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
<dpg23>Wow. That's pretty cool.
<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>Check out mthl's GSoC project, cuirass:
<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.
<dpg23>I had a typo in the machine.scm (>.<) but I did find this helpful for exporting lsh keys to openssh
***Piece_Maker is now known as Acou_Bass
<amz3`>Is there any progress done regarding dual boot ubuntu and guix together?
<janneke>amz3`: what do you mean?
<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
<alezost>amz3`: I personally don't have any problems with dual booting. I described my way here: <>. There is also another way described in that thread by paroneay`
<amz3`>ACTION looking at it
<janneke>i'm using a menu-entry in guix
<amz3`>janneke: you edit manually guix grub.cfg?
<amz3`>janneke: your solution is straighforward thanks
<janneke>amz3`: yw
<amz3`>civodul: o/
<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>o/ guix
<paroneayea>hey jlicht :)
<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"
<rekado_>does anyone else see this too?
<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?
<rekado_>kyamashita: I can push just fine.
<lfam>kyamashita: Sure!
<rekado_>(just pushed a minute ago)
<kyamashita>rekado_: Perhaps I am doing something wrong.
<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>Pushing to git://
<kyamashita>Looking up ... done.
<kyamashita>Connecting to (port 9418) ... done.
<kyamashita>Counting objects: 5, done.
<kyamashita>Delta compression using up to 2 threads.
<kyamashita>Compressing objects: 100% (5/5), done.
<kyamashita>Writing objects: 100% (5/5), 1.53 KiB | 0 bytes/s, done.
<kyamashita>Total 5 (delta 4), reused 1 (delta 0)
<kyamashita>error: unpack failed: unpack-objects abnormal exit
<kyamashita>To git://
<kyamashita> ! [remote rejected] 1c2f333d8a7463dee8454e0f366044aa09be72d3 -> master (n/a (unpacker error))
<kyamashita>error: failed to push some refs to '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>Try the SSH URL
<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>Now I've been denied permission.
<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 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?
<kyamashita>Yes, I see it there now and it's the same key.
<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:
<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.
<kyamashita>Thanks for the help, lfam!
<lfam>You're welcome!
<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 :-)
<sneek>Will do.
<rekado_>is core-updates open for commits again?
<rekado_>I still have the pulseaudio+bluetooth commit here that should go to core-updates.
<dpg23>Hello, again, I've managed to get the client to connect to the offloader, however I'm getting an error building. I think it may be related to bug;bug=18115 - however that patch should've been merged in with 0.10.0, so I'm at a loss.
<janneke>aargh, why are some things so opaque
<janneke>totem ~/toystory.mp4
<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)
<janneke>totem --debug ~/toystory.mp4
<janneke>Unknown option --debug
<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
<janneke>so, I created an openh264 package
<lfam>I guess that's why they are bad ;)
<janneke>that needed nasm
<janneke>so I created a nasm package
<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/[]
<janneke>Isn't anyone viewing videos on Guix?
<rekado_>I'm using mpv.
<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
<dpg23>VLC in a pinch.
<janneke>lfam: no i didn't...that may help...THANKS
<lfam>janneke ^
<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)
<mark_weaver_alt>janneke: you need the 'gst-plugins-ugly' package
<mark_weaver_alt>oh, also, 'gst-plugins-libav'
<mark_weaver_alt>I've never used the 'gst-plugins-bad' package
<janneke>mark_weaver_alt: thanks...just found that installing gst-libav already fixes it
<mark_weaver_alt>ah, good
<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>janneke: some package? what do you mean?
<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
<janneke>*depend on
<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
<mark_weaver_alt>what do you think?
<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
<mark_weaver_alt>but it could refer to gst-* packages anyway
<janneke>oh well, i didn't waste an evening watching a video, guess that's a good thing
<mark_weaver_alt>heh :)
<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 ?
<mark_weaver_alt>wingo: 'texinfo'
<mark_weaver_alt>hmm, well, maybe something else is missing
<mark_weaver_alt>'make dvi' in guile still fails for me
<mark_weaver_alt>ah, well, I guess you'll also need 'texlive' or 'texlive-minimal'
<mark_weaver_alt>ACTION tries installing texlive-minimal
<wingo>guix substitute: error: download from '' failed: 410, "Gone"
<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
<mark_weaver_alt>it's faster to build than to download anyway
<wingo>what a mess
<mark_weaver_alt>ACTION goes afk
<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>but i am not entirely sure
<daviid>wingo: ok
<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
<wingo>still grafting, wtff
<lfam>Faster than rebuilding :)
<efraim>lfam: unpackaged, but theres
<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>wingo: try again. that's a mysterious heisenbug
<mark_weaver_alt>but, I can report that after installing 'texlive-minimal', "make dvi" in guile gets further but has some errors
<mark_weaver_alt>it's possible that the full texlive might work better, dunno.
<wingo>mark_weaver_alt: i installed texlive-minimal but "make pdf" failed
<lfam>efraim: empc has a convincing slogan!
<mark_weaver_alt>but I have to go soon, no time to investigate now
<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
<lfam>Worst case annoying bug
<mark_weaver_alt>wingo: if you cherry-pick commit b79cf93ff6d1588adf4a606800ff381d4af4e052 from the 'wip-graft-improvements' branch, grafting will be a lot faster
<mark_weaver_alt>I should probably push that to master soon
<mark_weaver_alt>I've been using it myself for several months
<lfam>What are the rest of us waiting for? ;)
<mark_weaver_alt>heh :)
<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 :)
<wingo>afaiu anyway :)
<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>to use to build chromium
<wingo>one nice thing about guix is that no pre-built FHS binary will work on it :)
<mark_weaver_alt>wow, that's terrible
<wingo>welp, there goes my desire to make a guile release tonight
<wingo>eaten by the graft grue
<wingo>yeah :/
<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 :)