<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` <xd1le>efraim: do you mean the qt-webkit package? <efraim>looks like they're keeping qt-webengine with chromium but dropping qt-webkit <rekado>xd1le: since there is no /bin/env these scripts will not work. <rekado>you could create a link from /bin/env to /run/current-system/profile/bin/env, or you could change the shebang to #!/run/current-system/profile/bin/env bash <xd1le>efraim: this is pretty big news. thanks. <xd1le>i was actually hoping to package qt and qt-webkit at some point.. <rekado>(or to the actual path of the interpreter) <xd1le>efraim: oh sweet, you're right <xd1le>rekado: oh i think the first solution is simple enough. thanks. <xd1le>rekado: so basically the profile directory + /bin/env ? ***C_Keen is now known as C-Keen
***C-Keen is now known as Guest87036
<cpjjl>Hi. I’m trying to setup guixSD with an encrypted root (/dev/sda2), except for /boot, which is on a separate partition (/dev/sda1). <cpjjl>Not even sure it’s already possible. Anyway. I came across this post: ***Guest87036 is now known as C-Keen
<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". <cpjjl>update: I just realized the kernel isn’t copied to /boot, it’s in /gnu… and /gnu is encrypted… it couldn’t work <cpjjl>Got an answer to my first question: grub seems to be able to handle the decryption stuff by itself <cpjjl>which means I don’t need a separate unencrypted /boot partition <cpjjl>and if I recall well, grub is installed at the beginning of the disk, which isn’t encrypted anyway <xd1le>cpjjl: don't be sorry, it can always be helpful to others <rekado>I just noticed that our icedtea7 package still depends on icedtea6 to be built. <rekado>icedtea7 uses ant, which is built with icedtea6. <rekado>icedtea6 also uses ant, but there we use a binary bootstrap version. <rekado>got to try if ant can be built with the latest gcj instead. <efraim>sounds a bit like go, which now bootstraps itself <rekado>I think I've done this before and concluded that ant cannot be built with GCJ at the moment, which is why we ended up using the bootstrap ant in icedtea6. <xd1le>have you guys heard of the crystal language? <xd1le>bc it's compiler is also written in crystal... <xd1le>so to compile from source, you need old sources (in c i think) to compile <xd1le>and use that old compiler to compile a newer one and so on until the latest version... <rekado>huh, gcj actually compiled ant. It spit out 1200+ warnings, but it did compile it. <rekado>I wonder if I can use this ant to build icedtea now. <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 :) <xd1le>rekado: ah thanks. i wasn't sure if that's normal. <Steap>All packages on the list had already been built (so they were available in /gnu/store) <Steap>Still it took 9 minutes to run the "echo" command inside the environment <Steap>Is it this slow for everyone ? <Steap>It makes "guix environment" unusable in non-interactive mode <taylan>Steap: I never experienced 'guix environment' being that slow. I use it occasionally to get a build environment for Guile or Guix <civodul>Steap: i assume this is a pathological case; could you email bug-guix@ with the command? <Steap>civodul: yeah I might try to debug this a bit <Steap>for instance, I just ran "guix env" with a single package <civodul>but there might be something with propagated inputs <civodul>we had a similar pathological case in 'guix build', which bavier found out <taylan>ACTION tries the command in that paste <Steap>I wonder whether having a lot of packages in the environment could be the issue <Steap>taylan: remove python-{hacking,os-testr,tempest-lib} <Steap>they are not in master yet :) <taylan>oh I didn't even notice those are continuation lines <civodul>Steap: in the report, could you provide a command that works today? :-) <civodul>that is, with packages that already are in master <Steap>civodul: I donno, could you push the patches I'm about to send ? :p <Steap>ACTION patches guix and guix-tox so that the commands he'll show at PyCon actually work, and now has a ton of patches to merge :D <taylan>Steap: there doesn't seem to be python-os-testr in that list; did you mean something else? <rekado>just sent a couple of simple patches to update gcj, ant, and icedtea6 (security update). <Steap>taylan: oh no, then it's probably ok :D <Steap>just hacking and tempest-lib <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/? <taylan>rekado: IIRC there should be some mail by bipt on guile-devel which explains why compiled Elisp can't be serialized right now <xd1le>rekado: what is guile-emacs? <taylan>or maybe that mail was about another issue. in any case I think it was Elisp's string type. <xd1le>anyways i'm getting sidetracked sorry. <taylan>Steap: 2:30 mins. on my i5 processor, after removing those two and also python-oslosphinx. certainly way too slow indeed. <Steap>taylan: does that include build time ? <civodul>i can reproduce the slowness with just a subset of the packages you gave <Steap>civodul: could it be possible that *one* package slows the whole thing down ? :p <civodul>i'm guessing it's something along the lines of commit 161094c <civodul>the problem is only with "python2-" packages, not with "python-" <civodul>because the former creates lots of duplicate packages <civodul>so we don't benefit from memoization <Steap>indeed, it is only 5 seconds with Python3 packages <civodul>we have an agreement with van Rossum that we'd give our large user base an incentive to switch <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 <civodul>because it builds a couple of packages <civodul>to see what's going on, run: tail -f tests/guix-package-net.log <civodul>could you please use paste.lisp.org or something like that? <knicklux>these are the output of the commands. looks like PASS: tests/guix-package.sh is finished to me :/ <civodul>so you need to see which process is running <taylan>knicklux: pastebin.com is a very bad paste site. you might want to use paste.lisp.org instead. <civodul>knicklux: there's a process doing "guix package --bootstrap -i glibc:debug -p t-profile-30" <civodul>there's a "-n" at the end, meaning it doesn't actually build anything <civodul>anyway, you could check the children of the 'make check' process <knicklux>question offtopic: how could i do something like "ps for each in (pgrep make)" in bash? :) <civodul>for p in $(pgrep make) ; do ps $p ; done <knicklux>the build just failed, i'll pastebin the results <knicklux>should i upload a tar of the logs or particular log files? <civodul>that explains which files are useful <knicklux>i'll have to split test-suite.log to paste it, but i'll find a way. should i write to bug-guix@gnu.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 bug-guix@gnu.org 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. <knicklux>offtopic: using startpage, you can use their proxy to visit a website and some website that block tor do not however block the startpage/ixquick proxy ;) <lfam>BTW that is from the package in Debian Stretch <mark_weaver>knicklux: rather than continuing to support pastebin and advertise for them, it would be better to boycott them. <mark_weaver>there are plenty of paste sites, and most of them don't block tor <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>thanks for the discussion mark_weaver <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>Welcome back civodul, you have 3 messages. <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. <civodul>mark_weaver: mips and arm are still a bit behind but hey <civodul>lfam: i think i actually looked at the contents of the Debian package when i added that "include" output <civodul>Steap: did you file that slowness bug? <mark_weaver>civodul: any idea why only one armhf build is active? is andreas' novena offline? <civodul>mark_weaver: yes i put Andreas' Novena off-line yesterday at his request <civodul>sorry, i meant to email guix-sysadmin but didn't <civodul>let me do that anyway, better late than never ;-) <mark_weaver>ACTION makes another attempt to get the wandboard quad running. <mark_weaver>now that I have the proper cables, I'm successfully at a u-boot prompt. that's good! <mark_weaver>now to get a hard drive connected to this thing, which does not supply power on its own. <efraim>speaking of arm hardware, libreboot now supports the a[cer?/sus?] c201 chromebook with the rockchip rk3288, and archlinuxarm.org gives a walkthrough for replacing chromeos with arch <efraim>$200 for 4gb ram 16gb "ssd" and 1366*768 11.6" screen <efraim>the real question is if the wife will let me buy another machine <francis7>(check libreboot.git logs, an ARM chromebook was added to libreboot, with more to come soon) <efraim>iirc the rockchip socs are in mainline kernel <efraim>don't know about the rest of the hardware of the machine <francis7>rebasing is fairly trivial most of the time, and I guess there are people maintaining that <mark_weaver>efraim: I intend to acquire a c201 and port GuixSD to it at some point. <mark_weaver>in the meantime, Guix should run on the c201, on top of another system <mark_weaver>civodul: the Asus Chromebook c201 is now supported by Libreboot. <mark_weaver>(well, in their git repo anyway, and the docs are lacking at the moment as well) <francis7>there are several of these in coreboot, they are being added to libreboot. one of them (ASUS Chromebook C201) is added already <francis7>We want to get FSF endorsed distros running on these laptops. libreboot currently recommends Debian/Fedora <mark_weaver>caveats: the built-in wireless needs a blob, and there's no graphics acceleration without blobs either. <francis7>but on the other hand, free EC firmware too <mark_weaver>but, it can be run without graphics acceleration, and you can use an ath9k-htc via usb. <francis7>so you can have more freedom in practise than on the other libreboot laptops <francis7>mark_weaver, not unusual. afaik all chromebooks have free EC <francis7>that description isn't really complete tbh, but should be fine <civodul>i didn't know Google funds coreboot development <mark_weaver>google wants control over the software running on their servers :) <efraim>i heard google uses coreboot on the chromebooks <mark_weaver>it's on the network, and sees the hard drive. proceeding with installation. <Steap>I'm trying to replace "/bin/ls" with (which "ls") in a "snippet" of a package definiton <civodul>yes, don't do that in a snippet, there's no coreutils in there <Steap>is there any trick I'm missing ? <mark_weaver>Steap: the inputs are not available from snippets, and IMO, it's not good to install hard-coded paths into the store from a snippet anyway. <mark_weaver>better to do that from a phase added after 'unpack'. <mark_weaver>or perhaps it would be sufficient to just replace /bin/ls with "ls" <Steap>mark_weaver: well, I had not thought of that <mark_weaver>although I'm still not sure something like that belongs in a snippet. dunno. <davexunit>civodul: I bumped geiser to 0.8. just changed the version string and hash. OK to push? <davexunit>now we can connect to Guile REPLs over UNIX domain sockets. <civodul>Steap: i really need a bug number to put in the commit log :-) <Steap>I'm reviewing 12 patches right now :D <mark_weaver>civodul: it's been 3 days since a successful evaluation on hydra. the evaluation of 'master' just failed in demo-os.scm with "Unbound variable: dbus-service" <civodul>mark_weaver: yes, i've just fixed it locally <Emulatorman>francis7: cool! i let coadde know about it to give for GRUB ARMv7 porting for Asus Chromebook c201 with libreboot <mark_weaver>looks like grub now supports the "arm-uboot" platform, but not yet on arm-coreboot. <Emulatorman>mark_weaver: we are porting GRUB for all SoCs devices in Parabola, i hope "arm-coreboot" could be added for GRUB soon <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 :(