<rekado>serichsen: it’s fixed now. Thanks for the report! <eubarbosa>time to read geiser source code, I would like to behave more like elisp eval... <tavoris>The answer was I was missing pkg-config <Misha_B>is it possible to recursivly call gnu-build in one of the subdirectories of a build <tune>currently getting that info problem on my system profile. trying to update from the actual root account as I'm a bit scared of sudo recently <tune>guix (GNU Guix) 0.16.0-8.7ba2b27 <tune>interesting that the versions look different than when I run "guix --version" as user <tune>I'll just do a pull with the guix version I used to fix my user previously <reepca>Hm... I want to be able to use derivation-path? in (guix database), but I don't want to pull in (guix store), since it would cause a cyclic dependency. But I can't move derivation-path? to (guix derivations), because (guix store) uses it and (guix derivations) uses (guix store), so that would also be a cyclic dependency... <reepca>maybe I should just #:re-export it in (guix derivations) since I'll be using that anyway <reepca>I'm remembering why using git was a bit of a headache... rebasing really doesn't work well when you can't push with -f. <reepca>civodul: I've started pushing my recent work to the guile-daemon branch on savannah. I realize now that I should have split it into separate commits, but I think the changes to register-items (transactional registration and registering derivation outputs when the deriver is registered) may be of interest to the master branch as well <civodul>hi reepca! it's really great you're back working on this! <civodul>sure, i think we should try to merge things piecemeal as much as possible <civodul>i haven't looked at the branch yet, but do ping me when you think a specific change should be merged on master <reepca>I take it said changes should be in isolated commits? <civodul>that'll make it easier to review and to later find out where regressions come from, if any ;-) <reepca>Hm... so now I just need to figure out how to rewrite the remote's history when it disallows rewriting history. Should be interesting. <civodul>you can't push -f, but you can delete the remote branch and then push <civodul>rekado_: i'm planning to reconfigure berlin today to get the latest guix-daemon <divansantana>how can one get a Vodafone (Huawei) to work on guixsd? Would it work? Or does it require some nonfree component? <civodul>(in particular fixing the EMLINK issue) <divansantana>Currently I plug it in and it doesnt detect it as an interface only as sda. <divansantana>I don't see any modemmanager services under herd. And none running under ps. The manual says that it as part of desktop-services, should it should exist on my setup. ***rekado_ is now known as rekado
<rekado>we’ll have to manually copy the kernel and initrd to /store <rekado>I’m currently reconfiguring more of the build nodes <rekado>all build nodes are now reconfiguring <g_bor>I managed to create a layered DAG from our derivation graph. <g_bor>Now only the hard part remains :) <g_bor>I used the following algoritm: I removed the derivations with no input, recursively. This way the number of layers is the longest path in the graph, the length is 109, and on the top there is maven :) <g_bor>For the next step I will need the information which module corresponds to the nodes. <rekado>there is no mapping from modules to derivations. <rekado>but modules contain package values that can result in multiple derivations each <rekado>you could go through each module and compute all derivations for all packages. <civodul>rekado: actually net-snmp fails to build :-/ <rekado>civodul: I faintly remember it failed before, but only on berlin…? <g_bor>I would like to the following: List the modules in layer0, create a module-layer0 module for each one that is present. Then add in the layer0 packages to the module-layer0 modules. Then check if the module-graph is a DAG. If it is, then add in layer1 packages, and additional layer1 modules. Then check again, if it is still a DAG. If not, then freeze the previous modules, and start over from the layer1, and so on. *jonsger praises civodul for consequent usage of OpenStreetMap :) <htgoebel>g_bor: Are you working on a maven build-system? <roptat>civodul, re osm, it's best to send a link to the node or a marker (on the right panel, there's a "share" tab where you can check a box to add the marker) because there are so many nodes on the map it's hard to find the right one ;) <roptat>civodul, my train arrives at 7:50pm wednesday, and I'll probably have a big luggage, so I'll drop by my hostel first <civodul>roptat: ok i'll do that next time, i'm not an advanced osm user as you can see <roptat>I'd like to join you afterwards, but will someone be on IRC? Or can you share your phone number? <civodul>is your hostel close to Au Bon vieux temps? *civodul doesn't have a mobile phone <civodul>if someone else is coming, you'll have to get their phone number :-) <roptat>ah, actually not, but it's 10 minutes by foot from Au bon vieux temps <roptat>according to graphhopper which underestimates my walking speed :) <civodul>then if your train arrives at 7:50 at Midi, that's probably like 20mn to get to that area <roptat>so, 20 minutes from the station to the hostel, maybe ten minutes to check in, and 10 more minutes to go to the bar... I'll probably be there around 8:30 <civodul>rekado: texlive-latex-seminar is empty *civodul goes back to the big "texlive" :-/ <htgoebel>- oh I just discover that metager does not yet support markers. <roptat>civodul, at least you and cbaines it seems :) <g_bor>htgoebel:roptat is working on that. <jonsger>htgoebel: their tiles are a little old... <roptat>htgoebel, ah yes, I'm missing some knowledge on how plugins work (I need them before I can actually run maven, since they're used during the build) <roptat>I found that plugins have a META-INF/plugin.xml file, and that is generated by maven-plugin-plugin <htgoebel>jonsger: How do one get teh age of the tiles? <roptat>but it's a maven plugin, but I need it to make it an actual plugin... arg <htgoebel>roptat: IC, so welcome back to circular-dependency-hell :-( <roptat>so, I've built maven-plugin-plugin (that was a lot of work already) but I don't know how to use it <roptat>and I don't have a plugin.xml for it <roptat>I guess I need to learn what is inside plugin.xml to produce it with guile <roptat>then I'll have plugins and I'll probably be able to use them <roptat>so I'd say I'm not too far away from a maven-build-system :) <jonsger>htgoebel: looking at the stuff I changed recently and see if its there... <roptat>like, I have built the maven-resources-plugin, but it's not picked up correctly by maven because it lacks a plugin.xml. I think that's the only real obstacle <roptat>I built maven-plugin-plugin, but that was probably a mistake, I should simply generate them with guile <htgoebel>roptat: Do you need some help (plugin.xml)? I might be able to spend some time on it this afternoon <roptat>actually, I've added a point to the agenda of our guix days in Bruxelles about it <g_bor>I have found something really interesting: it seems that the guix package graph is not a DAG, but the derivation graph is... <g_bor>I am still investigating that, but it seems to contain a subgraph, where every node has at least one dependency... <g_bor>I mean form the same subgraph... <civodul>g_bor: the package graph is a DAG, if it were cyclic we'd have troubles computing the derivations :-) <g_bor>then I am doing something wrong :) <g_bor>I will have a look at the problematic part of the graph, to see if I can find it out... <civodul>it could also be that the 'guix graph' output shows cycles where there aren't any, but i think "guix graph -t packages" shouldn't have that problem <g_bor>ok, I assumed that these two invocations are the same... <g_bor>I have found a cycle: it is gcc-cross-i686-linux-gnu@5.5.0 and coreutils@8.30 <htgoebel>roptat: What is the test-case for testing maven resp. the plugin? <roptat>I don't have a test case. I tried to add a maven-build-system, similar to other build systems, and see how it failed <roptat>the first failure was about not finding plugins <roptat>I'm afraid I lost the code from that attempt, but it wasn't very complicated <roptat>I think you should be able to replace the build phase of a package with (invoke "mvn" "build") <roptat>you could also test outside of a guix container first, by creating an empty maven project with "mvn archetype:generate" (which should be easier to build) and run maven with "mvn build --offline" <roptat>the first thing it complains about is that it can't find maven-compiler-plugin (I think it used to complain about maven-resources-plugin first, before), and that is because it's not present in ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.8.0/maven-compiler-plugin-3.8.0.jar <roptat>and it should contain the plugin.xml file + metadata for maven to understand that the file is valid <roptat>maybe "mvn generate-resources" will lead maven to look for the resources-plugin first <htgoebel>I assume I need /some/ package to try to run maven on, right? <roptat>sure, or as I said, you can generate one with maven, and then try to build it offline <roptat>I think the maven build system should provide at least the plugins required to build an empty project <roptat>not sure if we need to provide more by default <roptat>and I think the first experiment is to see what is required inside the jar for maven to pick it up <roptat>then we'll have to write more code (to override hardcoded plugin/dependency versions, place packages at the right location for maven and put the right metadata in our packages) <roptat>so we don't need to create an actual guix package for that first experiment, but of course you can try with any package that requires maven <civodul>rekado: i've just reconfigured berlin and restarted guix-daemon, but i haven't copied the kernel + initrd <rekado>I copied $(readlink -f /run/current-system/kernel) and $(dirname $(readlink -f /run/current-system/initrd)) to /store <rekado>civodul: I’ll take a look at texlive-latex-seminar <civodul>i realized its source doesn't contain Beamer anyway, which is what i was after <rekado>I won’t be able to make it to “Au bon vieux temps” this time; will arrive on Thursday morning if all goes well. <civodul>you'll miss the great beer and very special atmosphere ;-) <civodul>i think it was wingo who introduced me to that place <rekado>a little more space for the rest of you all. You’ll need it :) <wingo>profitez bien :) & see yall friday morning (or thursday evening perhaps?) <jonsger>rekado: I could bring you a Frankonian one, if you wanna have a great beer :P <rekado>we don’t seem to even have a beamer package <tune>"M-x guix-generations" in my emacs takes forever and then times out without completing <tune>I restarted emacs and it completed fine now. I must've done something weird. <efraim>Do we want a guix-fosdem channel? <cbaines>savannah.gnu.org and debbugs.gnu.org look down to me :( <civodul>efraim: i think we could (ab)use this channel :-) *rekado fights with infiniband and openmpi <rekado>an antagonistic IT admin found a test case where openmpi from Guix doesn’t work, but the artisan hand-compiled version does… <rekado>so it’s probably missing hardware support <rekado>I’m now adding opensm and see if that helps *rekado is an openMPI noob <bavier>civodul: I've started looking at the openmpi update <cbaines>As I've been looking at the desktop services to try and make printing better, I thought I'd go and update the style of them... I've just made it through upower and I think I'll stop here. <cbaines>For some reason, writing out documentation feels quite slow to me. <civodul>make sure to use define-deprecated BTW <cbaines>Yeah, especially making sure I've got all the default values for the 12 fields right! <civodul>but! if ten of us take care of a couple of them, we'll be done very quickly :-) <rekado>with openmpi 4.0.0 I can’t configure because it says /gnu/store/5sjian3kxz7kwdya6rw21f6iv7bv7nkc-psm-3.3.20170428/lib/libinfinipath.so.4: undefined reference to `minor' <cbaines>and yep, I've been looking at the avahi-service-type for comparison, and that uses define-deprecated :) <civodul>rekado: looks like a glibc 2.28 vs. 2.27 thing maybe? <civodul>so maybe psm builds fine, but actually ends up with a dangling reference <civodul>ipath_proto.c: In function ‘ipath_userinit’: <civodul>ipath_proto.c:539:32: warning: implicit declaration of function ‘minor’ [-Wimplicit-function-declaration] <civodul>rekado: so you need to add <sys/sysmacros.h> <cbaines>Savannah and Debbugs look to be back \o/ <rekado>civodul: thanks for the hint. I built OpenMPI 4 with opensm support; now testing… <cbaines>Ooh, I've just spotted this new progress bar when building Kodi, very cool! <civodul>too bad things using the GNU build system don't have progress reports <rekado>civodul: texlive-latex-beamer now exists. <bavier`>rekado: sorry for the delay on getting openmpi updated; <rekado>this is just a test in guix-bimsb <rekado>I’ll leave the update in Guix proper to you :) <bavier`>rekado: thanks! we should be able to add the openib config flags. <bavier`>it's hard to test that sort of stuff without the hardware :/ <rekado>I’m almost done installing this version on the cluster. <rekado>the new openmpi’s mpicxx fails on a simple test program with errors like this: <rekado>/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libdl.so.2: undefined reference to `_dl_catch_error@GLIBC_PRIVATE' <rekado>ah, works fine after installing gcc-toolchain <bavier`>I wonder if the undefined reference couldn't be fixed with some additional mpicxx wrapper arguments <rekado>civodul: sorry for the confusion: the URL is actually workflows.guix.info, not workflow.guix.info <nckx>What time do the Guixfest doors open on Thursday? *civodul .oO( how 'bout bringing a bunch of refcards? ) <cbaines>I've just got my printer working, so I might be able to print some stuff (A4 only) <cbaines>(going offline, I'll be back online in a bit...) <civodul>cbaines: yes we do: gnu.org/s/guix/guix-refcard.pdf or in maintenance.git/doc/refcard <nckx>civodul: If my printer works OOTB with GuixSD I'll bring a few. <civodul>nckx, cbaines: i've just pushed an update in maintenance.git <civodul>you can do: cd doc/refcard; evince $(guix build -f build.scm)/*.pdf <civodul>i'm printing 40 of them, if you print more we can distribute 'em at FOSDEM! <efraim>sneek_: later tell civodul today the overdrive reconnected to my VPS 145 times <tavoris>Was it a conscious decision for the default '/etc/profile' not to load '~/.profile'? <nckx>cbaines: I noticed from afar. Seemed a bit GNOME-specific, though? <cbaines>nckx, I think system-config-printer will work under any desktop environment <nckx>cbaines: Thanks. I'll give it a try tomorrow when/if the toner arrives. <reepca>hm, tried to delete origin/guile-daemon so I could recreate it and split an old commit, but on trying it I get "remote: fatal: bad object 0000000000000000000000000000000000000000" <reepca>but I guess it worked anyway. Strange. <g_bor>reepca: this seems to be 'normal'. <g_bor>I could not yet find out where this message comes from <reepca>hm, it'd be nice if "make clean-go" would ignore test-tmp. <reepca>aye, I've sort of got 20GiB in there and emacs really doesn't like the long lines <reepca>bavier`: just tried it, that's much better! <rekado>Copenhagen_Bram: it only takes as long as it takes to build or download the packages you use. <Copenhagen_Bram>Wait, is that a normal experience? I ran `guix system --no-substitutes init /mnt/etc/config.scm /mnt/` last night and it still says it's downloading and building packages <rekado>the question is: why are you building the packages? <Copenhagen_Bram>Because I like compiling everything and not having to trust the binaries <rekado>oh, well, if you want to compile everything it’s going to take a long time. <rekado>longer than other distros because of all the bootstrapping. <Copenhagen_Bram>The bootstrapping is cool. OriansJ tells me they're making it possible to bootstrap from a tiny program written in Hex all the way to GuixSD <bavier`>Copenhagen_Bram: it would be cool if you'd like to run `guix challenge` and report any reproducibility issues, since you don't mind building locally ;) <Copenhagen_Bram>But... imagine if you tried to install Linux From Scratch?? It would take so long if you compiled everything, longer than this if you're doing it manually. I bet LFS probably involves downloading at least some binaries <cbaines>Copenhagen_Bram, if you have more than one machine, you can setup offloading so that you can build packages across them <Copenhagen_Bram>bavier`: could I run something like `guix system --no-substitutes --check init` to challenge every package that I install? <bavier`>Copenhagen_Bram: that should work, yes <bavier`>Copenhagen_Bram: though, '--check' builds everything locally twice, and checks that each is identical <bavier`>Copenhagen_Bram: 'guix challenge' checks that what you've built locally matches what you would have gotten from a substitute server, and only requires a single local build <bavier`>two types of reproducibility, both important <bavier`>Copenhagen_Bram: no, you'd need to build first, optionally with --check, then 'guix challenge' <bavier`>'guix challenge' operates on store items already present <Copenhagen_Bram>how do i check all types of reproducibility on all installed packages? <bavier`>Copenhagen_Bram: you could build all packages locally with --check (I don't know if there is a good short way to do this), and then simply run 'guix challenge --substitute-urls=...' <rekado>if you’re not using substitutes you don’t need “--check” as you’ll have local builds for everything <bavier`>Copenhagen_Bram: actually, there's a snippet in the manual, section 5.1, that 'builds all the available packages' <kmicu>Copenhagen_Bram: keep in mind that compiling will be that long after each core update. Reproducible builds let us trust binaries; compiling sources giving the same binary is wasteful. (Unless you already have solar panels then go ahead I guess ;) <Copenhagen_Bram>didn't think that this compiling everything would be bad for the environment <Copenhagen_Bram>although is it any more bad for the environment than just leaving my computers on all the time? <OriansJ>rekado: Do we have a proper procedure for guix challenge reports? <rekado>a package that is not reproducible is a bug, so reports should go to bug-guix@gnu.org <vagrantc>a very small, narrowly defined part of netbsd <rekado>these reproducibility numbers are very confusing <vagrantc>which is still awesome; having a reproducible core set is great progress and work! <cbaines>reproducibility stats are always a bit slanted, as it's boring to list the conditions under which you tested the packages <Copenhagen_Bram>So... should I keep compiling everything or should I go ahead and use substitutes to install, and check and challenge later? <kmicu>Copenhagen_Bram: Don’t worry too much. Compiling is still orders of magnitude less problematic than mining cryptocurrencies with a useless proof of work. You at least check determinism in Guix packages. Just keep in mind you need to recompile almost everything on the next core update. <cbaines>you don't say 80% reproducible when the filesystem order was randomised, the system date was altered, the number of cores was different, ... <bavier`>a collection of reports from 'guix challenge' would be as real-world as we could get as far as reproducibility <vagrantc>i literally earlier today was thinking about attempting to do some systematic reproducible builds testing for guix... <bavier`>(and then the questions about trusting the stats would come in) <OriansJ>rekado: with a standard for the bug reports so we can make it easy for people to find and know the status of those irreproducible issues <civodul>we could maybe revive it on guix.info <bavier`>it'd be neat if individuals could contribute to such a report <civodul>it would be hard: you'd need to trust them to not send "random" hashes <civodul>or just the same hash as the one you published <civodul>you'd need a proof of work or something <bavier`>could we start with accepting gpg-signed reports? *kmicu went to register GuixCoin⸮ *bavier` inserts joke about /guix/store on the blockchain <tavoris>the Contributing info doc says there's work to be done on packaging; is there a priority list for what packages are most wanted or something similar? <bavier`>tavoris: otherwise, 'packaging work' can also mean fixing builds of existing packages, or testing/reviewing patches from guix-patches@gnu.org <bavier`>tavoris: and also any packages that you think are missing <tavoris>bavier`: is there some CI reports somewhere which tells of broken (failing builds/test) of existing packages?