IRC channel logs

2018-10-05.log

back to list of logs

***Server sets mode: +cnt
<lfam>georges-duperon: You are using `guix build --check`?
<lfam>georges-duperon: Can you explain in more detail what you tried? In general, you have to first build the thing, and then try again with --check
<georges-duperon>lfam: guix build --check -f guix.scm builds twice if there's not already a build, that's not the issue.
<georges-duperon>lfam: I produced one binary file, and placed in in (string-append (assoc-ref outputs "out") "/bin/"), all fine.
<georges-duperon>lfam: But if I try to put a .tar file next to it, I get that message.
<georges-duperon>lfam: The only way so far I've found to get that data somewhere in the output without getting that message is to base64-encode it, and place it in a .txt file in (string-append (assoc-ref outputs "out") "/share/doc/foo.txt")
***Server sets mode: +cnt
<civodul>Hello Guix!
<roptat>hi guix!
<civodul>wazup? :-)
<roptat>I pushed patches to staging yesterday and found that it hasn't been merged on master since a long time
<civodul>oh
<roptat>oh and there's something wrong with nss-certs
<civodul>i think we're lacking organization somewhat
<roptat>substitution of /gnu/store/mbs5mavs3gi4y7xkywcwwjj9g3p1yjmv-nss-certs-3.39 failed
<civodul>or at least i'm lost
<civodul>hm?
<roptat>and then some expected and actual hashes
<civodul>which server?
<roptat>mirror.hydra.gnu.org
<civodul>one thing that's not good is that we get different hashes on different machines: https://paste.debian.net/1045985/
<civodul>
<civodul>that means non-determinism, which in turn could lead to narinfo/nar mismatches with caching
<civodul>could you email bug-guix?
<roptat>sure
<roptat>my email client doesn't want to cooperate...
<roptat>sent :)
<nico202>Hi, I was trying to get guixSD luks boot automatically with a keyfile, any hint on some resource I should read? Right now it requires me to enter the password manually (and twice), I'd like grub to load it from an usb key
<civodul>oops too late
***rekado_ is now known as rekado
<rekado>my boss on Guix vs Conda vs Docker: https://medium.com/@aakalin/scientific-data-analysis-pipelines-and-reproducibility-75ff9df5b4c5
*civodul reads
*kmicu reads ‘pigx’ as ‘piggy’.
<civodul>rekado: that's a nice write-up with clear explanations!
<civodul>it's good for you that your boss understands what's at stake this well :-)
<civodul>and can explain it in terms that make sense to the bioinfo community
<kristofer>hello! I've been troubleshooting my exim-configuration with exim -d+route -bt user@mydomain.com and discovered the running exim isn't using the configuration specified in my system configuration.
<mange>Can you paste your configuration using the link in the topic?
<kristofer> https://paste.debian.net/1046002/
<kristofer>my exim-service-type is basically copy-pasta from the manual. I have a custom exim.conf in ./ with my system configuration, but apparently chooses to use the default configuration packaged with exim
<rekado>I’m having a weird problem compiling Haskell things.
<rekado>ghc-inline-c no longer builds, saying it depends on two different variants of parsec.
<rekado>guix graph doesn’t show anything strange.
<rekado>it’s ghc-parsers that provides a conf for that parsec variant
<rekado>I worry that our haskell-build-system might be stateful.
<mange>kristofer: Hmm. I would have expected that to work. I'll try to reproduce on my machine, but it'll take me a little while to build the VM.
<civodul>rekado: stateful? how?
<rekado>civodul: I don’t know yet. For each Haskell package GHC generates a bunch of configuration files. It wonder if there might be a conflict with configuration files describing the same package (but using different identifiers), which could be order-dependent.
<rekado>on the other hand this could just be a problem with the store on my laptop because I ran out of space a few days ago.
<ng0>for a deactivated mailinglist, nix-devel gets still a lot of mail :)
<civodul>rekado: but do you think there are packages that produce different results on different machines? or are you just talking about run-time behavior?
<civodul>well maybe it's too early
<civodul>hello mange!
<mange>Hi civodul!
<rekado>civodul: too early to tell. What I see, though, is that the package fails to build on my laptop, while it could be built on the workstation where I packaged it.
<mange>kristofer: After a bunch of experimenting, I can't reproduce your issue. The service should set things up to load a small config file that contains two lines (setting exim_user and exim_group) before loading the config file that you supply.
<mange>I tried it by creating an incorrect config file and then traced through the references in the store (starting from the correct *-shepherd.conf file, then through the *-exim.conf files).
<kristofer>if your vm is running exim, try exim -d to see what file the runtime config is
<kristofer>mange: ^
<mange>Okay. It wasn't running, because I started it with an invalid config file, but I'll try to give it a valid configuration to try it.
<rekado>this is not good. The same derivation builds fine on the workstation, but fails on my laptop.
<rekado>the derivations are identical.
<rekado>the configure phase output differs
<mange>kristofer: Does -d connect to the running daemon and ask it for the config location? The man page isn't clear one way or the other.
<mange>kristofer: Based on what I'm seeing, I think that exim -d doesn't talk to the daemon, and just uses whatever config file it thinks it should. The daemon is run with -C /gnu/store/...-exim.conf, but running exim -d doesn't know that, so it just uses the default configuration file instead.
<roptat>rekado: could it be because of some missing processor feature?
<roptat>(or different processor feature)
<wingo>anyone made a guix machine into a pxe server?
<kristofer>mange: I see that, I guess it must be an exim.conf error. Thanks for investigating
<rekado>roptat: I don’t know. CPU features shouldn’t be a factor at this stage.
<rekado>I have to say, though, that this does look vaguely familiar.
<rekado>a couple of months back we had a similar problem involving Haskell.
<rekado>I just don’t remember enough about it.
<nico202>To get icecat display fonts should I install something? I see only squares
<mbakke>Oooh I managed to build "gcc-final" using GCC7.
<civodul>\o/
<civodul>mbakke: BTW, what's the status of core-updates? :-)
<mbakke>civodul: I haven't paid attention in a while, but ICU tests fail on i686: https://unicode-org.atlassian.net/browse/ICU-20080
<mbakke>I'll try and skip those tests so i686 gets going again.
<civodul>mbakke: that's a typical test failure, comparing floats for equality is bad :-)
<civodul>so yeah, i think it makes sense to skip that on i686
<mbakke>Interestingly armhf was fine.
<nckx>o/
<janneke>o/
<nckx>Dear bugtracker! Please update all packages so I don't have to.
<lfam>Do we have a calculator app packaged? Something graphical that looks nice?
<nckx>lfam: ...are you trying to exploit Guix?
<lfam>Haha, yes. I'm crowdsourcing this question ;)
<lfam>Or hoping for someone to mention an unpackaged program that I can add
<ng0>Buildbot is a nice rabbithole
<nckx>I'd say gnome-calculator, but maybe you were implying it's ugly.
<lfam>I hadn't tried gnome-calendar, so no judgment!
<lfam>xcalc is not quite pretty enough for my use case
<janneke>there's at least two under M-x ;-D
<nckx>Wait, calendar or calculator?
<lfam>I mean calculator
<ng0>do oyu have xcalc in master? i don't rememeber if I packaged that or just forgot to send
<lfam>Also thinking about calendars but I just looked at gnome-calendar so I slipped up :/
<lfam>We have xcalc, ng0
<ng0>but x* is far from pretty.
<ng0>ok :)
<ng0>is pari-gp@2.11.0 or what is was building on master? for my purposes I am working with 2.9.3 where I need to apply lots of additional magic glue
<ng0>i withdraw the question, I can at least get a su bstitute
<ng0>(weirdd...)
<nckx>Also weird: the new IceCat is great, but (at least on i3) the tab bar doesn't 'auto scroll' when opening a new tab: new tabs eventually 'drop off' the right end and I have to use the scroll wheel to get them back. Has anyone had this problem?
***mbowcutt_ is now known as mbowcutt
***tau is now known as Guest38059
<rekado>the package.cache files for ghc-inline-c on the two systems differ.
<rekado>the order of some lines in files in package.conf.d differs as well.
<rekado>the names of the files also differ
<rekado>I wonder how they are generated (they look like part of them is generated)
<rekado>there’s something non-deterministic about the haskell-build-system
<civodul>uh!
*rekado looks at make-ghc-package-database now
<civodul>regarding the order, it may be the usual readdir-without-sorting issue
<rekado>I wonder if maybe that’s our fault
<rekado>we generate that package cache from the inputs; maybe at some point we forgot to sort files.
<rekado>no, we copy all these files and then run ghc-pkg on the directory
<rekado>so maybe ghc-pkg needs to be modified to sort
<civodul>yes probably