<vivien>So I noticed that gnome-tweaks is broken on core-updates-frozen too, it won’t start without libhandy 1, and then it won’t find its own python module. Here is my patch: https://issues.guix.gnu.org/51731
<zamfofex>civodul: I decided to try to apply my Hurd changes to Guix as a patch, and then it failed with an error that I assumed has to do with the outdated glibc in ‘master’. I switched to ‘core-updates’ to try again with a newer glibc, and I’ve been waiting for over twelve hours now!
<vivien>That’s a bit unfortunate, because we need to recompile both rust and webkit
<zamfofex>It makes me wonder how Rust and Webkit are relevant to what I’m doing. Are they necessary for some basic package that is used extensively or something?
<rekado>I’m just trying to build the installer so that I can install Guix System on the honeycomb boards.
<Guest79>Hi, I recently decided to try guix-the-system (moving from arch) and followed the manual installation instructions. I have a two-disk efi setup, disk A being / and /boot/efi on separate partitions, and disk B being one partition with multiple folders that are bind-mounted at /home, /opt, /var, /usr, /share, and /gnu. Disk B and its bind mounts are
<Guest79>marked required for boot. The problem is: the bindings don't exist when grub tries to load bzImage from the raw-initrd folder in /gnu/store (so boot dies shortly after the grub menu).
<Guest79>Is there a way to have guix put the image in a more accessible location?
<Guest79>(without the obvious cop-out of giving up on bindmounting /gnu, ofc -_- )
<Guest79>Oh woops, correction: it can't load the bzImage from linux-libre in /gnu/store (as opposed to raw-initrd)
<lfam>the_tubular: Regarding #47229, can you say more about how it's an RCE? I had considered it as a local privilege escalation vulnerability, but not remote
<Guest79>I'm clearly out of my depth here. Would I be risking catastrophic meltdown by testing out replacing 'statfs64' with 'statfs' on line 843 of gnu/store/0iii8i1lc4wg3wccs1db7y7d8lg80i04-guix-1.3.0/share/guile/site/3.0/guix/build/syscalls.scm ?
<Guest79>(I'm assuming that long string is the git hash - more conceptually I mean changing what I assume is the dynamically linked symbol)
<Guest79>Okay apparently there're two versions of statfs with different ABIs and I'd been misreading the man pages, and statfs64 looks like it's supposed to be the right one...
<lfam>Guest79: You really don't want to try editing things in /gnu/sotre
<lfam>But if the system is already not booting, you might proceed, with caution. If the data on the system is important to you, you should back up the disk before you start editing /gnu/store
<lfam>Somebody else will be able to give better advice
<the_tubular>I can give you the whole traceback, but here is the relevant info : pkg_resources.DistributionNotFound: The 'python-dotenv<1,>=0.13.0' distribution was not found and is required by docker-compose
<the_tubular>I might use guix rollback, but is there anything I should try before ?
<char>I got it. I had to run mariadb-install-db to make some files, and I had to run mariadbd-safe to create the sock file. I also had to pass --datadir=./data.
<Guest79>Is there an equivalent to arch-chroot in the guix install medium? To run e.g. guix system reconfigure from a recovery-disk?
<apteryx>the install iso of guix can be used to do this, yes (it comes with guix)
<Guest79>apteryx: how? I've tried manually preparing a chroot from the install iso (dev mounts procfs sysfs etc) only to find that e.g. /mnt/bin is unpopulated and it being unclear how to tell guix to fill out PATH and such
<apteryx>ah right; that's a bit tricky. I've done it twice using some information found on guix-devel
<apteryx>can't find it again; but I think you need to execute the boot script of guix in the chroot to populate things
<sneek>xd1le, apteryx says: I may have asked this before (apologies if I did), but what's an easy way to test a newer guile-ssh with guix offload? do I need to run the daemon from the checkout?
<fcw>Hello, I managed to package smlnj for Guix. There is an existing WIP patch in the guix-patches mailing list (https://issues.guix.gnu.org/38606). Where should I send my patch? Should I send my patch to the existing WIP thread, or should I start a new thread? Thanks.
<rekado>.guix-profile is just a series of links into /gnu/store/…-profile
<rekado>and you shouldn’t ever write to /gnu/store; only the daemon may do that.
<abrenon>that, I know, and I wouldn't even want to think about attempting it
<abrenon>but, .guix-profile is a nice link to a writeable dir in /var which my user own, so I thought I could put a file in there to provide a temporary fix before I publish a patch to add a missing file in a package
<vivien>abrenon, follow the symlinks, you end up in the store :)
<abrenon>(I don't mean to write on one the links to update one of the files there, I know that's not possible and that's not my intent here)
<abrenon>ahhhh the guix-profiles-n-link themselves on the way to the directories point to /gnu/store !
<efraim>civodul: for today's presentation I'm going to show a proof-of-concept for working on newsboat (or other rusty packages) using `guix environment` or `guix shell -D`, since I plan on fixing the dependency tree AND documenting it ... within the next 6 hours
<vivien>For instance, on a C project, suppose that two different features implement a new function with the same name (in different locations). Suddenly, everything is OK but the linker fails because it has two functions with the same name.
<vivien>So, there’s no merge conflict, but the merge still breaks the program anyway.
<M6piz7wk[m]>shrug still think it's worth the time considering pijul
<abrenon>M6piz7wk[m]: I didn't find the video to be very clear, like "ok, category theory show you how to build a pushout", but I didn't see anything that explains why merging would work differently in pijul
<abrenon>it looks like a scientific rephrasing of the common merge issues (a diagram not commuting), what is different in pijul that makes it behave differently compared to other VCS ?
<M6piz7wk[m]><jpoiret> "6piz7wk: it also requires all..." <- would argue for standardized environment and tools
<efraim>this would be less error-prone if I did cargo-inputs -> inputs and left the development-inputs alone
<robin>M6piz7wk[m], for very large N$, pay people to do RE+reimplementation of the firmware ;) (about 1.5 MiB--2 MiB of firmware per gpu architecture). otherwise you're stuck because nonfree firmware
<M6piz7wk[m]>did nouveau at least figured out the power management engine thing yet
<robin>some of it's not even that bad, e.g. some of the firmware files are programs for documented RISC architectures
<M6piz7wk[m]>i prefer nouveau with the GPU not stuck on lowest clock -w-
<robin>the only workaround i can think of is some sort of PCIe riser that has the firmware on ROM and works with a modified amdgpu driver to load it, which technically might RYF, i think, but is also kind of ridiculous imo
<singpolyma>robin: if only people good at firmware RE were just sitting around waiting for my money....
<robin>(personally, i use nonfree firmware but i also haven't tested whether my mainboard's iommu actually works properly...i'd feel safer with a raptorcs system, as i trust their iommu to work properly, although i don't consider gpu firmware to be a real risk compare to say, intel's/amd's 'security processors')
<robin>singpolyma, i was mostly joking, but yeah, that's probably a real bottleneck
<singpolyma>robin: I just find a lot of our community's rhetoric is "well we just don't have money like those nonfree vendors" but if you show up with money people are like "oh... How do you spend money?"
<robin>singpolyma, both can be true i think :) we don't have as much $$$/€€€ to throw around and, given economic limitations, it's unsurprising that not many people are in a queue waiting for direct financial support. that probably goes double for anything involving hardware
<M6piz7wk[m]>how do we not have economical resources? Floss is a gold mine
<singpolyma>Yes, that's true, no industry to absorb the money partly because there is less of it
<singpolyma>M6piz7wk[m]: most hackers are not also good at business, for one, or interested in it really
<M6piz7wk[m]>luishgh: If its not in `guix search` then its probably not packaged
<singpolyma>Better do staff a shop with competent hackers and put them to work 100% of the time than create a marketplace of tiny work half of which never gets claimed and the other half never merged. In practise most nontrivial bug bounties are claimed by maintainers
<M6piz7wk[m]>100% work is waste of money as people are allowed to be lazy
<M6piz7wk[m]>Or FSF could stop being shady and just take back their endorsement of librem for us all to avoid going there
<M6piz7wk[m]>Bcs FSF is incompetent and just endorses everything that people say to use KiCAD even though the design seems obviously imported from a proprietary software and is shipped with a backdoor to target free software devs for surveillance
<singpolyma>FSF barely endorses anything. I think they've said the librem5 is "promising" but no purism product is endorsed yet
<singpolyma>M6piz7wk[m]: well, FSF doesn't care about libre hardware because RMS doesn't. I asked him to his face about it and he said "well, I don't have a fab line, so what good are hardware specs to me?"
<robin>re: game jams, godot is extremely promising; game developers seem to find it technically superior to the major proprietary engines. in fact i'm probably going to end up porting most of $client's 100s of general purpose components for $proprietary-engine to godot so they can be released as free software (selling license exceptions for revenue; that's not even allowed on $proprietary-engine's "app store"-equivalent afaik)
<robin>(...with time-delayed liberation for brand-new features, and i'm sure some people would prefer $client selling services/support instead license exceptions, but that's the best i can do with $client for now)
<vdv>Why is guix significantly slower than nix, guix pull takes on my laptop (razer blade stealth 2016) about 2-3 mins, guix system reconfigure ~1-2 mins. Nix needs even after garbage-collecting (which also runs faster on nix) for a nix-channel --update ~ 3 secs and for a full system upgrade without direct changes after garbagecollection around 10 seconds
<apteryx>I guess nix doesn't recompile anything? in guix as you've noticed 'guix pull' builds guix from the last master commit. sometimes that's reasonably fast if ci.guix.gnu.org had time to build it already (as it gets substitutes) but it depends on the timing of someone pushing a commit and you issuing guix pull.
<vdv>the manual rebuilding also needs much time, and the building of the actual profile definition
<apteryx>lengthy profile generation is a known pain point. the biggest offenders are profile hooks such as the manual page database generation
<vdv>true, but if there are no changes and a binary for the newest guix version on the substitute server then there should be no need to build anything, or is this wrong?
<apteryx>(which is useful to searh manpages with 'man -k regex' for example)
<robin>good stopgap solution, and yeah, a good incentive to optimize mandb generation as apteryx says :) i'll have to do some profiling later...
<dissent>hey guys what could be the best way to to add a custom xkb layout?
<dissent>I usually do this by inserting a customized evdel.xml file in the rules directory and the new layout in the symbols directory.
<dissent>Also this something to be resolved in config.scm or with guix-home?
<singpolyma>Hmm, does `guix shell` not allow me to authorize a directory and subdirectories?
<apteryx>dissent: you may want to consider using 'hey guix' or 'hey folks', as a more inclusive/international alternative :-). I haven't dived into guix home yet, but typically keyboard configuration happened in config.scm (system wide) via a keyboard-layout record (see: "info '(guix) Keyboard Layout'").
<dissent>apteryx: Will make an effort to do so. Usually in this context "guys" is not a gendered term. I looked at the section and my intetion is not to set a keyboard layout that is already there but to make an entirely new one.
<civodul>apteryx: yes, via manifest-entry-dependencies
<apteryx>still needing to figure out: rust on non-x86 systems
<apteryx>perhaps we can have polkit conditionally replaced by polkit-duktape for the systems that do not have rust support; or perhaps even globally? the duktape patch appears unmaintained unfortunately (it's lucky it still can be applied cleanly to polkit)
<apteryx>the problem appeared following an update to polkit, which requires a newer mozjs that pulls rust
<minikN>Good evening. Trying to build a package, configure failes with `checking for QtCore QtGui QtXml QtNetwork QtScript QtDBus... no` `configure: error: Qt is required`, is there anyway to see what lib exactly is missing?
<apteryx>so was there a commit on master that caused rust to be rebuilt?
<zimoun>apteryx, ah ok. Thanks! Obvious once read. :-)
<roptat>apteryx, I don't know unless you give me the actual error ;)
<minikN>apteryx: I included qtbase and all others I could think of already
<apteryx>then I don't know; it could be that their configure script is broken
<apteryx>roptat: i've used the wrecking ball 'git clean -xfdd' approach already; will do if it bothers me often :-)
<apteryx>why does ~/src/guix-core-updates/pre-inst-env guix search something screams with "In procedure abi-check: #<record-type <package>>: record ABI mismatch; recompilation needed" but works fine if invoked from the tree itself?
<apteryx>(this command was run someone else, hence specifying fully the location of pre-inst-env)
<nckx>vagrantc: My test was guix challenge hello to ci.guix → ‘100.0% identical’, to guix.t.gr ‘warning: no substitutes | 100.0% were inconclusive’. So a very clear error, maybe it takes something more subtle to confuse Guix.
<efraim>I think I'll push it as-is to wip-rust as a proof of concept and then look at ripping out cargo-inputs entirely
<vagrantc>nckx: i haven't reproduced the issue yet, but from memory the jist of it was i was doing "guix weather linux-libre" on an aarch64 system, and weather showed bordeaux as having a substitute but ci didn't, and then "guix challenge linux-libre" and it would respond with "no substitutes" or something ...
<civodul>"guix challenge vim-full" works for me, and i have no local build :-)
<lilyp>good thing is those old gpus also suck at mining crypto, so probably no one's gonna buy them :)
<nckx>Well, I asked vagrantc for details, only fair to provide them 😛
<vagrantc>nckx: yes, but it should complain about there being no local build, not complain about there being no substitutes when, in fact, there are substitutes ... but ... unless i can actually reproduce it ...
<nckx>civodul: My interpretation of ‘guix challenge: warning: could not challenge '/gnu/store/foo': no local build’ is that foo is skipped.
<civodul>next up: a talk on the Fortran package manager (yup!)
<zimoun>I need help by Emacs Wizzards. :-) I am trying to fix ProofGeneral [PG] (bug46016) and I am confused by the Emacs machinery. Basically, all .el or .elc are in only one directory. For PG, it is not the case.
<robin>for nontrivial cases (renaming, prefixing, etc.) guile procedures don't store their original module, just their original name; the module system might track that information though
<dthompson>vagrantc: might help to share more context. robin is giving advice under the assumption that you in the guile repl trying to find info about a procedure that is currently available in the environment. I'm giving advice about finding information about a procedure via the guile manual.
<civodul>zimoun: at least the add-to-list 'load-path bit may be unnecessary, i'd say (but i'm no expert!)
<vagrantc>dthompson, robin: specifically, i'm trying to write a package definition, and want to play around with how for-each, find-files, copy-file, lambda, etc. works in a little guile script ... when i edit package definitions in gnu/packages/bootloaders.scm, many of these functions are already avaiable, but if i want to get a simply script to toy around with something, i need to reverse engineer where everything
<vagrantc>real basic stuff, i know ... amazed i've gotten as far as i have with cargo-culting my way through this all :)
<apteryx>vagrantc: it's either from guile (have a look at Guile Reference manual (info guile, then use i to find the procedures) or (guix build utils) usually
<apteryx>you can see which non-standard modules are imported by inspecting the imported-modules argument in the builders sources.
<apteryx>there's not that much extra stuff imported on the build side usually
<apteryx>if you use geiser and have a REPL open, you may have luck with C-d d on the procedure at point
<apteryx>(geiser is emacs-specific though, the rest i've written isn't).
<zimoun>civodul, I do not know. For sure, something is missing because I have to (load “path/to/chboui”) before using PG which is more than annoying.
<apteryx>civodul: re manifest-dependencies; actually at first I was using MANIFEST-INPUTS, which does take into account the dependencies field of each manifest entry in the manifest... so I'm unsure why propagated deps are not found there.
<apteryx>in particular, (manifest-lookup-package manifest "gdk-pixbuf") is found, but is missing from (manifest-inputs manifest)
<civodul>apteryx: actually manifest-inputs recurses into dependencies, so it should do the trick
<zimoun>civodul, damned! ’proof-general-autoloads.el’ instead of ’proof-general.el’ seems to make it. Argh, these missing 9 letters made me lost 15min of my life for each letter )-:
<civodul>apteryx: the problem was that the code doesn't "see" gdk-pixbuf when it's propagated?
<civodul>did you consider adding pk calls in there? :-)
<apteryx>the problem was that manifest-lookup-package found gdk-pixbuf, but manifest-inputs didn't. I was relying on the fact that gdk-pixbuf carries its own loaders.cache file, ensuring the case without any loaders.cache file would never occur (and attempt to produce an void output derivation)
<apteryx>but it seems to happen as spotted by Thiago and myself
<apteryx>ah, it occurs with a manifest containing just (define manifest (packages->manifest (list (specification->package "icecat"))))
<apteryx>seems like manifest-lookup-package is more aggressive at finding things
<rekado>civodul: these slides are pretty! Very nice!
<rekado>what’s the story behind slide 28? (The low-res smiley.)
<apteryx>civodul: are search-path-specifications applied to the transitive closure of a profile or rather to the directly available and propagated packages?
<efraim>we might need to use the bundled crates in librsvg on core-updates-next, it has too many dependencies :/
<efraim>~3000 dependencies on librsvg, and there's all those unknown crate inputs
<apteryx>civodul: seems manifest-lookup-package searches deeper, at the level of packages and store items rather than purely manifest entries
<bavier[m]>I'm trying to create a vm with `guix system vm` but provide some persistence. The `--share` option seems to create ownership problems? e.g. if I `--share=$HOME/tmp/var=/var` some processes can write into $HOME/tmp/var, but others cannot, and services cannot create directories for activation. I thought maybe I could provide a qcow2 disk image to have the vm mount, but there seems to be know way to declare a filesystem like that. Any pointers?
<apteryx>you could use 'guix system disk-image' with the --non-volatile option
<bavier[m]>what does --volatile specifically mean? I'm probably just not familiar with the jargon.
<apteryx>it means the changes written to the disk will not be persisted
<apteryx>so if you restart the VM, it'll start as good as new
<bavier[m]>I see, this seems promising! apteryx, thanks!
<apteryx>civodul: given that this loaders.cache file would typically be computed any time a package is installed no a traditional distro such as Debian, I guess it would make sense that I pass the transitive inputs of the manifest to the generate-gdk-pixbuf-loaders-cache procedure.
<apteryx>on the other hand, that's not how it's done on the builder side (there the hook only consider build inputs; which arent't transitive AFAIK)
<apteryx>I guess I'll resort to this: gdk-pixbuf found in the transitive closure *and* a loaders-cache file is present in manifest-inputs
<apteryx>I'm a bit worried we may fall in the same old trap: nothing ends up propagating a loaders.cache file directly; and the single entry search-path prevails and picks the first one, which may or may not be complete.
<civodul>apteryx: wait, what does the ld.so cache have to do with the gdk-pixbuf hook?
<civodul>but that probably makes sense for the glib/gtk+ hooks
<apteryx>civodul: did I say something about ld.so cache? the loaders.cache file I'm talking about is the one used by gdk-pixbuf to locate (dynamically) its loaders
<apteryx>it used to be hard-coded (we'd have that of gdk-pixbuf, or that of gdk-pixbuf+svg); it wouldn't be possible to have both of them propagated safely in a profile
<apteryx>what I've done so far is an improvement, but I'm realising now that it's not bullet proof because at least on the builder side we're not considering the complete closure, just the immediates (and their propagated) inputs
<civodul>apteryx: ah sorry about the confusion re loaders.cache
<apteryx>so suppose that something uses librsvg but doesn't propagate it deep down, but something amongst the immediate inputs propagates gdk-pixbuf (rather than librsvg); the computed loaders.cache would not include librsvg
<apteryx>the format of leaders.cache look like it should be; I'm not sure if that'd be faster than simply calling the tool to generate it anew from the various inputs in this case; it seem fast. What may not be fast is searching for them through the whole closure