IRC channel logs


back to list of logs

<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>But it isn't
<EternalZenith>Nevermind, I think I fixed it
<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>Oh, thanks
<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
<EternalZenith>I remember changing that in my config
<EternalZenith>Now all I need to package is pywal, kitty, and caps2esc
<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?
<EternalZenith>Nevermind, I found 'setenv'
<EternalZenith>Packaging things is so far pretty fun
***tau is now known as Guest68295
***Guest68295 is now known as nyberg
<g_bor>hello guix!
<user_oreloznog>Hello Guix :) o/
<g_bor>hello user_orelozong!
<g_bor>hello user_oreloznog!
<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
<civodul>Hello Guix!
<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
<efraim>sneek: botsnack?
<civodul>efraim: sounds like non-deterministic issues, then!
<efraim>x265 also broken on armhf
<efraim>or old kernel / no TTYs / something random
<civodul>hmm, could be
<civodul>though we'd also have that problem on master i guess
<roptat>hi guix!
<civodul>heya roptat!
<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.
<g_bor>Is that correct?
<civodul>g_bor: yes, i think so
<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>wow, this is strange!
<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>i see
<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
<civodul>efraim: cool!
<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
<civodul>yes, sounds like a good test
<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 :)
<civodul>heh :-)
<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>fun times
<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
<roptat>(in /var/guix/profiles/)
<g_bor>yes, I think I can.
<civodul>spice test failures on core-updates
<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
<sneek>Will do.
<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 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>hi amz3
<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>hey folks
<wingo>ssl question! why doesn't this validate:
<wingo>gnutls-cli -p 6697
<civodul>hey wingo!
<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" 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" 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 into that box, indeed it says that the intermediate cert is missing
<civodul>glad it's not Guix's fault ;-)
<wingo>me too :)
<wingo>i am glad we found a config error in, 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>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>oh dear
<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!
<tune>Thank you for the help.
<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>tune: great!
<civodul>rekado: oh!
<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?
<rekado>not for glibc 2.28, I’m afraid.
<civodul>ok, np
<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?
<rekado>hmm, the new GNUnet web interface requires node:
<nly>I wanna add an entry to /etc/crypttab for encrypted home to be decrypted by a keyfile
<nly>How should I do it?
<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: 90% is too high.
<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
<civodul>just to see how people react
<civodul>or we can ask ho1ger
<demotri>What is 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?
<roptat>civodul: no we didn't
<roptat>demotri: not really
<demotri>BTW: "Minimalistic Languages" devroom accepted:
<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_>Hello Guix!
<nixo_>I just submitted my first patch (if the email has been sent)
<nixo_>Well I can't find it on ..
<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>nope, they're different
<civodul>with the same commit?
<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
<nixo_>Hello Guix!
<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>maybe on bug-guix actually
<civodul>rekado hinted at a bug in this area recently
<cbaines>here's a slightly crude paste with the two in
<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>(things are sorted alphabetically)
<civodul>ideally we'd then diff the two ghc-esqueleto .drv, and so on, recursively
<civodul>until we find the root of the differences
<civodul>(omitting fixed-output derivations)
<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>That, I understand.
<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>OK. Thank you.
<ngz>So there are a few hard-coded special outputs.
<ngz>At least in gnu-build-system.