IRC channel logs

<clemens3>on a fresh guix install in qemu with a cow2 image or what, then what? any url for further docu e.g. how to install xorg or what? just asking for a friend

<clemens3>i like the bsd approach to after install just do a "man afterboot" or "afterboot", i forgot, to just get started, in case you don't know what this is about..

<clemens3>the old chicken and egg problem

<clemens3>so how to get started

<clemens3>and don't get me wrong, because i am not afraid to fail, because, you know, there are a bunch of other options out there

<clemens3>guix doesn't know about the poweroff command?

<clemens3>so how do I shut the damn thing off gracefully? never mind if you don't tell me, i find a way:)

<clemens3>X

<clemens3>kill -9

<Noisytoot>clemens3: sudo herd halt

<clemens3>herd? what does that stand for?

<graywolf>clemens3: GNU Shep*herd*, https://www.gnu.org/software/shepherd/

<clemens3>ok, thanks

<nikolar>also there's shutdown

<apteryx>Noisytoot: hi! thanks; could you please file an issue so we don't forget about it?

<apteryx>(a simple mail to bug-guix@gnu.org)

<Noisytoot>Done.

<mwette>Hi all, for static-networking issue (#64653) where herd reports failed networking startup, are there any workarounds. This is causing other daemons (e.g., ntpd) not to start becuase they depend on networking.

<mwette>s/not to start/not to be started/

<daviid>asking here as well, did ask in #guile, because someone in #fsf told me guix has a matrix room somewhere - gnome irc channels are dead, they use matrix - but i can't find a descent matrix server, anyone uses/knows one that respect privacy? the fsf has none, unfortunately, the fsfe has one but is member only ... tx

<daviid>*descent as in privacy respectfull, no unacceptable identity nor terms of use assignemts ... thanks

<jacobk>Also, the "Group:Guix" page at <https://libreplanet.org/wiki/Group:Guix> links to app.element.io which will in some circumstances (registration) send nonfree JavaScript to the user for Google reCAPTCHA. It seems to me like there should be a note about how to avoid nonfree software if visiting that link, since it does not work at all with LibreJS. Or, maybe the link ought to be removed entirely.

<jacobk>I would have edited the page to remove the link, but it seems like I don't have permission, even when logging in with a FSF member account.

<apteryx>daviid: there is still 171 people in #gnome, not sure how there were before the bridge was stopped

<apteryx>I don't use matrix, sorry

<apteryx>Noisytoot: thanks!

<daviid>apteryx: no one answer any quiz in libadwaita nor in introspection anymore, just gtk, and yet, only one dev really uses irc, they are all gone :)

<apteryx>pity

<jackhill>I've had luck getting questions answered on discourse.gnome.org

<Noisytoot>My MTA has delivered the email but it hasn't appeared on the mailing list yet. Probably because I haven't sent from this address to bug-guix@gnu.org before.

<jackhill>daviid: I guess this is off topic for here, but you could also use an XMPP <-> Matrix bridge like the one hosted by aria-net.org.

<daviid>jackhill: i'll look into this thanks

<jackhill>daviid: cool. I beleive FSF associate members still get XMPP accounts

