<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?
<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.
<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...
<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.
<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
<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>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.
<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"