<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.
<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?
<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?
<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 ??
<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>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>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…
<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. 👍
<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>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 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.
<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 firstname.lastname@example.org?
<nckx>The /*DEBLOBBED*/ thing is probably not what caused this.
<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
<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.
<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
<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.
<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'"
<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>rvgn: I've edited some things by hand since, but here is more or less the relevant pieces: http://dpaste.com/3EYY26K (I changed the keyboard stuff within that, but I think that's irrelevant here)
<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.
<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
<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?
<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.
<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: http://ix.io/1P9G . 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>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
<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.
<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
<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?
<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.)