<bdju>is there any way to enable full disk encryption without reinstalling guix system? I'm getting a new drive soon but I kinda wanted to just clone it to save myself some fuss. otherwise I was thinking if I did a fresh install on it I could enable FDE and then copy data over afterwards somehow
<vagrantc>you could "guix system init config.scm /path/to/mounted/encrypted/filesystem" and manually do all the cryptsetup commands to mount /path/to/...
<vagrantc>but you have to be pretty confident in failure recovery skills ... might be a bit tricky to get everything right and might have to try a few times
<vagrantc>but using "guix system init ..." should copy much of what you already have installed, so shouldn't have to re-download or re-build much of anything
<bdju>as far as packages go I just have a few in config.scm and then a bunch in my manifest so that'd probably give a fairly barebones system
<bdju>so in that scenario would I format the new drive and set up luks on it before anything else? for some reason I was imagining I had to go through the guix system installer again and let it handle things for me
<bdju>another question, if I do just do a fresh install on the new SSD and then mount the old one over USB and copy stuff over, will I run into any issues like keys or IDs not matching stuff? how much can I copy back over? what about my store? would I just want to copy over my home dir and let the rest be built fresh? has anyone done something like this lately?
<bdju>and inside the installer can I grab my config.scm from elsewhere to apply it right away or should I just use what the installer gives me and then modify it later?
<vagrantc>bdju: you can either do it manually or reinstall through the installer ... kind of depends on what you're confident with work :)
<kennyballou>what am I doing wrong to specify a mirror and luks container on the mirror for install? I'm specifying the mirror exactly as the mapped-devices documentation. However, after unlocking the drive in grub, I get "invalid argument" after stage one(I think) attempts to assemble the mirror. I started with the /etc/configuration/desktop.scm as a start and filled in the mirror and updated the luks uuid to match.
<kennyballou>does grub need to be built with something extra to read the raid? Or does the raid need to be constructed with the metadata at the front? eg, --metadata=1.0?
<SeerLite[m]><ngz> "I see 0.10 was released." <- Alacritty 0.10 requires a newer version of glutin than what's on Guix ;_;
<SeerLite[m]>Should I package a new glutin version or bump the existing one?
<SeerLite[m]>How do you all keep track of all this versioning ;_;
<eonn>I've been thinking about setting up separate profiles for suites of things that are related. e.g. all my emacs packages, and then a profile for all my x11 related packages, etc. Is this the right way to be thinking about profiles?
<dumbdemic[m]><SeerLite[m]> "dumbdemic: `getenv` procedure" <- Cool that works, thanks!
<Ribby>With one computer as bridge, one usb-ethernet adapter, and few ethernet cables, the installing computer would have no problem getting updates/upgrades on a public network. And probably as acceptable behavior in public.
<Ribby>It's probably just me, but I don't see myself buying internet before buying a non OS computer with a guix usb in hand. However, computers usually come with OS already.
<Ribby>Back to public networks, if the updates/upgrades makes the GUI and other user friendly terms, the question would be "Now, how would I get to a accessible network?" It is technically up to the user's responsibility, but it could be a very creative process. Almost like a text adventure game.
<vagrantc>Ribby: that seems like a very general question and a bit off topic for #guix
<vagrantc>Ribby: i mean, it's fine to mention it, but to keep bringing it up after it's already been worked out
<Ribby>I thought that maybe someone would like to know the theory than a hypothesis. Libraries, wifi, and probably internet cafes would be potential sources. It's just a matter on how to remedy missing updates/upgrades during a Linux-like installation.
<vagrantc>Ribby: it's really pretty off-topic for #guix
<vagrantc>it's one thing to get help actually doing something like that with guix, but another to talk about the theoretical possibilities of bridged networking
<vagrantc>where theoretical is largely completely known and sorted out
<Ribby>I guess you can say it's more of a bootloader thing.
<vagrantc>Ribby: what do you mean when you say "bootloader" ?
<xelxebar>kitzman: I'm sure the Hurd would smile at any love you sent its way!
<kitzman>oh! that explains so much. i think i misread one of the other posts.
<kitzman>still, guix was what got me look into microkernels in the first place
<kitzman>the android project would be so much better with a microkernel for example, as well (better codebase)
<munksgaard>Good morning everyone! I'm trying to build a cabal (haskell) package that depends on z3. I'm on a foreign distro, but both cabal-install and z3 are installed with guix. I first had problems passing the right flags to cabal so that it could find the z3 include files, but I think I've gotten that to work. It also seems to be able to find the lib files, but now when I compile I'm getting undefined references to some GLIBC functions. I haven't
<munksgaard>installed glibc with guix, so it's not much of a surprise, since the distro-glibc is too old, but if I do `guix install glibc` a lot of other stuff seems to break. Does anyone know how to tackle these glibc errors?
<attila_lendvai>probably something like this: when skip-build is false, then the sources are not packaged, only the built binary (?), and if other packages want to import it as source, then they will fail.
<attila_lendvai>so, a bunch of the rust packages that i'm adding require rust-1.57, while the default is rust-1.54. how do i deal with this? shall i add a #:rust ,rust-1.57 to every one of them? that will mean maintenance burden in the future when the default rust is updated...
<attila_lendvai>i guess moving the default rust forward is not an option (without a world rebuild)?
<jbv1[m]>Hi guix! The interoperability of guix package manager and julia package manager still needs to be improved. Julia keeps on upgrading some minor dependencies, it makes it quite hard to understand why an environment stops working suddently, until one realizes that a cairo wrapper has been replaced... I'm thinking maybe a guix-julia package with a function that users can run which automatically checks for decrpencies. thoughts ?
<mbakke>attila_lendvai: rust 1.57 is the default as of current master
<gnoo>how do you package a git-package ? like something you're supposed to always build on master
<attila_lendvai>mbakke, damn, thanks! i was a few days behind, and i thought that shouldn't matter... :)
<ennoausberlin>Hi. I want to create my first own channel. I created a git repository to store it and now I want to declare it in a file. There is a hash parameter to (make-channel-introduction ... Where is this hash coming from?
<xelxebar>abrenon: Yeah, I see a similar error. I'm guessing that time-machine only pulls in the official guix channel, so when you do describe, the variables defined in your profile that come from non-official channels are chocking.
<abrenon>ahhh, good point, describe is not that innocuous
<xelxebar>A sharper tool might be to use the -C flag to time-machine.
<abrenon>but wait, why did it choke for the build ? other channels weren't needed in that case ?
<abrenon>yeah, -C is what vldn suggested and I'll try that
<xelxebar>Not sure. What was the other command that choked?
<johnhamelink>Hey folks, I'm running Emacs out of guix foreign (I plan on slowly building my guix config to the point where I can swap to using guix as my OS). The cursor on Emacs is almost entirely black - is this something I can change with guix and if so what should I read up on? I am very new to Guix so please excuse me if what I'm asking is obvious?
<jpoiret>pinning dependencies to a specific version as well (such as in golang) is also a curse
<nckx>SeerLite[m]: You cite a rather special case, since bash is often an implicit input, which are currently hard to address 😉 In general, I'd say no, use #$(this-package-input "bash") instead. This will in effect look it up in the inputs list, as assoc-ref used to do, which is generally what you want.
<jpoiret>"oh, you actually want to use a 4 yo version of a dep because you never took the time to update your code to work with the newer version?" "well, no security/bug fixes for you then"
<jpoiret>vendoring is what caused the log4j vulnerability to be this hard to patch
<jpoiret>one thing i wish languages would not do is try to do package management by themselves
<attila_lendvai>jpoiret, importing/duplicating golang's build system and packages, and making a mistake in the process that then results in miscompiling an app... is also a curse. i don't see any good solutions here.
<jpoiret>attila_lendvai: duplicating packages is basically what we're doing, that's cjust packaging for a distro
<jpoiret>there are upstream projects that are packaged downstream
<attila_lendvai>jpoiret, sure, but golang and rust probably has more packages than the rest of guix... :)
<jpoiret>the issue is because the languages think they ought to take over package management, people have started shipping smaller and smaller packages that 1) don't do much 2) aren't updated
<jpoiret>and people think it's cool to have a lot of them as dependencies
<jpoiret>attila_lendvai: i wouldn't say that's a meaningful metric
<nckx>The fix has to be in addressing the fundamental design mistakes in Cargo/Go/etc. That seems… unlikely, but ‘just keep the broken tools, it's less work in the short term’ is not a reasonable answer.
<jpoiret>nckx: i think upstream should keep escape hatches, like manual builds and external dep managament
<jpoiret>well, I have tried packaging a professionally-made go app (proton-bridge), and among the dependencies that I had to add, way too many of them were more than 5 years old, deprecated/unmaintained, some of them were very simple utility functions
<jpoiret>all in all, it's just a better reason to work on those importers :)
<nckx>vldn: Hm, the more I read, the more of an ‘interesting edge case’ it sounds 😉 ‘GPLv3’ … ‘allows you to stream games from your Windows gaming machine’ … hmm. IMO there has to be a reasonable way to use this to stream a libre game from a libre system to another libre system, without proprietary ‘driver support’ or whatever, for it to belong in Guix. But this should probably be discusse
<nckx>gnu-build-system is (especially was) the good-old-fashioned-gnu-bootstrapped-tarball-build-system. Less so now, but it still assumes a ‘release’ tarball by default and lets you add the autotools only when needed.
<zimoun>Yes, but it is weird to try something which cannot be successful, all by default
<zimoun>especially when the manual is not clear about that, IMHO.
<nckx>patch-shebangs will patch, e.g., python shebangs *if* python is an input, but it won't abort the build if it python's not an input and it encounters a python shebang.
<nckx>The gnu-build-system also runs ‘configure && make’ by default, both things that will certainly fail if you don't have the right inputs. I really don't see a difference.
<apteryx>is it discouraged to use canonical-package?
<nckx>zimoun: If you find a good place to document it, that sounds like a better ‘fix’.
<nckx>Other build systems like to inherit from gnu- (dunno about 'bootstrap specifically) so not sure where that would be.
<zimoun>nckx, I agree. My point is about implicit inputs with the build-system. I do not list python when I select python-build-system. Why do I have to add autoconf and automake to the gnu-build-system? Especially when it runs a phase requiring them.
<nckx>Because they are very seldom needed and the phase almost never runs.
<nckx>Lots of packages fail the 'configure phase when pkg-config is missing. We still don't add pkg-config to every g-b-s package.
<zimoun>I am surprised that a phase fails because tools are not in the implicit inputs of the build system.
<nckx>homeostat[m]: Look into, e.g., ‘guix pull --delete-generations=1w’ and ‘guix package --the-same’. They will break GC ‘roots’ (old references) so ‘guix gc’ can remove more trash. If that still frees far too little, LMK, maybe there's another one I forgot.
<nckx>zimoun: I feel like if this exact same thing happened it 'configure you'd be fine with it and add pkg-config or gettext whatever and be totally fine with it. You wouldn't try to add both to the implicit inputs of *all packages*. 😛
<zimoun>nckx: Since the phase is almost never used, it would make more sense to me to have #:bootstrap? #f by default, and when I would do #:bootstrap? #t, I would understand that I would have to add more inputs. As we do for #:tests?
<nckx>That's just making users jump through tedious hoops.
<nckx>The use case for #:tests? is different. And it's not even #f by default, so I don't get the comparison at all.
<nckx>zimoun: Now they have to add another magical keyword in addition to the inputs, to get the same behaviour as before. It's artificial.
<nckx>It's a regression, too. Instead of ‘autoreconf is missing’ (in the horrible ‘127’ secret code, but I suggested fixing that above), users now get ‘no configure script’. Then they have to know to add ‘#:bootstrap? #t’, *and* they still have to add autoconf/make. Nothing is gained, but more work is needed, and the error is nearly identical.
<homeostat[m]>nckx: Great that seems to have cleared a good quarter of the space. Probably good enough, thanks!
<nckx>Less than I expected TBH but glad you're happy.
<homeostat[m]>Well there's still 14.4GB in .links. Does that sound reasonable?
<nckx>Guix deletes nothing by default. Every action is append-only apart from ‘guix gc’. So unless you have a lot of space, you'll want to occasionally run it.
<nckx>homeostat[m]: .links should be as big as the rest of /gnu/store, all files in .links are hard links to files in /gnu/store.
<nckx>So don't count them as using additional space.
<nckx>I think du is clever enough to know that if you point it at /gnu/store, but more primitive tools might not.
<zimoun>nckx: I do not understand. What you are proposing to catch the error and instead display: «add autoconf and automake in native-inputs». What I am proposing is to add #:bootstrap? and why not extend the list of implicit inputs when it is #t.
<nckx>I think there's an optimisation now to not hard-link tiny files because it's not worth and actually degrades performance for little gain, so that might account for the difference.
<homeostat[m]>Great! thanks so much, really helpful. I shall guix gc every so often from now on
<nckx>But .links is all just pointers into /gnu/store, using very little storage (almost none).
<nckx>homeostat[m]: Run the commands I gave above before you do so; Guix is very conservative in what it will delete otherwise. Conversely, running those commands will break roll-backs to generations older than a week (or whatever you choose), so that's the trade-off.
<nckx>Can't have infinite roll-backs without near-infinite storage :)
<nckx>zimoun: Would you propose the same change if there weren't two siamese-twin packages (autoconf/make) but only one you needed to add?
<homeostat[m]>oh i get it. Being hard links Disk Usage Analyser, which I was using, considered it to be an extra 20G, but actually that's just because it contains hard links to all the generations in /gnu/store! I think I've just understood guix a little better!
<nckx>Well, it's not a crucial Guix concept, just an implementation detail to save some space, but it's always nice to gain 20G of (perceived) space completely for free! 😉
<zimoun>nckx: yes, I think. In any case, any improvement is a world-rebuild, so it is for later. ;-)
<homeostat[m]>nckx: Makes sense! I wonder if it would be helpful for useless people like me who have not digested guix as well as I should to have guix package say something about using guix gc once in a while? Just an idea.
<nckx>zimoun: Interesting, I thought maybe you were trying to save a line. Now I really don't understand which advantage you see, but that's all right, I'm just me. Don't wait too long to discuss it if you want to make the next rebuild 😉
<nckx>homeostat[m]: Guix (I can't say off-hand which subcommands, or all) will warn you if it detects ‘little free space left’. You must not have hit that threshold yet.
<zimoun>nckx: “too long” depends on the next core-updates cycle. ;-)
<jpoiret>imo, current-guix should always refer to the current guix package, while the `guix` package could only refer to major versions, but I don't have any knowledge wrt Guix bootstrap so that may be completely bonkers
<jpoiret>we could make it so that the install image always uses the current-guix, which would make testing guix changes in a vm much more manageable (unless I'm missing something, as right now I've been mounting the source inside the VM and using ./pre-inst-env there)
<apteryx>nckx: it maps a user exposed package to a package used implicitly by the gnu build system.
<apteryx>(that's my high level understanding of the thing)
<nckx>apteryx: Thanks for the attempt. It's not your fault it still won't just click 😉
<nckx>I mean, I almost get it, I just don't grok it.
<vagrantc>any compelling reason not to update guix? on aarch64 it was fixed in master a while ago, but hasn't been updated since, so guix-daemon fails to build on aarch64 ? i think basically the patch applied for https://issues.guix.gnu.org/52943 just needs an updated guix with that commit
<civodul>jpoiret: ok, i don't get your question then :-)
<vagrantc>civodul: i won't have a chance to test on anything other than arch64 at the moment ...
<antlers>zimoun: as I understand just from peeking at the commit that was mentioned, package/inherit will cause a package to inherit it's parent's replacements, where as the usual inherit field/mechanism doesn't extend to a package's replacements (when using eg. grafts, transformations?)
<jpoiret>wdyt about adding that code to (current-guix) rather than in the installer?
<antlers>zimoum: the field is present in all package records, but isn't usually inherited because it's marked as innate
<antlers>I dug a little deeper, and see that where the usual mechanism inherits from a package without considering it's inmate replacement field, package/inherit will inherit from either it's parent *or the replacement of it's parent* if present
<podiki[m]>recent breakage: wine-minimal fails somewhere between c9f9e78 and 4d7a997
<podiki[m]>from the git log not sure what could have done it
<apteryx>mbakke: I guess it sadly should be left disabled, to stick to the package's motto "with some functionality disabled in order to protect the users privacy"; leaving door open for Google would be a precedent.
<podiki[m]>though wine just had big update to 7.0 that might be better to do (should have less 32bit dependencies too, if I understand correctly)
<_73>How can I import a module that comes from a channel? For example I would like to use a service definition from rde which I have set up as a channel but I cant figure out how to import the module into my scheme file.
<antlers>zimoum: I may be going too far in, but once again, there are more details: the returned package inherits from it's parent, with any overrides applied to it, wether said parent has a replacement or not; when it does, said overrides are also applied to it's replacement, which is returned in the replacement field of the new package- effectively inheriting from the present replacement, but specifically via populating the replacement field, so I see that
<antlers>vldn: according to the blog post from it's release, guix pack is meant to be more like an application image, so you probably ought to use guix copy for your purpose
<podiki[m]>nckx: I don't really know the wine internals, but their release notes talk about not needing to install 32bit libraries at some point (still need them, but less so I guess) to run from 64bit
<podiki[m]>in our packages eventually that would mean no more wine/wine64? i'm not sure, but at least things seem to be converging
<podiki[m]>found the libratbag problem, it was that meson doesn't propagate python anymore (other fixes the last few days)
<nckx>podiki[m]: What the release notes mean is that they no longer link to ELF (‘Linux’) binaries, they build their own PE (‘Windows’) DLLs (or equivalent) from source. The binary package inputs are hence useless here. If you build Wine you'll notice that it runs perfectly if you delete every single input mentioned in the notes.
<nckx>It's not that it needs them less, it both doesn't need them and still does but uses its own copies. But it's not lazy bundling either. It's complicated.
<nckx>The only argument beyond unthinking reflexing ‘durr bundling bad’ would be grafts, and I'm a bit sceptical grafts would actually work the way we expect them to across a virtual OS boundary.
<nckx>(Did I test that assumption? No. Testing it would require implementing the whole thing, a lot of work.)
<jacereda>Anyone got Pipewire desktop capture working on Sway? I get: [4800:4800:0119/201758.043616:ERROR:base_capturer_pipewire.cc(746)] Failed to create a screen cast session: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop
<lilyp>I'm pretty sure grafts didn't work with Wine even before the PE thing
<nckx>I thought you brought it up 😛 As long as we both agree it's irrelevant all is good.
<lilyp>My main claim is "we have been building Wine PEs for a while"
<apteryx>mbakke: I tried enabling the hang services in chromium just for the kicks, and couldn't share a screen either. Perhaps relevant in the output: [2212:2212:0119/143403.799942:ERROR:context_group.cc(184)] ContextResult::kFatalFailure: ES3 is blocklisted/disabled/unsupported by driver
<lilyp>Possibly relevant side claim: "We're not grafting Wine for the foreseeable future."
<nckx>Which is triviall true, but (neutral) ‘so what’?
<nckx>I can't imagine Wine not containing PEs since day 0. It's kind of the point.
<lilyp>I simply thought there were technical issues with the 7.0 upgrade related to PEs
<nckx>Ah, no it did finish eventually. I mean it was noisy but ‘functionally identical’ all that differed were hashes and addresses, but no symbols were lost by removing inputs, they were already unused.
<nckx>podiki[m]: Yeah, I was not complaining, all the work it did was real. Nice objdumps. Very dumpy.
<lilyp>because of the way floating point arithmetics broke between processors, Microsoft was unable to correctly implement it for a while
<nckx>Yes. Which I just realised is a no-no here. I literally use it only to test Wine, because I feel like it's a more ‘interesting’ test than rendering text fields, and I don't have any other Windows software.
<johnhamelink>nckx: sorry to ask a potentially silly question, but is there a code of conduct for the mailing list I'm about to send to? I'm unsure if it's good etiquette to attach screenshots or not and want to check before bothering people.
<PotentialUser-28>To answer myself: nope. I tried with another image that included nonguix, same problem.
<f1refly>lilyp: I don't think so, and when I look into the resulting store path there's only a /share/cargo with the source there
<nckx>I agree with lilyp but that's when people send clearly in-screen screenshots of their desktop terminal…
<nckx>for some reason that is a thing that happens.
<johnhamelink>nckx: thank you! Just trying my best to be courteous - I don't have much experience with mailing lists so I'm not sure what normal looks like!
<lilyp>In case it's on a foreign distro: I recently found out that Guix' GSettings are actually divorced from your distro's GSettings. So chances are you just have to install the cursor themes through Guix as well as configure them and it ought to work fine.
<lilyp>Note that I haven't tested this hypothesis myself yet, I only did fonts so farr.
<johnhamelink>lilyp: yeah that might be the case - I'm not far enough along in my Guix knowledge next to know how to do this idiomatically so I'm still pretty stuck at this moment in time. Given that this might *not* be a bug, would I be better suited mail help-guix instead?
<jacereda>Hmmm... font-service shouldn't be in %base-services, the selected font just sucks on hi-dpi monitors and the default one is perfectly readable.
<nckx>johnhamelink: Disable HTML mail if your client lets you, don't top-post if you remember not to, and you're already doing great. To vaguely paraphrase someone: if you're even *wondering* if you're being an arse, you're very unlikely to be one. (It's not fool-proof but it's a good filter 😉)
<johnhamelink>nckx: Ha! That made me chuckle :D I'll be mailing with mu4e, which I am beginning to fall in love with :) I had no idea what top-posting was until I duckduckgo'd it just there haha
<nckx>jacereda: It's not about readability but about coverage. Without it you're stuck with an extremely limited CP437 character set. It should be possible to rewrite the service to query the console size and choose a ridiculous (e.g. 16x32) font based on that, but it would require a rewrite.
<apteryx>rekado_: I'm curious; in your past bazel packaging effort, had you looked at what Nix does? It seems they have it in their repo
<nckx>johnhamelink: mu4e++. It has the least annoying warts.
<apteryx>ah, but they fetch a bunch of java and other things, probably as binary seeds
<nckx>jacereda: That said making it %base is a judgement call I wouldn't personally make either. I don't use it myself.
<nckx>It was substituted from a build node that had already built it successfully, so I don't know what happened to cause the spurious failure.
<jacereda>is there a time limit for the jobs? Maybe it took too long to download and got killed
<nckx>It's hard to say. The truncated log was a genuine build log (it contained the output of unpacking the tarball until it was cut short), the ‘new’ log is just that of a substitution. So I don't think it was a download gone wrong.
<nckx>The failing build failed after 636 seconds IIRC, which is certainly no timeout we have.
<podiki[m]>hate to be a bother, but can anyone look at (and hopefully push) https://issues.guix.gnu.org/53372 (fixes failing test due to meson not having python anymore, prevents me from reconfiguring since I use the dbus files)
<podiki[m]>but now I see that doesn't fix piper, I think it needs the same python fix, and maybe no more librsvg....testing now
<nckx>So adding this to every consumer is the fix? Does every single Meson package require Python? Is there a pending patch for (say) c-u that addresses this in the build system? I'm willing to push it but I'm a bit lost.
<phf-1>Hello! So, i've 25 packages to add: https://paste.debian.net/1227741/ . I guess they are not that good quality wise (e.g. #:test? #f) in various places more by convinience than anything else. Where do I start from here? To add them if that's of any value?
<lfam>phf-1: If there are things in your packages that you would identify as "not that good", then add code comments explaining why they are like that. Or else it will discourage people from reviewing your patches
<nckx>My :) earlier was meant as a hint but I got distracted before I could follow up.