IRC channel logs

2019-11-17.log

back to list of logs

<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>hmm
<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>but first figure out which guix produces 1iy
<leoprikler>so that you're not repairing a working libwacom by accident
<malaclyps>oh good point I see what you mean
<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>but did that not produce a different one?
<leoprikler>oh, btw. did you check in the log of guix system build if libinput was built?
<malaclyps>leoprikler, how can i do that?
<leoprikler>In retrospect? With a lot of scrolling, I'm afraid.
<leoprikler>but okay, no biggie
<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>okay, so it used an already existing libinput
<malaclyps>i wish i better understood this error message: http://paste.debian.net/1116577/
<leoprikler>we just don't know which one
<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 ._.
<leoprikler>oh, wait, there's no --repair
<malaclyps>leoprikler, yep, i tried it with both --check and --repair and got the same error
<malaclyps>sigh
<leoprikler>ah, okay
<leoprikler>I'm still a noob
<malaclyps>me too!
<leoprikler>So the behaviour of --check is to error if there's a mismatch
<malaclyps>--repair doesn't seem to do anything
<malaclyps>very very tempted to just mount the /gnu/store partition RW and just blow this away
<leoprikler>don't do that
<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
<malaclyps> http://paste.debian.net/1116583/ -- there are a lot of attempted read/write locks before this
<leoprikler>Hmm
<leoprikler>Can you `guix gc --delete /gnu/store/1iy0fwk1hmvangichipg9kh9pwynl40y-libwacom-1.1`?
<malaclyps>no, it's still alive
<leoprikler>does it tell you what keeps it alive?
<malaclyps>no, sadly!
<malaclyps>maybe if i remove those generations
<malaclyps>and then gc
<leoprikler>generations? (plural?)
<malaclyps>yep, I've tried to do this a couple of times now
<leoprikler>okay
<malaclyps>(oh actually i effectively deleted that earlier generation by rolling back and then building this one)
<malaclyps>one moment while i reboot
<malaclyps>thank you for your suggestions!
<leoprikler>wait before you reboot
***daviid is now known as Guest65407
<leoprikler>some generation still references this corrupt libwacom, does it not?
<leoprikler>it would be bad if that is the newly built one
<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>did guix gc
<malaclyps>nope, still live!
<malaclyps>(apologies to everybody else on the channel having to scroll through all this!)
<leoprikler>hmm
<leoprikler>I give up, let's try reconfigure and reboot
<malaclyps>hahah
<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
<malaclyps>see you on the other side
<leoprikler>wait
<leoprikler>which roots are there?
<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>nice
<malaclyps>hooray i have garbage collected it
<leoprikler>btw which path appears now if you do list-busy | grep libwacom?
<malaclyps> . /gnu/store/z2zazz1xkb09r5d1ycz7fzgc62bm7av7-libwacom-0.33
<leoprikler>still the wrong one *sigh*
<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
<leoprikler>but will that be used if you reconfigure?
<malaclyps>no
<malaclyps>i mean, the 1.1 one should be used
<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.
<raghavgururajan>test
<malaclyps>leoprikler, thank you for helping fix my problem (and thank you for everyone else fo bearing with me)
<leoprikler>btw. you probably want to fix your path issues
<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>leoprikler Thanks for the info regarding 'gtk+:bin".
<raghavgururajan>ya hooo! Successfully packaged a package for guix for first time :))))
<malaclyps>raghavgururajan, nice work!
<raghavgururajan>gnome-characters works :)
<raghavgururajan>malaclyps Thanks :)
<leoprikler>yay, no more gnome-character-map
<malaclyps>leoprikler, hey man, you can just say how you would do it, rather than talking about how disgusting it is
<leoprikler>I'm not really sure tbh
<leoprikler>I don't do anything of the sort inside my own shell and it just works fine
<Deee-2>KDE Plasma would be nice :-)
<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>oh yes, you did
<malaclyps>how does bash handle it?
<leoprikler>I'm using zsh too
<leoprikler>My guix-specific zshrc lines consist of "fpath=(/run/current-system/profile/share/zsh/site-functions/ $fpath)" before the autoloads
<malaclyps>ooh
<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>~magic~
<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>what are you using?
<malaclyps>wayland, sway, sddm
<leoprikler>that doesn't sound too bad
<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>(of course with variables expanded)
<leoprikler>do you have something similar without your hack?
<leoprikler>btw. this should work regardless of environment, see /etc/profile
<leoprikler>which should be sourced by ~/.zprofile
<malaclyps>i don't have a .zprofile
<leoprikler>that's your problem
<leoprikler>create one with "source /etc/profile" in it and you need no other hacks in
<leoprikler>~/.zshrc or elsewhere
<malaclyps>okay, i'll try that!
<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
<leoprikler>do you have goa:lib as input?
<leoprikler>s/goa:lib/gnome-online-accounts:lib/
<raghavgururajan>leoprikler Yes, I have that as input.
<raghavgururajan>("gnome-online-accounts:lib", gnome-online-accounts "lib")
<leoprikler>hmm
<leoprikler>may i see your package in full?
<raghavgururajan>leopprikler https://bin.disroot.org/?4dfae7b26a29db57#ra2uCsslJMkao7MGQ3549tUVCmbH/tXEblWhERtBQPg=
***catonano_ is now known as catonano
<leoprikler>okay, first things first, your unquotes are off
<raghavgururajan>unquotes? Whats that
<leoprikler>your displaced commas
<raghavgururajan>oh inputs?
<leoprikler>yes
<raghavgururajan>okay, I'll fix that.
<leoprikler>you're also missing ("docbook-xml" ,docbook-xml-4.2)
<leoprikler> ("docbook-xsl" ,docbook-xsl)
<raghavgururajan>Thanks! done.
<raghavgururajan>So now I dont see error regarding docbook. Only error related to goa.
<leoprikler>yep, I'm building an environment to debug that
<raghavgururajan>Thanks so much
***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
<raghavgururajan>leoprikler Okay. I was looking at meson.build file
<leoprikler>after some t&e I got a vapi file
<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>leopprikler Sorry, not able to understand.
<raghavgururajan>Do you want me to add the above line in the package definition?
<leoprikler>Not quite
<raghavgururajan>leoprikler So in meson.build file, there is this:
<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>which recent conversation?
<raghavgururajan>*package definition
<raghavgururajan>I meant your last message regarding vapi
<leoprikler>Ah, yes
<leoprikler> https://bin.disroot.org/?4dbd494a037983a4#g5VbCGhM9H/BflzwEVg3zaxnMEE5z89DolQ9tMG6/SY=
<leoprikler>This works up to the installation
<leoprikler>you probably have some replacements of gtk-update-icon-cache to do
<raghavgururajan>Thanks so much.
<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).
<leoprikler>btw. install Emacs
<leoprikler>and with that, I'm off to sleep
<leoprikler>good night
<raghavgururajan>leoprikler Good Night I worked!!!!!!!
<raghavgururajan>*it
<raghavgururajan>Yee hoo!! So gnome-contacts is not off the check list :-)
<raghavgururajan>*now
<raghavgururajan>Oh oh. It does not run.
*raghavgururajan is pondering
<bandali>hey folks, anyone know if it’s possible to use guix without a wm?
<bandali>and e.g. use a tty only ?
<samplet>bandali: It sure is! Section 8.1 of the manual gives an relevant example of a “bare bones” system.
<bandali>samplet, great, ty!
*raghavgururajan found a fix :-)
<atw>hello bandali!
<bandali>hey atw!
<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>atw, cheers! i hope you enjoyed it
<atw>quite!
<bandali>also, videos are coming out very soon btw :)
<bandali>awesome, happy to hear that!
<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]>Yes gimme a sec to pull them
<elais[m]>It prints my password to the try and says Removed session c2
<elais[m]>Afterwards it's ntpd messages.
<elais[m]>New session c3 of user elais
<elais[m]>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")))) ...)
<elais[m]>I'll try to add Wayland to my packsges
<elais[m]>Packages
<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>with prboom-plus, I reproduced your problem. I read https://github.com/freedoom/freedoom#how-to-play, which recommends gzdoom. With gzdoom, I could start freedoom1, but the textures were thoroughly messed up
<atw>tried freedoom1 with chocolate-doom, that appears to crash ("Bad V_DrawPatch")
<gnutec>atw: See the link.
<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>Maybe I should try red-eclipse. ashuashuahsuahsuh http://www.thegameengine.org/wp-content/uploads/2013/03/red_eclipse.png
<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?
<raghavgururajan>It appears shebang is already fixed in the process.
<raghavgururajan>Please leave me a message via sneek . I'll rejoin in a while.
<gnutec>elais[m]: Have the same problem in XFCE. But not with gnome.
<raghavgururajan>Hello Guix!
<efraim>hi!
<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
<raghavgururajan>Hello Guix!
<rockandska>Hi guix
<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> make things run
<leoprikler>10:44 <leoprikler> if that's the case, add
<leoprikler> gsettings-desktop-schemas to inputs and glib:bin
<leoprikler> to native inputs
<leoprikler>... i need to pay better attention to QUIT messages
<gnutec>Uhuu! https://photos.app.goo.gl/e9Pwb6JhmLjPdaBNA
*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>Speaking of which....
<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.
<janneke>samplet: that is very good news!
<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>yay for wip-full-source-bootstrap!
<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
<ArneBab_>samplet, janneke:0that sounds awesome!
***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!
<sneek>Okay.
<janneke>sneek: botsnack
<sneek>:)
<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!
<sneek>Will do.
<janneke>sneek: botsnack!
<sneek>:)
<bandali>janneke, cheers
*janneke really enjoys so much help and kindness
<bandali>^_^
<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.
*civodul found a nice trick for https://issues.guix.gnu.org/issue/38226
<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>hi jje
<civodul>jje: does /var/log/messages contain hints?
<civodul>that's where shepherd logs its messages
<civodul>via syslogd
<jje>i will check
<jje>civodul: /var/log/messages just says "shepherd[1]:failed to start service smtpd".