IRC channel logs


back to list of logs

<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.
<Digit>thnx for the summary
<atw>wingo: congrats and thanks!
<catonano>I can't manage to import a perl module
<efraim>catonano: doesn't look like you named it correctly
<catonano>efraim: didn't I ?
<catonano>xls2csv ?
<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
<catonano>ah it's on th emannuual
<catonano>thanks !
<efraim>i'm getting certificate errors again, can't test out the commands atm :(
<civodul>Hello Guix!
<rekado_>hi civodul
<rekado_>I sent my reproducibility fix for R to the 25598 bug address. The fix is pretty straight-forward.
<civodul>moing rekado_!
<civodul>so you made it? woow!
<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> keyline at the bottom: "and you should now be able to boot debian-installer"
<efraim>its one of the boards supported by debian's arm64 kernel
<wingo>rekado_: congrats :)
<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?
<buenouanq>Happy Birthday RMS!
<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
<efraim> doesn't look like there's a quick way to export everything
<ryanwatkins>I am getting two error on GNU automake build for 1.15, has anybody else found similar?
<efraim>while building automake?
***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> !
<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)
<civodul>cool, thanks
<jmd>hydra is still dead?
<rekado_>jmd: “still”?
<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"
<[df]_>not just you
<rekado_>I was able to connect to it in the morning.
<civodul>it's been very loaded indeed
<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.
<ArneBab>here’s are the start and stop scripts I use to run the Guix daemons with OpenRC:
<jmd>If I look here : 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'
<civodul> done!
<civodul> still running
<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
<civodul>rekado_: we have an nginx config issue here:
<rekado_>it’s http not https
<rekado_>should we redirect?
<civodul>i think so
<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"?
<rekado_>nckx: I find this annoying, too!
<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.
<ryanwatkins>and now I can't edit a package, I am again getting 404's on some packages :(
***Piece_Maker is now known as Acou_Bass
<civodul>nckx: it's due to an optimization of beginning-of-defun in Emacs
<civodul>but yeah, really annoying
<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.
<rekado_>re “” — I can’t find this URL in our repository.
<civodul>rekado_: for gcc we "--with-local-prefix=/no-gcc-local-prefix", so you may see this file name in strace
<ryanwatkins>civodul: oh nono, I mean
<nckx>ryanwatkins: ‘Installing sudo breaks sudo’ sounds like a serious bug...
<rekado_>civodul: right, I remember.
<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
<civodul>anyone going to the repro build hackathon in May?
<ryanwatkins>civodul: the license for this one seems really weird ..
<rekado_>ryanwatkins: looks like BSD-3
<ryanwatkins>rekado_: oh yeah, true :D
<ryanwatkins>is there a way to get a binary symlinked into ~/.guix-profile/bin using the guix daemon?
<ng0>ArneBab: do you have an openrc file which works better than ? I'm no longer involved with Gentoo stuff, but lynX will accept pull requests and patches for changes :) and I can still push there
<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>bavier`: would be fun
<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>did you do the chroot?
<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_>civodul: :)
<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>ACTION nods
<rekado_>ACTION goes afk for a few hours
<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?
<lfam>nckx: Sure!
<catonano>configure can't find install-sh, or shtool. What should I add to my environment ?
<bavier`>catonano: have you run "bootstrap"?
<catonano>no. I have run aclocal and autoconf
<catonano>bavier`: ok, thanks
<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`
<nckx>davexunit: thanks!
<davexunit>what did I do? :)
<civodul>ACTION discovers that guile-json treats #nil specially
<davexunit>oh yeah
<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
<civodul>you folks aren't playful ;-)
<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>yes, yes indeed :)
<thomassgn>anyone seen 'which: no getcap in (' and then something that looks like PATH when trying torsocks?
<bavier`>thomassgn: yes, all the time
<thomassgn>it only happens with some programs, like I could run successfully 'torsocks wget' but not 'torsocks dillo' ...
<bavier`>w3m too
<thomassgn>derp. Do you have any idea what it is?
<civodul>oh that's a bug
<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
<civodul>hey lfam!
<civodul>lfam: it's a good idea, yes
<civodul>thomassgn: it's in libcap
<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?
<lfam>I see now that my email about the problem had a bad subject line:
<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>ACTION tries it
<efraim>here's the check for the list of drivers from mesa-git for 13.0.5
<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
<civodul>that was fast!
<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>oh really?
<civodul>are you sure the db is corrupt?
<civodul>did you try running "sqlite3 xyz"?
<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!
<civodul>ACTION -> zZz
<civodul>good night/day!
<thomassgn>anyone use onionshare? can't figure out how to set settings for it