IRC channel logs


back to list of logs

<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: So found any recommendations for yet? If you haven't noticed I recently added a few extras which are needed for implementing a compiler in lisp.
<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.
<civodul>Hello Guix!
<janneke>hey civodul!
<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>heya rekado!
<civodul>sounds like a good plan
<civodul> would be nice, but it's non-trivial
<civodul>i'll try to reproduce the non-deterministic compilation issue
<civodul>and probably merge the multiple-derivation 'guix pull' today
<g_bor>hello guix!
<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.
<rekado>(this includes Python things)
<htgoebel>Re bug 22533: What's about this:
<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”
<g_bor>ok, thx
<rekado>htgoebel: do you propose to patch the generated .pyc files? Or to set the mtime before the .pyc files are generated?
<civodul>rekado: would be nice!
<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>(patching .pyc files)
<htgoebel>civodul: mompl
<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
<htgoebel>Urgs, it' perl :-((
<civodul>if not code, we can always borrow ideas
<htgoebel>Does not seem to handle python.
<civodul>woow, hi matrix people!
<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>some are, plenty aren't
<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 :)
<mb[m]>Sup ;)
<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 ?
<efraim>htgoebel: ^
<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>guix --version does not tell, though
<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 :-(
<htgoebel>This is a bit frustrating :-(
<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.
<htgoebel>For me this is frustrating :-(
<rekado>this is a first attempt at providing Guile bindings to Debbugs:
<rekado>it’s not doing much at this point, but feel free to contribute
<wingo>rekado: neat :-)
<wingo>Creating manual page database for 79 packages... done in 39.850 s
<wingo>why does this take so long
<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>oh right
<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>civodul: it’s complicated.
<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 :)
<civodul>rekado: okay, i see
<civodul>hi bms_!
<bms_>How are you?
<bms_>That's good.
<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]>If I have guixSD can I create an image or something
<happy_gnu[m]>So that same guixSD with the same packages and configuration
<happy_gnu[m]>Can be installed on different machines
<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.
<civodul>sounds nice
<ng0><htgoebel> Perhaps we should change "beta" into "gamma" :-) Or into "rc1" <- "GuixSD. stability: As stable as Helloween \\o/".
<ng0>or "Gamma Ray"
<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>oh, certainly
<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
<happy_gnu[m]>civodul: but I would have to compile stuff again
<happy_gnu[m]>When installing
<happy_gnu[m]>And download every package on every machine
<civodul>rekado: it caches on disk and uses If-Modified-Since
<civodul>happy_gnu[m]: true, but you could use previous machines as mirrors
<happy_gnu[m]>civodul: oh I didn't know that
<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>ok, another issue
<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>they show on fc-list though
<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>I mean, they show up on fc-list
<TeMPOraL>but not on xlsfonts
<TeMPOraL>which (as I understand) means I can't target them via the magic X strings --*makapaka*-stuff-*-*-whatever-*-
<TeMPOraL>from X apps
<TeMPOraL>like... stumpwm
<TeMPOraL>which really _needs_ a readable font
<TeMPOraL>or xterm
<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>hmm not sure, probably not
<TeMPOraL>I'm installing it, and guix is reporting a collision warning
<TeMPOraL>so it apparently is there
<bavier>the collision might be part of the bug, actually
<TeMPOraL>installed, rebooted, didn't help
<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>has _some_
<TeMPOraL>doesn't have the ~/guix-profile/share/fonts/X11/truetype/
<TeMPOraL>sorry, ~/guix-profile/share/fonts/truetype/
<TeMPOraL>woah, adding it worked
<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>got fonts to work in stumpwm
<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>will post soonish
<civodul>unless things go wrong, that is ;-)
<lfam>As always ;)
<civodul>efraim, lfam: i'm considering getting an A20-OLinuXino-MICRO for myself
<civodul>any experience/comment on this?
<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
<kmicu>civodul: maybe put GuixSD on nudge nudge? :)
<lfam>Hm, Python 3.5.3 doesn't pass its tests with the latest libressl stable release :/
<efraim>Does it pass with openssl@1.1?
<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
<lfam>I'll try it now :)
<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?
<civodul>kmicu: oh that looks nice too :-)
<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' ;-)
<bavier>lots of swap :)
<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
<civodul>ACTION feels sooooo embarrassed
<civodul>re swap
<janneke>i found that gcc-4.7.4 does not build anymore -- also found a patch that fixes it
<lfam>Like this in case you are curious, efraim:
<civodul>anyway, good news!
<janneke>but no step further on diverse double compilation, same /gnu/store differences
<civodul>janneke: nice! mark_weaver reported it as
<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
<janneke>hmm, nice
<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>rekado: i see this diff now for bin/gcc 4.7.4 twice with another name:
<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>no, again this is only bin/gcc
<janneke>yeah, that puzzles me too
<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 :(
<dustyweb>janneke: could you file a bug on guix?
<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... :(
<mb[m]1>Good night, Guix!
<civodul>heh, good night mb[m]1!
<rekado>ACTION needs a faster machine to rebuild all of bioconductor / CRAN