<vagrantc>maybe when the bootstrap binaries become an auditable seed ... revist doing a full build from source <civodul>vagrantc: i think you could build Guix itself from source <civodul>that is, using Debian's guile-2.2 package and so on <civodul>though of course that's more work :-) <civodul>what would describe would already be very useful though <vagrantc>civodul: guix isn't itself an input, so wouldn't break the dependency graph? <vagrantc>e.g. debian could share the same substitute servers and so on... <civodul>there are distros that provide a 'guix' package built from source <vagrantc>ah, ok. i had the impression the bootstrap binaries would somehow be an issue ... <civodul>now, if you take that route, you'll have to make Debian packages for guile-gcrypt etc. <vagrantc>right ... there were a few that it needed <kriyative>hi all! just recently started using Guix on Ubuntu - it <kriyative>'s been great so far, however have run into a problem using the emacs guix interface <kriyative>Running `M-x guix` ends up with the following error message: "guix-geiser-eval: Error in evaluating guile expression: <unnamed port>:19:16: Unbound variable: help-string" <lfam>kriyative: You'll have better luck getting an answer during the European day. Or you could send your question to <help-guix@gnu.org> <tune>does the mpdscribble package on guixsd work with last.fm or only libre.fm? I have the former and I don't think my scrobbling has ever worked <tune>oh I think I fixed it, it wasn't finding my config in the right spot <tune>I read the man page and found the --conf argument and that did the trick *bavier rebuilding qtwebkit for the 3rd time... <EternalZenith>Is anyone here using upstream Firefox rather than Icecat on GuixSD? <EternalZenith>I'm thinking about trying to try to install Firefox proper so that I can use more addons and features from newer non-ESR Firefox releases <bavier>woot, finally fixed our qutebrowser package <pankerini>Is there any addons that doesn't work on IceCat? <efraim>Anyone else getting errors after a bit on 'guix refresh -t github'? *efraim is on the bus ATM <efraim>This was from last night, just remembered now, figured I'd ask before digging in <civodul>efraim: if you make too many requests on GitHub's API, you need to use their token thing <efraim>Don't remember if they had something about needing to update the token or the api requests or something from a while ago <jlicht>upgrading our node packages is turning into quite a hassle, as they need some magic combination of libuv, openssl and nghttp2 <jlicht>What is the state of core-updates atm? Can I still push "rebuild-the-world" commits there? <efraim>It should go to core-updates-next, we're trying to finish up core-updates <civodul>i guess i was in denial, hoping this would never happen <civodul>not sure how we're gonna deal with that :-/ <roptat>do we need librsvg to build rust? <civodul>newer librsvg releases are written in Rust instead of C <civodul>not a bad thing in itself, but it causes bootstrapping headaches <civodul>given that Rust is "yogurt software" <roptat>I thought our rust packages were correctly bootstrapped? <civodul>actually it's rather good, i think we only miss the final bit about mrustc <jlicht>civodul: last time I checked, mrustc was mostly targetting x86_64; has this changed already? <civodul>our mrust package doesn't have a 'supported-platforms' field <jonsger>when will the fringe event will start on 31rd? any estimate yet <mbakke>civodul: I have patches for Cairo 1.16 and Rust librsvg already. It works fine (with the bundled libs). <mbakke>But it would be great to trim the Rust dependency closure, since building Rust requires e.g. git. <mbakke>Oh, and I see we only have Rust on x86_64 and i686 currently :/ <mbakke>Why does Rust depend on PatchELF? <efraim>mrustc works just fine on aarch64 last I checked <pkill9>one of my favourite things about that website is it uses no javascript <apteryx>why do we have both %gnu-build-system-modules *and* %default-modules in (guix build-system gnu)? <fusion809>Hi folks, I'd like to know where I should suggest bumping the Julia package (presently 0.6.0; 1.0.2 is the latest). <nckx>fusion809: I'd wager that if it was easy, it would have already been done. *Finding* outdated packages is the easy part :-) <nckx>Have you tried bumping it yourself? <fusion809>Nope, I'm a GNU Guile newb, must admit functional languages tend to confuse the .... out of me. Fair point, I thought it'd be as straight-forward as it is on other distros. Then again most distros I've come across have had to patch Julia in order to build it properly. <nckx>fusion809: In my limited experience Julia is one of those ‘don't update on an empty coffee press’ packages, unfortunately. <civodul>i tried to update Julia to 1.0 but it turned out to be terrible <fusion809>civodul: have you tried looking at how the NixOS' team builds their Julia 1.0.1 package? Maybe their patches might be of use to you. <_tibbe>Hi, I have a problem packaging a driver for GuixSD: Is there a way I can get the configuration file of the kernel build? It is not contained in the header package and I could not find it in the binary version. <nckx>_tibbe: We apply some changes to the defaults in gnu/packages/linux.scm but don't ship a full config file. Why do you need it? <nckx>Annoying that we don't seem to build the ‘configs’ module to support /proc/config.gz. <_tibbe>nckx: I have a thinkpad with the Wacom W8001. This can be used using the input-wacom driver. But configuring this driver requires a full blown kernel source and build tree as far as I understand. <_tibbe>There seems to be no proper alternative as far as I understand the configure.ac file <nckx>_tibbe: Interesting. For building by hand, you can extract the exact sources used to build the kernel (guix build --source ...) and manually add those CONFIG_ options above to the .config generated by ‘make defconfig’. <nckx>I admit that this loses badly, and wont help with packaging at all. You might find someone with more (Guix-related) kernel knowledge on guix-devel. <_tibbe>nckx: After all this has just become a lot larger than a simple evening project. I will try my luck with the linux-console project and input-attach and try to get it working in userland. If that fails I will try to find someone who can help me with the kernel configuration. Thanks :) <thorwil>after behaving for a while, this happened again: guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/thorwil/current-guix-1-link" <thorwil>is there anything i can do to determine what is actually going on? ***rekado_ is now known as rekado
<rekado>thorwil: does it still try to migrate the profile? <thorwil>rekado: the line before is: Migrating profile generations to '/var/guix/profiles/per-user/thorwil'... <rekado>what version of Guix do you use? <thorwil>commit: 53bcee9ea7e885e756ad4689381aa2bdfbac97ef on a ubuntu 18.04 <thorwil>i think it may now be the 4th time this happened. each time at least one guix pull working afterwards <rekado>the two of us diagnosed this before on #guix, right? <thorwil>yes, but it seemd you considered it fixed <thorwil>in the sense of: it should not happen again on the same system <rekado>thorwil: can you tell me what “ls -la ~/.config/guix/current” says? <rekado>this should be a link to “/var/guix/profiles/per-user/thorwil/current-guix” <thorwil> /home/thorwil/.config/guix/current -> current-1-link <thorwil>with a timestamp that matches the current generation <rekado>ISTR that last time you had a problem getting the links right, but it solved the immediate problem <rekado>~/.config/guix/current -> /var/guix/profiles/per-user/thorwil/current-guix -> current-guix-1-link (in the same directory) -> /gnu/store/…-profile <rekado>the 1 in current-guix-1-link could be some other number, dependent on how often you ran “guix pull”. <thorwil>hmm, /home/thorwil/.config/guix/current/current-guix isn't owned by my plain user!? <rekado>“current” should be a link to /var/guix/profiles… <thorwil>`ln -sf /var/guix/profiles/per-user/thorwil/current-guix ~/.config/guix/current` right? <rekado>yes, but before doing that maybe check what the /gnu/store/…-profile target path should be before you override existing links. *rekado has to go back to packing boxes … <thorwil>rekado: thanks so far, may things fit nicely! <thorwil>seems there's something about `ln -sf` that i should, but do not know <thorwil>better results with `rm /home/thorwil/.config/guix/current; ln -sf /var/guix/profiles/per-user/thorwil/current-guix ~/.config/guix/current` <apteryx>would 'echo' be provided by coreutils? <apteryx>and shouldn't it be available in a guix build container by default? <apteryx>thorwil: regarding ln -sf, I had tried that myself and something was fishy as well IIRC. <thorwil>i guess --no-dereference would have been required <bavier`>so, we have a couple docker tools packaged, but not docker itself? <apteryx>it seems ng0 had knew of someone that was interested in packaging it <bavier`>I don't know for sure, but I'd imagine it'd be nontrivial <ng0>I have some parts of docker packaged, but not all of them <ng0>it wasn't developed against a guix tree, but I can look into decoupling it from the mixed tree it is in right now <bavier`>ng0: that'd be great if you could share :) <ng0>I'll see if I can manage that this weekend, though I'm not promising any date