<nckx_>Well, the reason it's currently like this is because it's easy to write services this way. Fixing it would have to improve the overall logic, not just tweak a line. I don't think I'll volunteer, but if you'd be willing to file a bug so it's at least public, I'd be much obliged.
<nckx_>(Genius: 'I won't do X, but I'll ask you to do Y' as if it's some kind of compromise on my part.)
<Cairn>And I was all but convinced you were making a reasonable compromise instead of giving me all the work! ;)
<nckx_>Of course: you are also welcome to go ahead and fix it, if you like.
<Cairn>I'll do my best to submit a bug. I'm a million years from being able to fix it though
<nckx_>If you insist on doing work we are powerless to stop you.
<nckx_>superkamiguru: You're not interrupting. On-topic questions are always welcome. Don't think I can be of help, though. Guix provides some helpers to run Guix System services *in* containers, but that seems to be the inverse of what you want.
<nckx_>I get typing notifications for fellow Web chat users. Weird. I no like.
<nckx_>Cairn: 'Geiser' gets mentioned a lot, but I don't use it.
<nckx_>Docstrings aren't as common as they should be in Guix.
<superkamiguru>Ok, no problem at all. I am currently trying to create a simple service that extends shepherd-root-service type, and then run the command to start the container with make-system-constructor.
<Cairn>Thanks for the Geiser recommendation nckx_! I'll probably set it after I read further into the manual.
<jts>hey y'all. how do you get the number of cores passed to guix build inside a package definition? i need build artifacts from a different package for a package i'm packaging and would like to use more than just one core for getting them
<bdju>I vaguely recall it being discussed here or on the mailing list in the last few months, so I thought it was fixed. I haven't rebooted in a long time, so maybe that could be why it's still saying 0
<bdju>so it's said that for a while, I haven't made any crazy changes to my setup. and I'm on guix system
<ekaitz>I can just help with packaging and a couple of things more
<ekaitz>now I think about it... didn't I already joined for the boostrapping part?
<ncbfg36>how would I go about forcing a kernel module to load on guix system? It looks like thinkpad_acpi doesn't load on coreboot systems unless forced and the only instructions I can find to do so involve /etc/modprobe.d on other linux systems. Running 'modprobe -f thinkpad_acpi' returns "Exec format error"
<ncbfg36>I'm looking at kernel-module-loader-service-type in the docs but it's not entirely clear to me how to specify options such as force_load=1
<civodul>rekado: yeah, i wonder what we could do to address that
<civodul>we've invited committers to talk about why they wouldn't review/apply stuff but haven't gotten much feedback
<civodul>perhaps we should make a few tasks mandatory, similar to how oss-security handles that?
<civodul>(i'm not a fan of this obviously, but if that's what it takes...)
<civodul>ekaitz: could be! i guess the main point is being able to guide people to get their package patches in shape for inclusion
<civodul>that requires familiarity with the patch submission guidelines, but that's really nothing difficult
<ekaitz>civodul: I'm not sure I'm the best for the job, my patches always get fixed by you but anyway, you can't count me in
<drakonis>civodul: the patch workflow pipeline could use some touching up
<civodul>ekaitz: heh, thanks for volunteering! :-)
<ekaitz>civodul: my only purpose in life is to be useful
<rekado>ekaitz: the idea behind the mentor team is really just that there is a committment by the team members to coordinate patch review for newcomers.
<rekado>we don’t want to have reviewers step on each other’s toes, but we also don’t want new contributors to be discouraged
<ncbfg36>oh I figured it out. I was just confused about setting kernel arguments
<rekado>so we need a few things: the means to identify/list submissions by new contributors, and a few people who will priorize these submissions and coordinate to a) respond to the submitter quickly and b) shepherd their patch to completion (this may include dismissing it).
<ekaitz>rekado: so it's not that some of the patches will arrive to my inbox and I'd be in charge of them
<rekado>ekaitz: this can be done by making mumi send notifications
<ekaitz>rekado: that would be cool, send notifications in a round-robin or something like that to people in the mentoring team so they don't have to dig in every patch to see if requires attention or not
<rekado>I’m playing with “guix system container”; when I use “--network” I see that the container gets the same IP as the host. Is this expected? Can I give it another IP?
<apteryx>would there be an elegant way to provide an environment variable to the lightdm login greeter? It doesn't carry its parent (lightdm) environment variables, rather it seems its env is initialized anew from /etc/environment (PAM) and perhaps /etc/profile
<apteryx>the environment variable is only of use to itself (to find its configuration file)
<apteryx>the alternative is to hack the lightdm-gtk-greeter package to look its default config file at /etc/lightdm/gtk-greeter.conf
<apteryx>(and have our service extend etc-service-type)
<rekado>to answer my own question: I guess cni-plugins could be used to change how the network between host and container is configured.
<civodul>rekado: yeah, or we could use guile-netlink to set up bridge interfaces
<apteryx>should /etc/profile extend rather than set XDG_CONFIG_DIRS and XDG_DATA_DIRS? that seems too niche
<civodul>apteryx: presumably these are necessarily unset by the time /etc/profile is sourced, no?
<abrenon>I'm trying to understand stuff in opam's import (again), and I'm confused about where actual parsing of the opam file inside the imported repo happens
<abrenon>get-metadata (l. 211) sounds like a good candidate but I don't understand the ,@( from its calling site
<apteryx>unmatched-paren: for the reasons autoconf exists :-) you'll always have forgotten some edge case or a switch, or introduced something incompatible with what is expected, and people will complain about it
<abrenon>so passing make flags with the output prefix is preferred ?
<ekaitz>it should only build for the GBA and not for the current arch...
<muradm>ekaitz: i suppose you have to dig into supported-systems then
<unmatched-paren>problem is, supported-systems probably only supports specifying systems that Guix itself supports
<acrow>getting guix-import-debian is a side project brought about to write a package for mkcue -- which is demanded by, already in guix, abcde. The problem is that the only source for mkcue I've found and got free access to is in debian. I am not currently running debian (another long story). So, guix-import-debian seems useful to me.
<muradm>ekaitz: build system is tools around build tools, like gnu-build-system is around autoconf/make, cargo-build-system around cargo, but in theory well equiped build tool is already capable of building for multiple targets.
<ekaitz>muradm: but how can I force a package only build for arm-whatever using the toolchain I choose?
<Lumine>I've been on exwm now since last christmas, works well, slight oddities but I'll figure them out one day
<acrow>muradm: did exwm cause problems? or did guix just provide many, many other opportunities to explore?
<muradm>unmatched-paren: while i understand why people desire "nix/guix home".. i am a bit against it.. and prefer to build my workflow in the way that, after the point OS logs me in and sources my .bashrc, it is my world now.
<atka>muradm: are you saying you don't use guix home?
<unmatched-paren>i think it would drive off a lot of users (including me, probably :D)
<Lumine>But yeah, was wondering the services comment earlier, because I was sure I had services enabled in home :)
<unmatched-paren>I just realized how meaningless my use of $THING would look to an average person. Funny how these things get embedded so deep in your brain :)
<Lumine>I'm excited about tomorrow morning, Guix is coming home, on my desktop :)
<klm1>hi guys! new user here. how can I remove the kdeconnect dependency of i3status-rust? It's very big. I tried (modify-inputs ... (delete "kdeconnect")), but it fails with `wrong-type-arg "string-append" "Wrong type (expecting ~A): ~S" ("string" #f) (#f)`, presumably because of
<acrow>unmatched-paren: I thought that the guix-import-debian python package was going to make it easy but, after some fixes and figuring, my target package .dsc file did not point to a source (homepage). Of course, it is in debian at source.debian.org but I'm not sure how to retrieve it without wget. I think there must be an easier way.