IRC channel logs


back to list of logs

<optikalmouse>virtualbox + .iso livecd and off to the races
<optikalmouse>and rsync.
<shanemikel_>I just converted the raw image to vdi, because I was having a little trouble building a live iso
<lfam>shanemike1_: Guix has tooling for building QEMU images built in
<shanemikel_>oh, great
<lfam>See the manual section "Invoking guix system" and "Running GuixSD in a Virtual Machine":
<lfam>We actually use some of those tools to build the GuixSD installer image
<paroneayea>btw, anyone who is in San Francisco right now
<paroneayea>you might be interested in coming to tonight
<Steap>lfam: I have a patch for, but it only works upstream, not in your Guix recipe :(
<paroneayea>I am giving a talk about how the retreat went for me
<paroneayea>and Guix comes up significantly :)
<lfam>Steap: Do you think it will be accepted upstream?
<shanemikel_>paroneayea: thanks, I'll try and be there
<lfam>And, how does it not work in Guix? Simply no effect?
<paroneayea>shanemikel_: whoo, cool :)
<paroneayea>shanemikel_: be sure you also introduce yourself to me before/after I speak! :)
<Steap>lfam: well, I talked to a CPython dev I know at work, and he seems ok with such a patch
<Steap>lfam: yeah, it does not change anything when appliedin our Guix recipe
<paroneayea>ok time to work on my talk!
<Steap>but the Python package has become quite weird, so I might be missing something
<lfam>Steap: Care to share the patch? I'm interested to see how you did it. And maybe I can try debugging it in Guix :)
<lfam>Yes, the python packages are very complex.
<lfam>I don't really understand them fully. Or at least, the understanding I gained a month ago has been washed away
<davexunit>paroneayea: good luck with your talk tonight :)
<davexunit>ACTION paroneayea 
<str1ngs>Are the docs for guix master/tip served anywhere?
<lfam>str1ngs: Not AFAIK :( You can build HTML with `make doc/guix.html`
<str1ngs>that will work thanks. actually I should just diff the node
<str1ngs>or log
<Steap>lfam: we bootstrap them from a minimal python, which makes things hard :D
<str1ngs>hmm make html depends on gif generation but I dont know the make rule :(
<lfam>str1ngs: It should "just work" if you are in a guix build environment. That is, in `guix environment guix`
<lfam>Is it not working in that environment?
<str1ngs>no I'm working on a s390x . I can build the docs locally though
<lfam>Oh, that's different ;)
<str1ngs>I just want to make sure the porting pages has not changed
<lfam>str1ngs: The online manual is only a few commits behind master right now. It should be relevant
<str1ngs>ok thanks
<str1ngs>I'm going to port guix first. then port the boot strap
<shanemikel_>should I report failure of tests/
<str1ngs>I also have a power8 server I can work on aswell
<lfam>shanemike1_: Yes, please
<ziz15>guys about how long does it take for guix to finish install?
<lfam>ziz15: It depends on your hardware, network speed, and how much you need to build from source.
<str1ngs>did you do a guix pull?
<str1ngs>cause if you dont it will take much longer :P
<lfam>What installer are you using, ziz15?
<lfam>0.9.0 or 0.10.0?
<ziz15>lfam: what do you mean?
<ziz15>lfam: 10
<lfam>Which version?
<lfam>Okay, good.
<lfam>Then, it depends on those ofter factors I mentioned a minute ago
<ziz15>i install it inside a vm i gave it 4 cores and it has download packges now i see it compiles them
<shanemikel_>oh, I don't know if it's relevant.. the failure mentions gnutls, but I skipped the optional guiletls requirement in the manual
<lfam>shanemike1_: I would send the report anyways. It helps us find bugs.
<lfam>If it's not relevant, we'll just say so and close the bug :)
<lfam>I'm curious, what method are you using? Binary installation or from source?
<shanemikel_>using the make test suite
<lfam>Okay, I wasn't sure because it's also possible to do the binary installation and use that to bootstrap a source based installation. Just curious :)
<shanemikel_>oh, that sounds fancy
<lfam>No, just lazy really :)
<shanemikel_>what are the advantages of that approach?
<lfam>The advantage is that you don't have to round up all the dependencies yourself. You install Guix from the binary and then use `guix environment guix` to provide the dependencies to build from source
<bavier>shanemikel_: yes, send a bug, because the test should be guarded/skipped probably
<shanemikel_>I see, so easy to build without root lfam?
<lfam>shanemike1_: Are you referring to use of something like `apt-get`? You could provide the dependencies by building them from source as an un-privileged user.
<lfam>For Guix, you still need root to start the daemon
***Basstard1 is now known as Basstard`
<Steap>lfam: k, I pushed the patch
<Steap>on debbugs
<lfam>Steap: Thanks, I'll try it out
<ziz15>guys,for much time does it takes about to install ?? i mean i have almost 3 hours already i keep it running..what does it do??
<ziz15>i mean eg when you install parabola it shows 200 mb to download and about a 40 min the install is finish and youre ready to configure the os
<Jookia>ziz15: what's it doing right now?
<jmarciano>well, it maybe builds packages from source....
<ziz15>Jookia: it compiles some packages from tcl 8.6.4
<Jookia>which image are you using?
<ziz15>jmarciano: guix 0.10
<ziz15>i have install so many distros over the years..this thing for me is...
<jmarciano>I think that GuixSD is future of Internet, just like Debian back in time, when they made some good decisions.
<ziz15>jmarciano: i also believe it have things to give thats why i want to try the os
<jmarciano>Well, I did not always get binaries, so sometimes system started to build, compile the programs, unlike some popular distributions.
<ziz15>jmarciano: but ...
<jmarciano>is it compiling now?
<ziz15>jmarciano: i believe so
<ziz15>it shows thread.test time.test etc
<jmarciano>yes it can happen
<jmarciano>I understand that later I can pull packages from not-centralized place unlike with other distributions.
<jmarciano>You could even have your own distribution and your own binaries done on VPS or maybe local server.
<ziz15>so guixsd is like gentoo ??
<str1ngs>ziz15: did you ever do a guix pull?
<ziz15>str1ngs: you mean from 9 go to 10?
<ziz15>str1ngs: or before install current image?
<str1ngs>before you did a system init
<str1ngs>what stage of the install are you at?
<ziz15>str1ngs: no i didnt
<str1ngs>if you do guild pull. it only builds guix and it generally will never have to build packages
<str1ngs>it only builds packages for substitutions it cant find
<str1ngs>IMO they should add that step to the install manual
<ziz15>str1ngs: so now it even builds binaries?
<str1ngs>not always but if it needs too
<ziz15>str1ngs: you kidding me right???please tell me so!!!!!!!!!!!!!!!!!!!
<str1ngs>it only builds them if it needs too
<str1ngs>guix pull keeps things in sync and generally the substitution will exist on the mirror
<ziz15>str1ngs: in my occasion what should i do let it be or stop?? i mean here is 3 am i need to sleep!!
<Jookia>cancel it, run guix pull, try reinit
<str1ngs>what command is it running? that is building alot. system init?
<str1ngs>if so ya kill it and guilx pull
<str1ngs>err guix*
<Jookia>fwiw it's not worth losing sleep over computers
<ziz15>Jookia: SO TRUE
<str1ngs>guix pull should be added to the install manual IMO
<str1ngs>if a package gets GC'd on the mirror you are using. it will build it.
<str1ngs>better to build just guix then the world
<ziz15>guys thank you all for your help..but i believe that with the things how are now im not gonna try another time to install that os
<ziz15>i ll keep an eye on project and if i can help ill help but for now...
<str1ngs>just do a local install :P
<str1ngs>you can run guix inside your current distro
<jmarciano>yes you can run guix totally independent of the existing system
<ziz15>str1ngs: i ll think of it ;)
<jmarciano>later, you can imagine... you define your own distribution in simple script, and it is always the same.
<lfam>str1ngs: The MOTD of the installer recommends the user run `guix pull`
<ziz15>jmarciano: i believe it ll take a while ..
<str1ngs>who reads MOTD? :P
<lfam>Just saying, the reminder is printed directly in front of the eyes of the user as they start the installation.
<ziz15>lfam: mea culpa
<lfam>But, it shouldn't be necessary yet since 0.10.0 just came out
<str1ngs>fair enough, but if your like me you have the manual open as you are installing :)
<ziz15>means my mistake
<str1ngs>I used vt2 :)
<lfam>I don't think it would make a big difference for the 0.10.0 installer
<ziz15>i believe thats the price to try beta or things like that
<str1ngs>bigger fish to fry?
<jmarciano>lfam: what kind of installer is it?
<ziz15>but we learn from our mistakes
<jmarciano>did not know there is one.
<lfam>jmarciano: It's actually a live operating system system
<str1ngs>guix can install form existing distro :)
<jmarciano>aha, like console mode?
<str1ngs>guix's making guix's its kinda perverted :(
<jmarciano>I have run last version, came to console mode from USB stick.
<lfam>You boot it from a USB flash drive (typically), mount your target storage device, and then it installs to the target.
<lfam>Sometimes it takes a while to build some of the components from source. There's not much we can do about except try harder to make sure the binaries are available from the substitutes server
<lfam>Right now we are having an issue where a small number of binary archives are corrupted. Users must use --fallback to get around that, and hopefully they will tell us about it so we can remove the corrupted archives.
<str1ngs>is there a flag to not fallback ever?
<lfam>To never build from source?
<ziz15>str1ngs: you 're my hero!!!!
<lfam>`guix build -h` doesn't mention one. I don't know why you would want that, however. If the substitutes aren't available, and you don't want to build, then you won't get anywhere.
<lfam>I mean, by default, you don't fallback if the substituter errors out. But if the substituter says "not available", then you will build.
<lfam>So, there is a difference between "no substitute available" and a
<lfam>and "substitution failed"
<ziz15>lfam: so the first things after start config.scm is guix pull and then guix system --fallback init /mnt/etc/config.scm /mnt
<str1ngs>it might be better in some cases to not assume you want to build packages
<ziz15>lfam: and wait to finish??
<str1ngs>e.g netbook?
<lfam>str1ngs: If you did that, you just won't get the software in question.
<str1ngs>it would be a way to blacklist builds.
<lfam>ziz15: Yes, just wait for it to finish.
<str1ngs>or alternative is a summary prompt flag?
<str1ngs>downloading such and such, buidling such and such ... continue y/n ?
<lfam>str1ngs: You could suggest it on guix-devel. I see your point although it goes against the spirit of the system, in my opinion.
<ziz15>man i cant believe that for a command i wait 3 hours...
<str1ngs>lfam: its a flag not a default
<str1ngs>current situation would not change
<lfam>I wouldn't be the person who decides or implements it, so that's why I suggest mailing guix-devel.
<lfam>ziz15: Some programs take a really long time to build. For example, libreoffice takes ~8 hours to build on my fastest machine.
<str1ngs>me personally I would like to know if I'm going to be building a kernel or gcc
<str1ngs>upfront atleast
<lfam>str1ngs: It prints out what it's going to do at the beginning
<str1ngs>I'll have to try with -n more
<lfam>You can CTRL+C and read the list, and then decide if you want to continue. I do that often
<lfam>Or that
<lfam>I forgot about that
<str1ngs>-n might be enough
<str1ngs>-y would be nice touch though :)
<lfam>What would that do?
<ziz15>lfam: by default if i choose desktop.scm and configure it as i like eg remove gnome-desktop and keep only xfce how long you estimate it will last to complete the install??
<str1ngs>continue after you hit yes
<str1ngs>be like doing -n then rerunning
<lfam>ziz15: What kind of CPU do you have?
<str1ngs>I have to check the output of -n though
<ziz15>lfam: fx 6300
<lfam>str1ngs: I just tried --dry-run (-n). It prints the summary and exits
<str1ngs>it doesnt do depends either
<str1ngs>like nested ones
<str1ngs>only direct
<lfam>Are you sure? It should print everything it's going to do
<str1ngs>try it
<lfam>I just did
<str1ngs>it will dowload depends not listed
<str1ngs>depends of direct depends
<ziz15>lfam: i mean it only install xorg xfce slim and their deps right no icecat libreoffice etc.right??
<str1ngs>so indirect depends are not listed
<lfam>ziz15: Right
<lfam>I don't know how long it will take. It really depends on whether the packages you need to build the system are already built and available, or if you have to build from source.
<str1ngs>I could be wrong. I need to follow up on it. was just something I noted.
<lfam>str1ngs: That doesn't seem right
<str1ngs>no that's why I made a note of it
<lfam>That feature broke for a while when we had to use grafts. I wonder if it didn't come back fully after we removed the grafts
<lfam>str1ngs: Can you give a reproducer?
<lfam>Like, a git commit and a package to build from that commit?
<str1ngs>I noticed with git
<str1ngs>let me see if I can produce it locally
<str1ngs>with fresh store and state
<str1ngs>sudo rm -rf /gnu/ /usr/local/var/guix/ dont run that at home haha
<lfam>If you can reproduce it, you should send a report to bug-guix
<str1ngs>I'll see what I can do. but its not easier to produce since its dependant on state
<str1ngs>but I think with a fresh guix install I can produce it with the git package
<lfam>The "easiest" way I can think of to debug things like this is to create a bare-bones vm-image, and do it in there. Keep a pristine copy of the vm-image around for when you need to start over
<lfam>There's probably a better way but I don't know it
<str1ngs>I use /usr/local
<str1ngs>then all I have to do is stop the daemon
<lfam>Oh, you have a separate store?
<str1ngs>and purge /gnu and /usr/local
<lfam>See, I would never purge /gnu
<str1ngs>my guix is hosted
<str1ngs>its intentional on my part. not advised for normal users
<lfam>At least set up a caching mirror on your local network...
<str1ngs>you can move the store but thats not advised either
<str1ngs>cache proxy is a good idea. thanks
<str1ngs>I'm really only using it while I do some work on guix
<lfam>But, I rely on my store, so deleting it would mean I would have to wait a long time to do anything while it is rebuilt. If I didn't rely on it, it would be less expensive to do your method
<str1ngs>not really effect on the mirrors
<str1ngs>I would us a docker image
<str1ngs>in fact I should make one
<str1ngs>with system init
<str1ngs>there is a guix docker image but... probably dated
<str1ngs>lfam: actually its looking ok
<lfam>That's good! Please report it if you see it again
<str1ngs>actually if anything.. it installing alot.
<str1ngs>here's an example for bash
<str1ngs>its not to bad
<str1ngs>but bash shouldnt need gzip
<str1ngs>or... coreutils
<str1ngs>glibc, ncurses, maybe readline
<lfam>You are starting from an empty store?
<str1ngs>there is no way, bash need coretutils
<str1ngs>glibc, ncurses, readline, libgcc atmost
<lfam>Those packages are the base of the system. I think they are required before you can do anything. Hopefully somebody with more knowledge can chime in
<str1ngs>that would make sense
<str1ngs>but there not really required by bash. unless they are used by guix
<str1ngs>almost perl
<lfam>You should explore the `guix gc --r*` commands. --references, --requisites, and --referrers
<str1ngs>anyways not a huge deal
<lfam>You can inspect the web of relationships of a given store item with those tools
<str1ngs>its probably working as intended
<lfam>I wonder if gzip is required to decompress substitutes.
<Digit>fresh guixsd on aspireone 32bit, followed instructions from altf2, no wired connection success (and no wireless here). may try install from the already installed slack-based connochaetos or even from the fsf trisquel card. tmro tho. zzz now. :)
<paroneayea>davexunit: thanks!
***Basstard1 is now known as Basstard`
<jololo>Hey! I'm having a problem installing 0.10. when downloading python it says the compressed file ends unexpectedly. What should I do?
<shanemikel_>ok, what kind of config should I use with the `guix system vm-image` command? certainly the disks config isn't gonna work the same as templates/desktop.scm, is it? is there an example config for this?
<shanemikel_>jololo: I had that issue too
<jololo>shanemikel_, did you resolve it?
<str1ngs>shanemikel_: use whatever config you would like
<str1ngs>jololo: sounds like there is an issue with the mirror
<str1ngs>jololo: try adding --fallback
<str1ngs>hopefully that only builds the python package
<str1ngs>shanemikel_: for qemu I might use base-system as a starting point though
<str1ngs>think its called base-sytem?
<str1ngs>or bare?
<str1ngs>bare-bones ! :P
<rekado>jololo: just try again.
<rekado>when you add "--fallback" it will try to build the package locally on failures to download the binary substitute.
<shanemikel_>so where's the guix source repo?
<marusich>This information is listed here:
<marusich>So, I've noticed that if you're running tor-service in GuixSD, IceCat can still browse to a .onion address (e.g., http://duskgytldkxiuqc6.onion/) when SOCKS5 proxy is enabled BUT remote DNS resolution is disabled.
<marusich>Does anyone know why that works? I thought that remote DNS resolution, through the TOR network via the SOCKS5 proxy, would have been necessary for .onion addresses.
<efraim>it's not necessary, but it's good practice to enable it
<marusich>Why isn't it necessary?
<marusich>What I don't understand is how Icecat is resolving the .onion name
<efraim>I don't remember exactly how it works, but IIRC remote dns is to prevent leaking information about you and your system
<marusich>I'm familiar with that aspect of TOR; what I'm trying to figure out is why IceCat is able to resolve the .onion address even though remote DNS resolution is *DISABLED*
<marusich>Not sure how to figure that out... It's just curiosity. I'd like to know where request are going.
<marusich>efraim, turns out that icecat is caching results while it's active
<efraim>ah, ok
<marusich>I don't know why, but it seems that there's some kind of strange caching going on. Restarting it makes it detect the new settings and behave as expected.
<rekado>marusich: I also found that icecat caches stuff (for a little too long), which (temporarily) made the development of a web server application in Guile really frustrating.
<rekado>for development I switched to epiphany.
<marusich>Interesting! I've seen similar problems with other software.
<marusich>For example, Java is notorious for ignoring TTLs:
<shanemikel_>ERROR: download failed "" 404 "Not Found"
<str1ngs>use another debian mirror?
<efraim>try `guix download`
<shanemikel_>no dice.. on there are many libpapers.. but none with the exact name.. I'm guessing it was replaced
<efraim>on my debian system there's no libpaper, but there is a libpaper1
<shanemikel_>I did a guix download of .. and my installation seems to be moving forward
<efraim>oh good
<efraim>the first I could find was
<efraim>still looking for a copy on debian
<ozzloy>(equal? (lambda (x) (1+ x)) (lambda (x) (1+ x))) ; => #f
<shanemikel_>so guix downlaod does a hashcheck of the file, and compares it to some cache of everything? or did it associate the name of the file downloaded with the name of the package, and do a hash verification afterwards?
<ozzloy>woops, wrong window
<efraim>it has the hash of the file, and it compares that to the hash of the file you downloaded
<shanemikel_>that's pretty amazing.. distro responsible for packaging/installation, all we need is the src package
<efraim>ok, found the debian source
<shanemikel_>no "packaging" necessary
<efraim>they moved it to the archive section
<efraim>uh oh, got a different hash from the debian archive
<shanemikel_>the fedora one seems to work
<efraim>yes, but the debian one shouldn't have changed
<shanemikel_>while guix is in this early stage, not hosting it's own source packages, it'd be nice if there was a really simple way for users/early adopters to post alternative package urls to an automated service
<efraim>does changing the source url cause the package to be rebuilt?
<civodul>Hello Guix!
<civodul>efraim: depends!
<civodul>if the 'file-name' field remains unchanged, nothing needs to be rebuilt
<efraim>ok, so I'll update libpaper's uri and see if it wants to rebuild my system
<efraim>also, we were getting it from debian, but they moved it to their archive and the hash changed somehow
<shanemikel_>where should I read about the hashing mechanism? is it the same as nix?
<str1ngs>its just sha256sum naw?
<efraim>i think its the same as nix's
<str1ngs>it probably uses public keys for GNU stuff aswell
<str1ngs>its probably optional
<civodul>shanemikel_: see
<marusich>shanemikel_, there is an option that lets you specify a custom source:
<marusich>If you routinely want a different source for a package, or you need other customizations, you can create your own packages by copying the package definition from the guix repo and changing the appropriate lines. Just put your package definition in a guile module on the GUIX_PACKAGE_PATH, and it will be used. See Info node "(guix) Package Modules" for details.
<marusich>Once you know how to do it, it's really quite pleasant and easy!
<civodul>hey, howdy marusich :-)
<marusich>Hi there!
<Jookia>civodul: qemu derivation stuff is to make the caller unaware of bootloader
<Jookia>civodul: at lesat as a beginning
<civodul>Jookia: could you reply in the email thread, because i'm afraid of getting lost otherwise :-)
<civodul>ACTION starts going through his backlog
<marusich>I need to log off - thank you for the very nice v0.10.0 release! It's awesome :)
<civodul>thank you for your feedback marusich!
<Jookia>civodul: i did :)
<marusich>my pleasure
<civodul>it was really useful
<civodul>right on time ;-)
***Basstard1 is now known as Basstard`
<rekado>not sure I understand this:
<rekado>or rather
<rekado>does this mean I can create a service "pam-limits-service" that extends the "pam-root-service-type" with a procedure adding ""?
<rekado>will this apply to *all* pam entries?
<rekado>we have the "unix-pam-service" procedure which takes a name and then produces a pam entry.
<rekado>is this also affected?
<civodul>rekado: yes!
<civodul>pretty neat stuff ;-)
<civodul>just throw a pk in your procedure if in doub
<civodul>or "guix system build" the thing and check its etc/pam.d
<rekado>I find it a bit hard to wrap my head around the service stuff. And I seem to have to wrap my head around it repeatedly, because my head is so unflexible... :)
<civodul>maybe it's a sign that things are unclear or complex (bah!)
<rekado>nah, I think it's just unfamiliarity on my side.
<rekado>ah, I think I understand better now: services are not "registered" anywhere, but they point to one another, all the way down to system-service-type.
<rekado>it seemed like magic to me that the extension mechanism would work without some sort of register of services.
<rekado>but it's right there in the "extend" field.
<shanemikel_>I just tried to build vm-image .. built a lot of things, and I failed some tests after about an hour of compilation.. it's saying to grab tests/testsuite.log, but I don't know where to find it
<rekado>I have a couple of R packages here that really only provide very large data files (the latest genomes for human, mouse, worm, and fly). Should I just keep them local or does it make sense to add them to Guix?
<rekado>the mouse genome tarball is 593 MB.
<rekado>or would it be okay to add them if we also mark them as not substitutable?
<rekado>to spare hydra from building them
<rekado>shanemikel_: are you running GuixSD already? Or is this using Guix on another distribution?
<civodul>rekado: re services, you can check "guix system extension-graph", it might help figure out what's going on
<civodul>rekado: we could add those packages are mark them as unsubstitutable, indeed
<civodul>is that data free?
<civodul>i would argue that genome data is not copyrightable, but you know...
<shanemikel_>according to us gov, the dna itself isn't, but the mrna transcripts of it are
<shanemikel_>as far as I recall
<shanemikel_>that's like saying the data in your raid is free, but the parity blocks aren't
<shanemikel_>except in your body
<shanemikel_>or the java of your body is yours, but the jvm of your body is property of sun
<shanemikel_>except there's no openjre for your dna
<shanemikel_>damn.. this guixsd installation sure takes a bit of time.. it really is the emacs of distros :)
<rekado>civodul: the packages are under artistic 2.0
<rekado>I don't know about whether the actual genome codons are copyrighted :)
<rekado>shanemikel_: what about it takes time?
<rekado>shanemikel_: compilation takes time, but if you use substitutes compilation is not necessary.
<rekado>we don't have substitutes for everything, and sometimes substitutes are unavailable because hydra is overloaded.
<rekado>in that case I'd just try again.
<rekado>it is okay to abort guix and retry. It's safe to do this. (Do not kill the daemon, though, as that's not safe.)
<nckx>rekado: what's the Right Way to terminate the daemon then?
<nckx>ACTION killalls guix-daemon all the time, but not when it's ‘working’.
<ng0>ACTION packages guix on gentoo today just for fun
<ng0>my #FIXME notes in it read like i won't be done with it afterwards.. FIXME: package shepperd for gentoo or get an shepperd-to-openrc import thing. FIXME: write openrc related files to be included in addition to systemd file in guix master . etc
<ng0>not that there is any point in shpperd-to-openrc.. but maybe someone does it as a proof that it works.
<fhmgufs>rain1: Hi!
<nckx>Hullo rain1.
<ng0>doing guix on gentoo is funny. the default just stuffs guix into the guile/site/ locations
<Jookia>GNU on windows 10 is going to be very interesting
<ziz15>when install bare-bone config how many packages does it downloads ?
<rekado>ziz15: which bare-bone config do you refer to? The one from the manual?
<ziz15>rekado: yes
<ziz15>rekado: i mean as a template
<rekado>nckx: you may of course kill it when it's not doing anything. I just meant that to abort a guix build process one should not kill the daemon.
<Jookia>To speculate it looks like Windows has implemented the Linux ABI on top of the NT kernel, meaning we could add Guix as a 'native' environment devel environment
<rekado>nckx: instead of using killall you could use the systemd service unit file (if you are on a system using systemd).
<rekado>nckx: or wrap it up in a non-systemd service.
<rekado>nckx: but ultimately it's the same as sending SIGTERM to the daemon.
<rekado>ziz15: I don't know how many packages it will download.
<rekado>ziz15: do you think it downloads too many?
<nckx>rekado: nope, just manually launched ./pre-inst-env from the git repo. But as long as there's no hidden danger in killing an idle daemon I'm reassured.
<ziz15>rekado: i will soon figure it out i just try to install guixsd with bare-bone.config :)
<ziz15>rekado: yesterday i try the desktop but after 4 hours i gave up
<rekado>ziz15: back when I installed a bigger GuixSD system for the first time it took a long time to download substitutes from hydra.
<rekado>as long as it's just downloading stuff it's all fine.
<rekado>when it starts building something from source it's very likely going to take a lot longer.
<nckx>ziz15: downloading alone took me 14 hours once. Those were the days.
<rekado>hydra is, unfortunately, very very slow.
<ziz15>rekado: i know it starts give me chills when i see it compiles :)))
<rain1>it shouldn't take that long!
<rain1> --substitute-urls=
<rain1> --substitute-urls=
<nckx>Now it's 1 hour of building packages truncated by the mirror...
<rain1>you could give one of the mirrors a go, that might help a bit
<rekado>we have the funds for a replacement, but there have been problems on the vendor's side to get the hardware set up.
<rekado>yes, using is probably a good idea in many cases.
<rekado>once we have the new hardware in place things are going to get better.
<Jookia>it'll be worth it
<ziz15>i believe at least for the basic setup of the os the packages needed should be all precompile so when someone who wants to try the os want have to wait for so long..
<Jookia>i feel like i've missed out on all the substitute drama but just compiling everything from source
<efraim>rekado: edirect fails to build because the source changed, it also seems like there have been a few new releases
<efraim>I was thinking of tossing the download on for the backup
<rekado>efraim: I was thinking about dropping edirect completely. I don't like to play catch with the developers.
<efraim>:( also an option
<rekado>ziz15: they are precompiled. They are available as binary substitutes on hydra.
<rekado>it's just that hydra is slow and busy.
<ziz15>for me at least every time a try to install guixsd it compiles something
<rekado>for example?
<Jookia>did you run guix pull
<ziz15>now i waiting for the results
<ziz15>man im about to cry !!! it just finish saying Installation finished. No error reported.
<Jookia>congrats friend
<ziz15>thank you all for you pacience toward me 2 days now.really appreciate
<ziz15>Jookia: :)
<civodul>rekado: Guix 0.10 uses aka. by default
<rain1>congras ziz15 :P
<ziz15>rain1: thanks my friend !! :P
<ziz15>now at last i ll see what this os is all about...
<ziz15>one comment i believe what rain1 was said was right someone should put on the manual this two commands before begin installation guix pull and guix system --fallback init /mnt/etc/config.scm /mnt and the just wait to finish
<Jookia>--fallback will compile things tho
<ziz15>now that i do the above steps and install bare-bone config it only took about 30-40 min to finish the install
<ziz15>Jookia: yes it will compile only if not find a precompile package to install or im wrong??
<Jookia>that is true
<ng0>regarding guix building from source: /var/empty should be equal for homedir as /dev/null , right?
<rekado>ziz15: each time you ran "guix system init" it downloads a little bit more. Already downloaded packages are cached in /gnu/store.
<rekado>ng0: I don't understand the question. Could you rephrase?
<ng0>compiling guix from source.
<ng0>one sec
<ng0>the point where I create users for guix
<ng0>I have to add parameters like homedir, does /var/empty (like recommended on the guix site) has an equal effect as /dev/null (gentoo default) ?
<ziz15>now that i login when i want to uprade the installed packages (guix package -u) should i run guix pull before or no?
<ng0>I ask about the difference between the null device and /var/empty because searching for the difference is not really productive
<ziz15>rain1: now i m in cli mode id like to install eg. xfce if i give guix package -i xfce do i have then to modify anything inside /etc/config.scm or it will be modified automatically(desktop-services etc)
<rain1>ziz15, xfce is a special case you gotta do this differently
<rain1>you need to copy the stuff from /etc/configuration/desktop.scm into yoru config
<rain1>so that it is able to start x and stuff like that
<rain1>then as root guix system reconfigure <your-config.scm>
<rain1>which will install XFCE and other things, then you can reboot
<rain1>for anything else you can just guix package -i though
<ng0>i'll just see if guix works with the gentoo default.
<ziz15>rain1: ahh ok thanks man
<ng0>so bug #355355 is still not relevant for gentoo.. or too little people working on it.. which is almost equal. (version bump to guile-2 , guile-2 already being in the tree but their guile-2 (can) break your entire system (happened to me))
<ng0>the bug was opened in 2011
<ng0>meanwhile the overlay I am contributing to ocassionally has a perfectly working guile 2
<ziz15>i want to install iptables after i create the rules is there a specific service i need to enable with herd?
<ng0>not yet i think
<ng0>not sure if my answer applies
<ng0>I was thinking of configuring iptables through the system file
<ziz15>ng0: how to do that?
<ng0>at the moment you can't
<ng0>there are system services which can be configured through your system.scm , like tor-service
<ziz15>so i just create my rules save them into a file and make it an autostart script?
<davexunit>yeah the service layer is the right place for this.
<rain1>you might have to write a new service
<rain1>I don't know
<ziz15>so how to setup a basic firewall?
<davexunit>ziz15: no one has written a service for doing that yet
<davexunit>you could manually configure iptables
<davexunit>but it can't be part of your declarative system config until there is a service for it
<ziz15>davexunit: thats what i think so..right now im reading the manual about network services and so and i think that i should make it as an autostart script
<ziz15>davexunit: anyway..thanks
<davexunit>ziz15: what do you mean by "autostart script"?
<ziz15>davexunit: i write my rules into a sh scipt and put it in /etc/rc.local
<ziz15>davexunit: or something like that
<davexunit>ziz15: that's not going to work on GuixSD
<davexunit>well, it may work, I don't know much about it, but it's very much not the way to do things in GuixSD
<ziz15>davexunit: ?? man that os is die-hard !!!
<davexunit>you want to define a service
<davexunit>I imagine rc.local is an init system specific thing
<iyzsong>yep, we can add a shepherd service to run '/etc/rc.local'.
<davexunit>sure, but we shouldn't need to do that!
<ziz15>davexunit: then why not? i ll try to create a service
<davexunit>just define a firewall-service
<davexunit>that way it will compose with the rest of the services
<davexunit>a good firewall service would allow for other services to extend it
<davexunit>for example, a web server could extend the firewall service to open up port 80 or 443
<ng0>a very good firewall service could allow the tor service to redirect tor traffic
<ziz15>davexunit: i know...back to 'school' back to reading :P
<davexunit>for getting something done quickly, sure go ahead and hack as needed, but I just want to make it clear what the "right way" is to do things in GuixSD.
<ng0>ACTION gets extra bonus points for adding 19 guixbuilder users >.<
<davexunit>consider this an invitation for someone to create an extensible firewall service to guix.
<ziz15>davexunit: Guixsd quote: "the right way is the hard way" :P
<rain1>Anyone want to compile the linux kernel to help the test reproducible build patch?
<davexunit>the right way is the *extensible* way
<davexunit>ng0: can that tor thing be achieved with an iptables rule?
<ng0>more or less.
<ng0>let me come up with the link for that
<ng0>depends on how you want to run tor. tor-dns is one method.
<ng0> somewhere on that page, but you should keep in mind
<rain1>" An Isolating Proxy requires at least two machines. Those machines can be either virtual machines or two physically isolated machines. Both machines are connected through an isolated LAN. One machine is called Gateway. The other one is called Workstation."
<rain1>could do that with guix environments?
<ng0>in the current state it is unlikely
<ng0>if you can fix that, it's one more step towards Guix'ish Tails
<TMA-1>Hi all, just about to try installing guix on a spare x200s I have :-)
<Jookia>rain1: i think using nftables/iptables to isolate connections is good enough
<efraim>gst-plugins-base on arm failed the orc related tests, on mips orc failed to build
<efraim>time to see about removing orc as an input on those two arches
<ng0>so i wonder if my problem is that files sit in their default gentoo location, but I have a /gnu/store/ dir. the guix command is available to all system users (personal, root) ,all buildusers are in the group guixbuild, i have not copied the /per-user/root/guix-profile to ~root/.guix-profile and I get a message about no users being in buixbuild group.
<ng0>could be an error of no .guix-profile in root?
<ng0>sure this is inofficial and not supported, but i am currious if someone might know the solution. otherwise I deal with this over a period of time :)
<ng0>it's almost working
***tschwing_ is now known as tschwinge
<ng0>sidequestion: openrc init files of gentoo are gpl2 (at least the vim template files and the ones included by default in packages shipped with portage), can this be included in master of guix?
***nckx is now known as nckx|offline
<bavier>I just read a very poorly researched and misleading "viewpoint" article in the Communications of the ACM about GNU/Linux history
<chewieQC>Do I have to reinstall guix to upgrade on a foreign distro?
<davexunit>chewieQC: no
<chewieQC>davexunit: I tried guix package -u guix and guix pull
<davexunit>chewieQC: that'll do it
<chewieQC>davexunit: still at 0.9.0
<davexunit>chewieQC: 'guix pull' is correct, it will pull the latest version from master
<davexunit>which is 0.10.0
<rain1>chewieQC, I think there's a bug that menas 0.10 doesn't show up in --version
<ng0>there is?
<ng0>guix (GNU Guix) 0.10.0
<davexunit>yeah I see 0.10.0 as well
<chewieQC>I'm retrying a guix pull
<chewieQC>Still at 0.9.0, but if I do guix edit guix I can see in the editor that the version should be 0.10.0-0.
<ziz15>why the os have so many users??(guixbuilder1,2,..)
<rain1>chewieQC, yeah it's the bug mentioned yesterday
<chewieQC>rain1: Oh I see
<davexunit>chewieQC: 'guix edit guix' has nothing to do with this
<rain1>it just isn't displaying the new version
<rain1>but I think we really are on .10
<davexunit>it should be easy to tell
<davexunit>look in .config/guix/latest/guix/config.scm
<chewieQC>Does it mean the deamon only is stuck on an older version?
<davexunit>the daemon is fine
<davexunit>it rarely changes
<rain1>that's interesting
<rain1>~/.config/guix/latest/guix/config.scm doesn't exist
<civodul>bavier: bah, disappointing
<rain1>~/.config/guix/latest/guix/ does
<rain1>maybe this is related to why it's still displaying 0.10?
<davexunit>maybe that's part of the bug then
<davexunit>I don't use 'guix pull'
<civodul>yeah, see
<davexunit>so I wouldn't notice.
<chewieQC>rain1: same for me
<davexunit>I symlink .config/guix/latest to my git checkout of guix
<chewieQC>Also I can search for packages added in 0.10 now (ex: blender)
<ng0>\\o/ woo
<ng0>guix on gentoo
<rain1>great :D
<ng0>well.. almost. :/ at least i managed to get some downloads
<ng0>maybe "error: build failed: the build users group `guixbuild' has no members" is its way to say connection interrupted. I can't guix pull as normal user either. might be a problem with where gentoo stuffs guix files
<rain1>is there something like add-
<rain1>ad-hoc but subtract-hoc ?
<rain1>I don't want to go all the way pure, just remove one thing
<davexunit>I don't understand what that would even do
<davexunit>if you need custom package transformations, you should write Scheme to create them.
<rain1>oh actually pure doesn't even help
<rain1>I have a custom qemu package that I made
<rain1>oh no it's fine!
<ng0>can i build guix to be more verbose?
<kas2207>Out of curiosity, is the current guix package management and guixSD able to be version controlled? Just thinking it would be cool to take a snapshot of my current configuration and load it onto another computer.
<davexunit>kas2207: this is why we describe system configurations in text files.
<davexunit>I keep all my stuff in a git repo
<kas2207>davexunit: that is awesome!! Do you mind sharing your repo?
<davexunit>here's the config for my laptop
<davexunit>and this is the config for my user package profile
<kas2207>awesome! Thank you!
<ng0>ohh. guix-daemon must run as root:root , right?
<ng0>is this assumed as default by systemd?
<rain1>I tried to package this
<rain1>the c library installed ok but there's also python bindings, not sure how to do that
<rain1>I don't know how python works
<anthk_>an "extensible" firewall for Guix... so a layer written in Scheme as an interface for iptables, kinda like ufw?
<davexunit>anthk_: yeah, pretty much. we already have a number of services like this.
<davexunit>services that extend other services, that is.
<davexunit>so it only seems natural.
<anthk_>davexunit: nice. I guess Scheme is really suited to create a dynamic firewall
<davexunit>well, it wouldn't be a dynamic firewall
<davexunit>I'm talking about using the service API to generate a configuration file for iptables
<davexunit>and let iptables do its thing
<davexunit>the configuration generated will be static
<optikalmouse>scheme as configuration tool, an alternative to ansible/chef/puppet
<optikalmouse>davexunit: ^ that's basically what you mean right?
<chewieQC>Do you know which package have a translated description? I'd like to study how it is done
<ng0>gentoo: /usr/bin/guix-daemon --build-users-group=guixbuild guixsd: /storepath/bin/guix-daemon --build-users-group guixbuild
<davexunit>optikalmouse: yes, this is what Guix does.
<ng0>notice the difference?
<ng0>does this matter?
<davexunit>optikalmouse: the system configuration interface replaces those imperative tools
<davexunit>and I am (very slowly) working on a tool to use that interface to manage clusters of remote machines
<optikalmouse>so docker+docker-compose+ansible/chef/puppet
<optikalmouse>which is far more than what Nix does am I correct?
<davexunit>NixOps does this
<davexunit>NixOps has some problems that I hope to avoid with 'guix deploy'
<davexunit>the most important of which being the state file that NixOps requires.
<lfam>rain1: Deterministic kernel builds :)
<lfam>Testing now...
<lfam>rain1: Have you played with 'diffoscope' yet? It's a very nice tool for exploring these issues
<rain1>lfam, I tried to install it but no guix package :)
<rain1>it slooks cool I might install debian to try it out
<lfam>rain1: There is a Guix package!
<rain1>oh wonderful ^^
<lfam>I sent some preliminary feedback on your patch while I build the kernel over and over again
<civodul>lfam: ooh, you're working on deterministic kernel builds?
<civodul>i never tried actually!
<lfam>civodul: rain1 is working on it, and I'm testing and giving a bit of advice
<paroneayea>hello everyone
<lfam>civodul ^
<lfam>'lo paroneayea
<civodul>ACTION must catch up
<civodul>hey, paroneayea!
<paroneayea>hey lfam, civodul, * :)
<ng0>does the format the error message outputs matter? why does it say `guixbuild' and not 'guixbuild' in the error message?
<jmd>How is the "container" feature going?
<ng0>i think gentoo broke guix. it does work, but essential features do not, which is why i need to rewrite the package to get installed in the guix standard way (binary) / layout.
<rain1>guix/build/gnu-build-system.scm: (setenv "SOURCE_DATE_EPOCH" "1")
<rain1>what is this?
<rain1>I am reading this too
<bavier>I was just going to paste that link
<rain1>grep -r SOURCE_DATE_EPOCH --include='*scm'
<rain1>i searched for it inside guix but I can't see any uses of it
<rain1>except the definition
<rain1>I don't really understand what it's about or what to do
<rain1>we use gnu build system, and it sets this var - so maybe it's not needed?
<bavier>rain1: it's for any packages that support the use of SOURCE_DATE_EPOCH
<rain1>Should I write (setenv "KBUILD_BUILD_TIMESTAMP" (getenv "SOURCE_DATE_EPOCH"))
<bavier>that should work, the source-date-epoch phase is run early
<bavier>rain1: I think there are other packages that explicitly use the timestamp of the release tarball
<bavier>makes upgrades a bit more involved though, so I don't know if that's the best solution.
<bandrami>Installing Guix SD 0.10.0 now. I’m noticing I have to regularly restart the ‘guix system init $CONFFILE $MOUNTPATH” command a lot, every time there’s a network timeout or sig mismatch or something. If nobody’s working on that I’ll see what I can do.
<jmd>I wonder if the guix project could maintain and publish a list of which packages appear to be reproducible and which do not.
<handsome_pirate>ACTION waves
<handsome_pirate>So, now that I have guix building under Fedora, I'll be submitting a review request shortly
<davexunit>handsome_pirate: hey!
<davexunit>handsome_pirate: that's really great to hear! I'm sorry that we didn't get a chance to catch up before the end of LibrePlanet.
<davexunit>having a Fedora package for Guix is really exciting.
<handsome_pirate>davexunit: So, before I submit an actual review request, what all should I be setting up beyond just building?
<handsome_pirate>davexunit: btw, you can follow my build here:
<davexunit>handsome_pirate: I guess it depends on how far Fedora packages go in setting up state with post-install hooks and things.
<handsome_pirate>davexunit: It's building for 32 and 64 bit Intel and 32 bit arm
<handsome_pirate>davexunit: I can go pretty far.
<davexunit>but for guix to be usable, the daemon needs to be running, which requires some users and a group to be created
<handsome_pirate>okay, I'll check that out
<handsome_pirate>Obviously, first goal was to get it building
<davexunit>yeah, naturally.
<davexunit>future steps could include packaging optional dependencies for Guix, like guile-json and guile-charting, that enable non-essential features.
<handsome_pirate>btw, I am also going to submit builds for several other arches
<davexunit>I think the only other one that will work is MIPS
<davexunit>mips64el, to be specific.
<davexunit>we don't have ports to powerpc or other architectures
<handsome_pirate>which, ironically, Fedora has not supported in quite some time
<davexunit>so I think you're good with what you have.
<handsome_pirate>Have you tried on aarch64?
<davexunit>I'm not familiar with that one
<handsome_pirate>64 bit arm
<handsome_pirate>annddd, build failed
<davexunit>as expected
<handsome_pirate>build failed on x86_64
<davexunit>well that's not expected :)
<davexunit>that's the platform most of users use
<davexunit>including myself
<handsome_pirate>Looks like it was trying to grab something over http?
<davexunit>handsome_pirate: are you using the 0.10.0 release tarball? was released yesterday.
***Basstard1 is now known as Basstard`
<ng0>on failing guix: i think after 8 hours I made progress but I refuse to follow building from source on gentoo today any longer. I'll just try and package the binary version first
<handsome_pirate>davexunit: Yes, I am
<bavier>bootstrap tarballs
<handsome_pirate>davexunit: As a note, network access is not allowed from within the Fedora build environment
<davexunit>yes, I understand.
<davexunit>but guix wants to download the bootstrap tarballs
<davexunit>because we're in a weird position
<davexunit>I agree that network access is bad
<bavier>could those tarballs be made into their own fedora packages?
<davexunit>guix builds also disallow network access
<ng0>gentoo without any specific instructions for econf and emake throws guix (from source) all over the place, it works, but the builder users never get recognized.
<davexunit>this would be a great question for guix-devel
<davexunit>or maybe when civodul sees this/
<handsome_pirate>bavier: Well, bootstrap binaries are sort of allowed to do an initial build of a package
<davexunit>bavier: our own guix package doesn't need network access
<davexunit>what do we do...
<handsome_pirate>I can do a copr build right quick, just to see how that turns out
<bavier>davexunit: I think we intern the bootstrap binaries into the store
<davexunit>ah, we have separate packages for the bootstrap Guile for each platform
<bavier>so that the guix package build has access to them
<davexunit>bavier: but those aren't inputs to the 'guix' package
<bavier>hrm, oh
<davexunit>I believe it's the bootstrap guile that is problematic
<davexunit>handsome_pirate: for reference, here's the guix package for guix:
<davexunit>the copy-bootstrap-guile phase copies the bootstrap guile binaries (which are separate packages here) into the correct places
<handsome_pirate>Can the bootstrap binaries be built without guix?
<handsome_pirate>ie, can I build them on their own?
<davexunit>no, at least not currently.
<davexunit>these are the binaries that are taken for granted so the rest of the system may be reproducible.
<bavier>they *can* be built without guix, via guix's makefiles, but I don
<bavier>'t think their reproducibility is guaranteed
<ng0>if i get this done for gentoo, I wonder if I try to shake up the portage project about guile-2, or if I just am done with contribution it to the overlay.
<davexunit>right, they aren't bit-reproducible.
<handsome_pirate>If I can build them in Fedora on their own, then they should be
<davexunit>so if the bootstrap binaries vary by any number of bits, *every package build* in guix will have a different hash than what all other guix users will have.
<davexunit>thus, Fedora users will build everything from source all the time, since we won't have substitutes for them.
<davexunit>this has grown into a bigger discussion into reproducible builds than I had hoped.
<davexunit>Fedora surely has bootstrap tools, too. all distros do.
<handsome_pirate>Packaging guidelines aren't going to allow me to grab someone's binaries for every build
<davexunit>so the question is: can Fedora accept that Guix bootstraps with a fixed set of tools?
<handsome_pirate>If those tools are built in Fedora
<davexunit>right, so it appears that Guix and Fedora are incompatible.
<handsome_pirate>For the same reasons y'all do it.
<handsome_pirate>Our builds have to be reproducable within our build system
<davexunit>the issue here is that Guix is a distro, that does its own bootstrapping process.
<handsome_pirate>We're smart folk
<davexunit>this discussion has come up before about getting Guix into Debian, and the conclusion I have come to but can't yet convince everyone of is that we can *never* hope to have a Guix package in Debian proper.
<handsome_pirate>We ought to be able to figure this out :)
<davexunit>we should distribute unofficial packages ourselves
<handsome_pirate>davexunit: if that's the case, a couple suggestions:
<handsome_pirate>first, you can do network-enabled builds on copr
<davexunit>that use our bootstrap binaries, because they are essential and must not be even a single bit different from what other Guix users use without suffering severe practical consequences.
<handsome_pirate>So, that would get you an official unofficial build with part of Fedora's build system.
<davexunit>the issue is less about the network and more about binaries taken for granted, though, right? if we just shoved those binaries in the Guix repo, the same issue would be present.
<handsome_pirate>I can also help doing the rpm
<davexunit>handsome_pirate: okay, maybe that's the best thing.
<davexunit>a discussion should probably happen on guix-devel about this. I'd be happy to have *anything* that Fedora users could install.
<davexunit>the problem with Fedora accepting a Guix package is the same problem that we have accepting self-hosting compilers.
<davexunit>bootstrapping requires taking binaries for granted that aren't in your blessed set of bootstrap binaries.
<handsome_pirate>So, I think the issue here is the definition of boostrap
<handsome_pirate>In Fedora, bootstrap means "initial build and inital build only"
<handsome_pirate>After that, you have to use binaries built within Fedora
<davexunit>the conflict occurs because Guix has its own "initial build and initial build only" binaries
<davexunit>and they *cannot* be changed without affecting the rest of the system.
<handsome_pirate>See, if I can build those inital build binaries in Fedora and then subsequently use them, then we're good
<davexunit>in that every Guix build will have a different identity because of such a change
<davexunit>handsome_pirate: you can build them, but you'd have to *ensure* somehow that they are bit-identical to the ones we provide.
<davexunit>a goal for us is to make that possible
<handsome_pirate>davexunit: Well, that would be an interesting challenge
<davexunit>but bit-reproducible builds are, as you know, an unsolved problem currently.
<davexunit>so maybe we can make some progress on that.
<handsome_pirate>davexunit: The issue I could see is linking against, say, different glibc
<str1ngs>also no distro is going to take kindly to linking against a third party glibc
<str1ngs>sorry redundant missed the last message :(
<handsome_pirate>davexunit: do you happen to know if there's a way to tell it to not install the upstart config?
<paroneayea>oh hi handsome_pirate
<paroneayea>handsome_pirate: chris webber here. Welcome to #mediagoblin!
<paroneayea>(I'm used to inviting people to a different channel oops)
<handsome_pirate>paroneayea: Ahoy!
<rain1>If anyone wants to test for the reproducible kernel - 5407vh3mpb69lnkd0ajx0xly6gd77gs1 is the hash I'm getting
<rain1>mark_weaver, btw I tried using a different email program - would be curious to know if this fixes that UTF-8 thing
<rain1>if not I should learn to use mutt
<mark_weaver>rain1: it didn't help. the relevant header is Content-Type. It should include something like 'charset=utf-8'
<mark_weaver>I guess it would be fine to use a different charset also, as long as the copyright symbol exists in that charset and is properly encoded for it.
<rain1>I specially set transfer encoding to UTF-8, I'll learn to use mutt
<rain1>(that was with claws from guix packages)
<civodul>handsome_pirate: re network access, Guix also disallows them as davexunit wrote, so our Guix recipe for Guix uses pre-fetched tarballs that are copied in the right place:
<mark_weaver>rain1: in your second email, the Content-Type of the attachment is application/octet-stream, which might be part of the problem.
<mark_weaver>I guess that means "binary", hence no encoding at all
<mark_weaver>in your first email, the Content-Type was text/x-diff, which was better, but it just lacked the 'charset' field.
<mark_weaver>anyway, it's not a huge deal, I can fix that up.
<mark_weaver>otherwise the new patch looks good... thanks again!
<rain1>oh no.. my build --check just finished with /gnu/store/n20i0s96p29vkl07vlvxli5xql3m3hgi-linux-libre-4.5
<rain1>that's a different hash, but it didn't complain?
<mark_weaver>rain1: removing the user and hostname environment variables would change the output compared with your original patch, but it's still deterministic.
<rain1>alright, hopefully we can confirm it across computers
<mark_weaver>the user, as set by the build daemon, is nixbld, and the hostname is the empty string
<rain1>ACTION running a new build
<mark_weaver>also, the timestamp will be different with the new patch version
<mark_weaver>(or maybe it will be different)
<mark_weaver>I don't know off-hand what we set SOURCE_DATE_EPOCH to
<rain1>I think it's set to '1'
<rain1>seemed a bit weird
<rain1>but I did that since it was suggested
<civodul>all build systems set SOURCE_DATE_EPOCH now AFAIK
<mark_weaver>rain1: pushed, thanks!
<civodul>so you shouldn't have to set it explicitly for one package
<rain1>awesome :)
<suitsmeveryfine>Hi! I'd like to try to get the Macbook2,1 touchpad working again but could need a little bit of help.
<suitsmeveryfine>I experienced the same problem in Parabola and found a way to fix it there (permanently), but GuixSD is very different.
<mark_weaver>civodul: the linux-libre build system doesn't seem to honor SOURCE_DATE_EPOCH, but honors KBUILD_BUILD_TIMESTAMP instead
<mark_weaver>so we now copy SOURCE_DATE_EPOCH into KBUILD_BUILD_TIMESTAMP
<mark_weaver>thanks to rain1's patch
<suitsmeveryfine>The Parabola solution was to simply copy "/usr/share/X11/xorg.conf.d/50-synaptics.conf" to "/etc/X11/xorg.conf.d/". How could that be achieved in GuixSD?
<rain1>suitsmeveryfine, I think one way might be to copy the /etc/hosts shepherd service
<rain1>I haven't done this myself so there might be challenges doing that i'm not aware of
<suitsmeveryfine>copy it where?
<rain1>I mean make a copy of it and repurpose it to do the xorg config file setup, instead of a /etc/hosts file setup
<rain1>it's just an idea that I wanted to suggest
<suitsmeveryfine>rain1: I see. Well, I've never looked into how Shepherd works
<suitsmeveryfine>I can't see why etc/hosts has anything to do with the init system though. Did you really mean the hosts file=
<mark_weaver>suitsmeveryfine: if you're running 'guix' from a git checkout, then the easy way is to add the relevant bits into the strings in 'xorg-configuration-file' in gnu/services/xorg.scm
<mark_weaver>and maybe that's how we'll want to fix it anyway, if we can find something that would work for you without breaking anyone else
<mark_weaver>there's another way to do it, but it's kind of a pain
<mark_weaver>of course, really the xorg-server should be fixed to handle this automatically.
<suitsmeveryfine>mark_weaver: cool! I'll try that. I'm mainly doing this for the project because the computer runs very fine on Parabola currently.
<mark_weaver>the goal nowadays is to not need to play with Xorg configuration files to have things "just work"
<suitsmeveryfine>yes, but I'd like to make a contribution so that the MacBook2,1 machine "just works".
<mark_weaver>yes, I appreciate that
<mark_weaver>especially given that you are not even using GuixSD, it's great that you are still trying to help us :)
<suitsmeveryfine>It was a good experience to install Parabola, because I experienced basically the same issues as with GuixSD, except it was easy to find solutions on the arch wiki.
<suitsmeveryfine>mark_weaver: I'm sitting with GuixSD right now on my desktop computer :)
<mark_weaver>ah, okay :)
<suitsmeveryfine>I really like GuixSD, but I must say that systemd is very convenient.
<mark_weaver>yes, shepherd has some catching up to do there
<mark_weaver>I think it will be a win for us in the end though
<suitsmeveryfine>libreboot + systemd + ssd gives you a pretty fast boot
<suitsmeveryfine>What is the advantage of shepherd vs systemd?
<mark_weaver>and anyway, we want to support GNU Hurd, whereas the systemd developers are unabashedly uninterested in support any kernel other than Linux.
<suitsmeveryfine>yes, of course
<mark_weaver>much of the benefit of Guix, we think, comes from using a general purpose language (Scheme) in many different areas, where other projects (e.g. Nix) tend to use multiple special-purpose, inflexible, languages for different things.
<suitsmeveryfine>yep, I really like the GuixSD project.
<suitsmeveryfine>By the way: I want to donate a c201 computer
<suitsmeveryfine>either to Guix or the Parabola project-
<suitsmeveryfine>Which would make best use of it do you think?
<suitsmeveryfine>I'm takling about the chromebook computer that's supported by libreboot
<mark_weaver>if I wasn't so overloaded, I'd jump on that :)
<civodul>mark_weaver: ooh, i see
<mark_weaver>there are just two complications with GuixSD on the C201. One is that at present, we assume GRUB, and GRUB-on-arm seems to only work on u-boot systems, and the C201 doesn't use u-boot.
<mark_weaver>and the other thing is that maybe the limited storage on the C201 would make it a bit tight to run GuixSD on.
<mark_weaver>I forget, how much storage does it have?
<suitsmeveryfine>I've done some reading on the Chromium OS website
<suitsmeveryfine>16 GiB
<suitsmeveryfine>But it can run the OS really fast from MicroSD
<mark_weaver>yeah, I don't know how much of a problem it would be in practice.
<suitsmeveryfine>Regarding u-boot: the depthcharge payload can be modified to chainload u-boot
<str1ngs>rain1: is there a doc for kernel building?
<mark_weaver>anyway, at this time I don't feel I can make a commitment to port GuixSD to it in the short term.
<suitsmeveryfine>mark_weaver: there are instructions for how this can be done on older chromebooks, but not on the c201. I'm not skilled enough to do it myself.
<suitsmeveryfine>I understand. Maybe I should ask in #parabola
<mark_weaver>I guess if someone from Parabola is ready to jump on this, maybe it should go to them.
<str1ngs>If I had chromebook I would look at it :)
<str1ngs>I think guix is good candidate for chrome books. does HOME allow for exec :)
<mark_weaver>the other thing is that the wifi needs a nonfree blob, and the GPU needs a nonfree driver, which makes the machine less interesting to me.
<mark_weaver>I was close to jumping on that bandwagon, but then had second thoughts.
<suitsmeveryfine>mark_weaver: that's true. It does work well with a USB dongle though
<suitsmeveryfine>another problem with it is that it seems to require a custom kernel
<optikalmouse>same, that's why I'm looking at the thinkpads the older ones, X200? T-something or other, I think they're all free now?
<suitsmeveryfine>so you'd be dependant on chromium os
<mark_weaver>suitsmeveryfine: well, we could add a custom kernel with additional patches on top of linux-libre, like I did for the Lemote Yeeloong 8101B
<str1ngs>optikalmouse: I have a x220 its awesome
<mark_weaver>(on the wip-loongson2f branch)
<str1ngs>but not free wifi :(
<str1ngs>needs kernel blobs
<optikalmouse>str1ngs: can be fixed with extrenal wifi right?
<davexunit>str1ngs: I use an x220 with a freedom friendly wifi chip
<suitsmeveryfine>mark_weaver: OK, but the problem is deblobbing.
<optikalmouse>davexunit: which chip
<str1ngs>how are are those to get and installl?
<davexunit>at the time, it required flashing a hacked proprietary BIOS
<petter>wifi affects our bodies in bad ways though, use wired network
<str1ngs>optikalmouse: yes, but dongles are a pain
<davexunit>but now I hear that you can use coreboot instead
<mark_weaver>str1ngs: and it has a processor embedded in the chipset that's running a complete proprietary operating system with independent network access, direct access to all your RAM, and designed for remote supervisor access.
<str1ngs>but the notebook is greal linux machine for the price
<davexunit>not libreboot, unfortunately, because of what mark_weaver notes.
<mark_weaver>str1ngs: see
<mark_weaver>if that doesn't send a chill up your spine, you haven't learned enough about it yet :)
<str1ngs>or chromebook?
<mark_weaver>str1ngs: x220
<str1ngs>sound kinda paranoid to me :)
<optikalmouse>can't win in the hardware game apparently
<suitsmeveryfine>str1ngs: you could get an allwinner A20
<suitsmeveryfine>free software + free hardware documentation
<davexunit>I'm hesistant to buy anything from allwinner
<davexunit>known GPL violators
<suitsmeveryfine>right, but they've started to behave lately
<mark_weaver>str1ngs: it's not paranoid, this is undisputed fact. it's a documented "feature"
<suitsmeveryfine>they've released all the u-boot and linux sources now I think
<davexunit>indeed, it's a very scary "feature".
<str1ngs>well guys thanks for the info.
<optikalmouse>what's the min. memory I can get away with for running guixsd? is a 10gb hard drive big enough or?
<str1ngs>what are the specs on the allwinner A20?
<suitsmeveryfine>2x 1 Ghz ARM 32 bit, 1 GB RAM, Gbit ethernet
<str1ngs>I need i7 or Xeon
<suitsmeveryfine>this thing can't even play video
<suitsmeveryfine>but I use mine to play music for me. It works great with mpd.
<suitsmeveryfine>It's more powerful than the beagle bone black
<fhmgufs>The development of the Raspberry Pi is great - they even have contracts with Broadcom for special chips. I don't understand why they don't use their power to enforce Broadcom to free these old firmware files.
<fhmgufs>If that would be possible this Board would be so good :(
<str1ngs>so who was giving away a chrome book?? :P
<mark_weaver>rain1: you might want to run: guix config "YOUR REAL NAME"
<petter>Martin Pall about health effects from wireless radiation,
<mark_weaver>rain1: looking at <>, I just noticed that you show up as "rain1" where others show their real names.
<mark_weaver>str1ngs: have you made any contributions to Guix yet?
<rain1>mark_weaver, is it ok to stick with how I have it? That's my default set up
<mark_weaver>str1ngs: or demonstrated an ability to do the necessary tasks here?
<rain1>Well I should set it different for guix
<mark_weaver>normally I wouldn't ask such questions, but if you're trying to get a free computer to do a job, and deprive Parabola of one, it might be good to know whether there's reason to have confidence that you can and will do that job.
<str1ngs>I've only been using guix less then a week. I'm not setup to contribute code yet. But I have stuff on my TODO
<mark_weaver>rain1: I guess it's not important
<str1ngs>right now my giving back is purely IRC support :)
<mark_weaver>str1ngs: okay, I don't think you're yet in the position to promise to port GuixSD to a new architecture and machine, then.
<str1ngs>I'm talking notes for the LD_PRELOAD idea
<suitsmeveryfine>Actually, I'd be happy to work on the machine myself, but the trouble is that so few people have one so it's hard to get help.
<str1ngs>I'm in the middle of porting it to s390x and powerpc64le
<fhmgufs>petter: What is he saying there?
<petter>fhmgufs: that wireless radiation (wifi etc.) has bad effects on our bodies.
<mark_weaver>str1ngs: sounds nice!
<petter>use wired network
<fhmgufs>petter: Yes, I know, but are there some new studies or sth like that?
<fhmgufs>I'm currently not able to see videos (compiling)
<suitsmeveryfine>mark_weaver: I rebooted and lost what you said above above what file to edit for xorg. Do you mind repeating?
<fhmgufs>petter: But I think that there's so much radiation already that (if you aren't using mobile phones constantly) it can't be worse by your fault.
<petter>fhmgufs: exactly how this affects our bodies is pretty new to us civilians, the military has studied it for 30-40 years
<mark_weaver>suitsmeveryfine: if you're running 'guix' from a git checkout, then the easy way is to add the relevant bits into the strings in 'xorg-configuration-file' in gnu/services/xorg.scm
<petter>fhmgufs: distance is very important when it comes to sources of radiation.
<suitsmeveryfine>thanks. And by "relevant bits" you mean what exactly?
<mark_weaver>it's terrible that we're forced to use microwaves for this stuff. we only use it because the rest of the useful spectrum has been allocated for other things, and microwaves were not of much interest because they're absorbed by water
<mark_weaver>suitsmeveryfine: the contents of that 50-synaptics.conf file
<fhmgufs>petter: Interesting, because I have seen a study on plants that happen to grow in a extrem way near wifi senders because of the higher temperature. And I already thought that this is bad for humans, too. (danger of cancer etc.).
<suitsmeveryfine>thanks mark
<fhmgufs>But didn't see a study on it. I'll look the video later.
<mark_weaver>basically, we had to use whatever dregs of the spectrum were left over after the commercial interests locked up all the best areas of the spectrum
<handsome_pirate>davexunit: Turns out someone else is already doing it.
<fhmgufs>But there are a lot of things the industry is doing to us for profit.
<petter>fhmgufs: yes, i've seen studies with plants as well. It's very obvious that radiation has an important effect on them.
<davexunit>handsome_pirate: news to me
<davexunit>I hadn't heard of it.
<mark_weaver>and those dregs happen to be in a range that is efficiently absorbed by water, e.g. by *us*, and thus quite possibly dangerous to us
<handsome_pirate>davexunit: irc nick is lantw44,
<handsome_pirate>davexunit: their spec file looks pretty good, too
<petter>mark_weaver: it's known to affect us in bad ways, and it's pretty well understood as well now
<davexunit>handsome_pirate: I guess all we need to do is probe them to update to 0.10.0
<davexunit>handsome_pirate: sorry if you feel like your work has been wasted effort. I didn't know that this even existed.
<petter>there's no doubt that we're not hearing the full story from politicians and media
<davexunit>AFAIK no one has ever shared this with us.
<handsome_pirate>davexunit: neither had I
<handsome_pirate>davexunit: it's all good
<handsome_pirate>davexunit: I will note one thing with this:
<handsome_pirate>Fedora builds packages in an isolated chroot
<handsome_pirate>davexunit: (You say differently)
<handsome_pirate>davexunit: Fedora's builds are, theoretically, reproducable. I just do not believe that there are currently tests in place to check that, though that is one of my current projects.
<davexunit>handsome_pirate: all distros that I know of use chroots, so I didn't mean to suggest that Fedora doesn't do this.
<davexunit>but a chroot alone isn't enough. I don't know what else Fedora does, but Guix uses Linux namespaces to isolate further, and *only* allows access to explicitly defined input dependencies.
<davexunit>so it goes further than I've seen any other distro go.
<davexunit>(besides Nix, though Guix is even a bit more rigorous)
<davexunit>but both Debian and Fedora are working on reproducible builds, too.
<davexunit>so I also don't want to suggest that they won't achieve reproducibility.
<rekado>hmm, writing services is still difficult to me :( I get the general idea but the services we have are all so very different that it's hard for me to see how this all works together.
<rekado>(I don't mean shepherd services)
<ng0>heh. might be that getting the binary version into gentoo is more pain than to build from source. gentoo runs tons of QA correction scripts on binaries.
<civodul>rekado: what service are you working on?
<rekado>civodul: just a simple service to add
<rekado>the task keeps getting bigger
<rekado>I'm now writing a service to create and populate /etc/security
<rekado>because limits.conf sits in /etc/security
<rekado>but there might be other files in that directory, so I need a service for that dir.
<handsome_pirate>davexunit: so, I've got guix running in an F24 vm
<rekado>I also have "pam-limits-service-type" which extends "pam-root-service-type" (that part is easy)
<davexunit>handsome_pirate: that's great!
<rekado>it will also have to extend the new etc-security-service-type, I guess
<handsome_pirate>davexunit: alas, 0.9
<handsome_pirate>davexunit: I could do a rebuild
<davexunit>handsome_pirate: you can 'guix pull' to compile a new guix for your user
<handsome_pirate>davexunit: first, I just wanted to play with it
<rekado>civodul: I also have "pam-limits-service", which is just "(service pam-limits-service-type config-file)"
<davexunit>handsome_pirate: yeah, I hear ya. just 'guix pull' so that you can actually install stuff without having to build it all from source.
<handsome_pirate>davexunit: if I run that as root, would it do it system-wide?
<davexunit>handsome_pirate: no, just for the root user.
<davexunit>each user may use a different version of the guix client
<rekado>and I suppose that config-file would be passed to the extension of "etc-security-service-type"; but I'm not sure about this.
<davexunit>on my systems, I have the system-wide Guix, and then my bleeding edge development version that I use pretty much exclusively.
<rekado>civodul: I have a feeling that I'm doing too much; that this can probably be achieved with less effort.
<rekado>took me a while to get to this point as I'm searching through the existing services for guidance.
<handsome_pirate>davexunit: might not be a bad idea to do guix pull as root updates system-wide ...
<handsome_pirate>or have an option for that
<handsome_pirate>sort of like pip
<davexunit>well, not sure about that.
<civodul>rekado: i think this should be a single service that (1) extends pam-root-service-type with a procedure that adds where appropriate, (2) extends etc-service-type with a "security" entry for /etc
<civodul>does that make sense?
<civodul>when you're done, we'll have to work on this API based on your feedback
<rekado>not sure about 2: not only do I need the "/etc/security" directory but also at least an empty "/etc/security/limits.conf" by default.
<rekado>I'm looking at "file-union" right now, which contains a gexp to create a directory and symlink files
<rekado>I suppose I could have a computed-file expression for "limits.conf" nested inside of a computed-file expression for "/etc/security"
<civodul>i suggest doing only (1), and when that works starting with (2) ;-)
<civodul>but yeah, you need a 'computed-file' that creates 'security' with an limits.conf inside
<rekado>I think I'm done with (1) already, but this would crash PAM as the config file must exist (even if it is empty)
<civodul>like (computed-file "security" #~(begin (mkdir #$output) (call-with-output-file (string-append #$output "/limits.conf") ...)))
<civodul>ah ok
<rekado>I guess I'm primarily confused about argument passing.
<rekado>by the time I have found the code that illuminates how the plumbing works I forgot what I wanted to do...
<rekado>it's just a tad too dense for my tired brain :)
<rekado>civodul: thanks for confirming my approach
<civodul>rekado: good :-)
<davexunit>the former emacs maintainer is working on a distributed issue tracking system
<davexunit>hmm, said this before looking at the code.
<davexunit>seems to be just one big bash script right now
<rekado>davexunit: in a past project I used this:
<davexunit>rekado: how did it work?
<davexunit>I could use a bug tracker for my personal projects
<rekado>davexunit: bugs are stored along with the git repository.
<davexunit>rekado: that's nice and simple, I could dig that.
<davexunit>I'd prefer a separate repo, though.
<rekado>here's a tutorial:
<rekado>it creates a separate directory for its state, so you could break that out into a subtree.
<civodul>yeah at one point distributed bug databases became the "hot" thing and there were several such projects
<civodul>bugseverywhere looks cool