IRC channel logs


back to list of logs

<mbakke>rekado_: In the past I've just deleted core-updates, then "promoted" the -next branch and deleted that too.
<mbakke>Also: yay, finally! :)
<mbakke>Ooh, the aarch64 kernel built successfully.
<vagrantc>i don't think i've ever been able to use a substitute for an aarch64 or armhf kernel before
<vagrantc>ACTION just assumed the substitutes weren't bothering to build it
<mbakke>vagrantc: Maybe if you don't pull so often ;-)
<vagrantc>or just poorly timed pulls
<mbakke>vagrantc, efraim: I sent the Linux-Libre fix here: <> :)
<pkill9_>is aarch64 arm-64?
<vagrantc>pkill9_: yes
<vagrantc>sort of
<vagrantc>ACTION guesses ARM really wanted to be sure they were at the top of some architecture sort-order
<vagrantc>but "linux" still calls it arm64
<vagrantcish>guix pull
<vagrantcish>guix pull: error: binutils-ld-new-dtags.patch: patch not found
<vagrantcish>that's with 116ca65b583ba4e404289f1481dc3a3ffef1c3dd
<mbakke>vagrantcish: Is that commit your current `guix --version`?
<mbakke>Any chance you have a custom binutils in GUIX_PACKAGE_PATH or something?
<vagrantc>mbakke: yes. no GUIX_PACKAGE_PATH set
<vagrantc>guess this is essentially bisectable
<mbakke>vagrantc: That's very odd, that patch disappeared a long time ago. But it was in 'master' until very recently.
<mbakke>Did you pull just now?
<vagrantc>"guix pull" was successful, which brought "guix --version" up to that commit.
<vagrantc>subsequent "guix pull" "guix package -u" "guix system build ..." all fail with that error now
<mbakke>Interesting, I'll try to reproduce.
<vagrantcish>i'll try removing latest and pull again...
<vagrantcish>well, that fails to build too
<vagrantcish>ACTION looks forward to versioned guix links...
<mbakke>Hah, that will be nice indeed...
<vagrantcish>ACTION sighs
<mbakke>Pulling from an old master branch (as in the embedded Guix snapshot) will require pulling 5d669883ecc104403c5d3ba7d172e9c02234577c first :/
<mbakke>vagrantcish: I'm not able to reproduce the problem after pulling from core-updates or master.
<vagrantc>mbakke: yeah, i'm guessing lots of people aren't, otherwise it wouldn't have been merged ...
<vagrantc>well, i pulled 5d669883ecc104403c5d3ba7d172e9c02234577c and now am trying to pull against master again ...
<vagrantcish>ugh. same issue.
<vagrantcish>gotta head out.
<mbakke>vagrantcish: That's with latest pointing to /gnu/store/ssmw0s12vq2hbr35x7xsc504sn9h9rcp-guix-4a007e2db ?
<jackhill>bavier`: cool, good luck! I'm KM4MBG
<Copenhagen_Bram>Is it possible to install the very latest experimental version of Cataclysm DDA, instead of the old stable 0.C, with guix?
<Apteryx_>how can I follow forks in guix-daemon? It's useless to debug the short infinite loop in the parent :D
<Apteryx_>I tried: set follow-fork-mode child
<Apteryx_>and then: break nix::LocalStore::exportPath(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, nix::Sink&)
<Apteryx_>and on a remote system I run: guix offload test
<Apteryx_>But gdb (running on the offload target machine) won't follow the spawned process.
<Apteryx_>Copenhagen_Bram: try creating your modified version of the package
<Apteryx_>using a recent version
<Apteryx_>If you are lucky it might be enough to just bump the version & hash
<Copenhagen_Bram>Apteryx_: hmm i might have to skip the hash, they update a lot
<Apteryx_>guix packages are frozen. You'll have to update it as often as you want the package updated.
<Apteryx_>(as any package, really)
<Apteryx_>otherwise if you're developing/testing it and it changes so often, you might be better git cloning it somewhere and spawning a guix environment so that you can build it and run it in place, updating it using git pull whenever you need to.
<Copenhagen_Bram>I thought guix was able to install multiple versions of packages
<Apteryx_>it can. But they need to exist (i.e. you need to update the version & hash)
<Copenhagen_Bram>Hmm. Maybe I could make a script to generate updated C-DDA packages?
<Apteryx_>There is already some machinery to update packages in guix; you could probably already use that or enhance it if it doesn't already support your use case.
<Apteryx_>by update, I mean refresh the package definition (bump version and hash in place).
<Apteryx_>See 'guix refresh' in the info manual.
<Copenhagen_Bram>So how do multiple versions in guix packages work?
<Apteryx_>They each have their definition
<Apteryx_>Look in the code for examples, I'm sure you can find some, e.g. for GCC
<Apteryx_>type: guix package -A '^gcc$' for example
<Apteryx_>I have to go. Gnight!
<vagrantcish>so, i simply re-added gnu/packages/patches/binutils-ld-new-dtags.patch ff19532fd545fd1b039d471155c2430c8efc1b27, ran "guix pull --url=/my/local/guix --branch=my-hacky-branch" ... which worked ... and then i could "guix pull" against master
<vagrantcish>i was able to reproduce it by switching to 5d669883ecc104403c5d3ba7d172e9c02234577c and then trying to pull 116ca65b583ba4e404289f1481dc3a3ffef1c3dd
<vagrantcish>so it seems to depend on what your starting guix commit is...
<rekado>vagrantcish: it really shouldn’t matter.
<rekado>vagrantcish: “guix pull” implements a trampoline that builds enough of the new Guix and then uses that to finish the upgrade.
<rekado>ACTION updates libreoffice
<vagrantcish>rekado: key word being "shouldn't"
<vagrantcish>maybe it's just dumb cooincidence ... but i tried the whole process twice.
<htgoebel1>civodul: wide-string compare in C works just like strcmp(A+22, B): wcscmp(A+22, B). I simply had counted my offsets wrong.
<rekado>libreoffice sure takes a long time to build.
<buenouanq>rekado: not as long as TeXlive
<rekado>I’m having problems with gitweb since a few months.
<rekado>I get these messages when connecting to
<Rukako>C++ programs in general tend to take a lot of time to build. Firefox, QT, webkit, and libreoffice have been some of the worst offenders in my experience.
<efraim>rekado: looks like theres something funky with my ISP, I'll look into ssh port forwarding to get the overdrive back up
***mubarak is now known as mubarak_
<g_bor_>Hello guix!
<g_bor_>rekado: I've found out why we have a duplicate in java-picard.
<g_bor_>I've sent an e-mail, but in case you have any idea how to solve it. In the build gradle file a dependency has an exclude module. I suspect, that this is not a unique case. Do we have a method to exclude a module from an input?
<rekado>updated libreoffice to
<g_bor_>rekado: I will need some more time to check what's up with dropseq-tools.
<efraim>rekado: the overdrive is currently up with ssh port forwarding at, same port as before
<rekado>g_bor_: I guess it’s something to do with the symlinks.
<rekado>efraim: great, I’ll give it a try.
<rekado>efraim: should I be able to ssh on that port?
<rekado>because it seems to time out.
<efraim>it should work
<rekado>failed to connect to Timeout
<efraim>could it be only one person can ssh in at a time with forwarding?
<efraim>i disconnected, try now
<rekado>same as before
<rekado>I get different IPs for and
<rekado>is that expected?
<efraim>yes, is at my house, is a VPS in Amsterdam
<efraim>port 52522?
<rekado>and I should connect to, not
<efraim>sorry, try it now, it seems it cut itself off
<rekado>oh, this is a new IP, isn’t it?
<rekado>then maybe I need to ask IT to punch a hole in the firewall first
<efraim>yeah, but the VPS's IP is static
<rekado>I think previously we only added a rule for, not for
<efraim>When I get back home I can move to but ssh might complain about fingerprints
<rekado>if that’s convenient I’d prefer that.
<rekado>changes to the firewall require tickets and communication with IT, so that would probably take longer.
<Apteryx_>hello! I'm trying to set breakpoints for the 'guix offload test' command, on the guix-daemon side. I can't seem to break in the forked process that the daemon spawns to process the job, even when setting 'set follow-fork-mode child'. Any idea?
<Apteryx_>I've set my breakpoint on this method: b nix::LocalStore::exportPath(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, nix::Sink&)
<Apteryx_>But it won't break on it.
<Apteryx_>rekado: I am the only one to see you apostrophes appear as '?' :)
<Apteryx_>Am I*
<soundtoxin>they don't appear as a ? to me, but they do look like a strange shape
<rekado>Apteryx_: ’ “ ” ‘ ` "
<rekado>what are your locale settings?
<rekado>this should look fine in a UTF-8 locale.
<Apteryx_>Ah, I think my locales might be broken. I haven't updated in a month or more; I'd like to get 'guix offload' to work before I do.
<rekado>We should make another release.
<Apteryx_>Yes, it's been a while!
<rekado>Mark wrote on guix-devel that the core-updates merge has left many packages broken.
<rekado>We should fix that as soon as possible and then make the release.
<efraim>We can still update guix to 0.14-12
<g_bor__>rekado: what are the priorities with the broken packages?
<rekado>I’m still getting this error: “no binding `invoke-error?' in module (guix build utils)”
<rekado>ACTION removes ~/.cache
<OrangeShark>rekado: I was getting that error last night
<rekado>Maybe I just need a newer version of Guix
<OrangeShark>invoke-error? was added in March
<soundtoxin>speaking of broken packages, qutebrowser doesn't work anymore
<Rukako>I just did a frech install and I get the no binding thing on guix pull
<rekado>soundtoxin: I think I’ve seen a bug report for qutebrowser.
<soundtoxin>alright, nice
<rekado>Rukako: fresh install from 0.14.0?
<mbakke>Rukako, rekado: In order to pull from an "old" guix (~1w), you'll first have to `guix pull --commit=5d669883ecc104403c5d3ba7d172e9c02234577c`.
<mbakke>We should get a new release out ASAP so that new users don't have to do that :-)
<rekado>thanks for the hint!
<Rukako>thank you for that
<rekado>and I agree
<rekado>but this means fixing packages
<rekado>I would appreciate it if people could investigate the issues Mark raised on guix-devel
<bavier>I'll take a look at the broken qutebrowser, but if anyone else wants to that'd be great too
<mbakke>I'm slowly making my way back into Guix development and will help out with what I can this week.
<mbakke>It's been nice with a good months sabbatical :-)
<jonsger>rekado: how can I reproduce or see those 900 failures
<mbakke>jonsger: See this page:
<mbakke>(warning: very slow, might time out a couple of times)
<jonsger>thats even slower then SUSEs bugzilla... :P
<rekado>this is why Tatiana is working on a web interface for Cuirass.
<pkill9_>qutebrowser rejects the native qtwebkit, and the other backend (qtwebengine) isn't packaged in guix
<soundtoxin> I saw this post from one of the qutebrowser devs (allegedly) earlier
<soundtoxin>and it made me wonder why webengine isn't packaged
<pkill9_>it's because it uses chromium
<pkill9_>there's a comment in qt.scm that explains why they remove qtwebengine
<mbakke>The problem with qtwebengine has historically been that it uses Chromium, which comes packed full of DRM and nonfree software. However it's possible to strip all that, which I've worked on for a while.
<mbakke>I'll give qtwebengine a go next week or so, hopefully I can reuse some of the Chromium stuff.
<soundtoxin>ah, didn't quite realize how it worked
<rekado>civodul: what do you think about tagging commit 5d669883ecc104403c5d3ba7d172e9c02234577c as “guix-pull-20180601” or similar?
<rekado>download speed from is 130KiB/s :(
<civodul>rekado: sounds good to me
<civodul>i noticed that problem today as well :-/
<civodul>rekado: BTW, did you remove the previous cuirass db on berlin?
<rekado>no, I did not remove it.
<jonsger>I have some MiB/s...
<rekado>from berlin it’s < 100KiB/s
<civodul>i get 42 MiB/s for
<civodul>which i think is not bad
<rekado>Oh, sorry, it’s the hydra mirror. I’m downloading icedtea-3.7.0-jdk from there at now 191KiB/s (was 80KiB/s).
<civodul>my theory is that we get the maximum bandwidth once the thing is cached by nginx
<civodul>i get 52M/s for
<jonsger>is it a network of mirrors or just one server?
<civodul>i think it's the first hit that's giving bad performance, especially for mirror.hydra
<civodul>jonsger: mirrors, and is independent but effectively mirrors things (thanks to reproducible builds)
<civodul>in other news, the Software Heritage archive is now accessible: \\o/
<jonsger>so can I add my personal server to the pool or
<civodul>but you can run 'guix publish' on your own server, if you want
<civodul>roptat: feel free to commit the .po file for guix-manual
<rekado>yay for Software Heritage!
<rekado>we should add support in Guix
<rekado>they don’t allow searching by SHA256, though, do they?
<bavier`>rekado: I think they do
<bavier`>rekado: e.g. their 'api/1/content/<q:hash_type:hash>/' endpoint
<bavier`>where 'q:hash_type:hash' can be "sha1", "sha1_git", or "sha256"
<roptat>civodul: understood. Can't do that today, but will do tomorrow
<ngz>Hello. Is there any problem with QWebView in Guix? Since Qt upgrade, Musescore cannot build due to "QWebView: No such file or directory" error.
<bavier`>the api seem amenable to a refresher too
<ngz>Since I see no similar report in the wild, I tend to think this is related to this specific distribution.
<civodul>bavier`: it'd be a slow-motion refresher i think, because SWH may not visit your repo as frequently as you'd like :-)
<mbakke>Oh no, the GCC ICE affects Chromium too (I recently switched from LLVM to GCC7).
<mbakke>By the way, did anyone try to add GCC8 yet?
<efraim>mbakke: I tried, the gccmov patch didn't apply cleanly
<efraim>Then I didn't try any more
<mbakke>Excellent, let's drop that patch for now and use that GCC8 in all packages that get the ICE :P
<rekado>bavier`: oh, I didn’t realise that. I only saw “sha1”.
<Gahrg>How can you add multiple encrypted luks partitions? I tried adding an additional entry in mapped-devices & file-systems ( but guix system init fails with "service 'file-system-/home' requires 'device-mapping-my-root', which is not provided by any service.
<civodul>Gahrg: oh i see
<civodul>for /home and /, instead of using labels, you should use /dev/mapper/XYZ
<civodul>and remove the 'dependencies' field
<civodul>that way, you'll automatically get fine-grain dependencies
<civodul>i.e., / will depend only on the mapped device for /dev/mapper/my-root
<civodul>and so on
<civodul>does that make sense?
<civodul>that said, i think it's fair to say it's a bug
<civodul>if you could send this to bug-guix, that'd be nice
<civodul>ACTION -> zZz