IRC channel logs
2024-02-16.log
back to list of logs
<lispmacs[work]>just curious, is there anything that stops a system image from being garbage collected in the store? <lispmacs[work]>on a multiuser system, could somebody gc your image right after you built it? <lispmacs[work]>you could hardlink to the image right after you made it, I suppose <PotentialUser-37>there is an easier solution, see '--root' flag in "invoking guix system" in the manual <PotentialUser-37>basically creates a symlink to the file which prevents garbage collection of that item until the symlink is deleted <lispmacs[work]>okay, and only you and root can delete your own garbage collection roots <PotentialUser-37>You and whoever has write access to the directory containing the symlink <lispmacs[work]>hi, I'm not using Home right now, and was wondering how to delete the GC root for that <ryan77627>So I know this is definitely going to be a bit of a stretch here, but does anyone happen to use nix's home-manager with flakes by any chance? I use home-manager to augment my home profile when I am exceptionally lazy and don't want to package something myself, but switching to flakes has been troublesome and was wondering if anyone had experience... <PotentialUser-59>I installed Guix on a foreign distro. How do I go about "building" my config.scm into a bootable USB for a different system(that has no drives) to use? I tried following the Manual Install instructions but I don't have the cow-store service. <mange>PotentialUser-59: I would have thought that "guix system image config.scm" would produce an image that you can dd onto the USB? That's what "(guix) Invoking guix system" in the manual suggests. <PotentialUser-59>mange: how do I configure the partition scheme & filesystems with that approach? <mange>I don't know. I expect the image command overrides the file systems you declare in your config.scm, but you might be able to play with the partitions after copying the image. <mange>You might want to build with --volatile, as well, so changes you make when booted into the image persist. <mange>It looks like "(guix) System Images" in the manual talks more about the lower level details of this. It looks like you can define custom image types with different partition schemes, but I don't have time to help you with the details. <freakingpenguin>Hey all! Are the fingerprints listed in a .guix-authorization file the primary key or the signing subkey? <PotentialUser-59>Then just dd the 2G image to my drive, expand the root fs, and created a swap partition. I'll play with it some more, hopefully I can get `guix system image` to generate an image with a swap partition and expanded btrfs root filesystem. <ayatsfer>hello, is there any package containing just clangd? the clang package provides it, but I don't want to get clang or clang++ in my environment <civodul>sneek later tell snape re 0data, perhaps it should be marked as “hidden” instead of being kept private, so that ci.guix can pick it up (esp. the ‘disarchive’ and ‘source’ jobsets) <hako>Is it viable to preserve XDG_RUNTIME_DIR in ‘guix shell --pure’? For Wayland environment both WAYLAND_DISPLAY and XDG_RUNTIME_DIR are required. <snihil>When I do `guix shell -E WAYLAND_DISPLAY --pure bash -- bash` I can echo $WAYLAND_DISPLAY with the value I have <snihil>hako: I spoke too soon, it also seems to preserve other env vars... <hako>snihil: Wayland socket is at $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY so both environment variables are required. <hako>Yes, default variabes to preserve (for --pure) are defined in %precious-variables (guix profiles) <sneek>Welcome back snape, you have 1 message! <sneek>snape, civodul says: re 0data, perhaps it should be marked as “hidden” instead of being kept private, so that ci.guix can pick it up (esp. the ‘disarchive’ and ‘source’ jobsets) <erikeah>good morning guys on another day! I hope everything is going well! <erikeah>I'm packaging a package which needs libcrypto, the lib is found on the openssl and libressl (and I expect to be in another tls providers, however this will need more testing <erikeah>My question: How can I set as input any of this packages and let the user use whenever is installed on their system? W <erikeah>I mean: If I already use libressl then use it and do not use openssl, on arch packaging system I remenber I hade the provides attribute which abstract this behaviour. <erikeah>Thanks hako, I think is what I was looking for! Huge thanks! <andreas-e>erikeah: Strictly speaking, it is not possible: Guix completely fixes all the package inputs instead of randomly using what it finds on a machine when running a program. So the only solution is to create two packages. This is what package transformations actually do. <snape>avalenn, it's stuff you need to build the package, and then you don't need it anymore <avalenn>snape: yes, but the word "native" just put my brain in some confused mode <avalenn>it's "native to the builder machine" and not to be used on the target <snape>avalenn: to the machine that builds the package <avalenn>but using it very rarely I cannot remember that <snape>it matters more when building for different architectures <avalenn>I will try to wire my brain to remember "native = build-time" <erikeah>andreas-e: thanks for clarification, I will give a try. <hako>`guix build ... --target=aarch64-linux-gnu` on x86_64-linux, then native-inputs are x86_64-linux, inputs and propagated-inputs are aarch64-linux <andreas-e>erikeah: Do you know more about these TLS libraries? At some point in time I thought libressl would replace openssl, but this does not seem to have happened. <erikeah>However It appears to be an improved version, I think <erikeah>This is not enough to use it because openssl has probe be enought good to do the job... so why change? <snape>is there some sort of "do-not-apply" tag? <snape>that we could add to patches that don't apply <snape>well that discussion is so big... <ulfvonbelow>what's the proper way to refer to an origin from within a phase gexp? <ulfvonbelow>presumably "this-package-native-input" wouldn't work? <lilyp>you can inline the origin into the phase, but I'd prefer search-input-file/directory or load paths <ulfvonbelow>(search-input-file inputs "qoedrnwpqdurnwqdoerwnqdrpwu-package-name-1.0.zip") just doesn't have quite the right ring to it <rekado>ulfvonbelow: it’s a missing feature. I’d like to either match on suffix or ensure that the file ends up in a directory so I can search it. <rekado>for cases like this I usually dust off the old labelled inputs style <rekado>or if it’s just the one input I sometimes get away with using “_” as the input name. <ulfvonbelow>speaking of missing features, I wish we had call-with-temporary-directory in (guix build utils) <civodul>funny how we always end up with avoid religious analogies <rekado>this time the original text actually includes the religious analogy <graywolf>Hi, I am trying to modify a bug, and I am getting an error: Failed to set submitter on 63707: can't find location for 63707. <janneke>possibly religion is safer than politics these days... <rekado>futurile: I mean the blog post on wingolog, not the Guix-HPC report. <rekado>graywolf: what did you send and where to? <futurile>I tried submitting the HPC report to Hackers News - I don't have much karma on that site - more of a wall-flower <rekado>I submitted it too, but it’s stuck at its initial 1 point ¯\_(ツ)_/¯ <graywolf>rekado: submitter 63707 MY-EMAIL to control@debbugs.gnu.org <graywolf>And I got: Processed (with 1 errors): control message for bug #63707; with the error I pasted above <rekado>I’m a little annoyed by the “Yeah, yeah, nice and all, but … have you tried Nix?” comments on *every* Guix submission on HN. <rekado>it’s got big Baden-Wurtemberg energy <aldum>>A common misconception is that we somehow don't like systemd. <dthompson>and "guix is built on top of nix so just use nix" <aldum>shame, because that's a killer app imo <dthompson>developing shepherd was absolutely the right choice for guix <rekado>aldum: we can choose not to use systemd and be entirely indifferent to systemd. <rekado>the decision does not require a dislike of systemd, that’s what I mean <dthompson>can't tell is aldum means shepherd is good or not lol <rekado>(I’m probably just an old fart, but software rarely makes me feel anything.) <theesm>the sentiment on HN that one must have strong opinions on systemd because of a preference for a different init system is so weird to me <aldum>I don't have strong opinions on shepherd, but it being not systemd (and the ugliness of nixlang) is the reason I'm here, and not there <dthompson>that assumption works out a lot of the time, but not for guix <dthompson>funny how andy can just quickly blog about a new laptop and bam! guix discussion on the very top of hn <janneke>yeah, what's he ever done for guix? /S <dthompson>no one cared when I blogged about my new thinkpad a year ago ;) <janneke>yeah, or when i blogged about installing guix on the pinebook <dthompson>if a gnu project reuses anything suddenly it's a fork that just removes the nonfree parts <dthompson>sometimes I wonder if just *everything* is misunderstood because I work with/advocate for so many misunderstood technologies <rekado>dthompson: to be fair, there sadly *are* quite a few such projects, so it’s not a simple misunderstanding. <dthompson>yes, again it's not an assumption without reason, like the anti-systemd thing <rekado>I see that this IRC discussion has gone off the rails. We really should be discussing this question: have y’all tried Nix yet? <janneke>rekado: i heard you can install in in guix system <lilyp>speaking of systemd, there were at least some efforts to package it, but I think someone would have to redo those <rekado>I heard they forked Guix because they are against the FSF. <lilyp>Well, Microsoft forked the FSF because they are against Guix. <rekado>I heard Microsoft released their own version of Guix that capitalizes (heh) on a common misspelling of Guix <futurile>dthompson: just so you know - I really enjoy all your blog posts - I promise to try and promote them on HN if you do some more?! ;-) <lilyp>really nice of them to encourage typosquatting <dthompson>I have a pile of potential blog posts that I need to get around to writing <dthompson>but lately all the blogging I do is for the spritely blog <lispmacs[work]>hi, a while ago I created extra profiles under .guix-extra-profiles, following the tutorial. Now I want to delete them, but I don't know how <lispmacs[work]>I mean, I sure I could delete that directory, but how to make sure the GC roots are deleted also? <lispmacs[work]>I'm looking through manual, but seem to be missing the part explain how to delete profiles and roots, outside of your default profile <lispmacs[work]>i can delete generations from a profile, but I do not know how to delete the whole profile, and I think package will not let me delete the last generation from a profile if there is only one left <apteryx>lilyp: any idea why on core-updates building pstoedit requires -lpangocairo-1.0, -lpango-1.0, -lgobject-2.0 and -lglib-2.0 ? These seems to be picked from the newer imagemagick .pc file <lilyp>Well, I don't know about core-updates, but the same ones appear to already exist in current imagemagick <lispmacs[work]>no guidance on deleting profiles? I see here the great "Guix Profiles in Practice" tutorial but I don't see info on how to delete profiles you don't want any more <lilyp>e.g. if you store it in $HOME/.extra-profiles/my-extra-profile, just delete that <lilyp>it'll be found to be dead in gc IIRC <lilyp>extra profiles don't end up there, that's one of the many flaws of how they're currently hacked together <lilyp>just do a plain old gc and they're gone, basically <lispmacs[work]>I can see them listed in /var/guix/profiles/per-user/christopher <lispmacs[work]>hmm, I see not all of them are represented in /var/guix/profiles <lilyp>/var/guix/profiles only has current-guix (guix pull), guix-profile (guix package) and whatever guix home uses <lispmacs[work]>I deleted one, but I see it still listed in guix gc --list-roots. but I'll try running gc and see if it goes away <andreas-e>Did you not see the "removing stale gc roots" text or something like this? I also thought it was automatic, as lilyp said. <lispmacs[work]>finding some forum links on the internet, where people were told just to delete the profile path and that didn't work for them either <andreas-e>I just gave it a try, and removed one of the links in /var/guix/profile/peruser/xxx, then "guix gc". It did free a lot of stuff. <lispmacs[work]>I found that original profile link had another link to it somewhere else. Maybe I just have to delete that one <lispmacs[work]>okay, yes, now that all the links are gone, it recognized it as a stale link <dissoc>what is the directory for %user-log-dir with regards to guix home? i see it in the service definitions but i never see the path defined <dissoc>never mind. i see it in (shepherd support) <lilyp>dissoc: %user-log-dir ought to have been deprecated some while ago – XDG_STATE_HOME is the hot thing to customize <podiki>jpoiret: how goes core-updates? there's a point release for mesa v24, so I was going to put that plus some related updates (i think i saw libdrm at least) on mesa-updates, but maybe i should wait for core-updates? <dissoc>lilyp: in (shepherd support) %user-log-dir is (or (getenv "XDG_STATE_HOME") <dissoc> (string-append user-homedir "/.local/state") <podiki>and a question for mesa is if we try to build the nvk driver, which needs rust. i suppose we should, though it'll just be on x86_64 probably? <lilyp>dissoc what I mean is that there was a similarly named variable in guix home – but with the xdg-whatever-variable-service-type you ought to be able to set XDG_STATE_HOME, which will also set your shepherd log dir <podiki>lilyp: i see you had added a meson/newer some time ago. can that just be updated to latest version of meson without lots of rebuilds? (guix refresh suggests just one dependent but i don't think that can be correct) <lilyp>It has only one dependant as far as I know. Most stuff builds with good ol' meson <podiki>meson 1.3.2 built just fine locally; might be needed if i want to enable the nvk driver in mesa <lilyp>since mesa is its own branch anyway, you might want to update meson to 1.3.2 there or on c-u <podiki>i was hoping for once to not do an entire world rebuild on mesa-updates :) <podiki>ah civodul had ungrafted meson on core-updates but just to 1.1.1, I wonder if there was a reason or just didn't check for a newer version <podiki>what is the proper procedure when building guix locally and hit errors on various .texi files erroring on "nonexistent node"? <podiki>i usually delete a bunch of stuff in docs and reset, but i'm always guessing <nlongitude>guix system has a lot of kernel versions (5.4.268, 4.19, etc), but i'm confused as to how to pick the older one i would like in the system config. could someone let me know? <nlongitude>oh, whoops, i can just say (kernel linux-libre-5.15) -- didn't realize that from the docs. silly me <lispmacs[work]>I'm a little confused why, when I build an image guix guix system image, why that it has to download GBs worth of packages. The OS I declared is basically subset of the one I'm already using <lispmacs[work]>like, why does it have to download nano-7.2 again, when it is already installed <futurile>lispmacs[work]: it should only download something once into the store - you probably know that each package is basically the name+hash of the package. It might be that there's a slightly different set of dependencies which causes the Guix daemon to download a different version of something you have. <lispmacs[work]>futurile: that must be it, but still seems strange - same guix pull, and subset of the same packages <lispmacs[work]>I wonder if the location of files (in the new system image) is somehow a dependency of everything else <andreas-e>lispmacs[work]: This may be due to grafts. In the end your profiles contain the grafted packages. But when you do a "guix gc", all the non-grafted packages, which are themselves not installed, are deleted. Then when building a profile with the same packages again, the system downloads the ungrafted packages again and grafts them. It cannot know that the grafted packages are already there. <andreas-e>So it is recommanded to use "guix gc" sparingly, or together with the -C and -F option, if you can afford the disk space. <snape>well the problem with shepherd is the guile dependency <snape>would be great that systemd is supported too <futurile>andreas-e: oh that's really good to know - and now makes me regret doing a giant guix gc yesterday! <snape>(it's a problem because it makes minimalist systems big) <ieure>Would be nice if guix gc was better behaved in these situations. Seems like grafts are going to be a thing forever (though hopefully/maybe less of a thing than they are now), so it'd be good if it dealt with them better. <andreas-e>It would be nice if you had more frequent ungrafting (and then rebuilding) sessions. <iK0u>Is the install.scm expected to be reproducible to match cuirass? Or the 1.4.0 release with time-machine? I am failing to reproduce it and I also tried guix pull with --bootstrap and it fails with " <podiki>currently the situtation is pretty extreme, due to glibc and lots of other grafts. core-updates will resolve that, but agreed we should do this more often <iK0u>ERROR: In procedure scm-error: <iK0u>ERROR: no code for module (srfi srfi-71) <podiki>(i did a bunch on mesa-updates before, but still many left) <iK0u>Am I failing to reproduce the install.scm based iso because I am not using --bootstrap? <iK0u>Or am I running the wrong commmand (using guix system image -t iso9660 gnu/system/install.scm) I am on the correct commit as well, with the same source checkout <apteryx>snape: can you elaborate on why depending on guile is a problem for shepherd? <snape>apteryx: because guile's closure is big, which doesn't fit embedded systems <iK0u>Extra info: the errors I posted above were in the log for the "module-import-compiled" step of guix pull --bootstrap, both for a recent commit and for the 1.4.0 release <apteryx>snape: I disagree. Guile's closure is not big. Embedded these days often means a 64 bit core with 2 GiB or more of RAM. <apteryx>guix size guile -> 135 MiB. That of Python is 226.3 MiB, as a comparison <apteryx>also ridiculous things I've seen in the "embedded" domain: docker containers and electron apps! <dthompson>natively compiled guile would greatly help here <jpoiret>podiki: there's one last hurdle I didn't expect, but I don't really know how to go about it <jpoiret>guix uses Guile's crypt function, but for that guile needs to be built with libxcrypt now, which we haven't built that early! (it does need some non-trivial dependencies) <podiki>i see. depends on python. and thus things like libx11 and so on <dkxr>yo wassuop guixx , are there any twitch alternatives that are based on the gpl thought? <yelninei>is the issues page having issues? The last bug/patch is from last sunday. <snape>dkxr, twitch.tv alternatives? <iK0u>Has anyone managed to succesfully reproduce the 1.4.0 release iso? What commands did you use if so? <snape>apteryx: bash-minimal closure is 76.3 <dkxr>podiki: thanku my dude, it does seem that peertube is the only decent at the moment <snape>dkxr, peertube isn't really an alternative to twitch, as it can't do live right? <dkxr>i guess im gonna start supporting peertube, it needs to grow <iK0u>This build in curaiss shows "/gnu/store/q7xxllkmy6zr7nlk7b0vscjd75rdb8yv-image.iso" as the output <iK0u>However, checking out the same commit and cd to the source directory, and running guix time-machine --commit=b13d6c5715b71c4499ce37ef3968e4216125a5ed -- system image -t iso9660 gnu/system/install.scm produces a different output <iK0u>Even if done via guix pull to that commit instead of time machine <iK0u>I ran this also in a vm, I do get the same output both times but not the same as the cuirass one? <iK0u>Could anyone else try this and share the output? <jpoiret>podiki: no, the python dependency can be removed, but there's pkg-config and some others which are annoying <apteryx>snape: what's your point about bash-minimal vs bash-static? this doesn't really have anything to do with the closure of guile (you could use busybox if you wanted) <apteryx>jpoiret: our gnu make already depends on pkg-config <apteryx>it uses its own local variant to avoid the cycle <podiki>jpoiret: maybe ask on guix-devel if you haven't already for what we can do. i would guess prefer not to keep older cryptographic libraries if it can be helped <lispmacs[work]>hi, I created an image with guix system image. What is the default password for the user? <podiki>i believe no password, need to use root to set one <podiki>(which has a blank password i believe) <rekado>people tell me that they don’t receive emails from debbugs <rekado>combined with the report about issues.* looking stale I wonder if there’s an outage on the gnu side <jackhill>Is it possilbe with the image API to create an image with a btrfs filesystem in an LVM volume? <podiki>rekado: i had no issues with debbugs or mumi on...wednesday? i think