<nckx>Well, it's a file system in early development, features are still being written (snapshots landed yesterday). While it's usable and I think it will end well, ‘risks are very low’ is simply not realistic yet.
<Guest64>vivien, Thanks a lot for sharing your process. I think this can potentially work for me. Lets say I create a channel repo like you, where the build and release process happens with Cuirass taking continuous look at it and building binaries, and my source repo updates the channel repo upon every single commit. However, I do want my tests to run on
<Guest64>EVERY branch/commit of the source repo. Any pitfalls you see there?
<quidnunc>Why am I still seeing "hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these lines" after installing glibc-utf8-locales and setting 'export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"' in my .zshrc ?
<vivien>I don’t use Cuirass, I use a git update hook. This hooks lets me know the exact set of commits that have been pushed, so the server can build every one of them before they are accepted. I don’t know if you can run cuirass on demand, so maybe you will need to change a lot of things for your CI use case.
<Guest64>vivien: Looks like Cuirass has the capability to scan repos every so often, and build upon changes to them. At least that's what I understood from the "period" flag to it.
<vivien>If you store only the latest commit of master (or of all active branches), maybe Cuirass won’t build all of them and will skip some.
<Guest64>But looks like creating a channel-repo is really the only way to go about things, there is really no two ways about it. I can't really invoke a package build by Cuirass without having a channel in any sane way. Am I seeing this right?
<Guest64>vivien: I think Cuirass can run a lot more frequently than that. But I agree with you, I don't like it that Cuirass may not see commits in between.
<Guest64>vivien: Nevermind, Cuirass will run upon every single commit to the channel-repo
<vivien>You can use the same repo, if you add a .guix-channel file at the root it will be considered a channel. But to define your package, you need to write down the commit ID, and you can’t know it before the commit is closed. So you need to push 2 commits for each change: one with the change, and one updating the package. I think using 2 repositories is cleaner.
<vivien>(there’s specific content for the .guix-channel)
<lfam>quidnunc: I understand that it's counterintuitive
<lfam>It's typical in Guix that build-time dependencies are not protected against garbage collection, but the decision about what to garbage collect is not made based on "build time" vs "run time", but something much simpler
<lfam>After building a package, Guix scans the built output in /gnu/store for strings that look like a directory in /gnu/store. When it finds one, it records this in the Guix database as a "reference" of the built package
<lfam>Then, when you install a package, Guix knows to also download the references. And when garbage collecting things, this database of references is used as well
<lfam>So, your profiles are also store items. (You can do something like `ls -l /var/guix/profiles/per-user/quidnunc` to look at that`)
<lfam>If the built profile does not include references to the things used to create it, those things are not protected against garbage collection
<lfam>Now, maybe we should invent a special case for profiles to protect these un-referenced build-time dependencies from garbage collection. You are not the first person to ask about this!
<lfam>But, the tricky thing is, the next time you build a profile, the same programs may not be used, especially if you have run `guix pull` since the last time you created a profile. Since `guix pull` updates Guix itself, it's expected that it may also change the dependencies of Guix, and the programs used to create profiles
<awb99>I am trying to add USER SERVICES to my guix config. I cannot figure out how to pass the script dir for this. I guess I have to create a .config/.bashrc file, where I export some kind of path.
<nckx>quidnunc: That will get you 95% of where you want to be! I think it will still happen that you have <foo> installed into your hacky profile, and ‘guix pull’ will download another <foo>, and that just bugs me. 😛 That and the manual aspect (same with hard-coding some ‘treat these specially because guix pull tends to use them’ packages — yuck).
<jgart>hi in order to compile dwm from source without writing a package definition I need to do the following in an environment containing dwm: make CC=gcc FREETYPEINC=/gnu/store/j602xc2fnj15rqnj8x1vnmpq6qzv0n35-freetype-2.10.4/include/freetype2/
<jgart>or readlink -f $(which freetype) but to find a useable /gnu/store/j602xc2fnj15rqnj8x1vnmpq6qzv0n35-freetype-2.10.4/include/freetype2/ directory
<qzdlns[m]>hi guix, should i be able to access arbitrary web services from other lan devices on the standard networkmanager config (I would assume permissive iptables defaults)? trying to access jupyter from another machine with no joy
<qzdlns[m]>lispmacs[work]: thanks for the help, I will try again tomorrow
<lispmacs[work]>qzdlns[m]: okay. my next thought was to wonder if it had something to do with the port number involved
***califax- is now known as califax
<char>I am creating a package. It builds fine but the test fails. When I do guix environment --pure. It builds fine and the test pass. How to debug? When when auto testing, it says libwx_gtk3u_xrc-3.0.so.0 cannot be found.
<apteryx>then 'cd /tmp/guix-build-*'; . environment-variables; cd build; <whatever debugging you wish to do>
<char>apteryx: I would think if it can't find the library then the error is related to the environment variables.
<apteryx>actually if it builds fine and fails in 'guix environment --pure' you probably want to get closer to the build environment by using 'guix environment --container'. This will disable networking. If it still passes, try 'rm /bin/sh' once in the container
<civodul>so gdb just checks that the separate debug file has the same build-id as the code, right?
<civodul>it doesn't matter whether it really is the sha1 of all those sections, does it?
<mjw>that is kind of the whole point of the build-id, that it captures the whole build environment, not just the generated code, but also how it was generated (which is what the .debug sections kind of represent)
<mjw>civodul, no, it doesn't need to be a hash over the actual bits produced. It can be a completely different hash, it can be a different number of bits (but not too short, they need to be globally unique).
<civodul>ok, so we could have our own way of caculating build IDs
<mjw>civodul, all that really matters is that it uniquely identifies this binary blob. If any input, source, compiler, flags, etc. changes, it should be unique.
<PurpleSym>civodul: Not just annoying, pretty serious. I think there’s no substitutes for openjdk right now due to this bug, leading to local builds of the entire openjdk chain, which needs a shitton of diskspace and usually fails if /tmp is a tempfs.
<cbaines>PurpleSym, bordeaux.guix.gnu.org should have good substitute availability, for example, I think it has substitutes for openjdk currently
<PurpleSym>cbaines: I can see it with `guix weather`, but `guix build` is trying to build it locally. Strange.
<cbaines>PurpleSym, are you on Guix System or a foreign distro?
<abrenon>why are there a pandoc and a ghc-pandoc package in haskell-xyz ?
<abrenon>is it a common pattern when a CLI tool is implemented in a language with a specific prefix for it, and exists as "the package in the language" + "the package as a language-agnostic CLI tool" ?
<abrenon>or is it just due to the particular needs of pandoc ?
<roptat>yeah, I think in the case of pandoc, it's a bit difficult. my understanding is that it provides a haskell library, that you get with ghc-pandoc, and a binary that you get with pandoc (statically linked, so you don't need to install haskell libraries too, maybe?)
<dongcarl>glibc also lists the /lib64-prefixed paths under SYSDEP_KNOWN_INTERPRETER_NAMES in sysdeps/unix/sysv/linux/powerpc/ldconfig.h rather than the /lib-prefixed ones
<dongcarl>nckx: Did you say you have an existing ticket for this? Perhaps it's better discussed on the ML
<nckx>I wonder if it would be a good return on investment to just force /lib at the root of the toolchain, to avoid having to carry (if riscv64 "/lib64" "/lib") in places. But I don't know if we would.
<nckx>dongcarl: No no, that was for my previous line about an unrelated issue.
<nckx>We've definitely discussed /lib64 before, in general, and why it's not a good idea. This is more specific though. I dunno… I mean, don't forget that the standard says ‘/lib64/ld64.so.2’, not ‘$prefix/lib64/ld64.so.2’, so we're already using a different name 😉 (Is this a strong argument? Probably not, but I feel like there might not be any in either direction.)
<Aurora_v_kosmose>Well that and "Guix has a broad definition of “service” (see Service Composition), but many services are managed by the GNU Shepherd (see Shepherd Services)." Many suggests not "all".
<nckx>I've been using dehydrated but I'm not entirely confident it will be updated when required (hard to tell if upstream is just resting, or dead). Uacme sounds like an interesting alternative. Thanks!
<vivien>Your penultimate message was blank to me ^^
<nckx>Which font do you use? Mine had a font rendering bug (I don't think it was in HexChat directly, but HexChat may well use, er, ’seasoned’ APIs that few others do) where the bottom row or so of pixels got cut off with some fonts (notably Cantarell), leading to gs looking like qs and would probably lead to what you describe. But it also seems to have magically fixed itself (which further implies a cause & fix outside of HexChat).
<nckx>So maybe play around with fonts to see if it's related.
<attila_lendvai>it would be really nice if union-build were a little smarter and did at least an an alphanumeric sort at collisions... but the required information is not available at that low level. and parsing the paths feels fragile, although any breakage would only revert it back to the corrent behavior (first in an unorderred list)
<attila_lendvai>or can i use e.g. %store-prefix to drop it from the front, and then drop the hash?
*attila_lendvai has found store-path-base, which is exported, and embarks on a journey with it
<Aurora_v_kosmose>nckx: \a: Actually, I'm curious about that. btrfs ran out of memory while checking a filesytem?
<nckx>Hence the if above, which is basically what the final patch looks like.
<nckx>But thanks for pointing it out. I'm familiar with btrfs only from past usage.
<Aurora_v_kosmose>I'm slowly moving stuff over to it now that it has implemented features I was waiting for. My ZFS storage is basically waiting for it to include a native caching layer before porting time.
<Aurora_v_kosmose>Needed because SMR is likely to the way for the next decade and ZFS hasn't even started implementing zoned-storage support.
<Aurora_v_kosmose>That or they're going cathedral style and the implementation work isn't publicly visible yet.
*Aurora_v_kosmose doesn't actually know how ZFS is developped.
<Aurora_v_kosmose>Because not even all dm-smr implements TRIM, so you've got drives that basically die once you've written their full size once, unless there's some way to trick the controller into garbage collecting anyway.
<nckx>attila_lendvai: Something tells me you're not talking about adding srfi-43 to the define-module at the top?
<attila_lendvai>nckx, i want to use srfi-43 in guix/build/union.scm. i have added it as a #:use-module (srfi srfi-43), and all is well: in the repl it works, and my code works. then i run the tests, and i get this error.
<nckx>Well, I have to go, but I will probably be back.
<attila_lendvai>nckx, if i remove the use-module, then i don't get that error anymore
<attila_lendvai>nckx, if i do something (probably make clean), then the test does more work, including the downloading of stuff. it prints: unpacking bootstrap Guile to '/path/guix/guix/test-tmp/store/qky0jf68rr7pnsvmhj0ay42rzh4qk6r9-guile-bootstrap-2.0', and a long list afterwards that does *not* containt srfi-43.go
<attila_lendvai>nckx, and i have found a comment: "Use the bootstrap Guile when running tests, so we don't end up building everything in the temporary test store."