IRC channel logs

2023-08-11.log

back to list of logs

<gnucode>just out of curiosity, has porting guix system to power9 stalled? No judgement. Just curious.
<mirai>apteryx: re docbook, there's a few fixes but I'm yet to send a v2 with a few new fixes and package simplifications
<mirai>re GDM, I'm yet to test with a new GDM release but xvnc is working correctly
<mirai>I'll see if I can send in the docbook fixes by weekend
<XiaoBiHu_>Hi, `guix shell poetry` does fail on my guix (apparently no setup.py found). What's the best way to report the issue, please?
<bjc>poetry being broken is a known issue
<bjc>i have no idea when it will be fixed
<yewscion>Hey Guix, I'm having an issue with scoping during packaging: If I define a procedure at the top of a package module, it is not available within the modified phases I am creating inside of each individual package. I'm currently working around this by defining the procedure inside of each lambda, but I'd rather be able to avoid repetition like that. Is there something I am doing wrong?
<iyzsong>yewscion: nothing wrong, i think there are 2 way to share the code in phases, one is via quote/unquote, another one is via modules (eg: (guix build utils)). quote is merly copy/paste, suite for small/standlone procedures. modules is more costly, the result builder (a guile script) will import those modules at build time.
<yewscion>iyzsong: Ah, copy that. Makes sense. Thanks!
<iyzsong>for unquote gexp phase, an example is %commonroad-dont-install-license-at-root in simulation.scm
<yewscion>Is there a standard way to delay the execution of a procedure inside of such an unquote/gexp phase? The procedure I'm trying to use depends on output from scandir, and I think it's being evaluated before the phase it is called in.
<yewscion>Nevermind, I had an illumination and checked the build utils, I can make do with (find-files) instead of (scandir)
<parnikkapore>Has anyone managed to get cuirass to build packages in a `guix system vm` or `guix system container`?
<parnikkapore>When I tried it, it crashed while... trying to change ownership of /gnu/store??
<cnx>may i have an eye on my patch set adding senpai irc client? https://issues.guix.gnu.org/64222
<jpoiret>cnx: I think it'd be nicer to wait for https://qa.guix.gnu.org/issue/64222 to process your patches
<civodul>Hello Guix!
<XiaoBiHu_>bjc: thanks, that's good to know. I was trying to find the issue in the issue tracker, but failed to identify the correct one. Also, what would be the way to install the last working version?
<jpoiret>civodul: do you have any opinions about 873518m8zr.fsf@jpoiret.xyz ?
<jpoiret>(that's in #64760)
<cnx>jpoiret, it's been 1.5 months, how long is it suppose to run (assuming it isn't borken)?
<jpoiret>ah, maybe there's a problem with QA then
<jpoiret>cbaines ?
<civodul>jpoiret: hi! no real opinions :-) but i replied regarding the tests/store-root.scm failure
<civodul>i'm not sure why that happens
<civodul>Works For Me™
<ulfvonbelow>what would the proper way be to express an array of platform-dependent size as a struct member in (guix build syscalls)?
<jpoiret>civodul: the lstat problem comes from the delete-file-recursively
<civodul>(the two other patches LGTM)
<jpoiret>there's an initial lstat on the directory that isn't caught
<ulfvonbelow>e.g. a sigset_t is defined as 1024 bits spread across a bunch of unsigned longs
<ulfvonbelow>is the type argument to the (array ...) subform evaluated?
<civodul>jpoiret: but then i wonder why i don't experience it? ./test-env is supposed to give a fresh localstatedir
<jpoiret>and I've looked into how the /profiles and /gcroots directory get created while running tests and it seems to me that the situation is too complex to assert whether or not they exist at this point
<ulfvonbelow>or more importantly in this case, is the length argument evaluated?
<civodul>ulfvonbelow: maybe you can do something like %struct-dirent-header?
<civodul>or you mean architecture-dependent?
<ulfvonbelow>architecture-dependent is the better phrase, yeah
<civodul>ok
<jpoiret>./test-env interns the bootstrap files in the store if they exist, which creates the state directories, but on archs without those i'm not sure they ever exist
<jpoiret>also there might be some funky PID reuse
<civodul>we can usually assume PID aren't reused prematurely
<jpoiret>we could rm -rf the statedir before creating anything in it
<civodul>yeah
<ulfvonbelow>but would something like (define-c-struct ... (__sd (array unsigned-long sigset-nwords))) work?
<civodul>but you're right that on systems where "guix download" isn't invoked, perhaps we won't get those
<jpoiret>civodul: not even prematurely, I have some leftover PID directories left in my filesystem so they don't get cleaned up properly
<jpoiret>and then, if /profiles and /gcroots aren't created, then you won't get the same gc-roots as claimed by the test
<jpoiret>since the expected answer is the /profiles directory that's linked under /gcroots
<civodul>jpoiret: you're getting the test failure on x86_64-linux?
<jpoiret>yes, and janneke too
<civodul>that rules out the missing "guix download" hypothesis, then
<civodul>and it's 100% reproducible, right?
<jpoiret>let me try again just to be sure
<ulfvonbelow>is there any particular reason why we don't have (guix build syscalls) use a guile extension? I quite like the idea of some C code using, e.g., sizeof(posix_spawnattr_t) instead of diving through header files
<civodul>ulfvonbelow: the goal was to not have C at all :-) and in the case of libc interfaces, the ABI is very stable, so it's reasonable
<jpoiret>civodul: so yes, the test reproducibly passes for me if I remove the sole /profiles entry from the expected result
<civodul>what you wrote above with sigset-nwords may work
<jpoiret>which is 100% what should happen
<jpoiret>since there's no /gcroots directory yet
<ulfvonbelow>also, when I'm diving through the libc headers, should I assume that anything under bits/ will likely vary by architecture?
<ulfvonbelow>that is to say, should I assume that the headers I see there are already customized to my architecture?
<jpoiret>yes
<jpoiret>a lot of the libc headers vary by arch/kernel
<civodul>ulfvonbelow: arch-dependent bits are under sysdeps/ but many structs are expressed in a generic way, using types such as size_t, etc.
<jpoiret>aren't sysdeps included once the headers are built?
<jpoiret>i mean, moved around
<ulfvonbelow>hmmm, so I should really be looking in the libc sources, not the built headers?
<civodul>jpoiret: yes, but i'm thinking about the source tree
<civodul>ah well, sorry for the confusion
<civodul>either way is fine i guess
<civodul>which struct are you looking at?
<ulfvonbelow>posix_spawnattr_t at the moment
<civodul>jpoiret: so i'm confused, i don't get why you and i would observe different behavior; maybe just punt and (test-skip 1) with a FIXME?
<civodul>ulfvonbelow: oh! are you aware of 'spawn' in Guile 3.0.9?
<jpoiret>civodul: I don't know why it works for you as is, but after reading the implementation a couple of times I'm convinced that the test is wrong
<ulfvonbelow>am I correct in believing that the structs defined by define-c-struct cannot themselves be included in other define-c-struct forms?
<jpoiret>without an opened connection there shouldn't be /profiles or /gcroots
<civodul>yeah, intuitively i think you're right
<civodul>oh well, maybe delete the test altogether
<jpoiret>what was the intent of the test? to check if the call to gc-roots errored out, or if its result was right? because we could just make the test return #t and still check for exceptions
<jpoiret>and also guard the (delete-files-recursively ...) call
<civodul>the intent was to test the bug fixed by 1261ce15233cbf7e24de9959df86a23b46314a28
<jpoiret>right, so I guess we can just fish for exceptions but not check the returned value
<ulfvonbelow>civodul: it's news to me, looks like its functionality is a subset of posix_spawn's, and my particular use case involves passing additional file descriptors beyond just stdio
<jpoiret>ulfvonbelow: guile's spawn *explicitely* closes all open fds except for the standard ones, so that's a no-go
<ulfvonbelow>indeed
<civodul>hmm, too bad we can't do that with 'spawn'
<ulfvonbelow>ah, on a somewhat related note, I have some patches sitting around for shepherd's #:extra-ports
<civodul>jpoiret: to summarize, do however you feel about that test, don't waste more time on it :-)
<ulfvonbelow>they have a case of the clobbers
<civodul>oh, interesting
<ArneBab>Is there something organized to check packages for reproducibility? Do we have a team that regularly guix build --check’s packages?
<civodul>ArneBab: hi! there's no team or formal process; there's the dashboard at https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-reproducibility and the rest is more like random sampling
<ekaitz>hi, what's the best way to have some printing in a `phase`? I tried `display`-ing but the output appears several phases later
<ulfvonbelow>ekaitz: it sounds like you might be running into a buffering issue. Try adding a (force-output) right after your 'display' call.
<ekaitz>ulfvonbelow: OH thanks! I tried to write to (current-error-port) to avoid that but it still happened. Let me try that! thanks!
<ulfvonbelow>ah, then you'll want (force-output (current-error-port))
<ekaitz>ulfvonbelow: thanks! I'll add that
<ulfvonbelow>👍
<ekaitz>ulfvonbelow: it worked as you said, :)
<ekaitz>I have a weird guix issue now: If I `guix build --system=riscv64-linux -f package.scm` the package I'm building detects the system as riscv64-linux, but if I `guix shell --system=riscv64-linux -f package.scm` it detects amd64
<ekaitz>efraim: did you find any issue like this while working in rv ^
<nckx>Does ‘guix shell’ not build a RISC-V output at all?
<nckx>Because I think it builds both.
<nckx>ekaitz: Are you noticing this because the package supports only riscv64?
<nckx>(Despite this, adding ‘(supported-systems (list "riscv64-linux"))’ does NOT fail the build when running ‘guix shell --system=riscv64-linux’ on an x86_64 machine.)
<next4th>ekaitz: there was a bug https://issues.guix.gnu.org/63230 fixed in 5.2 where the cache of guix shell failed to consider system, maybe related?
<nckx> https://issues.guix.gnu.org/65225
<nckx>Looks like issues. still inserts gratuitous spaces into words (‘f or both systems’).
<nckx>Subject: =?UTF-8?Q?=E2=80=98guix_shell_--system=3DALIEN=E2=80=99_builds_f?=
<nckx> =?UTF-8?Q?or_both_systems?=
<nckx>Not quite gratuitous.
<nckx>next4th: Kiiiind of. That fix itself is suspect, but I'm starting to see how the logic got crossed.
<nckx>Hint: ‘guix build --system={x86_64,riscv64}-linux foo’ != ‘guix build --system=riscv64-linux foo’. There are parts that assume that it is.
<adanska>Would anyone know of a way of setting a package origin as a local file? Such as something in the home directory with a known path
<nckx>adanska: (source (local-file "/home/you/stuff.tgz")) or (source (git-checkout …))
<nckx>This applies to package inputs as well.
<nckx>adanska: https://logs.guix.gnu.org/guix/2023-08-11.log#135039
<nckx>adanska: If you're not aware, your connection keeps flapping. IRC doesn't buffer messages so you won't see anything addressed to you whilst you're disconnected.
<adanska>thanks nckx ! sorry about that, i’m writing from an iphone irc client and it doesn’t seem to be able to keep the irc connection alive whilst i’m not using it. sorry if it’s a bit spammy, i’ll wait till i get home to use the channel :)
<nckx>No problem. I use Revolution IRC and it stays connected, but that's on Android.
<adanska>yeah, i think it’s another ios restriction :p
<nckx>At least on Android, the way applications prevent getting killed by the OS is by keeping a ‘notification’ open (even when they have nothing to say). Maybe worth looking at your notification settings, or maybe it's just a different world 🤷
<adanska>re your answer: thanks! that’s what i thought to do initially but i wasn’t completely sure as the reference says that source must be an origin object. so source accepts any file-like object?
<test-once>Hey all, I got interested in guix after seeing that it is used in bioinformatics lab too.
<nckx>adanska: Where did you read that it must be an origin? That's inaccurate, and you are correct: https://guix.gnu.org/en/manual/devel/en/html_node/package-Reference.html
<nckx>Hi test-once.
<test-once>I have been researching on guix, and got to know about 10years of guix, but I'm unable to watch videos on that event. Ref: https://10years.guix.gnu.org/video/maneage-a-proof-of-concept-for-rigorous-reproducible-research-paper-criteria/
<nckx>Hmm, they work for me.
<adanska>you are completely right nckx haha! glossed over completely the “usually” part :p
<test-once>You mean to me about videos of 10years, nxkx?
<nckx>I mean the (only?) video on this page: https://10years.guix.gnu.org/video/maneage-a-proof-of-concept-for-rigorous-reproducible-research-paper-criteria/
<nckx>Which is https://guix.gnu.org/guix-videos/ten-years-of-guix/02-boukema.mp4
<nckx>What happens when you try?
<test-once>Yea, even with mpv I cannot play. Maybe its my isp or network issue then
<test-once>I did go throught fosdem talks. Now wanted to watch this so..
<adanska>okay, cool! getting sidetracked from my onedrive home service into getting some strange tool my uni course needs me to use into my guix
<nckx>Weird. It works in Firefox, but I could also curl it just fine, and mpv both the downloaded file and the https:// URL directly.
<nckx>Does mpv print an error?
<nckx>adanska: Been there.
<test-once>Yes. [ffmpeg] tcp: Failed to resolve hostname guix.gnu.org: System error Failed to open https://guix.gnu.org/guix-videos/ten-years-of-guix/02-boukema.mp4. [ytdl_hook] ERROR: [generic] None: Unable to download webpage: <urlopen error [Errno 16] Device or resource busy> (caused by URLError(OSError(16, 'Device or resource busy'))) [ytdl_hook] youtube-dl failed: unexpected error occurred
<test-once>Sorry didnt mean to paste it raw text here. Sorry if its not proper
<nckx>That does sound like a network (specifically, DNS) failure on your end. Browsers like to use NIH DNS clients & separate caches from the rest of the OS, so that could explain why you were able to browse the site, but not why the video won't play in your browser.
<nckx>test-once: It's OK, as long as it's ~3 or so lines at most.
<nckx>And a line is <500 characters on IRC. If you'd paste a longer one it would get split. Now you know more than you wanted to know.
<nckx>When pasting log output or files, anything over 3-4 lines, use the pastebin in the channel topic.
<nckx>test-once: If you're using Guix System, you can try clearing the cache with ‘sudo herd invalidate nscd’, although it doesn't always help.
<test-once>That sounds true, because sometimes Dns wont connect. I recently did setup dns in my system. Thank you !
<test-once>..
<ulfvonbelow>dig +trace guix.gnu.org
<nckx>(dig is in the ‘bind:utils’ package output.)
<test-once>Nckx, is there other way to view them?
<test-once>Okay, my bad for haste. It is working on the other browser
<nckx>ACTION was going to suggest https://web.archive.org/web/20230325172416/https://10years.guix.gnu.org/video/maneage-a-proof-of-concept-for-rigorous-reproducible-research-paper-criteria/ but hasty indeed.
<apteryx>ACTION is closing in on a new rewrite-url procedure that does: (rewrite-url "https://dist.libuv.org/dist/v1.45.0/libuv-v1.45.0.tar.gz" "1.45.0") -> "https://dist.libuv.org//dist/v1.46.0/libuv-v1.46.0.tar.gz"
<apteryx>to be used as part of import-html-release, fixing issues like #64015
<apteryx>it's a bit hairy though
<civodul>nice you're fixing that
<civodul>i was looking at https://repology.org/ and found we're approaching the top 5 in number of packages!
<civodul>but... we're not good in terms of up-to-date packages
<civodul>which is kinda weird because we have great tooling i think
<civodul>i guess we really need "guix refresh as a service", something that'd feed the data service with upgrades to try
<civodul>we should check how the Nixpkgs folks handle it
<apteryx>yes; I think I saw nixos doing something like this, if I didn't dream it
<civodul>yeah they have bots
<apteryx>I guess it'd be some job for QA
<civodul>right
<mirai>apteryx: re #63081, do you prefer a new issue for the follow-up or will reusing the same issue be alright
<apteryx>is there a follow-up? I've already pushed/closed it
<apteryx>(to core-updates)
<mirai>the follow-up will be about dropping obsolete workarounds
<mirai>btw I only see 6 of the 8 patches in c-u
<mirai>the most important one IMO (1/8) seems to be missing and it does fix a subtle break with docbook 5.x
<mirai>the 5.x ones aren't being extracted correctly (you can confirm this by checking their resulting file trees)
<mirai>the 2/8 adds a new package (to be used while editing or validating)
<mirai>in any case I'll do a rebase first and we can sort it out later
<apteryx>phew; I think all the edge cases were ironed out; "make check TESTS=tests/gnu-maintenance.scm" is passing
<apteryx>no to remove the tens of pk calls...
<apteryx>mirai: will verify, thanks
<apteryx>the follow-up sounds good; a new issue should be opened
<parnikkapore>I'm trying to set up a temporary substitute server on my machine. How do you use cuirass to build packages in a `guix system vm`?
<parnikkapore>* substitute builder
<parnikkapore>I made a system definition for it, but Cuirass keeps erroring, yelling about not being able to change ownership of the Guix store??
<parnikkapore> https://paste.debian.net/1288629/
<minima>hi, anyone else suffering from this https://issues.guix.gnu.org/57498 ? it's about bash completion in the context of guix home (when bash completion is only installed via guix home as opposed to the main guix profile)
<minima>a work-around is suggested at the end of the thread and that seems to work fine, but i was wondering if there were any other (cleaner?) ways to solve this
<minima>the work-around is a little snippet to be added at the end of bashrc
<jackhill>hmmm, maybe someone more versed us cuirass can tall me: why is the weather bad for libjami? It seems to build locally on x86-64
<jackhill>s/tall/tell/
<ulfvonbelow>I recall both libjami and some of its dependencies having nondeterministic test failures
<ulfvonbelow>where the probability of failure grows with system load
<jackhill>oh, fun times
<jackhill>thanks!
<ulfvonbelow>in my experience if you ever try speeding things up with --max-jobs=<number of cores> during a big manifest build you find that it acts as a filter: the later on it goes the more huge builds there are going on at once
<apteryx>maybe the timeouts are too tight?
<apteryx>jackhill: libjami appears to have built fine on x86_64: https://ci.guix.gnu.org/search?query=libjami+spec%3Amaster
<apteryx>disregard my timeouts message earlier, I thought the question was w.r.t. the jami tests
<ulfvonbelow>there's a symbol collision in something I'm writing and despite specifying both #:select and #:hide in the #:use-module form for one of the colliding modules, it's still giving me warnings
<apteryx>civodul: any idea why we only support a few known sites for the html-updatable-package? predicate?
<apteryx>that's used as part as generic-html-updater, which is not very generic it seems
<jackhill>apteryx: but only one of the outputs? https://paste.debian.net/1288630/
<apteryx>interesting
<jackhill>apteryx: my derivation looks different than https://ci.guix.gnu.org/build/1622820/details if I understand it correctly
<apteryx>I don't see that from CI: https://ci.guix.gnu.org/search?query=libjami+spec%3Amaster+system%3Ax86_64-linux
<mirai>how can I get XML_CATALOG_FILES to be set during the build phase without having to piggyback on libxml2 (that sets XML_CATALOG_FILES as a native-search-path)
<apteryx>but I reproduce locally
<apteryx>mirai: you can't (you need to add a package that has the search path for it, such as libxml2)
<apteryx>that's used all over
<apteryx>with the comment ;for XML_CATALOG_FILES next to the libxml2 native-input
<mirai>apteryx: seems "wasteful" to rely on it for packages that might not even rely on libxml2
<apteryx>it may be in the closure already, haven't checked
<apteryx>and it's only used at build time
<PotentialUser-60>Can anyone please tell me How to upgrade guix Linux kernel? And how to change the current kernel?
<mirai>marginally related, I think it's worth adding a $XML_CATALOG_FILES to (guix profiles)
<mirai>(guix search-paths) I mean***
<mirai>its not exclusive to libxml2
<apteryx>if there's a need, why not!
<apteryx>how long does guix-daemon keep cached substitute servers it autodiscovered?
<civodul>apteryx: html-updatable-package? returns true for every site but those listed there
<civodul>that's because we have better update methods for these
<mirai>xmlto also uses this afaik and would save a lot of mysterious validation error headaches & workarounds
<apteryx>civodul: ah! I misread the code.
<apteryx>ACTION wonders why qtbase has no updater found for it
<apteryx>I'd expect the generic HTML updater to be used
<civodul>that's what "guix refresh qtbase" tells me
<civodul>but it doesn't find releases
<Altadil>PotentialUser-60: if you do a normal system update, it should automatically get to the newest version available.
<parnikkapore>How do you use cuirass to build packages in a `guix system vm`? I made a system definition for it, but Cuirass keeps erroring, yelling about not being able to change ownership of the Guix store??
<parnikkapore> https://paste.debian.net/1288629/
<nckx>I don't think (Guix) building anything in a ‘guix system vm’ is supported.
<nckx>The ‘store’ there is a limited, read-only view of the host store, and it's not set up to redirect writes.
<apteryx>no? i thought guix system vm is the same as guix system image these days
<apteryx>maybe you need --non-volatile or something
<parnikkapore>it would probably be worse if they're the same (for disk space reasons) kek
<nckx>apteryx: Oh?
<nckx>I'm trying with --persistent but that sounds like something very different.
<nckx>Also, a rather drastic change if true.
<apteryx>I probably confuse vm-image
<parnikkapore>I could just install guix system in a normal vm, but that'd be, like, the 5th linux rootfs on my pc 😅
<apteryx>why not host cuirass on the host directly?
<apteryx>ACTION rarely uses VM outside messing with foreign distributions
<nckx>There are so many Guix+VM+image possibilities these days.
<nckx>It's normal to get confused.
<nckx>(Even guix system vm --help struggles to deal with the matrix in a concise & clear way.)
<parnikkapore>I kinda want to mess around with binfmt, but don't want to set that up on the host to avoid breakage
<apteryx>it'd be nice to have proper subcommands longer term, so that each can have their own help
<parnikkapore>oh yeah because `guix system vm --help` equal? `qui system --help` rn
<apteryx>parnikkapore: if it breaks something it's easy to revert from your guix system config
<apteryx>parnikkapore: yep
<parnikkapore>ACTION is running a foreign distro
<apteryx>ah!
<apteryx>here lies your main issue, haha
<parnikkapore>XD
<apteryx>civodul: ah, I changed qt-urls to use the mirror:// scheme locally, maybe that's why it won't use the generic-html updater anymore
<parnikkapore>tangent about running guix system on bare metal: I have two concerns atm
<parnikkapore>the first is proprietary apps from work that hook into the system (hi vpns)
<apteryx>the motivation for the rewrite-url thing is mostly for updating qt :-)
<apteryx>parnikkapore: you can package whatever privately, or use channels
<parnikkapore>second one is that the situation wrt green graphics card company's official driver, which is completely off the beaten tracks even with That Channel's help
<apteryx>are you doing CUDA or something? else it seems unecessary
<parnikkapore>apteryx: and I do think that the latter is more of a blocker, esp with good binary repackaging tech (and an lsb package)
<parnikkapore>high-performance... gaming!
<apteryx>there are free nvidia drivers these days, no?
<apteryx>(minus the usual firmware blob part...)
<parnikkapore>possibly off-topic at this point, but the actually fun™ part is having to rename the driver and graft it in mesa's place
<parnikkapore>that's what brings the whole procedure into off-the-beaten-track territory
<parnikkapore>* driver package
<apteryx>sounds... fun. seems the free driver released a year or two back hasn't progressed, according to the Internet: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/nvidia-linux/1402584-nvidia-535-98-linux-driver-released-with-several-fixes
<apteryx>err, https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/nvidia-linux/1402584-nvidia-535-98-linux-driver-released-with-several-fixes?p=1402774#post1402774
<apteryx>civodul: got it, I'll fix this as well
<gnucode>hello guix!
<gnucode>I'm about to set up fail2ban for my server. is (service fail2ban-service-type) sufficient to block people spamming my ssh port?
<gnucode>am I reading the manual right? The fail2ban service by default as packaged in guix does not block people spamming your ssh session?
<gnucode>that seems a little odd.
<gnucode>I suppose there are some servers that do not run an sshd daemon...
<ArneBab>civodul: is there a way to run a nightly service that builds a package at random and reports it if it’s not reproducible?
<ArneBab>(I see that x86_-(-linux still has 8.35% unknowns.
<civodul>ArneBab: not really, but you could run 'guix challenge' on your random packages and have a script around that
<civodul>you don't even need to actually build it since we have two build farms
<civodul>(which probably uncovers most issues)
<RavenJoad>Guix can create ISO install images, but is there anything special that needs to be done to create an install image for a custom operating-system?
<nckx>‘For’ can mean a lot of different things here.
<nckx>It's very easy to customise the ‘live OS’ that boots when you boot the image, or ship some extra packages to ease low-bandwidth installations (as long as you don't ‘guix pull’), or include some extra files. It's not easy to modify the installer wizard's default or base template.
<ArneBab>sneek: later tell civodul: yikes! guix challenge guile:
<ArneBab> https://ci.guix.gnu.org/nar/lzip/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9: 1mn4ahip1cywc2nkq7lbgjfgdws9r283r3r12yq6ijg1b2zi5yz6
<ArneBab> https://bordeaux.guix.gnu.org/nar/lzip/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9: 17gvhxrcngyjjy2mlr9j2x6xv0x16b7dnf6dpz00vfqvddq9i2
<sneek>Okay.
<RavenJoad>nckx: I mean I already have an operating-system written with my configuration. I want to build that into an install image, so I just have to guix system init the new install and I am done.
<PotentialUser-60>Can anyone please tell me how to see kernel version in guix?
<bjc>uname -a?
<nckx>Same as anywhere. uname.
<PotentialUser-60>Can anyone please tell me how to upgrade libre-Linux kernel?
<nckx>guix pull && guix system reconfigure <your system configuration file, often /etc/config.scm>
<nckx>Sorry: guix pull && sudo guix system reconfigure <your system configuration file, often /etc/config.scm>
<nckx>RavenJoad: Add (services … (extra-special-file "/etc/guix/system.scm" "/etc/joadtime.scm") …) to https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/system/install.scm && build && boot it && guix system init /etc/joadtime.scm /mnt
<RavenJoad>nckx: Sweet! That makes things a lot easier. I assume I can do the same to get a custom channel file too?
<nckx>I don't see why not.
<nckx>/etc/guix/channels.scm etc. should not be magic. If you see any unexpected problems, it might be a bug.
<nckx>I don't think there's a way to embed channel definitions within an operating-system, though. (Maybe ‘yet’, maybe not.)
<RavenJoad>I don't need them embedded, just available. The final installed system needs access to my channel to build my website.
<PotentialUser-60>I can see #1 SMP PREM
<nckx>‘uname -r’ will show the Linux kernel version.
<PotentialUser-60>Is 6.0.10-gnu the latest stable version of Linux kernel available?
<PotentialUser-60>In guix distro?
<nckx>No.
<nckx>I think it's 6.4 now.
<nckx>6.4.9 to be precise.
<PotentialUser-60>Can anyone please tell me how to upgrade to 6.4
<nckx>TIL ‘fc’ because I mistyped ‘fg’.
<nckx>PotentialUser-60: I already did. guix pull && sudo guix system reconfigure <your system configuration file, often /etc/config.scm>
<PotentialUser-60>Thank you
<nckx>If that is unclear, please explain why, but it's the basis of all Guix System administration. If you've installed Guix System, you should be(come) familiar with that incantation.
<nckx>Check out https://logs.guix.gnu.org/ if you're missing messages due to being disconnected.
<PotentialUser-60>OK
<PotentialUser-60>Thank you
<PotentialUser-60>Is there any place where I can learn gnu incantation ?
<nckx>You should at least read parts of the manual, either with ‘info guix’ on your machine or <https://guix.gnu.org/en/manual/devel/en/html_node/> on the Web. I don't know how you installed Guix System, but you'll need to know the basics in order to change many things.
<PotentialUser-60>Thank you again
<lfam>I want to create a new PGP signing key for use with Guix development. Is there a particular type of key I need to create? Or is it okay to do `gpg --full-generate-key` and use the result. That creates a master key of type SC (sign and certify) and an encryption E key
<nckx>PotentialUser-60: Good luck. Also, a general note: Guix isn't finished, some things don't work or are missing. It expects you to be familiar with certain aspects of computing that other more ‘new-user friendly’ distributions don't. I wouldn't personally recommend Guix to someone who didn't figure the basics out on their own, but we'll do our best to help you out if you stick around.
<lfam>I suppose that the proof is in the pudding, and that if `guix git authenticate` works, then it's fine. But I also like to follow convention
<nckx>ACTION wants to recommend ed25519 subkeys, but doesn't want to *explain* subkeys today, dilemma.
<lfam>I know about subkeys, and use them currently. I have the offline master key and everything. I want to do something simpler
<nckx>Oh, OK.
<nckx>I don't think Guix has standards, no.
<lfam>ACTION prepares to quote nckx out of context
<nckx>Oh, it was deliberate :)
<gcarlos>what I'm doing wrong to be getting error like "commit 44bbf... of channel 'guix' is not a descendant of 77251..."?
<lfam>:)
<nckx>I'm a bit surprised that ‘gpg --full-generate-key’ doesn't suggest ECC keys at all, but again, I wasn't going to get involved.
<nckx>ACTION carefully closes terminal.
<gcarlos>I just ran guix pull as root (without keeping env from my user) and guix system reconfigure <config>
<nckx>It implies that you're downgrading Guix.
<PotentialUser-60>Any beginer friendly distro ( suggestion)which doesn't have any propitiatory code in it?
<nckx>gcarlos: 77251c5f5a or 77251d7791?
<lfam>nckx: I googled the ECC thing and it seems like a rabbit hole
<gcarlos>nckx: aborting reconfiguration because commit 44bbfc24e4bcc48d0e3343cd3d83452721af8c36 of channel 'guix' is not a descendant of 77251c5f5af193dcd031dffef744001cfc48f7e5
<nckx>PotentialUser-60: Not from experience, but Trisquel is based upon Debian upon which Ubuntu is based, both of which are the target of most tutorials and advice on the Interwebs. It's also fully Free.
<nckx>Again, I don't mean to discourage use of Guix (and others here might disagree) but I also want your experience to be positive.
<gcarlos>PotentialUser-60: I would also recommend trisquel, but i did never used it, just a guess
<nckx>(They left, but I told them about the logs earlier.)
<nckx>gcarlos: So you're invoking a ‘guix’ that is almost a month older than the one that was previously used to reconfigure the system.
<nckx>You can see more info with ‘guix describe’.
<gcarlos>isn't the guix upgraded when I run guix pull?
<nckx>Yes, but you mentioned doing so as root?
<nckx>This is at least unconventional.
<nckx>Are you also invoking ‘guix system reconfigure’ as root (not with sudo or so)?
<nckx>If this is the first time you pulled as root, you might also need to run ‘hash guix’ or log out & back in.
<nckx>The average user runs ‘guix pull && sudo guix system reconfigure …’. This way, you don't have to keep 2 guix's updated (yours and root) and prevent confusion.
<gcarlos>nckx: I'm doing that logged as root, what's the difference between doing that or use sudo?
<gcarlos>i'm using doas btw, without the config to keep env
<nckx>Got it (now).
<gcarlos>as I'm not keeping env, I'm in need to run 2 guix pull
<nckx>Assuming you're at least using bash, what does ‘type guix’ say? 😛
<nckx>As root.
<gcarlos>guix is hashed (/run/current-system/profile/bin/guix)
<nckx>OK, so you'll have to ‘hash guix’.
<gcarlos>no changes
<gcarlos>same version on guix describe
<nckx>And ‘which -a guix’?
<gcarlos> /run/current-system/profile/bin/guix
<nckx>Odd. We're looking for /root/.config/guix/current/bin/guix, which is what ‘guix pull’ creates.
<nckx>It should come first in $PATH, but does it even exist?
<nckx>If not, the pull did not succeed. Somehow.
<apteryx>ugh! that %tarball-rx is hairy
<nckx>If it does exist, it seems like your PATH might be off?
<gcarlos>hmm, I think that the bash isn't sourcing the root profile
<lfam>Unix environments strike again
<gcarlos>so, without that, guix pull did nothing?
<nckx>If it created /root/.config/guix/current/bin/guix it worked.
<nckx>Not sure if you saw my suggestion to log out & back in. I'd do that first, in case it is a missing profile thing.
<lfam>+1
<nckx>Yeah, so the default /etc/profile does if [ -f "$profile/etc/profile" ]
<nckx>so if you've never pult, guess what isn't getting added.
<nckx>I'm not sure that is a wise decision on Guix System?
<gcarlos>I did that (re-login)
<gcarlos>but no change too
<nckx>And yet $HOME/.config/guix/current/etc/profile exists?
<gcarlos>it exists
<apteryx>hurray, './pre-inst-env guix refresh qtbase' -> gnu/packages/qt.scm:586:2: qtbase would be upgraded from 6.3.2 to 6.5.2
<nckx>Does explicitly ‘. /etc/profile’ at least do something?
<apteryx>and './pre-inst-env guix refresh libuv' -> libuv would be upgraded from 1.44.2 to 1.46.0
<gcarlos>nckx: ah
<gcarlos>it changed my guix version
<gcarlos>the system /etc/profile
<nckx>Right, that's because it update $PATH.
<gcarlos>I was sourcing the root profile
<nckx>There are configurations (and desktop environments/login managers) with which I'm not familiar that do not source /etc/profile on log-in.
<nckx>Guix really relies on it getting sourced.
<gcarlos>I'm just very confused trying to understand the way that guix handles these envs
<graywolf>Is there a specific order in which home-bash-service-type are evaluated? It seems that first added appears in the ~/.bash_profile as last, is that something I can rely on or is it considered an implementation detail?
<gcarlos>nckx: I'm not explicity sourcing it with my user but it's working fine
<gcarlos>maybe when I'm using doas to login as root i'm missing that
<nckx>lfam: ‘ECC’ just means you get ed25519 keys instead of RSA, which are smaller and (at least for a while) more secure. It doesn't complicate anything. But RSA is fine.
<nckx>gcarlos: Maybe! I use sudo, because my life is too boring otherwise.
<gcarlos>anyway I can just use to keep env and never use root without that
<gcarlos>the sudo default config, for guix, as far I know, keep the env unchanged
<gcarlos>but thank you :)
<nckx>Yes. Not sure about ‘unchanged’ or if there are specific variables that are still filtered, but effectively, yes.
<apteryx>I can I update a package to a specific version?
<apteryx>e.g., qtbase@5 to 5.15.10 ?
<gcarlos>also, I'm having a trouble on guix that I never had on other distros, is that the kernel don't the password prompt to decrypt a volume, I stay stuck on the grub screen but if I type my password it boots normally
<gcarlos>It's not strictly related to guix, but as it's the OS i'm using, i'm asking for help here :)
<apteryx>re my question, it's supported via the '=' sign, per 'info "(guix)Invoking guix refresh"'
<nckx>gcarlos: I've never had a machine that did this, but could it be due to missing display driver modules at early (initrd) boot that aren't loaded until late boot (from the root file system)?
<nckx>So the GRUB screen remains on the screen because the kernel doesn't know how to draw anything yet. That's my guess 🤷
<nckx>You could try adding your display drivers to the initrd if you're bored.
<nckx>s/GRUB screen/GRUB background/
<apteryx>neato: ./pre-inst-env guix refresh qtbase@5=5.15.10 -> qtbase would be upgraded from 5.15.8 to 5.15.10
<gcarlos>nckx: the kernel just draw things on the screen after the modeset, that means that the video driver really isn't on the initrd
<makx>Hai! Is the "standard" method to get guix going on a RockPro64 still "put debian on it and build guix"?
<vagrantc>yeah, i don't think there are aarch64 installers for guix yet
<gcarlos>so, i think that the only way to get rid of it is to embed the video driver in the kernel or put it on initrd
<gcarlos>I think that the cause I'm having that problem on guix may be caused to it don't including the video modules on initrd by default. I really don't know how guix manage the initrd
<gcarlos>but thanks again, just thinking on it already lead me to know what would be the cause of the problem
<vagrantc>makx: alternately, you could cross-build a guix image for rockpro64 maybe ...
<vagrantc>makx: on some other machine...
<bjc>gcarlos: is the module you need part of mainline linux, or is it a separate package?
<gcarlos>bjc: it's on mainline, is the i915
<makx>vagrantc: I can try the debian -> install guix route first. I have quite a few of these rockpro64/quartz64s kicking around
<nckx>gcarlos: You can try adding (initrd-modules (cons* "i915" %base-initrd-modules)) to your o-s definition.
<gcarlos>it's present on linux-libre, of course
<bjc>gcarlos: then there's (initrd-modules) in (operating-system)
<makx>in my (limited) experience of cross-building nixos its a bit of a pita
<bjc>what nckx said
<makx>"it" being cross-building ;)
<nckx>(The * is optional but it's FUTURE-PROOF so I like suggesting it.)
<gcarlos>nckx: i'll try that, let me see
<nckx>ACTION away.
<gcarlos>it worked :)
<bjc>🎉
<gcarlos>nckx: yeah, the * isn't really needed, is just 1 element being consed
<dgr>what is a good size for swap on guix? got 8GB of RAM.
<bjc>there are precious few reasons to use ‘cons’ over ‘cons*’ imnsho
<bjc>i haven't configured a machine with swap in like 20 years, except once to test out hibernation
<apteryx>dgr: I don't use swap but I use zram on a 8 GiB desktop, which is similar
<gcarlos>apteryx: don't zram just compress the RAM?
<singpolyma>Yeah, generally swap is a bad idea IMO
<gcarlos>does it use some secondary media?
<apteryx>gcarlos: zram uses compressed RAM as swap
<dgr>apteryx: I think I read a lot is needed to compile some packages but I have no clue if I will ever build them. It's a laptop so hybernate a nice option and only available with swap
<apteryx>if you can affort it you can go for a 1:1 ratio; 8 GiB
<vagrantc>makx: might take a few tries, as getting the right initrd-modules sorted out can take some time
<apteryx>afford*
<apteryx>you'll need that ratio for hibernation anyway
<makx>vagrantc: no worries ;) been there done that with nixos
<bjc>i don't much care for hibernation, tbh. normal sleep is pretty low power draw, so the battery lasts a long time. i'd rather just eat the loss if the battery runs out than have to contend with hibernation making sleep/wake cycles extremley expensive all the time
<gcarlos>what's the difference between hibernate and sleep and what not, isn't the hibernate that put things on secondary memory and sleep on ram?
<dgr>apteryx: docu says halve but I remeber that 1:1 is recommendet for hibernation also.
<bjc>hibernation pages ram out to disk. sleep keeps the ram active so it doesn't lose
<gcarlos>hmmm
<gcarlos>thx for the explaination
<bjc>but that means that when your machine sleeps, it has to page out your ram, which is slow and power hungry. likewise when it wakes up it has to come back in
<bjc>for me, and i suspect most, that's a bad trade-off
<dgr>gcarlos: sleep is ram and hibernate is swap and if I rember correctly if your batter runs out, it will just resume from hibernate.
<vagrantc>makx: also one of the -generic linux-libre variants might be easier to start out
<gcarlos>a good use case for hibernate would be if you don't have a good battery
<vagrantc>makx: has more things built-in
<bjc>it's for when your battery empties itself often enough that normal sleep mode is a pain
<bjc>as for using swap because you need more ram than is available: if you're actively using the machine, you're going to hate your life as it constantly pages stuff in and out. it's what you do when you have no other options
<dgr>bjc: I guess RAM also got a lot less power intensive than I'm used to.
<nckx>hybrid-sleep is a good compromise for people for whom hibernation is slow for whatever reason.
<bjc>probably not so bad with nvme drives these days, but if you can afford nvme, you can afford more ram =P
<makx>do people use guix deploy a lot? I am using deploy-rs with nix atm, but tbh, I have wasted so much time on this nix language and things not working
<bjc>it doesn't take much power to just refresh ram. it's more costly to fetch or update from it
<makx>and I speak scheme, so I am just feeling more at home anyway
<dgr>bjc: 8GB RAM is soldered on the MB - ThinkPad x280...
<nckx>Oof.
<bjc>8gb is enough to compile most things most of the time
<apteryx>jackhill: does libjami builds fine locally?
<bjc>you can also just add swap later with a swapfile if you need to. you don't need to configure it up front, unless you need hibernation
<dgr>nckx: don't feel bad, it cost me < 200$ and I see it as a investment to learn guix.
<dgr>bjc: I think about reformating as I now got 550MB for EFI as fat32 and the rest is a LUKS2 with btrfs with subvols and I read someware that a swapfile on btrfs isn't a good idea. Did I get something wrong?
<bjc>i don't know why swap on btrfs would be bad, so long as you don't snapshot it. if you're swapping, performance likely isn't your concern anyway
<bjc>but that's just me thinking out loud. i haven't seen anything one way or another. historically, though, there's a lot of cargo-culting around swap that goes back many decades
<apteryx>dgr: no problem with swapfile on btrfs, but it's not possible to do so with btrfs raid
<gcarlos>you must disable COW to have a swapfile on btrfs i guess
<apteryx>you can still use a dedicated partition
<gcarlos>say, disable cow to that file
<gcarlos>beside that, i don't think it should have any problem in having one swapfile
<dgr>gcarlos: I didn't know one can disabe COW for a single file will investigate more as I prefere a swap file if possible.
<gcarlos>dgr: i'm almost sure that is possible to disable cow individually, just using chattr ou something like that
<gcarlos>also, what's the difference between a manifest and a file that can be passed to guix package -i -f <file>?
<jackhill>apteryx: yes. I only tried once on a beefy machine, but yes it did
<apteryx>so it seems a CI/substitutes issue
<apteryx>it builds fine for me as well
<nckx>dgr: chattr +C, but the file has to be newly-created and empty.
<nckx>Or, well, had, since it's been a… while.
<apteryx>for anyone wanting to mass upgrade url-fetch packages, you may be interested in this fix: https://issues.guix.gnu.org/65230
<nckx>👀
<PotentialUser-60>Does anyone known of a laptop model which support completely open source software ( without property code)? With a working wireless WiFi?
<gcarlos>PotentialUser-60: out of the box?
<singpolyma>PotentialUser-60: depends what you count as code I guess
<singpolyma>ThinkPenguin is always going to get you closest for new and out of the box
<efraim>I'm using a pinebook pro with a wifi dongle
<efraim>webcam works, haven't tried audio
<gcarlos>the most problematic drivers usually are from wireless cards and video cards
<apteryx>can we use 'guix refresh -m' with a destination version specifier?
<nckx>I just received a response to my CVE request for Guix, saying that it's a duplicate.
<nckx>I sent this request in 2021.
<nckx>It wasn't a duplicate then, you boneheads.
<apteryx>haha
<apteryx>is there a neat guile trick to add the directory of a file to its load path?
<apteryx>it's for sharing a common source file between two similar manifests
<jackhill>apteryx: indeed, thanks for checking. I wonder if the build on CI should be retried or some such.
<dthompson>apteryx: you could do (dirname (current-filename)) to get the file's directory, and then (set! %load-path ...) and (set! load-compiled-path ...)
<dthompson>%load-compiled-path, that is
<apteryx>jackhill: done -> https://ci.guix.gnu.org/build/1622820/details
<dthompson>(set! %load-path (cons (string-append current-dir %load-path)))
<dthompson>ugh typo
<dthompson>(set! %load-path (cons current-dir %load-path))
<apteryx>dthompson: I'll try that, thank you!
<jackhill>apteryx: woo! Fingers corssed!
<dthompson>apteryx: yw
<apteryx>dthompson: isn't current-dir current-source-directory from (guix utils) ?
<apteryx>maybe Guile's include would be simple, seems to support relative paths
<apteryx>yep, that did it! (include "common.scm")
<dthompson>or 'load'
<jackhill>apteryx: well, the build succeeded, but it didn't produce the store paths I want to substitute. If I understand cuirass correctly, that build is from evaluation https://ci.guix.gnu.org/eval/604016 which is commit c75022d65f1fa18b8c4839e50f915e8f4d4fe305 from July 18th.
<dthompson>I thought you wanted to modify the load path
<dthompson>so that module loading would work
<apteryx>I didn't communicate my intent too well, apologies. What's the different between load and include?
<apteryx>looks like if I use macros I should 'include', but anything else could be 'load'ed
<dthompson>include splices the source into the file at expansion time
<dthompson>load opens it at runtime
<apteryx>thanks
<jackhill>apteryx: I did find a failing test on one of my other computers: https://paste.debian.net/1288676/
<jackhill>amd instead of intel. tmpfs instead of btrfs
<apteryx>interesting
<apteryx>is it reproducibleÉ
<jackhill>I'll find out soon :)
<apteryx>apparently there's a 3s timeout on that test
<apteryx>maybe you could try raising it
<jackhill>apteryx: yeah it just failed for me again. I'll see about increasing the timeout later (no promises!)
<vagrantc>looking for a reference for how to make an upstream guix.scm module for packaging the current git checkout?
<vagrantc>thought i saw one somewhere ... but did not find anything obvious in the guix cookbook ... and that seems a bit too specific for the manual
<RavenJoad>Is guix system image on the install.scm/installation-os supposed to fail with a type error for a resumable continuation when passing the -L flag?
<RavenJoad>vagrantc: As in a guix.scm for a repo that builds the current checkout? This one may help with that: https://guix.gnu.org/en/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/
<vagrantc>RavenJoad: thanks, that looks like what i was looking for :)
<RavenJoad>There are a few gotchas as you go further down the article (just some forgotten redirections with ..). If you want to get a full channel out of the repo, look at the .guix-channel and .guix/modules/guile-package.scm under the "Wrapping Up" section.