IRC channel logs


back to list of logs

***malaclyps2 is now known as malaclyps
<vagrantc>wow. ghc has been stuck at building 100% for longer than it was at all the previous percentages...
<agohoth>hey does guix have latest kernel?
<agohoth>also is there any chance of iceWM package?
<agohoth>or jwm?
<vagrantc>agohoth: if there's something you want on guix and there isn't already someone working on it, might not be hard to package it :)
<bdju>there's also the guix wishlist on the libreplanet wiki
<vagrantc>agohoth: it appears to be a few minor versions behind on linux-libre
<vagrantc>agohoth: e.g. 5.3.4 vs. 5.3.6
<nckx>agohoth: Yes, we track the latest linux-libre, although not instantly.
*nckx is actually updating linux-libre right nowish.
<vagrantc>hrm. "guix environment --pure --ad-hoc diffoscope python-pypdf2" fails to find PyPDF2 ... but "guix environment --pure --ad-hoc diffoscope python-pypdf2 python" is able to find PyPDF2 ...
<vagrantc>if i add python as an input for diffoscope, it doesn't change the behavior...
<vagrantc>hmmm... if i add python to propegated inputs, then it works as i'd expect...
<ixtlan>Greetings@Guix :]
***jonsger1 is now known as jonsger
<leoprikler>quick question: how does Guix deal with fonts?
<roptat>hi guix!
<leoprikler>hi roptat
<civodul>Hello Guix! :-)
<leoprikler>hi civodul
<civodul>hmm diffoscope fails to build on master
<civodul>one test failure
<vagrantc>civodul: i've had inconsistant test failures after i pushed :/
<vagrantc>test failure related to stat?
<civodul>vagrantc: yes, that one
<kmicu>Finally a vulnerability. ヽ(*^▽^)/
<kmicu>An excellent opportunity to train the drill.
<vagrantc>civodul: diffoscope seems to build more often than not ... no idea what's going on
<civodul>we should tell upstream ;-)
<vagrantc>still always have a hard time identifying if the issue is with some surprise thing guix is doing that upstream didn't expect, or something is broken
<vagrantc>i'll try to dig into it a bit more tomorrow
<vagrantc>the lack of writeability in the source tree for git checkouts is a surprise i've only ever seen on guix
<civodul>ah yes
<civodul>the issue here seems to happen when the Python code parses the output of the 'stat' command
*vagrantc managed to get 10 successful builds with --rounds=10
<civodul>talk 'bout reproducibility! :-)
<vagrantc>maybe --rounds isn't working like i think it should ... it seems to only do a single build
<nee`>vagrantc: I think it only repeats parts of the build that aren't already cached at the start of it.
<vagrantc>i tried "guix build --check --no-grafts --rounds=10 diffoscope"
<vagrantc>civodul: shows success on i686 and x86_64 (and waiting for armhf and aarch64)
<nee`>maybe you can `guix gc -d $(guix build --no-grafts diffoscope)` and then try again. I remember doing something like that
*vagrantc tries again tomorrow
*vagrantc waves
<roptat>--check and --rounds are not compatible: --check is for when you have already built, --rounds is when you have not yet built the package
<nixo_>Hello guix, I had a random look at /var/log/messages and saw this line: guile: Libgcrypt warning: missing initialization - please fix the application
<nixo_>Is this expected?
<leoprikler>does anyone else have issues with Cantarell Oblique fonts?
<dutchie>civodul: if you are around and want to step through debugging issue 37662 with me more interactively, I'm the reporter
<civodul>dutchie: hi!
<civodul>thanks for chiming in
<civodul>could you check if your guix-daemon is linked against 2.29?
<civodul>you need to (1) check the "Exec" line in /etc/systemd/system/guix-daemon.service
<civodul>and (2) run "ldd .../bin/guix-daemon", for that program
<dutchie>the path is /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon
<dutchie>which is just a symlink to a guile script in /gnu/store
<dutchie>it execls something promising-looking though
<dutchie>(that is /usr/bin/ldd, there doesn't seem to be a guix ldd on my PATH)
<civodul>dutchie: does "ldd /proc/PID/exe" show the same, where PID is the PID of the running guix-daemon process?
<dutchie>the paths are the same, but the hex numbers in brackets after are different
<civodul>so does "guix build nss-certs" work now?
<civodul>or does it still fail?
<dutchie>it's built already
<dutchie>i don't think i ever managed to reproduce it after the initial failure
<civodul>aaah, so problem solved, dutchie? :-)
<dutchie>I guess so
<civodul>i thought we were still trying to get nss-certs installed
<dutchie>a little frustrating never to quite get to the bottom of it
<civodul>well, you probably fixed it when you upgraded root's guix, i'm guessing
<civodul>but yeah, it's frustrating
<civodul>in the guix-daemon.service that we ship now, the locale is fixed
<civodul>that avoids this kind of problem
<civodul>and it doesn't have any downside since you can always run the 'guix' command itself under your favorite locale
<civodul>that's independent
<dutchie>ah cool
<dutchie>(also, the root account is complaining because GUIX_LOCPATH isn't set)
<dutchie>thanks anyway, keep up the great work on guix!
<civodul>yeah, i guess you need to double-check your .bash_profile and all
<civodul>thanks, dutchie!
<dutchie>if i logged in as root more often i'd bother to fix it
<civodul>heheh, makes sense
<dattashantih3>Does anyone know how to get guix pull to work behind an http/https proxy?
<roptat>I think it honors http_proxy variables
<dattashantih3>hmm, it doesn't seem to
<dattashantih3>I set the http_proxy variables for the guix-daemon process
<dattashantih3>and for my user
<dattashantih3>and guix package -i successfully uses the proxy
<roptat>maybe it's related to git, then?
<roptat>maybe try to set http.proxy in git
<roptat>I don't really know, just guessing ^^'
<dattashantih3>I'll try that, although I use git through the proxy all the time without setting that
<dattashantih3>maybe it is an issue with guile-git not picking up the environment
<dattashantih3>Great, setting http.proxy in git for the user running guix-daemon worked! thanks.
<roptat>maybe we could find a way to set that at runtime
<dattashantih3>yeah, it is still a little strange that it doesn't pick it up from the environment
<roptat>would you like to send a bug report?
<dattashantih3>It looks like there are already related outstanding bug reports
<vup>hey guix! is it normal for guile-static to take ages to compile, when using the qemu-binfmt thing (for armhf on x86_64)? It seems to take more than 1h for `BOOTSTRAP GUILEC ice-9/psyntax-pp.go`
<vup>also this seems similar:
<fps>hmm, where can i inspect the profile that corresponds to the environment that i created with e.g. guix environment --ad-hoc arpack-ng
<fps>ah, got it in the docs
<wingo>vup: i have noticed that armv7 under qemu is really quite slow; what you are seeing sounds possible though obviously it's terrible
<wingo>aarch64 is much faster for me
<vup>hmm, but i can't use aarch64 for a armhf-linux compile, right?
<vup>(for --system armhf-linux)
<civodul>vup: you can do that usually, but it depends on the CPU
<vup>civodul: interesting, how do i tell qemu-binfmt-service-type to use a aarch64 qemu then?
<civodul>vup: so your machine is aarch64, right?
<vup>no x86_64
<civodul>ah, oh, i see
<civodul>i don't think qemu-binfmt-service-type can be told to do armhf on aarch64
<civodul>it's also not clear whether that'd be faster
<civodul>i have it configured to do armhf and aarch64 separately
<civodul>like you did, i guess
<vup>i thought thats what wingo was saying, that aarch64 under qemu is much faster
<vup>well i only need armv7, so i only have that
<wingo>yeah just noting that the difference in speed was large between the different foreign ISAs
<lprndn>hello guix!
<vup>so anything i can do to maybe improve performance or help improving performance?
<wingo>vup: i am working on jit compilation in guile; things will get faster that way
<wingo>also if you avoid stripping the .go files it can go faster, but guix wants to bootstrap, so dunno
<vup>oh sounds awesome, but surely something more fundamental must wrong if it takes literally over one hour, no?
<lprndn>htsr: hi!
<htsr>if i want to update guix, i need to guix pull then guix upgrade (guix system reconfigure is not needed right?)
<vup>htsr: guix upgrade only updates the profile of the user you run it with (so probably root or your personal user)
<htsr>vup: thanks
<vup>to update things like system services, or the base program's you have installed in your system config you need to use gix system reconfigure
<lprndn>htsr: and guix system reconfigure will update the system but not user profiles.
<htsr>for my school i need to use /etc/crontab (i know i should use mcron but it's not what's asked) but when i install mcron the cron daemon in /gnu/store/...mcron/sbin/cron is never started, how can i fix this?
<htsr>should i write a new sheperd service?
<lprndn>I'm fiddling with containers. Is it possible to use guix system container without sudo? (or root). Reading the sources, it seems needed for #:host-uids but if i remove it, it fails. (filesystems need #:host-uids?)
<civodul>vup: i suspect there are redundant graph traversals in the compiler (in Guile), but that's a difficult problem
<wingo>that's probably not the juiciest piece to bite off fwiw
<lprndn>htsr: a shepherd service is probably the right way, yes. But if you're in a hurry and you know what you're doing (i'm not) you could maybe work something with .bash stuff.
<vup>htsr: as lprndn a shepherd service, see here for more details:
<htsr>vup: i should only use the crontab, not mcron gexps :/
<vup>ah oh ok
<htsr>lprndn: so there's a way to start a daemon at boot without sheperd?
<vup>civodul: wingo: i see :/
<wingo>i mean if guix wanted to, it could cross-compile from x86-64 rather than emulating a native compile
<wingo>but that's complicated too
<wingo>anyway, jit will land with guile 3, which speeds up `eval' considerably, which helps bootstraps. so, things are moving...
<fps>man, julia is still quite broken. what are they doing in their build? crazy people :)
<wingo>but finding the right path forward isn't straightforward
<lprndn>htsr: i don't use this so don't quote me but I suppose starting cron from .bashrc could work. if you need anything in /etc/my-file you can also look at the etc-service-type in the manual. ;)
***lx0 is now known as lxo
<htsr>lprndn: but only when a user login, right? thanks for the etc-service-type, I will put my crontab here
<roptat>htsr, I don't get why you have such limitations? If you have access to /etc/crontab or /etc/config.scm, why can't you put your cron jobs there?
<htsr>roptat: /etc/crontab doesn't work because cron is never started...
<lprndn>htsr: yes, i suppose. but if you start looking at etc-service-type the you're really close from a simple service to start cron... and then not so far from services extensions so you rewrite everything and then the world...
<lprndn>(see simple-service in the manual)
<roptat>well, as people pointed out, you can use config.scm to run mcron and add jobs, or you can write your own mcron service that would read from /etc/crontab, but that's not really the spirit of guix
<htsr>lprndn: roptat thanks, I'll look at simple-service.
***Server sets mode: +cnt
<civodul>wb, bayfront-log :-)
<civodul>nckx & all: i posted a draft blog post for the /var/guix/profiles/per-user/ issue: (at the bottom)
<janneke>civodul: nice...and pretty silly/obvious once you see it :)
<bricewge>Hello Guix!
***Server sets mode: +cnt
<bricewge>I was hoping to get a third example with the recent batctl patch, but it doesn't contain the batman-adv module.
<nckx>bricewge: Those flags look bogus. What's wrong with the module without them? (I've built it, but am not loading it 😉)
<bricewge>nckx: The Makefile is written strangely (
<nckx>Oh, there's nothing to load. Well, that answers my quesh.
<bricewge>I planed to package the same way as I did in Nix
<bricewge>Yes nothing is build, that's what I'm trying to solve with the make-flags
<nckx>Sigh. So we'll end up adding #:make-flags pass-though for… BADLY_WRITTEN_MAKEFILE=true, not for COOL_FEATURE=yes? Such is the way of the world.
<bricewge>Unfortunatly. I could still patch the 2 makefiles to workaround it tought.
<bricewge>Anyway my question was more on the documentation side of thing. When I read `extension of gnu-build-system` i thaught I could use any of the arguments of the gnu-build-system, did I misread it or "extension" is used incorectlly there?
<nckx>bricewge: Neither, really. It's just not as ‘wholesale’ an extension as it led you to believe.
<nckx>#:tests? works because #:tests? is explicitly defined as a field. I've done the same with #:make-flags now, it works (the flags are passed) but still builds nothing.
<bricewge>nckx: You just added `(make-flags '())` in linux-module-build?
<bricewge>I can take it form there, I need to sharpen my skills in Guile/Guix!
<nckx>bricewge: Yes.
<nckx>Let's not push that unless you end up needing it, though 🙂
<bricewge>Hum, okay. I'll try patchin the makefiles then.
<bricewge>What's the reason behind not passing this flag?
<nckx>bricewge: Adding #:make-flags support is fine, it's just that it didn't make your pasted package suddenly build a .ko. Maybe passing another make-flag will, and then it's fine, or the issue is something else entirely and then let's not bother.
<nckx>bricewge: Can't speak for Danny, but I think ‘well-written’ modules shouldn't need it.
<ng0>if someone wants to update libmicrohttpd, it should probably be fine with gcc, but you'll hit a checksum mismatch once the mirror servers catch up in n hours to 24 hours, which contains a build fix for clang
<bricewge>nckx: Oh, okay. I'managed to build it with thoses falgs in Nix, so it /should/ work.
<ng0>just i ncase someone wants to do the update today.. wait 24 hours
***Server sets mode: +cnt
***Server sets mode: +cnt
<lfam>Looks hard at Golang again
<lfam>More big changes in the current version of Go
<bricewge>nckx: Sorry to bother you again. I need the kernel version, but I see it's a TODO in the configure of `linux-module-build-system`. And I have no idea how to get it.
<ng0>though mirror now has catched up.. so not all mirrors take 24 hours
<nckx>bricewge: I don't have time to look at the code to see what the TODO's about, but the l-m-b-s takes a #:linux argument to pass the kernel package. It defaults to ‘linux-libre’. So you can simply use ,(package-version linux-libre) to get its version.
<nckx>Maybe it'd be nice to do this differently some day to ease customisation, but the above is perfectly fine for now.
<bricewge>nckx: Thanks a lot! I'll do with that.
<cbaines>Does anyone know what the package-transitive-supported-systems means?
<cbaines>I think with the recent core updates merge, lots of packages are only transitively supported now on x86_64-linux and i686-linux
<cbaines>I think this might be because of the bootstrap changes, as some of the new packages involved declare they only support x86_64-linux and i686-linux, so most packages in Guix also only support those systems.
<dongcarl>mbakke: I found a solution to the problem we were exploring. I'll post something on the mailing list and CC you, it might apply to other things as well.
<mbakke>dongcarl: excellent! what was the solution? :-)
<dongcarl>mbakke: It's not pretty, gimme a sec to explain
<dongcarl>with the current patch, `x86_64-w64-mingw32-g++ -E -v -xc++ - < /dev/null > /dev/null` looks like:
<dongcarl>The problem is that we need `/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include` at the end of this list
<dongcarl>so that `#include_next` will work
<dongcarl>My solution is to set `CROSS_CPLUS_INCLUDE_PATH` to be all of the `/gnu/store/blahblah-gcc-cross-x86_64-w64-mingw32-7.4.0/*` paths first, THEN `/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include`
<dongcarl>This seems to override the ordering, and make things work
<dongcarl>HOWEVER, I did discover that doing the same to `CROSS_CPATH` doesn't work, as in, the ordering in the env var won't be respected.
<dongcarl>mbakke: Let me know if that makes sense
<dongcarl>It does seem hacky... So perhaps I'm doing something in a very roundabout way
<mbakke>dongcarl: so the solution is to simply change the order of the CROSS_CPLUS_INCLUDE_PATH entries?
<dongcarl>mbakke: `CROSS_CPLUS_INCLUDE_PATH` isn't originally set only `CROSS_CPATH` and `CPATH` are set, I had to manually set `CROSS_CPLUS_INCLUDE_PATH` to the order I want
<mbakke>indeed, and the package already does set CROSS_CPLUS_INCLUDE_PATH (albeit in a different order), right?
<mbakke>anyway, the fix (unfortunately) makes sense to me :-)
<dongcarl>mbakke: Nope, the package does not already set CROSS_CPLUS_INCLUDE_PATH
<mbakke>maybe i'm reading this code wrong?
<dongcarl>mbakke: Oh sorry, I've changed `'("CPLUS_INCLUDE_PATH" "LIBRARY_PATH" "C_INCLUDE_PATH")` to just `'("CPATH" "LIBRARY_PATH")`
<dongcarl>But in either case, the `include/c++`, `include-fixed` paths are not present in any environment variable, they seem to be paths that gcc defaulted to for system includes
<dongcarl>Hmmm... This is probably better explained in an email
*dongcarl goes off writing
<dongcarl>mbakke: thanks for bearing with me!
<mbakke>dongcarl: thanks for fixing the issue :-)
<dongcarl>mbakke: Hopefully this sheds some light on that long-standing `include_next` issue too
<mbakke>dongcarl: yes, one step closer to a definitive fix :-)
<janneke>dongcarl: great work!
<dongcarl>:-) thanks janneke!
<reepca>what's the proper way to get a cross-compiling toolchain for personal use (as opposed to being used to build packages)? There's cross-gcc in (gnu packages cross-base), but it only makes a gcc, not a gcc-toolchain. I tried invoking make-gcc-toolchain from (gnu packages commencement) with it, but it complains: "reference to invalid output 'debug' of derivation '/gnu/store/...-glibc-cross-arm-linux-gnueabihf-2.29.drv"
<dongcarl>Is guix-devel down?
<dongcarl>Don't see it in the list of mailing lists anymore
<dongcarl>reepca: I can help you... Gimme a sec
<dongcarl>reepca: Here's how we do it:
<dongcarl>reepca: Beware of the `CROSS_` environment variables though, they need to be set correctly
<vagrantc>dongcarl: archive still exists:
<dongcarl>vagrantc: True... Just wondering if the email is still usable
<vagrantc>ah, not sure what list of mailing lists you're referring to...
<dongcarl>mbakke: Sent out an email with logs and stuff that should make things very clear. I'd love some feedback and feel free to ask me for more details!