<Exagone313>Is there any project using Guix on another kernel than Linux btw? <pkill9>not that I'm aware of, though you can replace the kernel if you want, although I found the Linux kernel (not linux-libre) to give me some issues <pkill9>bavier`: no it runs on linux-libre <pkill9>though they want to run GuixSD on the Hurd to make it the first independent 'Gnu' system <bavier`>pkill9: sorry, *can* run on the Hurd <bavier`>about as well as anything runs on the Hurd afaik <pkill9>the Hurd looks interesting from what i read of it, i hear Stallman said it has fundamental design flaws but idk what they are <bavier`>I don't recall hearing about "flaws". if anything "design decision that are more difficult to implement" <pkill9>bavier`: oh it might have been this line: "The GNU Hurd is not suitable for production use, and we don't know if it ever will be. The capability-based design has problems that result directly from the flexibility of the design, and it is not clear whether solutions exist." - https://www.gnu.org/gnu/thegnuproject.en.html <bavier`>pkill9: fwiw, there are blog posts and at least one video iirc about guix-on-hurd status on the website <Exagone313>I might not have the same init available to each kernel (didn't look into that yet, not sure how monolithic some projects are), there isn't any problem related to Guix itself right? I'll need to be able to install particular files depending to the environment (kernel, init-like...) I have I guess, is that possible with Guix? <Exagone313>or would it need different package version? or worse, a different repository per environment? <rekado_>Exagone313: what I wrote is unrelated to containers and also unrelated to installing packages in separate directories. <pkill9>are you talking about bedrock linux? <rekado_>Exagone313: you can install anything as a separate package in Guix. <rekado_>Exagone313: but to actually boot a system you’ll have to tie them all together. <rekado_>Exagone313: the repository and its organisation is unrelated to how the system is booted. <rekado_>I recommend watching Ludo’s FOSDEM talks about GuixSD (“your system is a Scheme library”) to understand this better. <vagrantc>Exagone313: i would think guix would be easier than many of your use-cases, as you basically just build all the software and then can pick and choose exactly which pieces you're using for a given system configuration <Exagone313>I'll read more docs, try GuixSD, and I'll be back for when I start making my OS, when I'll know the docs. Thanks for your help, now I might really use Guix. <buenouanq>If you're anything like a lot of us, you might just find that GuixSD is exactly and everything you've ever wanted~ <vagrantc>ACTION finds guixsd lacks only two things 1) a "stable" branch and 2) an integrated system for verifying the git tree <vagrantc>the "stable" branch is just a matter of having a community large enough to support that, i suspect <jorgesumle>`guix system init /mnt/etc/config.scm /mnt` gives a 134 error and outputs 'Aborted' <jorgesumle>It's a problem because of a previous incomplete installation <chewzerita>How do I test-build a package with guix? When I rust `./pre-inst-env guix build leiningen` it says package not found. <chewzerita>oh wait, for some reason it wants to work now?!!!??!?! <atw>chewzerita: is leiningen a package? Was there a patch I missed? <atw>chewzerita: thank you! I'm super excited to use that <chewzerita>atw: clojure development on guixsd is basically nonexistent at the moment, so I wanted to fix that <chewzerita>For anyone reading the logs: the reason it cannot find the package is because the package definition had some sort of error (probably only effects syntax errors) in it, and just silently fails. Double check to make sure everything is correct! <darkpsi>thomassgn: had a play around with the package going to see if i can sort the issue out thanks for your work <efraim>Wow the debian e team finally updated from 0.17.6 to 0.22.1 <efraim>I still have some bits to fix before my enlightenment desktop service is ready <civodul>rekado: i'm thinking of creating a guix-blog@gnu.org alias (or mailing list?) so that people can review blog posts, WDYT? <efraim>I tested cross building bootstrap-tarballs on core-updates, aarch64-linux -> powerpc-linux, and it built successfully <Rukako>I got accepted to the guix gsoc! :3 <civodul>efraim: that sounds fun, it's always surprising when this kind of thing actually works ;-) <efraim>civodul: well now I have two iBook G4s and I have stuff to upgrade one to 1.5GB of RAM and an SSD <darkpsi>how do a make a package definition that uses a .tar on disk? <civodul>darkpsi: you could write (package (source (local-file ".../thing.tar")) ...) <efraim>slim pickings for OS options, looks like debian oldstable, gentoo, one of the BSDs or porting guix <efraim>i'm still waiting for my dad to upgrade from his so I can take it <darkpsi>i need to install libreboot or somthing on it so i can use a freesoftware approved card <efraim>i downloaded a hacked bios from a shady site so I could replace the wifi card <darkpsi>yeah i think with the x220 you need to use a external eeprom writer it is a real pain unless it has improved since i have last looked at it <efraim>i think that's the case for all initial libreboot flashes, mine was years ago so I don't remember what I did <Rukako>darkpsi: as far as I know you can't use libreboot on x220 because it uses a modern intel processor <Rukako>coreboot works though if you want a semi-free experience, please correct me if I am wrong <efraim>Rukako: which project are you working on for GSoC? <Rukako>yeah, I am quite excited for it. I can't wait for the exams to finish so I can start on it <darkpsi>ah thanks for saving me from bricking my x220 when i finaly get round to flashing it <darkpsi>what year are you in Rukako if i may ask ? <Rukako>I will finish my second year, but I am in the UK so the next year will be my last <efraim>Hmm, I'm going to have to look into reproducably creating gpg keyrings <efraim>zybell_ rain1: not so much of a joke, I'm working a bit on creating a gpg keyring (not key!) of the dev keys from savannah <efraim>working toward auto-checking the commit(s) from `guix pull' <rain1>I wonder if the problem could be worked around by just having a static (reproducible) folder of keys and then make a keyring on the fly <rain1>although I'm kind of curious what nondeterminism is put into these keyring files. I had a look but i'm not sure.. maybe internals of the hash table? <zybell_>rain1:trust signatures are the main nondeterminism. <zybell_>Because its the *reason* gpg exists. <efraim>This is just importing the public keys <efraim>I already have a folder of pre-downloaded keys <efraim>I can make sure I'm importing them in the same order each time <rain1>isn't that just about building the program reproducibly? <efraim>They have a bunch of public keys and mash them together to form their keyring <zybell_>debian doesnt use a key*ring* they use a key*package*. <efraim>Their key package creates several keyrings <zybell_>creates several key*files* that are imported into the keyring at appropriate times, and (I suspect)deleted after use. <zybell_>the whole aspect of *maintenance* is off ***odi_ is now known as odi
<ranger>Hello, after installing GuixSD, I booted into Gentoo on the same machine to install grub. But now Guix does not show up. What do? <wxie>ranger: What does it boot before installing grub? <ranger>wxie: pardon? I do not understand your question. Maybe my question needs a clarification? <efraim>I assume they used Gentoo's grub to reinstall grub and guixsd didn't show up <jlicht>wow, I actually got the Android stuff to work with some minor tweaks. Amazing :D <efraim>Now I suppose we should look up the gnu triplet for android <efraim>For the curious, looks like its $(arch)-linux-android <pkill9>jlicht: have you run any software form guix on android? <jlicht>pkill9: I'm currenly doing a `guix pull', but it is not going fast as I seem to be getting a lot of "ERROR: In procedure getaddrinfo: Temporary failure in name resolution" errors <jlicht>So I have to `guix download' the failing downloads manually <jlicht>pkill9: it is building glibc and binutils right now :) <civodul>jlicht: so you have Guix on your phone? :-) <civodul>the DNS errors may be because of a lack of /etc/resolv.conf <jlicht>civodul: Technically, I do, at least untill the next reboot. I'm looking into re-packing my boot.img to automatically mount the stuff that needs to be mounted in the initramfs <jlicht>civodul: I actually do have /etc/resolv.conf (I copied it from my laptop connected to the same network, so I guess it should work). <civodul>i suppose it's ok not to have /etc/nsswitch.conf at all <civodul>roptat: BTW, i was browsing guix.fr.info, and really: kudos on that! <civodul>it's impressive and heartening to see all the work you already put into it <civodul>only partly translated, but already quite a bit of work <jlicht>Though my name is Frisian, I only know how to say `good morning' ;-) <jlicht>bah, some tests in findutils are failing on my android :/ <roptat>jlicht: you need to set the temporary directory to /tmp <roptat>I don't have /etc/nsswitch.conf on my phone <pkill9>roptat: does it only need to be in /tmp during the build process? <pkill9>and i would have thought that would be handled by the build system <civodul>roptat: the manual is not on the Translation Project, right? <roptat>pkill9: run TMPDIR=/tmp guix-daemon … <civodul>should we put it there or somewhere else? <roptat>civodul: I think TP is the best place for it. There are 2 pot files to put there <civodul>do you want to email the coordinator? <roptat>maybe it's an issue with reproducibility: if a build output retains the path of its source for instance, we will get two different binaries depending on the location of the temporary directory <civodul>roptat: that's ok because inside the build env the build tree is always named "/tmp/guix-build-foo-1.2.3.drv-0" <efraim>Currently /tmp is the hardcoded temp directory <roptat>hm… well that's strange because depending on the location, findutils fails or succeeds to build <roptat>oh maybe that's because I used --disable-chroot on the daemon? <civodul>if you use --disable-chroot then yes, you're in trouble <roptat>civodul: ok, but I can't build anything without it :/ <roptat>I don't know why this is the case. What does it try to use exactly? <roptat>does it need some kernel support? <bavier`>imho, it would be nice if the daemon could try to do its best in setting up the build environments, but gracefully fall back <bavier`>I think that would be possible, and would help immensely in running the deamon as non-root <bavier`>or with tools like proot, fakeroot, fakechroot, et al <civodul>as non-root, you have to have either user namespaces or proot, no? <bavier`>proot is the only thing that has "worked" for me so far <civodul>right, so i agree that there should be a fallback for clone(2) <civodul>but i don't think it would help for non-root, would it? <bavier`>but that is painful, and is really only usable with the guix binary tarball <bavier`>probably not, there are other gotchas that you run into <bavier`>anyhow, I thought it'd be nice to keep in mind as we plan the guile-based daemon <bavier`>I'll try to keep some notes if I dive back into non-root again <civodul>i'm interested in any improvement in this area <civodul>but we seem to be kinda stuck if we don't have user namespaces <bavier`>maybe, but the daemon could also graceful, with warning, enter a "degraded" mode <civodul>for when some of the clone(2) flags are unsupported? i agree <civodul>we'd need to figure out which ones are missing, though <civodul>there were vague reports of this on ARM, but we never got to the bottom of it <dustyweb>ACTION trying to figure out what the status of Chromium being merged into Guix proper is <adfeno>dustyweb: With the email from that Fedora dev in directory-discuss, I don't have high hopes for that. <adfeno>Actually, I think it was bill-auger who forwarded that email. <mbakke>adfeno: AFAIK none of that applies to Chromium. <mbakke>There are blobs (flash, DRM) and nonfree sources (unrar..!), but they are stripped out with a source 'snippet'. <mbakke>dustyweb: The main issue now is that the "Web Store" is visible. Installing from it is not allowed without a special variable, but it's still possible for an unsuspecting user to stumble into it. <dustyweb>mbakke: it seems like it's very unlikely for that to be a problem then <dustyweb>it's also possible for me, as an unsuspecting user, to stumble upon many websites which advocate me installing nonfree software <dustyweb>it seems like it would be ideal, then, if we can reduce that risk of users bumping into it but <bavier`>the complaint on directory-discuss seems to just be that distros haven't put the work in the properly package chromium and electron <amz3`>ACTION 's brain was eaten by ansible, please help asap <mbakke>I'll send over the patch for 66 and a status update <mbakke>amz3`: You probably just need some Salt ;) <efraim>I haven't looked at the chromium patch since the very beginning, was my change to allow native building on aarch64 incorporated? <vagrantcish>trying to configure tlp, but disabling usb-autosuspend ... (service tlp-service-type (tlp-configuration (usb-autosuspend #f))) <vagrantcish>gives me: /home/vagrant/config/config.scm:97:39: error: extraneous field initializers (usb-autosuspend) <vagrantcish>in the same location, (service tlp-service-type) works, although causes issues with suspending the usb keyboard/mouse suboptimally <nckx>vagrantcish: Try (usb-autosuspend? #f). <vagrantcish>or at least, the system config built ... i think tlp needed a reboot before it actually worked laast time i did this <mbakke>efraim: Yes, I added the snippet you contributed. However it's currently x86_64 only due to the switch to Clang; the fix should be obvious though... <vagrantcish>now i just need to figure out how to get a gnuk usb smartcard to work... <vagrantcish>does slim run ~/.xinitrc or something similar at login? <vagrantcish>wondering where i can start ssh-agent from so it's available in my session by default <nckx>Dammit, mbakke. Why must you be so productive and why must you waste it on Chromium. :-p <vagrantcish>huh. gpg-agent manpage has it's contents repeated three times ... <nckx>vagrantcish: Oh! I opened a bug report about that (knot.conf and... something else)! Could you add this to that?