***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>also is there any chance of iceWM package? <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 <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... ***jonsger1 is now known as jonsger
<civodul>hmm diffoscope fails to build on master <vagrantc>civodul: i've had inconsistant test failures after i pushed :/ <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 <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>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 <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" <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 <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 <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>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? <dutchie>i don't think i ever managed to reproduce it after the initial failure <civodul>aaah, so problem solved, dutchie? :-) <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>in the guix-daemon.service that we ship now, the locale is fixed <civodul>and it doesn't have any downside since you can always run the 'guix' command itself under your favorite locale <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 <dutchie>if i logged in as root more often i'd bother to fix it <dattashantih3>Does anyone know how to get guix pull to work behind an http/https proxy? <roptat>I think it honors http_proxy variables <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` <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? <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 <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 <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? <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) <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. <htsr>vup: i should only use the crontab, not mcron gexps :/ <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>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
<janneke>civodul: nice...and pretty silly/obvious once you see it :) ***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 😉) <nckx>Oh, there's nothing to load. Well, that answers my quesh. <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>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 kernel.org 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. <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>The problem is that we need `/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include` at the end of this list <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>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 <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 <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 :-) <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>Don't see it in the list of mailing lists anymore <dongcarl>reepca: Beware of the `CROSS_` environment variables though, they need to be set correctly <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!