<EternalZenith>I'm attempting to package polybar right now, and I'm having trouble getting it to build <EternalZenith>It depends on the xcbgen module for python, which should be a part of the xcb-proto package <EternalZenith>I added the regular 'python' package to the native-inputs even though polybar only needs python2, and that seems to let cmake find it <pkill9>EternalZenith: i've actually already made a package for polybar, i never get round to submitting my packages though, i'll send you a link to it <pkill9>i added a patch though to switch the positions of artist/title in the mpd plugin, just remove the #:phases specification if you don't want that <EternalZenith>I think I'll try and see if I can get this working on my own first, this will be the first thing I've packaged once I can get the tests working <pkill9>you can see in my package definition the fix for xcbgen, it replaces the python3 input with python version 2 <EternalZenith>So xcb-proto just isn't building the python2 modules when the package is created? <EternalZenith>Do you really need to patch polybar to change the mpd module? <pkill9>yeah, because it's given python3 as an input, so you were right, i misunderstood what you wrote <pkill9>nope you don't need to patch it, i patched it for preference <pkill9>i patched it because i was using it for internet radio, and it just put the artist as 'autodj' and there wasn't enough space to show the title, so i switched them round <EternalZenith>My polybar package built, I just needed to sort out my native/propagated/regular inputs <EternalZenith>How do you export an environment variable for a build phase in a package definition? ***tau is now known as Guest68295
***Guest68295 is now known as nyberg
<ng0>has anyone experienced unusual problems with offloading with recent GuixSD systems where on both sides the guix daemon is fairly new (yesterdays version) <nixo_>Hi, is mpd working on guixSD for you? the service definition is missing the db_file parameter (cannot find it) and so mpc update fails with "no database" <nixo_>(if I add the line "db_file "/var/lib/mpd/mpd.db" it works) <efraim>time to see about fixing x265 on aarch64 <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, efraim says: I built shepherd for armhf-linux on core-updates on my aarch64 board and it built with no problems <civodul>efraim: sounds like non-deterministic issues, then! <efraim>or old kernel / no TTYs / something random <civodul>though we'd also have that problem on master i guess <efraim>does x265@2.9 build on i686 or does it fail with an error about detect512? <g_bor>roptat: I've came up with somethingn <g_bor>I almost have a reproducible javadoc for icedtea-6. <efraim>ok, i have x265 building on armhf-linux <g_bor>It also seems, that the relevant code is not changed very often, so we might have luck applying the same patch for later versions. <g_bor>civodul: I need some help in understanding what merges do we expect in the near future. <g_bor>I guess that core-updates will be merged to master, and then this will be merged to staging, then staging gets some more patches, then it will be merged to master. <roptat>g_bor: re reproducibility of javadoc, nice :) <civodul>g_bor: but really, we should coordinate on guix-devel to make sure it doesn't get out of hands <civodul>i'm currently trying to upgrade my profile to core-updates to see what breaks <civodul>i think we all need to do a bit of polishing on core-updates so we can move forward <g_bor>Javadoc now is reproducible, but jdk is not?! *g_bor running diffoscope <g_bor>civodul: I've just asked, because I'm trying to find out where to target these java-bootstrap related patches. <civodul>probably core-updates is a good target <efraim>civodul: I think I have some of the clang-runtime packages fixed for core-updates, have to finish testing them <efraim>merging master into core-updates should fix a couple of packages I fixed last week <efraim>then I was going to test building gnome xfce qemu and qtbase as my sample <efraim>after fixing gdk-pixbuf on core-updates I feel like someone should donate to gnome some slow arm boards for them to test with :) <efraim>i have clang-runtime@3.7 built, hopefully building out to clang@3.7 to test it shouldn't be a problem <roptat>I've finally rebuilt every ocaml package with the newer ocaml 4.07 (instead of our current 4.02.3) <roptat>bap requires ocaml <= 4.04, so I've kept our 4.02 and built most of our packages with both compilers (adding a package-with-ocaml4.02 procedure) <roptat>now I just need to clean my patches and I'll send them to the list <roptat>I had to update almost every package because of changes in the standard library <efraim>great job, it's always great to see batches of packages getting updates <g_bor>does guix system have a delete generations, like guix package does? <roptat>I don't think it has, but it would be useful <roptat>you can remove generations manually <civodul>g_bor: it's one of the things we really need to implement before 1.0 :-) <civodul>sneek: later tell snape i think Cuirass should register GC roots for its evaluations under /var/guix/gcroots <civodul>because it seems that berlin already lost things it built for core-updates before <civodul>rekado: could you push what you've done so far with the Hurd on core-updates somewhere? <civodul>i can try to continue where you left <amz3>hello, I am trying to setup guix in lxc container. I followed the tutorial at gnu.org/s/guix about binary install. It went well. Until I tried to guix pull, I get the following error: guix package: error: build failed: while setting up the build environment: unable to make ?/? private mount: Permission denied <civodul>looks like there are things guix-daemon cannot do in this container <amz3>Trying 'guix package -i hello' leads to the same error. Looking up dmesg, tells me: [240073.766716] audit: type=1400 audit(1539605833.825:115): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=13543 comm="guix-daemon" flags="rw, rprivate" <civodul>i guess you need to tell AppArmor to allow guix-daemon to do its thing <civodul>we don't have instructions for AppArmor though, and i don't know much about it either <wingo>ssl question! why doesn't this validate: <wingo>gnutls-cli -p 6697 irc.ripe.net <wingo>i just updated everything so that's not it <civodul>we configure GnuTLS to honor /etc/ssl/certs by default <civodul>so if you have nss-certs in there, it should just work <civodul>for example, "gnutls-cli -p https www.gnu.org" works for me <wingo>yes but this is on guixsd, all up to date, and i think probably that cert should work <civodul>but "gnutls-cli -p 6697 irc.ripe.net" doesn't, weird <wingo>unless ripe misconfigured their network, or are failing to attach an intermediate cert <wingo>which we don't usually include? weird <civodul>"grep 'DigiCert SHA2 High Assurance Server' /etc/ssl/certs/*" turns up nothing <civodul>did you try on a Debian machine, say? :-) <wingo>put irc.ripe.net:6697 into that box, indeed it says that the intermediate cert is missing <wingo>i am glad we found a config error in ripe.net, it's like finding a compiler bug in gcc :) <tune>getting an error trying to guix pull :( <tune>brad@kazuki:~/ > guix pull <tune>Migrating profile generations to '/var/guix/profiles/per-user/brad'... <tune>guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/brad/current-guix" <tune>I was able to guix pull last night, and then I rebooted. now I can't <tune>should I delete the file it's complaining already exists? <civodul>tune: what does "readlink ~brad/.config/guix/current" report? <tune>/var/guix/profiles/per-user/root/current-guix <tune>I'm am in the middle of a guix system reconfigure if that matters... although I thought I'd done them at the same time before <civodul>tune: oh, there a "root" vs. "brad" mismatch here, no? <tune>I'm not sure what that's supposed to link to <civodul>~/.config/guix/current is supposed to link to /var/.../per-user/$USER/current-guix <civodul>so here it should be "brad", not "root" <tune>alright, I follow that logic. would an update have changed the link for some reason? it says last modified today <civodul>you can fix that symlink by hand: ln -s /var/guix/profiles/per-user/brad/current-guix ~/.config/guix/current <civodul>i'm wondering, the problem might come from "sudo guix pull" with HOME=/home/brad <tune>ln: failed to create symbolic link '/home/brad/.config/guix/current/current-guix': Read-only file system <civodul>you might need "sudo rm ~brad/.config/guix/current" first <tune>Ah, that makes sense. I think ls did show root owned the file. <tune>Okay, did that and now guix pull appears to work! <rekado>civodul: my hurd work was not based on core-updates. <rekado>I wasn’t able to make it work with the new glibc. <rekado>I got far enough on “master” to build the bootstrap binaries, and I’ve uploaded them somewhere (I think on berlin). <civodul>but you did try to get glibc 2.28 for the Hurd, right? <rekado>I can push the changes to savannah later, but I don’t know how useful they would be for core-updates. <rekado>I did try that, but I wasn’t able to get far. <civodul>do you have something to share anyway? <nckx>efraim: Thanks for fixing x265/ARM while I was away. <nckx>Is there a way to notice such breakage without an ARM box or waiting for Hydra to build upstream? <nly>I wanna add an entry to /etc/crypttab for encrypted home to be decrypted by a keyfile <demotri>civodul: Concering FOSDEM-stand: You mentioned RB. I have the feeling that this project is 90% Debian, or is that impression wrong? <rekado>demotri: but Debian is very well represented in RB. <rekado>many other projects participate in the summits and on the mailing lists, but I don’t think any other project is as active in RB as Debian. <demotri>rekado: OK. Thanks. I was just thinking, if it was so much Debian, does it make sense for them to have a special stand for RB? But then maybe it's worth to ask the RB-project for stand-sharing. <civodul>demotri: i think it makes sense because R-B is an effort to spread the word beyond Debian <civodul>whether it makes sense to share at all, i dunno <demotri>civodul: About sharing: cons: It makes the whole process more complicated, you have to find a partner project. pros: I think chances are better, there is a high demand. pro: You can have just one person on the stand from Guix, and they can go to toilet while partner-project is still there. I think we have few people to be fully present. <civodul>demotri: the pros may outweigh the cons then <civodul>i guess you can try discussing it on the rb-general list or on #reproducible-builds on OFTC <demotri>Oh, I see. Another IRC service (and more). <demotri>civodul: I'm on the rb-general list, so I can write a mail there. <demotri>What do you think about asking FSFE in parallel? <rekado>the FSFE booth is usually pretty wide and full of merch. <rekado>in the past other people shared the booth (I think it was Technoethical), but they only got 50cm or so. <demotri>So you think it wouldn't be worth asking them? <rekado>I think it would be nicer to share a booth as equal partners :) <rekado>I remember that there was some confusion when the FSFE booth was shared as people assumed that Technoethical was a part of the FSFE. <demotri>The idea came from GNU->FSF->FSFE. But the stand is really full of merchandise and the "equal partner" argument is good. <demotri>I will ask on RB-mailing list. Any other idea? <roptat>two years ago we were 4 on the LFS stand, so it seems we have plenty of people for guix :p <civodul>roptat: did LFS share its stand with some other org? <demotri>roptat: Do you have any hints for the application process? <ng0>what goes into Minimalistic Languages? <efraim>nckx: my pleasure :) I really enjoy things like that <efraim>Not sure about how to find out without building it <nckx>efraim: OK, just wanted to know if i {c,sh}oulda known before pushing it. <nckx>(Besides trawling the issue tracker, but then every non-trivial project has an open 'fails to build on $arch-foo' bug.) <mbakke>nckx: You could use qemu-binfmt-service-type to fool Guix into building natively for arm. <nixo_>I just submitted my first patch (if the email has been sent) <nixo_>is there a spam filter or something? <civodul>grr i was wondering why berlin wasn't building all of core-updates <civodul>and it turned out it was set to build the "core" subset <civodul>i was looking for an obscure bug in Cuirass but no, it's working as advertised <cbaines>git-annex builds for me on one machine... but not on another one <cbaines>the generated derivations have the same output, but slightly different orderings for some of the inputs?! <civodul>cbaines: are the .drv file names the same? <cbaines>should be, I've tried running guix pull multiple times on both machines <civodul>can you double-check with "guix describe"? <civodul>if it's the same commit it should be the same .drv file name <cbaines>I get the same output on both machines with guix describe <nixo_>I still cannot see the patch I sent while postfix says the mail was sent.. Anybody has an idea on what's going on? <civodul>cbaines: could you send the content of both .drv files? <civodul>rekado hinted at a bug in this area recently <cbaines>however, it's not a bad way of diffing them <cbaines>if you search for ld-wrapper, you should see the start of the region that differs <cbaines>in the first derivation, the next package is ghc-tasty-quickcheck, but in the other, it's ghc-esqueleto <civodul>ghc-esqueleto is the one that differs <civodul>ideally we'd then diff the two ghc-esqueleto .drv, and so on, recursively <civodul>until we find the root of the differences <cbaines>I've tried using wdiff for diffing derivations, but it wasn't very revealing. Any suggestions? <rekado>cbaines: when I last looked at it the problem appeared to be due to the order of dependencies as seen and recorded by ghc-pkg. <rekado>it seems that with the current haskell-build-system it’s not always okay to mix packages that were built on berlin with packages built locally. <rekado>patching utils/ghc-pkg/Main.hs to sort the result of getDirectoryContents might help. <rekado>it’s expensive to test this, though, because this requires a rebuild of GHC and all Haskell dependencies leading up to the failing build. <rekado>would be nice to know more about the real cause of this problem. <cbaines>I've tried following the derivations down, looking for differences in the filenames <cbaines>The git-checkout derivations for ghc-esqueleto differ, and inside those, the git derivation differs <cbaines>I guess this doesn't matter though, as the git-checkout derivation is a fixed output derivation <civodul>cbaines: git-checkout derivations are fixed-output, ignore them :-) <civodul>cbaines: re diffing, i use ediff-regions-wordwise <ngz>Hello. I think I have some trouble understanding outputs in packages. Without moving any file explicitly, how is it decided that some file go to output "out" and others to, e.g., "doc"? <pkill9>ngz: i think the packages have 'doc' outputs when the docs are large, to save the need to download them when getting substitutes <ngz>My question is more about how to use it. If I add some "doc" output, it seems to be automatically populated by some files. <ngz>I try to understand by what rules those files are selected. <civodul>ngz: the "rules" are in gnu-build-system.scm <civodul>basically it passes --docdir to the configure script <ngz>So there are a few hard-coded special outputs. <ngz>At least in gnu-build-system.