IRC channel logs


back to list of logs

<brettgilio>leoprikler: got em
<mehlon>oppa guix style
<leoprikler>'(op op op op)
<drakonis1>hmm, i'm having issues with installing it seems
<drakonis1>getting readdir errors on the copying phase
<drakonis1>i know why
<leoprikler>forgot some mount?
<drakonis1>the store already exists
<drakonis1>or not
<drakonis1>i have both mounts i need
<leoprikler>and cow-store as well, I assume
<drakonis1>okay that's what's missing
<drakonis1>i think i didnt start it
<drakonis1>nevermind, still failing
<leoprikler>full traceback?
<leoprikler>(using or whichever paste service you can find)
<drakonis1>the traceback i can get at this point is just "readdir error: input/output error"
<leoprikler>just for reference, how old is your hard disk?
<drakonis1>half a decade
<drakonis1>havent had this kind of shit happen on nix though
<drakonis1>its not dying just yet
<NieDzejkob>woah, "half a decade" is a great way to make 5 years sound like more than it is
<drakonis1>if that's what you're implying
<drakonis1>it is, yes.
<drakonis1>actually its 6 years now?
<mehlon>that's a quarter of a quarter of a century!
<drakonis1>i figure it might be a good time to get a ssd
<mehlon>reminds me I should get one too somehow
<drakonis1>leoprikler: its at the final step of the process mind you
<leoprikler>according to nckx, guix really is an ssd killer tho
<drakonis1>ah yes
<mehlon>yeah that sounds like guix
<drakonis1>lots and lots of hard links
<drakonis1>sounds like fun
<leoprikler>drakonis1: can you at least estimate the path for which this IO error is raised?
<kirisime>My SSD is 6 years old.
<NieDzejkob>Maybe the error is on the installation media?
<mehlon>my pc is six years old :3
<kirisime>I'm old.
<mehlon>aren't we all?
<drakonis1>what are the odds
<drakonis1>but let's see
<drakonis1>i was running nix before guix so its not like i wouldnt have found out issues with it before this
<NieDzejkob>I mean, considering you're getting an "input/output error"...
<drakonis1>at the install phase
<leoprikler>at install pretty much everything of the disk is already read
<drakonis1>lol the issue is that it cant find the files it wants
<leoprikler>which file specifically?
<drakonis1>just a sec while it finishes running
<drakonis1>if i run it without strace it fails lol
<drakonis1>its downloading files with strace attached
<drakonis1>maybe i should purge my root filesystem before engaging on this
<drakonis>i'm almost certain why it failed
<drakonis>let's try again
<leoprikler>still erroring?
<raghav-gururajan>sneek: later tell brettgilio: gnome-boxes needs 'runpath validation' to be fixed. I will be sending email on help-guix for help. :-)
<sneek>Got it.
<drakonis>it does copy things to storage
<mehlon>sneek: later tell mehlon: welcome to the guix
<sneek>Got it.
<raghav-gururajan>mehlon I like you
<drakonis>it breaks when copying a module
<mehlon>sneek: later tell raghav-gururajan: :3
<sneek>mehlon, you have 1 message.
<sneek>mehlon, mehlon says: welcome to the guix
<sneek>Will do.
<drakonis>libre linux backlight
<raghav-gururajan>sneek botsnack
<sneek>raghav-gururajan, you have 1 message.
<sneek>raghav-gururajan, mehlon says: :3
<raghav-gururajan>You were supposed to reply ":)" before those messages. xD
<raghav-gururajan>Or no.
<brettgilio>raghav-gururajan: got it
<sneek>brettgilio, you have 1 message.
<sneek>brettgilio, raghav-gururajan says: gnome-boxes needs 'runpath validation' to be fixed. I will be sending email on help-guix for help. :-)
<leoprikler>drakonis: now you at least know which path is borked, now try looking at the destination
<leoprikler>specifically, try finding the minimal `ls` that triggers an IO error
<drakonis>fails at the same file
<drakonis>its stored not on the disk itself
<drakonis>hmm how should i do the install using the data already in the media?
<drakonis>do i cut off internet for that?
<leoprikler>at which file does it fail?
<leoprikler>(full path)
<oriansj>leoprikler: really drop emacs and use ed? on a guix system GTFO (ノಠ ∩ಠ)ノ彡( \o°o)\
<leoprikler>You asked for a smaller system, not a practical one 😉️
<mehlon>sneek: tell everyone: ed is the standard text editor!
<sneek>everyone:, mehlon says: ed is the standard text editor!
<oriansj>leoprikler: one can not have a guix system without emacs or atleast mg
<oriansj>mehlon: ლ(`ー´ლ)
<drakonis>leoprikler: a linux libre backlight module
<leoprikler>drakonis: can you get more specific? (/gnu/store/<hash>-<package>/...)?
<drakonis>i rebooted and now i gotta stracr it again
<drakonis>a sec
<drakonis1>a better question, how do i do the install with upgraded packages?
<drakonis1>always dies here
<drakonis1>which is strange
<drakonis1>i'm fairly certain this is a problem here and not with my disk
<leoprikler>you can `guix pull` after creating the cow-store
<drakonis1>it was happening even while my disk had more data in it
<leoprikler>what happens if you `ls /gnu/store/mmnl20fg05w8gzzsp4d8dvagmdn1vjil-linux-libre-5.1.2/lib/modules/5.1.2-gnu/kernel/drivers/video/backlight/lv5207lp.ko`?
<drakonis1>no errors
<drakonis1>it just prints out the file again
<leoprikler>`ls /mnt/gnu/store/mmnl20fg05w8gzzsp4d8dvagmdn1vjil-linux-libre-5.1.2/lib/modules/5.1.2-gnu/kernel/drivers/video/backlight/lv5207lp.ko`?
<drakonis1>its the iso lol
<drakonis1>its corrupted
<drakonis1>there's a dmesg error regarding the iso itself
<leoprikler>if you ls the file?
<drakonis1>well i'm glad my hard drive is fine
<drakonis1>i'll have to flash the iso again
<drakonis1>guix pull with the store mounted means it'll write to disk if i do guix pull then
<leoprikler>tbh i don't understand the magic there either
<drakonis1>its writing to disk right now
<drakonis1>i think it redirects the writes to a different store
<drakonis1>no magic here
<leoprikler>oh, I'm sure it has a very scientific explanation behind it, I just haven't cared strongly enough to comprehend it is all
<drakonis1>hilarious it doesnt exist if i stat it
<leoprikler>Well, it's almost 2am and I promised myself that I'd slowly fix my sleep rhythm.
<drakonis1>guix system init still uses existing data for the install
<leoprikler>So this is as far as I will go.
<pkill9>my sleep rhythm has gotten terrible
<leoprikler>hopefully someone else can help, but our irc is usally dead at these times
<pkill9>went to sleep at 6am last night
<drakonis1>same here
<leoprikler>I know that feel all too well myself
<drakonis1>really though
<drakonis1>my usb is dying
<drakonis1>i think i might have to bootstrap it using another distro
<drakonis1>anyways, back soon
<drakonis1>is there a way to fetch an install iso with fresher packages?
<drakonis1>or is it only available for releases?
<pie_[bnc]>they are easy to generate yourself if that helps
<drakonis1>hmm, its worth a try
<drakonis1>i'll generate one and move it to a partition i can access to write it to the flash drive
<oriansj>lxsameer: this is as small as one can possibly make guix (unless you wish to go a bit crazy on one of janneke's wip branches)
<drakonis1>pie_[bnc]: you here huh
<pie_[bnc]>drakonis1: oops, i mixed up the channels
<pie_[bnc]>drakonis1: i though tthis was nixos-chat 'xD
<pie_[bnc]>'dunno about guix
<drakonis1>did you come here because of me?
<drakonis1>i figure the process to generate should be about the same as in nix
<drakonis1>i'll just have my usb checked for errors before doing anything
***KE0VVT_ is now known as KE0VVT
<drakonis>it lives
<brettgilio>Hello Guix!
<drakonis>it works again...
<drakonis>all it took was flashing again
***akko is now known as hardnickFGIASJug
***hardnickFGIASJug is now known as akko
<apteryx>drakonis: Great! Enjoy your new system :-)
<brettgilio>raghav-gururajan: getting the hang of packaging?
<Gooberpatrol66>I ran guix pull, and it's been "building package cache" for an hour now...
<brettgilio>Gooberpatrol66: when was the last time you ran it?
<Gooberpatrol66>quite recently, i've been iteratively editing a package in a channel
<brettgilio>Gooberpatrol66: hmm. Let me run time machine on the latest commit and see if it hangs for me too
<Gooberpatrol66>i ran guix pull as a different user right before and it completed quickly, which is weird
<brettgilio>Gooberpatrol66: should be saved in your cache unless the head changed
<brettgilio>Nope. Last commit is still mine 5 hours ago
<Gooberpatrol66>hmm, i made an edit to my package and it completed instantly
<Gooberpatrol66>wild guess, does it freeze if you have circular dependencies in a package?
<raghav-gururajan>brettgilio Yeah i am learning a lot through packaging :-)
<brettgilio>Gooberpatrol66: correct
<brettgilio>Doesn't know how to terminate
<Gooberpatrol66>how would you resolve that if two packages depend on each other
*raghav-gururajan still need to get a hang of git though
<brettgilio>Gooberpatrol66: it's kind of a case-by-case thing. What are you working on?
<Gooberpatrol66>plugins for deadbeef
<Gooberpatrol66>two of them depend on each other
<raghav-gururajan>Gooberpatrol66 circular dependency?
<brettgilio>raghav-gururajan: means where two packages depend on each other to build
<brettgilio>Chicken and egg problem
<raghav-gururajan>yeah, they need to be merged into single package.
<brettgilio>raghav-gururajan: that isn't always possible
<raghav-gururajan>Oh wait
<raghav-gururajan>there is this gnu package.
<raghav-gururajan>GNU Stow?
<str1ngs>make you can create a union
<efraim>if you want to create a union of two packages like a metapackage then the xfce package is an example of that
<efraim>if you're looking to do that as an input then something like sdl-union might be a good thing to check out
<brettgilio>roptat: hey Julien. I am making progress on the Coq situation
<raghav-gururajan>I see lot of "#:glib-or-gtk? #t" in gnome package definitions. Whats does it mean and do?
<brettgilio>raghav-gururajan: check ./guix/build-system/glib-or-gtk.scm
<efraim>it adds soms of the glib-or-gtk-build-system magic to the meson-build-system
<brettgilio>It comes with a nice commentary in that file.
<raghav-gururajan>brettgilio efraim Thanks
<brettgilio>No problem :)
<brettgilio>Not that anybody asked, but I've always felt like the search-path method should be called apply-patch.
<brettgilio>Search-patches should be called apply-patches*
<brettgilio>Damned autocorrect.
<brettgilio>Just for fun, let's change it and then change every package that uses it. (◠‿◕)
<raghav-gururajan>I wish I had time ;-)
<brettgilio>I don't think efraim civodul or nckx would be too happy..
<raghav-gururajan>brettgilio I think I found out a way to fix runpath validation for gnome-boxes. I should be able to patch it by today.
<efraim>I always had a hard time creating a patch path with channels
<efraim>"good" news, there's now CVEs for 2020 so the cve linter is no longer broken
*brettgilio yay security flaws being available to fix our linter!
<efraim>I started very preliminary work on guix syntax support for vim, it was strange having the highlighting different
<efraim>I figure it'll also be a good chance to incorporate some of the linter checks into vim
<efraim>Use a tab? tag it as an error
<efraim>one space between sentences in the description? tag it as an error
<efraim>("foo", foo) in the inputs? same
<raghav-gururajan>Btw, why two spaces b/w sentences in description??
<efraim>at the very least because of consistency, but I assume we either inherited it from Nix or has to do with GNU coding guidelines
<raghav-gururajan>I see.
<g_bor>hello guix!
<raghav-gururajan>g_bor o/
<civodul>Hello Guix!
<raghav-gururajan>civodul o/
<g_bor>hello guix!
<g_bor>Do you know something about /var/log/guix/drvs/ix/g604gkxsnsk7h4lr4dw2vj9id4rsbn-guix-1.0.1-11.f38eabe?
<g_bor>I mean why this is being built?
<g_bor>I thought that there should be a substitute already...
<raghav-gururajan>It appears not built yet
<g_bor>on the first run it failed phase check for me...
<raghav-gururajan>It failed on build farm.
<raghav-gururajan>But it built fine on my system
<g_bor>same happened here.
<g_bor>This seems like serious trouble.
<raghav-gururajan>g_bor re-try fauled builds with "--cores=1".
<g_bor>ok, I am trying it as is for now.
<g_bor>Will do that if it fails again.
<raghav-gururajan>*I usually re-try failed builds with "--cores=1".
<g_bor>The main problem is that this blocks reconfigures.
<g_bor>It should be fixed on ci as soon as possible.
<efraim>it failed on one of my machines
<raghav-gururajan>On ci, it appears like network failure.
<raghav-gururajan>" failed to download ...."
<g_bor>raghav-gururajan: I am not sure about that...
<g_bor>what are these Servname not supported lines?
<raghav-gururajan>No idea :/
<civodul>is $http_proxy set?
<g_bor>civodul: I don't know hat happened here. I am running check locally now.
<g_bor>Here a proxy should not be needed
<g_bor>it seems that it passed fien now
<g_bor>maybe it was a transient error.
<g_bor>How could we retry it on berlin? Or is it done automatically?
<civodul>g_bor: oh sorry, i hadn't fully realized what this was about
<civodul>it would seem that the "guix" package upgrade is broken, no?
<g_bor>can I simply try a guix build on berlin?
<civodul>here the tests are trying to download things that they shouldn't need to download
<civodul>so it's not a transient error: those downloads will never work within the chroot
<g_bor>however it seems that it tries to do this only sometimes...
<g_bor>I mean the downloads
<civodul>[100%] deleting '/tmp/guix-tests/store/1l4210liw1bn1pjr4hcpb8ccmj7h59g8-guile-2.0.9.tar.xz'
<g_bor>On my dev machine the error was triggered first, but the same invocation worked the second time
<civodul>so the GC test removed these things
<civodul>so it's non-deterministic
<civodul>lemme see
<g_bor>civodul: Would it be useful to try 'guix build guix' on berlin?
<civodul>g_bor: that's cheating :-)
<civodul>i'm testing a proper fix
<g_bor>civodul: that's nice.
<civodul>hey ho, mjw!
<mjw>civodul, yo
<efraim>the refresh command is out to get me 'guix refresh vim-neocomplete'
<dutchie>least favourite part of submitting a new package: scrolling through gnu/packages/*.scm to find which file to put it in
<g_bor>dutchie: yes, that might be hard sometimes :)
<g_bor>I tried to use gnome with home-manager. I could start it, but the keyboard layout is not respected here.
<g_bor>It is respected in gdm whatsoever...
<g_bor>Any idea what is missing?
<g_bor>Is this normal?
<dutchie> what should I put this as? the home page claims it's "MIT", but this doesn't quite match the Expat text
<dutchie>it's closer to X11 but also misses a bunch
<g_bor>also it forgets the layout on the screen lockaer
<dutchie>ooh, x11-style fits maybe
<g_bor>also, on gnome settings I have an empty list of input sources, and can add none.
<g_bor>So I can't work around it using the gui...
<g_bor>ok, so this is gnome-control-center actually.
<g_bor>I will try to make some sense as what is happening...
<g_bor>ok, it seems that there is a dconf directory needed...
<leoprikler>g_bor: GNOME Desktop uses its own settings rather than inheriting from GDM, which is why you need to edit those yourself
<leoprikler>quite confusing imo
<efraim>Anything need to be added to the gnome-desktop-service?
<g_bor>ok, that was it
<leoprikler>efraim: for g_bor's use-case or in general?
<g_bor>efraim: it needs to have /home/.config/gnome-session ans /home/.config/dconf writeable.
<g_bor>This has to be explicitly configured when using home-manager.
<g_bor>This fixed all the layout issues.
<efraim>Was afk for a bit. Both, glad you got it
<grillon>hi guix
<nckx>leoprikler: Oh, I should really clarify before this becomes a meme: not Guix itself but running a Guix *CI* box 24/7 on a consumer Samsung SSD killed it after 2 years.
<leoprikler>fair enough, failed to include the CI part
<grillon>nckx: how long is the guaranty?
<grillon>(sorry I'm not part of the conversation :o)
<leoprikler>that said, guix does recompile things more often than other distros I'm aware of (with perhaps the exception of Nix)
<leoprikler>however, with substitutes it actually does less work than say Gentoo
<pkill9>that's not because of guix itself, it's because the project doesnt have enough people to maintain a set of packages guaranteed to have substitutes available
<pkill9>e.g. publish package definitions to bleeding edge, have them built by the build farm, then merge them into the main repository
<civodul>nckx: we could partner with SSD makers to benchmark their hardware :-)
<g_bor>civodul: that might make sense :)
<g_bor>could you find out what the test breakage was about?
<g_bor>roptat: I just added an issue to homme-manager describing a minimal addition to the config to make gnome working
<g_bor>me afk
<civodul>g_bor: yes, it's just that these tarballs could be GC'd by one of the last tests
<civodul>so i've added a GC root
<civodul>will push shortly
<grillon>is there a maven build system?
<pkill9>i believe so
<grillon>pkill9: there is only ant build system in the documentation
<brown121408>Do y'all know if anyone is working on a GUI for guix (outside of Emacs) (like for normal people)?
<jlicht>hey guix
<leoprikler>currently not
<leoprikler>at least not in a way that you could download some alpha code anywhere
<str1ngs>theoretically nomad could host a guix GUI
<str1ngs>though I have not done any work on that yet. I do plan to have nomad packages managed by guix eventually. using graphical controls
<str1ngs>brown121408: ^
<leoprikler>str1ngs: given the overall design of nomad, would that not be another variant of "guix via emacs"?
<leoprikler>but with worse keybindings ;)
<str1ngs>potentially yes, but it would have clickable features so it's not 100% dependent on emacs bindings per say
<brown121408>That sounds cool, str1ngs
<leoprikler>neither is the emacs frontend really
<leoprikler>the only "emacs bindings" magic is in the command to pop up the menu
<str1ngs>I think the users was looking for something more like a what you would find in a graphical installer.
<str1ngs>I could be wrong though.
<leoprikler>something along the lines of gnome-software I would assume
<str1ngs>better yet, we could add package kit support to guix. :P
<leoprikler>there was some discussion about a packagekit frontend years ago, but that has died down
<str1ngs>and gnome-software would work too :P
<pkill9>how do you popup the emacs guix popup?
<civodul>apparently PackageKit is "deprecated"
<civodul>M-x guix
<brown121408>I meant more something like you'd expect your parents to be able to use when I initially asked. How would a potential Guix GUI in nomad fare on this gruesome task, str1ngs?
<leoprikler>civodul: how is packagekit deprecated?
<leoprikler>brown121408: same as asking them to use emacs
<pkill9>it's not popping up :<
<str1ngs>brown121408: it would fare well. unlike emacs nomad GUI controls are first order
<civodul>leoprikler: apparently gnome-software includes its own backends, and they provide more flexibility or something along these lines
<civodul>just a vague recollection from a previous discussion on this topic
<leoprikler>so we would have to write a gnome-software backend for guix?
<str1ngs>with the advent of guile-gi and g-golf. writing a guix GUI frontend is not that hard.
<leoprikler>Probably not, but making it usable is.
<civodul>leoprikler: that's my understanding, yes
<str1ngs>though I'm currently tracking down a gobject-instrospection that effects guile-gi and g-golf
<leoprikler>If we want to go for full control (as in the emacs module), we'd have to turn abritrary guix records into GTK widgets
<str1ngs>gobject-introspection issue*
<leoprikler>which issue is that?
<str1ngs>leoprikler: that can be done in nomad
<str1ngs>records as GUI controls
<str1ngs>though it would be easier to do if guix record types used goops
<leoprikler>I don't think so.
<leoprikler>I very much like the data-driven approach of guix records.
<str1ngs>right that would be achievable using goops as well
<str1ngs>though record->goops would do the trick as well
<str1ngs>define-record-type* is rather nice though
<leoprikler>And yes, parsing that out into a set of widgets and controls is possible, but it would nonetheless be a lot of work.
<leoprikler>What advantages would you have through record->goops?
<str1ngs>the reason I mention goops is because g-golf uses it. so you could use inheritance much easier
<str1ngs>take for example nomad's webview which looks like this. (make <nomad-gtk-webview> (<text-buffer> <webkit-gtk-web-view))
<str1ngs>in the case of guix it might look like this. (make <guix-package-buffer> (<text-buffer> <vbox>))
<leoprikler>don't go that route
<leoprikler>g-golf and guile-gi use goops as a way to deal with the OOP-ness of GLib et al.
<str1ngs>exactly so why would you not use goops ?
<leoprikler>but making Guix records OOP serves no advantage
<str1ngs>plus emacsy uses goops
<leoprikler>for most cases, you just want to display a package in some human-friendly way
<str1ngs>guix does not *have* to use goops in this case. but a record->goops would work well in this case
<leoprikler>i.e. what you want is not record->goops, but record->widget and widget->record
<str1ngs>widgets are goops so the effect is the same.
<pkill9>what's nomad?
<leoprikler>an emacsy browser
<str1ngs>the difference is that you could do inherit the record->goops as part of the widget
<str1ngs>so you get generic method for ree
<leoprikler>you shouldn't care about the fact, that those libraries happen to use GOOPS underneath
<str1ngs>it's really hard to over look that fact
<leoprikler>plus the way guile currently allows arbitrary shenanigans with GOOPS inheritance will mostly be patched out with 3.0, making class hierarchies fixed
<str1ngs>there is only one place I use inheritance shenanigans in nomad anyways :P
<leoprikler>so you would end up with record->goops->widget, with record->goops being nothing but a data copy
<str1ngs>and that more related to emacsy making some assumptions. I'm still figuring out how to improve it
<str1ngs>in the case of widets is much easier to encapsulate widget layout/signals children in initialize and use slots
<leoprikler>back to my original point, you'd want to make something like <package> -> (<GuixPackageWindow> (name <GtkLabel>) (version <GtkLabel>) ...)
<str1ngs>why when you can pass that new control to other controls
<str1ngs>can not*
<str1ngs>not to mention with goops you gain generic methods. so you can use gtk functions/method directly on the class instance
<leoprikler>your point being?
<str1ngs>I thought my point was quite clear. in the case of guile-git and g-golf using goops. it makes much more sense to leverage goops to create widgets for something like package view etc etc
<str1ngs>gi :)
<leoprikler>as far as I'm aware, GOOPS has no magical "make this a widget please" function
<leoprikler>that's the one that you'd have to write anyway
<str1ngs>it's not magic but it has inheritance. ergo you can derived package-view from vbox for example
<leoprikler>sure, but you don't need goops for that
<str1ngs>in the case of package view I would just a container. then just used method/slots to expose only package related data
<str1ngs>why would you not use goops considering the controls take goops class in almost all cases.
<leoprikler>Because I'd argue, that using tools closer to the Gtk end of things will make the end result overall more visually pleasing.
<str1ngs>umm but in this case the GTK tools is goops
<leoprikler>no, it is not
<str1ngs>what what tool is closer to Gtk. I don't understand what you mean here
<leoprikler>Gnome-Introspection helpers for scheme happen to use GOOPS internally, but they are not GOOPS.
<str1ngs>well I'm not inclined to SCM pointers if that's what you are suggesting :P . goops provides some level of safety
<str1ngs>but first I need to fix this gobject-introspection issue
<leoprikler>no, that's not what I meant either
<leoprikler>but at least the display portion should in my opinion be done with some Gtk Builder XML (produced by Glade)
<str1ngs>oh gawd no
<leoprikler>why not?
<str1ngs>that's the reason I'm using goops you don't need xml madness to interfaces. you can just use a goops class and scheeme
<str1ngs>to create*
<civodul>brettgilio, bandali: this looks cool!
***ng0_ is now known as ng0
<bandali>hey civodul, nice find! another one i knew of was the deepspec summer schools
<bandali>also, thanks for the link :)
<spk121>str1ngs: for what it is worth, i've written a few Gtk GUIs without Glade. It is always faster to get started and up and running that way, but, harder to modify later.
<civodul>bandali: oh, looks nice too
*civodul would love to travel to .cl
<civodul>too late for this time tho!
<str1ngs>leoprikler: to replicate my gobject-introspection issue you can do this from within guile-gi git repo. guix environment --ad-hoc guile gobject-introspection gtk+ webkitgtk -- ./tools/uninstalled-env guile ./examples/browser.scm
<bandali>yeah :p
<str1ngs>leoprikler: as far as I have gathered so far removing the gobject-introspection-girepository.patch used in the gobject-introspection package fixs this. but that's not ideal obviously
<str1ngs>spk121: I agree it's great for prototyping. but it does not scale well.
<leoprikler>spk121: what is harder to modify later?
<str1ngs>spk121: and less of an issue when your using goops classes with initialize. not sure how guile-gi handles this. I think guile-gi can register types? which is nice too
<efraim>I've thought about a frontend, even TUI like aptitude, but I've apparently started working on guix integration in vim after having it on my todo list for years
<leoprikler>guile-gi can register types, but only to an extent
<leoprikler>e.g. you can't call guile-registered methods from scheme, which is a shame imo
<leoprikler>from C*
<str1ngs>even in C I found it much easier to create derived C classes then using glade in the long haul. mind you there is some tedious boiler plate with that method.
<leoprikler>fwiw guile-gi has a builder example ;)
<str1ngs>spk121: btw guix environment --ad-hoc guile gobject-introspection gtk+ webkitgtk -- ./tools/uninstalled-env guile ./examples/browser.scm should produce the cannot register existing type 'GtkWidget' issue as reported by the user in #guile
<spk121>leoprikler: well if one wanted to call guile-registered methods from C, I think I know how I would code that
<spk121>it would be would be a mess, though
<leoprikler>of course
<leoprikler>btw. how are your hash tables going?
<str1ngs>in g-golf I just use goops with slots and initialize . though I suspect I'll hit some corner case vs registering a type
<leoprikler>In guile-gi at least signals of registered types should work bi-directional, which is nice
<leoprikler>fields also
<leoprikler>str1ngs: why do you do --ad-hoc guile-gi instead of guile-gi --ad-hoc?
<str1ngs>I'm not using --ad-hoc guile-git I'm using the in tree guile-git
<str1ngs>err guile-gi*
<spk121>leoprikler: i tried always converting guile hash to C hash at the interface boundary, which is okay-ish and probably good enough. But then over December i got distracted working on an unrelated text processing library
<leoprikler>Also, I fixed an awfully similar bug in one of raghav-gururajan's recipe's earlier. The trick was to suffix the GI paths
<str1ngs>what was the error with that bug? also I'm not understanding the suffix GI path fix
<civodul>nckx: i took the liberty to add you to the "state of the union" item at :-)
<civodul>looks like the other maintainers may not be around
<civodul>mbakke: wazup?
<wingo>i will try to stop by the guix event if there is room, though i have a meeting for most of that day :P
<civodul>of which day? :-)
<civodul>it's Thu & Fri, no excuse! ;-)
<leoprikler>str1ngs: I think it is a weird version mismatch in Gtk/Gdk
<apteryx_>nckx: earlyoom works a treat
***apteryx_ is now known as apteryx
<leoprikler>basically, if your environment already has them (e.g. inside of GNOME), something will attempt to load two versions of the library and init both in the same process
<wingo>civodul: fri :) i arrive on thurs evening
<str1ngs>leoprikler: that sounds about right. can you explain your suffix fix for me. maybe I can test if this also fixs the guile-gi and g-golf issue.
<nckx>apteryx: Yay! Thanks for bringing it to my attention, I'd never heard of it.
<apteryx>I'm polishing a service for it, then it'll be up in the patches stack
<leoprikler>str1ngs: by putting GI_TYPELIB_PATH first, you ensure that whatever Gtk version the environment uses (if it has one), is the first to be loaded
<leoprikler>and that seems to avoid further problems, as you already have a full gtk init at that point
<leoprikler>I'm not quite sure what magic happens internally and I haven't debugged it too closely.
<str1ngs>for me GI_TYPE_PATH for this guile-gi environment is /gnu/store/5099hwdzajmsy2s78wy203gzr4bqj0xd-profile/lib/girepository-1.0
<nckx>leoprikler: Indeed, no question that Guix (and Nix) probably write more over the life time of a system than classical distributions.
<leoprikler>so just the environment you're in?
<leoprikler>which has only gtk+ and webkitgtk
<leoprikler>hmm, wait, I'll see what I can get
<nckx>grillon: The device was technically under its 2-year warranty, but it *claimed* (through SMART) that the total rated TB written had in fact been reached, that the SSD had been ‘used up’ so to speak. Am I sceptical of that counter? Would it be a very convenient firmware ‘bug’ for Samsung? Absolutely, but I certainly wouldn't have got a free replacement.
<str1ngs>leoprikler: I think you are right about versions. but not in the context or processes. I think possibly 1) a typelib has not been built properly with the new gobject-introspection-absolute-shlib-path.patch or there are mixed versions
<leoprikler>that may well be
<leoprikler>could gtk be a candidate for that?
<str1ngs>leoprikler: if you comment out gobject-introspection-absolute-shlib-path.patch in glib.scm and call ../guix.git/pre-inst-env guix environment --ad-hoc guile gobject-introspection gtk+ webkitgtk. then call LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib ./tools/uninstalled-env guile examples/browser.scm. this problem goes away. so is something so path related
<str1ngs>leoprikler: that might rebuild alot for you. and that fix is far from ideal
<nckx>civodul: Eee…. me & public speaking? :-/ OK, that's all right, I didn't need to sleep anymore this month. I don't get the pun though. Tor substitutes?
<str1ngs>leoprikler: my fix could be an indicator that one of the hard coded typlib so paths is using a wrong version somewhere.
<str1ngs>leoprikler: which is kinda what you were thinking as well
<nckx>civodul: ‘Our state will make you cry’? I'm going to change it to ‘Union’ 🙂
<leoprikler>can you link me the commit, that introduced this patch?
<leoprikler>btw. same issue from `guix environment --pure -l guix.scm --ad-hoc gtk+ webkitgtk -E DISPLAY -E XAUTHORITY`
<leoprikler>And yes, I have a local copy of guile-gi 😉️
<str1ngs>leoprikler: I have not been able to find the exact commit. I know with 1.56.0 this patch is not applied
<drakonis1>hmm, i'm having some trouble getting the clock to be correct
<leoprikler>so it is an upstream patch?
<str1ngs>leoprikler: I'm stealing this XAUTHORITY hack thanks
<str1ngs>no this patch is originally from nix as far as I can tell. basically when generating typelib this patch uses the full store path for dynamic so files
<leoprikler>you may also want to steal XDG_*, but I was too lazy for that
<str1ngs>as opposed to the base so name
<str1ngs>leoprikler: see grep shared-library $GUIX_ENVIRONMENT/share/gir-1.0/* . so cairo looks suspect
<civodul>nckx: c'm'on! ;-)
<nckx>Nope, still nothing.
<leoprikler>str1ngs: try adding gobject-introspection as native input to cairo, rebuild it and try again
<leoprikler>all those propagated inputs don't look nice to me either
<str1ngs>leoprikler: I'll try that also things improve with guix environment --no-substitutes --no-grafts -l ./guix.scm --ad-hoc gtk+ webkitgtk gobject-introspection but not by much
<nckx>civodul: …l'oiGNUon? I don't get it.
<nckx>civodul: Anyway, lemme know what I need to prepare 🙂
<str1ngs>leoprikler: also setting LD_LIBRAY_PATH fixs this. so to me it could be cairo or something else not setting absolute so paths
<leoprikler>perhaps i can be the person who earns themselves a bunch of commits by just adding gobject-introspection everywhere
<leoprikler>str1ngs: what other libs are missing full paths?
<g_bor>istm that if I long leave one of my guix system vms alone on the gnome desktop it gets into a sleep that I can't revocer from it.
<g_bor>Anyone else noticed that?
<str1ngs>IIRC cairo gir is from gobject-introspection . that needs to be substitute in the gobject-introspection package
<leoprikler>yep, you're right
<str1ngs>leoprikler: see maybe /gnu/store/khhhmbxq7kp1js3fvn4s02afj3g8cvc6-gobject-introspection-1.60.2/share/gir-1.0/cairo-1.0.gir
<drakonis1>where do i get the configuration file used to spin up the install image?
<leoprikler>but gobject-introspection does not depend on cairo at all
<str1ngs>no but I think maybe it makes some assumptions possibly for bootstraping
<str1ngs>and I don't think cairo has GI per say
<g_bor>drakonis1: it's gnu/system/install.scm
<leoprikler>perhaps we could run this as a profile hook
<leoprikler>ah, but then individual packages would be borked
<str1ngs>I know LD_LIBRARY_PATH won't work that method fails for foreign distros
<str1ngs>the patch as far as I can see is okay. just there is something either not built properly or not built with the new gobject-introspection I think
<str1ngs>even more odd is gsj and pygobject are not effected
<str1ngs>leoprikler: I have some gsj and python examples if you need them
<leoprikler>gjs becomes borked in much the same way
<str1ngs>also for less abstraction the C examples work
<str1ngs>though I maybe I should add GTK controls to the mix. I was just doing low level introspection
<leoprikler>your tests cleverly avoid the problematic libs from what i can see :)
<drakonis1>and i'm also having some issue getting the clock to work as i want
<leoprikler>str1ngs: how about a cairo-glib package?
<str1ngs>leoprikler: my tests were meant to introspect library paths. why I mentioned I should add GUI controls
<str1ngs>I don't know if cairo is the issue quite yet. it's the only gir file that does not have a store so file path though
<str1ngs>and it's not related to the cairo package in a ways.
<str1ngs>leoprikler: either way, I appreciate the feedback. it
<str1ngs>it's given me more to consider on this problem
<drakonis1>any advice on getting the system clock to update using a ntp server?
*nckx suddenly remembers they had a dream, last night, about their system clock being wrong. It was a long dream. WTF.
<nckx>drakonis1: Would (service ntp-service-type) fit your needs?
<drakonis1>it probably would but i have to try
<drakonis1>as i need to copy my time to the hardware clock
<drakonis1>something something running other operating systems at the same time
<nckx>If this is a certain well-know non-free operating system that historically preferred local time: there's a register key you can set to cure that.
<drakonis1>it is that very same
<drakonis1>please do.
<drakonis1>i have certain needs that cannot be met by linuxes due to occasionally sharing it with others
<drakonis1>oh i'm aware of that
<drakonis1>i thought there was a option for that
<drakonis1>to automate that
<drakonis1>that one is a thing i didnt know about that
<drakonis1>be back soon
<drakonis1>xorg's bringup is supposed to take a while, right?
<nckx>Er, a few seconds, perhaps.
<nckx>Maybe longer on slow HDDs.
<drakonis1>that's strange
<drakonis1>it doesnt come up unless i log in
<nckx>I don't think I understand what you mean.
<drakonis1>i'm saying that it takes too long to boot up and drop me into gdm
<drakonis1>its taking me minutes
<drakonis1>ah well i'll fix the clock real quick
<str1ngs>given that LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib tools/uninstalled-env guile examples/browser.scm works. I suspect something is not using the full store path
<str1ngs>works slightly better I should say leoprikler ^
<nckx>MinuteS seems awfully long, but Guix is indeed not a fast-booting system.
<str1ngs>lets create a kexec service and maybe we never have to reboot :P
<str1ngs>though im not sure if kexec is enough to replicate livepatch
<nckx>str1ngs: no, livepatch updates the kernel in-place while all your plates keep spinning; kexec is a warmer reboot, it still restarts the running system.
<spk121>Just got my work schedule for January. No Guix days for me :-(
<str1ngs>hmm I thought livepatch used kexec for some reason.
<leoprikler>str1ngs: perhaps try stracing or instrumenting ld?
<nckx>str1ngs: I don't think so, but there are so many per-distro implementations of this (ksplice, livepatch, kgraft, kpatch, …) that it's possible that one of them uses a (small) part of kexec. It doesn't seem like a good fit but who knows.
<civodul>spk121: ah, too bad!
<civodul>nckx: the "onion" thing is not from me, BTW
<civodul>the Tor folks hold a "state of the onion", which makes sense, much less for Guix tho
<nckx>spk121: Pity. Your talk last year was a nice change of pace, although I never tried your game.
<nckx>civodul: Oh OK. Well, I've changed it to Union now. Colour me boring…
*nckx , conversely, will only attend the Guix days this year but none of FOSDEM ☹
***g_bor2 is now known as g_bor
<mbakke>howdy civodul
<mbakke>I've been alternating between ill and busy lately, but will continue normal duty soon :-)
<drakonis>all is fine now
<drakonis>up next, os-prober
<nckx>I will screenshot that without context and look at it when I feel anxious.
<nckx>brettgilio: Allow me to completely kill your joke by answering it: calling this procedure ‘apply-patches’ would be wrong, because it only ‘searches’ (admittedly, not much of a ‘search’) for basenamed.patches in gnu/packages/patches and returns their location. It doesn't apply them. So, sorry, your change would be reverted 😛
<drakonis>you make me blush
<mbakke>not sure if I'll make FOSDEM this year :/
<civodul>heya mbakke! hope you'll get better soonish!
<civodul>oh, we'll see
<nckx>brettgilio: The name comes from a *very* early commit, 800cde, when ‘Guix’ was ‘Ludo’ and ‘yay I can search a standard dir for patches now!’ was a thing to celebrate in procedure naming.
<nckx>(Slight dramatisation.)
<drakonis>guix was ludo then?
<drakonis>that's a double entendre
<drakonis>a ludic experience arent we
<drakonis>he he he
*mbakke just packaged UFO: Alien Invasion, so I might get busy again :P
<pkill9>i wondered where the name came from
<drakonis>ah, os-prober isnt useful right now
<nckx>It used to be called Lunix.
<nckx>(It did not.)
<drakonis>i'm going to have to update grub.cfg to add that one other OS entry aren't i?
<lispmacs[work]>was there some command to only install if substitutes are available?
<lispmacs[work]>or to check if they are?
<leoprikler>you can check `guix weather`
<nckx>drakonis: There is a way (see manual) to include custom entries in your system .scm but I don't know if it supports chainloading at the moment.
<drakonis>i have a entry configuration for handling chainloading
<drakonis>carefully plundered from older distribution grub cgs
<drakonis>hmm, it doesn't seem to give me the ability to straight up insert a string of text as a menu entry
<nckx>Yeah, I think that's what's still missing.
<drakonis>no chainloading then
<nckx>Alternatively, you can set the installer field to a (const t) gexp, so Guix's grub-install is never run but Guix's grub.cfg is updated, then manually install a ‘top-level’ GRUB with a hand written grub.cfg with 2 entries: a ‘configfile /your/guix/grub.cfg’ Guix entry and something else.
<nckx>That's how I'd do it, hope it makes sense.
*nckx → bus
<drakonis>cool beans
***flor_ is now known as flor
<civodul>mbakke: we can come up with an "only hacking and no games" channel for you if that helps ;-)
<drakonis>i got patches to submit to a game package
<drakonis>see gzdoom's package, it doesnt include the roland soundfonts, so it sounds janky and wrong
<drakonis>plus bumping it to the freshest release
<drakonis>hmm, i cant figure out why bash completion doesnt work
<drakonis>i have it enabled on the system
<drakonis>so weird.
<bandali>i don’t think $HOME/.guix-profile/etc/profile.d/ is sourced automatically
<drakonis>it doenst exist
<drakonis>doesnt exist in here, strange.
<drakonis>i have it in the system environment
<bandali>hmm, did you install the bash-completion package?
<drakonis>i have
<drakonis>i just did now
<drakonis>it sourced
<bandali>hm, i see per-package completion definitions in $HOME/.guix-profile/etc/bash_completion.d/
<bandali>nckx, any thoughts on this?
<bandali>ah, i’d asked mbakke about this many moon ago
<bandali>drakonis, try this and let me know if it helps?
<drakonis>i have the distribution here tho
<bandali>right, but i’d try explicitly sourcing the completions anyway and see if that helps
<bandali>and file a :)
<drakonis>i sourced them and it works but i dont know why it isnt automatically sourced on login
<bandali>yeah i’m curious too. report a bug please?
<mbakke>bandali: there is a more comprehensive version of that at :)
<bandali>mbakke, nice, thanks! drakonis ^
<bandali>mbakke, btw, any reason why this isn’t done out of the box?
<drakonis>i'm trying to rename the configuration file generated by grub
<drakonis>my lisp fu is insufficient
<mbakke>bandali: those instructions are for foreign distributions and we'd have to modify the users ".bashrc" or similar, which is not great
<drakonis>you can source that systemwide
<drakonis>i'm almost certain i'm doing it wrong
<drakonis>i want to have guix generate my grub config with a different name
<drakonis>so i can just have it merge everything into a single grub.cfg on boot
<bandali>mbakke, hmm, can’t they be part of $HOME/.guix-profile/etc/profile ?
<bandali>that way we wouldn’t have to touch any of the user’s files, no?
<mbakke>drakonis: I think you need something along the lines of (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (configuration-file "/boot/your.cfg"))))
<mbakke>bandali: that could work, but then we'd be very tied to bash
<bandali>mbakke, right. i was thinking somehow installing bash-completion should result in that, not in general
*nckx ← bus
<nckx>bandali: For the record, I'm the literal worst person to ask about Guix on other distributions. Never touched the stuff officer.
<bandali>damn nckx, nice :p
<leoprikler>I think the code to include $GUIX_PROFILE/etc/profile.d/... should be mate part of $GUIX_PROFILE/etc/profile
<nckx>Speaking of things I therefore don't miss on Guix System and perhaps should: does anyone still use autofs? I was slightly surprised to see it's not even packaged. Obsoleted by some $new_hotness?
<bandali>leoprikler, +1
<nckx>leoprikler: I said the same thing yesterday so that means you're right.
<dctrud>nckx: At least many HPC people still use it (autofs)
<nckx>dctrud: Thanks. Makes sense, HPC seems to be (a) last bastion of NFS as well.
<dctrud>nckx: yep, still plenty of people running NFS v3 even.
<lispmacs[work]>hi, I'm trying to use emacs-treemacs, which I cherry-picked from guix master. It runs but has no icons and gives error message "cannot find image file '/home/christopher/.guix-profile/share/emacs/site-lisp/icons/default/txt.png'"
<lispmacs[work]>is there another package I need to install?
<drakonis>alas i have found out the issue, i reused my existing home and it didnt include guix's skel
<drakonis>i'm a fool
<drakonis>that clarifies why things were so hosed
<leoprikler>lispmacs[work]: what is `tree /gnu/store/<hash>-emacs-treemacs-2.6`?
<lispmacs[work]>here is the one for treemacs-extra:
<lispmacs[work]>leoprikler: it looks like treemacs-extra was supposed to contain the icons
<lispmacs[work]>but just became a duplicate of the other package
<lispmacs[work]>or, that is one guess
<lispmacs[work]>the recursive hashes are different, though
<leoprikler>it appears both lack everything but the code
<dftxbs3e>these are really nice: -- good job
<leoprikler>and no, treemacs contains extra code
<lispmacs[work]>leoprikler: yes, just releazed that, no actual icons though
<leoprikler>you have to add an additional install phase for the data and also patch the paths
<leoprikler>for an example, look at emacs-telega, although telega would install icons on its own without that patch
<lispmacs[work]>leoprikler: I was hoping the packager who submitted it could do it
<leoprikler>probably, but I haven't followed the mailing list to find out if they do
<pkill9>i think some asciinema recordings of basic guix commands would be nice
<pkill9>inspired by
<lispmacs[work]>leoprikler: new packages committed today by Oleg Pykhalov <>
<lispmacs[work]>commits baf5856de9180c83e4c8541c5f665d171fc5da27 and 129ddf8d4a7c044268cfa76c071dcf1a8af8d37d
<lispmacs[work]>I submitted the bug report, but didn't think to CC Oleg
<lispmacs[work]>just emailed Oleg
<erikg>I'm using cmake's ExternalProject_Add functionality to manage project dependencies, but this is not usable with guix's build containerization system. I get "Could not resolve host: ..." when cmake invokes git to try to clone the repositories. Is there any low-effort workaround in guix, or is the only reasonable alternative to add the dependencies as submodules in the main repo?