<codemac>mark_weaver: it appears that nix generates some alsa config file that contains their paths, and they use that + a big patch around having multiple paths in that config file. I think the environment variable will be easier, just still need to hack in multi-path support.
<efraim>according to phoronix, qt 5.6 is going to drop webkit
<xd1le>in guixSD. if for example i have a shell script with a `#!/bin/env bash`
<cpjjl>which I don’t understand. How can boot be encrypted as well?
<cpjjl>quote: “And i'm now only using one partition (which includes root and boot)”
<cpjjl>To me it seems like /boot should contain the necessary stuff to decrypt /, and therefore it shouldn’t be encrypted
<cpjjl>Other question: is there a way to do something like “guix system init /mnt/etc/file.scm /mnt”, but without re-downloading and re-installing everything, i.e. if only /boot/grub/grub.cfg needs to be updated
<cpjjl>(so I can fix my issue #1 without losing 30min every time I try something…)
<rekado> cpjjl: if you have an initialised system and you just want to update it (e.g. after modifying /etc/config.scm) you can just do "guix system reconfigure /etc/config.scm".
<rekado>xd1le: for bootstrapping problems this kind of approach is normal. The best case is to have an inefficient implementation of a compiler for the core language (written in a language that doesn't require much more than a C compiler) and use that to build the efficient compiler.
<iyzsong>rekado: thank you for packaging various music packages, I start learning guitar recently.. they're really handy :-)
<rekado>with Java that's what we're doing. We use GCJ which can just barely be used to bootstrap IcedTea, which then uses the IcedTea bootstrap built by GCJ to build a nicer version of itself.
<rekado>iyzsong: glad to hear it! Thank you for all the GTK stuff without which I wouldn't be able to use GuixSD at all :)
<rekado>playing with guile-emacs (via the Guix package) again, I see that it loads el files from source during startup. Could the startup time be shortened by compiling everything under $out/share/emacs/*/lisp/?
<knicklux>hi there, i'm installing guix on arch via the aur and it's building at the moment, now running the unit tests. FAIL: tests/guix-package-net.sh is at the moment the only test that failed and since PASS: tests/guix-package.sh it seems stuck. is it expected to take a very long time?
<civodul>knicklux: the first time you run it, it can take a few minutes
<knicklux>i'll have to split test-suite.log to paste it, but i'll find a way. should i write to firstname.lastname@example.org? could be a bug in the pkgbuild file too (it contains the build instructions for my pckage manager)
<knicklux>in the latter case i should also inform the maintainer
<civodul>knicklux: maybe you can first discuss it with the AUR package maintainer, and then send it to email@example.com if needed
<knicklux>offtopic hint: the large logfile can be easily dealt with tar and base91 :P
<knicklux>i wrote him, you'll hear from me again when there are new news ;)
<lfam>civodul: I made some progress on building recutils with readrec. But you are right, bash:include is missing some of the necessary headers. Currently, the build fails due to a missing stdc.h, which comes in include/ in the bash tree. But I don't know how to alter the bash package definition to copy this file into the proper place.
<lfam>The comparable Debian package (bash-builtins) provides a lot more than bash:include. But again I'm out my depth when it comes to understanding what they have done and whether it is appropriate to apply it here.
<mark_weaver>knicklux: using the word "pastebin" as a verb is a powerful advertisement for them, and yet they have long implemented a policy of blocking all Tor users outright.
<mark_weaver>if we want to retain the right to browse the internet without enabling mass surveillance and censorship, we must retain the right to use things like Tor, and that in turn requires creating a strong disincentive to website operators blocking Tor.
<lfam>sneek: later tell civodul: I made some progress on building recutils with readrec. But you are right, bash:include is missing some of the necessary headers. Currently, the build fails due to a missing stdc.h, which comes in include/ in the bash tree. But I don't know how to alter the bash package definition to copy this file into the proper place.
<lfam>sneek: later tell civodul: The comparable Debian package (bash-builtins) provides a lot more than bash:include. But again I'm out my depth when it comes to understanding what they have done and whether it is appropriate to apply it here.
<lfam>sneek: later tell civodul: You can see what I think is the relevant part of the Debian Stretch package starting on line 254 of this paste of the debian/rules for bash-builtins: http://paste.lisp.org/display/156705
<goglosh>ACTION somehow managed to get guix back in his pc
<codemac>it really feels like a "profile" is something a package should be able to reference, though I realize that would just make all of guix a source distribution (and compile locally) distribution.
<davexunit>huh? profiles are at a different layer of abstraction.
<mark_weaver>codemac: are you suggesting that it would be good to have to recompile 'alsa' and everything that depends on alsa every time the user changes their profile in any way?
<mark_weaver>anyway, profiles are collections of packages. having packages also depend on the profile they are contained within would be a circular dependency.
<mark_weaver>it would also mean that users couldn't share packages, since each package would contain a reference to the user's profile
<codemac>I'm not saying it would even be good.. just thinking outloud. It always feels like I'm fighting a core UNIX principle, which is paths having meaning. The only place in guix where they do is in the profile, so it has me musing on what it would be to have packages depend on paths
<codemac>or maybe represent a path as a installable package itself
<codemac>I dunno, maybe my coffee is psychadelic today lol
<goglosh>^ I too think there is something very much non-unix here
<goglosh>but, uh, are profiles objects like packages and.. OSs are?
<codemac>which is fine as far as what value unix provides if it can't solve the "functional packaging" problem.
<davexunit>the "UNIX philosophy" can safely be ignored for the most part.
<codemac>I run linux, and it's certainly not a UNIX. Heck, debian just gave up the LSB.. I'm just thinking about "paths". We have all these environment variabse to instruct things where to look in the profile, but then turn around and say that packages can't inpsect or understand profiles.
<davexunit>because a profile is a container for packages
<davexunit>packages having knowledge of profiles would be a serious design mistake
<mark_weaver>if you have a better proposal that preserves the key features we provide, I'm all ears :)
<codemac>So maybe that's my question then - what is the main goal of a profile? A good example of something that scares me is I have gcc-5.2.0 installed in my profile, but half of the programs in the same profile are linked against 4.9, this can cause ABI issues with C++
<codemac>Yeah, and I'm not trying to be destructive, maybe I just need to think more about exactly what feature / value I feel is missing.
<mark_weaver>hmm, there are over 700 queued armhf builds, and only one is active. I wonder why.
<codemac>Maybe that's what I should focus on - is there a way, given a set of say 7 packages, to say that I want to dictate what packages the 7 of them are allowed to depend on? Like, "only gcc-5.2.0" or much more notably "my custom version of gcc".
<mark_weaver>codemac: each package description specifies the "inputs" to that package, i.e. the things it depends on. what would you suggest we do if the user says "you're not allowed to depend on package FOO", when FOO is specified as an input to that package? (possibly indirectly)
<mark_weaver>codemac: you seem to want to redesign guix at a deep level.
<codemac>Not entirely, I think what I'm accidentally describing is the nix channel concept
<goglosh>guys where is the source code in my system?
<mark_weaver>goglosh: "guix build -S <package-name>" will output a path to the source code, downloading it if needed.
<codemac>as in - sure, there may be things that wont work and they should just fail, but saying "this hydra here builds only with gcc-5.2.0" and maybe drives improving or modifying other packages to work with that I don't think is a redesign on an entirely deep level
<codemac>I'm not trying to troll or distract, I apologize if I have a misunderstanding of a deep goal of guix
<mark_weaver>codemac: this is probably a discussion to have on the mailing list instead, and I would encourage you to try to think through the consequences of your suggestions and try to come up with concrete proposals.
<codemac>Ok, I think I'm just talking out loud about the nix channel concept, I'll research what they do more fully and see if I have a concrete proposal at all.
<codemac>and I'm so bad about updating my patches, I get such quick and good feedback on guix-dev. Need to do that this afternoon.
<codemac>Do people here use `git send-email`? Maybe that can speed up my response time.
<codemac>I'm used to gerrit where it's all `git push` and tracked in a branch. git send-email I think would let me reproduce some of that, need to see if I can't embed the Thread-ID from notmuch into a git send-email from magit :)
<mark_weaver>(although I confess I just run "git format-patch" and then send the resulting files as attachments)
<codemac>yeah, I've been doing the git format-patch thing as well, have lots of 0001-stupid-idea.patch files in my guix dir :)
<codemac>I wish gerrit was licensed gpl so it was more populare with gnu projects, really enjoy it's workflow for code review. I think it's apache right now.
<codemac>nice! git send-email takes an --in-reply-to
<civodul>mark_weaver: should we merge core-updates?
<sneek>civodul, lfam says: I made some progress on building recutils with readrec. But you are right, bash:include is missing some of the necessary headers. Currently, the build fails due to a missing stdc.h, which comes in include/ in the bash tree. But I don't know how to alter the bash package definition to copy this file into the proper place.
<sneek>civodul, lfam says: The comparable Debian package (bash-builtins) provides a lot more than bash:include. But again I'm out my depth when it comes to understanding what they have done and whether it is appropriate to apply it here.
<francis7>Emulatorman, that would be nice. depthcharge is cool, but I'm used to GRUB.
<francis7>In that case, I'd offer ROM images with GRUB or depthcharge, so people can choose.
<mark_weaver>GuixSD's system-wide roll-back functionality, which is rather important for us, depends on a bootloader that supports some kind of menu to boot into older versions of the system. I'm not sure if depthcharge is workable for this.
<mark_weaver>so, getting GRUB working on the c201 would be rather important for GuixSD.
<codemac>gummiboot has support for this type of thing as well, but it was merged into systemd-boot :(