<malaclyps>okay so I did guix system build ~/system.scm (which is where my system configuration is held). It gave me a gnu store directory, and I did "find -L . -name "*libwacom*" in that store directory, to no result. Is there another way I should be checking to see whether that system has a non-empty libwacom? <leoprikler>it appears the system does not reference libwacom directly, but indirectly <malaclyps>I originally found the problem by diffing the X windows log, where Xwindows errors from "Failed to load /gnu/store/29gkxw93z6nj7ki2yswf8wggzlxvycsg-xf86-input-libinput-0.28.2/lib/xorg/modules/input/libinput_drv.so: /gnu/store/1iy0fwk1hmvangichipg9kh9pwynl40y-libwacom-1.1/lib/li bwacom.so.2: file too short " <malaclyps>i mean, really what I want/need to do is to rebuild the bad libwacom directory, but guix build --repair doesn't seem to be doing that <malaclyps>let's see what sudo guix build --repair libwacom --no-substitutes does <leoprikler>--no-substitutes does not do what you want, probably <leoprikler>you will have to build everything from scratch, which is overkill <malaclyps>yes, apparently I am starting with building ghostscript :) <malaclyps>so, what I think we've established is that this my wacom /gnu/store/1iy.../ does not contain what yours contains, and is corrupt. But guix build --repair does not recreate a new, correct version. This seems like it should not happen under guix. <leoprikler>tbh I'm not quite sure what repair actually does <leoprikler>try --repair together with --check -- the latter forces rebuilding afaik <leoprikler>so that you're not repairing a working libwacom by accident <malaclyps>i am pretty sure it's ~/.config/guix/current/guix , if that's what you mean. Even if I occasionally mess up, that's the only one that works with guix system reconfigure for me <leoprikler>oh, btw. did you check in the log of guix system build if libinput was built? <leoprikler>In retrospect? With a lot of scrolling, I'm afraid. <malaclyps>oh, guix system build did not output much at all -- i think it just created a bunch of symlinks. It didn't seem to build anything. <leoprikler>that error states, what you are complaining about: that libwacom is nondeterministic <malaclyps>right, but why isn't it just replacing the old, corrupted lbwacom? <leoprikler>because I'm a noob and don't know how to guix build ._. <malaclyps>leoprikler, yep, i tried it with both --check and --repair and got the same error <leoprikler>So the behaviour of --check is to error if there's a mismatch <malaclyps>very very tempted to just mount the /gnu/store partition RW and just blow this away <leoprikler>btw. can you paste guix build --repair libwacom? <malaclyps>it just returns "/gnu/store/1iy0fwk1hmvangichipg9kh9pwynl40y-libwacom-1.1". Hold on, let me paste the full result with --debug=4 <leoprikler>Can you `guix gc --delete /gnu/store/1iy0fwk1hmvangichipg9kh9pwynl40y-libwacom-1.1`? <malaclyps>yep, I've tried to do this a couple of times now <malaclyps>(oh actually i effectively deleted that earlier generation by rolling back and then building this one) ***daviid is now known as Guest65407
<leoprikler>some generation still references this corrupt libwacom, does it not? <malaclyps>okay, so i didn't have to reboot to delete the latest generation, but the corrupted wacom is still live <leoprikler>did your remove all generations referencing the corrupt one? <malaclyps>looking now (there was a root generation that referred to it, so i've remove that, and a system generation which I also removed) <malaclyps>(apologies to everybody else on the channel having to scroll through all this!) <malaclyps>yeah, actually gc --list-busy lists the libwacom-1.1 directory and the manual says that these are considered GC roots, so it could be that I just have some process holding onto it <malaclyps>i'm going to reboot and see if it's still ungc-able <leoprikler>you mean this exact directory is a GC root currently? <malaclyps>leoprikler, i meant that it was listed in list-busy, which are files that are owned by currently running processes, and are considered gc roots <malaclyps>rebooting took it off the live list! hooray! <leoprikler>btw which path appears now if you do list-busy | grep libwacom? <malaclyps> . /gnu/store/z2zazz1xkb09r5d1ycz7fzgc62bm7av7-libwacom-0.33 <malaclyps>okay successfully built the 1.1 version, with no zero-sized files <malaclyps>well this is my old system configuration, so it's the right one for that <malaclyps>damn now i wish i hadn't done a full garbage collect -- i'll have to rebuild the non-free kernel from scratch <gnutec>That is cool! I just open the guix here in emacs (M-x guix) and see all the games. Figure out that Flare-game was add to guix. <malaclyps>leoprikler, thank you for helping fix my problem (and thank you for everyone else fo bearing with me) <gnutec>And my Freedoom, minetest and openttd is outdate. The update of packages in guix is amazing. :D <malaclyps>leoprikler, i did! that was the other good part of this <malaclyps>i ended up using "eval `~/.config/guix/current/bin/guix package -p ~/.config/guix/current -p /run/current-system/profile -p ~/.guix-profile --search-paths` " <leoprikler>that looks disgusting and you should feel horrible <raghavgururajan>ya hooo! Successfully packaged a package for guix for first time :)))) <malaclyps>leoprikler, hey man, you can just say how you would do it, rather than talking about how disgusting it is <leoprikler>I don't do anything of the sort inside my own shell and it just works fine <leoprikler>What shell are you running that forces you to resort to such measures? <malaclyps>well that's perfectly okay; but there's no need to diss me about it (I'm using zsh so the guides aren't entirely designed for me. I also think I probably wandered into some bad solutions) <leoprikler>My guix-specific zshrc lines consist of "fpath=(/run/current-system/profile/share/zsh/site-functions/ $fpath)" before the autoloads <leoprikler>oh, and you may have to remove .zcompdump if Guix ever updates their autocompletes <malaclyps>so how does you get the guix-specific paths? <leoprikler>I'm not quite sure, how it works exactly, but paths are set correctly if you spawn a new shell <leoprikler>That message that you sometimes get by guix pull only applies if you keep on using the current one <malaclyps>yeah, i think some of may be due to me using an eccentric windowing setup that doesn't fill environment variables correctly <leoprikler>Before I got my graphics card to work, I used slim and ratpoison <leoprikler>but even inside ratpoison, my config seemed fine <leoprikler>btw. my path is /gnu/store/...-glib/bin:$HOME/.config/guix/current/bin:$GUIX_PROFILE/bin/:$GUIX_PROFILE/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin <leoprikler>do you have something similar without your hack? <leoprikler>btw. this should work regardless of environment, see /etc/profile <leoprikler>create one with "source /etc/profile" in it and you need no other hacks in <raghavgururajan>leoprikler Any idea of what this error means? error: Package `goa-1.0' not found in specified Vala API directories or GObject-Introspection GIR directories ***daviid is now known as Guest35010
***Guest35010 is now known as daviid
<leoprikler>raghavgururajan: you're missing the .vapi for goa-1.0 ***catonano_ is now known as catonano
<leoprikler>you're also missing ("docbook-xml" ,docbook-xml-4.2) <raghavgururajan>So now I dont see error regarding docbook. Only error related to goa. ***jje_ is now known as jje
<leoprikler>in the meantime you should probably fix your uri to use the "mirror://" notation ***jonsger1 is now known as jonsger
<leoprikler>`vapigen -d vapi --pkg gio-2.0 --library=goa-1.0 /path/to/Goa-1.0.gir` <leoprikler>raghavgururajan: Add a phase after unpack, that generates the vapi and look if that helps <raghavgururajan> # Add our custom VAPI dir add_project_arguments( ['--vapidir', join_paths(meson.source_root(), 'vapi')], language: 'vala' ) <raghavgururajan>This seems related to our recent conversation. Should we be adding any build arguments to our build definition? <leoprikler>you probably have some replacements of gtk-update-icon-cache to do <leoprikler>To clarify what this does: this generates the missing goa-1.0.vapi file. That file appears to not be installed alongside goa-1.0 for some reason (probably because we don't want a vala dep inside there). *raghavgururajan is pondering <bandali>hey folks, anyone know if it’s possible to use guix without a wm? <samplet>bandali: It sure is! Section 8.1 of the manual gives an relevant example of a “bare bones” system. *raghavgururajan found a fix :-) <atw>big thanks for organizing emacsconf! <elais[m]>Has anyone had trouble running Wayland? Everytime I select a Wayland session from the sddm menu the cursor turns to an x and can move but the screen doesn't leave the login. I feel like I'm missing something. <bandali>also, videos are coming out very soon btw :) <atw>elais[m]: guessing here because I haven't messed with Wayland and sddm for a while, but are there any messages printed at tty1 (ctrl+alt+F1) after it does that? <elais[m]>It prints my password to the try and says Removed session c2 <elais[m]>On tty7 I see a blinking cursor. Does sddm start the session on tty 7? <atw>hmm ok less helpful than I had hoped. My guess is that the cursor with an x is actually an X11 session and that wayland has not launched. <atw>at one point I was trying to go totally X11-less. I had system config like (packages (list weston wayland ...)) (services (list (sddm-service (sddm-configuration (display-server "wayland")))) ...) <gnutec>I upgrade Freedoom (guix package -u openttd minetest freedoom) and when I start, the command returns incompatible with "The Ultimate DOOM". Is it the "prboom"? Should I reinstall, or use other alternative? <atw>gnutec: let me try to reproduce... <atw>gnutec: what's the command? <gnutec>To start. freedoom1 or freedoom2. But you have to install prboom-plus. "guix install prboom-plus" <atw>tried freedoom1 with chocolate-doom, that appears to crash ("Bad V_DrawPatch") <gnutec>atw: They recomend gzdoom. Are you sure there is problems with graphics? The game is old. <atw>gnutec: with gzdoom, I tried invoking both like "freedoom1" and like "gzdoom -iwad .../freedoom1.wad" <atw>not sure if the graphics problems are peculiar to my machine <atw>I also tried crispy-doom and got a segfault <atw>In case it matters, I've been trying all this like "guix environment --ad-hoc freedoom chocolate-doom" <gnutec>atw: Is 900MB of download. Maybe next time I put internet in my 4G. <gnutec>red-eclipse will launch version 2.0 in this year. <elais[m]>I did some digging and it's giving a warning execute gio-launch-desktop (no such file or directory) <raghavgururajan>Folks! I get this error "./autogen.sh: ./configure: /bin/sh: bad interpreter: No such file or directory". What does it mean? <gnutec>elais[m]: Have the same problem in XFCE. But not with gnome. <leoprikler>raghavgururajan: perhaps you need gsettings to make things run <leoprikler>if that's the case, add gsettings-desktop-schemas to inputs and glib:bin to native inputs <rockandska>Seems from my last tests, that 'guix gc' doesn't really clean old 'guix' versions even if there is no more generation who use them <rockandska>is there another people who have experience this too ? ***sneek_ is now known as sneek
<leoprikler>10:42 <leoprikler> raghavgururajan: perhaps you need gsettings to <leoprikler> gsettings-desktop-schemas to inputs and glib:bin <leoprikler>... i need to pay better attention to QUIT messages *janneke finally remembers export CVS_RSH=ssh *janneke pushes a new wip-full-source-bootstrap <samplet>janneke: FYI, I got Gash to work without any intermediate Bashes. That is, Gash builds everything until it can build Bash 5, at which point Bash takes over. <samplet>Unfortunately, I haven’t had the time to clean up the WIP branch yet. <samplet>It’s next on my list after pushing the Haskell updates. :) <samplet>There are three failures on Cuirass that I can’t reproduce. <samplet>They are ghc-hex, ghc-fsnotify, and ghc-foundation. <samplet>I’m guessing it’s intermittent test failures for the latter two. <samplet>The first one has an empty log, so I have no clue there. <samplet>I’m excited about the full source bootstrap, so that will be a good motivator! :) <janneke>yeah; i have been working on merging oriansj's amazing mes-m2 work into mes <janneke>so i haven't worked much on the scheme-only bootstrap, aka wip-build-mes+gash-core-utils last month <samplet>That’s fine. I’ll be able to push that forward over the next little bit. <janneke>i saw some work from you on wip-build-mes and only rebased my smallish patches there <janneke>ah great; one thing that i haven't done while moving all core-util tests to .org files, is remove the old test scripts; there's a big WIPWIP commit that should still be cleaned up <janneke>however, with that i was able to bootstrap guix without any coreutils&co ... so with your fixes we're getting very close to our scheme-only bootstrap! <janneke>i also added gunzip from industria weinholt <janneke>that seems to work, haven't field-tested it in the guix bootstrap yet <samplet>Do you have any ideas for the Bash binary that extracts and wraps the bootstrap Guile? Is that a longer term issue? <janneke>nothing concrete; civodul suggested creating a self-extracting guile binary with gash payload <janneke>but at the same time, oriansj pushes for full guile compatibilty in mes <janneke>so we may just postpone this all a bit, dunno <samplet>Makes sense. I was thinking about the self-extracting Guile, but I figured there was a more fundamental approach too (which I guess is running Gash on Mes). We will see what happens first. ***apteryx_ is now known as apteryx
<apteryx>is someone else seing php test failures on current master? <civodul>janneke: i wanted to embed .go files in special sections of the 'guile' binary <civodul>so we can have a single standalone file <oriansj>samplet: actually with stage0; is is straight bootstrap from a 357byte hex0 using unpacked sources until you get to mes-m2 and then one could simply provide an unpacked gzip/tar scheme program(s) to do the rest from there ***stikonas_ is now known as stikonas
<apteryx>hello, 'make check-system' fails because PHP 7.3.11 fails its test suite. Should we revert the commit that bumped its version? <apteryx>hmm, seems it could be built by the build farms <vagrantc>anyone know of guix folks around madrid, spain? will be passing through there on my way to the reproducible builds summit <janneke>sneek: later tell vagrant, thanks for dropping by on #bootstrappable with the great news about mes! it would be great to look at cross distro builds! <bandali>janneke, did you perhaps mean vagrantc? <bandali>(not sure if sneek can do approximate nick matching ?) <janneke>bandali: yeah, that won't work -- tnx <janneke>sneek: later tell vagrantc, thanks for dropping by on #bootstrappable with the great news about mes! it would be great to look at cross distro builds! *janneke really enjoys so much help and kindness <roelj>So, when I try to run a Docker image created with "guix system docker-image ..." it fails with "failed to start service 'host-name'", even though I only added one service to the services list (I even excluded %base-services). <roelj>How is the created image supposed to be run? <oriansj>roelj: well docker images run in docker <roelj>oriansj: Yeah sure. So I did "docker load < $(guix system docker-image ...; docker run -it ..." <roelj>I also tried to run it as a VM with "guix system vm ...", which worked fine. <jje>how are we supposed to run opensmtpd as a service? i have it configured as a service but shepherd always says it is stopped. when i run "sudo herd start smtpd" herd says "failed to start smtpd. are the some shepherd logs i should consult? and when i run "sudo smtpd" from the command line it starts right up. what am i doing wrong? <civodul>jje: does /var/log/messages contain hints? <civodul>that's where shepherd logs its messages <jje>civodul: /var/log/messages just says "shepherd[1]:failed to start service smtpd".