IRC channel logs
2024-03-30.log
back to list of logs
<db48x>only one copy of it was ever running <Aurora_v_kosmose>That normally should lead to logged errors though, without reuse enabled, so that's a bug anyway. <db48x>no, I am on Guix System, so it is shepherd rather than systemd <Aurora_v_kosmose>Ah, full Guix system. Good. Unfortunately that removes most obvious guesses I had left. <civodul>zamfofex: hi! it seems to work for me; any specific operation or URL that fails for you? <vagrantc>Aurora_v_kosmose: i actually do that with guix when packaging for debian ... wild, wild differences between the release tarball and the git tag. <vagrantc>most of it autofoo gibberish ... but also some things i think might actually be fixable <vagrantc>e.g. the release is built from a few commits after the tag ... <vagrantc>but the current release process uses the tag ... i think it just needs to be buildable by a specified commit that you tag after the release <vagrantc>but not many projects include how to build former versions of themselves as part of their code ... so that gets a little funky :) <Aurora_v_kosmose>vagrantc: Other than basically all non source-bootstrappable languages, anyway. <zamfofex>sneek: later tell civodul: Seems to be working again now, actually! Before, no packages would work, and the home page would fail to work too. <jaft>wingo: (assuming this is Andy) haven't read it in full, yet, but just came across your blogpost on getting Guix running on the Framework 13 AMD and, as I was possibly eyeing that for a next lappy, I was figuring I might need to seek out how others have done with it (in the context of Guix); just wanted to say thanks as I'm sure it'll make things easier, if the time comes <Guest96>I building a guix configuration system for syncthing. I'm at about 200 lines of guile. I expect the end results to be on the order of 500 lines. Is there a concern that Guix will not accept such a contribution because it is too long for just one program? <Guest96>I think syncthing is pretty powerful, so I would argue that it shouldn't be a problem <wakyct>hello, I've been playing around with the prebuilt qcow image in qemu, and I noticed there isn't a config for the guest account or one in /etc/, instead I think everything is kept in /run, is this just a peculiarity of building the qcow image or is this how some Guix systems are configured? <YatesRocks>hey all, i'm interested in running guix on an air-gapped device. can the installation from iso be done without internet? <YatesRocks>and is it possible to install packages / updates from usb? <vagrantc>YatesRocks: theoretically it would be possible if you built a custom image that seeded the store with all the needed source code for a minimal install ... but long term you're going to have to keep doing that <vagrantc>YatesRocks: i am not sure there is any tooling to faciliate that process ... <YatesRocks>vagrantc: alrighty, that's what I kinda assumed. <Guest96>Actually, I think there is that ability <YatesRocks>so i mean the hard bit is getting the custom image, which iirc i saw documentation for something like that <Guest96>the initial install might be difficult, but upgrades are quite possible. I built my entire home environment on another computer, copied the store itema over, then changed some symlinks in /var/guix/profiles/per-user/ <YatesRocks>i'll read some of the info pages and ask here if i have trouble <adanska>sneek: tell ludovic im going to try and reproduce the error whilst im at uni today: i havent experienced the error in weeks though, so im unsure if ill have any luck <sneek>ludovic, adanska says: im going to try and reproduce the error whilst im at uni today: i havent experienced the error in weeks though, so im unsure if ill have any luck <ardraidi>Honest question. Please don't take this the wrong way. <ardraidi>I have a few patches that have been there for a while (oldest 9 months). I think some of them were sent during a period where the Guix CI services had issues. <ardraidi>I also don't see the .scm files (e.g. arcan.scm) in teams.scm, so that might be a factor. <ardraidi>Did I miss something when submitting those patches, and that's why they weren't picked up? Maybe the fact that they are not in teams.scm is a factor? <ardraidi>I realize the team of committers is probably overloaded. I wish I could help, but probably too early for me. <lilyp>ardraidi: it is just committer/reviewer overload – gimme a bug number, I'll try to review it <ardraidi>I'm kind of worried this might set a precedent. Maybe I'm overthinking. <futurile>ardraidi: it's overload like lilyp said - one way to help is to review other peoples patches - we're running patch review sessions if you're interested (hint hint) <ardraidi>futurile: Where can I learn more about the sessions? <h3>futurile: Have you, even remotely, think to actually reply to asked question to see what would happen with that "script or something"? <h3>f1refly: Well if it does do a manual anyway because it lacks of instructions to make something that simple <jpoiret>it's not, they're most likely consulting the logs, so that they don't have to stay online <moesasji>I'm hitting a build failure on webkitgtk pulled in by the gnome update. Anybody else seeing this? <jpoiret>moesasji: are you building it locally? Do you have enough RAM? webkitgtk is a very expensive build <moesasji>Yes, as there was no substitute. I have enough ram (32GB) and cpu power to build it. <moesasji>it appears to fail in generating documentation for webkit2 <jpoiret>apteryx: I'm thinking of reverting/branching off before the pkgconf changes <jpoiret>multiple packages in the dep graph of desktop.tmpl don't build anymore, and I think it's time to push core-updates past the finish line <futurile>h3: it's difficult to answer your questions - they are quite complicated - so maybe emailing the mailing list would be easiest. One you asked is 'how to know what happened to a patch' - the easiest way is to look for the issue - https://issues.guix.gnu.org/ - you should be able to see the state there. <tusharhero>Is guix import pypi broken? It gives me this warning: <tusharhero>guix import: warning: Failed to extract file: itsdangerous-2.1.2.dist-info/METADATA from wheel. <tusharhero>guix import: warning: Cannot guess requirements from source archive: no requires.txt file found. <apteryx>jpoiret: oh. sorry I didn't have the opportunity to attempt building desktop.tmpl yet, but I'll get there, especially given there are issues to look at. But feel free to branch to a previous commit and finish prepping cu from there <lilyp>moesasji: It built fine on CI for gnome-team – whatever's happening is a post-merge fail <moesasji>lilyp: the error is in the pastelog I posted earlier. It is a strange one.... <yaslam>WASUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU <lilyp>I have no machine to build webkit on. You can submit a patch to fix the error, but it seems completely unrelated. <zjabbar>I have tried the following solution but it does not work: <zjabbar> (synopsis "The extensible, customizable, self-documenting text <zjabbar> (substitute-keyword-arguments (package-arguments emacs) <zjabbar> #~(cons "--with-xwidgets" #$flags)))) <zjabbar> (modify-inputs (package-inputs emacs) <lilyp>zjabbar: use a paste service <zjabbar> (commit "8e2f32cee982d42a79e53fc1e9aa7b8ff0514714")))) <lilyp>CI built webkitgtk for i686 three minutes ago – whatever bug you're encountering, it's weird <zjabbar>@lilyp How long did the build take? I tried doing a (with-source ...) package transformation but webkit times out on my computer. <zjabbar>This is a different way using inferiors which (I think) has access to the substitute from old guix. <lilyp>It takes 4 hours on CI, give or take. I wouldn't recommend with-sourcing webkit if you don't have a good machine. <zjabbar>Dang. I need to meditate on how to get this inferior to work. The browser within emacs was pretty sick. <ardraidi>futurile: Thanks for the link. Hopefully I'll be able to attend. <futurile>Q: I'm playing with a local build of Mutt, I've added a patch to the origin field (patches '("blahblah.patch")) - I keep getting a warning that "resolving xxxx.patch relative to current directory" - what am I doing wrong? <civodul>futurile: does it help if you instead write: (patches (list (local-file "blah.patch"))) ? <sneek>civodul, you have 1 message! <sneek>civodul, zamfofex says: Seems to be working again now, actually! Before, no packages would work, and the home page would fail to work too. <civodul>if you just provide a string denoting a relative file name, the thing isn’t quite sure where to look for the file, hence the warning <futurile>civodul: ah - yes that clears the warning - and makes sense. Thanks <civodul>got an idea 💡 set up a web site to host Guile/GNU-related manuals, automatically built from their Guix package, all with the same style, with proper cross-references <futurile>that would be cool - I spend a lot of time with both of them open - and searching in them - Guile is quite tough because it references lots of other SRFI stuff (and it tends to be short of examples) <futurile>Q: is there a way to append a patch onto the patches list from an inherited package: I'm trying - (patches (modify-inputs (package-source mutt) <futurile> (append (local-file "882690-use_fqdn_from_etc_mailname.patch")) <futurile>It seems like I'm getting the package-source - but then I can't figure out how to get the patch from the record? <civodul>yes, but not with ‘modify-inputs’ (that’s only for package inputs) <civodul>(origin … (patches (append (origin-patches (package-source mutt)) (list (local-file …))))) <civodul>i thought there was an example in the manual, but apparently not <civodul>there are certainly examples in (gnu packages …) though <futurile>ah cool that all works - thanks civodul - was so close .. and yet so far away from figuring that out heh <moesasji>lilyp: webkit-gtk managed to build on the 2nd attempt. <moesasji>Is it expected that Gnome44 has no default background? <lilyp>the VMs did have a background IIRC <lilyp>but I can't tell you whether it was a pattern or just a solid color <jpoiret>civodul: do you have tips when merging master into core-updates? a new commit B from master is conflicting with one of its own ancestors that got merged previously <jpoiret>well, not just one, that's the problem <jpoiret>i thought git would be able to manage that properly, but it seems I haven't used merges enough :) <ieure>Is there some trick to making channel news work? I followed the instructions in the manual, but `guix pull' fails because something is trying to eval the news file. Compared it to the official channel, and the setup is identical... what gives? <ieure>Dies with "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (channel-news)) (value #f))" <ae_chep>Once again, I am asking for some help to get #69023 through. Apologies in advance for the trouble <ae_chep>We're basically getting the language to bootstrap itself and turning off some recently added features <ieure>I guess channel news can't be in an .scm file? Which is weird, because the official Guix channel does it that way. <futurile>ae_chep: it looks like QA never processed it? <futurile>ae_chep: you might try bumping the series to see if QA will process it then <ae_chep>bumping as in, adding a note/email to the existing ticket? <civodul>but note that if it ends in .scm, it can be picked up as if it were a Scheme module when you pull from your channel <ieure>civodul, What's the thing in the official channel which makes it not do that? Official channel calls it etc/news.scm, doesn't have the channel source in a subdir, but doesn't break like mine does with that setup. <jpoiret>why are there a bunch of misc commits on core-updates? `git log --no-merges --first-parent origin/master..` reports commits like 0a91715442 gnu: Add python-scm-sr-ht. <jpoiret>ieure: the difference is in how they're built <jpoiret>the main channel has a specific build system whereas other channels are just *.scm -> *.go iirc <ieure>jpoiret, Where is that build expressed? Is the official channel special cased? <ieure>Okay, thank you for the explanation. <jpoiret>channels *could* have their own build system as well, no one has bothered to implement that feature though <jpoiret>t'would be a welcome change methinks <civodul>jpoiret: there’s ‘channel-build-system’ for packages, but you prolly mean something different :-) <jpoiret>i'm trying to clean up core-updates's log while i'm at it <jpoiret>there are a lot of commits which are on the branch that shouldn't be there <civodul>did you see my email BTW, re core-updates status? <jpoiret>ie they've seemingly just been applied on top, not merged <jpoiret>that means you can't just rebase easily <civodul>the branch is not meant to be rebased i believe <jpoiret>yeah, since we're just rewriting the history by dropping the pkgconf commits, might as well rebase instead. <civodul>traditionally we’d use the ‘wip-’ prefix for bracnesh that might be rebased <jpoiret>i haven't been that confident in the successive merges being successful <jpoiret>we can also revert the pkgconf commits, sure <civodul>why not fork off before the pkgc change? <jpoiret>forking off means no clean push anyway, right? <jpoiret>but in that case we can just make the branch more manageable. I think the stray commits are making the merges way more painful <civodul>that sounds less risky than rebasing a branch that has such a long history, merges, etc. <jpoiret>also quite a lot of commits have become irrelevant, or need to be changed in substance, which you can't really do during a rebase <civodul>we’ll need to talk collectively about processes once this is over :-) <jpoiret>ie. a commit disabling a test that used to fail but now doesn't anymore, the revert shouldn't go in the merge commit <jpoiret>yeah, tbh we should find a rebase workflow that works <jpoiret>merging into non-trivial changes is more dangerous than replaying the actual patches on top imo <civodul>but for now, i’d say the less risky approach is to fork off right before the pkgconf changes <civodul>and then cherry-pick anything that’s relevant from the commits that came after <civodul>(i’m saying this without actually doing anything though, so take it or drop it :-)) <jpoiret>git couldn't resolve lots of conflicts by itself which was very weird <jpoiret>haven't pushed yet. tbh i'm not super confident that the merges haven't broken something <civodul>i guess there’s always a risk, but then we’re embarking for a freeze + test period anyway <civodul>so we’ll find out if there are subtle issues <jpoiret>but really the git log is bloated by completely unrelated changes, i don't know how they ended up there <civodul>i guess we should clarify for everyone what the status is and get as many people as possible on board to work towards merging <civodul>podiki: hullo! are you or others in the security team looking into preparing a post/statement about the xz issue? <h3>futurile: I've already tried mail list. And not only of Guix. Through all my life I've never received any answer whatsoever. Not even negatives ones. It seems to be really for professionnals to discuss about bugs and that's all <h3>futurile: Yeah it's from that issue website that I've searched from to know what happenned to a patch. But nothing to be seen. It's only diff upon diff, and I don't know if it's been implemented or ditched or anything really <tusharhero>Is it neccasary to prepend a Go program with go-github-com*? <ieure>tusharhero, Probably depends on whether it's hosted on GitHub? Go packages are namespaced like that. <ieure>tusharhero, Then I'd assume yes, though I'm not familiar with Guix's Go packaging stuff. <ieure>It's important to include the full namespace, since, say, github.com/foobar/thing could get forked to github.com/bazquux/thing and you'll want to know which you're using. <jpoiret>h3: if the patch is on the bugtracker, usually the bug is closed once it's merged. <ieure>tusharhero, Well, it's the correct name, so, yes. <ieure>What would you change it to? <blum>If I'm very conservative with disk space, is it likely 50 gb is enough for a guix box or will packages alone eat all that? I'm not gonna save any multimedia, disk images, huge repos etc. <ieure>I guess the real question here is: is ollama a library other Go programs need to import? Or is it an end-user application? <podiki>civodul: can't speak about anyone else, but I can prepare a real quick message to guix info list. Not yet back to a computer today but will (some related messages to tend to on that front too) <ieure>Okay, then it should be named "ollama". <ieure>Syncthing is an example of a bare-named Go application. <jpoiret>blum: as long as you gc often it should be good <blum>jpoiret: thanks, i'll yolo it and see how it goes <tusharhero> error: go-google-golang-org-protobuf: unbound variable <jpoiret>tusharhero: i'd suggest having a checkout nearby that you can git grep <jpoiret>also for packages you can use `guix show` to see in which file they are <ieure>tusharhero, How are you building? `guix build' usually suggests what module you didn't import. <ieure>Ah. I have a channel set up and do `guix build -L. package-name' in the root of that checkout. <tusharhero>I am very new to Guix and newer still to writing package definitions <tusharhero>I keep finding things that are missing and I have to import <dale>When building an image with 'guix system image --image-type=qcow2 config.scm', how does one stipulate in the config.scm file that the disc image be GPT format? <dale>Am I supposed to wrap the operating-system object in an image object? <jpoiret>dale: currently we don't have an image type for qcow2 + gpt iirc <jpoiret>should be doable with some scheme, but from the CLI no <dale>I guess I can't easily do a UEFI boot in QEMU then. <x4d6165>is the guix security team aware of the xz backdoor? didn't get a notice in info so I wanted to make sure <ieure>I saw an xz update come when I pulled earlier today. Guix isn't affected by the SSH vuln. <ieure>(for some value of "update", at any rate) <ieure>Anyone have a good example of setting up a Guix system image which completely defines a user for build offloading? I have the container in decent shape, but the build user needs SSH keys, which means stuff in its home dir, which user-account can't do. <ieure>Sorry, special-files-service-type <ieure>Mm, that stuff just symlinks, so probably a nonstarter. <tusharhero>is it common to have 1000+ lines of package declarations in a single file? <db48x>ieure: isn’t that done by build-accounts on guix-configuration? <lfam>Not much you can do about "I'm tired and this person is willing to help" <db48x>no, not if they’re willing to be helpful for a few months or a year <lfam>Perhaps it does emphasize the utility of properly compensating FOSS projects and workers, but it's an American perspective $$$ <db48x>yea, the real answer is that if you want to prevent supply–chain attacks, then you have to hire someone to take ownership of the least well maintained part of that chain <lfam>A very challenging problem to address <apteryx>jpoiret: I'd just rename the current branch core-updates-next, then branch off from the commit you like and call that core-updates <apteryx>(or apply the 'remove-libtool-archives' phase to what I suspect are a handful of packages to get passed the few pkgconf-induced failures, but that's probably on my plate :-)) <apteryx>please do not rebase (rewrite) the branch history, as that's going to mess it up for everyone else who were working on it <podiki>re: xz exploit. I'll prepare a message now for info guix list <[>I don't think guix has new enough version to be affected. <podiki>indeed. among other reasons. but we will put out a statement <apteryx>magit seems well represented, as well as flyspell <dariqq>nice to see gnome-team branch getting merged :) <civodul>apteryx: the column on the left is total allocations? <apteryx>yeah... so not very useful. Apparently M-x memory-report may be what I'm after <lfam>"Building the following 9097 packages would ensure 21968 dependent packages are rebuilt" <podiki>cairo alone is 14k dependents, which will be the big one on mesa-updates shortly <PotentialUser-45>I've looked into GNU Guix from time to time, and I've always noted that packages seem to be out-of-date. In some cases, I understand that the package may simply be hellish to build (e.g. calibre), but at other times, I am not so sure. For example, I was curious what version xz was on (since it's in the news and all), and according to the package <PotentialUser-45>explorer, it seems to be on 5.2.8. For reference, the current (sketchy) version would be 5.6/5.6.1. Is this simply because there is a lack of manpower, or is it something else? I think it would be nice if I could switch to GNU Guix for my main system, but I am not sure whether it is alive/mature enough for that. <apteryx>cbaines: nar-herder on guix-hydra-129 seems in order, using a stable 1.2 GiB of RSS for now <blum>PotentialUser-45: ftr debian stable has xz 5.2.5 <PotentialUser-45>blum: I thought GNU Guix was a rolling release distro - was I wrong in that? <blum>I'm a guix noob, so can't rly answer unfortunately :^) <podiki>but the rate of roll depends on people-power :) <podiki>xz is one that affects many many packages, so updates for those tend to be slower <podiki>also depends on what people notice and decide to contribute <podiki>civodul: assuming you can moderate info-guix, I just sent a message; not sure if it can be approved or if i should send it to someone to send out instead <podiki>yup. we are still growing and figuring things out to do better, but we welcome contributions <podiki>you can see if what is important to you is more up to date or not of course, but many of use here of course use guix daily and maybe exclusively <civodul>podiki: sure, i’m among those who can click on the thing, lemme see <podiki>civodul: I sent to guix-devel as well (as you probably received now too), for completeness. and since i don't know if the guix-daemon cve was ever discussed there <podiki>jpoiret: should I take it you are branching and freezing core-updates? (probably a good idea) in which case I can take some ungrafts on mesa-updates next <civodul>podiki: i clicked on “Approve”, thanks for taking care of it! <civodul>yeah i guess we forgot to post the guix-daemon CVE on info-guix <civodul>it’s good to have that ready on the day there’s a fire to extinguish <podiki>i think it is time to formalize a lot of our guix structure (as has been coming up) <apteryx>civodul: a more useful command is 'memory-usage', from ELPA. I've just packaged it, will push it a bit later <podiki>my time on guix-security as been eventful <hapst3r>How do I deal with dependencies whose Version number is lower than the version packaged by Guix? Say I need ruby2.4, but the earliest packaged Version is ruby2.6? <podiki>we will have at least one update/ungraft coming (libarchive) <podiki>so i don't know if you want further big builds on core-updates. maybe better to just work on making fixes there? <podiki>we might have some others that have gone to master recently? i can't remember. i expect one for nss (we need updates, unless that was updated on core-updates already) <jpoiret>i'm not seeing any grafts on c-u right now <podiki>well for any new ones while core-updates is being finalized, I can take them on mesa-updates if that is helpful <jpoiret>i don't think we're close to being finalized, but I don't think I can take another world rebuild again <jpoiret>it's what's killed the momentum for me <podiki>i tried to update nss and after a looong time a handful of tests failed :( <podiki>out of like 14k tests or something like that <podiki>your work is appreciated jpoiret! and motivation for us to really limit core-updates and keep it more manageable (as much as such a thing can be) <jpoiret>yeah those long test suites are a pain <jpoiret>ghc too, it's fast to build, but slow to test (doesn't help that parallel tests make them flaky) <podiki>i was proud that i found out we could enable curl tests to be parallel, which helped a lot <podiki>but yeah, nss might take the cake, extremely long <podiki> ls $(guix build coreutils)/bin says no <podiki>(guix locate grep told me, since it is installed) <monaho>weary-traveler: coreutils and findutils are two distinct gnu projects and are packaged separetely in every distro <weary-traveler>TIL. i was under the impression coreutils included find and grep. i was mistaken it seems