<rdrg109>[Q] How to call a function from a module that has not been exported? (I'm asking this question on the basis that unexported functions from modules can't be called, please correct me if I'm wrongW)

<unwox>rdrg109: see https://www.gnu.org/software/guile/manual/html_node/Using-Guile-Modules.html#index-_0040_0040

<rdrg109>unwox: Thanks! This works: (@@ (gnu home services fontutils) home-fontconfig-service-type), but this doesn't work: (@@ (gnu home services fontutils) config->sxml). Do you happen to know what I'm doing wrong?

<rdrg109>Although the function config->sxml is defined in gnu/home/services/fontutils.scm, I get this error: config->sxml: unbound variable

<unwox>rdrg109: i don't really know, sorry

<bumble>rdrg109: the function must be exported

<rdrg109>bumble: Yes, a function must be exported in a module for it to be called. If the function is not exported, how to call such function? The manual mentions that @@ can be used in this scenario: https://www.gnu.org/software/guile/manual/html_node/Using-Guile-Modules.html#index-_0040_0040

<bumble>rdrg109: I see. Sorry I do not know.

<civodul>Hello Guix!

<cbaines>morning o/

<civodul>cbaines: you posted a nice draft blog post about QA some time ago, but then i lost track of it

<civodul>is it ready for publication?

<cbaines>I did get around to updating the draft, so I think it should be publishable

<civodul>cool, would be great

<cbaines>does mcron support running a job as a particular user?

<civodul>yes

<efraim>cbaines: https://www.gnu.org/software/mcron/manual/html_node/Guile-Syntax.html looks like there is a 'user' field

<cbaines>efraim, ah, thanks, I thought I tried to search that page, but obviously I missed it

<efraim>I searched for 'user'

<civodul>there’s another example at https://guix.gnu.org/manual/en/html_node/Scheduled-Job-Execution.html

<rdrg109>unwox, bumble: I found a solution for the question I asked before. Here you can find more info: https://lists.gnu.org/archive/html/help-guix/2023-09/msg00034.html

<euouae>Hello

<euouae>On the graphical installation last step, when you're offered to edit the installation script, I deleted the word "cups" from it (1 instance)

<euouae>Then the installation failed. Is this normal? I just tried to install without editing and it succeeded

<PotentialUser-36>Hello guix. I need some advice for best practise. I have an application that I can install with guix (package definition, services etc.) For a single use case this application needs to talk to an ML-Model running inside a Docker container. The OS in docker is Ubuntu (due to a more recent version of tensorflow). So the Docker container is a

<PotentialUser-36>dependancy of my application. Is there a way to specify the build from Dockerfile and run it when installing the app or is it better to do this manually beforehand?

<Altadil>euouae: did you delete it from the use-module field at the top ? What error did you get ? It’s probably that you had cups or a related package/service in your config (I guess - I’m no expert ^.^).

<euouae>Altadil: I may replicate to keep the error message.

<euouae>Altadil: (use-service-modules cups desktop networking ssh xorg) that's where I removed it from

<euouae>in /mnt/etc/config.scm

<Altadil>euouae: Is there a specific reason why you removed cups ?

<euouae>I thought cups had something to do with printers

<euouae>which I don't use

<Altadil>oh ok, yes it does, but then the cups module might still be required for one of the things listed in the OS declaration (the rest of the file, basically)

<euouae>The reason I'm not attempting to replicate the error right now is because I'm on a slow internet connection and it takes a while

<euouae>That makes sense Altadil.

<Altadil>If that’s good enough for you, you can remove cups now that you have done the install, no need to redo it.

<Altadil>it should give you the same error message

<euouae>"Unless you’re using Guix System, the guix install command must have printed this hint: "

<euouae>I get this hint even though I'm running Guix System. Why is that?

<euouae>Isn't Guix System the system that comes with the iso? that you can install?

<zamfofex>euouae: Well, it is careful to say “if you’re not using it”, so if you are, it’s probably not relevant to you.

<zamfofex>Also, hello Guix! I’m currently working on <https://issues.guix.gnu.org/63088> I have done what I mentioned on the issue: I added multiple packages for various Lc0 networks. (I also put them all in a new ‘gnu/packages/lc0.scm’ file.) They all use a common procedure that returns a package record since they are very similar. Do I really need to add each package in a different commit?

<euouae>zamfofex: If I read the sentence correctly, the hint shouldn't be printed on the guix system, but it is printed

<zamfofex>It is just saying “in the case you’re not using Guix system, the Guix installer might have warned you about this”. But since you are running Guix System, then the message is not relevant to you, and you might have not been warned during installation.

<zamfofex>This is how my ‘lc0.scm’ file looks: <https://paste.debian.net/plainh/caf8ea7d>

<zamfofex>cc lilyp, since you are actively helping review my patches.

<jpoiret>euouae: if the warning *is* relevant to you, it'll be printed again on the next `guix` invocation iirc

<euouae>It seems to be printed jpoiret

<euouae>but how can it be relevant? I installed the guix iso in a virtual machine

<euouae>furthermore, now I'm getting `/var/run/utmp: No such file or directory` when exiting GNU screen

<euouae>I'm just reporting things as I see them... I don't know if they're known issues or not

<jpoiret>what locale are you using?

<euouae>LANG=en_US.utf8

<jpoiret>what does `echo $GUIX_LOCPATH` print?

<euouae>it prints /run/current-system/locale

<euouae>Under $GUIX_LOCPATH/2.33/ there's a lot of *.utf8 directories

<euouae>e.g. en_US.utf8. there's also en_US.UTF-8 which is the only directory with name *.UTF-8.

<jpoiret>ah, you guix pulled right?

<jpoiret>you'll need to reconfigure your system

<jpoiret>you probably are using glibc 2.35 now but the system still only has 2.33 around

<euouae>I didn't guix pull

<jpoiret>what's `guix describe`?

<jpoiret>if you haven't guix pulled then i recommend doing just that instead

<euouae>guix 8e2f32c

<euouae>OK jpoiret, thank you

<euouae>I suppose it makes sense. If I'm outdated I may be seeing issues that are no longer around

<jpoiret>and then reconfiguring your system and updating your packages

<jpoiret>yes

<euouae>yup

<euouae>Sorry -- it's my first time on a functional deterministic package manager

<jpoiret>we don't support past point releases (however silly that sounds)

<euouae>jpoiret: I'm interested in guix for development (of software in general). Is there any interesting resources for this? I think the guix blog is a good one

<euouae>But I'm a bit slow to grasp some concepts, e.g. how channels/environments could be utilized for software dev. If it's illustrated in an article, it'd be useful to me

<jpoiret>there's https://guix.gnu.org/en/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/ but you've probably already read it

<euouae>ah thanks

<graywolf>Hello Guix :) Why is guix derivation being computed even if the pull did nothing since there are no new commits? Seems wasteful. Is there a reason?

