IRC channel logs
2023-04-25.log
back to list of logs
<mirai>assembly doesn't have a trailing slash yet the basename isn't honored? <lfam>Thanks efraim! I'm trying to make it work now <lfam>Got it! Thanks again efraim <lfam>I never would have figured that out <mirai>apteryx: is there some rationale to keep docbook-dsssl-doc as a private variable? <mirai>I'm thinking on merging it into docbook-dssl and split the outputs in there <apteryx>mirai: it doesn't need to be private because it's exposed as the "doc" output of docbook-dsssl already <apteryx>it's a separate package because it's released distinctly <apteryx>rekado: would you happen to know if outbound SSH from berlin is blocked? GIT_SSH_COMMAND='ssh -vvvv -o ConnectTimeout=10' git fetch origin in my 'guix' checkout, I get: debug1: connect to address 209.51.188.168 port 22: Connection timed out <apteryx>my SSH agent is forwarded to berlin (ssh -A) <mvnx>Some people have mentioned they install Guix with --no-bootloader - what do you use to boot instead? <apteryx>podiki[m]: ah, docker-compose is now a go app <apteryx>I fixed it by re-introducing a python-jsonschema-3 <tribals>How applying graft from command line will do if graft is named same as grafted package, but comes from another location? <tribals>Example: there is foo package. It depends on bar. I redefined bar (through inheritance) but changed a little: just applied patch. What will happen if I run this command: `guix build --with-graft=bar=bar foo` <podiki[m]>apteryx: do you know why if I try to update python-pypa-build to a newer version and use pyproject-build-system it seems to introduce a cycle? i removed all inputs too <podiki[m]>ah I think it is through python-toolchain. hrmm <dcunit3d>can anyone help me with building python using pyenv on guix system? it's basically like trying to build on NixOS my build log is here. <dcunit3d>something is not finding the headers correctly. I passed the include to CPPFLAGS and i see it in the calls to gcc, but i think there's something wrong with pkg_config https://0x0.st/HKM2.3.log <dcunit3d>i may end up using the python packages, but it's a bit harder to manage virtualenvs. by using pyenv, i was hoping to make configure my two systems so that working with python feels the same (i can share .envrc's on projects between both computers without changing them) <dcunit3d>all the same, i would like to learn more about make/autotools and building C/C++ software, especially so that I can handle these situations more easily. <apteryx>podiki[m]: yeah, this module is very sensitive to cycles <apteryx>dcunit3d: I recommend packaging everything the Guix way and using 'guix shell' <podiki[m]>apteryx: any thoughts on what to do here? probably need to do a pyproject build manually without using pyproject-build-system? or separate out the newer python-pypa-build for use as a direct input when needed by packages? (which is why I was updating it) <podiki[m]>and inevitably it will need to be upgraded anyway <sammm>hey hey, quick one I hope: I'm using the wonderful guix home to manage my emacs configs/packages. The issue I am facing now is that emacs cannot write to the readonly XDG config dir ` emacs: early error: no suitable directory for output in 'comp-native-load-path`, any ideas? <sammm>oh, that was meant to be `native-comp-eln-load-path`* <podiki[m]>i'm not sure about guix home (haven't used it yet), but I manage my emacs packages in guix and you can have it native-compile on install with e.g. guix install emacs-some-package --with-input=emacs-minimal=emacs <RavenJoad>Aha. I figured out my guix pull issue. Apparently Guix does not like using getenv in the default value field of a define-configuration (and co.) objects. <mirai>RavenJoad: well, that wouldn't work because the value would come from runtime <RavenJoad>mirai: Yep. I figured that one out once I saw it. It was just unfortunate that there was no way for me to find out beforehand. Perhaps a note should be added to the manual? <apteryx>podiki[m]: yes perhaps steal the old pip-powered build that used to be done in python-isort for example <podiki[m]>thanks for the pointer, I assumed one would be around that had it as an old manual phase but didn't know where <podiki[m]>hum...well that depends on python-pypa-build <podiki[m]>maybe keep this older version of python-pypa-build as a bootstrap and use that as input to build current version? would that work? <podiki[m]>build claims it can build itself with tomli only, but i'm not sure what that means or how to do it <apteryx>podiki[m]: python being interpreted, you can probably simply 'export PYTHONPATH=$PWD' to have it use itself to build itself <apteryx>I've used that trick a couple places <podiki[m]>well i got it to build from the older version, though trying to run tests hitting what i think others mentioned: In execvp of pytest: No such file or directory or maybe it is something else <yehochanan>what do I do if my USB thumb drive doesn't show up on the XFCE file manager? <apteryx>yehochanan: I use 'udisksctl mount -b /dev/sdX' <apteryx>it's a bit of a pain, we should fix these issues <apteryx>sneek later tell andreas-e: my system and large user profile have successfully been reconfigured to use core-updates! <podiki[m]>oh right, didn't include pytest, and can't due to a cycle <podiki[m]>bah python-pypa-build will need things from other python modules...ugh <podiki[m]>so let's ignore the sanity-check and starting building the python world and see what happens... <podiki[m]>nope, python-pyproject-hooks is needed....i'm stuck <yehochanan_>the f2 and f3 keys on my laptop normally control volume, however on XFCE+Guix they don't do anything <podiki[m]>you may need to set up the keys manually and/or check bios settings (or key combo) to enable/disable needing fn key <podiki[m]>apteryx: i've given up for now untangling the python-pypa-build cycles; will just add a new package for the new version separately in my patches <podiki[m]>apteryx: oh actually, python-pyproject-hooks is a new package I added so maybe it can just be moved to avoid the cycle...will investigate tomorrow <podiki[m]>apteryx: oh! pyproject-hooks is what pep517 was renamed. so this should all be sorted out already just with some updates. <rekado>does anyone know how to disable pep517/envbuild? <rekado>pep517 tries to pip install packages before running the tests <rekado>that’s the only thing that fails – the test suite itself completes fine <rekado>I’d like to disable the attempt to install packages <florhizome[m]><yehochanan_> "the f2 and f3 keys on my..." <- I have these same problems in xfce and GNOME doesnt even start up... guix DEs are quite bad atm <rekado>florhizome[m], yehochanan_: works fine for me with Guix System + Gnome <podiki[m]>rekado: not sure what you mean, but I see that happen and if I include the needed package it doesn't try anymore. is that what you mean? <rekado>all the required inputs are there <podiki[m]>what does it try to install then? something you already have? <rekado>there appears to be some sort of hook that runs: ['/gnu/store/l6fpy0i9hlll9b6k8vy2i2a4cshwz3cv-python-wrapper-3.10.7/bin/python', '-m', 'pip', 'install', '--ignore-installed', '--prefix', ...] <rekado>it tries to install to a pep517-build-env <podiki[m]>i think it should call the flag for ignoring dependencies <podiki[m]>(if you see the recent log you'll see i've been struggling trying to update what turns out to be some of this build system) <florhizome[m]>I'm even having a hard time using evolution outside of gnome <rekado>florhizome[m]: how does Gnome fail to start for you? <rekado>I wouldn’t say DEs in Guix “are quite bad atm” <rekado>so if you could provide details perhaps we can help <florhizome[m]>I don’t think they have been a focus of maintenance, and maybe there aren’t enough resources for all of them - I think most maintainers use WMs. <florhizome[m]>Gnome is pretty out of date, too. It would make sense if guix would narrow down a scope of DEs it supports more or less officially (that appear in the installer) to be able to make that a priority, but that’s beside the point… <florhizome[m]>I can’t really find a good hint. It just doesn’t start from gdm <florhizome[m]>It’s been happening for quite long now, I stripped down my system config to barebones (with free kernel), and it’s the same for X11 and wayland <Michal_Atlas[m]>I had this problem and for me it was literally just an old XDG environment variable that broke it. <florhizome[m]>About xfce, icon packs and themes installed via guix home don’t show up in the appearance menu, but cursors do <Michal_Atlas[m]>Sorry, had to go find it, I set XDG_CURRENT_DESKTOP=sway in Guix home, and that freezes gnome on startup <florhizome[m]>I only manipulate XDG_DATA_DIRS to include flatpak resources and my eMacs profile <Michal_Atlas[m]>But you're right, there are some things, perhaps separating some of the DEs into a separate extra repo and just leaving 2 or 3 official ones might make sense <florhizome[m]>I think it’s fine to offer the packages and services but just mark certain ones as stable and test them with major updates <Michal_Atlas[m]>Not saying any of them have major problems, but they're often not too out of the box working experiences <nutcase[m]>Hi, I'm doing 'guix shell --with-version=maven=3.8.6 openjdk@17.0.5:jdk maven' and get 'guix shell: warning: could not find version 3.8.6 of 'maven' upstream'. Why can't Guix find the version upstream? It is exactly the version I install with 'guix install maven' and which is defined in maven-pom in gnu/packages/maven.scm <florhizome[m]>I also find the idea interesting to see how much of a DE could be run as a home or other user service <florhizome[m]>Gnome is the only thing offering good gesture and touchscreen support <Michal_Atlas[m]>Okay, sorry, let me rephrase, sway and co. services would just work had that running for myself for a while, Gnome I'm not sure but should be possible afaik <efraim>mrustc is failing to build on riscv64 on core-updates :/ <efraim>I might need to save that for when I rebase rust-team after the core-updates merge <florhizome[m]>rekado if you could maybe tell me logs to produce I can upload them <Michal_Atlas[m]>Btw, once gccrs is shipped, are there plans to move some cargo-build-system things to that? Or is that too far in the future? <Michal_Atlas[m]>Wouldn't changing it in a local checkout and using ./pre-inst-env work? <nutcase[m]>Michal_Atlas: probably. I'm quite new to Guix and haven't tried that before. What do I need in a shell to run ./bootstrap and ./configure? <rekado>florhizome[m]: does gdm come up? <rekado>if it does there should be /var/lib/gdm with logs <rekado>if it’s just gnome-shell that doesn’t start you may want to move ~/.local/share/gnome-shell/ out of the way — perhaps it attempts to restore settings <attila_lendvai>if i have a leaf node application (zigbee2mqtt), then should i add it to messaging.scm (means additional use-modules forms) or to node-xyz.scm? <Michal_Atlas[m]><nutcase[m]> "Michal_Atlas: probably. I'm..." <- There's a short tutorial video on the site, that walks you through it, otherwise I think so, that should be it, maybe even leave out the --pure <florhizome[m]><rekado> "if it does there should be /var..." <- I think you mean /var/log/gdm? <rekado>florhizome[m]: no, I mean /var/lib/gdm, which is the gdm user’s home directory <attila_lendvai>so, i'm getting into packaging that node.js application, and it looks like an endless web of dependencies... and there seems to be active node.js work getting ready for merging (https://issues.guix.gnu.org/59188)... so, mission aborted. <attila_lendvai>jlicht, looking forward for those node.js commits getting merged! :) <janneke>ACTION fightting with --add-header="X-Debbugs-Cc:", seems that debbugs only takes one header after forgetting it in the initial bug report <florhizome[m]><florhizome[m]> "ima_ea9919f.jpeg" <- This seems to point to a Problem with orca <PurpleSym>apteryx: I pushed the downgrade to trio 0.21. No further failures in my tests, actually fixed 13 leaf packages via guix refresh. <minima>with regard to reproducibility, for those cases where there's no bit-by-bit consistency between, say, CI and Bordeaux, is there any particularly common root cause? is it for some non-deterministic bit that possibly made its way through to some packages? <janneke>minima: the hardest cases are where timing is involved; two builds on one machine (with different loads) would likely be non-reproducible too <ngz>Hello. I'm trying to use mumi, but, for example "mumi current xxxxx" raises an error : "No git top level found". Also, "mumi fetch" keeps complaining for a missing file ("/var/mumi/data/spool/index.db.realtime"). Am I misusing the tool? <minima>janneke: oh i see, interesting; when you say timing, is it about "how long the build takes" (therefore you mentioning different loads)? <rekado>florhizome[m]: e.g. /var/lib/gdm/.local/share/xorg/Xorg.0.log <janneke>not so much the duration, but relative durations, ie, interleaving of things that should be ordered <rekado>florhizome[m]: and /var/lib/gdm/.cache/ is a candidate for deletion, in case you’re seeing problems <minima>janneke: ah, i see, cool, that makes sense, thanks!! <florhizome[m]><rekado> "florhizome: and /var/lib/gdm/...." <- The xorg dir doesnt exisr <rekado>florhizome[m]: are you using wayland? <rekado>what does your system config look like? <rekado>if you aren’t using wayland gdm should at least be able to start an X session, and so there should be that log file <rekado>is there *anything* in /var/lib/gdm? <attila_lendvai>rekado, you changed beautify-description to escape @. this means that importers cannot generate texinfo into the description (if they want to use beautify-description). any hints how to proceed? my local go importer parses sxml to generate @url{...} and stuff like that. <attila_lendvai>looking at what beautify-description does, not calling it would be a loss <florhizome[m]>No but after starting an xorg session there also isnt that dir <florhizome[m]>rekado srry i just took a nap ill upload the minimal config im working with and logs asap <bjc>huh: guix offload: error: corrupt input while restoring '/gnu/store/guix-2ZTb6f/lib/ghc-8.4.4/ghc-8.4.4/libHSghc-8.4.4_p.a' from #<input: string 7fbabe2e1310> <bjc>was it apteryx who was seeing something similar before? <rekado>attila_lendvai: beautify-description was written for the cran importer. The importer gets some garbage, and beautify-description massages it. <rekado>it was not written to work on text that already looks like it should <rekado>you could change it to check the text following “@” to see if it is texinfo syntax <rekado>or you could add keyword arguments to skip certain behaviors <apteryx>sorry, I didn't understand what you wrote <AwesomeAdam54321>apteryx: I think telmo[m]'s asking whether flatpaks can enable software freedom as a packaging format <telmo[m]>Sorry, my english its bad without translate <AwesomeAdam54321>telmo[m]: Thanks for sharing! It's interesting that there's now a FSDG flatpak repository that can be used <apteryx>Our flatpak package should probably be configured to use it out of the box <bjc>i'm consistently getting “[GSSH ERROR] Parent session is not connected: #<unknown channel (freed) 7fdb2d4a64a0>” when offloading an llvm build. it happens while exporting the checkout. any clues? <apteryx>bjc: I think there's an unresolved issue about that <bjc>are there any workarounds? <bjc>i really don't want to build llvm on my anemic desktop =) <apteryx>GUIX_DAEMON_SOCKET=ssh://your-offload-host <bjc>i didn't know guix could use a remote daemon. that's pretty neat <bjc>how's that work for substitutes? am i going to have to add my offload host to my list of substitute servers? <apteryx>or just 'guix build the-thing' after it's been built on the remote will get it by offload, I think? <bjc>i'll try it when llvm is done and let you know <bjc>if it's your first report, you might be waiting for a bit <telmo[m]><AwesomeAdam54321> "telmo: Thanks for sharing! It'..." <- Appcenter.elementary.io too is freedom, but its more for your ecossystem <telmo[m]><AwesomeAdam54321> "telmo: Thanks for sharing! It'..." <- Now the guix project and others can replace flathub for pureOS flatpak <bjc>you do not have to set up the offload box as a substitute server, btw <rekado>florhizome[m]: have you tried deleting /var/lib/gdm/.config? <rekado>it says that it failed to parse a session file <civodul>apteryx: hi! i'll reconfigure berlin on the same commit as shown by "guix system describe", but with the latest maintenance.git (this is to get the new build-package-metadata.scm running) <cbaines>civodul, isn't the website still hosted on bayfront? <civodul>so i guess i'll reconfigure bayfront first? <cbaines>I don't know much about build-package-metadata.scm, but reconfiguring bayfront sounds like the thing to do <civodul>alrighty, i'll do that (again on the same Guix commit as it is now) <rekado>florhizome[m]: have you deleted everything in /var/lib/gdm already? <PurpleSym>Did core-updates get merged yet? Still sitting on GHC for i686 patches that I should push. <nutcase[m]>bjc: yes, it is my first bug report. Thanks for the info. <Altadil>Hi, I am trying to add a second encrypted drive to my config. Looking in the manual, I understand I must add a mapped-device, similar to the one the installer made for the main drive. But I would like to open this second drive with a keyfile located on the first. How can I specify this "passphrase source" in the Guix config ? <andreas-e>jpoiret: Thanks! And thanks for your help and support, as well as that of so many other people! <sneek>Welcome back andreas-e, you have 1 message! <sneek>andreas-e, apteryx says: my system and large user profile have successfully been reconfigured to use core-updates! <jpoiret>Altadil: I don't think it's possible in an easy way currently <PurpleSym>I’ll push the GHC fixes for i686 to master shortly then. Shouldn’t cause any rebuilds for x64. <andreas-e>PurpleSym: Just try the patches on master now and push them if they work. You cannot break things on i686, and we should have enough build farm power for x86_64. <SomeUserName>Hello! I'm trying to update flac from version 1.3.3 (in the current repository) to 1.4.2 and I'm stumbling upon the following issue: <SomeUserName>running `./pre-inst-env guix build flac` fails at test time saying <SomeUserName>> ERROR: iterator claims file is writable when tester thinks it should not be; are you running as root? <andreas-e>jpoiret: Indeed! And I feel very relieved now, it was a stressful moment to finally merge. <Altadil>jpoiret: OK, I’ll figure something else then. Thank you. ^^ <bjc>now we just get to wait for the bug reports ;) <jpoiret>i'll reconfigure asap (just need That Other Channel™ to merge their core-updates as well) <andreas-e>bjc: I enrolled you for work already, see my message to guix-devel ;-) <apteryx>rekado: note that /var/lib/gdm is now on a tmpfs, so gets cleared every boot <rekado>florhizome[m]: Ignore what I wrote above. The log shows that gnome-shell is in fact started, so you should look for your own user account’s log files. <SomeUserName>Hey, concerning flac, in fact the version 1.3.3 in the current repository fails to build with the same error message <SomeUserName>Anyone running `guix build --check flac` should be able to confirm that. <bjc>podiki[m]: i've updated #63044 <bjc>it changes python3.10, so there's a lot of knock-on <spiderbit>is nextcloud support in gnome working? or other services? I added a nextcloud account yet I don't find a mountpoint or anything in nautilus for it <jpoiret>bjc: could that be batched along with a python update? I don't know if we want to try 3.11 straight up <florhizome[m]><rekado> "florhizome: Ignore what I..." <- Where exactly should i look at? <bjc>jpoiret: that's the plan, i think <rekado>ACTION tries to build everything in bioinformatics.scm <bjc>it'd be nice if we could unbundle python-setuptools from python, but i suspect that's a bigger issue <bjc>but right now you don't know which version will be used <Altadil>spiderbit: I just tried it and I do get the folder. Do you have 2FA on your Nextcloud ? If so you need a special application password, not your normal one. <spiderbit>maybe it's because I use it from outside gnome <spiderbit>I still don't get why there is no gvfs-mount command availible as example <florhizome[m]>spiderbit if you added the account it should be visible in Nautilus <podiki[m]>bjc: I'm looking to update a build system package anyway, so it'll rebuild all of python if we do it too <podiki[m]>did the core-updates merge happen?? did i miss the moment? <andreas-e>Is everybody guix pulling now? I have a throughput of about 50kB/s from Savannah. <podiki[m]>(i have to update a certain other channel before doing a pull, and return my channels.scm to pre-core-updates state) <minima>on that basis, it'd seem that a git signature signs more or less the entirety of a commit <minima>and i'm not sure i can reconcile the two parts <zamfofex>Hello, Guix! I have created a few unrelated additions/updates to packages in my local Guix clone. What would be a good way to set up patches for each of those changes? Is it sensible to commit each of them in some order, then generate different patches for each commit? <AwesomeAdam54321>zamfofex: yes, commit the added packages according to ascending topological order, likewise for updates <andreas-e>minima: From an identification point of view, an object and its hash are indistinguishable (assuming the crypto is safe...). For instance by second preimage resistance of a hash function: given x and SHA1(x), it is impossible to find y != x with SHA1(y)==SHA1(x). So if you sign SHA1(x), it is clear you obtained it from x, so it is like signing x. <zamfofex>AwesomeAdam54321: Note that the changes are entirely unrelated to each other, so there is no real “topological order”, I think. <podiki[m]>andreas-e: how did the actual merge happen (i'm not super git savvy)? an actual merge? or cherry picked all commits after a local rebase? <minima>yeah, that i get it, but that'd be in the context of a perfectly secure hashing mechanism, which sha1 is not <andreas-e>I first merged master to core-updates a last time. Compiling it gave an undefined variable, which I corrected by an additional commit. <andreas-e>And then I merged this core-updates into master. <andreas-e>But since there had not been any additional commits in master in the meantime, it does not look like a merge. In fact the new master is identical to core-updates. <podiki[m]>since it was clean after the master->core-updates merge <jpoiret>i was looking through the git history to find the merge commit but couldn't find it : <minima>reading the SO post and skimming through git's codebase for a minute i was reassured that the signature applies to the entire commit (which would be resistant to the hashing mechanism being broken, i believed...) but then i read the paper and i got confused again <andreas-e>minima, jpoiret: This is a detail of implementation ;-) Of course once the hash function is insecure, the signature breaks down. <podiki[m]>also there's no force-pushing on savannah right? so you can't do things like a rebase <jpoiret>is it impossible to force-push to all branches or just master? <andreas-e>minima: All digital signatures start by hashing the content internally. <andreas-e>jpoiret: By convention, the wip-* branches may be rebased. So this appears to be technically possible. <minima>andreas-e: ah... so the issue is that git does sign the entirety of the commit, but that also goes through sha1... ah! insight! thanks, that makes it all clear now, i understand why the concern, as expressed in the paper <jpoiret>ah, great, that's what I was wondering <andreas-e>minima: I do not know which hash the git signature uses. <minima>andreas-e: well, according to the paper... it must still be sha1, i suppose <andreas-e>Rebasing would invalidate the signatures, so we cannot do it on the master branch. <andreas-e>It looks like git just delegates signatures to gnupg, so whatever they do will be used. <jpoiret>basically, if someone can mitm you and also find a collision for a commit sha1, they could technically add any code to it <bjc>a git commit is a reference to a tree, any immediate previous commits (typically one, but can be more for merges, or 0 for the root), and meta-data like the commit author/date/etc. the tree is a hash of a reference to the hash of every blob (basically a file) in the tree <bjc>so every commit hash can verify that the complete contents of a tree at a given commit along with its metadata <andreas-e>The git commits are 40 hex characters, or 160 bits. So this looks a lot like SHA-1 :) <minima>jpoiret: the way i understand it, it's more serious than that, you don't need the mitm part, you just need to (systematically) break sha1 (but i might be wrong, i'm just reading about this now) <bjc>if you can find a way to generate hash collisions, it all breaks down <jpoiret>minima: but you still need to somehow deliver that trojan commit to the user you're targeting <andreas-e>Which probably means that if SHA-1 is broken, you can modify a commit in a way that would yield an unchanged commit hash, and then the signature is still valid. <andreas-e>For this, you need a second preimage to a given hash value and not just a collision. <minima>jpoiret: oh well, yes, i think i get what you're saying, true... although that might be a relatively easier part <jpoiret>the cost of a SHA-1 collision is 45k USD according to wikipedia <andreas-e>(Well, you also need not just a random second preimage, but something that somehow suis your evil needs.) <jpoiret>yes, I'm talking about chosen prefix collision <andreas-e>Is "guix pull" so incredibly slow for everyone? <bjc>was fast for me. 4mib/s <jpoiret>maybe everybody wants to try out glibc 2.35 <andreas-e>bjc: Maybe someone cut a transatlantic cable then... <bjc>i'm in the us. this is actually much faster than i normally get from ci <PurpleSym>andreas-e: Fingers crossed it actually fixes the build. <andreas-e>bjc: These are two things. The git repo is at the FSF in Cambridge, Massachusetts (I think), CI is in Berlin, and a second build farm in Bordeaux. <bjc>andreas-e: this was downloading substitutes (guix-cli guix-extra etc) <bjc>at least, i assume those are substitutes being downloaded. guix pull is still a black box to me <civodul>would be nice to have an entry in etc/news.scm listing the major differences <andreas-e>"guix pull" starts by "git pull", which is incredibly slow for me just now. <andreas-e>Who knows what the differences are? That sounds like a joke, but I think nobody does.. <bjc>that's awesome. i had no idea. so everything is built from mes now? <civodul>janneke: speaking of which, now would be a good time to get a blog post out :-) (i can give a hand if you want) <janneke>civodul: that would be great, i'll dig out/prepare something <bjc>jpoiret: so are we gonna wait for c-u to shake out of ci, then try to get python updates happening? <janneke>(when i say finally i don't want to sound ungrateful, many thanks to everyone involved!) <jpoiret>bjc: wdym by c-u to shake out of CI? <bjc>with the merge to master, i assume ci is very busy right now <civodul>yeah, good job everyone, and thumbs up andreas-e for keeping it going! <podiki[m]>my "just fix yubikey-manager" has turned into updating the python build system package; not fully neccessary but we might as well if things build ok <jpoiret>ah, yes. Doesn't mean a new branch can't be opened for it, as long as there's no CI job for it it should be fine <podiki[m]>i'm still sorting out the dependency cycles for the update <podiki[m]>but any other low level python changes that are ready could also be built with this branch <podiki[m]>i'll try to finalize my commits today and submit the series for review <bjc>there's no small amount of irony in guix getting this close to a full bootstrap, finally closing the "trusting trust" hole, at the same time that node, go, rust and more are employing entirely new "trusting trust" holes with their package managers combined with built tools <PurpleSym>podiki: What kind of updates does python-build-system need? I thought we’ll replace it with pyproject-build-system at some point. <podiki[m]>yes, pyproject; it is python-pypa-build package and pep517 which is now pyporoject-hooks <podiki[m]>not strictly needed (i could add the updates as new packages rather than in the toolchain) but we'll need to eventually <podiki[m]>so I figure let's see how it builds, assuming I sort out the cycles; and if it is a headache we can defer in favor of fixing more immediate needs <PurpleSym>So you mean pyproject-build-system would use these packages to build other python packages? <civodul>vagrantc: in the same sense that Debian is 99% reproducible ;-) <podiki[m]>yes, it is currently and I wanted to update those packages <podiki[m]>the trick is that at least python-build now wants some more stuff and would lead to a cycle with the python modules <jpoiret>podiki[m]: so are you also aiming for python 3.11? <jpoiret>just want to know against what version I should base my patch <podiki[m]>just pep517 which is now call pyproject-hooks, and python-pypa-build <podiki[m]>took me to late last night to realize pep517 is renamed, so I think we do have the bootstrap structure I can just update <PurpleSym>pyproject-build-system itself does not use any external tools. <andreas-e>bjc: The charm is that CI should not be busy. By regularly merging master back to core-updates we have made sure that the latest core-updates is essentially the same as the new master. We are only trailing the aarch64 backlog. <jpoiret>civodul: should we open up a core team thread to uncover some potential goals? <podiki[m]>i don't know if I'll actually update the toolchain at first or just introduce the package updates; then we can deprecate pep517 for pyproject-hooks and deal with that (some find/replace I guess) <bjc>andreas-e: ah, true! that's pretty encouraging <podiki[m]>PurpleSym: are you pretty familiar with pyproject and python-toolchain? i might enlist your help or at least to review/clean up what I do <podiki[m]>but i won't assume, cause well...i don't always remember how i did things myself :) <PurpleSym>We’ll find out. Just CC lars@6xq.net, but it might take a while. <podiki[m]>while I have you here though, the newer python-pypa-build I think I managed to build from the previous version, it will want pyproject-hooks though, which hopefully can build without cycles as pep517 did <PurpleSym>There’s no generic tricks, unfortunately. I’d have to look at it. <podiki[m]>ok. well i'll ping you when i have something that roughly works or have given up :) <PurpleSym>I’m not sure why we have pypa-build and pip in python-toolchain though. They’re basically equivalent. <rekado>civodul, PurpleSym: I guess we’ll have some work to do for guix-past, guix-science, etc <rekado>I’m currently still trying ot fix new build failures in bioinformatics.scm <civodul>rekado: yeah; i'm still on jupyter but i end up upgrading the Python world, which doesn't sound good <jpoiret>regarding Hurd, I can try adding glibc-2.37 just for hurd <rekado>civodul: I feel I might not be able to continue for long, because I’m still sick and it’s gotten a little worse… <civodul>rekado: oh, sad to hear; take care of yourself <civodul>jpoiret: right, but maybe we should fix what we have first? :-) <podiki[m]>civodul: what sort of updates for jupyter cause the big rebuilds? <jpoiret>civodul: the thing is, I'm not sure if the problem comes from our configuration, or from a bad choice of commits <jpoiret>maybe I will need to learn some kernel debugging there <civodul>jpoiret: yes, it's rather fun (more than upgrading Python packages) <civodul>down the rabbit hole... "An extremely fast Python linter, written in Rust." ⁉ <bjc>it was nice knowing you, civodul <zamfofex>jpoiret: It makes me happy to see people interested in making Guix work well with the Hurd! <RavenJoad>Is biber 2.16 failing to build for other people too? CI shows the first error was on April 7. <civodul>we should get the pypi importer to retrieve all the versions from requirements.txt and compute the set of packages that go together given these constraints <jpoiret>RavenJoad: seems that it's due to a perl update <jpoiret>RavenJoad: I'll send a patch for it soon <RavenJoad>Ahh... I guess perl changed something in tis testing protocol, as none of Biber's planned tests get run. I get (wstat 65280, 0xff0) and "compilation failed in require". <jpoiret>just built it, required backporting a patch. <jpoiret>it would be nice to be able to upgrade our tex packages though <RavenJoad>Agreed. Guix's are from 2021, or something like that. And the 2023 release of TeXlive happened a week ago (something like that). <mirai>I see that c-u has been merged? <RavenJoad>Awesome. Thanks! Perhaps I can do a guix pull in a few hours and finish building my home environment. <mekeor[m]>hi guix. how to send patches from emacs (magit) (instead of command line)? <jpoiret>lechner: you might want to open a bug and cc the home team <RavenJoad>jpoiret: Alternatively, I could just submit a patch to update biber to 2.19... <spacecadet[m]>I'm getting an undefined symbol error from guile when I try to run the guix repl, is this just me or something break from the merge? <jpoiret>RavenJoad: no, apparently biblatex needs to be kept in sync <spacecadet[m]>/gnu/store/ad8351jvj61da279a3ddfs2gmk3whvdq-guile-wrapper/bin/guile: symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE <mirai>so, what's the fate for patches that will trigger world rebuilds now? <jpoiret>no, no, it's some .so leaking again for some reason <jpoiret>spacecadet[m]: can you `guix shell glibc -- ldd /gnu/store/ad8351jvj61da279a3ddfs2gmk3whvdq-guile-wrapper/bin/guile`? <RavenJoad>jpoiret: Interesting. I guess updating TeX is all that can be done then. <jpoiret>spacecadet[m]: do you use any weird guile stuff in your .guile? <gabber>hello there! i am running into issues trying to set up my childhurd as an offloadable machine. `guix offload test` tells me: "Access denied for 'publickey'", while the /var/log/messages in my childhurd vm say: "rexec line 13: Unsupported option UsePAM". is this a known issue? am i doing it wrong? <jpoiret>or do you maybe not have a .guile (that's fine too :p) <spacecadet[m]>nope, but I am using the non-free linux kernel from nonguix, possibly related to that? might ask someone from that side <jpoiret>can you maybe do `LD_DEBUG=all /gnu/store/ad8351jvj61da279a3ddfs2gmk3whvdq-guile-wrapper/bin/guile`? <efraim>andreas-e: you might want to bump the guix package now that core-updates has been merged <andreas-e>I will leave this to the specialists... It is something I have never touched. <gabber>jpoiret: WDYM with "just" and "atm"? i am working on a 2-week old guix pull right now <jpoiret>gabber: starting since a couple of hours ago, master has a broken hurd <jpoiret>spacecadet[m]: I need the whole thing unfortunately. Is the paste service not good enough? you can use `2> /tmp/ld_debug` at the end to get only the LD log in a file <gabber>jpoiret: so i must have messed up regularly, then (: <jpoiret>efraim: do you want to update the guix package? I can also do it <gabber>any idea where this "UsePAM" thing comes from? i'm (trying to) strictly follow the blog post and the reference manual, using a vanilla hurd OS definition <andreas-e>jpoiret: Thanks for the biber fix, I have just pushed it. <spacecadet[m]>jpoiret: I'm trying to figure out how to copy it into the pastebin, I don't have a graphical editor so I'm not sure how to get all that into my clipboard lol <jpoiret>spacecadet[m]: xclip (on X) or wl-copy (on Wayland) might help <jpoiret>ah :( would paste.debian.net accept it? <spacecadet[m]>nope, trying to split it into multiple parts, it's almost 20000 lines <jpoiret>ah! then, LD_DEBUG=libs guix repl might be enough spacecadet[m] <jpoiret>sorry, I didn't think it'd be that long <jpoiret>spacecadet[m]: it's what i thought initially, your .guile initializes readline, right? <spacecadet[m]>it starts with (cond ((false-if-exception (resolve-interface '(ice-9 readline))) <spacecadet[m]>I've never modified .guile so I'm not sure, I'm not that much of a lisp hacker yet <florhizome[m]>I'm getting "setting synchronous mode:unable to open database file" when trying to guix gc which i want to do bc im getting errors about my filesystem being full... <spacecadet[m]>jpoiret: ah, I moved .guile and it works now, so it is something with that file <jpoiret>spacecadet[m]: yes, but you will lose readline support <jpoiret>i'm wondering how guile-readline enters the environment <jpoiret>basically, guile is trying to use the old guile-readline, whose c extension is compiled against glibc 2.33 <jpoiret>but I'm not immediately seeing where guile-readline comes into the picture <jpoiret>spacecadet[m]: where are you running the `guix repl` from? <jpoiret>not within a guix checkout or anything, right? <spacecadet[m]>hmm, if I run 'guix shell guix -- guix repl' it works, and I have readline support <jpoiret>you should not use `guix shell guix`, you're using an outdated guix then <florhizome[m]>Ok, i did a guix gc --vacuum-database, then sudo guix gced, then guix system delete-generations 1m ... Now i get an error that the substitute server is not known <spacecadet[m]>I ran a guix pull and a reconfigure, but I'm just now seeing the reconfigure failed, this might be related <rekado>(still 56 broken packages in bioconductor.scm) <spacecadet[m]>jpoiret: thanks for looking at this, looks like my system reconfigure is failing from one of my own packages, sorry for the wild goose chase <jpoiret>spacecadet[m]: right, so for readline support in guile, you need guile-readline. Your guile-readline is coming from your system configuration, and because it hasn't updated successfully, you're getting the above error <jpoiret>you could also install guile-readline and guile in your user profile <jpoiret>or just `guix shell guile guile-readline -- guix repl` <spacecadet[m]>jpoiret: thanks again! that should be everything I need to figure out what I broke <tribals>Does `guix shell` will bring all dependencies of a provided package into constructed environment? I can't understand why `guix shell clojure` does not bring icedtea to environment. icedtea is a direct dependency of clojure. <efraim>jpoiret: I'll leave updating the guix package to you. I'm working on rebasing the rust-team branch <efraim>I almost re-introduced librsvg-bootstrap <jpoiret>alright! We have some test failures which I'm investigating <lfam>tribals: `guix shell clojure` creates an environment that provides clojure <lfam>`guix shell --development clojure` creates an environment for developing clojure, including its dependencies <lfam>So, it's just a matter of adding the '--development' option to your command <tribals>lfam: thanks, I don't know why I'm thought the way it was... <tribals>lfam: but, if I'll use `guix shell -D clojure`, then, environment will not contain clojure itself <lfam>`guix shell clojure -D clojure` <lfam>The arguments are positional <tribals>I think this is because of Java nature. For example, when package which yields some executables will be used in `guix shell`, and it depends on some library, its dependencies will be available implicitly <tribals>Or this package's executables will fail without those libraries <tribals>To that end, those dependencies are "crucial" for package <tribals>I think, jvm is crucial too, for running clojure. So it is natural to expect it in shell without additional options, is not it? <tribals>On the other hand, NOT doing so allows to swap desired jvm easily. So, I think that's OK. <mirai>is there something “integrated” I could use to compare two guix package builds ? <mirai>I'd like to compare whatever's on upstream/substitutes against my patched local build <andreas-e>(for an unknown reason, it is handled as an attachment) <efraim>mirai: there's diffoscope, but that's probably not what you're looking for, unless you want something like a binary diff <mirai>I'm mostly interested in directory structure and perhaps something that indicates file has changed <mirai>don't exactly need the binary diff but a text diff could be handy <rekado>I ran into a couple of packages using the python-build-system that now fail to build. These can be fixed by switching to pyproject-build-system. <lilyp>Why haven't we made pyproject-build-system python-build-system yet? <podiki[m]>yes, many packages i fixed needed pyproject-build-system and/or version bump <spiderbit>as I already told about my nextcloud problem a few hours ago, I have generally problems with gvfs <spiderbit>I don't get how it's supposed to work... why is there no gvfs-mount command or do I have to install it differently? <spiderbit>gnome is installed so shouldn't it be there? <lilyp>the gvfs-* commands have been deprecated in favour of gio * <spiderbit>ahh the config dialog says credentials have expired <wingo>zokay people. finally upgraded recently. gnome-terminal replaced by the console; ok. but i wanted to try the old gnome-terminal to see if i prefer it. why does guix shell gnome-terminal -- gnome-terminal not work? <wingo>complains about a missing dbus service definition or something <lilyp>hmm, does it work if you add glib to the shell? <jpoiret>gnome-terminal is an abomination: it runs as a server to which clients connect <jpoiret>ie. unless you install it in your profile, it's probably not going to work (dbus needs to know it exists) <apteryx>wingo: it's powered by a dbus service or something equally crazy <rekado>wingo: same here, haven’t been able to get it to work again :-/ <wingo>maybe i can just install some gnome shell extension to hide the titlebar in fullscreen mode <atuin>mmm anyway with common-lisp + asdf experience? I'm trying to understand how to load sb-rotate-byte in stumpwm :D <andreas-e>jpoiret: Indeed this works for me under xfce4: guix package -i gnome-terminal; gnome-terminal <rekado>hey, is anyone working on fixing python-distributed or python-versioneer? <spiderbit>atuin I use also stumpwm, had problems with loading stuff, the thing is you have to have the libraries you want and sbcl installed in the same profile <atuin>spiderbit: yeah, problem here is tht sbcl is provided as an extension by sbcl itself <ngz>Nice job for core-updates! Congrats! <atuin>yeah that works if you have screenshot in asdf registry <atuin>try this: `eval (require "sb-rotate-byte")` <zamfofex>Not necessarily directly related to Guix, but while building a program I’m currently packaging, I got ‘collect2: fatal error: ld terminated with signal 9 [Killed]’ I assume this is an indication my computer ran out of RAM while linking the executable. Is that a sensible assumption? <atuin>it works in a normal sbcl repl <zamfofex>(Apologies for interrupting the conversation a bit.) <apteryx>andreas-e: big kudos for core-updates! you did a stellar job <atuin>but it works when using a normal sbcl repl :D <atuin>I guess teh stumpwm image generated by the build does not have that code or something so not sure if there is a way to add it before dumping the image <zamfofex>Yeah, congrats on the merge! 🎉 I’m looking forward to trying it out eventually. <atuin>spiderbit: I want to use the notify contrib module but it has that module as a transitive dep, did you manage to load that module? (notify) <spiderbit>atuin is sb-rotate-byte automatically insatlled <atuin>an extenstion they provide, they provide the asd file as well <atuin>but the stumpwm image can not find it <spiderbit>ahh it's not a dependency but in the package? <spiderbit>as workaround you could search the path and use it as parameter for add-to-load-path <atuin>ahh yes I can load it manually, no problem <atuin>and i can even use teh function but asdf when trying to resolve the asd for ironclad it fails saying it's not a known component <mirai>what's wrong with transfig package? <mirai>i686-linux succeeds but x86_64 doesn't <atuin>I do this in my init: `(asdf:load-system :notify)` <atuin>that requires dbus that requires ironclad and ironclad requires sb-rotate-byte :D <atuin>then asdf failes to resolve sb-rotate-byte (since it's provided by sbcl but it can not find it for some reason) <atuin>this works: `eval (load "/gnu/store/cdnrpybzys3rpbdw3bwy94343y42vpps-sbcl-2.3.2/bin/../lib/sbcl/contrib/sb-rotate-byte.fasl")` <rekado>apteryx: IT confirms that .41 has the same rules as .40; so it’s probably a disconnected cable (or a cable in the wrong switch) <spiderbit>I have most stuff in my system profile so I wtould try to put it there if it does not work <apteryx>rekado: oh, OK! Thanks for the info. Do they have people to check this, or you'll have to check yourself next time you go? <spiderbit>again would try to put it in the system profile <atuin>ok, tell me if you manage to make it work, I don't undeerstand enough how asdf works <spiderbit>I still have to run gnome on a different tty so I can use suspend because that is the only way it works :D <atuin>I have been reading how the package is build (asdf build system) and basically they generate the image using the operation asdf:program-op (which I think dumps basically the current state and provides an entry point) <apteryx>mirai: seems discard=async is now on by default for btrfs on linux 6.2 <apteryx>so the fstrim service should not be used there anymore (it's redundant) there <podiki[m]>is that a new(ish) option? i only know from before to do periodic fstrm (rather than discard option) for nvme drives, but async does the same thing essentially? <mirai>but async discard and periodic discard are different <mirai>as in, you choose when to do so <mirai>depending on the workload or $CONDITIONS, async might not be ideal so my guess is that the service still has some value <mirai>but with this new default we don't need to add it to %base-services then <apteryx>yes, it does, if someone knew what they were doing and set discard=off or something then configure the fstrim service <apteryx>rekado: currently on node 129 the eno2 interface is connected to 141.80.181.41/24 network <podiki[m]>fstrim can take a while for me and i found that the system does not like to try to suspend when it is happening (for btrfs at least) <mirai>so for non-btrfs systems it's still needed <mirai>> The -o discard and fstrim are independent and can be used at the same time. <jpoiret>yehochanan: the appimage probably doesn't contain all required dependencies <mirai>no need to “filter out btrfs systems”, we can leave the fstrim service as is <podiki[m]>ACTION tries to build a boat load of python after updating the pyproject build system packages... <jpoiret>does my email address on the MLs always appear with "via Guix-Patches"? <lilyp>Might be some MUA thing – I personally can't remember ever causing this with Evolution <podiki[m]>i've been wondering the same, not sure why or why not it appears, likewise for git author emails when someone pushes a patch for someone else <podiki[m]>hooray I don't think I have python cycles....now we wait for a whole lot to build <mirai>jpoiret: those mails look different if you inspect the headers <mirai>in them you see Exim complaining about ACL or something <mirai>it looks like it's from the GNU side? <jpoiret>ah, my dkim seems to be failing, at least that's what the mail headers indicate <jpoiret>I wonder if my DKIM is actually set up properly (it should be) <florhizome[m]><lilyp> "Might be some MUA thing – I..." <- btw i think it would be very beneficial to document a workflow with GUI tools instead of just emacs <wingo>tfw your guix says that 5,117.3 MB will be downloaded <podiki[m]>PurpleSym: I seem to have updated to python-pyproject-hooks and python-pypa-build...or at least no cycles so far as I build; one difference sit that pep517 had python-wheel as a propagated-input which at least pyproject-hooks doesn't require. not sure if easier to keep it avoid needing to add that input for some packages. thoughts? <jpoiret>florhizome[m], lilyp: i use emacs-notmuch <jpoiret>as an example, apteryx's mails also fail the dkim check even though they come from gmail <gabber>also, i'm not 100% sure whether i like the "improvements" guix style did to the comments on the inputs. should i omit those? <mirai>but it looks like it broke recently <mirai>jpoiret: I have no dkim nor dmarc <mirai>I use git send-email to send the patches and thunderbird to reply <mirai>and it doesn't manifest on me <lilyp>pro tip, don't use evolution to send patches, use esm :) <mirai>I think the ACL message thing is present in all of the problematic mails <gabber>mirai: isn't "sizeof ((size_t))" too many parens around size_t? shouldn't that be "sizeof (size_t)"? might be some issue where the pre-processor cancels out some other expression? but i'm spit-balling here <florhizome[m]>mirai i always heard bad things about tb s plain text and patches handling <mirai>gabber: perhaps but the package hasn't been changed in years <lilyp>sizeof ((size_t)) should be the same as sizeof (size_t) <gabber>mirai: this may be, but probably some inputs have changed (i just fixed a package that built just fine a month ago) <gabber>there's a good bunch of warnings and errors in that log.. <gabber>didn't core updates get merged only a couple of hours ago? <mirai>I'd expect that i686 be most susceptible to problems <gabber>sooo, the problems that used to be in core-updates are now in master :) <gabber>i perfect opportunity to fix it ;) <gabber>i guess it's (mostly) about missing header files, but i haven't looked into it too carefully <gabber>"did you forget to '#include <string.h>'"? and a bunch of "conflicting types" point towards that assumption <florhizome[m]><florhizome[m]> "libwebsockets is not building" <- python-pikepdf, tok <jpoiret>just sent a mail to mailman@gnu.org, we'll see what they think <lilyp>missing headers in configure scripts sound like not the kind of error you'd like to debug <mirai>strange is that it doesn't look like there have been any changes to these packages? <jpoiret>noticably, glibc and gcc were both updated <jpoiret>maybe that package needs a good old autoreconf -fiv .? <mirai>I'll set a new worktree for this <lilyp>did glib really get downgraded through core-updates? sheesh <lilyp>looks like gnome-team got lots of work to do after rust-team finishes <jpoiret>lilyp: some of the merges between staging master and core-updates were ... flaky <mirai>ah wait, nvm, this package doesn't use ./configure <lilyp>I don't mind too much – that way, at least glib is stable unlike what it was before <lilyp>thing is, we want 2.76 soonish, gotta go fast on the gnome release cycle :) <lilyp>anyway /me → bed, I have lots of time to worry about this in the days to come <florhizome[m]>And when gtksourceview upgrade is there i could contribute tuba (tootle followup) <mirai>what do you do when the file-system with /gnu/store is not large enough? <mirai>but I'd like to use guix-daemon to offload some rather numerous and large builds to it <mirai>it = the remote pc with 128G storage on / <apteryx>mirai: I'm trying to fix my mpd service finally; currently trying without specifying a user (default to mpd) <mirai>florhizome[m]: I'm looking to expand it <apteryx>it says "exception: No database"; do you have a way to debug this? <mirai>or options to have /gnu/store read or start storing to some other file-system <mirai>apteryx: did you configure a path to a database? <apteryx>yep; (music-directory "/data/maxim/Musique") <mirai>the database file is different <apteryx>is it not something I can leave it to manage itself? <mirai>huh, I've noticed that there's db-file and database fields, I wonder if this can be “merged” <mirai>apteryx: did you set either db-file or database? <mirai>afaik that message you're seeing is either a red herring or you configured one of those fields yet the database doesn't exist yet <apteryx>mirai: I haven't (it used to work without it) <apteryx>the thing that is new is that i'm trying to run this as its own user (mpd), the default config <apteryx>no, it just prints "exception: No database" in /var/log/mpd/log <apteryx>my client is connected correctly to it <mirai>if github search worked better <mirai>that message is expected for a ”first run” <apteryx>ah. it'd be cool to have an activation phase that takes care of that <mirai>(incidentally, I probably should add a shepherd action for that) <mirai>no, the database is supposed to be updated “manually” at your discretion <mirai>or... there's an option for mpd to update on directory changes <mirai>I don't recommend the auto update though, it seems to write database updates on a per file basis <apteryx>I would have expected mpd to take care of rescanning with inotify or something <mirai>the auto-update uses inotify iirc <mirai>but say it finds 100 new files <mirai>then it writes the database file 100 times <podiki[m]>ACTION continues building hundreds (thousand?) python packages...so far so good <mirai>anecdotal but I think I was seeing that behavior either with the file manager (the file was flashing quickly) or through htop <apteryx>we don't seem to have an option making the auto rescanning feature easy <mirai>well... you could use a cronjob to achieve a better effect? <mirai>but yes, we could add that option <mirai>I'll have a look at it after my mini world rebuild finishes <apteryx>I just added auto-update; I'll try it <apteryx>I guess it won't do anything without running 'mpc update' first <mirai>idk how seasoned you are with 'mpd' but it has some unintuitive or corner cases that are hard to reason about <mirai>depends on how much you stretch its features :) <apteryx>how would I run 'mpc update' as the user mpd? <apteryx>sudo -E -u mpd 'mpc update' ? where will this create the db? <mirai>:))) as a workaround you can do 'mpc update' with the one-liner guix shell syntax <mirai>I'll add a shepherd command to do this <mirai>mpc will connect using network (be it an IP addr or a unix socket) <mirai>connect to the daemon that is <apteryx>ah. so it'll determine this magically <rekado>efraim: what’s the plan for the rust-team branch? <apteryx>what happened on master? lots of rebuilds :-) <apteryx>mirai: i've added an update action as well... building scipy for some reason so I can't test yet <apteryx>ah! I had a change to some python package <mirai>are you implementing the action with mpc ? 