<ng0>I have two more ksh which I will send soon <lfam>How can I run the guix-daemon out of my Git checkout? I tried `sudo -i /path/to/src/pre-inst-env guix-daemon --build-users-group=guixbuild` but it fails like this: http://paste.lisp.org/+7HRU <lfam>I added guile2.2-gnutls to my environment since it complains about not finding the Guile GnuTLS bindings but it still fails <lfam>It does seem to work if I don't need to build anything <rain1>oriansj: ah, M1 has global symbols (like %main) that get linked/ <rain1>well i got some unwanted PMs from mekeor. <reepca>in nix/libstore/build.cc, it says "only directories can be bind-mounted", but it seems to work fine in my command-line tests, and I can't find any documentation about that limitation. Any ideas? <reepca>in fact in that same file they bind-mount /etc/resolv.conf, so I guess some documentation must have gotten outdated <sneek>janneke, you have 1 message. <janneke>and i already liked hex2 so much better than directly->binary or even mes's lambda's :-) <rekado>is there a way to add a kernel module into the initrd without having to rebuild the system? <rekado>I have installed the system but it fails to boot. It boots fine with the USB image. <rekado>the problem appears to be a missing “sata_nv” module in the initrd for the built system. <rekado>I’d just like to regenerate the initrd and replace the one for the installed system so that I can boot it and reconfigure. <rekado>doing it the hard way now: boot into USB disk, bind mount /mnt/gnu to /gnu, run REPL, build derivation from REPL… <efraim>I need to talk to #linux-libre about getting an arm64 config <rekado>I don’t understand why Guix rebuilds gmp even though the installed system already has it. <rekado>I bind mounted both /mnt/gnu to /gnu and /mnt/var/guix to /var/guix, and restarted the daemon <rekado>the reason why I bind-mounted these directories is so that I can use the installed version of Guix (which is much more recent than 0.13.0) <rekado>“guix pull” would build a lot of things from source, indicating that substitutes for 0.13.0 are spotty on hydra. <rekado>we should get a new release out soon and make sure that substitutes are retained on hydra. <rekado>in other news: I’m trying to set up a few build servers for hydra today. <rekado>civodul: it looks like hydra lost a couple of 0.13.0 substitutes. <rekado>there are not enough substitutes for “guix pull” on 0.13.0. <efraim>i'm trying to figure out how other distros manage to build julia on aarch64, if its only on the super expensive boards or if I'm missing something <civodul>rekado: ouch, do you have examples of missing store items? <efraim>does python2-shedskin build on other arches? <efraim>i'm getting 'error: unknown value ?native? for -march' on aarch64 <civodul>we shouldn't use "-march native" in general because that can use ISA extensions found on the build machine <rekado>civodul: I’m installing another of these servers now and will take note of the items that have to be built from source when doing “guix pull”. <rekado>it would be sweet to have guix ops at this point <rekado>maybe I’ll just take an image of the first successfully installed server and apply this to all other machines <civodul>rekado: i think it's safer to do the full install on each of them <rekado>jsierles: it’s a new-ish server that was meant to replace hydra. <efraim>is there a reason we get numpy from github and not pypi? <rekado>“guix pull” causes the following sources to be downloaded: gnu-ghostscript, freetype, gcc-5, jpegsrc.v8d/v9b, lcms2, libpaper, mpc, etc <rekado>ACTION fetches substitute from the local cuirass server <civodul>rekado: can you copy paste the file names? <jsierles>is that because there are no substitutes available? <rekado>I’m considering to use “guix archive” to export a recent guix from a different machine and apply that on the server instead of running “guix pull” <jsierles>thinking now just to setup our own substitute server and start building stuff there <jsierles>rekado: so guix pull would always build? <rekado>civodul: it’s possible that some of these items in the list above were actually just not baked. <rekado>civodul: I just got a gcc-5 substitute after trying again. <civodul>rekado: if you try again you'll probably get more substitutes <civodul>i've just made a checkout of version-0.13.0 to see what the status is <catonano>why did Bayfront die again ? What's the problem, this time ? <rekado>catonano: if we knew exactly what the problem is, we could probably fix it more quickly. But investigating this always takes a lot of time. <rekado>catonano: you didn’t do anything wrong :) <catonano>I'm sorry for Bayfront. Guix sorely needs an upgrade in the build hardware. It also need its devs not to dedicate their time to troubleshooting hardware failures :-/ <rekado>I’m a little bit worried about the shared store we have here. <rekado>there are quite a few empty directories <rekado>permissions on them are weird: dr-x------+ 2 root root <rekado>e.g. /gnu/store/h37467f9k4p1sxgky430kpzmshkdvhf1-fonts-dir <rekado>they look normal, but they are all empty <rekado>also /gnu/store/mp11vshlwhh7lpm5anvf28l527h1lgvy-nautilus-3.18.2 <civodul>but are they in the ValidPaths table of the database? <civodul>for instance does "guix gc --references" work on them? <rekado>no, they are not considered valid ***kelsoo2 is now known as kelsoo
<civodul>rekado: also i think hydra.gnu.org times out right now, which may be why you don't get substitutes <rekado>“guix pull” finished; on to system init <efraim>'guix pack guix' is the new method for making a binary install tarball? ***octe_ is now known as octe
<reepca>"It is this mechanism that is used to create Guix’s own standalone binary tarball" - 3.7 (Invoking 'guix pack'). I don't know if that's the exact command used, but something like that I would guess. <efraim>i found 'guix-binary.%.tar.xz' in Makefile.am <jsierles>can the daemon be given a specific path for the work it does while building? looking to move everything to SSD <rekado>jsierles: doesn’t it just use TMPDIR? <rekado>I set TMPDIR a long time ago when I had limited disk space. <jsierles>"When the daemon performs a build on behalf of the user, it creates a build directory under /tmp or under the directory specified by its TMPDIR environment variable" <rekado>jsierles: don’t you use the excellent Info manual? <rekado>“2.4.1 Build Environment Setup” mentions TMPDIR <rekado>Guix comes with a manual in Info format. <rekado>the sources are written in texinfo format <jsierles>i found it on the page. just skimming it i didn't notice that section. TMPDIR was the keyword <rekado>this is the second server with hard disk problems <ijp>it's a misdemeanour, not a felony <rekado>“Device offlined - not ready after error recovery” <rekado>not sure if this is a driver problem or a problem with the disk controller. <oriansj>rain1: please join #bootstrappable most of us are already there discussing <ng0>jsierles: well info can be used without emacs <rekado>you can also use emacs as an info reader. <rekado>another common problem with these servers: “usb 1-8: reset high-speed USB device number 3 using ehci-pci” <jsierles>web also has a cool feature where you can send links to documents <rekado>and then the live GuixSD disappears. <rekado>jsierles: you’re missing out on the index <rekado>the index in the web version is terrible. <rekado>arguably that’s a problem with the HTML export of texinfo, though <reepca>as far as I can tell from my reading of nix/libstore/build.cc, when chroot is enabled, the build happens in the store. <reepca>or rather, in a <drv-name>.chroot directory in the store <reepca>the reasoning given is so that hard links from the chroot to non-directory store items are certain to be possible, because apparently bind-mounting non-directories isn't possible... <civodul>rekado: could it be that the usb stick is problematic? <civodul>i have a USB stick that can be password-protected and all, but it disappears from time to time and you have to press a button on it <reepca>so I don't *think* that changing TMPDIR will allow you to use the SSD for building stuff (if I understood what you meant correctly) <reepca>unless you run the daemon with chroot disabled <civodul>reepca: no i think the part of the manual that was quoted earlier is correct <jsierles>reepca: it's OK, the store will also be backed by SSD <civodul>that is, you can do "TMPDIR=/tmp/foo guix-daemon ..." and it will use /tmp/foo as its temp dir <civodul>however, the name of build directories inside the chroot will always be "/tmp/guix-build-foo.drv-0" <jsierles>i'm curious, how much space does hydra's store use? <civodul>jsierles: currently 1.3T but that's for 3 architectures <rekado>here’s an error running “guix system init”: guix/ui.scm:1264:8: In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f <rekado>it’s a result of primitive-load’ing something from /gnu/store/azdrj6…-guix-0.13.0-1.a6d728b/ <civodul>rekado: does it come from 'guix substitute'? <rekado>this server’s CMOS battery is down <jsierles>if you guys change your mind about cloud hosting, let me know ;) <ng0>civodul: the suggestion to use just what .bashrc skeleton provides on GuixSD (the if-case for sourcing /etc/profile) does not work. Now ssh host env | grep "GUILE_" is empty <ng0>this is with bash on all systems <ng0>I know that it should work, and I should have GUILE_ and everything this way, but it doesn't <ng0>I think this was part of the reason why I added the manual sourcing of ~/.guix-profile/etc/profile <ng0>I'll just add the part when I get (guix) from to the variable <ng0>but just following the documentation, this is the problem I see with offloading. the described way doesn't work. it was an accident that it used to work for a while for me 1.5 years ago <roelj>Is anyone interested in/working on deep learning packages like TensorFlow for Guix? <rekado>roelj: but TensorFlow requires bazel <rekado>I actually wanted to take a break from packaging Java things <boskovits>I am trying to package thrift, and I have a problem with running tests. <jsierles>do i need to version/track anything in /var/guix besides the db folder? <boskovits>It seem to be, that the reason is a shebang #!/usr/bin/env python <roelj>rekado: Bazel is a build system, isn't it? <roelj>rekado: Maybe it's quicker to rewrite the build system than it is to package Java stuff ;D <roelj>rekado: Nevermind.. I just looked at the 'BUILD' files.. <rekado>good news is that most of the third party jars have already been packaged. <civodul>ng0: hmm that's weird, it works for me <civodul>jsierles: re your previous question, Guix uses /gnu, /var/guix, /var/log/guix, and optionally /etc/guix <civodul>CERN is big enough to have developed a bunch of operating systems and compilers i guess ;- <jsierles>yes civodul, learned about it at Curry On conf last week <civodul>"Curry On", didn't know that one either <rekado>roelj: all those that are not in (gnu packages java) yet. <roelj>rekado: Heh. I'll try to find time to help with the Java packages. <wingo>sneek: later tell mark_weaver from comment 1 <rekado>tried booting the USB image from iPXE but failed <rekado>because it’s waiting for the USB image partition <jsierles>civodul: yeah, one of our guys did a talk at the curry on conf about reproducibility, and we mentioned guix <joshuaBPMan_>Is there a student this year working on rewriting the C++ bits of guix? I believe to rewrite the build daemon in guile scheme... <civodul>joshuaBPMan_: reepca is working on it, and may well send an update soon, that's a good idea! <civodul>jsierles: i like the approach of that talk! <civodul>side node: i think GitHub is clearly the wrong tool for a "time machine for science" <civodul>the software is proprietary, and the service is commercial and could disappear overnight, like Google Code, Gitorious, etc. <rekado>ACTION is working on a side node <ng0>nevertheless it is a big social coding network, however problematic it is <civodul>ng0: undoubtedly :-) i was just referring to the idea of a "time machine for science" <rekado>ng0: sure, but that doesn’t make it a suitable candidate for reproducible science. <jsierles>civodul: i hope it didn't seem like we're promoting github in that talk <ng0>if reproducible science can get contributions otherwise and set up selfhosted infrastructure which scales (github occasionaly suffers the size of its own), then no. I really would not promote github for anything, just as a last choice if you considered everything else. <ng0>and science within proprietary walls should be avoided <civodul>jsierles: no, not really, the transition from "time machine" to "GitHub" just stroke me as i was watching the intro <civodul>i haven't watched the talk entirely yet, i'll do that soonish <jsierles>civodul: 'git' is really the time machine, not github. it's just not great for all types of projects <ng0>I know people who stuff big videos and pdfs into git oO <ng0>speaking of github and a little offtopic: some Gentoo people are around, how's that github/gentoo.org dual hosting working out for the project? Is there a reflection post or something which shows if it had a good effect? <efraim>I love git-annex for things like that <jsierles>our system is also proprietary for now, but we plan to open source it <jsierles>we just dont believe that you have to run everything yourself. and in fact by doing that, you are severely limiting what's possible <ng0>I agree. You have to make logical choices and choices which meet your capacities and goals and intentions. <jsierles>so, our hope is to build an expensive and open system you can adapt to any scale, but has strong foundations for reproducibility <jsierles>clearly, whatever science is doing, it has mostly failed in this area :) this is why we want to adopt guix, cernfs, etc. but in a way that gives them more exposure, like how github exposed git to a lot of people. <rekado>I think that science infrastructure should not be in the hands of corporations. <rekado>we’ve got too much of that already, unfortunately <rekado>so whenever there are non-profit orgs I prefer them <jsierles>sure. we will be starting a non-profit foundation soon for this reason <rekado>jsierles: I’m just commenting on ng0’s assertion about github and science. <jsierles>my view is that tools are bad. it we can make better tools, it's easier to choose how/where they are hosted <ng0>rekado: My reply was very open. <rekado>jsierles: agreed. I strongly hold that tools are bad. <rekado>the flac test suite takes a very long time… <ng0>would this work in (firmware) of the (system)? some-name:outputname <ng0>But what I want to do is less confusing with inherit and idividual names ***kelsoo1 is now known as kelsoo
<rekado>finally! GuixSD installed on one of these SunFire X2200 M2 servers. <mekeor>do we have any (command-line) tool packaged for guix which allows to concatenate PDF documents? <mekeor>mekeor: maybe the "poppler" package contains a tool called "pdfunite". check it out! <mekeor>mekeor: alright, cool, thanks :) <mekeor>because poppler doesn't contain pdfunite :( <ZombieChicken>Hello. has the install instructions changed? I'm trying to install to a LiveUSB and "herd start cow-store /mnt" says cow-store doesn't exist. <ZombieChicken>civodul: That's interesting. I figured there was a change that simply wasn't documented <mekeor>thanks, civodul: indeed, `podofomerge` allows to merge several PDF files :) <lfam>Unless we find a fix soon we'll probably have to remove the package <lfam>"like this one": I meant that podofo is full of bugs <lfam>Looks like there are some recent fixes in their SVN. Somebody should try cherry-picking them into our package <lfam>I'll file a tracking bug for Guix but I'm not going to actually work on fixing the bugs soon <lfam>All the recent Podofo SVN history is security fixes. Maybe we should just build from SVN or, even better, a tarball snapshot of the repo. <civodul>lfam: are these ACE vulnerabilities? <civodul>i thought this was a widespread acronym, maybe not :-) <lfam>I think more about RCE :) <lfam>Well, they are heap overflows and null dereferences, so it's quite possible <lfam>And since the main purpose of PDFs seems to be emailing them to other people, maybe one could call it a remote vuln ;) <lfam>civodul: What do you think about having tracking bugs for issues like that? Maybe it would help encourage others to help out <civodul>lfam: why not, it could make the problems more visible, indeed <lfam>Okay. Expect a huge number of new bugs soon :) <civodul>there's always a risk that they'll be happily ignored like the other bugs ;-) <civodul>but it's a risk that's probably worth taking <lfam>Yes, but I think that, currently, people who would be interested in these bugs simply don't know about them <civodul>the added visibility is a good thing <lfam>My oss-sec email inbox is not a great bug tracker, after all <ng0>ZombieChicken: in a naive way, yes <ng0>freenodeok2gncmy.onion <rekado>ZombieChicken: I ran “herd start cow-store /mnt” today and yesterday for a few times. <mekeor>it'd be good to package pdftk at some point <ng0>Has someone tried to offload to an .onion addressable build machine not using iptables on the master to route everything through tor? <ng0>in other words, last time guix proxy didnt really work <ZombieChicken>rekado: I've tried several times today. Any quick way to check if I'm on .13 or .12? This install is a bit old <mekeor>ZombieChicken: guix --version # ? <rekado>ZombieChicken: can’t you download the latest release image? <ZombieChicken>rekado: I'm trying to use an already installed system for this <ZombieChicken>Okay, weird. Just ran guix pull;guix system reconfigure /etc/sysconfig.scm, then rebooted into the new system, remounted the new USB, then tried "herd start cow-store /mnt", and it's still claiming cow-store doesn't exist. <ZombieChicken>specificiallly "herd: service "cow-store" could not be found". <lfam>ZombieChicken: If I understand correctly, the cow-store service is specific to the USB installation image. It's not used in "regular" GuixSD. <lfam>It's defined in (gnu system install) <ZombieChicken>So if using a "regular" GuixSD, is it needed to install another system? <lfam>ZombieChicken: I recommend you create a disk image for the USB stick with `guix system disk-image`. <lfam>Then, you can just copy the image into place. <lfam>... assuming I understand your goal correctly. <lfam>You are trying to put GuixSD on a USB stick, right? <lfam>Okay. Then you can either install from the USB installation image, or create a disk image and copy it over. Those are the two best options, IMO. <ZombieChicken>Just seems a little odd that guix system init wouldn't work here <lfam>Regular GuixSD is not the same as the USB installation image, so it won't work "out of the box" with the system installation instructions in the manual. <lfam>The USB installation image is a special GuixSD system built from the system declaration in 'gnu/system/install.scm'. If you read that file you can see the differences. <lfam>That is, you'll see the differences between it and the system declaration you are using now. <lfam>I have to go now, but good luck! <ng0>does hydra hang or did I crash something in the last reconfigure? I get no progress with guix pull or guix package -i <ng0>wasn't this on the mailinglist recently: <ng0>substitute: guix substitute: error: TLS error in procedure 'handshake': The TLS connection was non-properly terminated. <ng0>guix pull: error: build failed: substituter `substitute' died unexpectedly <ng0>either my wifi card, driver or networkmanager has issues <cehteh>some bullet proof distributed package distribution would be overdue. gnunet, ipfs, bittorrent whatever, anything, but no hydra errors anymore <ng0>people like to talk. but if only a minority is working on not-talking it takes a while. <cehteh>i am not familar enouhg with guix yet to contribute <ng0>that's not really what I meant, but I grew tired of discussing the topic of gnunet distribution.. I just do. My just-doing needs to be documented more, but eventually this will get into guix. if someone else decides to work on some other mechanism, that's fine too, I'll keep working anyway. problem is what I do grew beyond just this topic. but I see it like this, whoever really wants any of these distribution <ng0>methods and is capable of investing time into it will do it. <solene>what is the easiest way to run a X session from a xinitrc instead of xfce/gnome etc.. ? <solene>I want to use emacs-exwm from packages <rekado>solene: create an executable ~/.xsession with a line “exec the-window-manager” <efraim>You have to add 'exec my-wm-of-choice' to .xsession <solene>rekado: yeah, but I am using the login manager which starts xfce or gnome <rekado>if you use slim it should detect your .xsession and run that. <rekado>just need to make it executable. <solene>I had a .xinitrc not .xsession, I'll try after renamed it <solene>that's workingm but exwm doesn't start correctlym but this is is another problem now :) <solene>does somebody here use emacs-exwm ? I can't get it to work. It fails with a XELB error protocol <rekado>I think there are at least two people here who use(d) it. <solene>finally I got it to work, but when installing emacs-exwm it seems that emacs-xelb isn't installed ? <rekado>argh, I again get “database disk image is malformed” :( <rekado>I already dumped and reimported the db <rekado>but this time the error sticks :( <rekado>note: use the same version of sqlite3 to dump and reimport as the database that you want to recover. <rekado>check with “file the-db” to see what version was used to write it. <civodul>good to know that you worked around it! <civodul>lfam: should we apply the glibc LD_LIBRARY_PATH patch to core-updates? <lfam>civodul: Yes, we should. I guess we have a lot of work to do on that branch <civodul>ACTION does another "git worktree add" <lfam>I didn't come up with a solution for all the breakage resulting from perl 5.26.0 yet. I think that if we can't find upstream solutions, we should stick to 5.24.* for this cycle, and backport security fixes as necessary. <civodul>so revert the Perl ugprade altogether? <lfam>Well, I'd rather keep the upgrade. But if we can't find solutions elsewhere, or write the fixes ourselves, we don't have much choice. I suppose we could keep both versions around as you suggested, but it sounds complicated to me :/ <lfam>I'll try to do "both versions" before I revert, which is the last resort. <lfam>I'm short on time lately :/ <civodul>i'll see if i can test the 3 glibc patches on core-updates <lfam>Okay, I'll look right now for a solution to the Perl / intltool issue, since that's also a rebuild-everything change. <rekado>I just found out that I’ll be on vacation in two days. Will be afk for a week. <civodul>i'll post the patch in the stack-clash bug report <civodul>rekado: sounds like a good thing to discover no? :-)