<jpoiret>graywolf: yes, to create the derivation to build guix, Guix first needs to resolve the dependencies of Guix in the guix pulled code. That code is not compiled yet and so takes a long time to load.

<jpoiret>that step isn't substitutable, because it's in the process of creating the derivation

<graywolf>But the same work was done on last pull no? I don't fully understand why it needs to be re-done

<graywolf>Just to repeat that: The upstream commit did not change, so it seem the exact same derivation could be used, since I assumed everything is described by the commit.

<graywolf>Are there some environment factor (date, ...) that could cause the guix derivation to differ despite being on the same machine from the same commit?

<euouae>non-deterministic builds

<euouae>?

<cbaines>graywolf, even if the output for that guix is in the store, the derivation needs computing to find out what the output is

<cbaines>some Guix commands do cache this, but not all

<graywolf>Ah, I see. So there there it no mapping stored for commit-hash -> guix derivation, so it need to be recomputed every time. But it is not a fundamental requirement (to do so), it *could* be cached. Correct?

<graywolf>there is no mapping*

<cbaines>yep

<graywolf>Thanks, it is not exactly a priority (I do not pull without changes that often), but wanted to make sure I understand why it behaves like this.

<somenickname>Isn't one positive side effect of GNU Guix not having a FHS to stop malware from actually being able to run?

<graywolf>I would expect most malware to be staticly built musl binaries, so I am somewhat skeptical about that

<euouae>somenickname: that doesnt sound right

<somenickname>sure, only works for dynamic linked programs

<somenickname>Does someone know the progress of Emacs 29.1? I can see that Emacs branch got merged and some packages are now at 29 but not Emacs itself.

<jpoiret>somenickname: it's in the pipes, coming Soon™

<jpoiret>basically waiting for CI to work its way through the backlog

<somenickname>Ah perfect. Emacs 29.1 has ERC 5.5 which has SASL support

