IRC channel logs


back to list of logs

<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>yes, definitely
<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
*civodul -> zZz
<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"
<kriyative>any pointers would be appreciated, thanks
<lfam>kriyative: You'll have better luck getting an answer during the European day. Or you could send your question to <>
<tune>does the mpdscribble package on guixsd work with or only 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?
<kriyative>lfam: ok, thanks - will try that
<Gamayun>bavier: Nice!
<g_bor>hello guix!
<civodul>Hello Guix!
<efraim>Anyone else getting errors after a bit on 'guix refresh -t github'?
*efraim is on the bus ATM
<civodul>refreshing while on the bus :-)
<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>I have my api token set
<civodul>oh, then i don't know
<efraim>Don't remember if they had something about needing to update the token or the api requests or something from a while ago
<roptat>hi guix!
<civodul>morning roptat!
<jlicht>hey guix!
<civodul>heya jlicht!
<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
<jlicht>efraim: thanks for the heads-up
<swedebugia>hi :)
<civodul>the Rust-y librsvg starts making waves:
<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>the converse
<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?
<jlicht>roptat: only on x86_64 I think
<jlicht>if at all :)
<roptat>ok, not really nice
<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>jlicht: good point, dunno!
<civodul>our mrust package doesn't have a 'supported-platforms' field
<jonsger>bus "booked" from FOSDEM back :)
<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
<mbakke>Ooh, the platform code hosting platform is now open for public testing:
<pkill9>one of my favourite things about that website is it uses no javascript
<pkill9>or third party requests
<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 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>hi guix!
<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>deja vu
<rekado>what version of Guix do you use?
<thorwil>commit: 53bcee9ea7e885e756ad4689381aa2bdfbac97ef on a ubuntu 18.04
<rekado>that should be recent enough
<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
<rekado>let’s check
<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
<rekado>that’s not correct
<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>so let’s fix this.
<rekado>the link chain should be:
<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>this file shouldn’t exist
<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>i'd appreciate if anyone else could have a look at this short bash session:
<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?
<thorwil>man page says: GNU coreutils 8.28
<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
<apteryx>ah, maybe!
<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
<apteryx>but this was a while ago
<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