IRC channel logs


back to list of logs

<TaoHansen[m]>now guix fails to build after a `guix environment guix -- guix pull`
<TaoHansen[m]>fails to build itself that is. are system breakages like this to be expected regularly or is it something wrong with my own method?
<CompanionCube>ACTION just can't get ikiwiki to find it's own libraries when invoked via the CGI wrapper
<CompanionCube> how could I test applying this to see if it works?
<lfam>TaoHansen[m]: How does it fail? What is the error message?
<TaoHansen[m]>lfam: let me get you a couple pastes
<lfam>Okay :)
<TaoHansen[m]>lfam: paste of last messages before it bailed to a prompt:
<lfam>Do you have more? Above that, it should say which test(s) failed
<lfam>Also, can you give some more details about your system? Specifically, kernel version (distro kernel?), filesystem type that /tmp is on, hardware architecture, whether its virtualized, etc
<TaoHansen[m]>lfam: more complete:
<TaoHansen[m]>let me just get you my config.scm and i'll answer any other questions you've asked not answerable there.
<lfam>Okay, I see that there was a failure in 'tests/store.scm'.
<TaoHansen[m]>lfam: config.scm:
<TaoHansen[m]>bare-metal, x86_x64
<lfam>Normally one can pass `--keep-failed` to commands that build stuff in order to keep the build directory around, which would also keep that test-suite.log filed it asks for. I'm not sure whether or not it will be honored when building Guix with `guix pull`, but it's worth a shot to add --keep-failed and run it again in order to get at that log
<TaoHansen[m]>lfam: okay rebuilding. it's going to be maybe 10 minutes before it fails. :-)
<lfam>Okay, I'll be around
<lfam>I'm going to try building it locally to see if I can reproduce. I wonder if those tests assume ext4 somehow (I noticed your / is btrfs)
<TaoHansen[m]>i'd be happy to switch to EXT4 if it will make the failures stop.
<lfam>If that's the issue, it would at least be worthwhile to get the test-suite.log so that we can fix it.
<lfam>I wonder if anyone else has their store on btrfs? I think plenty of us use btrfs on GuixSD for other filesystems, but I know that my store is still on ext4
<TaoHansen[m]>lfam: i looked for the test-suite.log in my root directory but it wasn't there so fingers crossed --keep-failed saves it.
<lfam>It would be under the '/tmp/guix-build-guix-0.13.0-7.8b920d7.drv-0' directory mentioned in your pastes. Those are the build directories used for chroot / containerized buildsin Guix, and they are deleted when done unless --keep-failed is passed
<TaoHansen[m]>lfam: i don't see it under that directory
<TaoHansen[m]>wait no found it
<lfam>TaeHansen[m]: Can you share it, and any other log files related to the failing tests in test/store.scm?
<TaoHansen[m]>sorry for, all the others rejected the output as too long or spam.
<TaoHansen[m]>because i'm curious: what's your methodology for parsing a logfile like this? do you just /fail?
<lfam>Yeah, I look for FAIL (all caps)
<lfam>line 4879
<TaoHansen[m]>i see it, looking at it too.
<lfam>Was this during `guix pull` or during another command?
<TaoHansen[m]>exact command was `sudo guix system reconfigure /etc/config.scm`
<TaoHansen[m]>those invocations were passing until i did a `guix pull` earlier today.
<TaoHansen[m]>technically `sudo guix environment guix -- guix pull` with your help
<lfam>Hm, I'm sort of stumped. But also wondering about the effect of `sudo` vs `sudo --login`. I'm not sure how it effects pulling and reconfiguring
<TaoHansen[m]>do you do it all from a root prompt?
<lfam>I usually do sudo --login
<TaoHansen[m]>i mean, i have actually tried this earlier today and got the same error.
<lfam>I see
<TaoHansen[m]>alright, i'm just going to blow away this install and start again.
<TaoHansen[m]>with EXT4.
<TaoHansen[m]>which makes it an embarrassing number of days trying to get a functional GuixSD machine hah.
<lfam>Yeah, that's not great
<happy_gnu[m]>lfam hi are you here
<happy_gnu[m]>marusich: hi!
<marusich>How's it going?
<happy_gnu[m]>Pretty good actually how about yourself marusich
<marusich>I'm well!
<Digit>i dont suppose there's a way i could run a command to, like... diff guixsdspec singleunixspecification ? i dont suppose anyone made a specification for specification such that a command like that could work.
<civodul>Hello Guix!
<civodul>ACTION runs "guix build perf" in M-x shell
<civodul>bad idea, bad!
<roptat>civodul, re dns tests, I don't have a lot of time and other projects too, so it will take some time. I'll try to do something about it next week-end
<civodul>roptat: sure, sounds good!
<civodul>it's mostly about moving code around, compared to the patch you already sent
<civodul>rekado_: when you have time, could you reconfigure berlin from master?
<civodul>it has 'guix publish' fixes, and 'guix offload' scalability improvements
<rekado_>civodul: will do!
<efraim>I'm getting wrong hash for the guix checkout for 0.13.0-8
<civodul>efraim: oh?
<civodul>did i mess up?
<efraim>I'm runnign it again
<efraim>ACTION has to run
<civodul>bah indeed :-/
<civodul>efraim: fixed!
<civodul>at last perf can find tips.txt \\o/
<civodul>simple things that change one's life :-)
<Apteryx>anyone having problems with rsync recently? It's too slow to be usable anymore it seems... unless my disk is dying a slow death.TaoeuAO
<efraim>I believe my debian install is in need of repair, easiest to just swap out the HDD and install GuixSD. Just have to pre-format and try copying over the rEFInd binaries as a proof-of-concept
<ng0>how does the guix.texi output manage not to have weird indentations of text after @end example ? are we using some custom texinfo thing there?
<ng0>my pdf output of the GNUnet handbook still looks too weird between 2 or more of those example blocks
<ng0>In case you need an example for 'weird' I can upload the current HEAD of it.
<ng0>alternatively, git clone the source and run guix build -f contrib/packages/guix/gnunet-doc.scm in its rootdir
<ng0>for example page 27 or 21 here:
<htgoebel>Hi, anybody here to help me building a KDE-Plasma Desktop service? Packages are build, but I fail defining the service – complicated stuff this is.
<ng0>if it's not as easy as gnome-desktop-service or mate-desktop-service?
<htgoebel>ng0: The problem is that I do not *understand* these definitions :-)
<ng0>basically you have a 'one-package to catch them all', that's the biggest part
<htgoebel>These is an undocumented function"package-direct-input-selector" which is used for gnome and *may* pull in other packages, but I did not get this to work.
<ng0>like you could have 'kde-plasma' as a "meta" package if that doesn't exist
<ng0>*doesn't already
<ng0>idk… I just read what gnome does, though mate-desktop-service is far from finished
<ng0>what does kde-plasma require?
<htgoebel>For xcfe, there seems to be a meta-package and it pulls in another one (thunar) in the service- So mayby I start with something like that.
<ng0>maybe you can just list that for yourself. In packages, what constitutes a kde-placma desktop, and beyond that.
<htgoebel>Requirements? Hard to tell, not documented.
<ng0>you could take a look at Gentoo, Archlinux, etc
<htgoebel>On my distributions it there is a "tast-plasma-minimal" package requiring ark dbus-x11 dolphin gwenview kcalc khelpcenter kwalletmanager kwrite oxygen-fonts phonon4qt5-gstreamer phonon4qt5-vlc plasma-desktop plasma-pa plasma-workspace sddm systemsettings task-x11 xsettings-kde
<htgoebel>I would prefer to not use a meta-package. I assume the service definition could pull in the packages.
<ng0>why not?
<civodul>htgoebel: does help understand what's going on with gnome-service-type for instance?
<htgoebel>I can't see any benefit in having a meta-package. But if this is the way guix is thinking, I'll have to go this way.
<civodul>or maybe
<civodul>htgoebel: you don't *have* to provide a meta-package
<civodul>i think it just happened to be more convenient in the case of GNOME
<htgoebel>civodul: No. This is a documentation of functions, while I would need a tutorial.
<htgoebel>Further, package-direct-input-selector is not documented.
<htgoebel>Which makes it hard to adopt gnome-desktop to my needs.
<civodul>htgoebel: documentation of functions?
<civodul>rekado_: yay for Axoloti, at last! ;-)
<rekado_>it only took two years! :)
<htgoebel>civodul: Yes. I'm not a lisp-programmer and "package-direct-input-selector" is just magic for me. So is "gnome-polkit-settings"
<htgoebel>I not even have a clue whether kde-desktop-service-type would need to extend other services beside polkit- and profile-service.
<rekado_>htgoebel: that depends on what you want to make it do.
<rekado_>these are questions apart from Scheme programming
<htgoebel>rekado: ACK, but still a problem for me :-)
<rekado_>htgoebel: do you understand how we use system services?
<htgoebel>rekado: Roughly. I do not understand when to use which service. Eg. when do I need an etc-service-type?
<htgoebel>And I just see that describes only a few of them :-(
<rekado_>etc-service-type is used to create files under /etc
<rekado_>other services may extend that service, so it isn’t used directly very often.
<rekado_>about package-direct-input-selector: it’s a procedure that returns a lookup procedure for a given input.
<htgoebel>Found etc-service-type in Service-Reference.html :-( Inconsistend manuals are a horror for newbiew (no offence menat, I know how hard it is to write manuals)
<rekado_>what’s inconsistent here?
<htgoebel>rekado: about package-direct-input-selector I got so far, but did not understand how to use it.
<htgoebel>inconsistent: Some serve-types are in Service-Reference.html, some in Service-Types-and-Services.html.
<rekado_>you give it an input and the result is a procedure that will look up that input among the inputs of a given package.
<rekado_>I wouldn’t bother with package-direct-input-selector unless you know you need it.
<civodul>htgoebel: the articles above don't talk about package-direct-input-selector at all
<civodul>i'd suggest not getting stuck on this one function
<civodul>(i discovered it recently and i'm not a big fan FWIW :-))
<htgoebel>rekado: Thanks. gnome-desktop uses it, so I thought I'd need it, too.
<htgoebel>civodul: mentioning the articles above is about the other discussion thread: service-types documented at different places.
<civodul>i see
<civodul>well as usual, suggestions and patches to improve the doc are always welcome
<civodul>with a fresh eye you can notice things that i wouldn't necessarily notice, for instance
<civodul>so yeah, this is really valuable feedback!
<efraim1>does anyone know about installing guixsd on an older macbook?
<bavier>efraim1: I recall it's been done, but iirc there were keyboard issues? not sure
<efraim1>bavier: i think it was already librebooted, mine just has a blank ssd
<efraim1>according to debian's wiki it may want a 32-bit efi
<mb[m]2>efraim1: if you have to, simply copying the "boot.efi" from the i686 GuixSD installer to the ESP on the x86_64 installer *should* work.
<mb[m]2>No idea if GRUB will automatically detect 32bit firmware, though.
<efraim1>mb[m]2: i'll try that later, it turns out that my macbook 4,2 found the guixsd installer
<efraim1>so now to upgrade the RAM to 3GB and install guixsd, i'll work later on extracting whatever I had on the other hdd
<mb[m]2>In that case you have 64-bit firmware (or "legacy" mode).
<efraim1>the macbook 4,2 definately is 64-bit
<efraim1>*64-bit firmware
<mb[m]2>You can test for "/sys/firmware/efi" to check if the installer booted in UEFI mode. Maybe we can show that in MOTD or something.
<efraim1>it did NOT like my ram upgrade, back to 2GB
<cbaines>CompanionCube, are you still having trouble with Ikiwiki?
<CompanionCube>cbaines: yes
<cbaines>Ok, what is the context, e.g. are you trying to setup the CGI with nginx on GuixSD?
<CompanionCube>CGI on a foreign distro
<CompanionCube>I know it's not the webserver's problem because I had it working before I moved ikiwiki to guix
<cbaines>Ok, is it the lib/w3m/cgi-bin/ikiwiki-w3m.cgi within the ikiwiki package that you are using?
<cbaines>how are you setting up the CGI then?
<cbaines>(I don't really know much about this)
<CompanionCube>cbaines: it's generated by ikiwiki itself
<cbaines>Ah, right
<CompanionCube>when running it against my .setup
<CompanionCube>if I had to guess, the environment sanitization breaks it, and while it's configurable I have not had success in getting that to work
<CompanionCube>I'll go ssh in and grab the error
<cbaines>CompanionCube, I'm guessing it doesn't work via CGI, as the ikiwiki binary is wrapped to set the PERL5LIB environment variable
<cbaines>I'm just trying to generate this CGI thing locally...
<cbaines>Hmm, it's actually a compiled program... that's a little awkward
<CompanionCube>cbaines: I believe it's generated/compiled in;a=blob;f=IkiWiki/;h=739ee317326c82c89d926430dfac315006d73a8a;hb=HEAD
<cbaines>CompanionCube, excellent, it looks like that file includes some stuff to modify the environment
<cbaines>I'll have a quick go at patching it to persist the PERL5LIB environment variable
<CompanionCube>ACTION tried to do that in the .setup file but couldn't figure out the syntax
<cbaines>It looks like it might be possible... but I can't quite tell what this line would do: if (ref $config{ENV} eq 'HASH') {
<cbaines>and anyway, it would be best if a unmodified config file just worked
<CompanionCube>while you're fixing this, apparently there was a recent update which you may or may not want to look at
<cbaines>CompanionCube, I have a patch now that at least gets the PERL5ENV value in to the binary, are you able to test this?
<CompanionCube>if you give me instructions, I'll do whatever
<cbaines>do you have a checkout of the guix repository?
<CompanionCube>ACTION git clones, seeing as ~/.config/guix/latest isn't one
<CompanionCube>so, apply the patch to the checked out guix. then test installing the patched thing?
<cbaines>CompanionCube, yep, that would be great, how can I send you the patch?
<CompanionCube>how do you want to send it?
<cbaines>CompanionCube, email, or I can just put the bit to add in a pastebin if that would be easier?
<CompanionCube>the last would be easier. Preferably the raw link.
<cbaines>CompanionCube, actually, none of the above :) Here is a link to the patch as a commit
<CompanionCube>ACTION guix environment guix
<cbaines>CompanionCube, any luck yet?
<CompanionCube>cbaines: guix is building
<cbaines>ok, that can take a while...
<CompanionCube>ohey, it's done
<cbaines>great, what to do next will depend on how you're using the ikiwiki package
<CompanionCube>i just installed it via guix package -i
<cbaines>ok, so you should be able to replace that with the patched version by running ./pre-inst-env guix package -u ikiwiki
<cbaines>I think...
<CompanionCube>ACTION rebuilds wiki
<CompanionCube>it worked. Now it fails to find HTTP::Request...but regular ikiwiki also did that until I added a package into my environment
<CompanionCube>(i think, it's been a while)
<cbaines>CompanionCube, awesome :D
<cbaines>I'd suggest adding the relevant package for HTTP::Request to the ikiwiki package as a propagated input, and testing again
<CompanionCube>ACTION patched web.scm, reran make and now the pre-inst-env command
<cbaines>CompanionCube, how are you getting on with the HTTP::Request issue?
<CompanionCube>ACTION remembered the generations gave him a list of packages he added to the env
<CompanionCube>so I added them too, and am now testing that
<CompanionCube>so the CGI works now
<CompanionCube>i think
<cbaines>great :)
<CompanionCube>so do you want a diff or something?
<cbaines>I'll put the patch regarding the PERL5LIB environment variable up for review
<cbaines>If you could put a patch up for the extra inputs, that would be great
<CompanionCube>i added perl-http-message, perl-libwww, and perl-uri to the propagated inputs
<cbaines>right, I've got a patch up here now
<cbaines>I've got to go now though, good night :)
<CompanionCube>good night