<Rovanion>graywolf: We need a kernel patch to only allow binaries built and signed by the Guix daemon.

<Rovanion>Making it completely useless for anyone wanting to run a normal computer :D

<euouae>Rovanion: this seems relevant <https://www.kernel.org/doc/Documentation/ABI/testing/ima_policy>?

<euouae>jpoiret: guix pull && hash guix && guix package -u did not seem to have an effect on GNU screen message /var/run/utmp: No such file or directory.

<euouae>guix describe gives guix 9996896

<apteryx>yay, magit now properly puts the trailers at the bottom of git messages

<efraim>How far along is the emacs branch? I'd like to change libgccjit to track the gcc version

<jpoiret>euouae: what abuout the locale problem?

<jpoiret>did you reconfigure and reboot?

<apteryx>is it possible in GNU Readline to abort C-r (recall history) without loosing the text I typed thus far?

<apteryx>e.g. when there are no good matches

<civodul>apteryx: probably, it’s super customizable (to the point few people customize it…)

<apteryx>ACTION reads info '(readline) Searching'

<apteryx>doesn't look to be possible out of the box

<apteryx>I mean via the stock behavior

<avalenn-42>Hello, is there any way to declare a package without source ? (or with empty source or with pure "local-file"ey source)

<avalenn-42>As usual I find my response 10 secs after asking

<avalenn-42>" (source #f) ;no source" as explained in https://guix.gnu.org/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/

<apteryx>what sets TZDIR on my Guix System?

<ulfvonbelow>civodul: have you had an opportunity to look at the v2 of my shepherd patch series?

<ulfvonbelow>apteryx: I believe /etc/profile, by sourcing /etc/environment

<apteryx>ulfvonbelow: thanks, it's hard-coded in the operating-system-environment-variables procedure, which ends up in that /etc/environment file

<apteryx>I think we should define the TZDIR search path in (guix search-paths) and use it on glibc and for other users

<apteryx>such as qtbase

<apteryx>so that it works in containers too

<apteryx>yep in glibc-2.35/time/tzfile.c it does: tzdir = getenv ("TZDIR");

<apteryx>it's not documented though

<apteryx>ACTION lines up qt updates for the qt-team with: ./pre-inst-env guix refresh -u -m etc/teams/qt/qt5-manifest.scm --target-version=5.15.14

<apteryx>ah fun, that's "released" but not actually

<apteryx>just for their commercial customers

<apteryx>so the latest is still 5.15.10

<apteryx>according to https://download.qt.io/official_releases/qt/5.15/ at least

<civodul>heh, wonderful

<apteryx>interesting, I stumbled on this: https://foundationdevices.com/

<apteryx>the hardware is apparently freely licensed

<apteryx>the integration (mainboard), I reckon

<vivien>Mmh https://gitlab.gnome.org/GNOME/gnome-photos/-/issues/214

<apteryx>ah, it's a bitcoin wallet. I mistook the hardware as some dumb and smart phone ^^'

<euouae>lol

<euouae>apteryx: I was about to say, it doesn't look that interesting

<civodul>cbaines: https://guix.gnu.org/en/blog/2023/a-new-quality-assurance-tool-for-guix/ \o/

<civodul>nice work!

<civodul>janneke: hey! i586-gnu builds were attempted and… it’s all 🔴: https://ci.guix.gnu.org/eval/latest/dashboard?spec=hurd-packages

<graywolf>For the channel authentication, one should specify a subkey fingerprint, not the primary key?

<civodul>graywolf: yes (which is arguably unusual)

<graywolf>Wait, but the original guix pull succeeded when I put the primary into the introduction

<graywolf>Only subsequent guix pull seems to fail

<graywolf>That is also expected or I fucked up somewhere?

<civodul>i was talking about the fingerprint in ‘.guix-authorizations’

<civodul>but should be the same with the intro fingerprint i guess

<civodul>now, there’s a local cache in ~/.cache/guix/authentication/

<civodul>so if you’re testing things, you might want to remove it

<graywolf>will do and test again, thx for the tip

