<lfam>Digit: Regarding hardening, you should find previous discussion in the guix-devel archives. In short, we want to start building C / C++ software with some hardening options that are set by default, but somebody really needs to lead the effort. <atw>wingo: congrats and thanks! <efraim>catonano: doesn't look like you named it correctly <efraim>i've always used the cpan importer with the caps and the colons <catonano>would you mind to write down an example ? I don't know the first thing about perl <efraim>i'm getting certificate errors again, can't test out the commands atm :( <rekado_>I sent my reproducibility fix for R to the 25598 bug address. The fix is pretty straight-forward. <rekado_>yeah, it took me a couple of seemingly endless rebuilds but it builds fine now, and all R packages I built with it were reproducible as well. <efraim>its one of the boards supported by debian's arm64 kernel <efraim>wingo: 46 minutes on aarch64 without removing the prebuilt folder <wingo>efraim: cool. could be better i guess <wingo>i guess you were testing the 2.2.0 tarball? <wingo>i am not sure how those numbers will go in the future. on the one hand, native compilation will yield a 2-4X speed improvement in the interpreter (and later, the compiler, when it's compiled). on the other hand, there will be more compiler code. <efraim>Its a bit wonky between really slow storage and smaller than x86_64 cache, cmake builds faster and with fewer test errors with 2 cores than with 4 <efraim>Most people will end up using distro provided binaries, so its probably not an issue <efraim>to transfer store contents i want `guix archive --export * | ssh othermachine -q guix archive --import' ? <efraim>i finally changed the guix-daemon on my aarch64 machine, --no-substitutes --no-build-hook (no guile-ssh installed) and --cores=3 <ryanwatkins>I am getting two error on GNU automake build for 1.15, has anybody else found similar? ***orly_owl_ is now known as orly_owl
<ArneBab>but going through the guix installation on a foreign system again: the only hard part is that Application setup comes so much later in the manual than the binary install. If the shorter binary install instructions included guix package -i glibc-utf8-locales, adding the GUIX_LOCPATH to the bashrc, and adding build users (essentially the complete minimal install), it would work more easily. <civodul>ArneBab: "Binary Installation" has links to all these things, no? <civodul>though i admit that it would be better with fewer manual steps <civodul>ryanwatkins: i don't recall seeing that, could you paste it? <ArneBab>it has one link — which I must admit I missed because it came after "this completes" <civodul>efraim: you should try 'guix copy' for remote transfers <ArneBab>root-level install still needs the Application setup, so adding step 8 which gives the commands for "Application setup for root" (and the link to there) could avoid that <civodul>ArneBab: right, we could make "Application Setup" an 8th item in the list <ArneBab>aside from that, the installation went smoothly <civodul>this is some sort of social engineering: how can we make sure people will actually read this? ;-) <ArneBab>programming on the diverse set of human brains :) <ArneBab>I could provide start and stop script for Gentoo (to go into /etc/local.d/) <ArneBab>for guix-daemon, to be used with OpenRC <civodul>oh sure, we'd happily include them along with the systemd and Upstart files <jmd>civodul: My reply to your comment on bug 25995 seems to have lost it's context. The answer to your question is, that without it users cannot build Guix without guile-json installed. <efraim>i have to get `guix package -A` working on the aarch64 board, then I can do `guix package -A | cut -f1 | sort -u | shuf | xargs guix build' to build random things <wingo>i think it can make sense to make a "guix init" on foreign distros to install dynamically-scoped dependencies into a user profile and to suggest commands to add to the appropriate dot-files like bashrc <wingo>it might print out a link to the manual too :) <civodul>jmd: could you reply to the bug address? <civodul>wingo: the "guix init" idea sounds good <jmd>civodul: I did so. But, somehow it lost it's context. <jmd>I must have mistyped the number or something. <civodul>yeah there's no subject and no quoted text, so it's hard to figure out what you're replying to :-) <civodul>the last question was "what ...?" so the answer cannot start with "But" ;-) <jmd>The problem it causes is that the software cannot be built. The "But..." sentance was a reply to your first statement. <civodul>jmd: could you resend the message with full context? i'll check it out later <jmd>I'll try and work out how to do that tonight. <jmd>(I'm still learning debbugs) <jmd>hydra is still dead? <jmd>I haven't been able to get a response from it for the last 3 days - maybe it's just me? <jmd>"504 Gateway Time-out nginx/1.11.6" <rekado_>I was able to connect to it in the morning. <civodul>uh there's an rdiff-backup process taking forever <thomasd>impressive work packaging all that kde stuff <thomasd>well, preparing all that kde stuff for packaging <jmd>He should divvy it up into sections and allocate one section per person to work on. <jmd>If I look here : http://hydra.gnu.org/build/1910273 it lists some "Failed build steps" If I click on the log for step 1 for example, there is no failure. Everything succeeded. That does this mean? <thomasd>Is there a way to extract a patch that git will apply from the mailing list archives? (via web interface, or another interface?) <jmd>thomasd: Without downloading that part of the archive, I can't think of a reliable method. <thomasd>jmd: ah yes, I wasn't aware of the “download” link. thanks. <efraim>depending on how its laid out, you might be able to `wget download | git am' <davexunit>wingo: kcachegrind is a fun tool. haven't used it since 2012 <davexunit>but I used it to hunt down some serious performance issues in a Ruby web app <wingo>i use it often. instead i have been using a guile tool to process callgrind logs recently but it is not as good <civodul>IWBN if perf, valgrind, & co. could be extended to be aware of the VM stack <nckx>Hullo guix! I've question: why does emacs mark brackets at the beginning of a description line in red? And should I make an effort to avoid them? <jmd>What do you mean a "description line"? <nckx>‘Any multiline string‘, I think, but it only ever catches my attention when editing package descriptions. <ryanwatkins>Hey guys I accidentally installed the sudo package and lost the ability to be a sudoer, is there a way to fix this? <nckx>If it's just a (heavy-handed IMO) ‘you know you're not writing code, right?’ then I'd ignore it. But... you know... red. ***Piece_Maker is now known as Acou_Bass
<civodul>nckx: it's due to an optimization of beginning-of-defun in Emacs <ryanwatkins>also has there been an attempt to package haskell stack yet for guix? <civodul>ryanwatkins: maybe you can type the absolute file name of the right "sudo" command? <rekado_>Do you know of a way to prevent the GCC toolchain from looking at files in standard directories? <rekado_>(I need a solution that does not involve containers) <civodul>rekado_: does it actually doe that? i think it doesn't <ryanwatkins>civodul: I had forgotten that root had no pw and was able to manipulate things from there :D <nckx>civodul: thanks! That would have taken me quite some time to figure out. <civodul>ryanwatkins: there are currently 279 GHC packages <rekado_>oh, in that case it’s probably just R doing this. I’ll investigate. <civodul>rekado_: for gcc we "--with-local-prefix=/no-gcc-local-prefix", so you may see this file name in strace <nckx>ryanwatkins: ‘Installing sudo breaks sudo’ sounds like a serious bug... <ryanwatkins>rekado_: weird, it kept cropping up in some packages, not sure why <ryanwatkins>rekado_: now it is fine for me though, I think somehow it wasn't grabbing from the mirror before for some reason <civodul>ryanwatkins: oh, no idea; there are importers for hackage and stackage, but not for this one <ryanwatkins>is there a way to get a binary symlinked into ~/.guix-profile/bin using the guix daemon? <ng0>would be great if there was a service file which really works, so an guix provided one could be used <bavier`>civodul: I can't attend the repro build hackathon in person, but I can maybe set aside those same days for a personal hackathon <civodul>apparently rekado_ has been on a personal repro build hackathon for quite a few days now ;-) <determinator8899>I just wanted to install guixsd, but it seems that herd cow-store start doesn't work for me as I understand correctly everything I write in /gnu/store is written on my /mnt directory but this doesn't happen ? <wingo>i think there is a chroot in there, could be wrong tho <wingo>installation is tricky but i think if you follow all the steps to the letter it should work <ArneBab>ng0: no, the gnunet one looks cleaner. The main difference is that mine is just a start and stop script which the user throws into local.d while the gnunet one is a full init file for /etc/init.d/ <determinator8899>wingo: chroot is not mentioned in the documentation but when I do chroot /mnt it fails to run the command '/gnu/store/something/bin/bash' no such file or directory this is strange. <rekado_>I’m not sure if I can make it. Hamburg isn’t far, but … I don’t know if it would really be worth traveling and reserving a weekend for sitting in front of a computer. <civodul>i almost have 'guix pack -f docker', i'll need testers to make sure i didn't break anything <nckx>lfam: Re: knot, is ‘ "--enable-rosedb" ; serve static records from a database’ friendly enough? <catonano>configure can't find install-sh, install.sh or shtool. What should I add to my environment ? <ZombieChicken>What is the easiest way to tell what packages are installed in the system profile? <alezost>ZombieChicken: guix package -p /run/current-system/profile -I <buenouanq>ZombieChicken: try running a command the package supplies ;3 <quiliro>what is the difference between `guix package -u .` and `guix package -u` <civodul>ACTION discovers that guile-json treats #nil specially <civodul>i was wondering why rekado_ was using #nil in docker.scm <davexunit>that's one of those things that (ice-9 json) avoided I think <Digit>ACTION rolls civodul a ball of yarn <thomassgn>hi, just wanted to point out that after vacuuming my fans I could once again run compile jobs fine with --max-jobs=2 --cores=2; maybe even more, but not yet tested. :P <civodul>thomassgn: neat; i'm glad Guix isn't to blame :-) <thomassgn>anyone seen 'which: no getcap in (' and then something that looks like PATH when trying torsocks? <thomassgn>it only happens with some programs, like I could run successfully 'torsocks wget check.torproject.org' but not 'torsocks dillo check.torproject.org' ... <civodul>i don't see that because i have getcap in $PATH <civodul>we should change torsocks to refer to getcap by absolute file name or somethig <thomassgn>ah, nice. where does getcap live? I mean package? <lfam>civodul: Is it a good idea to "Cancel all scheduled builds" before starting a new evaluation? I don't want Hydra to try building anything that depends on mesa since mesa has changed since the last evaluation <efraim>I need to fix libepoxy already on aarch64, that one keeps giving me test failures <lfam>efraim: Do you have access to an x86_64 machine with Guix on it? <lfam>I can't build mesa on core-updates since that triplet of patches starting with c5e91014a2859b7e5c226c411fb14d19bb008a8a <efraim>Those were mine? I didn't test them on x86_64, just aarch64 <efraim>ok i see the patches, where does it fail? <efraim>ok, on the c5e9 commit where I moved gallium-llvm to intel only, i also specified all the dri-drivers instead of leaving it at the default <efraim>try changing it from 915 to i915, looks like i typo'ed it <lfam>Yes, the configure phase succeeded. I'll commit the change. Thanks efraim! <efraim>np. I thought I caught that one also when I realized i put 965 and not i965 <lfam>I'm going to test the build here and then start a new evaluation on Hydra <lfam>My request to cancel the previous evaluation times out (504 error) <lfam>Well, maybe the request goes through, but the page load times out. I'll find out when I can load the jobset page :) <civodul>there's an ongoing evaluation, and the machine is super loaded <civodul>could someone test a Docker image for me? <civodul>ACTION .oO( not the best channel to look for Docker users... ) <rekado_>civodul: I could test it tomorrow at work. <rekado_>I ran out of space while building things and it seems to have corrupted the sqlite database :( <rekado_>I wonder how I can recover from this <rekado_>this means I can no longer run “guix gc” <civodul>guix-daemon reserves extra space precisely so the system doesn't really run out of space <civodul>and i'd be surprised if sqlite didn't protect against it, too <civodul>anyway, let me know tomorrow if there's anything i can do to help! <thomassgn>anyone use onionshare? can't figure out how to set settings for it