<rekado_>I now know why berlin.guixsd.org only built 2% of the rhel6 branch: FTP downloads are currently blocked by the firewall, so libxml2 couldn’t be built, blocking all progress. <rekado_>opened a ticket with IT to unblock FTP. <vvedantham>When I try guix import pypi readline I get "guix/build/download.scm:296:6: X.509 certificate of 'pypi.python.org' could not be verified: insecure-algorithm signer-not-found invalid" I tried searching for the error online and it seems that my University proxy is changing something. I tried "pip install --trusted-host pypi.python.org readline" but that also did not succeed. Does anybody have any idea how to solve this? Thanks. <rekado_>vvedantham: you may need to install the nss-certs package and then set the following environment variables: <rekado_>export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs" <rekado_>export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" <rekado_>(see also the Guix manual in the section entitled “X.509 Certificates”) <civodul>divansantana: i think i already replied a couple of days ago ;-) <civodul>essentially, i'd suggest trying "mv ~/.config/guix/latest{,.bak} && guix pull" <divansantana>civodul: sorry my znc replay is not working too well. I missed it. Thanks! <Rukako>civodul: hi, is this a good time to pm you? ***Steap_ is now known as Steap
<thorwil>hi! i've build a custom kernel. used guix download to obtain a hash and for not having to fetch it twice. all that worked fine <thorwil>but now i can't find it in the store anymore <thorwil>shouldn't a `find -name "thisisthehash*"` in /gnu/store work? <Sleep_Walker>(I'm trying to override the list of modules (once again)) <Sleep_Walker>is 'rest' overriding my specification of '#:linux-modules'? <rekado_>I’m seeing lots of rebuilds on the rhel6 branch, despite only merging master into it. <rekado_>I lost count of the number of times I rebuilt qt and gcc. <rekado_>I’d like to have another graph layout that shows me bottlenecks, packages that are fundamental for many packages higher up. <rekado_>it would be great if we could split the matplotlib backends for gtk and qt into separate packages. <efraim>Especially since qt no longer depends on gtk <thorwil>what's wrong with (native-inputs `(("kconfig" ,(local-file "/etc/kernel.conf")) ,@(alist-delete "kconfig" (package-native-inputs linux-libre)))) <thorwil>that i get: config.scm:49:4: In procedure native-inputs: alist-delete: unbound variable <rekado_>“alist-delete” is not defined. You’re missing a use-modules clause. <thorwil>hmm, none of the examples here list anything that seems related; apparently it belongs to srfi-1 list library <thorwil>indeed (srfi srfi-1), which is absent from my examples <davexunit>civodul, rekado_: I'll be talking about guix at libreplanet this weekend. any recent developments that you think I should mention? <davexunit>it will be sort of a beginner's talk, but I'd like to cover some new ground as well <davexunit>the theme of the conference is "freedom embedded" so I'll be repeatedly demonstrating how guix enables the user to exercise software freedom. any cool tricks that reinforce that theme would work well. <wxie>System boot boot.catalog efi.img etc gnu mach_kernel mnt run var <wxie>Why I cannot boot it by using Libreboot? <wxie>EFI LEEME.TXT README.TXT casper dists isolinux md5sum.txt pool preseed <civodul>davexunit: really cool that you're going to talk about Guix! <civodul>i don't have any specific idea in mind <civodul>there'll be a talk by lamby about reproducible builds, so i guess it would make sense to show the connection <civodul>in that vein you could mention 'guix challenge', 'guix build --rounds', things like that <wxie>If the DVD is not booting, how could I install guixSD? <civodul>wxie: what is the error you're seeing exactly? <civodul>rekado_: didn't you have a separate hpcguix-web repo somewhere where you had integrated the if-modified-since change? <wxie>civodul: There is no error, but the BIOS menu does not change when pressing on boot from DVD option. <davexunit>civodul: yeah sure, that sounds good. thanks <wxie>civodul: If I use another PC without libreboot, my DVD boots. <civodul>davexunit: also you could mention that derivations do provenance tracking in a way similar to Debian's recent "buildinfo" format, but in a more accurate way :-) <civodul>wxie: so it might be a libreboot or configuration issue i'm afraid, probably not something GuixSD-specific <wxie>civodul: ok, I will ask libreboot people. Thanks. <efraim>davexunit: as far as embedded goes, creating a <efraim>GuixSD image for an arm board is pretty cool <demotri>I have in mind that there is a difference between github.com/pro/ject/archive/... and /release/... When packaging, the "release" should be prefered, as this is stable, where the "archive" could change slightly, leading to stability-problems with Hashsums. Is that right or have I made that up? Do we have any reference/mail-archive for that? <rekado_>demotri: if it’s just a tag with a tarball download link it’s best to avoid it. <mbakke>demotri: The "archive" tarballs are autogenerated from git tags, whereas releases are uploaded by project maintainers and often contains other preparations. <OrangeShark>davexunit: looking forward to attending your talk :) <demotri>rekado_/mbakke: Thanks. Is that written down anywhere? <mbakke>demotri: I suppose you'll have to read through GitHubs documentation. <OrangeShark>davexunit: yup, first time going to libreplanet, pretty excited. <demotri>mbakke: Yes, I searched for something like this bug. I knew I read it somewhere on the mailing lists, but was unable to find it through search engines. <soundtoxin>Okay. I was just surprised to not find it, but find similar games that I had not even heard of already packaged. <bavier`>soundtoxin: we would certainly welcome a patch if you'd like to package it :) <soundtoxin>I was worried I'd give such an impression. I have no experience with that sort of thing. I'm used to giving up when something isn't packaged on a distro. I've got my own little list of stuff that isn't packaged on guix get. <bavier`>soundtoxin: np, understood. Feel free to share your list when you're ready <soundtoxin>If you just mean say it here, this is it so far: deluge, ranger, polybar, tewi, i3lock, greenclip, nitrogen, openarena <soundtoxin>the i3lock situation is weird, there is i3lock-fancy and i3lock-color but not a normal i3lock that I could find. <rekado_>sahithi-ihtihas: you can run “guix hash” on the source code archive. <Cogitri>So I'm currently trying to upstream a few patches related to elogind, but I've received some doubts if elogind will update new functionality of logind in a timely fashion and won't keep releases of the respective software back. Does elogind have some guideline about that, or is it "just" "We'll work on it when we have time"? <civodul>Cogitri: i suppose the latter, but note that elogind is now maintained independently of Guix <efraim>I thought we had deluge, I'll have to take a look at that <efraim>I have a local patch for ranger, some of the tie-ins don't work correctly yet though <nckx>soundtoxin: There was a guix-* list post about the i3lock(s), but I fail at finding it. <civodul>rekado_: do you have tips to make NFS caching more efficient for the store? <civodul>stat(2) is quite expensive, so package lookups are slow <thorwil>does the guixsd default kernel configuration conatin anything special to avoid a dependency on python? <nckx>thorwil: No. Which dependency on Python? <mbakke>How can we convince Paul to Make a release? :P <thorwil>nckx: patch-shebang: ./Documentation/sphinx/kernel_include.py: warning: no binary for interpreter `python3' found in $PATH <mbakke>thorwil: That file is only used for building the documentation, which we don't. <thorwil>mbakke: i can't find a trace of any build-documentation flag in my kernel-config <thorwil>it happens after "phase `configure' succeeded after 4.0 seconds" <thorwil>starting phase `patch-generated-file-shebangs' <thorwil>but actually, those are all just warnings. <thorwil>phase build fails with: Makefile:933: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop. <mbakke>thorwil: I suspect adding libelf to the inputs of your kernel package will solve that. <ng0>soundtoxin: the i3lock situation is weird, there is i3lock-fancy and i3lock-color but not a normal i3lock that I could find. that is because I never bothered to package the normal i3lock. <ng0>if you want the normal one, you need to package it. it should be very straight forward, as -color is just i3lock with some additions on top <efraim>mbakke: looking at the aarch64 glibc patch you showed me, it looks like it is also applied after the 2.27 release <mbakke>I have rounded up all post-release patches for 2.27 in a 12k lines megapatch :/ <mbakke>Still struggling with getting "make" to build though; but I think I've figured it out now. <mbakke>But have to build Guile every time I change "make", so test cycles take a while. <thorwil>is this the right approach to add inputs? (inputs `(("libelf" ,libelf) ,@(package-inputs linux-libre))) <soundtoxin>ng0: I guess I'll just install i3lock-color and give it a go then. I've been using xlock for the past few months. <ng0>question: is mesa + glu (the packages) not enough for "libGL" to exist? It was just pointed out to me that my xonotic package can't start in OpenGL mode <ng0>there's a bunch of x11 packages I added in addition to that. <ng0>I can try wrapping it in though, but normally glu == libgl, no? <ng0>then I'll try wrapping <davexunit>libgl alone isn't enough for graphics because it needs to use some sort of GPU driver, etc. <ng0>well the binaries already wrap curl in as this was the only way to get network working for it <ng0>I can paste a crash log <swiftgeek>when is guixsd going to start using squashfs ? <ng0>ACTION starts searching for the new new source <thorwil>kernel build failed after like half an hour with: module not found "uas.ko". what's the job of that module? search hits suggest it has to do with usb/storage <ng0>if that's the same as before. will send patches if I find anything new <ng0>if not we have to switch to git <shoaloak>Hello, im trying to install GuixSD on a laptop but i've run into an error. <thorwil>shoaloak: something to do with a SYSTEM_DRV partition, it seems <nckx>shoaloak: a wild guess appears: is /gnu/store/2m4kj0py6dcsm33r4h0wgmm7cqc9fhqi-nano-2.9.1/share/locale/es a file? <thorwil>argh 'module not found "hid-apple.ko"'. if guix somehow expects a bunch of modules to exist, where can i find a list of them? <nckx>thorwil: gnu/system/linux-initrd.scm: "usbhid" "hid-generic" "hid-apple" ;keyboards during early boot <nckx>thorwil: Which isn't to say that couldn't be handled far more elegantly, for sure. <thorwil>i may know only a small collection of hammers, but i do have to get better at putting those to work on anything that could be vaguely nail-like ;) <nckx>When people say ‘Unix philosophy’ what they really mean is ‘hammers duck-taped together to make bigger hammers’ so you're bound for greatness. <mbakke>efraim: Does changing to 'target-arm32' change the derivation? <nckx>shoaloak: Unless you're talking about something else now, ‘file’ would be overkill anyway. <mbakke>If it does, it will have to wait until the next cycle to prevent a large armhf rebuild. <nckx>shoaloak: what does ‘stat -c %F /gnu/store/2m4kj0py6dcsm33r4h0wgmm7cqc9fhqi-nano-2.9.1/share/locale/es’ say? <nckx>shoaloak: as I suspected :-) <mbakke>efraim: Also, the patchelf changes must wait until the next cycle since staging is nearly fully built. <shoaloak>nckx: nice, but how to continue from here? ***fkz is now known as Guest34721
<nckx>shoaloak: So I think the problem is that Guix is trying to merge the different /share/locale/es directories into your profile, but nano's /share/locale/es is a regular file, not a directory. <mbakke>PatchELF has 1111 dependents now. <nckx>shoaloak: Give me a moment... <mbakke>civodul: Yes, thanks to meson-build-system. <mbakke>We really need to swap it for something more Schemey :) <nckx>shoaloak: stat -c %F /gnu/store/knmz2za07lm1jfx4jmrjv5k9x8kbaa04-nano-2.9.4/share/locale/es → directory, so it's no longer a problem in master. <nckx>shoaloak: nano 2.9.1 is pretty old, can/did you not ‘guix pull’ before installing? <nckx>ACTION has to leave in 1 minute :-/ <mbakke>I'm going to look into making (guix build gremlins) able to detect unneeded RUNPATH entries when I become a Scheme pro. <mbakke>Right now I struggle with a simple macro for (with-build-pythonpath ...) in python-build-system :P <shoaloak>this is my first time using/installing guix <shoaloak>nckx: i take it that 'guix system init /mnt/etc/config.scm /mnt' doesn't do this autmatically then <nckx>shoaloak: This should be mentioned in the manual (you'll need ‘cow-store’ too, did you not encounter that?). <nckx>shoaloak: No, it uses whichever Guix you have, which in your case is probably the last release, which is not too fresh. <shoaloak>nckx: i did run 'herd start cow-store /mnt' <nckx>OK, then ‘guix pull’ should work. :-) <nckx>(It would run out of RAM otherwise.) <nckx>ACTION really has to go now, sorry. Good luck. <efraim>mbakke: it shouldn't change the derivation <nckx>TBH I think it is, but patches welcome otherwis. <mbakke>efraim: OK, we can keep that commit then, if you're certain :) <nckx>shoaloak: My lift is late, so here I am again :-) I checked the manual and you're right, it doesn't recommend guix pull. Probably because it broke someone's system once (or twice, or...). <nckx>shoaloak: I'd give it a try and with some luck, it won't compile for days and might even solve your problem. <civodul>mbakke: yup, that's on my to-do list and it has the potential to be fun <civodul>and "fun" as well, if you see what i mean :-) <castilma>hey, is there any effort in enabling ccache for the build-daemon? or are there reasons why you would not want that? <mbakke>civodul: I'm sure we'll learn a lot about the linker ;-) <mbakke>nckx: I think the main reason guix pull is discouraged is that there may be inconsistencies with the manual, e.g. bootloader syntax. <civodul>castilma: the store is already a cache, though maybe coarser-grain than what you'd like <mbakke>Also, we do keep substitutes for releases for a long time, whereas master may not have substitutes for everything. <nckx>mbakke: I'm aware. I just thought it was in the manual, but I guess I was dreaming. <nckx>Anyway, I wonder which release shoaloak is using since — at a glance — that configuration looked pretty stock and the mode of breakage is pretty... bad. <castilma>civodul: AFAIU, it doesn't address the issue ccache does. ccache caches compilation units (right name?), /gnu/store caches whole builds. if you built foo-1.0.0, building foo-1.0.1 would take less time using ccache. /gnu/store wouldn't help there in that sense. <civodul>castilma: right, that's why i said it's coarse-grain <civodul>so in a sense they're similar, but in practice you're right that ccache operates at a lower level and could be more beneficial in some cases <nckx>ACTION tries to leave the house, attempt #2. o/ <civodul>however, using ccache can introduced undesired side-effects, even if it's not supposed to, so we don't use it <castilma>mbakke: I think you side-stepped my point. I want to reduce build time, and you offered me to use substitutes. I do, but I want to reduce build time on the substitutes, too. <mbakke>castilma: Sorry, the substitutes thing was about running `guix pull` from the installation medium. <bavier`>castilma: at one point I had explored introducing ccache support into the daemon <mbakke>That said, I suspect ccache has the potential to introduce nondeterminism. <bavier`>my idea at the time was to introduce a new build-time option that wouldn't inject ccache into the buid chroot <castilma>civodul: what kind of side-effects are there? <mbakke>I used it for years on Gentoo without problems, but still sceptical about Guix use. Gentoo isn't known for their reproducibility efforts. <castilma>mbakke: that's my only idea about side-effects. but those are always bugs in the implementation, right? caching by itself can not produce nondeterminism; is my understanding correct? so one should be able to live with it as opt-in, as all software has bugs? <mbakke>I don't know enough about ccache internals to comment on that, unfortunately :) <castilma>bavier`: you looked into it. what was your conclusion? why didn't you do it? (or did you?) <bavier`>castilma: I didn't end up implementing anything, because of time and current efforts to rewrite the daemon in scheme. it would be doable imo <bavier`>it would at least be interesting to run a daemon running --with-ccache and 'guix challenge' it with hydra over time <ng0>civodul, rekado_ , is it okay if I CC you wrt something Whonix plans on writing a Debian community proposal for exception of Guix and Nix? So far it was okay for me, but writing up something on behalf of the project (or helping to) in this would be more like maintainers work. I'll fill you in the details when Whonix agrees to switch to Email. <castilma>bavier`: (second post:) exactly my thoughts. (first post:) wouldn't it be pretty simple to implement? replace the compiler with symlinks to ccache? <civodul>ng0: this is lacking a bit of context, but in general, i have nothing against receiving email :-) <lfam>efraim, mbakke: On staging, "ERROR: In procedure %resolve-variable: Unbound variable: target-arm32?". Any idea which compiled objects need to be rebuilt? <civodul>ng0: getting Guix in Debian is something i'd really want to see happen, but that requires work (social work in particular) <ng0>civodul: yeah, sorry. it spans quiet a lot of time. goes back to the time when bancfc asked about Guix for Whonix. I'll give you the summary in Email + their bugtracker link <ng0>it's about the social work ;) -> Debian community vote <civodul>well that would be the very last step <civodul>there's a lot to be done before that if we want it to succeed <civodul>dustyweb spent a bit of time thinking about this, so we might want to share <bavier`>castilma: as far as implementation, I'm not sure, we'd have to see how package's react <ng0>point is though, Whonix is Debian connected and trying to get forward with this. Looks better than us asking for it directly. <dustyweb> - Debian and Guix should be best friends: what's good for one is good for the other (or especially: what's possible to package in one is generally possible in the other) <dustyweb> - the biggest threat Debian and Guix face is the "giving up" direction of packaging things caused by non-composable language package managers which often are not focused on reproducibility <vagrantc>i'd be very interested in getting guix into debian! <vagrantc>though it is a particularly unusual package ... <dustyweb> - a number of us are happy-ish with GuixSD :) but Debian provides something that Guix doesn't have, which is long term support and stability, a lot of packages that aren't *yet* in Guix, and honestly an amazing community with a more advanced governance model than we have (Guix hasn't needed Debian's level of governance complexity... some day we might!) <dustyweb> - Guix provides something Debian doesn't have: "guix environment". If Debian folks encouraged people to use Guix for local development, we'd end up with more packages that could be packaged in both Guix and Debian <dustyweb> - so chocolate and peanut butter, right? :) <dustyweb> - except: it isn't possible, currently, to "apt-get install guix" in Debian. detrout made some progress: <dustyweb> - Guix likes /gnu/ and doesn't want to give it up, it's the complement to /nix/, it's a cute name, and it's hard to do something that isn't three characters anyway because of linux restrictions on path limit length iirc <dustyweb> - Debian doesn't want anything that's not in the FHS, and /gnu/ is not in the FHS <lfam>shebang lengths are limited by linux <dustyweb> - this is absurd, we're giving up a glorious future together over /gnu/ ? Well, what can we do <dustyweb> - Debian could give in: make an exception for the FHS. It's in Debian's best interest if "guix environment" could result in more debian-friendly packages <dustyweb> - Debian folks could completely recompile /gnu/ at their own location, maybe at /opt/ ... lots of cpu resources wasted and I'm not sure you'll find anyone excited enough to do it <mbakke>In theory, Debian could use "/var/gnu" and provide their own substitutes. <dustyweb> - we could rewrite all our binary paths a-la grafts :) <mbakke>I'm sure Debian would like to have their own build server anyway. <dustyweb>mbakke: assuming you can find anyone dedicated enough... Debian is already low enough on resources for their own work... <dustyweb> - Guix could switch from /gnu/ to /opt/ <lfam>Grafts are not reliable enough in practice <dustyweb>*everyone in #guix throws me out of the channel!* <vagrantc>if it switched to /opt it would be perfectly compliant with FHS, i suspect <ng0>mutiny! how dare you! <vagrantc>why not /opt/guix instead of /gnu/store ? <dustyweb>though if a time were ever to consider that <dustyweb> - here's the easiest one: Guix can at least ship its own Debian packages as part of its release <dustyweb>however, that doesn't make "apt-get install guix" happen <vagrantc>debian provides a mechanism for trust-paths to external repositories <lfam>Honestly, does anyone want to deal with Debian's packaging of Guix? Already the distro packages from smaller distros brings lots of problems <ng0>I don't know if we should run our own apt. <civodul>lfam: if it's one that we produce with 'guix pack', say, that could be fine <dustyweb>lfam: it's leaving a huge userbase on the table to not do it <dustyweb>and it's losing the potential of Debian and Guix teaming up to try to prevent a packagepocalypse <lfam>Personally I don't think Debian is the organization that will lead the future of free software distribution <ng0>apt.guixsd.org is a last solution I guess.. we'd need people to maintain it <lfam>It might not be us, either <ng0>but Debian has a large user base. <dustyweb>but we can try to best assess where we can collaborate and try to make a path forward <vagrantc>and you've got more than a couple debian developers excited about guix <civodul>+1, and i agree that Debian and Guix share values and all <ng0>it might not be the future, but it has a user base. even if just a small number of them will use Guix, it's a good combination <lfam>I think it's worth it to make Guix easier to package, but I think it would be better to focus first on Fedora <usrn09701>hi, can you run guixsd live from usb memory stick? <dustyweb>lfam: maybe, there's no reason we can't also get ourselves in Fedora <lfam>That would bring compatibility with CentOS and RHEL, right? <dustyweb>I think Debian is maybe more important in the long run because their community is more closely aligned imo <buenouanq>usrn09701: yes, that's basically just what the installation image is <dustyweb>in terms of FOSS (semi-)strictness and also a position against bundling <vagrantc>well, if there's any way i can help with getting some form of guix into debian, let me know. i've got upload rights :) <dustyweb>iirc Fedora has weakened its position a lot lately <mbakke>usrn09701: Yes, the installation image works on USB sticks and CD-ROM. <ng0>usrn09701: but you don't get a grpahical desktop. it's like Gentoo install-disk <vagrantc>but i also don't want to bite off more than i could chew <lfam>After a few years involvement in Guix, I think that long-term focused support is critical for success. The RHEL world is nice because there are resources to pay that <mbakke>Nng0 , usrn09701 It's possible to make any GuixSD configuration run from a USB stick. <dustyweb>is that I haven't had success in making this case to Debian folks <buenouanq>be it know that I am in the anti standard hierachry camp <dustyweb>tbh I think some Debian folks I know are a bit frustrated hearing this, it sounds like "let Guix overtake Debian". and yet it's ok to package Docker... <usrn09701>mbakke, im looking for something like linux mint/ubuntu/ to try live without having to install <dustyweb>and npm and python's packaging tools and gems <ng0>ah. well we don't offer that out of the box currently, usrn09701 <dustyweb>buenouanq: let's please not get into that <ng0>you'd have to assemble it yourself <dustyweb>systemd is the godwin's law of free software <mbakke>usrn09701: Ah right, we don't provide pre-made graphical live environments right now. But you can install Guix on any distribution and make it yourself. <usrn09701>is there any plan to make pre-made live enviroments? <lfam>usrn09701: What sort of live environment do you require? <dustyweb>civodul: you summoned me, hope you're happy with the braindump ;) <lfam>Thanks dustyweb, it's great food for thought <ng0>dustyweb: thanks! I pointed it out in the WHonix bug ticket <lfam>I wish we could all get together more often to discuss this in person <civodul>it generated more feedback than i thought :-) <dustyweb>yes and too bad that I couldn't make this year's FOSDEM, whah <dustyweb>there was just too much going on in my life <lfam>dustyweb: Next year, let's charter a plane together ;) <mbakke>If only there was a free software conference we could go to. <civodul>dustyweb: if you're at LP with davexunit, let's chat with lamby and vagrantc and whoever from Debian is around :-) <ng0>2018, year of the linux planet <civodul>dustyweb: also, i'm very interested in the Racket-for-the-people thing <dustyweb>civodul: we just ran a workshop here in Madison this last saturday <civodul>i'd prefer Guile, but it's true that Racket has so many goodies we don't have (yet) <dustyweb> - 7/8 of participants were women... and we didn't even mention gender on the flier! Instead, we made a call-out to people who wanted to program but felt like they were excluded by being not part of that field <dustyweb> - 100% of the participants made it through the "make a snowman with the picture language" tutorial, and 100% made it through the "publishing with scribble" tutorial <dustyweb>CompanionCube: their development tools recently switched to using some npm-based libraries <dustyweb>so now they're going to require some tools that are packaged through npm <dustyweb>this is going to be a real problem for icecat I fear <lfam>IMO we can't not have a firefox <shoaloak>got a little further during my install :) <shoaloak>grub-efi doesn't seem to be installing properly <ng0>recently doesn't mean 55, and doesn#t mean immediate 60, but afterwards <ng0>so there's still some versions time for the npm <ng0>I'm halfway through with getting 55+ to build I hope <ng0>where their mandatory rust is the problem :) <mbakke>shoaloak: Where did you mount the EFI system partition? <ng0>I think icecat is catching up there at least <mbakke>There was a recent change that made it so it had to be mounted at /boot/efi instead of /mnt/boot/efi, methinks. <mbakke>Though we should fix that, it's kind of awkward to have to mount it under the host /boot. <shoaloak>and yes, one would expect to mount ESP on /mnt/boot/efi instead of /boot/efi... <mbakke>shoaloak: Glad it worked. Can you file a bug report about it? :) <mbakke>shoaloak: Excellent. Email bug-guix@gnu.org :) <mbakke>shoaloak: Guix does not have systemd. <mbakke>And I doubt anyone is working on packaging it :) <ng0>the Gnome here works without systemd <shoaloak>still unsure which side to pick in the new emacs/vi wars... systemd/other init <ng0>you'd use the gnome-desktop-service instead of just installing it <mbakke>I'm sure you'll like The Shepherd :) <ng0>there's no "war".. just people bringing it up again every time and getting upset over nothing <mbakke>It's like systemd, except <1000 LoC. <mbakke>Less than 1000 lines of code. IIRC. <lfam>mbakke: I'm having trouble with `guix system reconfigure ...` on staging since the arm32 changes <lfam>I think that target-arm32 is used without being declared <ng0>well.... 3891 lines of code including build system stuff <mbakke>lfam: I suspect meson-build-system needs (guix utils), though I fear that might change the derivations. <ng0>so it's a bit more than 1000 ;) <mbakke>I think efraim is working on it, though. <ng0>soundtoxin: I might do a package for i3lock next month, should be done in less than 30 minutes. <mbakke>The Shepherd also does not do DNS resolution, login management, network time synchronization, kernel device management or clean dishes, but that's OK. <civodul>mbakke: re target-arm32, it's ok for (guix build-system meson) to include (guix utils) <lfam>I'm going to try this now <bavier`>civodul: commit bc499b113 broke guix build on guile@2.0.14, should I submit a bug report? <mbakke>Ooh, looks like someone beat me to restarting the aborted jobs. <shoaloak>mbakke: damn, could've used a dishwasher <mbakke>lfam: We'll need to revert the PatchELF changes before it can be merged, though. Since PatchELF now has 1111 dependents. <lfam>(guix build-system meson) already imports (guix utils) <shoaloak>just add some magic to the /etc/config.scm file <mbakke>shoaloak: If you use %desktop-services, adding i3-wm to the (packages ...) list should make it show in the SLiM menu. <mbakke>And reconfigure would take care of the rest. <mbakke>SLiM is the default display manager in Guix. You can also use SDDM, but you'd have to override %desktop-services in that case. <mbakke>lfam: I don't get any errors when running reconfigure on staging. <lfam>mbakke: Yeah, I think it was just an ABI break. It went away for me too after `make clean-go` <mbakke>builder for `/gnu/store/8frxszr6dypsvq9vlx1cnr1slg8vr145-json-glib-1.4.2.drv' failed with exit code 1 <lfam>Ah, I guess it will come later in my interminable reconfigure process :) <lfam>Yeah, that's the one I saw before <civodul>sneek: later tell bavier re "commit bc499b113 broke guix build on guile@2.0.14", please submit a bug report, yes :-) <shoaloak>I must replace %base-services with desktop-services? <lfam>shoaloak: Yes, that's right <mbakke>shoaloak: Using %desktop-services will add a display manager, elogind, and other things you generally want on a desktop system. <mbakke>lfam: It looks like that code is is part of the derivation of meson-build-system users. <shoaloak>i see in the beginning of the config file <mbakke>Specifically /gnu/store/fynzigzqz5lr0dq6z213akz4y00vbd2z-json-glib-1.4.2-guile-builder <mbakke>So I guess we'll have to revert it. <shoaloak>i see (use-modules (gnu (gnu system nss)) <shoaloak>what are these last 3 parameters for then?