<efraim>I can restart a few of the i586 jobs, I have some time

<graywolf>Hm, what is Guix trying to tell me: https://paste.debian.net/plain/1291757 ? I am not pulling from savannah, so why would it be stale?

<civodul>graywolf: you’re pulling from https://git.sr.ht/~graywolf/guix, which is apparently a mirror of https://git.savannah.gnu.org/git/guix.git

<graywolf>Also, channel introduction accepts the primary key fingerprint, while .guix-authorizations requires the subkey's. Bit weird. I will use subkey in both places.

<graywolf>civodul: There should be one extra commit, they should be diverged

<graywolf>But I take it that I can just ignore this warning then

<civodul>graywolf: in that case, if it’s a “fork”, you can change the main URL that appears in ‘.guix-channel’

<civodul>that’ll get rid of the warning

<apteryx>are search paths honored at the time of building the the consumer?

<apteryx>e.g. I added TZDIR on qtbase, and added tzdata-for-tests to its native-inputs, but when building qtbase, I don't see TZDIR being set

<apteryx>cbaines: neat blog post

<apteryx>thanks for this multi-year investment in bettering the Guix tooling

<graywolf>civodul: great, will do, thanks for the tip :)

<apteryx>'./pre-inst-env guix shell -D --pure qtbase' suggests search paths are not honored at the time of building the consumer

<ulfvonbelow>I wish there were a way of submitting a patch series from gnus

<ulfvonbelow>it'd be nice to be able to gpg-sign the patches themselves

<apteryx>you could do so with GNU Anubis, in theory (signing outbound messages)

<apteryx>I think the package is broken at the moment though

<efraim>sneek: later tell vagrantc I tried manjaro's alsa asound.state on my pinebook pro and I had working sound through my speakers and headphones

<sneek>Will do.

<efraim>sneek: botsnack

<sneek>:)

<efraim>ok, now to figure out how to add that into my OS config

<efraim>now that I have the sound working I've almost immediately muted it

<dthompson>I started drafting an email for that loooooong "How can we decrease the cognitive overhead for contributors?" but decided against it. I'll just say here that I 1000% support moving to a more modern patch review process. I have struggled to follow development for years because I'm not very active and email makes it very difficult to see what's going on whereas a forge makes it easy.

<dthompson>aaaaand of course it an obstacle for any new contributor who hasn't just chugged a glass of GNU kool aid

<vivien>I imagine there is a deep reason why we can’t have rust on 32-bit systems, right?

<euouae>dthompson: I also don't like e-mail contribs although I'm not a contributor in this project

<efraim>vivien: short version is mrustc needs too much memory to bootstrap on 32-bit systems

<vivien>Can’t we get away with an ad-hoc swap space?

<vivien>Gegl is starting to require a newer librsvg and it sucks

<vivien>it sucks in all the problems that we have with rust on 32-bit systems

<efraim>I don't fully understand how the memory limit works on 32-bit systems, but it's not something that swap (or more ram) can solve. it has something to do with one of the processes needing too much memory

<apteryx>vivien: if you want to help: https://github.com/thepowersgang/mrustc/issues/78#issuecomment-1267692031

<apteryx>maybe restarting a failed build could be enough

<apteryx>efraim: there's apparently a 2 GiB limit somewhere

<vivien>I don’t have a 32-bit system handy though

<apteryx>I think building with --system=i686-linux should do?

<efraim>i've tried it before, --system=i686-linux still triggers it

<euouae>Maybe running the build under valgrind massif will show you which part of the build bloats memory. or is that known? maybe that can be optimzied

<euouae>massif makes graphs like this <https://courses.cs.washington.edu/courses/cse326/05wi/valgrind-doc/date.gif> that show memory consumption

<efraim>there's a part where it generates a massive number of rust functions using something like lex/yacc and it balloons up to like 6 or 8GB

<efraim>its a good idea but it's not even close

<efraim>there should be room to split it into multiple parts but no one's taken the time to do it yet

<euouae>efraim: do you have more details on that?

