<ryan77627>Awesome, I will try that. For future reference for myself, how would I go about finding things (like these variable names I always see in docs) out so I don't need to come and ask every time, I'm trying to learn the system :)
<bjc>i use ‘guix search’ to find them, although that only shows packages, you can see *where* they are defined, and then search through that file
<RavenJoad>I am migrating from msmtp's old msmtpqueue scripts to its new msmtpq and am having trouble figuring some things out. Does someone else here use msmtp and msmtpq who would be willing to share their config(s) with me?
<RavenJoad>Something Nixpkgs has that I am not sure we have in Guix is a program/scripts that builds all dependent package updates. Meaning if I update something, I can run the script to build all packages that would be affected by my update. Is there something like that?
<podiki[m]>do you have sbcl in the same profile installed? it should find via that search path I would think, but there was some message/bug report about this we should sort out if true
<flora1[m]>"I'll teach 10individuals how to earn $100,000 in 72 hours from the crypto market. But you will pay me 10% commission when you receive your profit. if interested send me a direct message by asking me (HOW) for more details on how to get started
<RavenJoad>lfam: Ok. May I see your muttrc config then? I am trying to adapt my mu4e config.
<spiderbit>also question try to find out how xterm would change the title when I change the path, currently the title is fix "xterm" not only the class that is "Xterm" but .bashrc is some link probably because I use homeconfig
<podiki[m]>spiderbit: yes to the question of modules; e.g. just python-<some pkg> doesn't give you the search path for python to find the module, so generally you want the tool/compiler/etc. and the modules together
<podiki[m]>as for your other questions I don't follow, sorry; and need to run
<spiderbit>podiki[m] ok would be really nice I even wrote my own rofi-stumpwm window switcher because I could not got ttf-fonts for stumpwm included
<RavenJoad>spiderbit: Part of the reason StumpWM behaves a bit strangely when loading the stumpwm-contrib modules is because StumpWM's *module-dir* variable is set to $(pwd)/.stumpwm.d/modules at build-time. The $(pwd) expands to /tmp on a running system. That is something I wanted to tackle long-term.
<RavenJoad>Neither. It is a behavior of StumpWM that I tracked down a while back. You can use the set-module-dir function with a string argument with the path to the stumpwm-contrib modules on your system.
<podiki[m]>oh for modules I use a local git checkout anyway, so maybe my advice before doesn't help for that
<RavenJoad>lfam: Ok. I guess I might be over-complicating my mu4e config for queuing then...
<spiderbit>that's when you adapt stuff to your format :D
<podiki[m]>but generally for something like sbcl or python to find modules it needs to be in a profile together
<lfam>RavenJoad: I'm sure there are other people here using mu4e + msmtpq
<podiki[m]>ACTION has to be off, will push more python core-updates fixes later
<RavenJoad>spiderbit: I intend to eventually get around to getting the stumpwm-contrib packages composed with regular StumpWM in such a way that you specify both and a /gnu/store path is used instead of /tmp for *module-dir*.
<RavenJoad>lfam: Probably. I originally wrote my config on OpenSuSE and NixOS using very old versions of the software stack. Currently bringing a 3 year out-of-date config back to life for future-proofing.
<spiderbit>ok restart-hard killed stumpwm have to logout for a sec
<podiki[m]>apteryx: are you familiar with python-llvmlite? there's a phase to fix the libllvmlite.so loading but i'm not sure how to test it. seems to build fine and python-numba passed its long test suite
<podiki[m]>so i'm thinking to remove that (and the fix test phase since that passes for me too) and update it to python-numba and dependents will build
<zacchae[m]>Alright, I am satisfied with my initial setup of guix home on my Librem 5. There were some hiccups which have been addressed. I think it's a good starting point for others.
<zacchae[m]>Is there a good place for me to put a guide detailing what I've done?
<zacchae[m]>If I send a guide in an email to firstname.lastname@example.org, will people be able to find it?
<ChocolettePalett>Well, I found some useful stuff in those emails, but only because it was indexed by search engines
<podiki[m]>cuirass doesn't seem to be building x86_64 right now...hopefully comes back soon, there's a bit of a back log now; night guix!
<dds>hey guix hackers. would you say that it is efficient in the long term to fully learn and use the standard emacs keybindings or is evil better? i feel evil mode brings too many inconsistencies with the rest of emacs, even with evil-collection. what do you think?
<ngz>"guix substitute: warning: ci.guix.gnu.org: connection failed: Connection timed out" :( Builds on powerpc64le are failing on CI.
<evilsetg[m]>I think evil is great and after a while of adapting it works really well with everything. I never learned the standard keybindings though. In the I landed in a spot somewhere in between using only emacs or only evil bindings, so it's kind of a weird miz. But for me that is fine, every emacs config is unique anyways.
<tribals>I'm trying to set up build offloading to another machine. Actually, I'm having two - one is cloud provider and one is my personal hardware. Cloud runs Guix System, and personal one using foreign distro installation. I set up cloud machine to become offloader successfully, but can not to the same to personal one.
<rekado>andreas-e: tensorflow-lite is for inference on mobile devices
<ffrrnn>Does guix, in this regard, avoid all forms of dependency looping?
<ffrrnn>ngz: Just in the sense that an output causes the analysis of its inputs, with a memoized tree allowing the algorithm to avoid unnecessary remaking.
<ffrrnn>Perhaps I don't mean looping, either. I mean instead that dependencies are not singular, and that instead, different dependencies that would normally be shared on a system can coincide--is that right? Does that mean that every package must be very carefully specified for that sake?
<ngz>AFAIU, there cannot be dependency looping because all inputs have to be resolved before building. If an input is already built, it isn't built again when another package depend on it.
<ardon>Hi Guix, is there a way of having a local channel not use an absolute path? I want to use a single channels lock file in two foreign distro guix home installations but each one has different usernames. I found no way of specifying a relative path with file:// to point to the local channels
<nutcase[m]>ChocolettePalette: Thanks, I'll have a look into it
<blacktoad>Hello Guixers. I built Guix from source code. Then when I run "make clean-go" I get this message: "warning: stray .go files: guix/build/po.go". Is this .go file supposed to be deleted like the others?
<mirai>apteryx: nice! thanks for doing the S&D phase of the plan
<apteryx>yw, it had been annoying me for a while, thanks for fixing it!
<gabber>i'm facing challenges with setting up my childhurd setup. i've set it up according to the blog post but now `guix build git -i i586-gnu` fails building openssl -- it doesn't offload correctly. also: `ssh childhurd` does not work as described in the blog post. do i have to add an entry to my /etc/hosts for that to work? i can connect to the machine when specifying identity file and port manually
<apteryx>mirai: 'conflict in profile' seems a bit niche; most projects should focus on using a single version I guess
<apteryx>but if you have an itch to scratch, a fix would be welcome
<mirai>oh, it's mostly so that it will work within a guix shell (for authoring, etc.)
<mirai>sure, I'm not too familiar with this area but it seems doable
<mirai>is it only docbook-xml package that needs tweaking or does it involve libxml2 as well?
<apteryx>just docbook-xml I think; the search path seems written in a way that would still work
<andreas-e>blacktoad: I also see this and usually remove it; but I think it is harmless to keep, and it will be recreated if something changes. I think we should add it to a Makefile somewhere. I will file a bug.
<andreas-e>Most of the time the warning refers to .scm files that have been removed; then keeping the .go file also does not hurt, but it may as well be removed by hand.
<mirai>apteryx: where can I read more about this ”conflict in profile” thing (how do they work and what's going wrong with the current docbook package?)
<mirai>or perhaps a package that I can use as an example?
<mirai>sidenote, the good thing with the fixed catalogs is that we now have a better chance at getting shared-mime-info updated so that AVIF, AV1 and other file types will actually work on guix
<apteryx>mirai: profiles are a union-build of all the packages' files joined
<mirai>since the pixbuf stuff (and possibly other things as well) rely on the mime database to know how to handle the files
<apteryx>if two files share the same file name, they conflict, and the first one takes precedence
<gabber>nvm, i think i found (some of) my mistakes
<apteryx>this morning's offload problem is: guix package: error: corrupt input while restoring archive from socket
<apteryx>it tries to send a lot of sources over the wire to be built
<andreas-e> attila_lendvai: Yes, I have also been surprised by it.
<nflqt>Hello. I would like to report a weird thing on the french installation instructions. Can I write in my language?
<andreas-e>wdkrnls: I would not say that there is an "issue of downloading files within the builder". It is not possible, period. All inputs to a package need to be specified in the recipe. You cannot have functional package management when downloading random stuff.
<andreas-e>nflqt: Bien sûr, si tu es prêt à baisser tes chances d'une réponse. Peut-être qu'il serait utile de faire un rapport de bogue le cas échéant que quelqu'un de l'équipe de traduction peut traiter.
<andreas-e>attila_lendvai: This may have to do with grafts again. You install grafted packages, then "guix gc" removes the ungrafted ones; when you pretend to install the same again, Guix does not see that they are the same until the ungrafted packages are downloaded again, and maybe regrafted.
<gabber>nflqt: no, it verifies whether the iso was really created by one of the people you have obtained a public key from
<andreas-e>Si, une signature numérique vérifie les deux. Si tu changes un bit à .iso, la signature ne sera plus vérifiée. En fait la procédure de signature commence par calculer un haché (qui n'est plus MD5, mais peu importe), puis signe le haché. Sinon la signature serait aussi longue que le fichier à signer.
<andreas-e>civodul: Incredible, I do not even remember we had something like this. It must fill the mailing list server with information nobody ever reads!
<andreas-e>Ah, the good old times when we had so few packages that breaking one was an event!
<mvnx>wdkrnls: I only looked into it briefly so I don't have the full story but it looks like the build system was never updated to build for Go modules. I also need this because package restic is too far out of date for me. It's way too above my skill level to contribute at the moment. The Nix Go build system would probably be a good point of reference since there was a point it had to support Go modules as well.
<jpoiret>seems that the running zig binary has a borked GOT table for some reason :/ it's starting to get a bit too out of my comfort zone, I'd probably need to debug what ld is doing (and might be related to the move to a PIE glibc)
<gabber>any practical ideas on how i could test my unified home-night-time-service-type? is it easiest to create a vm and then configure a home environment with that service?
<andreas-e>gst-plugins-bad exceeded its test times again, so we lost gnome again. This can probably be fixed by restarting the build, but with all packages depending on it, this is a lot of boring busywork :-(
<mirai>andreas-e: looking at the definition for kdoctools, it has a substitute* for "cmake/FindDocBookXML4.cmake"
<mvnx>I guess yeah, `go mod download` and `go mod vendor`
<andreas-e>jackhill: I did not quite understand the problem with LUKS. The security should not depend on the speed of the key derivation function, but on the entropy of the passphrase. Of course you should use passphrases with 128 bit of entropy ;-)
<mirai>so my guess is that it wants docbook 4.x (which version exactly will require looking at the sources and seeing the what the DTD declaration says)
<mirai>I wonder if those substitution snippets are still required
<nflqt>Zut! L'installateur me prévient que la carte wifi de mon ordi (Intel Corporation Wireless 8265 / 8275) ne dispose pas de pilote libre. Est-ce qu'il y a la possibilité de la faire fonctionner a posteriori sous Guix System ?
<andreas-e>mirai: Yes, I just compiled it with docbook-4.5. Strangely before, it was compiled with docbook-5 (5.0.1?), which still worked.
<mirai>is there an easy way to download the source of this?
<jackhill>mvnx: I think the general approach is to keep the sensitive data someplace that grub doesn't have to unlock, either by having unencrpted /boot (not well integrated in Guix System, but possible) or haveing a separate partition for data that is not needed for boot.
<andreas-e>nflqt: Non. Le noyau linux-libre refuse de charger un firmware non libre. De mon côté, j'ai une carte wifi Atheros dans une clef USB.
<jackhill>mvnx andreas-e: right passphrases that are stored in (human) memory are bad! Using a separate hardware token to store the passphrase might be the way to go.
<andreas-e>mirai: You mean "guix download kdoctools -S"?
<mirai>andreas-e: ah, the previous docbook-xml name is misleading, it's inherited from docbook-xml-5 but the version is "4.5"
<andreas-e>Ah, I see. So you changed variable names, which automatically updated every package to docbook-xml@5. And if it does not work we need to replace by docbook-4.5.
<mirai>yes, though if you really want to be “right” about things then you have to find out exactly which docbook version was used to write the documentation
<andreas-e>Then I will just upload my fixed kdoctools without checking whether the remainder of KDE will build with it. Let CI be bothered with the compilation!
<mvnx>jackhill: I'm fine with unencrypted boot but this may be a struggle for me if it's not well integrated in Guix
<andreas-e>Actually CI would not even need to rebuild things, I think, since it is just the status quo ante. The derivation will not know about the name change.
<mirai>there was a name change and a change to the build-system
<jackhill>mvnx: yeah, indeed. I don't have references handy to how to do that, but it would be good to get those cleaned up and an option by default. It would be useful for more than just this too, like booting straight from u-boot to fancier disk setups, etc.
<apteryx>andreas-e: is kdoctools still in need of fixing? I'd replace docbook-xml with docbook-xml-4.5
<mirai>including some permission changes (I doubt the X in XML stands for Executable)
<mirai>different canonical names but same virtual symbols
<civodul>mirai: "conflicts" had actually become non-existent since the introduction of "replacements" in the Shepherd, years ago
<civodul>in 'master' i've removed traces of "conflicts"
<mirai>is it feasible to have 'replacement' support in guix?
<civodul>it's there already: it's used anytime you reconfigure
<mirai>I'm getting uneasy with my horrifying approach for a btrfs-scrub service
<mirai>so, the idea is to have a service that does “btrfs scrub start …” but in the case that it doesn't complete due to a reboot or $REASON, it uses activation-service to create a transient service that performs a “btrfs scrub resume …” which is launched after boot
<mirai>but rather than all this horrifying circus across the subsystems, perhaps (shepherd-service …) could make use of a replacement field instead?
<mirai>idk if we can matryoshka the record-type definition this way since the value for this replacement field would be a shepherd-service itself
<mirai>another thing I'd like to know is if “herd start foo 1 2 3 4” will result in “1 2 3 4” to be passed as arguments to the procedure in the start field
<nflqt>Est -ce que H-node fait toujours référence pour le matériel ? 😃
<andreas-e>civodul: You mean merge to core-updates? I suppose it rebuilds everything with subversion sources?
<andreas-e>Then we could combine it with the valgrind/lz4 commit, that would bring R and some texlive packages back to powerpc.
<andreas-e>We should then make sure they are pushed at the same time, to avoid cuirass evaluating two commits and possibly building more or less the same packages twice.
<blacktoad>Excuse me, I compared the list of .scm files in "MODULES" variable in Makefile.am with the list of built .go files. It looks like "guix/scripts/import/cpan.scm" is missing from "MODULES". Is this intentional?
<andreas-e>I am mainly worried about aarch64. I think the other architectures are being built sufficiently fast now so that we can cope with even moderately large rebuilds.
<andreas-e>Now that the Guix Data Service is offline, we have almost no vision of the status of aarch64.
<andreas-e>Why does one need several docbook versions in the same profile?
<mirai>andreas-e: if you're authoring some documents which for $REASON are in different versions
<mirai>but fundamentally they're DTDs and are organized specifically not to conflict with each other
<andreas-e>Then why not use different profiles? This amounts more or less to the same thing, no? Binaries with the same name end up in different directories.
<andreas-e>But apparently upstream creates the conflict then. I would go upstream with the problem.
<mirai>upstream does it like this “/usr/share/sgml/docbook/xml-dtd-4.5/ent/isonum.ent” (overlook the SGML for now)
<mirai>well, the 4.x series should actually place the SGML files in a sgml/ dir and a catalog.xml in xml/ anyways but I only wind of that a few days ago
<mirai>I'll try taking a stab at the issue and see if things can be fixed without introducing more patches
<andreas-e>I see, we use the copy build system. Then I have no opinion. We should do what is common so that our software finds what it needs ;-) For instance, if we could drop the substitute* in kdoctools, this would be a plus.
<andreas-e>The FindDocBookXML4.cmake has a line for the Nix package manager, I wonder if this could not work for us as well.
<andreas-e>10 minutes of clocking between building gst-plugins-bad and restarting everything needed for gnome. It is like a computer game. I am getting good at it!
<andreas-e>Why does something called "gst-plugins-bad" is even considered as an input for something as important as gtk+? Should we not take it out?
<andreas-e>Time to see if I can switch my system and user to core-updates!
<andreas-e>No. For x86_64, we miss substitutes for openjdk (19 down to 9), icecat, ungoogled-chromium and qtwebengine (for calibre).
<andreas-e>civodul: Honestly, it is too late for commits with costly rebuilds. They tend to cost us one day for being up to par (not even speaking of aarch64), which is incompatible with the merge schedule.
<civodul>andreas-e: yeah, that's what i thought; we can always do that afterwards, that's fine
<civodul>i thought i'd ask anyway, just in case :-)
<mvnx>andreas-e: What kind of effort would be required to set up your own subsitutes for those? I was thinking maybe you could fire up low-cost one time builds for every new version on some cloud provider and then push the substitutes to a CDN - many free options there at least for bandwidth required for personal use.
<mjw>andreas-e, we are working on valgrind 3.21.0-RC2 right now (with 3.21.0 final end of next week). Any of these valgrind commits you want to see upstream or is this all guix specific?
<andreas-e>civodul, rekado: Cuirass not doing topological sorting is terrible. pankow has been building abbaye for over 24h now. That is because it does not build abbaye, but recursively its inputs. So now it is at gcc. So what can happen is that in parallel another build machine builds gcc for another package. In fact *all* aarch64 build machines might be stuck building the same gcc, if I understand things correctly.
<andreas-e>What is worse: GC runs every night. So once abbaye is finished, gcc may be garbage collected, and be rebuilt for the next leaf package. I think in the worst case we may end up rebootstrapping the whole chain for each and every leaf package.
<lfam>The related problem is that there may be no way to search for or view the job that built GCC
<andreas-e>mjw: It is not even a commit of valgrind. We just want to upgrade to 3.20 and remove it as an input to the lz4 package. So only internal "bookkeeping", but it would require us to do quite a few rebuilds. Thanks for reaching out!
<lfam>andreas-e: Unrelated, are you preparing for one last big rebuild of core-updates?
<andreas-e>lfam: No, I hope the rebuilds are over. Just leaves or things close to them. I hope for a merge on Tuesday.
<mjw>andreas-e, haha, so I am actually making you sad working on a 3.21.0 release, then you have to do lots of rebuilds again :)
<lfam>Okay andreas-e. We missed updating the time zone database, unfortunately. Well, the true misfortune is that our packages depend on it, which is ... demented
<andreas-e>lfam: If there is no gc, the problem is not as bad; the gcc will remain in the store of the build machine, and if cuirass asks for it, it will be returned immediately. This works particularly well if there is only one build machine and no gc.
<lfam>Well-behaved programs look up the database dynamically at run time, and do not depend on it statically
<mjw>andreas-e, BTW. valgrind 3.21.0 final is scheduled for upstream release next Friday April 28th. And I am fairly confident about that date. RC1 had some small issues, RC2 is looking good. Don't expect any blockers to pop up.
<andreas-e>mjw: Nice! Someone else can do the upgrade and rebuilds in Guix then ;-) I will be on vacation.
<lfam>It's hard to tell andreas-e. The rust packages don't work with `guix graph`
<lfam>We are working ourselves into a corner without it
<tribals>I'm trying to set up native builds in Guix on a foreign distro. I already set up binfmt for aarch64 in order to utilize `--system` option. But whenever I'm trying to build something I got strange errors like `/gnu/store/xxx-guile-3.0.7/bin/guile` not found. I tried to build it, and it builds correctly, but hash is different from what command tries to execute
<tribals>I have another machine, which is Guix System. And there native builds just works.
<andreas-e>mjw: Yes, exactly. We replace /lib by */lib in the suppression files.
<andreas-e>lfam: You mean register with tzdata that nobody should keep a reference to it? So behave as if tzdata would be added as a #:disallowed-reference to all packages? That looks like a nice feature.
<andreas-e>civodul: This is already done, I think. So once it exists, it is downloaded. But if I understand things correctly, cuirass orders the offloaded tasks; out of 10000 packages, it may put gcc last. Then it asks for 9999 offloaded builds, and the build machines start building gcc, but never send it back to cuirass, because they were not asked to.
<andreas-e>The argument that Rust is already needed is another reason to switch, not to keep the Java dependency.
<andreas-e>But seriously, is there a reason why "./pre-inst-env guix build openjdk@19 -n" starts at 10 on my laptop, and 17 on berlin? If the other packages are built, why do they not show up as substitutes?
<podiki[m]>andreas-e and apteryx: any thoughts on python-virtualenv? it is quite outdated and poetry needs a newer version; virtualenv is like ~430 dependents; poetry doesn't have many dependents but the failure i'm looking at is yubikey-manager which i'd say is pretty important for users
<podiki[m]>complicated by virtualenv i think needing some hatchling packages added so I haven't actually seen if it builds and if i can then fix yubikeymanager, so a bit theoretical
<podiki[m]>I could try and see if it is reasonable first
<apteryx>podiki[m]: there's now hatchling on core-updates with two of its extensions
<lfam>The bulk of the tzdata madness is through the Go compilers, which evade inspection via `guix refresh -l`, since that tool doesn't capture build-system dependencies. Unfortunately, other languages now depend on Go in Guix, so the embedded (???) copy of tzdata we add to Go causes many thousands of reverse depenencies. There are also a few thousand reverse dependencies via libical, a problem which is now almost 5 years waiting for an upstream release:
<lfam>As long as the linter doesn't alert on a huge number of packages, sure. I think that enforcement is better than warning for policies that will impact a large number of packages. Or else we will have to answer the same question a million times
<lfam>I'm creating a local branch to cherry-pick the Nix patch to libical, and changing Go to use tzdata-for-tests, which could perhaps be renamed to tzdata-pinned or whatever the conventional name is for packages like this
<lfam>Also going to try building Go without tzdata at all
<mirai>lfam: are the linux-4.x and linux-5.x system tests supposed to work?
<podiki[m]>perhaps I'll have to pre-emptively start a python-updates branch for these, all that to try to get yubikey-manager to build...
<podiki[m]>so far pretty trivial changes, except a bunch of virtualenv's tests don't pass/error (looking for windows stuff, trying to use pip to download, etc.)
<podiki[m]>civodul: was that "uh" for this discovery of very outdated python core packages?
<podiki[m]>sigh...and requires building inkscape, webkitgtk-with-libsouop2, gst-plugins, ...I'm guessing from some substitutes missing not these updates but I guess I'll let everything build locally and see how it goes
<bjc>i'm amazed at how deep in the package graph inkscape sits
<civodul>podiki[m]: yes, it always feel daunting to me when deep Python packages need an update
<lfam>I forgot, but python-pytz contains its own copy of the time zone database and has a few thousand dependents. But thankfully it looks like that's being replaced in Python-world with new support in dateutil, although I have no idea if dateutil does the right hting or not: https://fedoraproject.org/wiki/Changes/DeprecatePytz
<lfam>I wonder why changing the Go compiler, libical, python-pytz, tzdata, and tzdata-for-tests packages cause the Rust compilers to be rebuilt
<podiki[m]>jackhill: i know some python but not up on the packaging ecosystem; virtualenv doesn'
<jackhill>lfam: yep. I'm kind of hoping that core-updates will fix some of the broken builds, or at the very least I'd rather troubleshoot on core updates. In the meantime, may as well try to help core-updates along however I can.
<bjc>any rust people here? is there a way to cache the ‘patch-cargo-checksums’ or ‘upacking’ phases across builds?
<bjc>i assume the reason it uses every crate on the system is because building the graph of crates is hard for those steps
<lfam>You should keep waiting for a more expert answer, but I know that our rust package building doesn't work in the "normal Guix" way, and doesn't even have a concept of dependencies that can be manipulated with the Guix tooling, due to a large number of dependency cycles in Rust-world
<singpolyma>Someday we'll invent a way to handle coreqs in guix
<bjc>i was wondering how the dependency cycle tracking was working!
<bjc>if there's no way to limit the unpack and patch-cargo-checksum phases for rust, it has to be adding a tremendous burden to ci. they're, by far, the longest step in most crate builds, and it happens for so, so many crates