<civodul>it would be nice to understand what in that merge commit led to Rust rebuilds <civodul>because that's really Rust itself, not just some Rust library <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 <vivien>The first time I’m using guix style :) <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? <vivien>Rust is needed for librsvg, I think <civodul>zamfofex: you should try on core-updates-frozen, it might be better <civodul>vivien: oh, how did you like "guix style"? <civodul>it's been sitting there for ages :-) <civodul>KE0VVT: you mean "can Rust be avoided", right? <civodul>i think the short answer is "hardly" <civodul>the cost to avoid it is to maintain the C librsvg <KE0VVT>civodul: I don't care if a program is written in APL. I just care that it is free. <singpolyma>That's like "can C++ be avoided" like, maybe, but lol no <vivien>I love the concept, I think it gives reasonably good output, but it’s unfortunate that it disagrees with guix lint on the name for the "bin" output of glib. <civodul>vivien: ah yes, maybe something to fix <civodul>well it's not guix style's fault, but rather the auto-labeling code <podiki[m]>certainly a joy to write inputs in the new style <zamfofex>How does ‘core-updates-frozen’ differ from ‘core-updates’? <vivien>core-updates-frozen is able to build software :) <civodul>zamfofex: it's supposed to have fewer disruptive changes and merged "soon" in master <zamfofex>I see. I could try it, I suppose! Though now that I’ve waited half a day, it doesn’t feel so clear whether I should. <vivien>Joke aside, core-updates is a bit neglected right now, so core-updates-frozen should be considered instead. <podiki[m]>it was frozen earlier in the summer from core-updates (supposed to only be bug fixes then), not sure how much core-updates has moved since then <vivien>On my CI for my personal project, almost everything fails on core-updates <podiki[m]>random question: does guix needing only user permissions (except system reconfigure) improve security in any meaningful way? <zamfofex>Should ‘core-updates-frozen’ be mentioned in the manual too? <vivien>podiki[m], that depends on what you mean by "security" <podiki[m]>I feel like less sudo is better, but in the end something is using elevated privileges, so does it just move the trust in a sense? <podiki[m]>zamfofex: ideally -frozen is just temporarliy between core-updates merging to master; but yes maybe the process should be more detailed? <podiki[m]>vivien: I'm thinking in terms of "typical" desktop user, where sudo for me was nearly always for installing software on non-guix <podiki[m]>kind of normalizing sudo, or expected to do that for installing things. now on guix i so rarely need it I pay more attention maybe? <vivien>If you consider the fact that the person using the computer might play 2048 all day without working as a security breach into your cash flow, then guix isn’t secure <vivien>(the fact that ...) as a security breach <vivien>If you are an employer and you install guix, then your employee might install any application without the need for sudo, and that might harm your business ^^ <vivien>But yeah, if your user can add any channel and install a ransomware, that might be a problem :… <podiki[m]>one example I was thinking of is on Arch with AUR, the (often ignored) warning to look at packages because you use sudo to run the installation <podiki[m]>of course in guix or any distro you have to trust (or read the source) of something <vivien>That’s more of a problem for multi-users setup <vivien>Ultimately though, installing a ransomware without root privileges should be easy. <podiki[m]>sudo 'a random package install' seems less risky than a 'guix install'? (all bets off in running what you installed) <zamfofex>Quick question: Can I use ‘make’ but avoid having to build the docs? <the_tubular>The only thing that would point as to guix being insecure IMO is a RCE in an old version of guix <podiki[m]>the_tubular: thanks, do remember seeing that. trust in guix-daemon is perhaps what it comes down to then <podiki[m]>you always need/should check package definitions in any distro if you want to be sure <the_tubular>Yes, unless you have a user that is compromised already ... <vivien>Rust is needed for rav1e, a video encoder <podiki[m]>anyway, was just curious people's thoughts. general advice of being careful with sudo is always good, using it less in general is probably safer? (or just shuffles the possible holes) <vivien>My thought is that sudo is often misused, because it promises an immediate ending of your suffering, but at what cost? <vivien>I mean, I think it’s safe to use sudo to edit /etc/config.scm <podiki[m]>personally I love turning on the sudo option to insult you when you get your password wrong <the_tubular>Yeah, there's tons of places where guix needs more love than some jokes IMO <podiki[m]>maybe an easter egg for the progress bar in guix operations (again thinking of Arch's pacman that has...a PacMan mode) <DigitalKiwi>tl;dr ILoveCandy enabled that progress bar podiki[m] mentioned. internally the setting was called chomp <rekado>“guix system image --system=aarch64-linux -t iso9660 gnu/system/install.scm” fails <rekado>v86d fails to build with: #warning "LRMI is not supported on your system!" <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 <lfam>Just wondering if you noticed something new :) <lfam>Still a bad bug, to be sure <zamfofex>Guest79: Can’t you just use ‘cp’ on the image to put it wherever you want? <Guest79>Yes, but I figure that defeats the purpose of using guix for reproducible systems <lfam>The duration continues to increment but the log shows that the build has succeeded <Guest79>Scrolling through syscalls.scm, it looks like the error is that the guile interpreter can't find a symbol named statfs64. Anyone know which lib provides it (can't find it in the man pages)? <lfam>I suppose the kernel provides it <Guest79>Huh. Then that begs the question why it's inaccessible to the guile interpreter... <lfam>The init is written in Guile, yes <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 <Guest79>Understood; thank you for your help! <lfam>The long string is not a Git hash, but a hash that Guix calculates of the entire dependency graph of the package <lfam>The package in this case being Guix itself <lfam>If you wait a while I'd expect another person to chime in <char>any tips for running mariadb (not as a service)? <Guest79>What's the etiquette for anon users leaving a hanging question that they'll come back to after leaving the chat? <apteryx>efraim: I was looking at merging gold into our binutils package; but it seems gold depends on GCC, which is bad for our binutils-final package used in the bootstrap, right? <apteryx>hmm, it already does it seems, at least for 'binutils' <apteryx>ah, binutils-final doesn't because of 2~ <apteryx>oh, perhaps not after all, I dropped the gcc:lib input and it still built fine <apteryx>but it kept a reference to it, I guess it got it as an implicit input <char>is running $ mysqld not how I'm supposed to do it? <apteryx>the_tubular: do you know which commit broke it? <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 <apteryx>which version of docker-compose is this? <apteryx>I know it was broken this way with commit c9c4c851a8 but later reverted with ad39268cdf; perhaps you simply need to guix pull <the_tubular>Can't even run docker-compose --version without it crashing :( <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 <apteryx>perhaps /run/current-system/activate? <sneek>Guest79, you have 1 message! <Guest79>Heh; I have the chat log open in another tab - didn't understand how sneek works. ***bdju_ is now known as bdju
<efraim>apteryx: the problem with binutils-gold is the bc dependency, it drastically increases the bootstrap chain before gcc-final <efraim>Otherwise that was the plan. Perhaps we can use a modified version of bc or something <jgart>I'm trying to package cwcwidth because it's needed by the next version of the bpython repl that's in guix <jgart>Has anyone seen similar hacks needed with other packages? *jgart greps away through guix/gnu/ <sneek>Welcome back xd1le, you have 1 message! <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. <civodul>fcw: great! maybe start a new issue but provide the link to that one <civodul>and say a few words as to how they differ from each other <fcw>civodul: Okay. Thank you. <vivien>civodul, how is your packaging conference going? <civodul>vivien: getting prepared, it starts again later today <civodul>i watched a talk around TUF yesterday, that was nice <abrenon>florhizome[m]: it's a text art representing someone waving hello ("o" is the head, "/" is an arm) <abrenon>oh noo… my .desktop shortcut is broken again ! -_-' <rekado>I’m trying to package rust-bio, and I’m currently arguing with a hair stylist on whether their scissors are going to be able to cut yak hair. <rekado>to build glam 0.13 I need spirv-std, and that needs glam 0.17. <abrenon>how bad is it to temporarily write a file to ~/.guix-profile/share ? can it seriously mess up with guix' stuff ? <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 ! <rekado>so, the spriv-std package has an *optional* dependency on glam, but when I attempt to build the package it aborts because glam is not found. <rekado>is there something I need to do to build without an optional dependency…? <abrenon>so I really have to fix everything now ^^ <vdv>hi :) no "gsettings" in guix? i installed gsettings-desktop-schemas and dconf but not gsettings-command <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 <civodul>did you see that our talks are at the same time? <civodul>rekado: that Rust story sounds fun; so even bioinfo comes to Rust? <jpoiret>"Go mod's lesser known features for supply chain security": unpackagability and un-upgradable dependencies? :) <efraim>I figured out how to pass along the source crate even with #:skip-build? so I'm actually doing fairly well so far <jpoiret>i have to imagine using `guix shell` in front of unsuspecting bystanders will raise some eyebrows <jpoiret>while we're at it, anyone running nm-applet on core-updates-frozen? i'm getting a segfault in libgobject when trying to connect to PEAP+MSCHAPv2 wifis <abrenon>jpoiret: depends on the audience, I did that a couple times in front of the class and in front of colleagues but no one seems to have realised anything spectacular was happening <vivien>jpoiret, I don’t have wifi on this machine, sorry :( <vdv>any1 succeed in running guix system on a raspberry pi ? <rekado>civodul: it would seem so. The end of innocence. <rekado>vivien: should be okay. Nothing depends on Gnome Boxes. <rekado>I assume you are not a thing, so there’s no contradiction. <rekado>vivien: your patch looks good to me. <civodul>efraim: why do we sometimes omit #:cargo-development-inputs? *civodul plays with the "reimporters" <GNUHacker>hi #guix, Im trying connect to ssh root@localhost, Ive added manually my user public key to /root/.ssh/authorized_keys, but ask me a root password, what I do wrong? <abrenon>GNUHacker: permissions on that file ? <efraim>civodul: it cuts down on the number of crates that need to be imported, which can recurse crates back to the mid 2010's <jpoiret>GNUHacker: you can use `-v` to get more verbose messages, it will print out which keys it tries too <abrenon>ok, I'm never going to find it again <efraim>the problem was the 'package' phase I added, which tries to do some sort of building or testing, which we don't care now if it fails when there are missing cargo-inputs <efraim>on my WIP area I now just copy source to target/package and mangle the name correctly <abrenon>wasn't there a proposal at some point to simplify the syntax of inputs to remove the need for a string naming the package plus the variable pointing to the package definition itself ? <jpoiret>i tried to find it yesterday but couldn't <rekado>abrenon: it’s on core-updates-frozen <abrenon>ok yeah jpoiret you tried to find it in the conversation when someone re-invented the idea itself right ? <jpoiret>what's the issue #, and was it added to the docs <abrenon>I answered I thought it existed, then saw no one commented and I thought maybe I had dreamt it <jpoiret>abrenon: yes! great minds think alike i guess :) <abrenon>and today looking at random package definitions while trying to define a package I found only the "old" (rather, current) style, so that was really disturbing <abrenon>so, coming up, as soon as we manage to merge CUF ? <civodul>efraim: oh, but are #:cargo-development-inputs used at all, then? <jpoiret>abrenon: thanks! I thought it was more recent than this, so i didn't look that far back <abrenon>"Getting rid of input labels"… I thought I'd never find that wording again <abrenon>I had the feeling it was sometime during the summer <civodul>vivien: BTW, the plan is to have a "flag day" where we run "guix style" on the whole repo, shortly before merging to master <vivien>Glad I put the styling commit last so you can ignore it then :) <civodul>the goal being to avoid merge conflicts <vivien>There are different kinds of merge conflicts <vivien>Some can’t be avoided without a deep understanding of the source code. <efraim>civodul: they're used in lieu of native-inputs, only for the tests <efraim>the real problems were the ones that didn't have #:cargo-inputs <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 <vivien>I’m not against pijul, I’m against migrating in the hope that you won’t get merge conflicts <zamfofex>On guix.gnu.org, is it normal that ‘/packages’ redirects to ‘/en/packages/’, but ‘/packages/’ (with a slash at the end) doesn’t? <zamfofex>It has been like that since basically ever, I think. <zamfofex>Also, both e.g. ‘/en/packages/foo-0.0’ and ‘/packages/foo-0.0’ (with and without ‘en/’) exist and neither redirects to the other. <civodul>zamfofex: that's annoying; could you email bug-guix about it? <civodul>hopefully Florian will have an idea of things to look at <M6piz7wk[m]><vivien> "I’m not against pijul, I’m..." <- i ain't if pijul ppl didn't lied to me <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]>So afaik the theory is that patch on top of patch on top of patch that are independent from each other and you just define how the patching behaves <abrenon>so then you can't represent the same range of changes on files ? <abrenon>or that's the way changes are represented ? <M6piz7wk[m]>i am not an expert on the subject, but the theory as i understand it that you have it set that each patch rewrites the previous one in sane way unless defined otherwise <abrenon>after having watched the video, I still haven't understood what would happen in practice if Bob updated "color = RED" to "color = BLUE" while I updated it to "color = GREEN" <M6piz7wk[m]>afaik it's more demanding to set up and then it's just smooth sailing in terms of conflicts and overall management <jpoiret>M6piz7wk[m]: it also requires all contributors to adopt it <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 <M6piz7wk[m]>i can't even remove the hugging screw from the water block.. <robin>oh, not for nvidia, that has the extra problem of having proprietary kernel modules (or something equivalent) if you don't use noveau, right? <robin>it'd only be feasible for amdgpu because everything's free except the firmware <robin>nouveau is totally free, iiuc <M6piz7wk[m]>i can't do power management engine last time i checked <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') *M6piz7wk[m] doesn't trust raptorcs <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]>lets revoke GPLv3 to everyone who didn't do the 3 hour course on economy then <singpolyma>The FSF is mostly hackers so they suffer from this same issue ;) <robin>imho raptorcs, mnt research, and even framework (yes, i know, starting with intel...) and powerpc-laptop are making some valuable contributions towards better hardware availability <robin>M6piz7wk[m], you probably know this but for the the sake of the discussion, the FSF did once upon a time pay hackers directly to work on e.g. emacs <M6piz7wk[m]>robin: No, as long as ECAD files are not available then they are just part of the problem <singpolyma>robin: yeah, FSF paying hackers directly was probably a good model I think, but that was a long time ago <M6piz7wk[m]>robin: Last time I checked it was an ecomical disaster <robin>seems like a bit of a missed opportunity, they could've theoretically invented liberapay, but this was before even paypal (to say nothing of cryptocurrencies) <M6piz7wk[m]>Paying people for working on code is bad.. giving the option for bug bounties is good <M6piz7wk[m]>Bcs you are not just throwing money through the window <singpolyma>M6piz7wk[m]: that seems the opposite from experience overall. Bug bounties are usually a disaster <robin>that doesn't seem workable for large-scale projects, imho. for small-scale bugs, sure <M6piz7wk[m]>singpolyma: Depends on how it is maintained since you are defining what exactly are you paying for, why and have clear calculation to adjust your finances for it <robin>for a year-long project i'm not going to roll the dice and hope i beat all the other bug bounty-hunters, for example <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]>Minimal wage + management of the project e.g. paying the sysadmin for having 100% uptime and then scaling down the pay <M6piz7wk[m]>singpolyma: People who work for me in that area got paid 63K CZK monthly on that model <singpolyma>Anyway, all this is besides the point because even if we had these mythical workers, what would they work on? <M6piz7wk[m]>It just gets more work done and makes more more finances for everyone <M6piz7wk[m]>Whatever makes more resources or maintains them or whatever community decides to finance <singpolyma>Right, but I think we started out talking about how FSF should spend their 1M. Independent if the model they might use to spend it, what should they spend it on? <singpolyma>1M is enough to fund about one person forever, but not at market rates obviously <M6piz7wk[m]>Developing a libre hardware in cooperation with OSHW <M6piz7wk[m]>Rest would have to he discussed as those are not nobrainers <M6piz7wk[m]>Also none told me how FSF works so that could probably allow to micromanage the hell out of <singpolyma>So, free software game dev incentives, I could see that one <M6piz7wk[m]>So libre license for hardware and mandating the ECAD files to be publicly available <M6piz7wk[m]>singpolyma: Right now I need a phone which I've calculated on 1500 EUR <singpolyma>You're going to develop a phone for 1500 EUR using minimum wage workers? <M6piz7wk[m]>1500 EUR in calculated work for it assuming all the specs and docs available to know now to wire everything <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 <M6piz7wk[m]>They literally had a whole xmas campaign about how great it is <M6piz7wk[m]>And its shit like this that make me constantly disgusted in what FSF does in the libre hardware field.. literal shitting on everyone who wants to make libre hardware <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?" <M6piz7wk[m]>some kind of weird compensation for "ethical software" apparently <M6piz7wk[m]>singpolyma: The pcbs cost pennies for <5 layers -w- and anyone can make those at home <rekado>In my opinion a discussion about rms and the FSF’s endorsement programme is off topic on this channel. <rekado>I’m not discussing, just stating my opinion. This channel is about Guix, not about ways to develop and manufacture hardware. <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) <apteryx>robin: great news! thanks for sharing <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) <robin>i was very surprised, it was like letting them spend ten minutes with godot and their immediate reaction is "wow, this is actually way better than $proprietary-engine" <M6piz7wk[m]>i wish it was more gnuish like allowing to move the windows out and stuff like gimp <apteryx>civodul: hello! do we have some means to access a manifest propagated inputs in a profile hook? <apteryx>seems manifest-inputs returns only the explicitly specified items <robin>apteryx, it only required a few...entire days of persuasion on my part ;) <apteryx>well done on the advocacy of free software :-) <vdv>Nix even runs after a garbage-collect (which is faster on nix too..) un <vdv>Nix even runs after a garbage-collect (which is faster on nix too..) un <vdv>oops, whole question : <apteryx>perhaps we should peek at their newer daemon code and backport any improvement they've made in this area? <apteryx>does nix do file deduplication as well? <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 <vdv>i think it is because it pulls the whole definition and rebuilds guix everytime on pull? <apteryx>sytsem upgrade without any chaneg is very fast here <vdv>but nix is faster by a factor of 300+ <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) <vdv>but nix has mans from binary pulling without rebuilding the whole man database i think.. <apteryx>then there's probably a lot we can learn by inspecting how they do things there *M6piz7wk[m] goes to sleep while being angry at FSF <apteryx>I'd suggest you to do so if you have the bandwith :-) <apteryx>M6piz7wk[m]: keep in mind that bitterness won't make you or anyone else happy ;-). good night! <vdv>i will try to look into it a bit :) <roptat>apteryx, we got read of the man page hook recently <roptat>ludo pushed it two days ago I think <apteryx>are we still able to search manpages? or did we simply drop it? <roptat>the hook is only needed for man -k, which most users don't use anyway <robin>roptat, really, how'd that happen? that's great news :) <roptat>(I think there's still a condition under which it runs, I don't remember the details) <apteryx>roptat: hmm. 'most users don't use anyway'. I use it, but I don't know if I'm like "most users" ;-) <apteryx>anyway, agree it was slow as molasses. Now I have an incentive to improve its performance if I want it back. <jab>apteryx: I've heard talk that guix could potentially use the man page generator that openBSD wrote, which from what I've heard is faster... <roptat>3c1158ac4e5ef825a9b9a229a233fabd7cef334e: profiles: Build the man database only if 'man-db' is in the profile. <vdv>so they are not the problem.. :D <apteryx>so we can still have our manpage database if we want to by adding man-db to our profile <vdv>still profile generation needs too long and pulling changes <vdv>no need to rebuild the guix binary when there are no changes to it after a new pull maybe <vdv>high end gaming laptop from 2016 ^^ <apteryx>building guix if it's not substitutable still going to take some time <vdv>that's why i wonder why it's so much slower then nix <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>dissent: hmm, indeed keyboard-layout seems more geared toward customizing an existing rather than wholly specifying a custom layout. <apteryx>vdv: have you read: info '(guix) Channels with Substitutes' ? it may help <vdv>yeah but still trys to build network-manager etc if it's not avaiable.. @ apteryx <vdv>maybe i'm doing it wrong, how to use the shown definition with an additional channel <vdv>just include ist behind the last paranthesis with (channel ... ( blbalba)) <apteryx>if you have an extra channel, that may be where the slowness comes from, as it probably won't have substitutes available. <apteryx>only the %default-guix-channel has support for substitutes configured out of the box on Guix System <roptat>but other channels are usually small compared to guix, so it's not that slow <vdv>true but at the moment reconfigure trys to build network-manager and udiskie that should be in the official channel <vdv>so what should be the right way inside channels.scm to use the substitution defintion for the ofiicial channel and one additional? <roptat>note that it only ensures "guix pull" is substituted, but not that everything at that generation is built <vdv>at the last time i included it within the list <roptat>mh, yeah you can more simply do (list (channel ...) (channel-with-substitutes-available ...)) <apteryx>kexec-tools on i686 should unlock many packages there for cufbc <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>what is the difference between #:modules and #:imported-modules in ’arguments’ <apteryx>imported-modules is to import non-guile modules in the build environment <apteryx>modules is to put them in scope (,use them) <apteryx>non-guile -> not part of the guile standard library <apteryx>such as those under the (guix build ...) namespace <apteryx>roptat: weird, I'm getting a failer to build a manual on my local dev branch: make[2]: *** [Makefile:4996: doc/guix.ko.info] Error 1; would you know the remedy? <zimoun>apteryx, thanks. What is the difference between ’import’ and (,use them)? <apteryx>,use -> (use-modules ...). import -> pass them to the build env and have them available on GUILE_LOAD*_PATH <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) *vagrantc notices vagrantc has some guix.info URLs in browser history !! <vagrantc>i can't seem to get "guix challenge" to compare against bordeaux.guix.gnu.org ... is this a known issue? it seems hard-coded to ci.guix.gnu.org <nckx>vagrantc: It's not hard-coded. <nckx>It uses your substitute-urls, or Guix's default, but you can override both. <nckx>Are you saying it blatantly ignores your request? <vagrantc>e.g. i tried substitute-urls and i also have both in my guix-daemon configuration <nckx>I tested it before answering. Can you share the full command? <efraim>finally built newsboat with cargo-inputs->inputs, ~3000 line diff <nckx>vagrantc: How do you determine that it failed? <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 ... <apteryx>haha, my error was silly; my tree is at ~/src/guix-core-updates-next, not ~/src/guix-core-updates. works fine now. <vagrantc>i probably didn't have a local build either, though i wanted to compare against both remote servers <vagrantc>efraim: i haven't followed closely, but how is wip-riscv coming along? <vagrantc>efraim: i see commits getting pushed to it now and then <efraim>vagrantc: There's one last bug I'm fighting, packages get -lgcc_s but not a path to libgcc_s.so so they fail <efraim>I've worked around it by adding gcc:lib in a bunch of places but actually fixing it was suprisingly hard <civodul>i was very frustrated about mine :-/ <efraim>civodul: I've done better, couldn't get screen sharing to work from my desktop so I did it from my pinebookpro <efraim>and not all the slides synced over <civodul>i was on the panel before so i had zero seconds to set up, which didn't help <efraim>I think I can finally try 'guix shell -D --pure newsboat -- make' <vivien>Is it OK to submit a patch to core-updates-frozen to upgrade a package, even if there’s no bug in the present version? <vivien>Also, did I read you correctly, that it’s pointless to submit restyling now and we’ll run guix style for all packages at once? <civodul>vivien: yes, i think it's better to do it all at once right before merging <civodul>to avoid merge conflicts in the meantime <dstolfa_>civodul: did you get any interesting comments/questions? <civodul>dstolfa_: not much unfortunately: due to technical issues, i was 5mn late so no questions <civodul>well, one question about NVIDIA support in pytorch... <vagrantc>nckx: hrm. not able to reproduce the issue with guix challenge ... :/ /o\ <nckx>vagrantc: guix challenge requires a local build. <lilyp>M6piz7wk[m]: nouveau sadly only works with older hardware, I have a 710 for example <nckx>(Just coincidentally returned and replying to an older message above, vagrantc.) <civodul>nckx: "guix challenge" can work with only remote builds <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. <nckx>Is that not what happens? <nckx>vagrantc: So here it did just that. <nckx>Say there's no local build. <civodul>nckx: because there were no local builds *and* no substitutes? <civodul>in my case no local build but two substitutes <nckx>civodul: No, because ‘guix build hello’ promptly downloaded a substitute, and then ‘guix challenge hello’ changed output to ‘100% are identical’. <nckx>All this without explicit --substitute-urls=. <civodul>yes, by default lack of --substitute-urls means ci.guix + bordeaux.guix <vagrantc>well, i can't find what triggered my "issue" ... so hrm. <nckx>You mean by ‘really, really default’, not default for someone who has non-default substitute-urls in their OS configuration. Just checking. <civodul>yeah, really default: the daemon's --substitute-urls option is not taken into account <civodul>maybe there are confusing reports in some cases <civodul>we just need to find out which cases :-) <nckx>I'll save my log and produce more log later! *nckx about to hop a bus. *vagrantc imagines nckx leaping over a bus <nckx>I still don't understand how ‘"guix challenge" can work with only remote builds’ jives with what I describe above, the challenge → build → challenge thing. <civodul>it downloads narinfos from all the substitute servers, that's it <nckx>Does that mean ci had hello & bordeaux didn't? <vagrantc>it has helped me learn how to spell bordeaux, but i wonder if a shorter URL wouldn't be in order :) <nckx>So the first ‘guix challenge hello’ should have compared ci to bordeaux if I read you right. It didn't. <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. <zimoun>The code for starting the package is under the subfolder generic/ <zimoun>Therefore, I am confused for the correct Guix way. <zimoun>Ah and it uses gnu-build-system. <zimoun>I have tried to add various “phases” from emacs-build-system but nothing works. Because I should miss a conceptual point. :-) <vagrantc>short of just knowing, how does one find where a particular guile function (procedure?) comes from? <robin>vagrantc, ,apropos maybe? if "where"=module <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. <robin>yeah, i should've been clearer about that, esp. as this is #guix not #guile <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 )-: <apteryx>I'm trying to revalidate what I just wrote at the REPL <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 <apteryx>ah, you just omit to specify --volatile <apteryx>non-volatile appears to be the default <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>from a look at manifest-lookup-package, it can end up checking the closure of a manifest entry <civodul>that's when the manifest is read from disk <civodul>i think that dates back to before the 'dependencies' field was introduced <civodul>apteryx: you're right: manifest-lookup-package looks deeper than just propagated inputs <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 <civodul>so it would be a regression compared to now, right? <apteryx>or a slight improvement (the user can add something to the profile to change the outcome) <civodul>i don't quite like manifest-lookup-package as it is <civodul>it behaves differently whether it's looking at a "live" manifest (with <package> objects) or a "dead" one (with store file names) <civodul>in the latter case it looks at the closure of references <civodul>it'd be better to always look at manifest entries alone <apteryx>why do we have to deal with store file names directly? I see in the code it seems to be because of computed-file (or other gexp) used in the profile; is there a use case to do this? <civodul>(but that'd be even worse for the glib/gdk use cases) <civodul>"dead" manifests are encountered in the "incremental" model, that is, when you run "guix install foo" as opposed to "guix package -m manifest.scm" <civodul>"guix install" first loads the manifest from ~/.guix-profile/manifest <civodul>thus it contains store file names, not packages <apteryx>I was experimenting with live manifest only, and still could find gdk-pixbuf transitively <civodul>on a live manifest you could use package-closure, but that's quite expensive <civodul>for all these hooks, i think we should generally compute per-package caches <civodul>and then have hooks that merely assemble them <civodul>but it's not necessarily possible or easy to do <civodul>in this case, the hook would concatenate all the loaders.cache that packages already contain <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 <apteryx>I have to run; I'll ponder over it. Thanks for entertaining the discussion. ***tricon is now known as tricon-afk
<civodul>apteryx: oh indeed, it's plain text, we'd just need to concatenate them <civodul>it would not be much faster since it's already fast (it has less i/o to do though), but then you wouldn't need to do this whole manifest-lookup-package dance 