<stikonas>I think 32-bit system is limitted to 3 GiB of RAM

<stikonas>that's 2^32 (4 GiB) - 1 GiB reserved for kernelspace

<efraim> https://github.com/thepowersgang/mrustc/issues/78 I think this is the one

<efraim>thanks stikonas

<stikonas>indeed, but I don't think tweaking options, etc is sustainable

<stikonas>there will be newer versions of rust later that presumably would need more memory to build

<stikonas>ideally, we should be able to use smaller compilation units, but I don't know how hard it would be to modify mrustc to do that

<euouae>first we need to figure out which part of the code is responsible for the memory consnumption

<stikonas>euouae: it's not mrustc that uses memory

<stikonas>it's gcc

<stikonas>mrustc is not too bad

<stikonas>but it produces huge C files

<stikonas>that are then compiled with gcc

<stikonas>and gcc runs out of memory

<euouae>possibly mrustc could split the C file into multiple?

<stikonas>possibly

<stikonas>but I haven't looked at mrustc code, so hard to tell how feasible it is

<stikonas>but that would be ideal option

<euouae>do you have the output of one such file?

<stikonas>not at the moment

<stikonas>but if you start running mrustc to build rustc, they'll be in build directory

<stikonas>but it's machine generated C, not really readable

<stikonas>C is just used as some kind of platform independent assembly

<euouae>the callgraph is what matters <https://github.com/koknat/callGraph>

<stikonas>actually I might have it

<euouae>if there's many root nodes, the C file can be split. if I understand what's happening

<stikonas>one momebnt

<euouae>s/many root nodes/many separate trees/

<euouae>or actually some other condition on the callgraph -- I've not spoken accurately but it's some characteristic

<stikonas>ok, I found it

<stikonas>though might not be the latest build of mrustc, but doesn't matter

<stikonas>e.g. here https://stikonas.eu/files/bootstrap/librustc_query_impl.rlib.c

<euouae>Can you 7zip?

<stikonas>oh yes

<stikonas>oh maybe xz

<euouae>I'm over a 400Kbps connection

<euouae>err KB

<stikonas>yeah...

<stikonas>we'll see how small compressed size is

<stikonas>might still be painful on 400 Kbps

<euouae>I could download a 1GB file, but it'll save me some time

<stikonas>done

<stikonas> https://stikonas.eu/files/bootstrap/librustc_query_impl.rlib.c.xz

<stikonas>now just 20 MiB, should be much better

<euouae>thank you!

<vivien>While trying to build rust for 32-bits, I get at the LIBS step:

<vivien>TTStream:0: error:0:Unknown architecture for asm!

<euouae>stikonas: on top of my head we can reduce memory simply by stripping comments

<euouae>because this 1GB file is ~30% comments

<stikonas>yeah, but that doesn't mean that GCC usage will go down by 30%...

<stikonas>it might be insignificant gain

<stikonas>not sure which stage uses most memory

<euouae>sure, the crux is to split the file

<stikonas>but I doubt it's preprocessor

<stikonas>ok, preprocessor wouldn't strip comment

<stikonas>but still, tokenizer is unlikely to use most of it

<euouae>these files seem easy enough to strip comments from by a simple sed commant

<hrn>Hi all! Is there a preferred way to append a line to a file in a package definition?

<stikonas>euouae: gcc should be able to do that much better

<stikonas>internet suggests gcc -fpreprocessed -dD -E test.c

<lilyp>zamfofex: your batches are fine by me, but note the replies to the patches

<euouae>stikonas: to strip comments?

<stikonas>euouae: yes

<stikonas>well, gcc already knows C syntax

<stikonas>so should be able to do more careful job than sed

<vivien>Anyway, the problem with mrustc for i686-linux for now is not with memory

<euouae>stikonas: it already stripped down to 290MB

<stikonas>yes, but the interesting bit is who much memory is used when building it...

<jackhill>lilyp: by the way, I tried building Dino on the gnome-team branch, and ran into a problem. It smells like an upstream issue to me, so I opened one, https://github.com/dino/dino/issues/1479 but FYI

