<mbakke>rekado_: In the past I've just deleted core-updates, then "promoted" the -next branch and deleted that too. <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>ACTION guesses ARM really wanted to be sure they were at the top of some architecture sort-order <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? <mbakke>vagrantc: That's very odd, that patch disappeared a long time ago. But it was in 'master' until very recently. <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. <mbakke>Hah, that will be nice indeed... <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 ... <mbakke>vagrantcish: That's with latest pointing to /gnu/store/ssmw0s12vq2hbr35x7xsc504sn9h9rcp-guix-4a007e2db ? <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_>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_>If you are lucky it might be enough to just bump the version & hash <Apteryx_>guix packages are frozen. You'll have to update it as often as you want the package updated. <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. <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_>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 <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. <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. <rekado>I’m having problems with gitweb since a few months. <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_>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? <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 flashner.co.il, 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 hydra@flashner.co.il on that port? <rekado>failed to connect to flashner.co.il: Timeout <efraim>could it be only one person can ssh in at a time with forwarding? <rekado>I get different IPs for git.flashner.co.il and flashner.co.il. <efraim>yes, git.flashner.co.il is at my house, flashner.co.il is a VPS in Amsterdam <rekado>and I should connect to flashner.co.il, not git.flashner.co.il <efraim>sorry, try it now, it seems it cut itself off <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 git.flashner.co.il, not for flashner.co.il. <efraim>When I get back home I can move git.flashner.co.il to flashner.co.il 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_>rekado: I am the only one to see you apostrophes appear as '?' :) <soundtoxin>they don't appear as a ? to me, but they do look like a strange shape <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>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>Maybe I just need a newer version of Guix <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. <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>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>(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>and it made me wonder why webengine isn't packaged <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. <rekado>civodul: what do you think about tagging commit 5d669883ecc104403c5d3ba7d172e9c02234577c as “guix-pull-20180601” or similar? <rekado>download speed from mirror.hydra.gnu.org is 130KiB/s :( <civodul>i noticed that problem today as well :-/ <civodul>rekado: BTW, did you remove the previous cuirass db on berlin? <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 <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: mirror.hydra.gnu.org mirrors hydra.gnu.org, and berlin.guixsd.org is independent but effectively mirrors things (thanks to reproducible builds) <jonsger>so can I add my personal server to the pool or mirror.hydra.gnu.org? <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>they don’t allow searching by SHA256, though, do they? <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 <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 (https://paste.debian.net/1028394/) but guix system init fails with "service 'file-system-/home' requires 'device-mapping-my-root', which is not provided by any service. <civodul>for /home and /, instead of using labels, you should use /dev/mapper/XYZ <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>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 