<podiki[m]>chromium is in your PATH no? no need for a store path <podiki[m]>you wouldn't want to use a store path or it will break on an update <vagrantc>the version of chromium in guix has a lot of the upstream bundled stuff removed <opalvaults[m]>podiki: I think he means to create a service that would point to store for him, specifically for chromium. <podiki[m]>but for desktop files in a user path, I don't think you'd want a store patah <mekeor[m]>chromium is FLOSS and google adds google-stuff to it and rebrands it as "google chrome". i.e. google exploits the FLOSS-community <podiki[m]>(versus desktop file from a package which will use its own store path usually) <awb99>It is not picking up the desktop file unfortunately. <podiki[m]>you but it somewhere in XDG_DATA_DIRS (or whatever it is) and woffi uses that? <vagrantc>"guix edit ungoogled-chromium" to see how much is actually patched out of the so-called FLOSS chromium <awb99>so that the XDG_DATA_DIR change is picked up. <awb99>might be that it uses it, but I cannot see it <mekeor[m]>there might be non-male people here. let's avoid exclusive words like "gents" :) <Kabouik>I know most Guix users would use emacs but I trying to get my kakoune config to work on Guix and am having trouble, for some reason even after copying my ~/.config/kak from a Debian computer where it works, on Guix the syntax highlighter fails and some other plugins too, and I really don't understand the debug buffer. <Kabouik>I asked on #kakoune too but the issues seem to be specific to using the Guix kakoune package or at least the Guix filesystem and I doubt I'll find many Guix users there <lfam>Kabouik: Would it make sense that the plugins are missing on Guix? <lfam>Like, do you have a reason to expect them to be available? <Kabouik>I don't think so, they're installed through a plugin manager inside kak and I can see they are installed <lfam>Do you know where they were installed to? Like, where on the filesystem? <Kabouik>Inside ~/.config/kak is the typical place <lfam>So, the problem is that kakoune doesn't seem to be looking for plugins in the normal place? <Kabouik>I think plugins are fine, but kakoune I believe must be looking for default stuff in /usr/share/kak and can't find it on Guix unusual filesystem <lfam>It's definitely something for kakoune experts to investigate, but I understand if they didn't want to help <Kabouik>They're very helpful and keen to help usually, but since they're obviously not emacs user (like me!), I don't know if they'll know much about Guix <lfam>So, we do set PREFIX... let's see if the Makefile uses it in a way that would cause this issue <lfam>Regarding asking them for help, they might at least already know how Kakoune looks for these things, and so we could take that information and apply it to Guix, to understand what's wrong <lfam>Also, they can interpret Kakoune error messages more easily than us <Kabouik>It may very well be a local issue on my side too, since I got no issue with the fresh kakoune install, just when using my kakrc (which works on Debian); but I'll wait for their answers too yup <lfam>You said that you think there is not a problem finding plugins, but your errors show that it can't find 'surround'. Isn't that a plugin? <Kabouik>But that one apparently is not loaded with the plugin manager currently in my config, I'll see if they changed something in the source of that plugin <lfam>I guess I'm still trying to understand what the problem is <Kabouik>I'm not sure what is the source problem either, I just see my debug buffer filling up and my syntax highlighter not working <Kabouik>Yeah surround works, it's just that it no longer needs "require-module surround" in my kakrc since some update, and on Guix I had the updated version. That solves one issue in the debug but I still have the others <Kabouik>Okay, seems most issues are due to plugin updates that changed the way to enable them or their special features, I'm slowly solving the different issues. <Kabouik>The highlighter is still broken though, which is the most annoying <lfam>And do you know if the highlighter is an external plugin, or supposed to be part of Kakoune? <Kabouik>I think it's builtin at least form base languages, like that in kakrc <Kabouik>Phew, problem solved, this was all due to a conflict between the autoload folder and the plugin manager, which didn't occur with the older version of the plugin manager. <Kabouik>Now I just have those clipboard issues. xclip and xsel are installed, but maybe Guix uses something else by default for system clipboard? <Kabouik>I'm not raingloom, just xfce4 right now while configuring things, then i3 when I'll consider it ready for real use, and then hopefully StumpWM (although I read it doesn't allow multimonitor workspaces, which is a dealbreaker) ***Xenguy_ is now known as Xenguy
<Kabouik>Is there a way to get cargo nightly? The guix package is stable and installing through rustup fails <jgart>hi guixers! when setting up a channel, is it possible to add the gpg keys in the same branch as the channel instead of a separate keyring branch? <jgart>I haven't tried but I was just wondering if anyone has made a channel this way? <raghavgururajan>jgart: Yes! You just have to have specify the branch name in the .guix-channel file <jgart>I'm just brainstorming how much I can automate for a cookiecutter template for a Guix Channel *jgart wonders if a cookiecutter can ask the user for a file path to a gpg public key to add to the initial repo in a branch *jgart should rtfm for cookiecutter <lilyp>rekado_, nckx: I thought the style for using commits if upstream has unreliable tags is to let-bind them <nckx>Not if they're releases. <nckx>The reason for let-binding is so you can use git-version and the like. <lilyp>nckx: If releases are volatile, there's no reason to treat them differently from normal commits as far as the version field is concerned <lilyp>you might still only bump the package if upstream moves the tag, in which case the revision "field" captures how often you've done that <nckx>Yes. You're moving the goal posts. <nckx>It has nothing to do with ‘using a commit, hence let’ but ‘upstream doesn't do meaningful releases, hence we use a VCS-style version number, hence let’. <nckx>If upstream has sane release management I still advocate for using commits ‘for robustness’, not using git-version for *every single* git-fetch package. <nckx>If that's what you're advocating I can't agree. <lilyp>you're using a commit in both scenarios <nckx>Hence why ‘using a commit’ is not a meaningful factor in ’should I let-bind’. <nckx>Because the answer is ‘maybe’. <nckx>I don't think you can tell if upstream has unreliable tags beforehand? <lilyp>Why is the answer on that maybe? <nckx>That it depends solely on other factors. <nckx>Maybe I'm reading your question too much in the context of rek ado's message. ‘Tags are mutable’ does not mean ‘upstream has unreliable tags’, it means *all* tags are mutable. That was the context of my earlier messages at least. <lilyp>Well, sure, but so are tarballs. <lilyp>I think we can by default assume that upstreams do not mutate tags and treat those who do specially. <nckx>We tend to find out which upstreams are unreliable when it's too late. I don't think that means using 0.7.1-0.abcdef0 version numbers everywhere is a good idea. <nckx>I just don't see why let-binding is relevant here? <lilyp>because a raw commit is used "in case upstream moves its tag" <lilyp>and I'd argue that when using raw commits (even if those happen to be releases at some point), we ought to also use the revision flag <nckx>So we should use 0.7.1-0.abcdef0 versions for all Guix packages building from git, which is or will be the majority? <nckx>We simply disagree on that. <lilyp>at least "in case upstream moves its tag" <nckx>But it's certainly not ‘guix style’ to do so now. <lilyp>if we can't agree on "version = tag", what other source of truth do we have? <lilyp>configure.ac et al. might hold the same version for a loooooooooooooong time <nckx>The first commit to be tagged as such; the release announcement; commit messages… <nckx>This is getting into hypotheticals though. <nckx>Unfortunately, yes, configure.ac and other sources can be just as unreliable as the rest of upstream… if upstream is unreliable. <lilyp>commit messages can be shaky, release announcements withdrawn and the tag moving is the reason we have this debate <lilyp>unless you capture them elsewhere meticulously such as SWH <nckx>I guess I see it as hijacking my original messages to promote some unrelated matter. <nckx>Having the distro littered with custom versions was not the future I wanted. <nckx>You're welcome to suggest it, I just don't agree with the reasoning or the conclusion. <nckx>In fact it would save me the trouble of starting a guix-devel@ thread 😉 <nckx>How do release announcements get withdrawn? And why couldn't we deal with that extremely rare occurence by simply moving from 0.7.1 → 0.7.1-1.abcdef0 *when it happens*? <nckx>Which is very much the status quo. <robin>Kabouik, they're not packaged at present, but if you only need rust beta/nightly packages to be available for access to cargo nightly it'd likely be fairly straightforward (depending on what changes upstream, of course -- most rust packages need at least small modifications, though in the ideal case a new version only requires a three-line package definition) <robin>(having multiple guix-packaged versions of crates would be rather more complicated, but i'm assuming, perhaps incorrectly, that one would just use cargo directly for beta/nightly-based development) <gnoo_>hello, i messed up the efi-entry on config.scm while doing guix system init /mnt/etc/config.scm /mnt, I then rm -rf /mnt/boot, now, is it possible to only install grub and not other packages from the live-image? <gnoo_>from looking at the documentation guix system build looks like what i want but can it work for /mnt instead of /? <gnoo_>(i'm away from that pc but will see your replies with this nick and my other nick (gnoo)) <Karthik[m]>PotentialUser-84: Technically Yes, you could create / update guix packages on other distros too <PotentialUser-84>Karthik[m] thx. i want to help, just dont have hardware to install guix system rn <raghavgururajan>While `guix pull`, if building package-cache keeps failing, would that indicate a specific issue? <ns12>Hi Guix. When using the gnu-build-system in a package definition, how do I specify the GCC version? For example, I want to compile a package using gcc-9 instead of the default version. <ns12>Btw, what is the default version of GCC that Guix uses to compile packages? <raghavgururajan>ns12: If you add gcc-n (n=version) in native-inputs, the build-system will use that version. <ns12>raghavgururajan: Is that all that's needed? Wonderful. <ns12>Btw, what is the default GCC version if I don't specify a particular GCC version? <ns12>lfam: Thanks. How many times is the default GCC upgraded each year? From my understanding, it cannot be very often because changing the GCC version will trigger the rebuild of a great many packages that are built using GCC. <lfam>Less than once per year in recent years <ns12>When do such upgrades usually occur? When a new major version of GCC is released? <lfam>We batch all the changes that would cause the entire distro to be rebuilt into a long-term project called "core-updates" <lfam>These core-updates cycles sometimes take a few months to complete, sometimes 2 years <lfam>So, it's not tied to upstream release cycles <ns12>I see. Is that the "core-updates-frozen" that people kept on mentioning last month? <lfam>It was merged a couple weeks ago, and that's why we have GCC 10 now <PotentialUser-84>guix is rolling release right? so are all packages frozen until each core-update is done? <lfam>The "frozen" part refers to what happens at the end of the core-updates cycle. No more big changes are added to it, and we just fix bugs and get it ready to deploy <lfam>The master branch is not frozen during that time. Just the core-updates branch <lfam>The master branch is basically never frozen. Maybe for a few hours while new releases of Guix are being prepared <PotentialUser-84>ok so it would be comparable to fedora linux. where during each release some packages get upgrades, and big changes (eg rebuilds) happen every now and then <lfam>Guix releases are basically just milestones. They don't deliver anything new for existing users who were already keeping up to date <lfam>But, they provide a tested and current entry point for new users <ns12>lfam: Was the introduction of the new-style inputs the result of merging the core-updates-frozen branch? <lfam>I don't recall if that happened on core-updates or not ns12. My understanding is the style change was done in a way that wasn't expected to cause any rebuilds, so it could be done freely without disruption <lfam>That's partly why the change is incomplete. Only the parts that could be automatically and without causing rebuilds have been done yet, for the most part <ns12>Does Guix have a policy against open source gambling games? <AwesomeAdam54321>ns12: I'm pretty sure, since the goal of free software is to be of benefit to society <ns12>AwesomeAdam54321: Gambling games are not allowed in Guix? <lfam>There's definitely no policy about that <ns12>Okay. There's a poker game and a blackjack game in Guix. <lfam>So, it has to be freely licensed, and the linked FSDG says "no malware". The last bit has been interpreted in a variety of ways but usually you know it when you see it <sneek>mothacehe, you have 1 message! <sneek>mothacehe, jpoiret says: do you think we could add a "Paste to paste.debian.net" link for the backtraces in the installer? I was thinking we could also have the same for syslog <mothacehe>jpoiret: great idea, we could even send crash reports (backtrace + syslog + dmesg) to a server if the user agrees <user844486>Hi, I installed guixos with gnome desktop. guix system reconfigure /etc/config.scm downloads gnome apps which already exist with same version. Is there any way to avoid it <userr>Hi, nautilus open in terminal options is missing, is there a way fix it <Karthik[m]>Hello people!, I need help with guile setup on doom emacs <Karthik[m]>I get this error after installing `geiser` & `geiser-guile` packages <florhizome[m]><Kabouik> "I don't think so, they're..." <- Have you looked at nix' solution?^^ <florhizome[m]><florhizome[m]> "„guix style -L .“ in guix shell..." <- someone got a clue to this? <mroh>Karthik: I don't think guix emacs- packages work well in doom emacs. Maybe, try the doom equivalents of geiser. <nckx>lilyp: I should not have said ‘hijacked’ this morning. Apologies. <nckx>Still am, so no IRC for me. <florhizome[m]><mroh> "Karthik: I don't think guix..." <- hmm karthik I might try using guix emacs from straight since it hasn’t been working for a while now for me if that works for you <florhizome[m]><user844486> "Hi, I installed guixos with..." <- It’s very hard to say why they have been downloaded I think. maybe there has been a change in the dependencies, or so. <htgoebel>How to get some fixes required after the last core-update merge into the upcoming next release? <htgoebel>Concrete: 140 trytond packages failed after core-update merge, which is now fixed on master. And this fixes should go into the next release, of course. <PurpleSym>htgoebel: I believe you can/should cherry-pick into the branch version-1.4.0. <PurpleSym>(See topic “core-updates-frozen branch merged” on -devel3) <cbaines>this makes it really inconvinient to update systems using the prometheus-node-exporter <Kabouik>Thanks robin. I just needed nightly for some crates (namely broot) and I assume that's the issue with Rust, some packages do *need* nightly and just don't build with stable. <PotentialUser-3>Hi, I would like to know if there is a converter/translator for AUR build scripts to Guix Scheme. Or is it realistic to create some kind of script that will do. <Kabouik>Another issue: I'm confused as to what is the workflow to compile programs from sources on Guix. On Debian I would install a bunch of -dev packages and build in the git folder (which I know is not great, I clutter my system with dev packages, I should use a VM I guess). On Guix I don't see -dev packages. <rekado_>PotentialUser-3: not sure if it’s feasible because we don’t use shell snippets for build phases. And package definitions in the AUR do not comprehensively declare all necessary inputs. <ss2>where could I find the gvfs- binaries? They are not in gvfs. <efraim>cbaines: I've been working at go on aarch64 for about a week now, can't get the one test skipped <efraim>I think there's issues in that whole file, but upstream discussions are mostly about it only affecting the test suite and their try-all-the-options flags <efraim>I'm actually going to just disable the test suite for go on aarch64, everything I've test built with it has worked fine <rekado_>ss2: what binaries are you looking for? Many executables are in /libexec of the gvfs package. <ss2>rekado_: uh, good question. :) I think I just confused it with gio-* utils. <ss2>gvfs, dbus, gio, and the whole gang are mildly confusing. <ns12>I notice that I have ~/.guix-profile/share/emacs/site-lisp/subdirs.el even though emacs is not currently installed. Is this normal? <jpoiret>Kabouik: dev packages don't exist in Guix, since headers and library files are part of the same package, it's other distros who artificially separate them <jpoiret>sometimes, when there are binaries, or heavy library objects or whatnot, you can find 'bin' or 'lib' outputs <jpoiret>but more often than not, the library package is enough <jpoiret>ns12: you can `readlink -f ~/.guix-profile/share/emacs/site-lisp/subdirs.el` to find out where it comes from <ns12>jpoiret: /gnu/store/pnvgz4mwnvynrjdyck3djz497hpjhrsz-emacs-subdirs/share/emacs/site-lisp/subdirs.el <ns12>"emacs-subdirs" is not a package however. <ns12>jpoiret: What does that mean? Why is it present even though I don't have emacs installed? <jpoiret>you can find the definition of the hook at line 1143 of guix/profiles.scm <jpoiret>iiuc profile hooks are always run and do not depend on a package being present <jpoiret>maybe they could be run conditionally, but they're pretty cheap imo <efraim>there are some that can be conditional but that one is really "cheap" <efraim>I also have it, with two packages listed <ns12>It seems to set an environment variable "EMACSLOADPATH". <ns12>... which disrupts the use of an Emacs version that is not installed using Guix. <jpoiret>in the meantime you could unset EMACSLOADPATH <ns12>jpoiret: Was that caused by a recent change in Guix? <jpoiret>are you sure that you don't have emacs installed in your profile? (`guix package -I`) <jpoiret>that's the only way I can see EMACSLOADPATH getting set by the profile <ns12>"guix package -I | grep emacs" returns an error code of 1. <jpoiret>\a: looks like GCC 9 added that warning/error flag <jpoiret>ns12: how about `guix size $(readlink -f ~/.guix-profile) | grep emacs` <ns12>"/gnu/store/pnvgz4mwnvynrjdyck3djz497hpjhrsz-emacs-subdirs 0.0 0.0 0.0%" <jpoiret>yes, so I have no idea why the profile would set EMACSLOADPATH. Can you double check that there is a related line in ~/.guix-profile/etc/profile? <jpoiret>\a: I think the easiest would be to update the vboot-utils package to latest <jpoiret>do you think you could manage? If not, feel free to open a bug report <awb99>shoudl a guix home reconfigure re-install packages? <ns12>jpoiret: There is no "export EMACSLOADPATH=..." in ~/.guix-profile/etc/profile. <jpoiret>ah, so it's not the profile that sets it :) <ns12>I will try to logout and re-login to see if that fixes the problem. ***utkarsh181 is now known as utkarshsingh`
<ns12>Same problem even after logging out and logging in again. <ns12>Maybe I could solve the problem by uninstalling Guix. <jpoiret>what do you source exactly in your .profile (eg .bash_profile, .zprofile, etc)? <jpoiret>if the profile doesn't explicitly export EMACSLOADPATH=, then it's not the culprit <jpoiret>I wish there was a way in bash to track where env variables are set :) <ns12>jpoiret: Okay. I'll investigate in more detail. Thank you for your help. I'll ask again if I encounter anything weird. <rekado_>if any of you has some time to help me understand something about cmake I’d be very happy <rekado_>our tensorflow package uses the cmake-build-system <rekado_>we’re building a whole bunch of stuff in the 'build phase and then proceed to install things in the 'install phase. <rekado_>however, the 'install phase takes about as long as the 'build phase <rekado_>and it looks like it performs some of that work a second time <rekado_>is this … expected? or is the package definition doing something silly that would invalidate the previous build phase? <Kabouik>Thanks jpoiret. I still face issues trying to compile nnn (I know there's a package, but I need special compilation options). make, ncurses and readline are installed. <jpoiret>you don't need to install any packages to work on something, you have `guix shell` for that <jpoiret>i'd suggest (especially if there is a package already) running `guix shell -D nnn` <Kabouik>I am not familiar with guixx shell, I'm checking it <Kabouik>I think it fails, the shell closes itself immediately. I'll try after installing the nnn package first. But while it installs, I noticed the "building profile with xx packages..." step of `guix install` takes very long. I think it's taking more than 5 min with just 55 packages in my case. <Kabouik>Same after installing nnn, I'm confused with guix shell <Nazar>Hello there, does anybody know how i can start the notification-daemon as dbus service ? <Nazar>mannually i can trigger it like that /gnu/store/s8yizsqn07y9pg7141b9gmb8aa0rkj6f-notification-daemon-3.20.0/libexec/.notification-daemon-real <Nazar>and its's work as expected, but how i can put this into config ? <rekado_>Nazar: is there a corresponding dbus service file? <rekado_>so there’s nothing installed to the package’s etc/dbus-1/system.d directory? <Nazar>yes it is missing there, as i;m using EXWM as my window manager, so i need to provide it by my self <rekado_>too bad. There’s only a .desktop file. <Nazar>org.freedesktop.Notifications.service <Nazar>Name=org.freedesktop.Notifications <Nazar>Exec=/usr/lib/notification-daemon-1.0/notification-daemon <Nazar>i there a posibility to define services to dbus ? like avahi (dbus-service (list avahi)) <rekado_>Nazar: you could add a simple package that installs just this file to the etc/dbus-1/system.d directory of its output. <rekado_>and then you add that package to the list of the dbus-service. <awb99>I am seeing a very old package in my store that should long be gone. I have done guix system delete-generations and guix home delete-generations and then guix gc. <awb99>Is there any way to find out why this package stays on the system? <rekado_>the Exec line obviously would have to be created from an input to your custom package <Nazar>i have tried like that (modify-services <Nazar> (dbus-root-service-type config => <Nazar> (dbus-configuration (inherit config) <Nazar> (services (list notification-daemon)))) <rekado_>Nazar: this doesn’t work, because that package doesn’t provide a service file in etc/dbus-1/system.d. <rekado_>you’ll have to provide a package that does <Nazar>okay, thank you, will try then <rekado_>awb99: yes, you can use “guix gc” to find references <rekado_>Nazar: it’s also worth considering whether this should be added to the notification-daemon package directly. <rekado_>this would make configuration for everyone much simpler, and it’s a pretty small change. <awb99>thanks rekado. would this be guix gc --list-dead? <awb99>I think I found the culprit. I have to delete-generatiosn both for package and home. <awb99>I am a little surprised by this, as home can install packages. <awb99>iis it recommened to install user defined packages in home? <awb99>or shold this be done via packages? <jpoiret>it's up to you, but i think guix home-installed packages should be much cleaner <Kabouik>Does guix shell work through ssh jpoiret? I'm logged into a distant machine (the Guix machine) right now and I'm trying to figure out why guix shell -D nnn doesn't allow me to compile nnn <jpoiret>it launches a new shell with the necessary dependencies <Kabouik>I'm still facing a linux/limits.h: No such file or directory, when trying to compile nnn <Kabouik>Uh, that seems to be related to me trying to use `sudo make install` while I should only be using make install in a virtual environment of course <Kabouik>Damn, guix shell is awesome, no more cluterring of my system with header files. <Kabouik>How do I check if I'm in a guix shell or not, or if there are other open? Are they deleted when exited and/or when rebooted? <Kabouik>Yeah I'm not used to let go sudo yet! <jpoiret>Kabouik: it's your own system, but i suggest never running `make install` or similar <jpoiret>Kabouik: you can look at the $GUIX_ENVIRONMENT env var, which will point to a profile in the store if you are in a guix environment/shell <jpoiret>guix shell internally simply uses guix profiles, which end up in the store like (almost) everything else in guix, so it will be reaped if not used when using `guix gc` <jpoiret>which can be a bummer if you plan on using that `guix shell` often, in that case i recommend using `--root=<gc-root-filename>` to register a gc root for that profile. you can look up what gc roots are in the manual <jpoiret>if you want to use a modified package, you can simply modify the package definition (either by using your own checkout of the guix source code, which can be a bit unwieldy, or simply by inheriting the initial package in a .scm file and then using `guix build/package/shell/... -f your-package.scm`) <jpoiret>it might look like a lot of information at once but once you get used to all of this you'll be even more delighted :) <Kabouik>You're right jpoiret, I'm just use to other distro's paradigm, and that led me to accept a lower vigilance level when compiling from sources. I just make install programs I truste. With guix shell, this isn't necessary anyway, I can compile in a shell, then ln -s thebinary to my ~/.local/bin for instance <Kabouik>Good tip about GUIX_ENVIRONMENT, thanks <drakonis>i forgot now, but there's a way to include variables into the environment when installing a package, yeaH? <Kabouik>I'd actually prefer deleting those shells/profile jpoiret, I'm not a dev and just compile when upgrading stuff, or occasionally when I try to contribute. Nothing that prevents me from recreating the shell when needed. But I guess I could still make one "permanent" with most frequent dependencies like ncurses and such. <jpoiret>well, it's entirely up to you again, but personally i just run `guix gc` when i notice i'm running out of space <Kabouik>Re: modifying package definitions for my own preference: that looks very interesting, but indeed a bit overwhelming. Typically I'd just need to apply a .patch file to nnn sources and compile with an extra option (O_CTX8=1). <jpoiret>well, that's exactly what it would be used for! <Kabouik>How does guix gc recognize what is actual garbage? It just freed 1GB for me and I don't really know how it filtered. <drakonis>garbage is anything that isnt being currently used by profiles or generations <jpoiret>Kabouik: the GC knows which store entries are being used by gc roots (typically your profile/system generations), or running programs, and deletes the rest <Kabouik>Nope! My first experience with lisp (common lisp, but for a moggle like me it's close to guile) was when I started using Nyxt, and configuring it is still hard! <jpoiret>but you can manually register your own gc roots to prevent something from being garbage collected <jpoiret>ah, well, I would have sent you a snippet, but it might look too cryptic if you're not used to lisps/scheme <Kabouik>And if I happen to have concurrent versions of one package installed, can I decide what to prune? <jpoiret>you can't really have concurrent versions of one package installed (they would conflict in the profile), but you can have multiple versions of one package in the store <Kabouik>I think I could understand a bit guile, but it's hard to me to understand special chars like #, ', or to discover commands (or are they arguments?). And in the case of package definition, it's not clear to me where to store my custom changes and take them into account for future package installations. <jpoiret>the GC would just remove anything that is not being used by any live profile/system generation <Kabouik>That's what I wanted to say about verions, but I used the wrong words. :p <jpoiret>you don't need to worry about the GC, it will only remove things that you shouldn't be using <jpoiret>Kabouik: rather, the GC will never remove something that's in use, it's literally impossible (unless there's a bug of course). No toggle or "manual way" out of it (the store is even mounted read-only, so you can't rm -rf unless you remount it) <Kabouik>I guess I could add other `string-append` there to add my compile option, and probably change the version so that it always pulls master <drakonis>It isn't quite recommended for packages in the mainline repository <jpoiret>yes, although you should always point to specific commits, never a ref that moves around, since guix forces reproducibility <jpoiret>although there's something around that lets you do that anyways <drakonis>but it is very possible to write some code to get around that <Kabouik>You're both referring to the same trick I guess <lilyp>nckx: Don't worry, I only stopped responding because the bus to work leaves early <Kabouik>But even writing the commit hash manually would be fine <lilyp>Perhaps I'll take it to guix-devel later <Kabouik>I just need (1) to add a step to patch source files, (2) add a compile option (I think I know how), and (3) understand how to edit/store/call this custom definition with guix install. <jpoiret>Kabouik: you don't need patching steps, as patches can be included in the (source ) record easily <jpoiret>you can look at examples in the sources, for example with `guix edit gdm`, which has a bunch of patches <lfam>Security bug disclosures for djvulibre ^ <jacereda>is it possible to have hardware video decoding with nouveau driver? <jgart>Does anyone know/have an example of the recommended way to splice inherited package-inputs with the new style? <jgart>(inputs (list foo bar (package-inputs baz))) <jgart>In other words, should we be using a helper function to flatten the list that results from `(package-inputs baz)`? <jgart>Or, is there some other way that I'm not noticing? <lilyp>PotentialUser-78: Depends on what upstream considers the source of truth. If it has a dedicated release page that serves tarballs not generated by github, use that. If it's just git tags, then git-fetch is to be preferred. <jgart>ahh, I had seen that in others code <jgart>Looks like what I need is modify-inputs composed with append. I just need to add a few inputs to the inherited ones. <awb99>I have roots in current-guix guix-home and guix-profile <awb99>I dont understand why I have 3 guix roots for a user now. <lfam>Your paste shows that 3 different profiles: "current-guix", "guix-home", and "guix-profile" <awb99>I jsut ran guix home "guix home delete-generations" and "guix package --delete-generations" <awb99>I thougth that most of this profiels are deleted <lfam>These correspond to 3 different things: Your `guix pull` profile, your Guix Home profile, and your "default" profile of installed packages <awb99>I am using home and package, <awb99>guix pull is the system wide profile ? <lfam>`guix pull` upgrades Guix itself, including the command-line tool and the set of available packages and services <lfam>And it uses the "current-guix" profile <lfam>The system-wide profile is found at /var/guix/profiles/system <awb99>I am doing the guix upgrades via sudo on a user, <awb99>so I guess this is why I see this profiles in my user profile. <awb99>Do you know how I can remove this old profiles? <awb99>I thought delete-generatiosn will remove them. <awb99>My real issue is that I have a lot of old packages that dont get removed from the store. <awb99>I have 200 gig of packages that should not be there. <lfam>When you do `guix package --list-generations`, do you see those old profiles? <lfam>For looking at the guix pull generations, you can use `guix package --profile=$HOME/.config/guix/current --list-generations` <lfam>That's how you specify other profiles besides the default profile <awb99>the profiles do not appear on guix package --list-generatiosn <awb99>guix package --profile=$HOME/.config/guix/current --list-generations <awb99>this command lists a few of them. <awb99>but I think I have way more in the gcroots <lfam>For the profile generations that are listed with the `guix package` tool, I recommend deleting them using the tool <lfam>For the others, you can delete them with `rm` <lfam>But, be careful that you only use `rm` for these profiles that are "lost" <lfam>It's definitely weird that they got lost <lfam>I wonder what went wrong <awb99>guix package --profile=$HOME/.config/guix/current --delete-generations <awb99>This sorted out my issues :-) <lfam>In case you didn't know, you can also delete them by how old they are <awb99>I still am lost why this profiels were there. <lfam>`guix package -d 2m`: delete generations older than 2 months <awb99>but it seems the syntax -d 2m does not work for home. <lfam>And also `guix package -d 101`: delete generation number 101 <lfam>I haven't tried home yet, so I don't know <awb99>So it seems that my "sudo guix pull" ends up in the user profile of the gc roots. <lfam>Yeah, that's what I would expect <lfam>When you do `sudo foo`, you do it as your own user <lfam>If you want to "act as root", you have to do `sudo --login foo` <lfam>What `sudo foo` does is "run foo as me with privileges" <lfam>But, it doesn't make you root <lfam>On other distros it doesn't matter <awb99>would you run the guix pull then rather with "sudo --login root"? <lfam>But Guix uses these distinctions to set up the per-user package management <lfam>Remember, `guix pull` is per user. That means that each user have their own Guix and they can manage it independently <lfam>So, what command you use depends on your goal <awb99>if I run a guix pull as one user, <awb99>then the other user woudl not see the updates... <awb99>But once I runn guix system reconfigure, <awb99>then everyone will see the changes <awb99>but only as root user, right? <lfam>On Guix System, there are two levels <lfam>The user can install their own packages with `guix package` and they have their own version of Guix with `guix pull` <lfam>There is also the system level, which provides the kernel, the system services, and any packages specified in config.scm <lfam>When you run `guix system reconfigure`, it uses the version of Guix that is used by *whoever* is running the command <awb99>when you say guix, do you mean the state of the guix packge repositories, or do you mean the guix app/daemon? <lfam>So, if you want to know which version that is, try running `guix describe` in the same way you will reconfigure <lfam>The Guix app *is* the repository <lfam>`guix pull` upgrades Guix itself, including the command-line tool and the set of available packages and services <lfam>So, try `guix describe`, `sudo guix describe`, `sudo --login guix describe`, and pick the version of Guix you want to use for reconfigure <lfam>To use your own users Guix for reconfigure: <lfam>`guix pull && sudo guix system reconfigure ...` <awb99>so sudo --login guix describe, this gives me the status of the operation system ? <lfam>No, it gives you status of root <lfam>Root =/= operating system <lfam>Root is just another user <awb99>and guix user is operating system? <lfam>`/run/current-system/profile/bin/guix describe` <-- OS Guix <lfam>But, you won't use it very often <lfam>Try `which guix`, it's probably your Guix from `guix pull` <jpoiret>FTR, the guix daemon is run as part of the system configuration, so it is updated only on `guix system reconfigure`, and it uses the guix version from that invocation <awb99>thanks so much for this expaination Ifam <morgan>In the guix manual it says to make a swap file using `dd if=/dev/zero`. Does the swap file actually need to be zeroed? It takes a while for large swap files and I'm wondering if we could suggest fallocate instead <jpoiret>not all fses support fallocate iirc, but that's an alternative for sure <rekado_>nckx: FYI: I started an rsync process to copy from /var/cache to /mnt_test/var/cache. <rekado_>we just got 5TB more on /mnt_test, so I think it makes sense to continue copying. <rekado_>the rsync over the internet probably should use the data at /mnt_test instead of /var/cache, as the former is much faster <morgan>Anyone know why my gpg isn't decrypting stuff for me anymore? Probably my fault but idk if there's a bug going around or something. <lfam>That bug was fixed in the last couple days <lfam>Basically, if you are using GnuPG 2.2.30, symmetric encryption and decryption will not work <morgan>I start gpg-agent by using the gnupg variable in my home.scm. It seems I'd have to change the variable I'm using to the new one. Although maybe gpg-agent should be a herd service thingy anyways... <lfam>For me, gpg-agent starts itself when needed <lfam>Like, I don't run a service for it <morgan>Well I have an ssh-agent that talks to gpg-agent. idk if the ssh-agent would start itself <lfam>Anyways, the bug should be fixed when you update your gnupg package <lfam>And yes, if you are specifying a particular package variable, you'll need to change it to use the gnupg-2.2.32 variable <morgan>Well I don't really want to do that because then I'll have to change the variable back in the future when the gnupg package is updated proper. I'll look into gpg/ssh agent stuff and maybe guix service stuff (but that scares me a little) and see if I can't find a better solution. *tissevert goes away mumbling <jacereda>If I have a ~/src/guix checkout, do I still need to deal with channels or should I just have no channels and use that checkout? And if so, how can I checkout the latest commit that has already built by the CI and available in the caches? <morgan>jacereda: I'd recommend reading the "Running Guix Before It Is Installed" section of the guix manual if you haven't already. When running guix from your git checkout it won't have access to channels. If you want to use channels you always add "-L path/to/channel" to your command. <jacereda>morgan: that seems oriented towards development, which I intend to do sooner or later, but I was wondering if channels are redundant when you have a checkout. On NixOS I used to get rid of channels and point NIX_PATH to my git checkout, I was wondering if the same is possible/usual on Guix <morgan>So are you trying to save bandwidth by pulling updates from local git repositories instead of from online? <jacereda>my approach was then to visit the hydra builds and update the checkout to the latest built hash to ensure a `nixos-rebuild switch` would find everything in the caches, probably there're better ways to do that though <jacereda>morgan: no, I just find it somewhat confusing to have 2 places defining the packages, if I want to visit the sources for a package I don't want to be wondering which one am I visiting... <jacereda>I mean, before checking out the sources M-. on emacs was showing me the sources for some symbol from the channel, now it's showing the ones from the checkout because I changed geiser-guile-load-path. If I´ <morgan>are you currently using channels? I'm wondering if the nix terminology is different from the guix terminology because I am royally confused right now. <jacereda>I'm visiting some symbol I'd like to be sure that's the definition I'll use in my config.scm <morgan>oh ok I think I understand your question now but it doesn't involve channels at all :P <jgart>Is there a way to search for packages filtered by a custom guix channel? <jpoiret>sneek, later tell mothacehe: I'm nearly done implementing a per-installer `run-command`, with configurable line-hooks: you can chose what to do with each line of the output, ie giving it to syslog and displaying it, be it in newt or in the tty. I'll try figuring out how to buffer and handle refreshing in newt properly next, but it should be good <jgart>Or even something like the following would be nice: `guix show -L . '*'` <morgan>guix pull and git pull are kinda similar. Both will just grab the latest commit and I don't think there is a good way to wait on CI but I could be wrong. Guix has a builtin way of pulling up package definitions by using "guix edit". So you can do "guix edit emacs" to see the definition of emacs that the installed guix has. <jpoiret>sneek, later tell mothacehe: Also, do you think a parameter (run-command-in-installer) is good enough? I don't really see how we could pass the installer-specific procedure down to the steps. <jgart>The above command is executed in the custom guix channel's root directory <jpoiret>jacereda: we have a built in switch to `guix pull` to the last built commit i think <jpoiret>in any case, you can just do `guix pull --commit=<SHA>` to pull the commit you want. You can check the CI to see which commit good for you (remember to `--allow-downgrades` if you need to) <jacereda>morgan: so "guix edit" will show whatever the particular commit in the channel has, and that could be different to the commit I have in ~/src/guix, that's what I'd like to avoid by having a single source of package definitions <jpoiret>jacereda: you can do `./pre-inst-env guix edit`, which will bring up the one in your checkout <jacereda>jpoiret: that switch doesn't seem to be present in --help <jpoiret>yes, I haven't managed to find it. But I seem to remember something of the sort <morgan>Maybe what you want is `cd ~/src/guix && git pull && guix pull --url=~/src/guix` <morgan>that would keep the local install and repo in sync <jacereda>morgan: that would work if there's some way to specify that url in an environment variable or something <jacereda>that's what NIX_PATH was for, there's probably something similar? <jpoiret>if the only thing you want is to be able to pull to a specific commit, no need to locally check-out, you can just use --commit <jpoiret>otherwise, you could have a channels.scm file whose url points to file:///the/path/ <jpoiret>if it's in .config/guix/, it would be automatically used by guix pull <KE0VVT>I do "guix home reconfigure", but it does not install the packages declared. <morgan>See the manual section "Using a Custom Guix Channel" to configure the default guix channel url <morgan>No problem :). I got confused because when people talk about channels they are usually talking about extra channels they've added, not redefining the existing one. <jgart>Is there currently a way to list all the packages defined in a single module? <KE0VVT>guix system: error: aborting reconfiguration because commit 6b01be8b04c95fed164fd6b154a2fa58548e4d73 of channel 'guix' is not a descendant of b891f8519dbea5457d9ad154974b1ab1459b4b8b <KE0VVT>rekado_: I don't mess with the defaults. <KE0VVT>rekado_: I did "sudo guix pull" and "sudo guix system reconfigure config.scm". ***blendux is now known as blendo
***blendo is now known as blendux