<myglc2>I think I just observed that one can rearrange a .scm file to make it prettier (e.g., comments or order) and that such a change does not cause the package to be rebuilt. Am I hallucinating, or is this how it works? TIA
<mark_weaver>there's a procedure that takes a package definition and creates a "derivation" out of it. that's the .drv file. the .drv file is the only thing the guix-daemon sees when asked to build it. if the .drv file doesn't change, then the package doesn't need to be rebuilt.
<myglc2>That is so cool. How do I propose an enhancement patch for an existing .scm?
<mark_weaver>okay, so commit the proposed changes in your local git repo with a commit log that conforms to our conventions (see the log for examples), and then send the patch to firstname.lastname@example.org is the format produced by "git format-patch -1"
<kristofer>that's what I've been trying to get to the bottom of.. it will require a system reconfigure
<lfam>mark_weaver: I'm continuing to work on the python-3 bytecode timestamp issue from a couple days ago. The more I think about it, the more I think that patching Python to make all the bytecode have a "epochal" timestamp is the wrong thing to do. And I think that making the Python build system set the timestamps of unpacked Python source code the right thing. My question is, is there a danger to discarding upstream's timestamps like that?
<lfam>In general, do upstream projects ever use the timestamps of source files when building in a way that would break stuff if we reset the timestamps?
<lfam>I plan to say this in the bug thread but I wanted to get a "sanity check" before I write the email
<kristofer>do I need to run guix system reconfigure as root?
<paroneayea>I don't see where it uses setuptools / etc, which is what I expected
<mark_weaver>Jookia: the plan is to distribute substitutes over Gnunet, and that would include the sources as well.
<mark_weaver>of course, we should try to convince the upstreams to allow Tor connections. I'm surprised that GNU's ftp site would block Tor. I doubt that was the intent; it's more likely that some exit relays are getting automatically blacklisted for some time because of attempts to break in from those IP addresses.
<mark_weaver>if they really are blocking Tor, I could talk to RMS about it. I'm sure he would be against blocking Tor.
<pizzaiolo>I asked for guixSD to download icecat and for some reason it's installing a whole bunch of unrelated stuff, like binutils and linux-libre
<mark_weaver>pizzaiolo: yes, run as root. make sure to either run "guix pull" as root also (in addition to your user account), or make ~root/.config/guix/latest a symlink pointing at ~USER/.config/guix/latest, where USER is the user you normally run "guix pull" as.
<Jookia>mark_weaver: Me either, but most distros I know of switch from text mode to kms+drm when booting- Guix doesn't seem to. Not sure how (maybe a module option?), it'd be useful for people that don't have a working screen in Libreboot/GRUB but it does work in Linux
<mark_weaver>Jookia: are you talking about the graphical boot process, i.e. plymouth ?
<Jookia>Perhaps- It's not by default in NixOS so maybe there's some magic detection glue that should be added to cover this for things like Noveau too. Though Debian and Arch both recommend explicitly adding the module
<Jookia>I think documentation is warranted at the least, so I'll see what I can do about that
<Jookia>I guess the 'solution' in Guix to most problems is 'package it' which doesn't work very well for things that don't involve installing things
<wingo>Jookia: so i can understand the argument for not having any /bin or /usr. but i also understand that once you start adding to /usr there is no logical stopping point, and for development you need more than /usr/bin/env usually
<Jookia>wingo: logical stopping point is making a distro that's usable for most tasks
<wingo>so the real solution for most development is containers and mapping a profile to /usr in the container
<lfam>No, that's true. Although there's no reason you couldn't make a shell-build-system that trivially copied the script into the store and set the right permissions
<Jookia>civodul: I think /usr/bin/env should exist in containers- we can specify dependencies there and teach people to wrap their scripts maybe- but not at all means there's a huge amount of breakage. Throwing away compatibility with other distros for no gain at all is really weird
<wingo>man, it's cute when guix newbies like me have opinions innit :)
<Jookia>I want to get my libreboot? patch put on the mailing list in the next hour but I can't test it :(
<lfam>Really, a security critical shell script that just relies on absolute paths for its reliability is just one mutable-usr-operating-system upgrade away from falling over. That's one situation where it would be worth it to port the script to Guix.
<Jookia>lfam: True but not everyone runs Guix and the problem is that writing code for both Guix and normal systems is a little more difficult now
<lfam>Oh, okay. I was going to point out that there are many package in Guix that have shell scripts inside them and they all work fine. So you might look in there for some examples of how this can work.
<boegel>civodul, rekado: there's bad news too though... it seems like part of the Guile talks are missing, the recordings only start at 12:20 or so, i.e. during the Q&A part of rekado's talk :(
<lfam>If I had a large project and I wanted to be able to build it reliably, and effectively manage the relationships between the zillions of dependencies, I would develop it for Guix or a system like it. Developing it on a traditional distro such as Debian requires you to manage the state of all the dependencies, without having the tools to do that build into the system. But of course he is the one working on the big project, so that is my
<lfam>And one usually doesn't have to repackage something just to recompile. Not until you make some change to the build process would you normally need to touch the packaging.
<Jookia>'Have everyone use Guix' isn't a solution to 'I can't write code for both normal systems and Guix'- and I imagine 'normal systems' would be chosen instead of Guix
<lfam>I just don't see the large barrier. Most of our packages are only changed by automated processes in the build process. There aren't many Guix specific changes, at least to leaf packages. And all distros have to make distro specific changes to core packages.
<Jookia>That doesn't seem like an appropriate response to 'Guix breaks a commonly established workflow'- on Arch I don't make a PKGBUILD for every piece of software I download and develop. The proposed solution seems like something I could fix in a day (if Git worked)
<civodul>boegel: re videos, yeah, i read they had recordings only starting from "lunch time" :-/
<civodul>boegel: anyway, thanks for helping out with videos!
<boegel>civodul: I'm happy to help any way I can with FOSDEM stuff, such a great meetup
<Jookia>mark_weaver: civodul: libreboot? patch should be in guix-devel now
<Phlogistique>Suggestion: use binfmt_misc to handle binaries that start with #!/usr/bin/env with the user's env
<sneek>fhmgufs, mark_weaver says: if a package wants to install its gir data into an existing store directory, you need to modify it to install the gir data in its own package output directory. see the grilo and libgee packages in gnome.scm for examples, but the fix might be somewhat different in your case.
<taylan>(game console emulators all seem to have strange build systems, presumably because the community is half programmer half multimedia oriented, and partly MS Windows oriented, so they're not keen on all the best practices...)
<mark_weaver>civodul: did you try building gnupg-2.1.11 on your machine?
<mark_weaver>civodul: is there a way to find out which slave built a given package?
<mark_weaver>we really need that, IMO. for example, we could see if non-deterministic build failures like internal compiler errors (which happen fairly often) are correlated to a particular machine, maybe that machine has bad RAM.
<mark_weaver>and recently, a webkit build failed due to lack of virtual memory. I'd like to know which slave it was, but the information seems to be lost to me.
<mark_weaver>of the two failures on hydra where only the gpgtar.test failed, I can see that they were done different slaves, because the localstatedir is different (/var vs /usr/local/var) and one of them uses /tmp/nix-build-* and the other /tmp/guix-build-*
<civodul>if only we had Munin running on all the machines
<NiAsterisk>sorry for interrupting. I need to create an 'make install', I already found packages which can serve as a base for experimentation. I remember /usr/share/docs/'uniquename-version' as the dir for documents of all kind, and /usr/bin as the directory for executables to copy to?
<mark_weaver>fhmgufs: and see the "Contributing" section of the Guix manual.
<fhmgufs>I meant write access and if there is a kind of "qualification process".
<mark_weaver>fhmgufs: there's no official process, but generally we grant write access when you have submitted enough patches that we gain confidence in you, and when it becomes a burden to commit your patches :)
<NiAsterisk>system declaration is easy, for me coming from gentoo getting into packaging was difficult.. still is
<mark_weaver>pecg: one more note: we only recently added the needed crypto+hash modules to the default initrd, so you'll need to either add them manually to your OS config or run "guix pull" from the USB installer.
<davexunit>(nix actually cheats somewhat in this regard by using pre-built binaries in a number of packages)
<davexunit>speaking of pre-built binaries, I'm still quite concerned about Chicken Scheme including non-source C files for the compiler.
<pecg>NiAsterisk: I never got into ebuilds, I was using gentoo because of openrc and the compilation features, but they don't support deblobbing anymore and in order to use >= 4.0.9 kernels I have to add 'freedist' licenses, that I cannot do
<pecg>If it were the case, why don't fix them? and share the improvements
<davexunit>guile 2.0 (not guile, 2.0.11 or something new, but 2.0) is *masked* due to some problems that I'm unconvinced are problems.
<NiAsterisk>davexunit: and if you try to build guile 2, you break it so hard you end up with an unrepairable system (kind of why I ended up here)
<pecg>davexunit: And you will find a very hard day trying to update to 'unstable'
<pecg>The only reason I haven't changed to guixSD already was lvm, but today I convinced myself I can live without it, in fact I have never been in the need to actually use it
<NiAsterisk>pecg: because contributing to gentoo is not easy.. I prefer to work with projects who have some common goal with what I want, and guix serves more than just the distro and is free as in freedom :)
<pecg>NiAsterisk: Exactly, guixsd is a freedom commited distro
<mark_weaver>pecg: one more note regarding that draft guide: it was written for use on Libreboot machines, which include GRUB and grub.cfg burned into the boot flash, so even /boot can be encrypted.
<pecg>before gentoo I was on parabola, but I changed because of some problems I had with systemd.
<pecg>I cannot even count how much times I have had to install GNU/Linux and its different flavours, and as much as I enjoy the process, it is a pain in the ass, wether you are in apt, yum, pacman or portage, it is always a time consuming manual task
<pecg>declarative operating systems are the future
<mark_weaver>and I must warn you that installing Guix for the first time is far from streamlined, to put it mildly :)
<mark_weaver>especially when you're doing something unusual like you're planning to do.
<pecg>mark_weaver: I tried to do it in 2015 and failed
<NiAsterisk>so if I have (outputs '("out" "doc")) and later on in (arguments) I have (doc-dir (string-append doc "/share/doc")) and (doc-dir (string-append doc "/share/doc") (copy-file "Documentation/DevelopmentProcess.txt" (string-append doc-dir "/DevelopmentProcess.txt")) would that be a valid way to only copy that file when guix package -i lispf4:doc is called? it's a bit out of context, but basically that's it?
<fhmgufs>I'm currently wondering about the compiled glib settings schemas in my profile. There is one gschemas.compiled symlink to the store dir of one package, so the other package's schemas are missing of course. How do I fix this?
<bavier>ISTR that our downloader write only to RAM
<nckx>mark_weaver: yeah, it feels a bit hacky... A way to specify a local/network preference ratio would be better (e.g. even with GNUnet/HydraNG, my local connection might be as slow as my CPU) — as well as a total mess in practice.
<a_e>efraim: Yes, I keep the texlive sources also in my home directory, so as to be able to do a quick "guix download file:texlive-20150523-texmf.tar.xz" in case it gets garbage collected in the store.
<a_e>You could say that I am collecting texlive-texmf copies :-)
<fhmgufs>How do I get the version (major.minor) of another package?
<mark_weaver>roelj: better to make a custom phase that does the right thing.
<mark_weaver>if you want to see the default phase, it's 'build' in guix/build/gnu-build-system.scm
<roelj>mark_weaver: Thanks. That was my next question :)
<calher>OK, how did I boot GuixSD on Libreboot last time? The tips on the installation manual draft doesn't look like what I entered. Something about "cryptomount -a; set root=(ahci0,usb1); config /boot/grub.cfg"?
<janneke>i'm having trouble with running more recent guile versions in guix, how are you all doing that?
<janneke>i am trying guile-next, but it seems that .../guile/site/2.0/.. paths are used which hold conflicting guile-library .go's
<janneke>i would like to run something much more recent (git?), why do i not find that in the repo?
<calher>I thought the whole thing about Guix is that you can have different versions without conflict.
<mark_weaver>ah, after disabling https-everywhere and some other protection that icecat was doing, one time I got a brief glimpse of what appeared to be build statuses, but it's now I can't get it working anymore.