<drakonis1>hmm, i'm having issues with installing it seems <leoprikler>(using paste.debian.net or whichever paste service you can find) <drakonis1>the traceback i can get at this point is just "readdir error: input/output error" <drakonis1>havent had this kind of shit happen on nix though <NieDzejkob>woah, "half a decade" is a great way to make 5 years sound like more than it is <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 <leoprikler>drakonis1: can you at least estimate the path for which this IO error is raised? <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"... <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 <drakonis1>maybe i should purge my root filesystem before engaging on this <raghav-gururajan>sneek: later tell brettgilio: gnome-boxes needs 'runpath validation' to be fixed. I will be sending email on help-guix for help. :-) <mehlon>sneek: later tell mehlon: welcome to the guix <mehlon>sneek: later tell raghav-gururajan: :3 <sneek>mehlon, mehlon says: welcome to the guix <sneek>raghav-gururajan, you have 1 message. <sneek>raghav-gururajan, mehlon says: :3 <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>hmm how should i do the install using the data already in the media? <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 <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 <drakonis1>a better question, how do i do the install with upgraded packages? <drakonis1>"/gnu/store/mmnl20fg05w8gzzsp4d8dvagmdn1vjil-linux-libre-5.1.2/lib/modules/5.1.2-gnu/kernel/drivers/video/backlight/lv5207lp.ko" <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`? <leoprikler>`ls /mnt/gnu/store/mmnl20fg05w8gzzsp4d8dvagmdn1vjil-linux-libre-5.1.2/lib/modules/5.1.2-gnu/kernel/drivers/video/backlight/lv5207lp.ko`? <drakonis1>there's a dmesg error regarding the iso itself <drakonis1>guix pull with the store mounted means it'll write to disk if i do guix pull then <drakonis1>i think it redirects the writes to a different store <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 <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 <pkill9>my sleep rhythm has gotten terrible <leoprikler>hopefully someone else can help, but our irc is usally dead at these times <drakonis1>i think i might have to bootstrap it using another distro <drakonis1>is there a way to fetch an install iso with fresher packages? <pie_[bnc]>they are easy to generate yourself if that helps <drakonis1>i'll generate one and move it to a partition i can access to write it to the flash drive <pie_[bnc]>drakonis1: i though tthis was nixos-chat 'xD <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
***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 <Gooberpatrol66>wild guess, does it freeze if you have circular dependencies in a package? *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? <brettgilio>raghav-gururajan: means where two packages depend on each other to build <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>Not that anybody asked, but I've always felt like the search-path method should be called apply-patch. <brettgilio>Just for fun, let's change it and then change every package that uses it. (◠‿◕) <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>one space between sentences in the description? tag it as an error <efraim>("foo", foo) in the inputs? same <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 <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... <g_bor>on the first run it failed phase check for me... <g_bor>This seems like serious trouble. <g_bor>ok, I am trying it as is for now. <g_bor>Will do that if it fails again. <g_bor>The main problem is that this blocks reconfigures. <g_bor>It should be fixed on ci as soon as possible. <g_bor>raghav-gururajan: I am not sure about that... <g_bor>what are these Servname not supported lines? <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... <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 <g_bor>civodul: Would it be useful to try 'guix build guix' on berlin? <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... <dutchie>it's closer to X11 but also misses a bunch <g_bor>also it forgets the layout on the screen lockaer <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 <efraim>Anything need to be added to the gnome-desktop-service? <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 <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. <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 <civodul>g_bor: yes, it's just that these tarballs could be GC'd by one of the last tests <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)? <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 <leoprikler>str1ngs: given the overall design of nomad, would that not be another variant of "guix via emacs"? <str1ngs>potentially yes, but it would have clickable features so it's not 100% dependent on emacs bindings per say <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. <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" <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? <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. <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>leoprikler: that can be done in nomad <str1ngs>though it would be easier to do if guix record types used goops <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>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>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. <str1ngs>the difference is that you could do inherit the record->goops as part of the widget <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>not to mention with goops you gain generic methods. so you can use gtk functions/method directly on the class instance <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 <leoprikler>as far as I'm aware, GOOPS has no magical "make this a widget please" function <str1ngs>it's not magic but it has inheritance. ergo you can derived package-view from vbox for example <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 <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>but at least the display portion should in my opinion be done with some Gtk Builder XML (produced by Glade) <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 ***ng0_ is now known as ng0
<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 would love to travel to .cl <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 <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. <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 <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. <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 <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>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 <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>looks like the other maintainers may not be around <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 <leoprikler>str1ngs: I think it is a weird version mismatch in Gtk/Gdk ***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. <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 <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` <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 <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>leoprikler: see grep shared-library $GUIX_ENVIRONMENT/share/gir-1.0/* . so cairo looks suspect <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. <str1ngs>IIRC cairo gir is from gobject-introspection . that needs to be substitute in the gobject-introspection package <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>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>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 <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>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>i have certain needs that cannot be met by linuxes due to occasionally sharing it with others <drakonis1>xorg's bringup is supposed to take a while, right? <nckx>Er, a few seconds, perhaps. <nckx>Maybe longer on slow HDDs. <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 <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>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>I've been alternating between ill and busy lately, but will continue normal duty soon :-) <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 😛 <mbakke>not sure if I'll make FOSDEM this year :/ <civodul>heya mbakke! hope you'll get better soonish! <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. *mbakke just packaged UFO: Alien Invasion, so I might get busy again :P <pkill9>i wondered where the name came from <nckx>It used to be called Lunix. <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? <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. <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. ***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>hmm, i cant figure out why bash completion doesnt work <bandali>i don’t think $HOME/.guix-profile/etc/profile.d/bash_completion.sh is sourced automatically <bandali>hmm, did you install the bash-completion package? <bandali>hm, i see per-package completion definitions in $HOME/.guix-profile/etc/bash_completion.d/ <bandali>ah, i’d asked mbakke about this many moon ago <bandali>right, but i’d try explicitly sourcing the completions anyway and see if that helps <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? <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 <mbakke>bandali: those instructions are for foreign distributions and we'd have to modify the users ".bashrc" or similar, which is not great <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>bandali: For the record, I'm the literal worst person to ask about Guix on other distributions. Never touched the stuff officer. <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? <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'" <drakonis>alas i have found out the issue, i reused my existing home and it didnt include guix's skel <leoprikler>lispmacs[work]: what is `tree /gnu/store/<hash>-emacs-treemacs-2.6`? <lispmacs[work]>leoprikler: it looks like treemacs-extra was supposed to contain the icons <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 <lispmacs[work]>leoprikler: new packages committed today by Oleg Pykhalov <go.wigust@gmail.com> <lispmacs[work]>commits baf5856de9180c83e4c8541c5f665d171fc5da27 and 129ddf8d4a7c044268cfa76c071dcf1a8af8d37d <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?