<taohansen>running into a catch-22 here: i give slim-service its xorg service module. if i reconfigure, xorg-service is provided more than once. if i remove the module slim-service becomes unbound <taohansen>can i tell guix to ignore and continue its reconfigure? <sneek>Welcome back bms_, you have 2 messages. <sneek>bms_, oriansj says: that the discussion about stage0 have moved to #bootstrappable <ng0>sneek: later tell atw: no idea. I'm probably not coming, there's CCC congress in december and a GNUnet meeting/workshop in january. I think there'll be Guile/Guix related talks in other rooms. <rekado>plan for today: update bioconductor importer, update all bioconductor packages, update bioconductor-uri to also return archive URLs <rekado>and I’d love to fix bug 22533, but that’s probably for another day. <civodul>i'll try to reproduce the non-deterministic compilation issue <civodul>and probably merge the multiple-derivation 'guix pull' today <rekado>later this year (or early next year) our group is going to publish a paper where Guix is going to be important for reproducibility. <g_bor>Do we have an easy way to repbuild all packages depending one a package? <rekado>it would be great if we could actually achieve 100% reproducibility for the set of software we need for the paper. <htgoebel>IIRC, we stet the mtime of all files after installation, so we could add a phase to set the resp. in the .pyc files, too. <htgoebel>Thus the test-suite should still pass, but the output would be deterministic. <htgoebel>The only thing we need to verify is whether we did it right and the byte-code is actually used (instead of recompiling). <g_bor>I have a package where I would like to bump major version. <rekado>g_bor: you can get a list of dependent packages with “guix refresh -l foo” <rekado>htgoebel: do you propose to patch the generated .pyc files? Or to set the mtime before the .pyc files are generated? <htgoebel>rekado: Setting the mtime before the .pyc files are generated would be much easier, since python is going to make the job. But if I understand 22533 correctly, this approach was already taken and made tests fail. <civodul>rekado: now you have a legitimate reason to work on this ;-) <htgoebel>Thus maybe we could patch the .pyc files. <htgoebel>But this is more fragile, esp. since Python 3.7 will have a new deterministic file-format. <civodul>actually strip-nondeterminism probably does that <civodul>we already patch gzip files, so why not, after all <htgoebel>civodul: I can't find strip-nondeterminism in master <civodul>htgoebel: it's a tool developed by the Debian folks <civodul>if not code, we can always borrow ideas <htgoebel>Maybe one of the existing patches in 22533 can be used, if we *un*set SOURCE_DATE_EPOCH for the tests. <civodul>rekado: once we have an understanding of 27476, i'd like us to finally release <buenouanq>I think there is a significant number of people right now waiting to jump in because of that scary `beta' word. <buenouanq>Funny given that I've found GuixSD to be perhaps the most stable distro I've ever had the pleasure of trying. <kmicu>Nah, nowadays people are ok using a bleeding edge randomly bricked Arch so they are not afraid silly beta :) <buenouanq>I've heard multiple people say that they are waiting for GuixSD to `become stable' before they'll be willing to try it. But they are interested in doing so. <jonsger>buenouanq: for me it was the most difficult distro to configure (not to install, that is straight forward)... <kmicu>[joking] More stable? Like making releases once every 2 years? :P <kmicu>civodul: glad to hear about a new release. To celebrate I will convert my last system from NixOS to GuixSD :) <rekado>civodul: yes, I agree, we should make the release then. <rekado>civodul: are the fixes to Guile already released? <wingo>civodul: regarding complexity of guild compile -O0: i am sure we can do better. probably sufficient to write a different slot allocator for use in -O0 compilations <wingo>i think that would more-or-less solve the problem. <wingo>civodul: i'm also looking to solve the problem in other ways in master, but that's not really applicable to guix right now <htgoebel>Perhaps we should change "beta" into "gamma" :-) Or into "rc1" <htgoebel>How can I create an installation image which includes the guix from my *current* development tree and will install this version of guix into the new system? (I want this system to substitute stuff already build on my development machine.) <efraim>guix system disk-image gnu/system/install.scm ? <wingo>i think that uses a named guix, right? <wingo>like there's some guix reference in the source code that gets updated periodically <wingo>so it's never quite what you have checked out. maybe i have that wrong tho <htgoebel>efaim: Tried this and this seems to give a different version <htgoebel>But on "system reconfigure" with only the authorized keys changed a lot of stuff will be build, while I'd expect all software to be present already :-( <efraim>What if you make your own 0.13.0-9 release first? I would think that would take care of it <htgoebel>efraim: To be honest: Meanwhile my motivation for even more testing is non-existent. Each test-cycle is taking an hour or so. <htgoebel>I tried automating things by changing gnu/system/install.scm and running "make check-system TESTS=installed-os", but every change to install.scm leads a complete rebuild. <rekado>it’s not doing much at this point, but feel free to contribute <wingo>Creating manual page database for 79 packages... done in 39.850 s <efraim>Maybe we can more directories than necessary? <wingo>guix upgrade day is always a big day :P <civodul>yeah it's especially 'guix pull' that's terrible <wingo>guix pull much less bad than e.g. texlive <civodul>i wonder what's preventing us from getting rid of 'texlive', rekado? <wingo>also i upgrade only once every month or more, so it's a gnarlier thing <bavier>civodul: thanks for the patch reviews <rekado>the texlive-union packages don’t seem to recognize already generated fonts <rekado>we also haven’t built a profile hook using texlive-union, so users cannot make use of the split-up packages. <rekado>I wanted to fix the font problem first, but haven’t figured it out yet <jonsger>rekado: +1 for the guile bindings :) <bms_>I just (finally) got my package to install on GuixSD and I'm very happy with it. It's still a less-than-ideal setup as I'm hosting my tarball distribution on Dropbox (eventually, my plan is to submit to GNU and use their FTP), meaning I have to reupload to that and rehash everytime I make a change, but it works. <bms_>But for the current stage in the project, it works perfectly. I need to move it farther along before GNU evaluation is viable. <bms_>I also want to thank you and everyone here for making Guix and GuixSD so good. Once you get past the dirty setup bits, it's near-perfection. <bms_>And the Grub-EFI support is very helpful for my iMac. <civodul>bms_: what is the project you're talking about? <happy_gnu[m]>So that same guixSD with the same packages and configuration <civodul>happy_gnu[m]: normally it's enough to have (1) the GuixSD config file, and (2) the Guix commit id <bms_>My project is an extensible, encrypted, federated instant messenger, written in Guile. I call it msg. It's designed so that one command can start both a server or a client and with small communities in mind. Don't think of it as a replacement for large IRC servers, more like a modern UNIX talk with groups. It's not exactly that either. I don't know what to compare it to. <bms_>In theory, everyone can start a server with relative ease for a small group of friends. And the servers stay small and simple enough that you can run one and the client on the same computer, with standard specifications. <ng0><htgoebel> Perhaps we should change "beta" into "gamma" :-) Or into "rc1" <- "GuixSD. stability: As stable as Helloween \\o/". <rekado>I think beta suits GuixSD just fine, actually. One bug that I think needs to be removed before we could drop this is that of cache files in the home directory. <rekado>things like the ibus cache, or gtk cache files, all of which may embed store paths, which can be garbage collected. <rekado>ACTION fixed the bioconductor importer/updater; proceeds to upgrade all packages <rekado>this took much longer than I thought, because the Bioconductor project no longer offers a way to access DESCRIPTION files over HTTP. <rekado>eventually I found a way to access a list of all packages and their versions <civodul>is this something where http-fetch/cached can help? <rekado>I didn’t use it; I used “memoized” to cache the result. <rekado>but I suppose http-fetch/cached is better because it expires <civodul>rekado: it caches on disk and uses If-Modified-Since <civodul>happy_gnu[m]: true, but you could use previous machines as mirrors <civodul>didn't reach my goal regarding 'guix pull' :-/ <efraim>does anyone know where 'xaa.h' is? ***db48x is now known as db84x
<janneke>gcc@4.7.4 does not build anymore...found a patch that should work <TeMPOraL>I can't get the fonts to work under X :< <TeMPOraL>I installed a few fonts with guix package -i, but they don't show up on xlsfonts <TeMPOraL>are there any obvious things I might be forgetting in configuring fonts under X? <TeMPOraL>also: xfontsel aborts with "no font found" -.- <ng0>fc-cache -fvi or something <ng0>we really need that as a profile/package hook. <TeMPOraL>done; even really-forced with fc-cache -rv <TeMPOraL>which (as I understand) means I can't target them via the magic X strings --*makapaka*-stuff-*-*-whatever-*- <bavier>TeMPOraL: do you have the 'font-alias' package installed? <bavier>IIRC there is a bug about the fonts there shadowing other xorg fonts <TeMPOraL>I'm installing it, and guix is reporting a collision warning <bavier>the collision might be part of the bug, actually <alezost>TeMPOraL: check with "xset q" if xserver has your font paths (~/guix-profile/share/fonts/X11/75dpi, etc.). If not, you can add them (probably with "xset +fp", but I'm not sure) <TeMPOraL>doesn't have the ~/guix-profile/share/fonts/X11/truetype/ <TeMPOraL>sorry, ~/guix-profile/share/fonts/truetype/ <TeMPOraL>I supposed it is something I need to put in some rc file to have it survive reboot, right? <efraim>hmmm, not all u-boot packages have an MLO output <TeMPOraL>now the trick question - how to make them antialiased <civodul>TeMPOraL: if stumpwm uses one of the regular graphical toolkits, it should just work, no? <lfam>Hi civodul, how's it going? <lfam>I'm working on updating cmake for core-updates now <civodul>lfam: awesome, thanks for doing this! <civodul>i'm working on a patch for Mesa (core-updates) to shrink it a bit <civodul>efraim, lfam: i'm considering getting an A20-OLinuXino-MICRO for myself <lfam>The newer CMakes seem to build our packages fine, but there are some test failures in CMake that appear spurious. I'm trying to understand them a bit more before sending a patch to disable them <kmicu>TeMPOraL: did you load Xft module in your StumpWM configuration? <lfam>I used that system-on-a-chip but in a different board (the Cubieboard 2). For a low power 32-bit ARM CPU, it's pretty nice since it has (slowish) SATA and real Ethernet. The SOC can be used with 100% free software unless you actually need to use the MALI GPU. The thing with ARM is that the GPU does less than on Intel-compatible systems, so you can still use a display with it <lfam>I generally trust Olimex to make reliable systems, since most of their business is to industrial customers <efraim>If you're going to compile on it you might want the one with emmc or nand for swap <efraim>Their A64 with the 2GB of RAM is the board in their laptop I think <lfam>Hm, Python 3.5.3 doesn't pass its tests with the latest libressl stable release :/ <lfam>I haven't tried it. I noticed it when testing my openssh-libressl package, which uses libressl in place of openssl for the entire dependency graph <civodul>lfam: cool, i actually mostly need a bit of CPU power and audio output, i don't really care about the GPU <lfam>As long as you only need a bit ;) <civodul>it's 2x1 GHz though, so not too bad? <lfam>Yeah, sure, but the CPU does less per-cycle than, for example, a desktop x86_64 CPU of the same era, or even the 64-bit Cortex A53 used in Olimex's A64 board <lfam>It's definitely usable though. It's no microcontroller <civodul>i wonder if it could run 'guix pull' ;-) <civodul>ACTION is going to have 'guix pull' nightmares again <lfam>It might not be practical considering how much RAM is currently required. It used to work with Guile 2.0, but I haven't tried it since we started using Guile 2.2 <civodul>lfam: did you try the audio output on that board? <lfam>Yes, that worked fine for me <lfam>Well, I don't want to dissuade you too much! It depends on the speed of the swap medium <lfam>And how long you are willing to wait <lfam>efraim: Python 3.5.3 fails 'test_alpn_protocols' with OpenSSL 1.1.0g <janneke>i found that gcc-4.7.4 does not build anymore -- also found a patch that fixes it <janneke>but no step further on diverse double compilation, same /gnu/store differences <civodul>janneke: re DDC, i was thinking that maybe we could build the derivation in a VM with a fixed prefix <civodul>for comparison purposes only, that is <civodul>as with expression->derivation-in-linux-vm <janneke>i'll reply to that bug with my patch...this will probably need to go in core-updates or so? <civodul>i think so, because of all the inheritance <janneke>i only tested it in a inherited gcc-4.7.4 of course, but that should be fine -- i'll mention it <rekado>civodul janneke: is this to avoid embedded build paths? <rekado>should this not be fixed by adopting that new repro-builds variable? <janneke>that includes the bppm patch and my $ORIGIN hack <rekado>hmm, I wonder why that store reference is split up (eg on line 17) <rekado>and I wonder why we have references to the output directory when $ORIGIN and bppm are used. <rekado>but other than that: is this the full diff? <rekado>if so: that’s already pretty damn good! <janneke>i didn't see references to the output directory with 7.2.0...but saw other weird stuff there (hash table difference or something) <janneke>that's when i decided to backport bppm and try with 4.7.4 ... <civodul>rekado: BUILD_PREFIX_WHATEVER_MAP is for the build directory name, not for the installation prefix <janneke>full diffoscope diff is 12,000 lines (including context) <janneke>i think i'll redirect my focus again to stage0/mescc <janneke>ACTION needs to reboot their window manager (emacs) again, memory exhausted %-| <janneke>dustyweb: i tried to compile guile-emacs and failed, you want to have a look? <dustyweb>janneke: I don't have time right now unfortunately :( <janneke>what, no time for this right now?! -- ;-) sure, i'll do that. <dustyweb>janneke: yeah sorry! I'm in crunchmode on activitypub and debugging what happened to guile-emacs sounds... complicated :) <janneke>yeah, i like to add a patch with a bug report but tried several things and failed, unfortunately <mb[m]1>So many emails, so little time... :( <rekado>ACTION needs a faster machine to rebuild all of bioconductor / CRAN