<str1ngs>I'll build on my publish server. and when I package -i sometimes it will randomly build when I least expect it <vagrantc>or rather, after interrupting the first run, and re-running it, it ended with: Guix already up to date <vagrantc>ACTION is mostly cargo-culting the nginx configs, so there's a distinct possibility of problems there <str1ngs>I'm a guix noob. I was running under the assumption I was the issue <vagrantc>and guix challenge is spitting out errors no matter what substitutes i use <rekado>vagrantc: could you please send details to bug-guix@gnu.org? <vagrantc> proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; <ofosos>fuck, this krita thing seems to compile even longer than the kernel ***pksadiq__ is now known as pksadiq
<Apteryx>Hello; this got printed while doing a guix pull (notice that a newline is missing): "loading... 26.1% of 656 filesrandom seed for tests: 1512443119" ***pksadiq_ is now known as pksadiq
***pksadiq_ is now known as pksadiq
***pksadiq_ is now known as pksadiq
<g_bor>gtk+-2.24.31 does not build on current core updates. <g_bor>FAIL: abicheck.sh PASS: pltcheck.sh ============================================================================ Testsuite summary for gtk+ 2.24.31 ============================================================================ # TOTAL: 3 # PASS: 2 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See gtk/test-suite.log Please report to http://bugzilla.gnome.o <g_bor>--- expected-abi 2017-12-05 05:45:34.472000000 +0000 +++ actual-abi 2017-12-05 05:45:34.508000000 +0000 @@ -1,3 +1,4 @@ +g_cclosure_marshal_BOOLEAN__BOXED_BOXED <rekado_>hmm, I built guile-git locally, added it to the load path and load compiled path, but “guix pull” still tries to build it itself — and it downloads from the old invalid URL. <rekado_>I’ll cheat. Changed the URL for guile-git in the derivation :-/ <civodul>rekado_: so you weren't able to download it from a mirror? <rekado_>I was trying to see if there was a way to build it from source and not to depend on a substitute. <rekado_>but fixing the guile-git problem is not enough; the libgit2 problem was next, so I authorized hydra’s key and downloaded the substitute. <civodul>i meant using a substitute for the source, not for the binaries <rekado_>how would users fix this who want to reproduce an environment at a later point in time with an older version of Guix? <rekado_>we have “--with-source”, which might help in the case of guile-git, but we have no way of faking hashes for regenerated tarballs. <efraim>g_bor: I got the same test failure on aarch64 on core-updatea <g_bor>efraim: Do you have any idea about it? <g_bor>I rebuild it now, to see if the message changes. <g_bor>First two lines seem to embed a timestamp very near to each other. <efraim>Someone suggested it might be related to dbus changes <g_bor>Might it be a race condition? <g_bor>It really seems, that these should come from the same derviation... <g_bor>It seems, that abicheck.sh is using a regexp to filter nm output. Maybe the g_cclosure thing escapes through the regexp... <civodul>rekado_: normally we have those tarballs in cache, so IMO we should simply fetch them by default instead of going to the upstream site <civodul>of course, if we don't have a copy of the tarball, we're screwed <civodul>but we should arrange so that it never happens <civodul>i wish SWH could help us, but unfortunately here are technical issues <rekado_>yeah, I just looked over the conversation on the bug report again. <rekado_>I agree that fetching them from the cache first seems like a good idea. <efraim>we should look into adding a fallback option of checking debian for a name-version_orig.tar.gz and/or fossies <civodul>efraim: technically we could add them to the content-addressed mirrors in (guix download)... but they're not content-addressed <civodul>so they might give us different pieces of code <efraim>Wouldn't we check the hash also? <civodul>mb[m]1: somewhere you suggested removing a glibc graft because the CVE was considered "minor" <ofosos>civodul: that thing yesterday was a dependency from graphics.scm to kde-frameworks.scm, after I moved krita from graphics to kde, everything worked fine <ofosos>admittedly not a 'fresh' checkout :( <rekado>efraim: took me a day to build clementine on my laptop <efraim>Took me about 4 hours, but qtwebkit was most of it <efraim>Now I'm building qt with and without ccache to see if it speeds up the build time <ofosos>efraim: looks like krita is not maintaining their unit tests well, but it would work with "offscreen", just not right now <brendyn>rekado: do you have patches for clementine? <civodul>ofc better error reporting would have helped <rekado>brendyn: clementine is available in Guix <brendyn>The description says it's inspired by Amarok 1.4, but isn't it actually forked from Amarok 1.4? <wingo>is guile 2.2.3 going to become guile-2.2 for the next guix release? <civodul>wingo: not for this week's Guix release, but for the next one <civodul>the main issue being that we have to rebuild a lot <efraim>We can do that on core-updates, we still need to bump glibc some more <brendyn>Does anyone have any information on the 10% of non-deterministic guix packages? What are the most common reasons for them? <civodul>basically there are a few key packages that produce non-determinisic output, such as Python and its .pyc files <brendyn>civodul: Do those require upstream changes. <civodul>search for "reproducib" or "determinist" :-) <brendyn>Sometimes the 1970 date bubbles up into a user facing program. It wouln't be nice if documentation said it was made in 1970. I wonder if there is a better option. ***cuckle[m] is now known as bighugmug
<civodul>i've never faced this situation, except sometimes in --version output or similar <bighugmug>hey, I know proprietary firmware is not supported, but I was wondering if anybody has had any success installing iwlwifi? I've looked for anywhere on the USB image file and the initrd to see if there's any directories containing .ucode files, but can't see anything <civodul>as you wrote, it's not supported, which is why you didn't find these files :-) <nee`>brendyn: patching out the line that prints the date would probably be the best option. Maybe replace it with "Built in GNU Guix". ;-) <g_bor>It seems, that core-updates gtk+ 2 has a broken test. <g_bor>We had a discussion about it here in this morning. <bighugmug>civodul: thanks, didn't realise ucode was only for proprietary blobs. Any pointers for what I should read up on if I intend on trying to manually add proprietary drivers? <g_bor>It seems, that some g_cclosure_marshal abi is leaked from libgtk, and abicheck.sh fails because of that. <g_bor>For now I really don't know if it is right that this symbol is exported. <g_bor>Anyone knows something about this? <g_bor>All the other symbols are named like gtk_... <wingo>i think that symbol is meant to be exported <g_bor>For now we could make the test pass the following ways: <wingo>could be wrong but it's a very old story... <civodul>bighugmug: no, no idea; the project is not focusing on this as you can imagine <g_bor>Patch the .symbols file, so that it also ha the g_cclosure_marshal thing, or patch the file generated from the library to only include symbol names starting with gtk_ <g_bor>Both these solutions will make the test pass. <g_bor>The interesting thing is that only one of these symbols appear in the output of the nm command used in the abicheck.sh. <wingo>g_bor: those changes will change gtk abi. i think there are some external libs that rely on those exported symbols. <wingo>so, better to avoid touching it imo <g_bor>ok, so changing or disabling this test is ok? <g_bor>Or should we check why we have this difference? <g_bor>I also think it is not wise to hide the symbol, but I think it is ok to check that only symbols matching the gtk_ pattern are the same... <g_bor>I don't think that a test in the gtk subdir should care about these g_cclosure_marshal symbols. <g_bor>I don't know if it really is a problem if a library provides a superset of the abi anyways... <str1ngs>interesting, seems guix gcc startup files are modified to use the glibc linker in these store? <str1ngs>[Requesting program interpreter: /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/ld-linux-x86-64.so.2] <str1ngs>just found it interesting. saves me from hacking the linker. if I build something manually <civodul>these hacks are in the gcc and glibc package definitions <str1ngs>also I guess I need to use LD_LIBARY_PATH it seems <str1ngs>this is just for building manually, will be while before I can create a package for this. <civodul>str1ngs: you should install the 'gcc-toolchain' package, not just 'gcc' & co. <civodul>'gcc-toolchain' does the right thing <str1ngs>ah I was going to ask about a build-essentials like package <brendyn>can packages use hash functions other than sha256? <str1ngs>I kinda got ahead of my self hacking away here :P <civodul>brendyn: internally yes, but the API doesn't expose that yet <brendyn>It'd be nice to ensure such future options are not a pain when it comes time. <brendyn>blake2 is twice as fast as sha256 too, hence the curiosity. <civodul>ACTION fixes a bug in grafts: no more expat builds, wo0t! <civodul>did everyone built expat a few times recently? <civodul>i actually built it only once long ago and never gc'd it since, so i didn't notice that we were all rebuilding it <rekado>I love bug fixes relating to grafts! <rekado>the bugs themselves: not so much. <civodul>waiting for 'make check' to complete and then i'll push <civodul>i have the idea to revamp the graft implementation using delimited continuations to implement "build rounds" <rekado>one of the build nodes has a broken disk. Gotta re-install GuixSD there. <str1ngs>is it possible my host system is polluting run time libs? <rekado>the storage seems to be ready now, but before I use it in production I’d like to run a couple of tests to ensure it’s properly set up for speed. <civodul>str1ngs: are you sure you removed binutils, gcc, etc. from your profile? <rekado>this is going to be XFS over NFSv4. <rekado>on the file server itself it’s XFS; that’s high-speed connected to a server, which exports the file system over NFSv4 <civodul>got it (i'd call that NFSv4 over XFS, a matter of perspective ;-)) <rekado>the file server itself is just a bunch of disks with RAID cards and cache, really <str1ngs>is there away to start with a fresh profile? <str1ngs>I should probably use environments for this I think <civodul>"guix package --switch-generations=0" may work <civodul>environments should be nice for development <rekado> try pure environments if you don’t want to mess with your profile. <str1ngs>I'm kinda new to guix methods. so environments are a bit complex for me right now. <str1ngs>ahh removing binutils and gcc did the trick <rekado>str1ngs: they might be easier than profiles, actually. You just run “guix environment --ad-hoc this that here there” and you end up in a sub-shell where “this”, “that”, “here”, and “there” are available. <rekado>you can further control your environment by adding “--pure”, which resets some environment variables. <rekado>or with “--container” for even more isolation. <str1ngs>thing is I'll be using this in profile anyways. <str1ngs>but... it would be good to use containers, and or environments for testing. <str1ngs>I think I need to convince the GNU farm admins to install guix <civodul>i agree that it'd be a good idea to have Guix there <civodul>i think about it every time i see a message on the user list with someone asking to install/upgrade this or that package :-) <str1ngs>I will touch base with osuosl, once I'm familiar with guix more <str1ngs>osuosl has quite a few servers in the compile farm, that I'm familiar with. <str1ngs>there could be issue on the admin side for them. like security and storage paths <str1ngs>though inherently guix is rather nice when it comes to security. I may just have to convince them of that. <civodul>rekado: do you feel like adding the ASCII/ANSI art logo to /etc/issue in the installation image? <str1ngs>does guix use ~/.guile ? or only when using the a REPL? <vagrantc>if i run: "guix pack -s x86_64-linux --localstatedir guix" does that build a tarball for guix i can basically unpack on a foreign distro? and what version of guix does that tarball contain? the version used to build the tarball? <vagrantc>but it still seems to rebootstrap everything <vagrantc>admittedly, so much scrolls past it's hard to tell what exactly is going on <civodul>vagrantc: it produces a standalone tarball containing the current 'guix' package <vagrantc>currently after unpacking it and configuring it as described in the documentation above ... running "guix pull" is building gcc-4.9... <civodul>not to be confused with the Guix you're currently using :-) <vagrantc>ACTION was hoping to avoid having to rebuild the thing on the installed machine <vagrantc>well, gcc-4.9.4/... is scrolling past the screen <vagrantc>weather it's building that as a prerequisite for some other package or not, i have no idea <efraim>If you check the makefile, I think you want 'make binary-tarball' <civodul>efraim: it's the same thing as what vagrantc did <vagrantc>i think i accidentally diabled substitutes <civodul>that would explain why you're rebuilding the world :-) <vagrantc>e.g. i used an empty variable and specified --substitute-urls="" <vagrantc>after cancelling that, it now appears to be building glibc-intermediate <brendyn>clementine is now installed, but it fails to play audio, complaining about gstreamer <civodul>ok, that could have something to do with grafts <civodul>maybe one of the things i fixed in version-0.14.0 <rekado>brendyn: you may need to install gstreamer plugins <str1ngs>I need to get glib-networking to use a ca bundle <rekado>brendyn: huh? Gstreamer plugins are in Guix, but it’s up to the user to decide which to install. <brendyn>hmm ok i assumed everything like that would be in inputs <rekado>brendyn: plugins are always up to the user. <brendyn>Ok I hadn't thought of the difference between an optional dependency and a plugin <g_bor>I just got some more info from the gtk+ irc channel: <g_bor>17:49 < EmmanueleBassi> gabriel_: It's fine to ignore 17:49 < EmmanueleBassi> gabriel_: GLib added a new marshaller in its public API 17:50 < EmmanueleBassi> gabriel_: And the `abicheck.sh`in GTK+ 2.24 hasn't been updated because GTK+ 2.24 is in deep maintenance mode and very few people test it against newer versions of GLib 17:50 < EmmanueleBassi> There's the question as to whether GLib should have added a new marshaller in the public AP <g_bor>EmmanueleBassi> But that happened a long time ago <g_bor>so, I think it is fine to update the abicheck.sh in a way to ignore glib marshaller symbols. <rekado>g_bor: sounds good to me. You could disable that whole test instead of trying to patch the script. <civodul>rekado: i should be able to start the build process tonight and formally release tomorrow <rekado>I’d rather not add the prettier logo today, lest I screw up something in the last minute <civodul>it should be a breakage-free change, but either way is fine :-) <civodul>i'll upload a rebuilt ISO in a few minutes, just so people can see if there are any other obvious issues <rekado>right, but I’d like to be sure and would have to rebuild the image and boot it. <myglc2>Oops, Sorry, trying to figure out erc doctor <str1ngs>when I do something like. guix package -i git -n . it does not say it needs to build anything other then some drv's . however when I actually run guix package -i git. there is more to build then with -n <str1ngs>should -i git and -i git -n not show the same actions? <efraim>228 minutes to compile qt@5 with ccache added, now to time it without <janneke>efraim: ccache, that's interesting; how? <efraim>i noticed it was a configure option, added to native-inputs, '-ccache' configure option and set homedir to /tmp <janneke>ah, right. i tried to create a specific ccache origin package -- something generic would be nice <g_bor>Ok, I just sent a patch for gtk, fixing the test on core-updates. <bavier>efraim: but the cache isn't persisted across builds, is it? <g_bor>Trying to build the java stuff again:) <efraim>nope, but qt might have a bunch of repeated bits, so i figured I'd test it out <myglc2>{Uptime} [15:21pm up 18:33, 1 user] {Load average} [0.12, 0.08, 0.07] <myglc2>myglc2 Duh... still trying to learn erc <janneke>nix/libutil/types.hh:26:12: error: ‘std::list’ has not been declared <vagrantcish>In procedure public-lookup: Module named (system repl debug) does not exist <janneke>oops, i had a file called `list' in CWD my bad <civodul>janneke: what compiler are you using? <janneke>civodul: ./pre-inst-env guix environment guix --pure gives me: 5.4.0 <civodul>could it be that there's something else interfering? <janneke>it works now, `list' in CWD gives interesting results ;-) <janneke>i had a file called `list' with just a list of words in CWD, no idea where it came from <janneke>then c++'s #include <list> apparently preferred CWD <str1ngs>I have this thing while using guix's emacs. if make a new frame my font is not applied. I have to use (set-default-font) for that frame. <str1ngs>I also get a this warning . GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. <vagrantc>ACTION isn't entirely sure when to mumble on irc vs. when to submit a proper bug report yet <civodul>you can always check on IRC if it's a "known problem" <vagrantc>yeah, that's generally what i'm trying for first :) <vagrantc>which doesn't exactly inspire confidence ... but ... :) <civodul>yeah well, it does suggest we should look more closely at threading issues... <efraim>looks like its slower to build qt@5 with ccache than without it <efraim>ACTION heads off to bed and to ponder this development <str1ngs>efraim: do you check hits with ccache -s etc? <str1ngs>keep in mind, ccache improves with rounds. first round will always be on par as if ccache was not used. <bavier>or slower, because of the caching <str1ngs>if it's slower then, generally it's disk IO bound. kinda rare these days <str1ngs>my experience with ccache is generally almost always faster. provided your environment is setup right. in the context of guix I dunno <str1ngs>example if you only link gcc to ccache and not your host tuple. say x86_64-guix-linux-gnu you'll have misses when gcc is invoked that way. <vagrantc>ACTION would be a little disturbed if ccache were faster on than without on the first build of any given object <str1ngs>you'd be surprised, configure can do many redundant gcc tests <civodul>ACTION finds a 10-hour old message that hadn't been sent grrr