IRC channel logs


back to list of logs

<nckx>genericspider: At first glance, Guix's libextractor seems to be incompatible with the version of exiv2 in Guix.
<nckx>So the fix would be to find a working version combination.
<nckx>But first you should probably file a bug 🙂
<genericspider>Will Guix use a preinstalled library if I try to build?
<genericspider>Because I could always try to build my own version.
<genericspider>But yeah, I will file a bug report.
<EternalZenith>Does the Guix system installer support luks, or does that have to be configured manually?
<nckx>genericspider: I just tried to build it myself, if that's what you mean, it's not a sometimes-error.
<nckx>So the build farm will not be able to build it, so there are no binaries, anywhere.
<nckx>I *think* that answers your question.
<Dynamicmetaflow>nckx: how were you able to determine spice-gtk dependencies?
<nckx>EternalZenith: There's *code* to handle it (as in, I grepped gnu/installer for ‘crypt’). I haven't tried it myself though.
<genericspider>I mean if I build exiv2 manually and stick it in my /usr/lib directory (or wherever it would go) and have it use that instead.
<genericspider>I imagine some modification of the makefile would need to be done though
<nckx>Dynamicmetaflow: cat `guix build spice-gtk`/lib/pkgconfig/*
<Dynamicmetaflow>thank you!
<nckx>genericspider: But how would you build exiv2 manually? Either you'd build the exact same version that Guix had, with the same problem (it will still not provide that ‘conflicting return type specified’ discrepancy), and if you know which version to use instead you can just up/downgrade the Guix package to that version.
<nckx>I'll see if I can find out more but it won't be this hour.
<nckx>s/not //
<genericspider>I'm new to build systems in general, so thanks for the tip.
<nckx>General question: does setting my status to ‘away’ actually make a difference in common IRC clients?
<nckx>Like I am doing… now.
<ryanprior>Guix folks who use Emacs: do you use guix to manage your elisp packages? Is there a library like `use-package` that you use to manage packages from within elisp code or do you do that outside Emacs?
<Dynamicmetaflow>ryanprior: Check out this link
<nckx>ryanprior: I install emacs packages through Guix and use use-package just for the syntax, not to ‘manage’ them.
<nckx>Wow. What Dynamicmetaflow just pasted is… what is it?
<Dynamicmetaflow>I need to post this script from the mailing list, it uses the ELPA importer and imports emacs packages from MELPA.
<Dynamicmetaflow>Instead of having to use the ELPA importer for each emacs package you want, you can define a list of packages you want to install and it pulls it from MELPA.
<Dynamicmetaflow>Emacs packages are then autoloaded and then within emacs I use use-package to configure it
<Dynamicmetaflow>all emacs packages are managed by guix
<ryanprior>nckx: to dig into what you said: if I have a package installed via guix and then I invoke `use-package` will it pick up the already-installed version and not download a new version over it?
<ryanprior>Okay that sounds pretty usable.
<ryanprior>Possible migraiton plan: get a list of what packages are installed now in my Spacemacs, install all those onto my Guix system, and then delete (rename) my elpa folder. Does that sound sane? Anybody else do similar?
<Dynamicmetaflow>ryanprior: check this out for configuring use-package
<Dynamicmetaflow>you will also want to declare your package-user-dir
<Dynamicmetaflow>(setq package-user-dir "/home/alexander/.guix-profile/share/emacs/site-lisp/")
<Dynamicmetaflow>for package.el
<Dynamicmetaflow>nckx: I'm about to give up with gnome-boxes lol
<Dynamicmetaflow>i think will have to pick it up tomorrow again
<Dynamicmetaflow>hopefully once I have more of an understanding of how guix packages different packages I will be able to contribute and package packages
<nckx>Live to fight another day.
<Dynamicmetaflow>de verdad
<Dynamicmetaflow>nckx: Thanks for your help! Wouldn't have gotten this far without you.
<nckx>De nada.
<ryanprior>I've read the packaging guide and still feel like I understand practically nothing about how to package software X.X like unless it's a C program with basically no dependencies other than `make` and `gcc` im like ??
<Dynamicmetaflow>That's been my whole today
<Dynamicmetaflow>whole life*
<ryanprior>I've also read a few packages using `guix edit [packagename]` and they totally overwhelm me
<ryanprior>I feel confident I can get it eventually - I've built Debian packages, node packages, gems, Docker containers, Ansible playbooks, so I'm like darn it if I'll walk away defeated, but it's not clicking yet.
<nckx>can't even.
<trzcdev>ryanprior, I'm lurking in hopes of learning more about Guix packaging. I find your questions, and people's repsonses, helpful.
<ryanprior>Thanks for saying so trzcdev! And yes big thanks to folks who answer questions, it's so appreciated.
<nckx>trzcdev: Do you run Guix yourself?
<Dynamicmetaflow>trzcdev: Make the leap! I highly recommend it
<Dynamicmetaflow>nckx: Suggestions?
<Dynamicmetaflow>Getting the same src/ ERROR: Vala library 'spice-client-gtk-3.0' not found
*nckx builds it.
<Dynamicmetaflow>nckx: hugs
<nckx>Dynamicmetaflow: What's your wgetpaste command line? We should really fix that ‘$’ and the error messages, even if it's probably not our bug.
<Dynamicmetaflow>I've been doing wgetpaste -c ' <insert code snippet> '
<nckx><code snippet> being? That file? Because -c expects a command: wgetpaste -c 'echo foo' →
<nckx>OK, then it's not wgetpaste's fault. wgetpast < the-file.scm should work better.
<Dynamicmetaflow>for some reason.. I thought.. my mistake
<nckx>Dynamicmetaflow: Well, the error message is right (ignore the maybe misleading first -1.0): ‘need 'libvirt-gconfig-1.0' ['>= 2.0.0'] found '1.0.0'.’
<nckx>So it really needs libvirt-config 2.0, not 1.0, and we have 1.0.0.
<nckx>So your mission, if you choose to accept it, is to update libvirt-config to 2.0 and make sure nothing breaks. Or wait for me (or someone else) to do so, but I won't have time tonight.
<nckx>Sorry about the bumpy ride but that's just the fun of packaging.
<nckx>Somebody keeps changing all the software.
<nckx>When I find out who…
<Dynamicmetaflow>nckx: Thanks! What do you means someone keeps changing all the software
<Dynamicmetaflow>And isn't libvirt-config part of libvirt-glib?
<nckx>Nothing, just silliness. It's just so damn hard to keep up with all these updates sometimes.
<nckx>Dynamicmetaflow: Yes. You got that right in your package. But we have libvirt-glib 1.0.0, and gnome-boxes expects (at least) 2.0.0.
<Dynamicmetaflow>so i already updated libvirt-glib to 2.0.0
<nckx>Oh, sorry, I managed to miss that relevant fact.
<nckx>Then I guess ‘wait whut’ is my official response on the matter.
<Dynamicmetaflow>nckx: LOL
<wdkrnls>any suggestions for configuring tooling for guile/geiser so it becomes easier to inspect the magic incantations of guile code used to make packages?
<wdkrnls>My geiser doesn't seem to know anything about the gnu guix libraries.
<wdkrnls>I too really see the value (also the necessity) of being able to package my own stuff in guile.
<nckx>Dynamicmetaflow: Well this is not what I expected. /gnu/store/c3f0hrzabhf9hvsybpiwxyvk6nf4d0nv-libvirt-glib-1.0.0/lib/pkgconfig/*.pc all still say ‘Version: 1.0.0’
<ryanprior>good question wdkrnls , I would like to figure out how to macro-expand the guix package definitions in geiser
<ryanprior>I think you need to have the guix libraries installed, but I'm not sure how to do that (does it have to do with guildhall, the package manager? or do you do this with guix itself?)
<Dynamicmetaflow>nckx: that's interesting...
<nckx>It might be, yes. I'm dealing with a failed RAID drive right now but this has certainly got my attention as next task 🙂
<Dynamicmetaflow>also is that gnu/store you are referencing the one in your system
<Dynamicmetaflow>or from source
<nckx>Aw shat, it was just a stupid mistake I made while distracted by the RAID alarms going off. Never mind…
<nckx>No, the 2.0.0 .pc files all say 2.0.0, as they should.
<Dynamicmetaflow>ah ok
<Dynamicmetaflow>nckx: still stumped but at least they say 2.0.0
<nckx>Dynamicmetaflow: That store file name (even though it was pointing to the wrong 1.0.0 one) is on my system, but due to the way Guix works, we will have the exact same path when building the same libvirt-glib.
<nckx>Yeah, it's still weird, just weird somewhere else…
<Dynamicmetaflow>nckx: thanks for the info... I have a lot of gnome-boxes builds does gc take care of that?
<Dynamicmetaflow>i mean gnome-boxes drv files
<nckx>Dynamicmetaflow: It will, yes. But don't let's gc (unless you need the space) while working on this package, you'll probably have to re-build/download things.
<Dynamicmetaflow>nckx: ah ok, thanks
<nckx>(Because the GCor looks at ‘installed’ items, and we haven't managed to install a single gnome-boxes yet to serve as GC root.)
<nckx>I should also add that .drv files don't really take up space (they are a few K at most).
<Dynamicmetaflow>yeah i just saw drv and build files about 300 or so
<Dynamicmetaflow>and then remembered about gc and also drv are text files but wanted to ask to make sure about
<nckx>Dynamicmetaflow: So I've ‘updated’ libvirt-glib to 2.0.0 (as in I've bumped the version and hash, but haven't done any more due diligence) and I get ‘Vala library 'spice-client-gtk-3.0' not found’ now too.
<nckx>…these error messages are really not doing it for me…
<nckx>So spice-client-gtk-3.0.pc Requires: gtk+-3.0 >= 3.22 spice-client-glib-2.0
<nckx>We have gtk+-3.24 so that's fine.
<nckx>spice-client-glib-2.0.pc (are you having fun yet?) Requires
<nckx>And Requires.private: pixman-1 >= 0.17.7 openssl
<Dynamicmetaflow>nckx: Well now I don't feel alone, we are getting the same errors lol
<nckx>…so let's add spice-protocol and see if we can ignore Requires.private for now since I admit to not really knowing what that means…
*nckx bilding.
<Dynamicmetaflow>ok,crosses fingers
<Dynamicmetaflow>also how do you do the * <i am doing something>
<nckx>Dynamicmetaflow: 😃 I type:
<nckx> /me is doing something
<nckx>without the leading space.
*nckx gets that question suprisingly often, about twice a month or so.
*Dynamicmetaflow testing irc
*Dynamicmetaflow wonders why it took him so long to have an inner-monologue...
*Dynamicmetaflow building....
<nckx>Adding all 3 packages (in gnome-boxes directly, yes that's cheating, yes it should be done in libvirt-* when adding to Guix) gives me the same error :-/
<nckx>ERROR: Vala library 'spice-client-gtk-3.0' not found
<Dynamicmetaflow>Same here...
<Dynamicmetaflow>I've been drawing a blank from this point
<Dynamicmetaflow>nckx: I'm even comparing the gnome-boxes packages from other distros in case I've missed something and nothing unsual comes up
<nckx>Remember -K from earlier? Are you still using that?
<nckx>It will print something like ‘note: keeping build directory `/tmp/guix-build-gnome-boxes-3.32.1.drv-5'’ (the number may differ), in that directory you'll find build/meson-logs/meson-log.txt.
<Dynamicmetaflow>although i used lowercase -k ....
<nckx>Well, no 😛
<Dynamicmetaflow>nckx: ok well using upper case -K now
<Dynamicmetaflow>nckx: I was wondering why i coudln'y access that meson-log file...
<nckx>Yeah, I didn't mention it because it doesn't seem to contain the key to all this.
<nckx>And didn't want to confuse you with n threads of investigation at once.
*nckx admits to being in ‘teacher mode’…
<nckx>All it says is: error: Package `spice-client-gtk-3.0' not found in specified Vala API directories or GObject-Introspection GIR directories | Searched [] and 'spice-client-gtk-3.0' wasn't found
<Dynamicmetaflow>nckx: As someone who used to be a teacher, thank you for understanding cognitive load theory
<Dynamicmetaflow>Yeah reviewing the meson-log.txt I get the same error
<Dynamicmetaflow>so it's a mattery of specifying paths?
<nckx>That might mean something to someone better versed in Meson/Vala than I am but it's very much not my world.
<nckx>Mmaybe? I can't really say. I'm not into Gnome, like, at all.
<Dynamicmetaflow>nckx: same... i only want gnome-boxes lol
<nckx>I use the meson-build-system as a black box that poops working Gnome things. When it doesn't, welp, here we are.
<Dynamicmetaflow>well going to do some research
<Dynamicmetaflow>nckx: lol
<nckx>The empty [] is definitely suspect.
*nckx points out the obvious.
<Dynamicmetaflow>hmm yeah
<Dynamicmetaflow>seems like we need to pass something to vala
<Dynamicmetaflow>maybe related?
<nckx>I don't see how. Could you elaborate?
<Dynamicmetaflow>Well it can't find spice-gtk and it's talking about some vala binding
<Dynamicmetaflow>reading more about it
<Dynamicmetaflow>nevermind not really related
<nckx>Indeed, I don't think it should affect us.
*nckx has put the issue aside for now but remains present & interested.
*Dynamicmetaflow is determined to build this!
<nckx>You're pretty damn close.
<Dynamicmetaflow>Thanks! This is why I want to figure it out
<Dynamicmetaflow>and I also think a lot of people in the community would benefit
<Dynamicmetaflow>I thought about just creating an interface in emacs to do what gnome boxes does
<nckx>Throw up your current state on the mailing list when you go to bed or run out of ideas, the solution might be obvious to someone familiar with Vala. #guix is also pretty quiet during the Euronight.
<Dynamicmetaflow>but then I thought I will never learn how to do a guix package so here i amfl
<nckx>Gnome boxes is definitely a box (er, not intended) we want to tick. 👍
<jackhill>win 23
<Dynamicmetaflow>Ah yeah I've noticed that, east coast time here
*nckx stares at the clock and the clock stares back… 02:49.
<Dynamicmetaflow>still working on that raid setup?
<rvgn>Dynamicmetaflow All the best! I would be greatful as I benefit from that too :)
<nckx>It's happily syncing away. I'm trying to find a way to get IceCat to install and respect system locales.
*nckx was thinking of rvgn specifically above 🙂
<Dynamicmetaflow>rvgn: Hola! Thank you! That gives me motivation!
<Dynamicmetaflow>nckx: by system locales, you mean like languages?
<rvgn>nckx You mean for Icecat?
<rvgn>Dynamicmetaflow :)
<nckx>rvgn: No, when I mentioned that Gnome Boxes is definitely something ‘we’ want.
<Dynamicmetaflow>also side tangent, does it matter if it's ("gtk+3" ,gtk+) or ("gtk+" ,gtk+)
<nckx>Dynamicmetaflow: It doesn't.
<Dynamicmetaflow>ok making sure..
<nckx>It can be ("foobuzz" ,gtk+) for all Guix cares. It's just a text label, and only relevant when using (assoc-ref inputs "gtk+") in a phase.
<rvgn>nckx Ah I see. Yeah! I badly need gnome-boxes as virt-manager failed me with
<nckx>The plan is to eventually support just the package name and derive the label from that.
<nckx>rvgn: I know ☹
<nckx>s/package name/package variable/
<Dynamicmetaflow>rvgn: yeah, i couldnt get virt-manager working either after much tinkering, i was able to get the flatpk of gnome-boxes to work. problem was that i would create the vm and then if i started up gnome-boxes it woudlnt initiate the vm anymore. i think that error is related more to flatpk rather than gnome-boxes
<rvgn>‎Dynamicmetaflow‎ I was thinking of flatpack too. But using that when we have guix was kind of diabolical to me. xD
<nckx>Hey neato 5 years of Guix and tonight I learn that we tab-complete packages on the CLI.
*nckx livin' the functional manifest lyfe.
<Dynamicmetaflow>rvgn: I agree...
<Dynamicmetaflow>I've actually been tinking of using qubesos
*rvgn is being very loyal to guix :-)
<Dynamicmetaflow>as my main distro and using guix template client machines
<Dynamicmetaflow>but i really would prefer to stay in guix
<rvgn>I see.
<Dynamicmetaflow>so what i want to do is replace some of qubes functionaly with Guix
<Dynamicmetaflow>that gets into hypvervisor and some other virtualization tech that requres more reading
<Dynamicmetaflow>also has anyone used this
<Dynamicmetaflow>The Libvirt Sandbox project is an effort to facilitate the use of libvirt virtualization drivers for the purpose of sandboxing applications. The key features of the project are:
<raingloom>heyy, how do I get outputs in 'configure? it seems like i can't use `(#:key inputs outputs #:allow-other-keys)`
<Dynamicmetaflow>the sandboxing of applications intrigues me and i wonder if it's like qubes appvm
<nckx>raingloom: Nope, you can't, you have to use the slightly uglier %outputs global variable.
<raingloom>....yikes. thanks nckx
<nckx>(Same for %build-inputs instead of inputs.)
<nckx>raingloom: I see the ' now. Did you mean #:configure-flags or the 'configure phase?
<raingloom>'configure phase
<nckx>Oh. But you can use them there.
<raingloom>huh. then i probably messed up the syntax. the error is kind of unclear.
<nckx>It's Guile; sounds legit.
<raingloom>oh. i have to use lambda*. duh.
*raingloom palms face
<nckx>(Sorry for misreading your question, it just so happens that it's a common question about #:configure-flags.)
<Dynamicmetaflow>so in the gnome-boxes-3.2xxx/src there is a
<Dynamicmetaflow>when building does gnome-boxes are the contents of that passed? like is vala_args used?
<ryanprior>Does guix support the meson build system? There's a ton of stuff in the Gnome & elementary OS sphere that's using it these days.
<ryanprior>According to it looks like there is `meson-build-system` which gives you Meson and Ninja
<ryanprior>I don't see anything about supporting `` but I would hope it would be part of the build and would get passed to meson during the configure step?
<Dynamicmetaflow>ryanprior: yeah, i've been trying to package gnome-boxes, with the help of nckx and few people here.
<Dynamicmetaflow>almost there but running into some issues related to spice-client-gtk, where vala can't find the library, so i'm looking into the and spice-display.vala source now
<ryanprior>That's great, I would like to try and get a bunch of elementary OS stuff into guix so I should follow your effort :)
<nckx>Dynamicmetaflow: Yes. You should be able to use #:configure-flags (list (string-append "-Dvala_args=" …)) if you know what the expected args are.
<Dynamicmetaflow>Well this is my first time doing a contribution and packaging, so your experience and support is appreciated :)
<Dynamicmetaflow>nckx: Thanks!
<nckx>ryanprior: Meson should be fully supported, and if Ninja is the thing that build Chromium, well, we package that so it must be at least partly working.
<Dynamicmetaflow>from the, this looks interesting
<ryanprior>ninja is a dependency of the meson build system. meson pitches the balls and ninja hits 'em, so to speak.
<nckx>Aha. Thanks.
<Dynamicmetaflow>the line for gio-2.0 specifies vapi_dir and the vala_args look interesting
<Dynamicmetaflow>I don't think the library exists?
<Dynamicmetaflow>it's not part of the source
<nckx>Dynamicmetaflow: Which library?
<Dynamicmetaflow>if you go to gnome-boxes-3.32.1/vapi
<Dynamicmetaflow>you see gio-2.9-workaround.vapi
<Dynamicmetaflow>but I don't see spice-client-gtk-3.0
<Dynamicmetaflow>im going to grep and see where it is
<nckx>I was grepping for ‘gio-2.9-workaround’ earlier but I forgot why, smells like we both came close to the same place.
<nckx>Is it not part of spice-gtk instead?
<nckx>I can see why GB ships a ‘workaround’ to something in gio (glib), but the regular spice-client-gtk is not their responsibility.
<Dynamicmetaflow>yeah.. well it's asking for a library and it's not included by GB
<Dynamicmetaflow>so my question is where do i get this library, since we already installed spice, spice protocol and spice-gtk and not getting anything
<Dynamicmetaflow>unless we have to point the to where spice-gtk is?
<nckx>Dynamicmetaflow: That's pretty much the most likely case.
<Dynamicmetaflow>the spice-gtk we have is 0.36?
<Dynamicmetaflow>and it's asking for 3.0?
<nckx>(At least I don't have to feel bad about not having more time to help you with this, you're doing just fine.)
<Dynamicmetaflow>lol, you have been an excellent teacher. Thank you.
<nckx>Dynamicmetaflow: No, that's the ‘confusing’ thing I noted earlier: the -3.0 is not the package version. In the output of our spice-gtk package, you'll see a lib/pkgconfig/spice-client-gtk-3.0.pc file, despite the package being at 0.36.
<nckx>This file wil have a Version: line with the latter number.
<Dynamicmetaflow>hmm i wonder if that's part of the problem?
<nckx>3.0 is the soname/ABI version or somesuch.
<nckx>It shouldn't be.
<nckx>This is how the system is designed, I doubt it.
<nckx>Your notion of pointing GB's vala towards spice-gtk paths was more promising.
<Dynamicmetaflow>Yes, now how to do that
<nckx>And thanks.
*Dynamicmetaflow opens the package tutorial and manual...
<nckx>I think I gave you the Guix part of the puzzle above: it would look like #:configure-flags (list (string-append "-Dvala_args=--somevalaoption=" (assoc-ref %build-inputs "spice-gtk) "/some/path")).
<nckx>(Assuming vala_args is the thing that will fix all these troubles, which we don't know, but hey.) The two ‘some’things are Vala-dependent, the Guix manual can't help you there.
<Dynamicmetaflow>yeah that's what i was looking into... let's try it out!!
<romulas>I have had a kernel crash last time I booted from a usb, how do I collect the log files?
<nckx>romulas: Erm, probably not. Where would they be stored?
<romulas>On the usb...
<nckx>The USB drive isn't mounted read-write.
<romulas>I see
<nckx>I don't think that's even possible, being really a DVD (ISO) that can also be dd'd to USB drives through some clever hackery. But the iso9660 filesystem is read-only by design.
<romulas>So should I just diconnect all devices that crash the kernel?
<romulas>I assume they are the usb devices that can't load a driver.
<nckx>I guess that would be as good a first step as any.
<nckx>What did the panic say?
<romulas>Something about the driver wasn't deblobbed
<romulas>bluetooth if I remember
<nckx>(There are ways Guix could be extended to store panics somewhere, but it's still not as simple as having a writable USB. There is much complexity involved. You'd boot a whole new kernel to perform an autopsy on the old one… lots of work. There are simpler methods but they carry risks.)
<nckx>romulas: If this happens again, could you upload a screenshot (it may be a literal photo) to a friendly website and send a bug report to
<nckx>The /*DEBLOBBED*/ thing is probably not what caused this.
<romulas>I mean it wasn't deblobbed
<Dynamicmetaflow>I love spices, especially on my food. After this experience I don't think I'm going to have anything spicy for some time now..
<nckx>The Guix kernel *is* deblobbed. That just means it won't load any non-free firmware. So your Bluetooth devices that require non-free firmware wouldn't work, which is a shame, but it's very unlikely to crash your kernel also.
*nckx just put some Sriracha in their soup and is enjoying it very much.
<romulas>Okay I will try it again let me download the iso and load it to my usb
<romulas>Thanks for the help.
<nckx>romulas: If you're downloading it again (presumably to rule out corruption?), be sure to verify the signature. It will catch a damaged download.
*Dynamicmetaflow thinks nckx has strong mental fortitude to put Sriracha on food after dealing with the Boxes that shall not be named
*nckx just has a Problem.
*Dynamicmetaflow is updating spice-gtk to 0.38 has a small attempt to see if it autofixes
<apteryx>how can i remap some key to another one? xmodmap doesn't seem to work on Guix
<sneek>Welcome back apteryx, you have 1 message.
<sneek>apteryx, str1ngs says: you don't need C bindings for this. just write the fields to /dev/input/by-path/platform-pcspkr-event-spkr using guile.
<apteryx>str1ngs: oh! interesting... I thought the fields were meant to be a C struct. Is it possible to have the equivalent directly from Guile?
<nckx>apteryx: How so? I use it.
<nckx>xmodmap -e "keycode 151 = Multi_key" # Thinkpad's Fn button
<apteryx>nckx: i've tried for example: xmodmap -e 'keysym Muhenkan = Control_L' to remap some weird Japanese key to a left control. xev shows that pressing that key gives me the right Control_L keysym/code, but it has no effect.
<apteryx>(in xterm, or anywhere)
<nckx>Well, I've never owned a weird Japanese keyboard (they look cool though), but I don't think the problem is xmodmap + Guix per se.
<apteryx>lemme try remmanig the keycode 151 to Control_L to see
<nckx>I just rebound my Fn key to Control_L and xev sees it.
<apteryx>but can you use it as a control key, in emacs or xterm?
<Dynamicmetaflow>so nckx have do you have any interest after hopefully packaging gnome-boxes, want to tackle nextcloud :p
<nckx>apteryx: Ah. Nope.
<apteryx>that's my problem
<nckx>I assumed it was my ‘fault’ for also rebinding my actual left Control key to Caps Lock.
<apteryx>yeah, I thought the same (I do that also), but even after clearing that with 'setxkbmap -option', the problem remains
<nckx>It's not fun, but have you tried never setting that option in the first place (so, assuming you set it in system.scm, commenting it out, reconfiguring, and rebooting?). I remember having to do that once a long time ago. Wasn't even on Guix. Not a great bet but worth a shot if you're out of options.
<apteryx>nckx: I set this in my ~/.bash_profile, so I can comment it out and relogin
<apteryx>let's see
<romulas>virtualization problem
<nckx>Dynamicmetaflow: The main reason I haven't put NextCloud on my home server, just to see what it is, is probably that it's not a ‘guix install’ away, so sure, although I can't promise I'll like it & keep using it. Also, packaging Web stuff is often… not fun.
<Dynamicmetaflow>try out next cloud there from yunohost, yeah i agree. I think trying to package it will be challenging but also rewarding
<nckx>sneek: later tell apteryx: You probably know this, but just in case: (keyboard-layout) understands all XKB options and will even set them… on a VT! I was flabberghasted.
<nckx>Dynamicmetaflow: Does it use npm?
<apteryx>nckx: eh, didn't do it :-/
<sneek>Welcome back apteryx, you have 1 message.
<sneek>apteryx, nckx says: You probably know this, but just in case: (keyboard-layout) understands all XKB options and will even set them… on a VT! I was flabberghasted.
<Dynamicmetaflow>not sure, i think last i checked i saw a lot of php dependencies
<nckx>apteryx: Aw, shame ☹
<apteryx>nckx: that's cool! I have lots of dubious logic looking at different machines to do different things though... I'm not sure if that'd be easy to hack at the config level.
*nckx is reminded that a Webmail, any Webmail, would also be nice to have.
<nckx>(That's not a request, not even an implied one 🙂 )
<nckx>Dynamicmetaflow: Oh, so it's ‘App’-based? (And Yunohost needs to update one of them. 🙂)
<Dynamicmetaflow>yunohost is something else entirely
<Dynamicmetaflow>I directed you to yunohost so you could see nextcloud
<nckx>No, I know, I'm inside NextCloud.
<romulas>Alright email sent
<nckx>But it seems (or at least pretends to be) pretty modular.
<nckx>romulas: Thanks!
<romulas>It is a vitulzation bug
<romulas>virtulization bug
<romulas>There is the image above:
<nckx>Dynamicmetaflow: Unfortunately, JS stuff is often bundled. We have PHP, but no PHP ‘packages’ yet, so we're probably missing a php-build-system too.
<nckx>(I mean, I know we are.)
<Dynamicmetaflow>nckx: Damn..
<romulas>AMD-VI bug
<Dynamicmetaflow>I know this may be more than what I can do right now but I wonder what would a php build system entail
<romulas>Here is the image I sent in the email:
<nckx>romulas: Yep. It's not clear (as so often with Linux) if that's an error or a warning or something in between, but it's the only culprit we have. Let's hope someone on the list knows a lot about AMD virtualisation (I don't). In the meantime: does your firmware (BIOS/UEFI) provide an option to disable virtualisation for now?
<nckx>romulas: You've pasted that link 3 times now; are you unsure whether your messages are coming through? They are 🙂
<apteryx>nckx: it was a user error; xmodmap works, but to modify existing "modifier_map", you have to redifine the map, such as by doing "xmodmap -e 'add control = Control_L Muhenkan'"
<romulas>Yes it does
<romulas>bug#36757: Acknowledgement (AMD-Vi IOMMU bug, kernel crashes using GuixSD 1.0.1)
<nckx>Dynamicmetaflow: Erm, I know there's a difference between PHP modules, which are compiled, -ish? and PHP packages, which are just PHP. NextCloud needs both. But I just use PHP, I don't hack it.
<romulas>nckx: you a dev?
<Dynamicmetaflow>hmm good to know, thanks
<nckx>romulas: I guess so. I never got my spandex uniform or silly hat but sure.
*nckx is getting ready for bed since it is 4:34 and soon it will be light.
<nckx>Good night everyone.
<Dynamicmetaflow>nckx: Have a good night and rest! Thank you for all of your help
<romulas>yes ty
<romulas>So how is the herd work going?
<rvgn>nckx Let there be light xD
<Dynamicmetaflow>rvgn: lol
<Dynamicmetaflow>so what are you working on rvgn
<rvgn>Dynamicmetaflow‎ Atm, I am searching for job xD
<Dynamicmetaflow>Good luck, I should also be doing the same..
<rvgn>Dynamicmetaflow‎ I am also researching about BIOS vs UEFI and would like to know which going to be the future.
<Dynamicmetaflow>rvgn: cool
<apteryx>nckx: for the record, here's the solution to turn a Japanese keyboard into a useful Emacs ally:
<rvgn>Dynamicmetaflow‎ If you have any insight on that. Do share :)
<Dynamicmetaflow>honestly, i always forget the difference between UEFI and such
<Dynamicmetaflow>All i have to contribute is that I dabbled with coreboot and have flashed my thinkpads with it
<emacsomancer>hopefully coreboot &c. is the future, not either BIOS or UEFI
<rvgn>‎Dynamicmetaflow‎ I see.
<rvgn>emacsomancer‎ Coreboot is a firmware where as UEFI is the specifiaction (not a firmware by itself)??
<emacsomancer>that's true. and there is TianoCore which works with coreboot implementing the UEFI specification
<emacsomancer>from that perspective UEFI is probably the future since it offers some theoretical security advantages, as I understand it, but I'm not necessarily keen on the actual typical implementations of UEFI
<rvgn>‎emacsomancer‎ That's eaxctly my confusion. Will coreboot+bios or coreboot+uefi going to be the future.
<emacsomancer>I think it's worth looking into things like TianoCore (or Yabits). I believe there will at some point be hardware implications for using/not using UEFI.
<emacsomancer>e.g. some things will not work without UEFI
<rvgn>I see.
<emacsomancer>I've just been doing coreboot+bios on my current machines, because it's easy and I don't think I'd have much benefit from anything else, but for the future....
<Dynamicmetaflow>what are your concerns for the future, and when you say 'future' how far off you think.
<Dynamicmetaflow>I have to thinkpad x230, running coreboot with the seabios
<emacsomancer>Dynamicmetaflow: I have the same hardware currently.
<Dynamicmetaflow>ah dope
<emacsomancer>(plus some older thinkpads on libreboot)
<Dynamicmetaflow>16gb crucial ram + samsung evo SSD
<emacsomancer>but I think some of the newer ssds require uefi?
<Dynamicmetaflow>yeah I kinda stopped looking into that, once i got it up and running i was happy
<emacsomancer>Dynamicmetaflow: more or less the same, though my x230 has a samsung pro (I've got samsung evos in the x200s)
<emacsomancer>Dynamicmetaflow: re: the x230 - have you seen
<emacsomancer>it makes updating coreboot easier
<Dynamicmetaflow>also if you are ever interested in running Qubes i recommend this wireless card
<Dynamicmetaflow>i had a different atheros wireless card that didn't work, used this one and everything worked perfectly in qubes
<Dynamicmetaflow>I'm aware of the skulls project
<emacsomancer>I've currently got an Atheros AR5B22 card in it
<Dynamicmetaflow>ah great then
<rvgn>‎emacsomancer‎ You coud benefit from coreboot+grub better. It supports full disk encryption. I use libreboot+grub.
<rvgn>Dynamicmetaflow‎ By future I meant, standardisation and interoperability. Like how BIOS was there for long time.
<emacsomancer>rvgn it dumps into grub, where i do have full disk encryption. & my x200 has libreboot+gru
<rvgn>emacsomancer and Dynamicmetaflow I made this guide ( Could be useful for you both to setup full disk encryption. :)
<rvgn>‎emacsomancer Oh I see.
<emacsomancer>i think my guix x200 is set up more or less like that. though i just used the installer's full disk encryption set up
<rvgn>emacsomancer‎ Wait, the guix guided installer shows FDE as an option?
<emacsomancer>rvgn: yes, it's one of the options.
*rvgn has to try guided installation once
<emacsomancer>(though the installer is a bit buggy in some parts - choosing "wifi" seems to crash it)
<rvgn>Yeah that was "rfkill" thingy
<emacsomancer>and its keyboard choices are weird
<rvgn>emacsomancer‎ Dynamicmetaflow Could you both please share your system config? I would like see how guided installation geerated the config.scm.
<emacsomancer>rvgn: I've edited some things by hand since, but here is more or less the relevant pieces: (I changed the keyboard stuff within that, but I think that's irrelevant here)
<rvgn>Thank you!
<emacsomancer>(I have a single / setup, no separate /home etc.)
<Dynamicmetaflow>^^ opposite, multiple partitions on mine
<rvgn>emacsomance Is your current storage drive has MBR or GPT??
<rvgn>Did the installer gave you an option?
<rvgn>MBR vs GPT
<emacsomancer>I could choose either
<rvgn>I am pretty sure it would not have worked if you chose GPT. The installed would have exited with error "Failed to install bootloader on /dev/sda".
<emacsomancer>I suspect the same; which is why I choose mbr
<rvgn>The link I sent you; it has cutom bootloader config to make it work with GPT.
<emacsomancer>rvgn: ah!
<emacsomancer>do you find much advantage to gpt over mbr?
<rvgn>I read about technical difference between mbr and gpt and found out the latter was better.
<emacsomancer>I know you can have more partitions, and bigger disk size, but aside from that?
<rvgn>There was couple of listed advantages. storage size, backup partition table, guid etc.
<emacsomancer>right. for my usage here, I have a smaller drive with very few partitions, so some of the advantages were irrelevant to me, though I guess gpt has some checksumming stuff or something like that for the header, tables
<rvgn>Mainly I was impressed at backup partition table which provides redunancy. If something happens to first few sectors of storage drive, one can still use the disk with the back up table found at the last few sectors of the disk.
<emacsomancer>ah, that is a nice feature.
<emacsomancer> I wonder if you could contribute code to the guided installer to make gpt work right
<rvgn>Ah thanks! That's actually a good thought. I will try to do that. :)
<g_bor[m]>hello guix!
<kori>hello g_bor[m]
<brendyyn>Is anyone running Anki from Nix ontop of Guix System. When I try to run it i get an error could not find GLX
<g_bor[m]>brendyyn: Hello. I don't run Anki, but one thing I would look for is where does it try to find GLX.
<g_bor[m]>I believe this error comes up on stracing it might lead to results fast.
<g_bor[m]>come up on startup
<brendyyn>it looks in the nix store
<brendyyn>wow there is anki, .anki-wrapped, and ..anki-wrapped-wrapped
<brendyyn>do we have this madness in guix too?
<roptat>hi guix!
<kori>hi roptat !
<rekado_>brendyyn: the wrappers for scripts can be replaced with inline-wrapping on core-updates.
<rekado_>using “wrap-script”
<rekado_>kori: I don’t think we would reject a Firefox package. Of course it should be FSDG compliant, but that shouldn’t be as difficult as making ungoogled-chromium compliant.
<efraim>TIL ordering matters in trivial-build-system for begin and use-modules and let :/
<efraim>morale of the story, always always use begin -> use-modules -> let -> code
<manzerbredes>Hi, I was wondering how can I change the gcc-toolchain version used by cmake-build-system when creating my own package ? I tried to use gcc-toolchain-9 (the version that I want) in the package inputs but it is not taken into account during the build (maybe because of the entries order in $PATH)
<roptat>manzerbredes, that's probably because we don't use a gcc-toolchain package
<roptat>(in the gnu build system I mean)
<roptat>we use directly a gcc package, so maybe try to set ("gcc" ,gcc-9)?
<roptat>(part of the default set of packages loaded by the gnu-build-system is in %final-inputs in (gnu packages commencement))
<manzerbredes>roptat: thank, I tried ("gcc", gcc-9) but cmake still not found the right version :/
<kori>I asked a bit ago but I don't think I got an answer
<kori>is there interest in replacing bash with maybe something based on gash (god, what an awful name) + scsh-on-guile?
<rekado_>kori: gash will eventually replace bournish in the rescue REPL, bridging the gash between bournish and a real shell.
<rekado_>manzerbredes: that should work. How can you tell cmake doesn’t “find” it?
<manzerbredes>rekado_: because I got something like: "-- The C compiler identification is GNU 5.5.0" in cmake output
<rekado_>manzerbredes: how does it search for GCC?
<manzerbredes>rekado_: Hmm I don't know exactly but this search seems to be made by cmake I guess
<eiro>hello people
<rekado_>you may be able to override the location. It really shouldn’t be necessary as ("gcc" ,gcc-9) in the native-inputs has worked just fine for other packages, but maybe yours is special.
<rekado_>eiro: hello
<g_bor[m]>hello guix!
<manzerbredes>rekado_: thanks I will try to see what I can do x)
<rekado_>g_bor[m]: hello!
<g_bor[m]>rekado_: I had a look at the memory leak problem, and did not see a more obvious solution.
<g_bor[m]>One thing I noticed while working on this was that glibc-utf8-locales-2.28 is not defined.
<g_bor[m]>Do we need that for something?
<manzerbredes>rekado_: by the way, when I go to the temporary directory of guix for my build, then I source the envrionment variables, "gcc --version" give me the wrong version of gcc
<rekado_>g_bor[m]: what bothers me is that we don’t know why introducing a memory leak seemingly fixes our problem.
<rekado_>that’s just not right.
<rekado_>g_bor[m]: if we have glibc-locales-2.28 that’s enough I think.
<rekado_>manzerbredes: does the environment variables file contain your gcc-9 at all?
<g_bor[m]>rekado_: yes, that bothers me too... I thinks I will have a look at the with a debugger later.
<g_bor[m]>I have seen that most probably there will be some delay because of the bootstrap binaries, so I will have some more time to investigate this.
<g_bor[m]>Also it seems that we should update our java packages from icedtea-8 onwards, as there was a security announcement just today.
<g_bor[m]>We also don't have glibc-locales-2.28.
<rekado_>g_bor[m]: it should be added then, and glibc-utf8-locales-2.28 as well. Having these packages simplifies upgrades.
<g_bor[m]>ok, I will look after that.
<rekado_>(I also need them here at the institute as I install locales centrally for everyone so as to avoid problems)
<manzerbredes>rekado_: yes it does, but it comes after gcc-5.5.0
<tune>would be cool to have a webpage that lists packages that take a long time to build (qtwebkit, icecat, rust, etc.) and if their latest version has already been built
<tune>I was innocently running updates when my mouse started to lag and I saw icecat was building. I was not in the mood for that so I just canceled the whole thing
<tune>I know about guix weather and --dry-run but I think my idea is still a bit different
<bojan_petrovic>hi all! I'm using guix on Debian, and the manual suggests to set GUIX_PROFILE to "$HOME/.guix-profile", but `guix pull` suggests to set it to "$HOME/.config/guix/current". Is there a preferred value for this variable? Maybe the second suggestion is for root user?
***rEnr3n is now known as Guest70690
<rekado_>tune: does that
<rekado_>bojan_petrovic: these are for different things
<rekado_>“guix pull” installs Guix itself into its own profile at ~/.config/guix/current.
<rekado_>GUIX_PROFILE should not be set for the “guix pull” profile. Is this really what “guix pull” recommends?
<rekado_>it should only recommend to add ~/.config/gux/current/bin to the PATH.
<bojan_petrovic>I'll try to reproduce it, I think i got it after a pull to cd9f56ff5a0c187eb9d931713cb6774564163788, but now I cannot see probably because it is already at the latest version... I'll let you know.
***amiloradovsky1 is now known as amiloradovsky
<bojan_petrovic>rekado_: here it is:
<bojan_petrovic>GUIX_PROFILE is set to "/home/bojan/.guix-profile" in that shell, and PATH starts with "home/bojan/.config/guix/current/bin/:/home/bojan/.guix-profile/bin"
***MinceR_ is now known as MinceR
<rekado_>I can’t access the paste, but the values for these two variables look fine to me.
<rekado_>.config/guix/current/bin should be first (it is), and then comes whatever is set by the current GUIX_PROFILE
<bojan_petrovic>Here's the new paste: . I think I understand the point, i guess the GUIX_PROFILE variable is only used when sourcing the corresponding scripts, and does not need to be exported.
<Dynamicmetaflow>Good morning Guix! I was wondering if someone could help me out, I've been working packaging gnome-boxes, I've made progress since yesterday although there are a few more things to figure out. From what I can understand when I'm building gnome-boxes it's unable to find the spice-client-gtk-3.0 library, I believe what I need to do is use a configure flag to set the path of where the spice-client-gtk-3.0 library is, which is the
<Dynamicmetaflow>although I'm not sure how to do this exactly. Below is the output of meson.log
<Dynamicmetaflow>Here are relevant entries from -
<Dynamicmetaflow>and here is the gnome-boxes package I am working on
<rekado_>bojan_petrovic: yes, the presence of the variable only affects whether the profile link will be used or the exact /gnu/store location of the profile.
<Dynamicmetaflow>rekado_: Hello, was wondering do you have any hints related to this problem I am facing with gnome-boxes and finding the spice-client-gtk library?
<Fzer000>ryanprior: did you figure out how to create a clojure environment?
<aaster>Hi there,
<rekado_>Dynamicmetaflow: let me see
<aaster>PasteBin doenn't seem to work...
<Dynamicmetaflow>Thanks rekado_
<rekado_>Dynamicmetaflow: unrelated, but I’ll say it anyway: why are all these inputs propagated in gnome-boxes? That’s probably not right.
<roptat>aaster, try
<rekado_>Dynamicmetaflow: the error here is “Package `spice-client-gtk-3.0' not found in specified Vala API directories or GObject-Introspection GIR directories”
<rekado_>Dynamicmetaflow: this is about Vala stuff.
<Dynamicmetaflow>rekado_: I've been doing a lot of trial and error, once I figure it out I'm going to place the inputs where they correspond.
<rekado_>Dynamicmetaflow: they don’t need to be propagated. This will have no effect on building gnome-boxes, only on packages that depend on gnome-boxes.
<rekado_>Dynamicmetaflow: I’m guessing that spice-gtk provides the spice-client-gtk. But it looks like it doesn’t build any Vala bindings.
<rekado_>Dynamicmetaflow: so the next step would be to confirm that and figure out how to enable the Vala stuff in spice-gtk.
<Dynamicmetaflow>rekado_: Thank you for the advice I will adjust accordingly, it's my first time working on a package so learning a lot as I go doing this.
<rekado_>Dynamicmetaflow: you’re doing great
<Dynamicmetaflow>rekado_: Thank you! Also sidenote: did you do a talk about the little "|"
<rekado_>Dynamicmetaflow: yes, I did. That was the FOSDEM talk about the Guix Workflow Language.
<Dynamicmetaflow>rekado_: I LOVED that talk, thank you! It was entertaining and learned a lot.
<rekado_>thank you! I’m glad you found it entertaining :)
<Dynamicmetaflow>No offense to anyone's contributions but sometimes technical talks can be a little hard to sit on, yours was like a wonderful bedtime story of adventure all that was missing was dragons and swords
<Dynamicmetaflow>rekado_: Thank you for the advice regarding vala I will take a look around
<Marlin1113>hi guix
<Marlin1113>nckx: about whiskermenu on xfce
<Marlin1113>i installed it, there is the xfce4-popup-whiskermenu command on the terminal, but there is no option to add it to a panel
<Marlin1113>so that's weird
<Marlin1113>maybe xfce4-panel can't see xfce4-whiskermenu?
*rekado_ makes a note to include dragons and swords next time
<Dynamicmetaflow>rekado_: when you say figure out how to do vala bindings for spice-gtk do you mean i should figure this out by modifying gnome-boxes or spice-gtk.scm
<Dynamicmetaflow>*spice-gtk from spice.scm
<Fzer000>Hello, Anyone using Clojure here? Do it come with tools.deps.alpha?
<str1ngs>Dynamicmetaflow: spice-gtk probably. more then likely you just need to add vala as a native input
<minall>Hello guix!
<str1ngs>and possibly a configure flag if it uses autotools
<Dynamicmetaflow>str1ngs: I believe I already have vala as a native-input, trying to figure out configure-flags, how do i determine if it uses autotools?
<str1ngs>Dynamicmetaflow: if it uses autotools it will have a ./configure file in the source tarball
<str1ngs>which you can see it's configure flags with ./configure -help
<str1ngs>err --help
<minall>How can I test the 'speed' of my pc on guix? I want to be completely sure that there's an improvement when I load linux kernel instead of linux-libre kernel, just for comparison
<minall>Is there a tool like that?
<amz3>ArneBab: did you see the convo on racket ml about changing syntax?
<amz3>s/changing/creating a new/
<amz3>oops wrong chan
<minall>I installed 'lxde' on guix, and now on my slim login I have: 'OpenBox, KDE/Openbox, LXDE and GNOME/Openbox'... Why?, I only tried to install Lxde
<mbakke>rekado: is not responding:
<janneke>one of my "favourites": In procedure scm_lreadr: /gnu/store/.... Unknown # object: #\<
<rekado_>mbakke: it does that sometimes
<rekado_>mbakke: the problem is with fibers stalling for some unknown reason.
<rekado_>mbakke: I’d like to separate the web server from the rest of Cuirass to avoid this problem.
<rekado_>(because I can’t figure out why it happens)
<rekado_>janneke: homoiconicity, eh?
<mbakke>rekado: cuirass.log just printed an error: In procedure accept: Too many open files
<rekado_>some file descriptor leak?
<minall>What package do I have to install in order to use glxgears?
<rekado_>minall: I think it might be mesa-utils or similar
<rekado_>minall: note that glxgears is not a benchmark
<rekado_>using it as a benchmark is misguided.
<mbakke>rekado: possibly... Or maybe 2048+ concurrent client connections (they take up two fds each).
<minall>brendyyn: rekado_: thanks!, that is the package indeed
<minall>Then How can I test and compare the performance of my pc with linux libre and with linux
<minall>Is wayland available for guix? how can I test it, and is it better than Xorg?
<rekado_>mbakke: unless we keep these connections alive I don’t think we have anything close to 2048 concurrent client connections.
<rekado_>minall: “better” is hard to say. It avoids certain problems that the Xorg design imposes (like the round-about way a compositor works with the X server).
<rekado_>minall: it generally gives you faster and flicker-free graphics.
<rekado_>minall: you lose X-forwarding over SSH, but this may not be a problem for you.
<janneke>rekado_: something like that...also: constant error messages, the info you're looking for is ....just out of reach
<Dynamicmetaflow>quick question, i'm trying a document and it's asking for the pdflatex package
<Dynamicmetaflow>Is that available in guix? under a different name?
<rekado_>Dynamicmetaflow: there’s ongoing work to make latex work better (see wip-texlive branch).
<rekado_>Dynamicmetaflow: you may need to add the huge “texlive” package for now, or waste time trying to figure out which “texlive-union” works for you.
<rekado_>pdflatex is provided by texlive-bin, but it may not actually work out of the box
<rekado_>(it may need configuration files that are provided by other packages. It’s a mess.)
*rekado_ goes back to finishing the wip-texlive branch
<Dynamicmetaflow>rekado_: Thanks for the info! I think i'll try texlive and see how that goes
<rekado_>just know that texlive is huge: ~3GB
<jonsger>rekado_: I find latex in generell awful, but I didn't find an adequat replacement :(
<Dynamicmetaflow>I remember tex packages as being large and complex process
<rekado_>jonsger: same here :(
<Dynamicmetaflow>Yeah I'm seeing that, downloading now
<Dynamicmetaflow>Well I try to stick to org-mode and export to pdf..
<Dynamicmetaflow>so yeah
<Dynamicmetaflow>still need tex packages
<rekado_>there’s lout, but it doesn’t have Unicode support :(
<minall>Is there a way on guix of using Wayland instead of Xorg?
<rekado_>minall: probably. I know that Mark Weaver uses it.
<rekado_>minall: I’d be happy if we had a system configuration template for a Wayland system.
<minall>So what's the best way to check the system performance, I'm comparing linux-nonfree and linux-libre
<rekado_>AFAIK it does not work when GDM is used.
<minall>rekado_: So we don't ...
<minall>So there's no way of testing wayland on guix?
<rekado_>minall: we don’t have a template, but you can of course build a system like that.
<minall>Ohh I see
<roptat>you can probably use sway
<rekado_>minall: the only difference between linux-libre and vanilla linux is firmware blobs. If you don’t use any drivers that use firmware blobs you aren’t going to see any difference.
<roptat>you should be able to start it from a tty I tihnk, but I didn't test it
<minall>So wayland is available, but we just dont have a template
<minall>roptat: I'll check it
<minall>rekado_: That's what I want to test, if there's an improvement on the performance on linux, then I'll have to see what linux loads and try to implement it on linux-libre
<rekado_>janneke: on some days I just can’t deal with software problems. Error messages are cryptic, introducing memory leaks fixes problems, applications run out of file descriptors… Sometimes software makes it clear that it just doesn’t want to be used.
<rekado_>minall: it is known what linux-libre removes. Implementing these things often isn’t a matter of skill but of access.
<Dynamicmetaflow>Out of curiousty what's the process for adding a build system like?
<Dynamicmetaflow>for example a php-build-system?
<Dynamicmetaflow>I'm interested in packaging next-cloud
<rekado_>Dynamicmetaflow: the first step is: document how software of that type should be built, i.e. what needs to be executed in what order.
<rekado_>translating that to a build system is the easy part as you can copy from the many existing build systems.
<Dynamicmetaflow>hmm, ok thanks rekado_
<minall>rekado_: What do you mean by access?, what I want to do is, use my pc with the peak of performance, but I think the performance drops with linux-libre, BUT, I don't want to use linux, I want to use the pc with good performance but with linux libre
<minall>So I need to compare, is there is an improvement with linux, then I have to do something
<Dynamicmetaflow>I think once I hopefully package gnome-boxes, I'll try and package a few more packages to get experience and try to tackle packaging nextcloud and documenting how to create a php build system
<rekado_>Dynamicmetaflow: I encourage you to look at one of the simpler build systems.
<rekado_>Dynamicmetaflow: for example guix/build/r-build-system.scm
<Dynamicmetaflow>I intend to :)
<minall>If not, then there's nothing to do, and better. since I can use my pc without proieraty
<rekado_>you see near the bottom that it defines %standard-phases in terms of the gnu-build-system’s standard phases.
<jonsger>minall: then you only can use intel graphics. I wouldn't say they are fast but for normal deskotp needs they are fast enough
<rekado_>then look at the procedures it provides as replacements, e.g. “install”
<rekado_>in the end it’s just setting variables and invoking commands.
<rekado_>figuring out what you *want* it to behave is the hard part.
<rekado_>minall: by access I mean access to hardware manufacturers’ documentation.
<Dynamicmetaflow>thanks for the explanation rekado_
<minall>Maybe I'll have to switch to intel only lol
<minall>But, now
<minall>How can I compare the performance of the 2 kernels? just to be sure if the performance improves?
<minall>if linux doesn't improve the performance, then perfect, I'm using my pc with all it has
<rekado_>minall: if all you have is a stream of bits that are uploaded to an opaque chip and that somehow makes it work then you’ll have a hard time understanding how to generate such a stream from source.
<minall>But if it does improve the performance, then
<rekado_>minall: what performance do you mean? Disk I/O? Graphics? Networking?
<minall>rekado_: that's right lol
<minall>Mhh, perhaps disk and graphics?
<rekado_>minall: for graphics there’s this benchmark:
<janneke>rekado_: yeah i know the experience, weird
<janneke>i removed the last entry in a cons*, while i was looking for a whole other error #<unspecified> or #<proc/#<record/ ...
<minall>rekado_: Thanks!, I'll check it out, I hope I don't have to use propietary drivers
<rekado_>minall: you could also just boot up a linux-libre distro and see if you can use it.
<quiliro>saluton samideanoj
<jonsger>minall: what pc/laptop do you have
<Dynamicmetaflow>the spice gods heard my prayers
<Dynamicmetaflow>gnome-boxes was able to find spice-client-gtk
<Dynamicmetaflow>thanks rekado_ and str1ngs
<Dynamicmetaflow>Now I'm getting another fun error about not finding dependency govirt
<rekado_>Dynamicmetaflow: is it this ?
<Dynamicmetaflow>would it be a similar situation as before?
<lispmacs>hi all, is the some substitute available yet for ungoogled chromium (32 bit)
<lispmacs>I'm trying to get a full-featured web browser on a 32 bit netbook but haven't had success yet
<lispmacs>gave up on ungoogled chromium after a 5 day build
<bavier>lispmacs: last I heard ungoogled-chromium was having build issues for i686 on the build farms
<lispmacs>erk, that is what they said for Firefox. Guess I better give up on 32 bit. I tried Ephiphany but ran into some really fundamental problems trying to run JavaScript
<lispmacs>not that I really want to run JavaScript, but it is needed for accessing some of my routers
<rekado_>I’m able to run Javascript in Epiphany just fine.
<quiliro>minall: saluton. kiel vi fartas?
<raingloom>are functions like with-directory-excursion documented anywhere?
<rekado_>but still, ungoogled-chromium should eventually be built for i686. Don’t know why this hasn’t happened yet.
<rekado_>(maybe check for more info)
<raingloom>(i'm looking for a way to run a custom patch-shebangs pass)
<rekado_>raingloom: probably not.
<rekado_>raingloom: it runs its body in the directory specified by the first argument.
<rekado_>all of these procedures and macros have docstrings; they are not documented explicitly in the manual.
<mbakke>lispmacs: I triggered a build of ungoogled-chromium for i686 on the CI, it should be available in a few hours.
<raingloom>rekado_, thanks, i haven't gotten used to the repl yet, so i'm still looking at sources and the online docs
<lispmacs>mbakke: ok, thx
<mbakke>lispmacs: Note that the build is for current 'master' (there were some changes to ungoogled-chromium today).
<lispmacs>ok, did you have a specific commit in mind?
<mbakke>lispmacs: 26986544469ef290885f5f8d71006751e9e8daf8 is the one currently being built on the CI.
<raingloom>is there a way to keep the build dir even if guix thinks it did not fail the build? (i'm getting some permission errors while trying to build plan9port)
<minall>quiliro: Kiel vi fartas!
<quiliro>minall: bone. Ĉu kaj vi?
<minall>quiliro: nice!
<quiliro>minall: beneta
<lispmacs>what package has the "recsel" command, which is mentioned in the manual?
<lispmacs>guix search recsel is not bringing anything up, and it doesn't seem to be installed already
<lispmacs>oh, recutils
<quiliro>lispmacs: guix install recutils
<quiliro>but i think you have already tested it
<shirajho>Hello all!
<raingloom>is there a way to specify in the package arguments that I want #:modules to be _in addition to_ the default modules?
<kori>can I make a package that builds software from a local dir?
<kori>i.e. can I make a "guix makefile" that would install things to guix?
<kori>if not, that would be cool
<nlyy>how can i run fsck from 'bournish' shell?
<nlyy>fsck /dev/mapper/dev-name, i guess
<mbakke>lispmacs: Substitutes should be available now.
<lispmacs>mbakke: thx, I'll try that
<lispmacs>mbakke: did the problem with icecat on 32 bit get worked out yet?
<mbakke>lispmacs: Here is the upstream issue wrt 32-bit rust:
<lispmacs>ok, thx, I'll try to watch that
<lispmacs>mbakke: 32 bit ungoogled-chromium installed quickly and appears to be running fine
<mbakke>lispmacs: good to know :)
<rvgn>Hello Guix!
<kori>hi rvgn !
<kori>can (package (source (origin (method ...)))) only fetch remotely?
<kori>please respond ;_;
<raingloom>uggh. so I've been trying to debug this all day. plan9port seems to build but I see a permission error and I have No Idea Why >_<
<raingloom>could someone help me debug this mess?
<kori>raingloom: huuh
<kori>link to error?
<kori>not an expert but this interests me
<raingloom>a sec, I'm gonna push the definition to gitlab in a minute
<raingloom>>>> cd /tmp/guix-build-plan9port-0.1-0.e995a0c.drv-0/source/src/cmd/page; mk all
<raingloom>cat | sed 's/.*/"&\\n"/g' >pdfprolog.c
<raingloom>sh: line 1: pdfprolog.c: Permission denied
<raingloom>that's the error. it continues after that like normal. the package definition is based on Nix.
<kori>raingloom: lemme try
<lispmacs>I put xfce-desktp-service-type into my config.scm, which got me XFCE, perfect for my little low-resources netbook; however, the login manager that is launching is GDM, which is very slow and it takes me like two minutes to get logged in. Can I make some tweak to that service s-exp to get a more lightweight login manager? (Unless maybe GDM has some kind of "fallback mode" I could active which is more lightweight.)
<kori>raingloom: weird!
<kori>it compiled.... but it only installed 9
<kori>oh no
<kori>it compiled fine
<raingloom>kori, yeah the other things went to $out/plan9/
<kori>oh, yeah
<kori>kori@eientei ~$ /gnu/store/dkd25sknx9l4kkx0q80ys37wk4jbaixg-plan9port-0.1-0.e995a0c/plan9/acid/acme
<kori>bash: /gnu/store/dkd25sknx9l4kkx0q80ys37wk4jbaixg-plan9port-0.1-0.e995a0c/plan9/acid/acme: Permission denied
<kori>maybe it's missing +x?
<kori>-r--r--r-- 3 root root 2279 Dec 31 1969 /gnu/store/dkd25sknx9l4kkx0q80ys37wk4jbaixg-plan9port-0.1-0.e995a0c/plan9/acid/acme
<kori>it is... I could have just ls -l'd it
<kori>but yeah, no +x
<raingloom>weird. is my mkdir wrong? why doesn't it get the right permissions?
<kori>not sure
<kori>maybe it's the cp?
<kori>maybe cp --preserve=all
<kori>im gonna try that
<kori>nope that didnt work
<kori>well, clearly something in the permissions is getting [expletive deleted]d
<kori>at least you're further along :P
<raingloom>kori, do you know how I could keep the build dir even if it succeeded in Guix's eyes?
<kori>im still trying to figure out how to make the package origin be a local dir rather than a remote dir
<raingloom>--with-source=packagename=/absolute/path ?
<kori>raingloom: i meant defining it in the (package)
<kori>how did you even discover hg-fetch was a thing
<kori>its not listed in the info page
<raingloom>kori, oh. I suspected it was a thing, since hg is pretty popular. I checked in the package definition sources and that confirmed it and also had examples showing the field names.
<raingloom>hmm. if keeping the build dir around is not possible, is there a way to break into a debugger repl?
<kori>raingloom: I don't know and i'd also like to know
<mbakke>kori: you can use (source "/the/directory")
<mbakke>if it's just for quick testing
<mbakke>otherwise you need to use (local-file ...)
<mbakke>raingloom: I think `guix build --check --no-grafts --keep-failed` will do what you want
<kori>mbakke: epic, thanks
<kori>im getting compilation errors then
<rvgn>mbakke Just following up. What's the status on core-updates-->master merging?
<kori>send help ;_;
<mbakke>rvgn: there are still some problems that require mass rebuilds, so it will take a while
<mbakke>I'll send an email when it is ready for general testing
<rvgn>mbakke Ah I see.
<rvgn>That would be great. ThanksS
*rvgn is desparate to use gnome 3.3x.y
<jje>hopefully the new gnome will fix the gsd-xsettings bug, bug #36481. it ruins the gnome experience. feel free to comment on that bug i filed it a couple of weeks ago but nobody said anything.
<raingloom>soo, anyone else knows what can cause permission errors?
<mbakke>jje: can you reproduce it in a VM?
<mbakke>kori: what is supposed to provide those missing symbols?
<mbakke>raingloom: what kind of permission error?
<rvgn>jje I will take a look :)
<kori>mbakke: google says libc
<kori>do you mean xmakeglyphfontspecs
<raingloom>mbakke, the INSTALL script for plan9port tries to generate a file during the build phase and sh prints an error
<raingloom>(it looks like the chain goes INSTALL->mk->sh)
<mbakke>kori: can you paste the package definition?
<mbakke>raingloom: I suppose the directory is not writable? git/hg/svn checkouts have that problem
<raingloom>mbakke, huh. but then how does everything else gets built? like... all those .o files are new.
<kori>mbakke: sure, moment
<raingloom>oh, nvm, i think i get it.
<kori>mbakke: imagine this "st-eientei" dir is the same as st-0.6 from
<kori>the suckless package compiled fine
<kori>so i think its just a missing package declaration
<kori>whoop,s I meant st-0.8
<raingloom>hmm. wait no i don't got it. manually checking it out and running find -not -writeable only returns two .git special files.
<kori>oh nevermind mbakke
<mbakke>raingloom: oh. I guess something is missing the executable bit in that case.
<kori>it was just dirty build files
<mbakke>kori: heh, np :)
<mbakke>glad you figured it out