IRC channel logs
2026-01-26.log
back to list of logs
<Graham31415>I'm trying guix for the first time. Yesterday, I installed guix system under qemu-system-x86_64, using the default config.scm provided with sway as the window manager. I faced two problems immediately: 1. After loggin in to the gui, the fonts are tiny and quite blurry. So I switched to logging in via ssh and serial console. 2. The system goes to sleep very quickly (triggered by xorg/gdm?), which causes <Graham31415>interactive processes such as `guix pull` to fail. I was unable to pull or system reconfigure due to these operations being far slower than the sleep timout. <Graham31415>Today, I've reinstalled using a config.scm without gdm/xorg. Now I get a different issue with `guix pull`: after receiving 35% of objects, `guix pull: error: Git error: SSL error: received early EOF`. <Graham31415>Installed from guix-system-install-1.5.0.x86_64-linux.iso <Graham31415>I've gotten this git error from `guix pull` twice now, after about 10 mins each time. <emacsomancer>thinking about `privileged-programs` and capabilities and so on in Guix (reminded by 1.5.0 release blog), does anyone have a doas+remove-sudo guix setup that's been working for them? <anemofilia>Removing sudo is quite easy, you simply pass #f as the value of the sudoeers-file field of the operating-system <Graham31415>I tried again `guix pull` finally succeeded this time, after 46 mins. This is painful! <Graham31415>And now `guix system reconfigure...` has failed with: `Git error: SSL error: received early EOF`. <emacsomancer>anemofilia: thanks! that's very helpful. this has worked well for you? (I've been interested in reducing ambient authority where possible.) <apteryx>hello! On one (desktop template based config) machine, bluetooth-service-type does not run, the bluetoothd executable errors with: "D-Bus setup failed: Connection ":1.332" is not allowed to own the service "org.bluez" due to security policies in the configuration file"; which is odd, because a very similar configuration does not have that issue on another machine. <meaty>apteryx: Unfortunately I can only offer my sympathies, the bluetooth stack is made of gremlins in my experience <meaty>every reconfigure I cross my fingers and wonder if my headphones will work fine, need to be re-paired each connect, will misconfigure, or will not connect at all <meaty>And the bluetooth+audio stack is complicated enough that it's impossible to find and choose the right support/documentation, if any non-developer material exists at all <loquatdev>I'm trying to run `guix pull` and not only is it not substituted but it attempts to build and fails during the `check` phase. <loquatdev>I'm trying again right now in case it was some kind of fluke. <loquatdev>May I ask why `guix-1.5.0.drv` even needs to be built if I'm pulling from the latest commit? <loquatdev>Also, is there any sort of timeline on when the CI might be back up? <loquatdev>Interesting. It built just fine this time around... <loquatdev>I'm sure I messed something up the first time. <apteryx>meaty: eh! In this case the issue is before any device question arises; it's the bluetooth daemon itself that refuses to start. <apteryx>on my machine bluetoothd was started by the root user (shepherd service); I'm using the bluetooth-service-type <apteryx>the /etc/bluetooth/conf.main is the same on my own machine, where it runs successfully, where it runs fine, and a different machine that exhibits the 'Connection ":1.332" is not allowed to own the service "org.bluez" due to security policies' error <Graham31415>Is there a meta package for developer/build tools? Something that might include things like gcc, make, bison, flex, autotools, etc? <lilyp>not quite, but you can use `guix shell -D` to work on a specific package <Graham31415>i'm not looking to make a package (at least, not yet) <lilyp>because that's the addressed use case <lilyp>if you need something more free-form, you'd have to look into writing manifests for your own purposes <gorilla>Why does the TUI installer copy such an extensive list of packages during the install? Can't it just copy a minimal list? <gorilla>It seems like a waste of disk, network, and time to copy a bunch of stuff it doesn't actually even install. <apteryx>ah, I think it was a mismatch in the config files (/etc/dbus-1/) vs the binary that was running <apteryx>a reboot appears to have cured that one <apteryx>meaty: for your personal KB ^ (reboot was required following adding the bluetooth-service-type service to config). Maybe I could have killed the dbus PID to have it re-read its config files. <apteryx>this could be improved in Guix... I'm sure on other systems the normal behavior is that dbus reloads its config when it detects changes to /etc/dbus-1 <apteryx>ACTION is not *sure*, but would assume <test202020>today pulled latest version in user profile, bt with sudo guix system reconfigure /etc/config.scm guix get objects from remote repo, is normal?l <anemofilia>emacsomancer, yes, I've been using the setup for a couple years now <DiffieHellman>Just realised kate is now proprietary software, how do I file an issue on the issue tracker? <DiffieHellman>>bug-guix@gnu.org to submit a bug report. I see, time to get that mail server working.. <efraim>Can't login with two factor authentication without javascript <DiffieHellman>Why would you weaken your account security with a second weak password exactly? <efraim>I don't understand why having 2FA would weaken account security, but it seems off topic for this channel <DiffieHellman>If the 2FA is on a totally compromised mobile device and can be used to reset the password or other things, then clearly account security would be weakened. All topics about freedom are clearly on topic for Guix. <nemin>Hey guys, I was hoping to try out Guix after the recent 1.5 release, but I'm really struggling to get it going the way I'd like. I installed it using the KDE desktop service type, but not only does it default to X11 for some reason with no option to switch to Wayland, I'm also unable to move any windows as they completely lack titlebars and borders. <sneek>nemin, nckx says: Use (installer #~(const #t))) in your bootloader configuration. Guix will manage its grub.conf, but not install GRUB. Not a hack. <Rutherther>nemin: Plasma has both wayland and X support, just choose when you're logging in in GDM <Rutherther>nemin: are you on 1.5.0 or have you pulled and reconfigured? <Rutherther>nemin: I am certain that on 1.5.0 there are both options. Since it has been updated post the release I cannot really say for sure that after pulling it is available <nemin>I tried it before and after and couldn't see it in either. My guix describe currently says "guix b989e01". <Rutherther>it doesn't matter what guix describe says, guix system describe is important <nemin>I installed using the 1.5.0 ISO yesterday, experienced the issue described above, did a pull/reconfigure and still face the same thing. My services contains plasma-desktop-service-type, lxqt-desktop-service-type (I added this manually), and the basic keyboard set-xorg-configuration stuff. <nemin>I'm running Nvidia which I know isn't the nicest player out there, is it possible that Guix is not allowing Wayland under that? <Rutherther>nemin: I don't know. You can try something more easy like sway in a TTY and see if it throws an error or starts it. Ie "guix shell sway -- sway" <nemin>"Found 0 GPUs, cannot create backend". Aw, I see. Sucks, I was hoping to go with free firmware only. <Rutherther>nemin: try "nomodeset" kernel argument. But I would expect lagging or lower resolution and so on <yelninei>i think my gdb commit on master is a world rebuild. Not sure how <untrusem>is there a cookbook page on packaging go programs? <untrusem>I want to update the age package to v1.3.1 <untrusem>though Idk if its suitable for a first timer <attila_lendvai_>untrusem, go apps usually have a wide web of dependencies. you will need to make decisions what dep requirements to override, or which new versions to duplicate into the guix packages, etc to satisfy all apps' dependencies... <attila_lendvai_>untrusem, i think golang knowhow is more important than the guix side, though <Rutherther>yelninei: definitely at least rebuild of rust and all its packages, because you've changed gdb/pinned. Specifically with that input addition <Rutherther>yelninei: your comment says cross-compilation, was it meant to go under an if (%current-target-system)? <yelninei>Rutherther: I guess that would work as well. I thought it was not a problem as guile is already in inputs and it gets deduplicated <untrusem>I see attila_lendvai_ , so kinda like rust but manualy <yelninei>Rutherther: in the derivation as it as now a native gdb has the same guile twice in the inputs <Rutherther>yelninei: yes. I don't know what would deduplicate that, also even if it did, chances are it could change the order of the inputs, also leading to a different derivation <yelninei>could the commit get reverted so I can figure out how to do that wihtout rebuilding everything? <Rutherther>yelninei I can revert it in like 20 mins, but if anyone else can, feel free to do it befoee that <efraim>if the substitutes are currently good then IMO it's too late and should be fixed later <efraim>oh, I thought it came in earlier <Rutherther>I think we should cancel the builds if it gets reverted here. Its unlikely were going to arrive at the same derivation eventually I would say <efraim>I'll revert it and we can rework the patch not under pressure <efraim> It happens. I've broken master before :) <yelninei>cbaines: Is there something to do if the revert is immediately after the wrong one? <Rutherther>yelninei: definitely, the builds are already scheduled, it doesn't matter how far in the future it was reverted <Rutherther>yelninei: the only case where nothing was to do would be if the revert made it before QA started processing the commit, I think <cbaines>Rutherther, this is the master branch, so it's the bffe not the qa-frontpage that submits the builds <Rutherther>cbaines: I just wanted to say bordeaux, not sure why I said QA, yeah, thanks for correction <cbaines>efraim, wonderful, thank you! I'll reconfigure bayfront and restart the bffe <efraim>it's good you mentioned it, I wouldn't have thought of it <Rutherther>I think there is an improvement for the tooling here, though. guix refresh checks for a package dependents, but what about the packages you change due to inheritance... I also recently broke a package by changing qemu, this package is in completely different file, so I haven't realized it <Rutherther>not sure how to easily find what inherits from a package. Worst case implementation would be collecting all drvs before and after a change, looking as which ones changed <cbaines>Rutherther, this is what the data service/QA was/is meant to do, but there's still work to do to bring it back after the patches to pull requests switch <Rutherther>cbaines: on one hand, but I think we could improve it by having something local. Or do you think it's impossible to do this locally? <cbaines>nope, but rigor is important, so if you have a local tool, you want to be able to trust it <Rutherther>cbaines: not sure I understand, could you elaborate on what could be problematic here? <cbaines>so given how packages are structured currently, you'd need to do what you describe (and what the data service does) by computing the derivations for some base revision and with the changes you're looking at, for all systems and cross targets <cbaines>personally I still think there's value in a more data driven approach, and one that focuses on tooling as a service, but I recognise there's a lot of value for tooling that's optimised for people to use locally <Rutherther>cbaines: oh I agree completely that the services are important and we should improve them. But sometimes you do not have them at your hand and the last resort is doing it locally <cbaines>I'm just very unmotivated at the moment, it seems like we're back to this "understand the impact of a change" thing being a far away goal <Rutherther>cbaines: in this specific case of gdb I think that it might have been that the cuirass bot has discarded it due to too many edits, I suppose it should notify about such cases, though <Rutherther>also another thing is that the cuirass bot inadvertedly also builds it, but we could also have a service that would just evaluate it and tell you the result of the changes, no need to actually build it all for all architectures <Rutherther>cbaines: why do you mean, do you mean because of my messages suggesting a local tool that I am saying it's a far away goal, or what exactly? <cbaines>Rutherther, I'd like to get something similar to QA for patch series setup for Codeberg Pull Requests, but I'd also like to do this "properly", addressing the problems in the previous design, all of which takes a lot of time and effort <cbaines>keeping in mind that this was a project "automated testing for patches" that I started back in 2019... <yelninei>even adding the guile as a condiontal input changes the non native-derivation. The reason is because the configure flags change from '() to "(list)" <Rutherther>cbaines: I see, is there a place where one can read what the problems in the previous designs were? <cbaines>but more generally, the qa-frontpage did a poor job of showing what it was doing <cbaines>so even if people took an interest, they'd often find it hard to understand <cbaines>and even though I knew what it was meant to be doing, when things went wrong, it would take time for me to figure out what was going wrong <Rutherther>cbaines: btw what's the relation between Cuirass and all these parts on the bordeaux (data-service, qa etc.). Is one meant to replace the other eventually... do they live their own lives with different use cases... ? <cbaines>the data service was originally written to work in conjunction with Cuirass, but that never really took off, and then I started working on the build coordinator to fill that gap of building things to test patch series (as well as providing substitutes) <cbaines>given the things people are trying to use them for are converging though, I can see the feature set converging as well <cbaines>for better or worse, there's not really a grand plan <yelninei>programming in gexps after a quote feels a bit wrong <getstate>Is anyone else having issues using `gpg --card-status`? Polkit complains that my user is not authorized, but this used to work? <Rutherther>cbaines: thanks. I have been a bit confused about the relation for now, because it seems sometimes both are trying to solve the same issue. But some competition definitely does not hurt <ximon>I install qtile and get lxqt that's a fucking joke <Rutherther>this channel is about guix, for topics not related to guix, you can use #guix-offtopic or other channels <getstate>Ah, it was the update to polkit that changed some behavior <futurile>Rutherther: I replied to you/ludo on the thread about next release. See what you think about moving to just after summer and whether there's things that can simplify the process <sneek>Welcome back futurile, you have 1 message! <sneek>futurile, ekaitz says: please ping me later if you are here and want to talk <Rutherther>futurile: thanks, I have seen it, but I am taking my time to dose off and reply at some other time :) <Rutherther>futurile: btw my initial proposal would've been November <untrusem>wait does the recent gdb caused rebuilds <Rutherther>untrusem: yes it cuased 7k rebuilds so it has been reverted <untrusem>there doesn't seem to a substitute for librewolf 147 its was commited was 3 days ago <untrusem>> there doesn't seem to a substitute for librewolf 147 its was commited was 3 days ago <Guest50>For local experimentation, is it possible to have a GUIX package where the source is just the current directory? I've search around and can't seem to find any documentation of what is acceptable for the "source" field on a package, other than "origin" -- I have seen "git-checkout" used, and that is my planned workaround, but I thought there'd be <ieure>Guest50, The uri field of the origin record may be a file:// URI. <Guest50>I'm working off an example of "(source (git-checkout (url (dirname (current-filename)))))", but has the interface for "source" changed? I can't seem to get it to accept anything other than "origin", which then requires a hash (which makes sense in general, but is inconvenient when I'm just trying to locally experiment iteratively) <Rutherther>Guest50: no, it hasn't, git-checkout is accepted <yelninei>you could also try local-file with recursive? #t <Guest50>Thank you both, I will spend some more time trying to figure this out... <yelninei>this argument quoting is messing with my brain <Rutherther>Guest50: note that local-file is generally better for development, but it is advisable to apply a filter to only git tracked files so that you do not end up with large unnecessary binary files in store... or worse, secrets. Git-checkout will need to actually pull from your repository to a different place. Also only committed changes will work <ieure>yelninei, The eternal Lisp struggle. <Guest50>Rutherther: thanks, that's helpful context. Yeah, I'm just locally experimenting -- trying to just create a package that places a single text file (a shell script) :) <yelninei>i have the feeling that what i am trying to achieve is impossible <ieure>yelninei, Well, don't keep us in suspense. :) <efraim>we could just override the configure-flags in gdb/pinned to be what they were before <yelninei>that might be better than the wild gexp wizardry. Id need to check if it is ok to rebuild all the other gdbs <efraim>is #:disallowed-references for all outputs or only for #$outputs:out? <Guest50>Any pointers on how to debug "Wrong type argument" errors in package definitions? I'm trying to narrow down my mistake, but it's more difficult than I expected. On the command line, it only references the source file's line where the "package" definition starts, and the REPL doesn't seem to even provide a line number <Guest50>Ideally, I'd start with a known working package, but I haven't gotten to that point yet, embarrassingly <ieure>Guest50, Paste your package definition and the error. Not in the channel! Use a pastebin. <ieure>Guest50, Guile errors are generally pretty poor. <yelninei>efraim: That seems fine. Hwoever some things depend on gdb or gdb-minimal when it probably should be gdb/pinned <ieure>yelninei, That does look tough. <muaddibb>Guest50: try to define package fields separately <yelninei>ieure: It would be easier if it could be (list) but it has to be '() specifically <Guest50>I thought my mistake was in the "source" part, but now I'm thinking it's related to the build system <ieure>Guest50, What's the exact error? <Guest50>Apologies for forgetting that: In procedure manifest-entries: Wrong type argument: #<package foobar2@1.0 /home/user/code/sharer/shc.scm:13 7f9bc03b42c0> <Guest50>And a big stack trace... maybe I should pastebin that <ieure>Guest50, What command are you using to build this? <Guest50>oh my, I hope that's not my mistake... guix pack -f tarball -m shc.scm <ieure>Guest50, `guix build -f shc.scm' is what you want. <ieure>Guest50, The `-m shc.scm' tells guix to treat shc.scm as a file containing a manifest, but it contains a package. That's what the error is telling you. <ieure>Guest50, If you want to use your code as a manifest, bind the package to a variable (ex: (define my-package (package ...))), then at the bottom, (packages->manifest (list my-package)) <Guest50>Ok, well I'm clearly out of my depth <Guest50>Well thank you, everyone, for helping out even though I had apparently gotten completely lost in the weeds <ieure>All good, that's what the channel is for. <Guest50>ieure: your tip on creating a manifest from a package was great, thank you! Retracing my steps, I'd wanted to see if GUIX could package things up easily, so I was experimenting with a local package. I was working off GUIX 1.5 docs which had a "--file" option for "guix pack", but I was on 1.4 and that option didn't exist yet, so I got mixed up <Guest50>thinking that a manifest could just *be* a package--rather than *contain* one. Very helpful! <ewyufg34>Hi, does Guix require bitmaps font to be manually enabled as in Trisquel/Debian/Ubuntu or declared in the system/home config? I can't find my bitmapped fonts when I run fc-cache/fc-list or xlsfonts even if they are in my .local/share/fonts/ directory. Only vectorized fonts are listed. In Trisquel I had to remove the 70-no-bitmaps.conf file, symlink 70-force-bitmap.conf to /etc/fonts/conf.d/ and run `dpkg-reconfigure fontconfig-co <ieure>Guest50, Yep, manifests are collections of packages. But nothing stopping you from creating a manifest with a single package. <podiki>has anyone used hyprpaper recently (since update in past few weeks)? i think it can't find/load egl properly and not sure how to fix it <podiki>i think the issue is that hyprpaper now uses hyprtoolkit which uses egl; i can get it to work by using mesa compiled with libglvnd and specifying some environment variables <podiki>but i would think it would work some other way <look>podiki: I have the same issue on my AMD laptop. however on my nvidia system it works flawlessly <podiki>yeah, i'm guessing you use some nvidia drivers from a channel, which will have glvnd correct <podiki>this is a long standing issue/request to build mesa with glvnd <look>it would be really nice to have libglvnd support on mesa <podiki>the basic idea is real easy: add libglvnd to mesa inputs <podiki>but that requires a bunch of package changes because some libraries are then only in libglvnd <podiki>maybe i'll just try this on a branch, build with libglvnd, specify some search paths and patch the egl_vendor file, and see what breaks mesa->libglvnd in packages <Rutherther>podiki: are those search paths only for builds or even for usage in runtime? <podiki>since libglvnd is meant to be a wrapper/loader to direct to a vendor supplied libegl, for instance <look>would it be possible to gradually move packages into it? e.g adding a mesa-with-libglvnd and switching packages slowly over time, or is it an all/nothing thing? <podiki>libglvnd acts as the main place to ask for libGL stuff <podiki>look: that's what i'm wondering right now too <Rutherther>podiki: that's going to be a problem then I presume, because what will bring the search paths to profiles normally? <Rutherther>podiki: seems to be it could be similar issue to XDG DATA DIRS and the like <podiki>yeah that's always the potential issue, but i think mesa ends up in system profile pretty generally for any graphical system? <Rutherther>I don't have it. Not in home profile, not in system profile <podiki>if you look at /run/current-system/profile/share ? <Rutherther>I use quite a minimal setup in this regard. No login manager etc. <podiki>e.g. i have /run/current-system/profile/share/vulkan which points to mesa <Rutherther>okay, that folder is there and does point to mesa. But I don't see mesa in guix system describe --list-installed. Hmm, maybe I misunderstood and list-installed doesn't show propagated inputs <Rutherther>but now I am wondering what propagated it and if it's not something we would want to ideally get rid of in the future <podiki>this might be part of the whole xdg_ env stuff <Rutherther>...of the propagation I mean. Because if it was just .pc file propagation, I would like to get rid of that in the future. But it would prevent this use case we're talking abouthere <podiki>as that's where share is used from often <Rutherther>podiki: I mean what package propagated mesa so that it appeared in the profile <podiki>it's .pc requires egl and egl according to the comment <podiki>likely that would become libglvnd then <jnms1>I'm having issues reproducing python-minimal on v1.5.0 because of tests receiving EINVAL when expecting EACCESS or EPERM <podiki>Rutherther: see ^ for where mesa is propagated probably; might play around with this on a branch in the near future; away for now <Rutherther>podiki: yeah but that makes me worried because I would say go for multiple people (though there might not be consensus yet, I don't know) is to get rid of .pc propagaations <podiki>yeah we always want to minimize propagations, wasn't aware of any particular effort to do away with them in this case (what would need to be done?) <yelninei>Rutherther: Did you see my snippet to patch pc Requires fields with absolute paths. Both pkg-config and pkgconf accept this. <jungy>Just want to follow up on yesterday--moving it to base-services from xfce seems to have resolved all my network issues. <jungy>Thank you to everyone who gave me advice. <yelninei>jnms: Do you run the daemon unprivileged or privileged? <ieure>...assuming this is the same thing. <ieure>"Unlicensed" means the owner retains all rights and grants none, so it's not only incompatible with a libre license, but actually illegal to do anything with. <light`>Hello, are there any people here <light`>wait how do you mention in irc channels? I'm new here <noe>You just put the name, so your mention worked and the @ is not needed <light`>wait you see it being highlighted, like I see light` <ieure>light`, Well-behaved IRC clients notice when your nick appears in a message and will do something (highlight/notify) with it. <ieure>light`, Very good IRC clients let you do something similar, but for arbitrary text. ERC is one such client. <ieure>light`, You're using rcirc, which is another Emacs-based client. There are (at least) three clients bundled with Emacs, rcirc, circe, and ERC. <light`>ieure why do you find ERC the best? everything is just a text buffer right? so you must be able to run any emacs function anywhere right? <ieure>light`, I never said it was the best, nor do I think that. It's just what I'm used to and comfortable with. <ieure>I have no opinion about what the "best" client is. I think it's too subjective for such judgements. <ieure>And the ability to pick a client that works for you / agrees with your taste is one of the best things about IRC! <light`>I came here to ask some skheme gods what I fun stuff I can do with guix. PID 1 is a whitebox just like emacs. Whay are you doing? <ieure>light`, Just, uh, normal computer stuff. Been thinking it'd be interesting to try the port of Shepherd to Spritely Goblins. <light`>I found emacs-guix to be super cool, I instantly installed it on hardware after I came across it while trying out in VM. But there must be something "emacsy" people do with this right? <ieure>light`, I use the REPL when I'm developing packages and services. <light`>ieure, sorry for not saying your name bro, you probably didn't get the text highlighted <ieure>You don't have to mention every time in the middle of a convo, the context is clear. <light`>ieure, that's something I found super cool as well, but I got it up an running like today morning so I haven't tested a bunch of stuff <ieure>light`, Have you tried EXWM? It's not Guix-specific, but Guix has the best support for it of any distro I'm aware of. <light`>ieure, How difficult do you think would it be to write a home-i3blocks-service-type kinda stuff to like generate a i3blocks config file with skheme? I only know some emacs lisp though <ieure>light`, Why do you keep spelling it "skheme?" It's "Scheme." <noe>light`, shouldn’t be too hard :) <light`>ieure, sorry bro, never learned it in school. <noe>you can always copy from similar services <ieure>light`, Service to generate a config file shouldn't be too difficult, but I don't know the file format, and that's what drives a lot of the complexity. <light`>ieure noe, i thought about i3blocks because it's config file looks dead simple. <ieure>There is often a lot of subtle complexity that you only discover when actually building the code. <light`>ieure I'm not planning to like distribute it because It's going to be a stupid hack that only works on my usecases. But the file format looks like toml so IDK. Maybe I'll try looking into it tomorrow and decide if I can do it. <noe>light`, by the way, please consider avoiding gender specific nouns like bro, in case your correspondent is not a man :) <podiki>(funny enough, i think at this point it has become gender neutral, at least with younger generation in the us) <Guest50>What should go into a "guix pack" tarball? I have a manifest with a single package I authored that contains a single file, but somehow it looks like emacs-subdirs, bash, and some C headers are getting included <Guest50>I tried disabling several options to no avail. This is on Guix 1.4.0 <noe>Guest50, the package and all its dependencies are included <noe>Also Guix 1.4 is 3 years old, please consider running guix pull <Guest50>Sure, but I didn't specify any dependencies at all, so <ieure>Guest50, There are implicit dependencies from the build system, if you have a shell script, you'll need a shell to run it, etc. <Guest50>I'm using copy-build-system -- I'll check and see if that is the culprit... <noe>As ieure said, you can see these dependencies using the guix size or guix graph commands <ieure>Guest50, If this is a problem for you, why are you using `guix pack' in the first place? You could just `tar czf script.sh mypack.tar.gz'. <hanker>> (funny enough, i think at this point it has become gender neutral, at least with younger generation in the us) <hanker>not being gender-neutral in the first place was something very US-ey anyway <Guest50>Sure, I'm just trying to start wit hthe most minimal package and build up from there. I was expecting the bare minimum to be tiny, but it's already 13 MB -- not necessarily a big deal, but I didn't understand where all the cruft was coming from, e.g. an Emacs lisp file! <noe>If you really want no dependencies, you can try using trivial-build-system, or if you are just using the origin verbatim you can use the origin as if it was a package <ieure>Guest50, I think you maybbe confused about what `guix pack' is for. Which is, for allowing Guix-packaged software to be sent to / run on systems not running Guix. <ieure>`guix pack' isn't something you run if you want to package software for Guix and run it on a system which runs Guix (either Guix System or as a foreign package manager). <Guest50>Yes, thanks, I understand that. I'm basically doing a "hello world" because I was worried about unexpected overhead <Rutherther>Guest50: that elisp file is added from a profile hook. There should probably be a check that ensures it creates this file only when it's actually necessary. Still, it's only a text file and it doesn't reference any other store path, so it adds a few bytes only <Guest50>Yeah, the elisp file is small, but it was just very surprising to see. If I'm reading correctly, it looks like copy-build-system uses the same packages as gnu-build-system, which I bet is where these files are all coming from. I assumed copy-build-system would only impact the build environment and not the result. I will look into <Guest50>Thanks for indulging my questions! I'm just "kicking the tires" of Guix to see if it's a good fit for my purposes (low overhead distribution of some utilities in both tarball and container form -- "guix pack" sounded great for this when I read about it) <Rutherther>Guest50: no the lisp is not coming from the gnu-build-system, it is coming from profile hoooks <Rutherther>Guest50: however some other files could definitely be from gnu build system, like if you see ld.so.cache <Parra>Hello, I have a CI that incrementally builds a Guix image, how is it possible that in only 33 commits after one week, the risc-v architecture passed to build in 2h22min: <Parra>Is any way I can cache or speed up builds better? Maybe I have to build it each two days instead of weekly? <ieure>Parra, Your setup is extremely inefficient, you're doing a ton of work each time. Look at the list-generations output from pull.sh: it's always starting from commit 696b85377d5402920dec32c223cdcb1ed815a0fb. <ieure>They keep leaving right before I say something. Oh well. <ieure>sneek, later tell Parra You're doing a ton of repeated work on every build. Look at the list-generations output from pull.sh: it's always starting from commit 696b85377d5402920dec32c223cdcb1ed815a0fb. <ieure>sneek, later tell Parra You need to cache at least $HOME/.cache/guix and /gnu/store across builds, otherwise it will get slower with each commit added, because you always start from the same commit and don't seem to be saving work across builds. <sneek>Welcome back Parra, you have 2 messages! <sneek>Parra, ieure says: You're doing a ton of repeated work on every build. Look at the list-generations output from pull.sh: it's always starting from commit 696b85377d5402920dec32c223cdcb1ed815a0fb. <sneek>Parra, ieure says: You need to cache at least $HOME/.cache/guix and /gnu/store across builds, otherwise it will get slower with each commit added, because you always start from the same commit and don't seem to be saving work across builds. <Parra>I am caching everything there.. one thing I am doing is deleting all the generations except by the latest in order to have always one unique generation.. I'm not sure if that's what you mean in pull.sh <ieure>Parra, Hmm, well. Hard to say what's making it slow, or whether it's a trend. Commits are not equal, some commits will trigger a world rebuild, some only a single re/build. <ieure>Parra, Timing also matters. If you're using substitutes, you might get substitutes for all, some, or none of the store items you need. <ieure>Parra, Yeah, I hear you, I'm just at work and can't do an in depth investigation of your problem. <Parra>Thanks Ieure, I know it's very vague <Parra>I thought this time I would be able to skip this issue, I already had it in the past <Parra>I think the only way to improve it is build it locally, first time it worked faster but now it seems it is building something in riscv that makes it really slow to build <ieure>Parra, I believe there was some work done on a Guix image for CI, is your thing that, or homegrown? It feels homegrown to me. <ieure>Parra, Maybe check guix-devel, I believe the CI image was mentioned there. <Parra>I have been building this since three years ago or so <Parra>I have published it few times already and as it seems it's not properly indexed in google people kept reimplementing it xD <Parra>this implementation I reached seems the most robust and complete <Parra>I was expecting to work for all architectures for a long time but I reached a similar issue I already had in riscv etc <Parra>I was thinking maybe building each two days <ieure>Sure, you can try that, but it's a balancing act. Like I said, there's a timing component. <ieure>If you build more often, you lower the probability of substitutes for the things you're building. <ieure>Which will, probably, make it even slower, as you have to compile stuff, and this is all happening under qemu. <Parra>how substitutes work under the hood? I mean is there a server that builds all substitutes of riscv? I couldn't find it in guix ci <ieure>Parra, Not sure I understand your question. Both CI and Bordeaux build for riscv64. <ieure>Those are in the default substitute server list, so unless you're removing those, you will get some substitutes. <Parra>How can I check what substitutes are built? <ieure>Parra, Note that the non-amd64 platforms are usually in very poor shape, and often have no substitutes, sometimes because the builds break on them. <Parra>yes that's what I have observed, I wanted to overcome it in this last version I've done <ieure>Parra, ex. 22.5% of packages in Guix have riscv64 substitutes, vs. 98.2% for amd64. This is a pretty typical ratio. armhf is the best of the non-amd64 builds, at nearly 35%. <lfam>I'm surprised that armhf is better than aarch64 <ieure>lfam, Sorry, I misread, aarch64 is 94.8%. <Parra>I only used to build 386 and amd64 <ieure>Parra, My point here is that overcoming the problem means that your image builds will be slow, because you're compiling more stuff. <ieure>And if the package is broken on riscv64, it will both take a long time and also fail. <Parra>so probably it won't work on my software as I was expecting <Parra>I should keep building 386 and amd64 as before <Parra>this is what I build with that guix image: <Parra>it depends on python, nodejs... <Parra>guix has helped me a lot, I want to try to make reliable incremental releases for everyone too <Parra>I will build it locally and push it.. I will investigate a bit more too <Parra>one more question would you cache like this? <Parra>or would you copy the whole store? <ieure>Parra, Why do you keep quitting and rejoining? <Parra>what is the difference between the whole store and that? I keep doing that because I'm using the IRC web client and it's horrible <Parra>I just block the phone and it does that... <ieure>Oh, well, there are many clients available that aren't the horrible web interface. <ieure>Parra, I'm not sure exactly what the difference is, compare what ends up cached vs. the whole store? <Parra>for android? I tried few some years ago for the guix irc too haha, but they were very bad <ieure>Parra, I have The Lounge set up, it connects to ZNC, it works okay. But I mostly just don't IRC from my phone, I prefer a real computer. <ieure>Parra, I believe there's a SQLite database in play as well, not sure if that's getting handled by your setup or not. <Parra>respect to the other issue I will build locally and then I will try to cache the whole store <ieure>guix export / guix import ought to do the right thing. <ieure>Would think you probably want to turn your profile into a manifest, export that, import it next time around. <ieure>Parra, It's in the Guix manual. <ieure>I'm not sure if that'll include the current guix or not. <Parra>what I am doing now is generating an image and binary tarballs that can be installed fast, they are up to date, and I can build anything with it <Parra>and I'm hacking around the profile a bit <Parra>just for having always the generations clean <Parra>otherwise as it is incremental, it keeps growing the generations <ieure>Parra, I hear IRCCloud is nice. <parra>I'm from the IRCCloud now XD <parra>I'm not sure if what you said about export import is exactly what I need <parra>I will investigate more and come back here <parra>I just need this to be robust, that's all <parra>it seemed to work but apparently it doesn't xD