<lilyp>nice catch

<jackhill>:)

<euouae>stikonas: yeah nothing sticks out, but I'd say I'm confident this file can be split into multiple

<stikonas>well, it probably should be done in some automated way from mrustc...

<euouae>Yes

<euouae>Could you start an issue in <https://github.com/thepowersgang/mrustc/issues> with how you obtained this file and some more details? Maybe someone more knowledgeable with the project can direct us to the processes responsible for this code generation and we can take a closer look and/or ask more about it

<euouae>I don't think I can solve this problem without collaboration from the mrustc devs

<euouae>& maybe they don't care, so it's good to ask before jumping in

<euouae>From <https://github.com/thepowersgang/mrustc/blob/master/Notes/ImprovedCBackend.md.txt> there is definitely interest in improving the quality of emitted C code

<euouae>"- Multiple codegen units"

<euouae>I'll ask myself in their github issues stikonas, see how that goes

<stikonas>euouae: well, it was just output from make...

<anadon>`guix install gnome-tweak-tool` and `guix search gnome-tweak-tool` don't do anything, but http://data.guix.gnu.org/revision/888e477bf82452028fb188ec94e793bd04f98d55/package/gnome-tweak-tool/3.28.1?locale=en_US.UTF-8 says it is there to be searched and installed. How do I get the aforementioned commands to behave as expected?

<jbnote>Hi, is it possible to 'guix archive --export --recursive' a full system (from guix system build) to move to an offline server? and if so, how?

<jbnote>Answering my own question, it looks doable by doing guix system describe and then something like 'guix archive --export --recursive /gnu/store/p9kh5m8qdf3jxb9vfw0q5sdgfnb8525c-system' (hoping it will work okay, it's running at least)

<euouae>stikonas: got it

<anadon>Also, is the firefox-but-not-firefox package compatible with Mozilla accounts? I require that functionality. If not, I'll kick off that install to Nix.

<dthompson>anadon: I'm not supposed to mention it here but there's a way to get regular firefox without resorting to nix

<jbnote>Hi, is there a way in a system description to specify the guix hash to use? All my systems seem to be packaged with the 'guix' package version, i'm forced to do an update to a specific revision afterwards. I'd like to skip this step and generate the system with the correct guix version by default.

<svoneric>hello

<rekado>jbnote: no, but you can use “guix time-machine” with a channels file to build the system with a known-good version of Guix.

<svoneric>I'm trying to install a guix system on an encrypted btrfs with subvolumes. guix system init seems to produce a sensible grub.cfg, but even though it starts with the correct cryptomount line, rebooting doesn't even ask for the passphrase before complaining that the decrypted device doesn't exist and dropping to grub rescue. Does anyone have a similar setup and maybe an idea?

<jbnote>rekado: thanks

<jbnote>svoneric: you can feed the grub.cfg to grub rescue in order to identify what's missing / goes wrong. Does it even find the grub.cfg? You can inspect the current state with 'set' and 'ls'

<jbnote> https://www.gnu.org/software/grub/manual/grub/html_node/GRUB-only-offers-a-rescue-shell.html

<svoneric>jbnote: thanks, I'll try that

<jpoiret>svoneric: you're using LUKS2?

<jpoiret>if so, LUKS2 is broken on grub 2.06, next version which should get released soon™ will have fixes for it

<svoneric>oh, great, yes

<svoneric>jpoiret: next version of grub or next version of luks2?

<jpoiret>grub

<jpoiret>you can use LUKS1 in the meantime

<jpoiret>orrrrr, you could use the grub rc with tests disabled (haven't figured out how to disable the ones which require root)

<jpoiret>you'll have to write the package definition yourself, shouldn't be too hard

<jpoiret>used it on one of my friends' laptops, worked fine

<svoneric>yeah, sorry, I'd like to have something running first before trying to learn enough guile and guix to fiddle around ;-)

IRC channel logs

2023-09-12.log