IRC channel logs

<civodul>i can't home-reconfigure on master: i get a texlive-font-maps.drv build failure

<civodul>anyone seen that?

<rekado>seen it a couple of times in the past

<rekado>can you show me the build log?

<rekado>depends on the texlive packages you use

<civodul>looks like this: https://paste.debian.net/1278249/

<civodul>it was fine last week (9a5e1dc1f16f5f8c056e64f2077b035784003673)

<civodul>perhaps a problem with the 'staging' merge?

<mvnx>I've been in a legacy boot environment in QEMU so far. Now I'm trying to use grub-efi-bootloader. The only Guix-specific part of my question is during a manual install `guix system init /mnt/etc/config.scm /mnt` should my grub-efi-bootloader configuration target be /boot/efi or /mnt/boot/efi because my Grub is failing to install though it could possibly be my partitioning stuff as well.

<rekado>civodul: hmm, I don’t know. I’ll look into it tomorrow.

<rekado>ACTION fixed linphone-desktop on c-u, again

<rekado>blender is broken on c-u

<civodul>this is Sisyphean

<civodul>i made some progress towards python-jupyter but we're not there yet

<rekado>I’m slowing working through the long list of broken builds in my profile

<rekado>it’s a drag

<user_oreloznog_>good night guix!

<rekado>civodul: I’m trying to reproduce the texlive font maps error by reconfiguring home from current master

<rekado>bleh, python-yubikey-manager is now broken on master…

<rekado>civodul: I can’t reproduce this.

<rekado>civodul: this is good. Could you share your list of texlive packages, please?

<spacecadet[m]>I've got a kind of odd situation, I have two channels and need to reference a module from one in the other. Both are in my channels.scm, and when I use the repl the modules work fine, but when I run guix pull I get "no code for module", do I need to modify %default-channels somehow or am I missing something?

<civodul>rekado: there are none, that's the weird thing

<civodul>i'm not supposed to get that profile hook

<lfam>Does anyone know off-hand how I can expand the swap partition created by the Guix installer?

<lfam>ACTION works on blender on c-u

<lfam>almost ready to push

<lfam>Just need to build it without hitting OOM

<bjc>why am i building mes again after the latest master merge into c-u?

<bjc>guix weather says there are no substitutes. does ‘weather’ work with ‘pre-inst-env’?

<lfam>Yes

<lfam>Your build environment has to be set up correctly though. You might need to be inside of `guix shell -D guix`

<bjc>i am

<bjc>i'm running: guix shell --pure -D guix -- ./pre-inst-env guix weather mesboot

<bjc>s/mesboot/mes/

<lfam>It's working for me

<civodul>rekado: got it: i have Guile as an extra channel, and my Home pulls in "guile" (by spec), which somehow pulls in texlive things

<civodul>i can reconfigure by removing Guile from my channels

<lfam>bjc: Does it output anything at all?

<bjc>lfam: how old is your c-u?

<lfam>About 30 minutes old

<bjc>hrm

<bjc>i'm also getting a 502 from bordeaux

<lfam>Have you built the checkout yet?

<lfam>Yes, same re: bordeaux

<lfam>But 1 of 1 for ci.guix.gnu.org

<bjc>yeah, i did a bootstrap → build a little bit ago, after pulling c-u

<bjc>my output from weather: http://ix.io/4u7p

<lfam>What is the derivation of mes for you?

<lfam>./pre-inst-env guix build --no-grafts mes -d -> /gnu/store/mijbv1vbk5wjhrdhzim3wk1xkxzcf7xc-mes-0.24.2.drv

<bjc>/gnu/store/5iy5368lnjd0nlqs93jfxz6friwjzksq-mes-0.24.2.drv

<bjc>i think i might need to gc

<lfam>I don't think that would have an effect

<lfam>What commit of core-updates are you on?

<bjc>though, mes of all things should reproduce

<bjc>v1.3.0-36654-g6c7a506446

<bjc>oh, hold on, that has some of my patches

<lfam>Unless they affect the bootstrap, they won't change the mes derivation

<bjc>bdd48e3cb92eaa8f6ba6a6e35a8d74cc94c513b6

<bjc>lemme reset back to origin/core-updates and see if that changes things

<lfam>Yeah, it sounds like you are in another world if mes has a different derivation

<bjc>indeed, going back to origin fixed it

<bjc>i guess changing (guix build utils) has an effect on the whole build then?

<lfam>Yup!

<bjc>is that true for everything in (guix build)? or even (guix)?

<lfam>Good question! I don't know off-hand

<bjc>hrm. i need to find somewhere to stick this timestamp change procedure

<lfam>ACTION pushes blender fix

<civodul>ACTION reported the texlive-font-maps.drv bug

<lfam>bjc: Does it reset timestamps in the build environment?

<bjc>yes

<lfam>Maybe we'll have some kind of "build changes" feature branch

<bjc>there are at least two packages that won't build at all without fixing the issue, which knock on into som virtualization packages. i think virsh and lxd

<lfam>In the meantime, I guess the change could be done specifically to those packages

<bjc>yeah, it's just code duplication, and i assume there are going to be more packages, they just haven't been found yet

<podiki[m]>yes weather should work with pre-inst-env, just checks servers directly for derivations

<podiki[m]>civodul: what python packages have you needed to fix/update? i better put my python patches to guix-patches so work doesn't get repeated

<podiki[m]>python-ecdsa might be a transient test failure on core-updates as it built locally :(

<podiki[m]>rekado: I think yubikey-manager being broken was from staging originally, the python-crytography update

<podiki[m]>let me clean up these patches...I think I'll have to guess on the order, some might break more intermediately because of the dependency structure

<podiki[m]>but will be one set anyway

<lfam>I notice that eyed3 is broken on core-updates, with the typical chain of broken dependencies and absurd version constraints throughout the dependency graph

<lfam>That's Python

<podiki[m]>well there I can see that python-grako doesn't exist (the repo we look at) and eyed3 dropped dependency

<podiki[m]>as grako doesn't build

<lfam>Yes

<lfam>Currently I have it building without grako, magic, or pathlib

<lfam>Another common thing with Python is that packages grow to declare a bunch of dependencies they don't use

<lfam>Building libmediainfo: "In execvp of ./autogen.sh: Exec format error"

<podiki[m]>yes

<podiki[m]>and our importer/linter seems to not be too accurate on suggestions on adding/dropping dependencies it seems (often most are native-inputs for tests too)

<podiki[m]>well that's mysterious...what does that mean?

<chipb>missing interpreter in sandbox?

<lfam>Dunno!

<lfam>ACTION tries --keep-failed

<chipb>the shebang line also has limits. they were raised in the linux kernel...recent-ish?

<lfam>Oh, they were raised?

<lfam>Do you know to what?

<lfam>Huh, the shebang of this script is '#libtoolize'

<lfam>Is that a valid shebang?

<lfam>Or, maybe it's just a comment

<chipb>no bang?

<lfam>No

<chipb>it'd be a comment in that case, and it'd fall back to default /bin/sh iirc.

<lfam>Works okay when I run it with /bin/sh

<chipb>but does /bin/sh exist in the build environment?

<lfam>I just did that as a test. There is a shell available

<chipb>wrt the raising the shebang limit, I think it's on the order of 512 bytes rather than 128 now. raised late 2020 I think? doubtful that's your problem.

<lfam>No, I don't think that's it

<lfam>We already built most of the distro. Now we are just cleaning up the scattered failures

<lfam>512 bytes should enough for anybody

<chipb>can you point me to your derivation? I'm curious.

<podiki[m]>lfam: just saw your openimageio fix as I was working on it (missed it, my fault!) is there a reason for 2.2.21.0 rather than latest 2.4.10.0?

<lfam>podiki[m]: No real reason. As I was working, I thought to myself "what's the smallest and easiest change that might work?" Like, I didn't want to have to start updating dependencies of openimageio

<lfam>But, feel free to update it again, as long as everything still works

<podiki[m]>i try for latest and then work backwards :-P

<podiki[m]>it built, I'm checking blender now

<lfam>Meet in the middle

<lfam>Cool

<podiki[m]>i saw some warnings for more inputs it could want, i'll see about that too, why not

<lfam>What do you mean by derivation? Like, the .drv file?

<lfam>chipb ^

<chipb>oh, sorry. more of a nix user and I'm dreadfully sloppy with terms. where's your package declaration?

<lfam>It's this package, chipb: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/video.scm?h=core-updates&id=5fda088fb17f0f5ad5cbb47314bada5f25afdb68#n4157

<lfam>The autogen.sh file in question is in that directory "Project/GNU/Library"

<lfam>This is on the core-updates Git branch

<lfam>The package does build on the master branch

<lfam>It seems to be working when I add a #!/bin/sh shebang

<lfam>Weird, I wonder what changed that made this fail. Some part of Autotools I suppose

<lfam>I wonder if it's a common problem or only for this package

<lfam>Same story for the associated 'mediainfo' package

<podiki[m]>weird

<lfam>Yeah

<lfam>Also looking at rapid-photo-downloader / python-tenacity now, since it is a dependent of libmediainfo

<lfam>"E AttributeError: module 'collections' has no attribute 'MutableMapping'"

<podiki[m]>lfam: well blender built, but it took a bit of time, so I don't know if I'll bother further updating openimageio with more inputs to then test blender again...

<lfam>That's fair podiki[m]. It will happen eventually

<lfam>The blender dependency graph is not fragile, but it's not robust either

<podiki[m]>yeah, the update was trivial though, just changing the git commit format

<podiki[m]>and blender itself needs an update, so we'll leave that for future work

<lfam>Agreed

<podiki[m]>it was just more fun to watch it compile than format these 20 python patches

<lfam>I recently got a Fast computer, so I don't get the pleasure of watching anymore

<lfam>But it's for the best

<podiki[m]>well this is still pretty fast but i guess blender is pretty big

<podiki[m]>can always be faster...

<lfam>I ran out of memory on my fast computer. I'm cheap

<lfam>Building Blender with all cores, that is

<podiki[m]>hahah

<lfam>I had to reduce the core count

<lfam>I guess I'll upgrade the memory later

<podiki[m]>all the computing power in the world won't help if you run out of memory...

<lfam>I need to increase the swap partition on it, I guess. I have to figure out how to do that

<lfam>It came with some NVME storage that I'm not using, would be nice to use it as /tmp

<lfam>tmp and swap

<bjc>can you just jerry-rig a temporary solution with swapon?

<lfam>Good point

<podiki[m]>i was suprised too that some things will devour memory and then fail in weird ways (like any browser build wants a ton of memory)

<lfam>I guess I would swapoff the existing swap partition and swapon the NVME?

<bjc>what's ‘a ton of memory?’ i've got 64gib in my build box and haven't noticed problems yet

<lfam>I actually tried to make /tmp a tmpfs but the Guix System wouldn't boot

<bjc>lfam: makes sense if the existing swap is slow

<lfam>I haven't diagnosed that

<lfam>The existing swap is mostly small (only 4 GB) rather than slow

<bjc>dang. i had been planning to do just that at some point. weird that it doesn't work

<lfam>I mean, that's normally more than enough. But I don't like to run out of memory anyways

<bjc>you can have more than one swap device

<lfam>Oh nice

<lfam>And it just works?

<bjc>should

<lfam>That's good to know, thanks

<podiki[m]>64g is definitely more than I meant :)

<lfam>With 12 cores and 16 GB of RAM, I hit OOM building Blender

<lfam>Had to use 6 cores

<lfam>16 GB RAM and 4 GB swap

<bjc>64g with 16 coresx2 threads has been pretty comfy

<bjc>surprised you have so many cores with so little ram. have you repurposed a gaming rig ;)

<lfam>I bought a second hand "ThinkCentre" that came with 8GB, and I threw in another 8GB. The second 8GB was only like $15 so I'll wait a bit before spending more money it

<lfam>I'm not sure what the target audience is for this machine

<lfam>It's miles faster than any computer I've ever had

<lfam>LLMs have created a plethora of junk web sites for literally any error message you might come across

<lfam>Sad

<podiki[m]>anyone familiar with python testing and keyboardinterrupt? I would think that is when manually halting something (say a test in a loop) so maybe we can't do this test in a build

<podiki[m]>but not sure

<podiki[m]>i'm just gonna disable it with a comment

<bjc>i swear i started noticing a huge amount of junk web sites, written in that college undergraduate paper style, many months before chatgpt showed up

<AwesomeAdam54321>bjc: I think GPT-3 already existed before ChatGPT

<bjc>it wasn't so much with programming topics, but things like ‘x vs y’ comparisons, a lot of gardening stuff

<bjc>hmm. mighta been gpt-3, i'd need to see a timeline. at this point it's been at least a year since i noticed the deluge

<podiki[m]>bah, fudged my last commit

<bjc>lfam: was it you who said i should use ‘git format-patch --stdout’ for a patch series?

<bjc>how am i supposed to attach this to a ticket? it looks like an mbox file, but i don't see a mime-type for that, and ‘application/octet-stream’ isn't rendering well anywhere

<podiki[m]>lfam: my previous commit didn't format the invoke string properly (I included the same test twice instead of combining the string); what's the right commit message now, gnu: python-ecdsa: Fix faulty commit. with a message describing the formatting change in the 'check' phase?

<podiki[m]>(pushing, figure better to fix quickly, i'll receive my demerits later and any other fixes)

<lfam>bjc: Yes, it's the --stdout option, if you want to use it. You can attach it in any way you want. When downloaded, `git am` will apply it

<lfam>podiki[m]: I think it's nice to include a message saying which commit it is a followup to

<podiki[m]>alas, I pushed, modeled after a similar commit I saw. it was the very next one though

<lfam>There have been AI text generators for a while, it's been happening for a few years now. But the last year has been terrible

<podiki[m]>(i'm worried that package has nondeterministic tests sometimes, but every time I see a failure and rebuild it works. just did 10 rounds without issue)

<bjc>lfam: i was more curious in the right way to do this that'll make life easient for someone reviewing the patch. something that'll render properly in mumi would be good, for instance

<lfam>Fair

<lfam>There must be a way to download the series as a single file

<bjc>it has a link to download the attachement, but it doesn't render inline

<jackhill>have other seen the warnings about the deprecated texlive packages on `guix pull --branch=core-updates`? I wonder if that is worth fixing.

<bjc>also, i'm not sure this'll kick off a ci job. but i also have no idea how that magic happens

<bjc>i'll just resubmit it as a series of emails

<lfam>Yes jackhill

<lfam>It's definitely worth fixing

<jackhill>lfam: I guess I should have said before or after merge :)

<jackhill>should I submit an issue? It seemed like a generic problem, but I was testing on aarch64, so I have many problems there others don't have

<apteryx>how is the default goal of our Makefile.am file defined?

<apteryx>probably magically via the primary variables

<morte_>Hi everyone, I've been trying to setup wayland with gdm, but I just don't know if I'm doing it correctly

<morte_> http://paste.debian.net/plain/1278263

<morte_>This is the configuration I'm trying to use

<apteryx>neat; git auto-reconfigure on 'make'

<apteryx>always have your Guix git hook/config up to date!

<morte_>But I'm getting this message "duplicate field initializer"

<mirai>morte_: you ain't using modify-services right

<the_tubular>Kernel release day!

<the_tubular>Ohh I lied :(

<zacchae[m]>How long does it take for mailing list (help-guix) archives to update?

<zacchae[m]>Trying to figure out why I don't see my email from 2 hr ago there

<lfam>It should be arriving soon zacchae[m]. The server needed a kick

<zacchae[m]>Alright, I sent my first draft guide detailing an optimal setup up guix home on the Librem 5 which you can find on the guix-help mailing list: https://lists.gnu.org/archive/html/help-guix/2023-04/msg00141.html

<the_tubular>Does it also run guix the distro ?

<zacchae[m]>It doesn't really detail anything about your home environment itself, but rather helps you set up your phone, i.e. anything that has to do with the PureOS install

<zacchae[m]>the_tubular: Guix-SD is not yet supported on the Librem 5

<ChocolettePalett>From the mailing list:

<ChocolettePalett>> Are you using latest or release? Release is quite old now, and bugs have been fixed in latest.

<ChocolettePalett>Should one use latest or release GNU/Guix system installation image?

<AwesomeAdam54321>Chocolette: You should use the latest

<AwesomeAdam54321>s/Chocolette/ChocolettePalett

<ChocolettePalett>Ah, this must've been the reason for my installation attempt failing

<unmatched-paren>hello guix :)

<user_oreloznog>hello unmatched-paren!

<bumble[m]>unmatched-paren hello!

<mekeor[m]>hello unmatched-paren!

<jpoiret>1.4 should be very stable as an install image, unlike 1.3 which had a bunch of bugs in it

<jpoiret>I haven't seen any patches to it since then (I think)

<jpoiret>zacchae[m]: it's now called guix system!

<jpoiret>jackhill: any problems that we could look at in general?

<jpoiret>i'm going to test the installer and the default configuration on core-updates today

<abrenon>hi guix !

<AwesomeAdam54321>hi

<andreas-e>Hello!

<atka>helllllooo

<jpoiret>hello everyone

<jpoiret>andreas-e: do you run gnome?

<andreas-e>No, xfce4.

<andreas-e>Which pulls in gdm.

<jpoiret>ah, I thought you did. I'm wondering if anyone tried gnome on core-updates. I'm going to try

<andreas-e>Is there a problem?

<jpoiret>andreas-e: which pulls in gnome-shell 🤡 so you might already most of gnome already

<andreas-e>I just verified it built.

<jpoiret>i will try running it, or rather, the base configuration of the installer

<andreas-e>rekado: Your fix for linphone makes us end up with two openldap packages with the same version, but which are not the same. This is confusing (it made me remove one of them when I updated the other one to the same version). Should it not have a different version, and preferably a smaller one, similarly to what we do with non-released git checkouts? Or if the version number becomes larger because it is a commit after the release, hide the package?

<rekado>andreas-e: we can hide the package

<rekado>that openldap package is a fork, but it’s only for use with liblinphone

<AwesomeAdam54321>I don't think the openldap variant should be hidden

<rekado>it adds types and macros that are not contained in the official openldap package

<andreas-e>Okay, then maybe add a comment that it is a fork also. Would you like to do it, or should I?

<rekado>I can add a comment

<rekado>AwesomeAdam54321: why not?

<andreas-e>AwesomeAdam54321: Why not? It is not supposed to end up in a profile.

<andreas-e>And now, I think, if you install openldap you may end up randomly (or at least non-predictably) with one or the other.

<AwesomeAdam54321>andreas-e: I didn't realise they could conflict, I thought liblinphone's ldap would have a different name

<andreas-e>jpoiret: The gnome thing was when I realised I needed java, which civodul changed with his font building patch.

<jpoiret>andreas-e: are you still running into the "gcry_md_hash_buffer: Function not implemented" error?

<jpoiret>i just got it

<andreas-e>No, after "guix pull"-ing everywhere it disappeared.

<jpoiret>but i did guix pull everywhere :/

<andreas-e>I had attributed it to the system guix and the profile guix not being the same and maybe mixing guile libraries.

<andreas-e>And reboot? (Not that it should matter.) Or maybe "hash guix"?

<jpoiret>i've already rebooted when i switched everything

<rekado>andreas-e: done

<andreas-e>rekado: Thanks! Sorry for causing this additional work.

<andreas-e>jpoiret: This is all very strange. I think I have seen it on my other machine after updating only the user profile. civodul should have an explanation.

<rekado>andreas-e: no, thanks for bringing it up!

<jpoiret>andreas-e: I'm investigating it right now

<jpoiret>andreas-e: deleting the `guile` executable in the source tree and rebuilding it with make made the error go away

<andreas-e>Hm. Why is there a guile executable?

<jpoiret>we modify it so that it doesn't complain about locales (for some reason)

<jpoiret>it's quite small

<andreas-e>This is the line in the Makefile:

<andreas-e>guile$(EXEEXT): $(guile_OBJECTS) $(guile_DEPENDENCIES) $(EXTRA_guile_DEPENDENCIES)

<andreas-e>It looks okay.

<andreas-e>I am just discovering "guix pull --branch=...". I thought it would also be "guix pull --commit=core-updates". Does the latter also work?

<andreas-e>I get other problems with "make" in my git checkout of guix:

<andreas-e> MAKEINFO doc/guix.ru.info

<andreas-e>guix.ru.texi:3499: @node `??????????????????????' previously defined

<andreas-e>guix.ru.texi:2452: here is the previous definition as @node

<andreas-e>This is with guix on debian

<andreas-e>But it also happens inside "guix -C -D guix".

<jpoiret>andreas-e: I know the origin of the error! Basically, our guile is compiled with the older glibc, so the newer gcrypt library can't load because it relies on glibc >= 2.34, but glibc 2.33 is already loaded

<jpoiret>i don't really know how autotools cope with updated dependencies

<andreas-e>I see. Now I remember that I deleted my guix checkout and created a new one before the gcrypt thing worked. (Which caused other problems, because I lost my git hook of signing all commits.)

<andreas-e>But "make distclean" also remove the guile binary.

<efraim>in that case I normally run 'git clean -dfx'

<andreas-e>That looks dangerous! I do have a complete untracked subdirectory with a TODO list and other stuff.

<efraim>I generally keep that outside of the repo and symlink it in

<efraim>I have a .exrc for vim stuff that lives in my home directory for each of the git worktrees

<attila_lendvai>oh no! rottlog is written in .sh?! then i'll not look further into fixing https://issues.guix.gnu.org/56780 (rottlog flattens the dir structure when rotating)

<efraim>quick! rewrite it in guile!

<andreas-e>CI is building some aarch64 packages from April 6... There are still 1000 missing. If we are lucky, they have not changed since then.

<andreas-e>And 1400 from April 15.

<andreas-e>And 3700 from April 21.

<efraim>andreas-e: some might need to be restarted. some of my aarch64 rust-team packages got garbage collected before being built

<andreas-e>These are only the scheduled ones... I already did a round of restarting.

<efraim>ah, ok

<andreas-e>But there may still be packages to restart.

<andreas-e>So on this architecture we are not ready for more building through feature branches.

<rekado>we should buy a few more servers

<andreas-e>It is not "cost effective" when comparing the time needed for administration compared to their computing power.

<rekado>I can ask if we can host more at the MDC data centre

<rekado>maintenance time is high because we have no way of controlling them remotely

<andreas-e>Central hosting of reliable machines could make it easier (at the expense of you putting in work, I suppose).

<jpoiret>i'm working on the python-pyside-2 build failure currently

<andreas-e>Are there more powerful aarch64 machines?

<jpoiret>(so that we don't duplicate effort)

<efraim>I know of the thunderx boards, which are now several years old, and are probably as good as anything

<efraim>I seem to remember them being expensive though

<jpoiret>andreas-e, rekado: would that delay the c-u merge?

<efraim>a mac mini is always an option I guess

<jpoiret>i can imagine aarch users don't really want to build everything on their own

<andreas-e>efraim: It all depends on how expensive... So far we humanpower has been more precious for the project than money.

<andreas-e>jpoiret: $ ./pre-inst-env guix refresh -l python-pyside-2

<andreas-e>Building the following 5 packages would ensure 6 dependent packages are rebuilt: hydrus-network@495 mygnuhealth@1.0.5 freecad@0.20.2 rfcat@1.9.6 onionshare@2.6

<andreas-e>Or are there hidden dependencies?

<efraim>lets say they're still on the order of $10000, IIRC they come well stocked with like 36 cores

<jpoiret>it's for freecad, which someone mentioned on the MLs

<andreas-e>The Overdrive have 4 cores. The Honeycomb have 16 cores for $1000.

<jpoiret>i was looking for bugs to fix

<andreas-e>jpoiret: Since there are so few dependencies, we can add it to core-updates at the last minute, or just push to master after the merge.

<rekado>solidrun finally offers honeycomb 1U servners: https://shop.solid-run.com/product/SRLX216S00D00GE064H09CE/

<andreas-e>32 cores for $3000. Sounds reasonable.

<andreas-e>Ah, without RAM...

<jpoiret>andreas-e: right, but it should be easy to fix, so one more bug squashed i guess

<efraim>andreas-e: https://www.gigabyte.com/Enterprise/ARM-Server?fid=2326 these look nice, but "call sales"

<efraim>I'm seeing SDcard only for the honeycomb servers :/

<andreas-e>With up to 128 cores of ARM 8.2 architecture, whatever this means.

<andreas-e>Anyway, I think we need the specialists to discuss about what to do. And if rekado thinks that MDC can host them, that would definitely be helpful.

<cbaines>efraim, the Honeycomb's behind bordeaux use M.2 NVMe drives for storage

<cbaines>but I do see the same bit on the specification tab...

<efraim>I wouldn't be against PXE booting them, but someone would need to set that up and make sure it didn't break ...

<rekado>or we could add a bunch of AWS nodes

<cbaines>Hetzner also do ARM VM's now

<jpoiret>anyone know how our python works? I'm seeing different behavior between python and python-minimal that I can't explain

<jpoiret>`import importlib; importlib.machinery` works on the former but not the latter

<andreas-e>Something completely different: Is it normal that "guix pull" builds meson, swig, graphviz, docbook, ghostscript, texlive packages and what not?

<andreas-e>This means that a simple "guix pull" on my aarch64 machine will take hours, and maybe fail. A case for lfam chasing useless inputs!

<andreas-e>Oh, I forgot nss. So maybe days rather than hours...

<jpoiret>yes, it is unfortunately part of the dependency tree

<andreas-e>cairo, harfbuzz, gobject-introspection; half of gnome for "guix pull" ?!

<jpoiret>half of gnome? now this is something i wouldn't expect

<andreas-e>Sorry, I am just exaggerating a bit. Or what else is cairo, harfbuzz, pango, gobject-introspection?

<andreas-e>"Cairo is a 2D graphics library". Definitely not something I need for a CLI "guix pull".

<cbaines>I think docs is the reason for some of this stuff

<andreas-e>Is there already a bug report? Otherwise I will file one.

<andreas-e>Done. Soon "guix pull" will depend on rust, I suppose.

<jpoiret>wdym soon? i bet it already does

<andreas-e>I did not see rust among the packages to build, but it may indeed be available as a substitute and already have been downloaded.

<jpoiret>ah, I may have been a bit hasty, it doesn't yet

<jpoiret>I thought inkscape would get pulled in somehow, as is usually the case with docs

<andreas-e>inkscape is another one of these dependency nightmares.

<andreas-e>If it depends on rust, this is worse.

<jpoiret>inkscape depends on librsvg

<jpoiret>librsvg is the gateway to hell it seems

<clemens3>indeed, worst piece of software ever

<ngz>andreas-e: texlive pull probably comes from po4a, which is used as guix input.

<clemens3>i am on linux from scratch and i use the some old version without the need for rust

<clemens3>of librsvg

<jpoiret>clemens3: that's also what we do for architectures which don't have rust

<ngz>I'd like to push <https://issues.guix.gnu.org/62670>, but I'd like to understand its relative lint warning first: "#:tests? must not be explicitly set to #t". Do you have an idea of what I did wrong?

<ngz>I lean towards a false alarm

<jpoiret>well, #:tests? is by default #t is what it's telling you I guess

<jpoiret>so you don't have to specify it

<jpoiret>I would also agree that if I see this I would immediately wonder what's wrong with the tests

<ngz>Ah

<andreas-e>jpoiret: So python-shiboken-2 is not ready to be pushed because of the obscure differences between python(-minimal), or did I misunderstand?

<jpoiret>no, python-shiboken-2 can be pushed i think, it's another failure of python-pyside-2

<ngz>jpoiret: I understand. I was misleaded by the "must not" and the fact that I mostly commit Emacs stuff, where tests are disabled by default. Thanks.

<clemens3>jpoiret: yeah, i wonder if the never ones are really necessary.. other projects should just boycott librsvg

<jpoiret>clemens3: it's hard to boycott a well-written library though. of course projects are going to depend on it

<andreas-e>ngz: There are so many texlive packages, it cannot only be po4a. Probably they are needed for the documentation of all kinds of other packages. After all, I countered over a hundred dependencies!

<clemens3>jpoiret: yeah, it is in the control of each project.. but in the end each user can also decide which project to use.. so better the projects make good choices first

<andreas-e>"counted", but indeed I think they should be countered! Freudian lapsus.

<clemens3>jpoiret: I think i needed librsvg for gimp.. as a user, i just stay with an old gimp..

<clemens3>if necessary

<andreas-e>jpoiret: I think you should get commit rights to ease our work ;-)

<jpoiret>yes, i think so too

<bjc>which package provides ‘ldd’?

<jpoiret>bjc: glibc

<jpoiret>you can also use "LD_DEBUG=all" to look at what ld's doing

<andreas-e>bjc: or gcc-toolchain

<jpoiret>that's what I often do, it's more informative

<bjc>i just want to see where some shared libraries are coming in from. i saw your mail about ‘pre-inst-env’ this morning, and it doesn't explain things for me

<bjc>i did go through the step of manually deleting guile in my checkout, but nothing changed after re-building

<jpoiret>are you still experiencing the gcry error?

<bjc>the only thing weird i've noticed so far is that the guile git modules are being loaded from a different place under ‘pre-inst-env’ that doesn't get used otherwise

<jpoiret>the simple test I used is `./pre-inst-env guile` then `,use (gcrypt hash)` and `(file-hash (hash-algorithm sha256) "somefile")`

<bjc>i get all kinds of errors depending on what gets called first

<bjc>it this point, i should not have any reference to the older glibc on my system, but somehow one seems to persist

<bjc>s/^it/at/

<bjc>so hopefully ldd will give me some guidance on where these broken symbols are coming from

<jpoiret>can you confirm with the above test that it is the guile binary that causes this problem?

<bjc>In procedure gcry_md_open: Function not implemented

<jpoiret>did you `autoreconf -fiv .` then `./configure --...` anew before regenerating `guile`?

<bjc>yeah, i did a full rebuild starting from ‘./bootstrap’

<ordoflammae[m]><_jdb> "I am running Guix system in a..." <- I tried doing the same kind of thing, but I think the only real way to do this properly is to insert it into the fstab service manually, rather than go through the default `device` property.

<jpoiret>and you're using `guix shell -D guix` with the newer `guix` I presume? Sorry I'm asking these basic questions but just to make sure

<jpoiret>did you find out which glibc guile was linked against?

<bjc>yeah, i'm using system guix for ‘shell’

<bjc>no, i don't think i'll be able to dig into this until later in the day. i'm just doing some minor poking right now

<ordoflammae[m]>(define services

<ordoflammae[m]> (modify-services %ordoflammae-services

<ordoflammae[m]> (fstab-service-type fstab => (cons* libvirt-shared fstab))

<_jdb>I guess I'm wondering if it makes sense to try and `stat` the 9p device given that it isn't actually represented by a file on the file system. Separately, I also wonder if `stat`ing relative paths makes sense at all because it introduces impurities based upon the directory you run `guix system reconfigure` in.

<_jdb>I'm pretty sure not every type of mount results in a `stat`, so I would propose adding `(type "9p")` to those exceptions.

<ordoflammae[m]>Yeah, but you'd have to add a new type. It's just an edge case that hasn't really been considered yet.

<ordoflammae[m]>A new type to the device list.

<ordoflammae[m]>It would definitely be useful to add a new type of file system that bypasses that check, or has a different check, but I'm not entirely sure where that check is handled. I found it a while back, but it's been a while since I figured that particular difficulty out.

<ordoflammae[m]>I think the stat happens whatever the type of the device is, though.

<ordoflammae[m]>Although I was specifically using the virtiofs type.

<graywolf>Hello :) I need to execute some shell code (well, one command) on system shutdown, *after* network is down; Would someone have a example how to achieve that? I'm not really sure, especially that part of doing something only on shutdown and after network is already down...

<bjc>graywolf: i don't think there is any way to do that right now

<_jdb>Yeah, I think a file system type that bypasses the check makes sense

<graywolf>bjc: Not happy to hear that but thanks anyway :/ Currently my system just hangs on every shutdown. It's not a deal breaker, but definitelly annoying.

<bjc>are you using nfs or some other networked file system?

<graywolf>No, shepherd is just waiting for kernel thread(process?) to stop (and it never does). The command I need to run is "modprobe -r mt7921e" to stop the `[mt76-tx phy0]' "process".

<graywolf>(it's driver for wifi, that is why I was asking for "after network is down" :/)

<bjc>i see. yeah, i don't think you'll be able to order that explicitly. afaik, the only hook for terminating things is ‘user-processes-service-type’, but that doesn't have an explicit ordering

<bjc>there are similar issues with network file system mounts, which is why i asked

<bjc>you may be able to hack around it, depending on how desperate you are. if you attach something that forks to ‘user-processes-service-type’, which can watch the network status, and then remove the kernel module

<graywolf>I see, interesting idea. Will try to give that a try.

<graywolf>I guess I'm not too desperate, since the "hold the power button" method for shutting the system down works, but for some reason it triggers me a bit

<graywolf>So I'll try and see

<bjc>same here. it's something that i would love to see fixed, but i think that's a lot of work with not enough hands. shepherd currently has no way of even encoding something like shutdown ordering

<graywolf>I somewhat assumed it would reverse of the boot up order

<bjc>imho ‘user-processes-service-type’ is a hack. or at least the way it's currently being used is

<bjc>in the simple case of shutting down a system, reversing the startup graph may work, i'm not sure. in general, though, you can't encode service dependencies with a single graph

<bjc>there's a reason that even the ancient sysv-init had start and stop scripts with their own independent ordering

<graywolf>I see

<graywolf>thx for explanation

<ordoflammae[m]>_jdb: Anyway, while you are waiting for that to be implemented in guix, my code snippet should help work around the check without breaking anything.

<efraim>I suppose you could have a service which depends on networking with something like #~(lambda #t) for the start script and your shell script (with a small sleep) for the stop script

<efraim>oh, this is what I get for having joins/parts/quits hidden

<efraim>sneek: later tell graywolf For your 'modprobe -r mt7921e' on shutdown I suppose you could have a service which depends on networking with something like #~(lambda #t) for the start script and your shell script (with a small sleep) for the stop script

<sneek>Got it.

<efraim>sneek: botsnack

<sneek>:)

<andreas-e>rekado: Among the packages that fail all the time on core-updates, I see propeller-*; I have no idea what it is, except that it is a cross-compiler. So I wondered whether your gexp miracles could work there also, although I do not see anything fishy in the (hidden) propeller-gcc package.

<andreas-e> https://ci.guix.gnu.org/build/1149611/log/raw

<civodul>apteryx: hi! just noticed 286cdf0bc55a29d5a63f7191edde7ea4dbd8cf2a: did we formally decide to drop desktop support on i686-linux?

<apteryx>civodul: hello! no decision, just observation and reaction to it ;-)

<jpoiret>is rust being unsupported on i686 a guix problem or a rust problem? or both?

<apteryx>mrustc

<apteryx>so guix problem

<andreas-e>I see that disabling the test hides the problem. What options have we got for solving it? Would a bug with a stop-gap measure of doing a binary bootstrap be an option?

<civodul>until now we were arranging to have GTK+ & co. without Rust on i686 (as with the recent Samba fix)

<bjc>was there a graft for glibc 2.33 that bumped it to 2.34 at some point?

<bjc>i'm just started looking back into this pre-inst-env problem, and when i try (dynamic-link %libgit2) i get this: In procedure dlopen: file "/gnu/store/kmqzzvwm4a85jbrs4sb6h2frpxwgsr49-libgit2-1.3.2/lib/libgit2.so", message "/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6: version `GLIBC_2.34' not found (required by /gnu/store/kmqzzvwm4a85jbrs4sb6h2frpxwgsr49-libgit2-1.3.2/lib/libgit2.so)"

<bjc>that says that the glibc2.33 library is looking for GLIBC_2.34? why on earth would that be the case?

<jpoiret>bjc: no, rather libgit2 requires the GLIBC_2.34-specific features, which are also available in GLIBC_2.35

<bjc>but it's trying to load everything from a glibc2.33 store path

<bjc>interestingly enough, if i ldd that libgit2.so, it shows that it's linked against 2.35

<jpoiret>yes, that's because glibc-2.33 is loaded before by the main executable

<jpoiret>you can only load one glibc, so if glibc 2.33 is already loaded it won't try to load 2.35

<bjc>what main executable? guile?

<jpoiret>yes

<bjc>!

<bjc>my guile *is* linked with 2.33

<bjc>now why would that be?

<bjc>the guile in the guix directory, not the one used by the system, that is

<bjc>is there a flag i can give ‘make’ that'll have it spit out the shell commands it runs?

<apteryx>civodul: system-config-printer depends on python-cryptography through urllib3

<jpoiret>if you are in the right gux shell environment, and you rm guile, autoreconf -fiv . then ./configure and make it should link it properly

<bjc>i'll admit that i may be screwing up the build process, but if so, i'm doing so consistently

<bjc>can you post your exact steps somewhere?

<jpoiret>they're as above really, `rm pre-inst-env guile`, `guix shell -D guix, `autoreconf -fiv .`, `./configure --localstatedir=/var`, `make`

<jpoiret>that should do it i think

<jpoiret>that's what i did to get rid of it

<andreas-e>Ah, so you also remove pre-inst-env? I thought it was part of the git checkout.

<bjc>hmm. i've never removed pre-inst-env

<andreas-e>Me neither!

<jpoiret>it's created my the makefile

<jpoiret>although looking at it there's nothing special in there :)

<bjc>eh, it didn't help anyway

<bjc>somehow gcc is picking up an old glibc, but i don't see anything in the build flags to it that would do that

<apteryx>civodul: gnome-boxes also, bust just for building the docs of qemu-minimal

<apteryx>font-abattis-cantarell needs it to build too...

<apteryx>most dependencies on it appear to be via sphinx (build time)

<apteryx>some run time dependencies are via urllib3, e.g. tracker-miners.

<apteryx>it's not insurmountable but I'd rather we invest the effort on getting rust to build on i686... not much was missing

<andreas-e>jpoiret: Well, it contains absolute directories, so it makes sense to recreate it. But I do not quite see why one should have to remove it.

<PurpleSym>apteryx: I’m gonna downgrade python-trio to 0.21 and python-pytest-trio to 0.7 to get python-anyio working again.

<bjc>andreas-e: it didn't make any difference to remove it

<andreas-e>But now I understand why renaming the directory poses problems... (I do so now from time to time to try out a "git merge" and then just remove it.)

<jpoiret>civodul: we're missing librt.a in glibc:out by the way, it might break some builds

<jpoiret>zig is an example, only figured this out afterwards

<andreas-e>jpoiret: I still did not get why you want it there. If it is needed, why not just add glibc:static to the (native-)inputs?

<jpoiret>because we're breaking backwards compatibility

<jpoiret>you used to be able to link against librt with glibc:out, not anymore

<bjc>is core-updates on gcc 10?

<bjc>i thought it got bumped to 11

<efraim>PurpleSym: please do

<bjc>i ask because ‘guix shell --pure which -D guix -- which gcc’ points to /gnu/store/z8qv19hrxndrkl3x4yy4wsy8lyld6sfy-profile/bin/gcc, which is a symlink to gcc-10.3.0

<jpoiret>bjc: core-updates's default is gcc 11

<jpoiret>what's your guix describe?

<bjc>and i'm wondering if that gcc is pulling in the wrong libc

<bjc>i can't run "guix describe" with pre-inst-env, because libgit2 fails to load

<jpoiret>no, but your outside guix

<jpoiret>since you're using `guix shell` from the outside guix

<bjc>8d347815c742283de30f43cd26363f372dc506af

<bjc>it's relatively recent. in the last few days atleast

<jpoiret>`guix shell -D guix -- gcc -v` gives me gcc 11

<bjc>uh. no, it's not, it's from 14-apr

<bjc>yeah, mine's saying 10.3.0

<bjc>i am *positive* i've done a system reconfigure in at least the last week

<bjc>i'll try again

<jpoiret>ah, but you need to guix pull

<jpoiret>the guix package in guix hasn't been updated, so you really need to be using a guix pull'd guix, and from core-updates

<bjc>my HEAD is on 827df9d1dde4f4a06e1789ec17cf0586602aa121, which is a day old

<jpoiret>ie `guix pull --branch=core-updates`

<bjc>oh!

<jpoiret>otherwise you'll be using dependencies from master instead

<bjc>i have not run that step. or, rather, i did a while ago, everything broke, and i had to rollback my system

<andreas-e>I did a "guix pull" for root to reconfigure the system and the root profile, and then for (each) user to reconfigure the user profile. I am a bit wary of a mixed system and user profile, although this should theoretically work.

<attila_lendvai>changing the network config in NetworkManager asks for my unix user's password. is there a way to avoid that? all i find is some polkit magic that looks like something the nm service should add, not me, the user.

<jpoiret>attila_lendvai: what login manager are you using?

<andreas-e>Maybe it runs "sudo" behind the scenes?

<attila_lendvai>jpoiret, gdm. it's a pretty standard guix gnome install.

<jpoiret>attila_lendvai: all parts of the configuration, or only some?

<jpoiret>and are you using nm-applet, or nmtui, or others?

<attila_lendvai>jpoiret, my gdb-configuration has two extras: (wayland? #true) and (default-user "alendvai"). i think i'm using nm-applet (the gnome thingy in the upper right corner)

<attila_lendvai>*gdm-configuration

<jpoiret>what part of the configuration are you trying to modify? just add a network?

<jpoiret>i recall that the polkit policies for nm are pretty granular

<attila_lendvai>jpoiret, yep, adding a network.

<attila_lendvai>i also have some changes for the network-manager-configuration: (vpn-plugins (list network-manager-openvpn)) and (dns "dnsmasq")

<jpoiret>hmm, would love to reproduce but i'm getting errors regarding some missing schema

<jpoiret>you can snoop on dbus with dbus-monitor --system, maybe that could give you a hint

<bjc>after pulling ‘gcc -v’ says 11.3.0!

<bjc>thank you. i think this might finally be fixed

<apteryx>PurpleSym: OK! I hope it doesn't break others... (I think it did when I tried that)

<mirai>afternoon guix

<attila_lendvai>jpoiret, two dbus-monitor hints: "System policy prevents modification of network settings for all users", "org.freedesktop.NetworkManager.settings.modify.system"

<PurpleSym>apteryx: Running the builds right now. Do you remember what broke?

<jpoiret>☠️ the C.UTF-8 locale name doesn't follow the specification for locale names

<attila_lendvai>jpoiret, do you think that 1) this is something only on my install, or 2) is this how it supposed to work out of the box?

<attila_lendvai>BTW, my user is in the wheel group

<jpoiret>attila_lendvai: because it's gnome i've got no idea. you should be able to look at the polkit policies directly, they should be in the /run/current-system/ folder iirc

<jpoiret>do you have polkit-wheel-service?

<rekado>andreas-e: I’ll take care of the propeller packages

<rekado>(this is a free hardware design multi-core microcontroller)

<mirai>attila_lendvai: I think fedora has this feature “right”

<attila_lendvai>jpoiret, great hint! it has a gnome-control-center.rules that allows stuff for wheel, but it doesn't have anything for NetworkManager. i'll grep the guix sources now...

<mirai>if it happens that our package/service is missing something we could inspect what they're doing

<attila_lendvai>jpoiret, i don't have the word "polkit" in my config.scm. the desktop-services-for-system lists it, so i'm pretty sure i have it.

<apteryx>PurpleSym: no, it's already been paged out, sorry :-)

<mirai>can someone confirm that loginctl manpage in c-u displays correctly?

<mirai>apteryx: regarding #62710, I don't see where we're using the snapshot version?

<apteryx>it's on core-updates

<apteryx>./pre-inst-env guix edit docbook-xsl on that branch

<mirai>it's 1.79.2 ?

<andreas-e>rekado: Nice, thank you!

<mirai>ohh, I see the base-revision is just informative

<mirai>we're using the latest commit from that repo

<vhallac>Hello

<bjc>jpoiret: pre-inst-env works again. thank you so much! that was driving me batty

<jpoiret>attila_lendvai: ah, probably. Sorry, something urgent came up and I probably won't be able to help

<bjc>and now i definitely need to figure out what magic goes on in ‘guix pull’ =)

<attila_lendvai>jpoiret, mirai: `find `guix build network-manager` | grep polkit` doesn't have any .rules files, while `gnome-control-center` has one. the fedora project sets some polkit -D's at compile time: https://src.fedoraproject.org/rpms/NetworkManager/blob/rawhide/f/NetworkManager.spec

<apteryx>any idea why the latest Cuirass image cannot be downloaded? it throws a 503

<vhallac>I have a question. I have a bunch of scripts in my ~/bin directory. I used to manage them via my dotfiles repository in my old distro.

<vhallac>Now, I am moving to guix / guix home. How should I treat these guys? Make a package? Just copy them in?

<vhallac>Keep a dotfiles style bits and pieces? Any suggestions?

<janneke>so...something changed on the build server; shell scripts without hash bang do not execute anymore

<civodul>apteryx: i vaguely remember seeing this reported earlier but i can't find it

<janneke>In execvp of ./test/all/parse_import_order/run: Exec format error

<janneke>any idea when/where/why this change was made?

<civodul>janneke: hey! on which build server?

<janneke>civodul: log file: https://ci.guix.gnu.org/build/1149620/log/raw

<janneke>ACTION looks...

<janneke>this job: https://ci.guix.gnu.org/eval/426023

<podiki[m]>hi guix

<lfam>janneke: I saw this last night oo

<lfam>Too

<lfam>It's not just the build server. It happens on my computer too

<janneke>lfam: ah, "good"

<janneke>kernel update? I'm still at 6.2.8-gnu

<lfam>For example: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=a0b2b4f1e95b876cbf5a3b8ca25f901504fc1acf

<lfam>Dunno, I'm also on 6.2

<janneke>weird!

<lfam>Yeah

<apteryx>civodul: perhaps the recent message to help-guix

<apteryx>i've now forwarded it to guix-sysadmin

<janneke>the scripts in question are executabsle, but lack a hash-bang (not intentionally, but hey ;)

<lfam>apteryx: I couldn't find a list of mailing list moderators

<lfam>Yeah, it's definitely a regression janneke. Something changed on core-updates

<janneke>ah, some machines got switched to core-updates, nice!

<civodul>lfam: the derivation above /gnu/store/qknwr9y7297va17c0qbplj3bwy1kh21y-dezyne-2.17.2.drv is on glibc 2.33 (master)

<civodul>ACTION tries to build it locally

<lfam>I mean, the package was built on the core-updates branch. But I don't think the underlying system is based on core-updates

<janneke>hmm, my package is on master

<lfam>Ah, now that's interesting

<mvnx>From discussions here and mailing list IIRC only LUKS2 pbkdf2 works for encrypted root on Guix but with /boot unencrypted? That's fine enough. I see a few example system.scm's that supposedly work but none outline their disk partitioning. Can someone please point me to a working config and the `parted` commands that are required for it to work? I must have tried every permutation other than the one that works.

<bjc>nice, i only have one open bug left on core-updates and my whole system+home works 👍

<lfam>mvnx: If you don't get an answer here, try sending mail to <help-guix@gnu.org>

<mvnx>Thanks :)

<lfam>But, you might get an answer here if you keep waiting

<civodul>janneke: i have the "Exec format" error for that derivation on my laptop as well

<civodul>does it pass on yours?

<civodul>the only thing that can leak off the top of my head is binfmt support (i'm using the qemu-binfmt service)

<rekado>salmon fails to build on core-updates (and thus pigx)

<lfam>I'm not using the qemu-binfmt service and I can reproduce the failure

<civodul>rekado: ok but fish builds

<lfam>:)

<lfam>Therefore, salmon should be okay

<civodul>exactly

<rekado>¯\_(ツ)_/¯

<janneke>civodul: yes, it passes here

<rekado>curiously, scallop builds fine

<janneke>civodul: wait, i did not do a full, local build

<janneke>a guix build, in a container, that is; our build server is older

<janneke>(April 19 b82a18c8a33482249c634de1e91be18ac10a3c76)

<janneke>civodul: does this work for you?

<janneke>$ echo -e '# no shebang\necho yay!' > script

<janneke>17:22:30 janneke@drakenpad:~

<janneke>$ chmod 755 script

<janneke>17:22:35 janneke@drakenpad:~

<janneke>$ ./script

<janneke>yay!

<janneke>hmm my laptop is at april 18, no use to double check; that works

<civodul>janneke: works for me

<civodul>even that works: guix shell -C coreutils -- /bin/sh -c 'rm /bin/sh; ./script'

<janneke>civodul: interesting!

<jpoiret>mvnx: yes, you need /boot unencrypted if you want LUKS2

<jpoiret>unless you use grub2 HEAD

<jpoiret>some configs might be using grub2 patches to make it work

<jpoiret>bjc: do you need some help with that open bug?

<jpoiret>civodul: should we add C.UTF-8 as a locale choice in the graphical installer? I would argue against

<bjc>jpoiret: if you want to look at it, it's #63044

<bjc>it could use a more experienced hand, i'm sure. this was the best i could do with what i know, though

<bjc>there was a small discussion on the ml about it. since it's too late to fix python-setuptools, we're stuck patching individual packages as they're found

<jpoiret>you're probably not going to like it, but the #:tests? #f comment suggests that the tests should probably be looked at in fact

<jpoiret>also you shouldn't use (guix utils) from the build side i think

<bjc>d'oh! sorry, i forgot about the disabled tests. i'll see if i can figure out what's up with that. it happened in a recent master merge

<mirai>how can I check what builds are broken in c-u

<jpoiret>what do you need (guix utils) for bjc?

<mirai>the ci.guix interface feels very MMN

<jpoiret>mirai: you can use https://qa.guix.gnu.org/branch/core-updates

<bjc>as for (guix utils), i couldn't find a better place for that procedure. unfortunately, (guix build utils) is very deep in the dependency tree, and changes the derivation of mes, at least

<lfam>You might put it in the Python build system

<jpoiret>right, but pulling in (guix utils) is not an option either

<bjc>i wanted a place to put ‘change-file-timestamps-recursively’, that's all, and it seemed the best

<jpoiret>lfam: it's also going to cause rebuilds of all python packages, no?

<lfam>Yes, but that's less impactful

<jpoiret>i think we have python pretty deep down in the dep tree, no?

<lfam>I mean, how many packages are affected by this bug?

<lfam>And how many dependents do they have (roughly?)

<bjc>sssd and criu use ‘gnu-build-system’

<lfam>Like, are we talking about a major issue, or a minor issue

<janneke>civodul: it fails on my laptop too; our build server builds are pinned at a much older channel

<bjc>it impacts libvirt, so not super minor

<lfam>Oh, I thought it was a python thing, bjc

<bjc>it *is* a python thing, but they don't use python's build system

<lfam>libvirt only has a few dependents, right? That's minor

<lfam>We need to figure out what the impact of the bug is, and what the impact of fixing it will be

<lfam>If it's a few hundred package, that's minor. Major starts at several thousand. In between is medium

<bjc>it'll affect anything that uses python eggs, which i'm not sure about. eggs have been deprecated, but there are probably more than the two packages

<janneke>civodul: at about a year old,..that's going to be quite a bisect

<lfam>bjc: I was able to update my systems without hitting the bug, and I have a lot of packages installed. So I wonder how widespread it really is

<lfam>jpoiret: Do you have any ideas where to put this procedure?

<bjc>i've updated everything, too, and only run into those two

<jpoiret>lfam: except in a new file, no

<lfam>Yeah

<lfam>If it's just a few scattered packages, I suggest copy and paste

<jpoiret>it's a minor bug, so my opinion would be to just duplicate the code and put it right in their phases

<podiki[m]>if it is a big python change we can group it with the patchset i'm (still) working on

<bjc>i figured a new file would be a problem. my initial take was code duplication

<podiki[m]>it already touches ~3k+ rebuilds

<civodul>janneke: i wouldn't do a bisect because it's not clear what to bisect

<jpoiret>we do need a way to transition to a more principled approach down the line

<lfam>Nobody loves duplicated code but there are trade-offs

<jpoiret>otherwise we end up with endless ;; XXX

<civodul>janneke: instead, i'd "strace -f -p $(pidof guix-daemon)" on both the servers where it passes and a machine where it fails

<bjc>podiki[m]: is that going to be merged soonish? the change to setuptools is a one-liner

<janneke>civodul: yeah, i was just pondering on that

<lfam>Well, that's why we have to pay attention and clean up jpoiret

<jpoiret>maybe it would be a nice project, just taking care of all those XXX

<lfam>In the future, we should deal with changes to core python stuff on a python-updates branch

<jpoiret>would probably constitute a world rebuild, but I don't think it's too much in an issue

<lfam>It will be a better workflow

<lfam>It will let Python people focus on Python, rather than having to become experts in everything

<mvnx>jpoiret: I'm okay with /boot unencrpted but I've tried different permutations of, in addition to / via mapped /dev/mapper/root, either separate /boot, separate /boot/efi (this one makes sense not to work if all of /boot needs to be unencrypted), separate /boot and /boot/efi, and even tried /boot and /efi per Arch docs, and variations of setting esp/boot flags on the partition so I was hoping to find more specific `parted` commands.

<podiki[m]>bjc: the plan is a separate feature branch just following core-updates merge

<podiki[m]>I'll get the patchset submitted soon, just been trying to clean it up and have hit other things to fix along the way

<civodul>jpoiret: i agree: adding C.UTF-8 to the installer makes little sense; C.UTF-8 should make sense though everytime we added en_US.utf8 and glibc-utf8-locales

<podiki[m]>it is not really core changes, just happens to hit updates of things that have many dependents, all to fix yubikey-manager

<ekaitz>is anyone having an issue with icecat saying you are in GMT? It's converting all my hours to -2 as I'm in CEST

<podiki[m]>we could throw in more changes, like updateing pytest (rebuilds a lot of python then)

<jpoiret>civodul: wdym by that second part?

<bjc>i think i'd rather just do the fix in setuptools, then

<jpoiret>you mean all the places where we arbitrarily use en_US.utf8?

<civodul>jpoiret: right

<jpoiret>yes, i agree

<civodul>for the sole purpose of allowing Guile to decode file names as UTF-8

<civodul>(or things like that)

<jpoiret>the installer currently crashes because of C.UTF-8 being in the supported locales. I'm working on it atm, but it's still quite hard to test

<lfam>podiki[m]: Have you ever done a big pytest upgrade before?

<podiki[m]>lfam: nope! i just tried and it builds fine locally (just a minor version bump), but yeah, everything that uses more recent testing will need to be rebuilt then

<lfam>Yeah, we always have a few versions of pytest packaged, because it's really fragile and different applications require different versions

<lfam>Just FYI

<podiki[m]>well i'm not going to touch it yet, turns out I didn't need to update it (was getting an unsupported option error from another package, turns out it needed another input)

<podiki[m]>this "just fix python-yubikey-manager" has turned into quite an adventure

<podiki[m]>a consequence of us being rather behind on some key packages, and the state of python packaging in the larger (non-guix) world in general I guess

<lfam>The Python dependency graph is always very brittle and tangled

<lfam>It's not as bad as some languages, but it's pretty bad

<podiki[m]>I think it is also a lot of older packages or ones that don't get updated much (upstream) and get stuck on older versions

<podiki[m]>and that python is so popular it touches so much

<jpoiret>don't want to pile up problems, but could anyone look at https://yhetil.org/guix/87o7ndvbu5.fsf@jpoiret.xyz/ ?

<jpoiret>it's python-related as well so that's why i'm mentioning it

<podiki[m]>anyway, will try to keep this patchset relatively lean as we want to merge it quickly after core-updates, which will depend on unintended breakages...

<jpoiret>i don't think it matters too much, don't know how much freecad is used

<lfam>It's nice to keep freecad working IMO

<lfam>It's one of those things that people might choose a distro for

<lfam>Not quite a "flagship" application... yet

<podiki[m]>jpoiret: on a quick look I dont' know, we have backports of importlib pieces, but I don't see machinery in the name

<jpoiret>what's worrying is that it's different between python and python-minimal

<podiki[m]>so that might be a clue

<podiki[m]>I don't know the difference but I'm guessing a bunch of modules stripped out? which then have separate packages. i'm guessing

<lfam>I'm working on a major upgrade of Transmission, and they changed their build system so our patch about locales, which allows "GTK-specific localization", no longer applies. Does anyone know how I can test these features? Use a locale besides en_us at the system level and see if Transmission is appropriately translated?

<bjc>i use freecad =(

<jpoiret>lfam: wouldn't LC_ALL="whateverlocale" be enough?

<bjc>honestly, though, freecad's rough on guix just due to lack of graphics drivers, so it's pretty slow

<bjc>if i need to model anything that isn't dead simple i need to use another distro

<lfam>jpoiret, Do you know any other locales? As an american, I ignore all this stuff

<jpoiret>fr_FR.UTF-8 😳

<lfam>Thanks

<jpoiret>(the emoji is *not* part of the locale name)

<lfam>I figured ;)

<podiki[m]>emoji locale when

<lfam>Heh

<podiki[m]>that mumi update looks very handy! just in time for this ~20 patch series as soon as I finish it

<jpoiret>yes, I was about to use it for one of mine as well

<bjc>oh man, the mumi update looks great

<podiki[m]>our tooling has seen some nice improvements this past year or so

<jpoiret>Will the installer be able to get me a full GNOME install? find out soon

<mvnx>Presently with my setup after GRUB boot I get "you need to load the kernel first". I have separate /efi (fat32) and /boot (unencrypted ext4). It also already prompted me for my / LUKS password before GRUB.

<andreas-e>Indeed, mumi looks nice, I am eager for the next bug with patches ;-)

<jpoiret>mvnx: what's your grub configuration?

<andreas-e>bjc, podiki[m]: Maybe you could have a look at my one line change to python setuptools. It does not appear in the bug; I think I sent it to guix-devel.

<podiki[m]>python-pyflakes is failing now...didn't we have some fix/workaround before?

<andreas-e>It just tells the zip module (or whatever it is) to not worry about files in the past.

<jpoiret>for some reason the install image doesn't have the acl enabled by default... but they *are* in /etc/guix/acl

<andreas-e>podiki[m]: The last time pyflake occures in "git log" was June 2022.

<podiki[m]>andreas-e: hrm. vaguely remember something about it maybe from staging, but perhaps it was through another package. it has ~450 dependents. let me check if it really is failing now

<andreas-e>So probably not. By name it is allowed to be flaky...

<bjc>andreas-e: i haven't tried it yet, but that was exactly what i was going to start with

<bjc>it'll be at least an hour before i can get to it, though

<andreas-e>Well, there is no urgency! The bug wait for us until after the core-updates merge.

<andreas-e>ekaitz: I am not sure whether this is an icecat "issue", it has been like this forever. It is supposed to be an anti-fingerprinting measure. There is some setting you can change on one of these hidden pages (such as "about:"), but I have forgotten what it was.

<andreas-e>Maybe civodul remembers how to set the correct timezone in icecat.

<ekaitz>andreas-e: I have resistfingerprinting set to false :)

<ekaitz>i knew it was related somehow but I don't know why having it to false fails to report the proper date

<podiki[m]>nevermind on python-pyflakes, it builds (just not on e.g. aarch64)

<mvnx>jpoiret: This was the generated grub.cfg. https://paste.debian.net/plainh/67cf100e

<mvnx>I'm surprised there was no gfxterm in there - at one point I had a config booting into "blind mode".

<jpoiret>gfxterm is only available after root has been decrypted unfortunately

<jpoiret>grub support files like artwork are not copied to /boot, so need to be looked up in the store that is on the root partition

<apteryx> https://guix-install.sh/ certificate expired?

<mvnx>OK I'm not sure what I need. I don't care about graphics I just wanted to boot and didn't really understand the error message.

<mvnx>I'm not sure if where I'm at is a step further or behind

<jpoiret>mvnx: i meant the part of your config.scm

<mvnx>Oh, sure

<jpoiret>it's more digestible than the grub.cfg

<mvnx>jpoiret: My parted commands and relevant system.scm portion https://paste.debian.net/plainh/8123dc5e

<mvnx>The above paste has that "you need to load the kernel first". IIRC with just separate /boot marked with boot flag (and no separate /efi or /boot/efi) got me the "no suitable video mode" blind mode error. Not sure which is closer.

<apteryx>rekado: I managed to pxe-boot node 129; re-installing

<ekaitz>civodul: if you guide me a little bit on how to organize the code I can send a patch to the quotation issue we found

<zacchae[m]>jpoiret: Oh no! I'll fix it in later versions :)

<jpoiret>mvnx: first time i'm hearing about this error message

<jpoiret>mvnx: did you input the password properly?

<jpoiret>the GRUB LUKS password prompt is in qwerty

<mvnx>I did - only use English US standard qwerty setup. I can remove the heredoc key file and manually enter password when partitioning to confirm

<mvnx>Otherwise it would have just said incorrect password, right?

<jpoiret>not exactly. It would still show you the menu

<jpoiret>if it's a blue background for me I know it didn't unlock the LUKS partition

<apteryx>ekaitz: you need to disable resistFingerprinting

<ekaitz>apteryx: it is disabled long time ago

<apteryx>and also currently set TZ

<ekaitz>andreas-e: and I checked it

<apteryx>there's an open bug about that, it's on mozilla's side

<ekaitz>apteryx: and how do you set the timezone?

<apteryx>see #59368

<apteryx>export TZ=America/Montreal

<ekaitz>oh than you!

<apteryx>yw

<lfam>Transmission changed from the glib-or-gtk build system to cmake. But we still need to wrap the 'gui' output, which is fine. However, I can't figure out how to use '#:glib-or-gtk-wrap-excluded-outputs' in cmake-build-system

<lfam>Are there any other keys that we sometimes "cherry pick" from one build system to another? I could use those a reference

<rekado>apteryx: oh, good! Do you know why it didn’t work before? (Did you do anything differently or has apparently something changed on the PXE server?)

<jpoiret>pretty weird that we don't include --sysconfdir=/etc in our sample ./configure invocation. It's more correct to also add it

<jpoiret>just got bitten by this + the fact that (current-guix) and hence the installer inherits those configuration options

<apteryx>rekado: it always fails on the 1st try, reboots, then succeeds

<apteryx>so the only way is to change it in BIOS Setup so that it sticks, rather than go through the web page

<apteryx>I've documented that now

<mirai>is it possible to input commands in a sequence for a tool that uses an interactive interface? (like fdisk)

<mirai>programmatically

<apteryx>use guile-parted :-)

<mirai>oh, fdisk is an example

<apteryx>I think in the guix code base there is a hack invoking some tex related utility at some places

<mirai>the tool I'd like to script is xmlcatalog

<apteryx>which is interactive

<apteryx>jpoiret: yes, we should add it!

<bjc>yeah, i needed that flag for ‘guix offload’ to work correctly, and was very confused for a long while why it didn't

<bjc>honestly, i wonder if we should just default configure's flags to use /var and /etc. does anyone ever build it any other way, except by accident?

<mirai>apteryx: my grep fu isn't revealing much

<apteryx>rekado: ugh, the activation scripts do not run on 'guix system init'?

<apteryx>now I'm stuck in GRUB without access to the SAN

<apteryx>(and without the copied kernel modules)

<apteryx>ACTION grumbles

<apteryx>ACTION prepares to chroot

<lfam>I sent my Transmission patch with the tricky interaction between 2 build systems: <https://issues.guix.gnu.org/63056>

<lfam>Help wanted!

<lfam>ACTION going AFK, but I'll take my answer off the air

<unmatched-paren>afternoon, guix! :)

<unmatched-paren>rekado: git.elephly.net doesn't seem to be responding to web browsers or ``git clone''

<mvnx>jpoiret: When I removed the heredoc for password key file and instead typed it manually, and otherwise the same config and partitioning, my error switched from "missing kernel" to "error: no suitable video mode found Booting in blind mode"

<apteryx>rekado: seems to be booting... taking ages to symlink the kernel file to under /boot

<apteryx>fileS

<apteryx>"hydra-guix-129 login:" phew!

<apteryx>rekado: can't access it from 141.80.181.41 though; did something change?

<apteryx>accessing it from berlin works

<andreas-e>I just announced that I intend to do the core-updates merge tomorrow, as suggested. Does anyone think this poses a problem? I do not know how to seek a consensus...

<apteryx>I'll try it with my profiles shortly, but at any rate, I'm fine with it

<efraim>lfam: how about (apply (assoc-ref glib-or-gtk:%standard-phases 'glib-or-gtk-wrap) #:glib-or-gtk-wrap-excluded-outputs '("out"))

<efraim>lfam: librsvg uses gnu:configure after cargo:configure and adds the configure-flags directly in that phase

<apteryx>mirai: see texlive-updmap.cfg

<apteryx>in general when looking for process interactions via STDIN, you can search for open-pipe*

<apteryx>it's a very crude example though, but perhaps it is enough

<podiki[m]>andreas-e: personally works for me, for what that's worth :)

<podiki[m]>actually may be I can push a few more python patches before then, stuck on fixing poetry's tests in upgrading it, I think the patches up to this point are some additions and minor fixes, but getting poetry working would be i think useful

<podiki[m]>but we'll see if I still hit the big dependents

<efraim> I spent some time on poetry earlier, ended up hitting python-virtualenv and python-filelock but didn't try adding a new version of them

<podiki[m]>ah ok, filelock is the big one I think

<efraim> https://bpa.st/QR72G

<podiki[m]>i haven't had to update it yet, but some tests are failing so I haven't gotten to the sanity-check

<podiki[m]>efraim: yup that looks about the same here

<podiki[m]>but I was a bit sloppy before and in going through to finalize these i'm being more careful with tests etc, but not sure why i'm hitting a failure now (also updated poetry too)

<efraim>it might be easier to downgrade poetry

<podiki[m]>or rather I didn't upgrade but kept the latest version (from staging too?)

<jpoiret>andreas-e: I have some installer-related patches coming up, but they could also go on master afterwards

<jpoiret>one thing I'm worried about is substitutes availability on arches other than x86

<podiki[m]>efraim: also we weren't running tests before for poetry, so these may not be new failures

<efraim>I was trying to get past the sanity phase first before trying the tests

<efraim>I wonder if I should patch xdg-open in alacritty

<podiki[m]>haha I did that at first and now returning to the tests is also difficult :(

<podiki[m]>I think i'll just disable the 8 tests. i think one or two are trying to detect a shell (won't work in test env?) others i'm not sure if it is trying to download/write something but i haven't gotten anywyere

<podiki[m]>i'll leave it for someone to review later

<rekado>andreas-e: I just fixed a few more packages, but many more are still broken

<rekado>I’m working on scribus now

<rekado>I’ll also try to fix sicp, which is very unimportant

<rekado>fixed pigx today

<jpoiret>mumi does take some time to receive mails

<jpoiret>"Mail not acknowledged by issue tracker. Giving up." we'll get em next time

<rekado>mumi does not receive mails

<rekado>do you mean debbugs?

<rekado>or do you mean mumi’s sync of debbugs emails?

<rekado>does anyone what this means: https://elephly.net/paste/1682366997.html

<rekado>(I’m building scribus with GCC 10 and with -DWANT_CPP17=ON)

<apteryx>rekado: any clue why 141.80.181.41 is not reachable from the internet? (that's hydra-guix-129)

<rekado>apteryx: no idea. The traceroute output looks the same to me.

<apteryx>OK, thanks

<rekado>(141.80.238.253 being the last visible hop)

<rekado>if you have good reason to think that the firewall is to blame here I’ll open a ticket

<apteryx>does it work for you?

<apteryx>ssh at least works from the internal network (from berlin, say)

<apteryx>so the port is listening to the outside

<rekado>I’ll open a ticket

<apteryx>OK, thanks!

<bjc>podiki[m]: looks like python includes its own setuptools, so fixing the date issue will cause a rebuild of everything that uses python

<jpoiret>rekado: ah, right, it syncs with debbugs

<rekado>apteryx: actually… I wonder if that node is connected to the right switch

<jpoiret>so there's probably no way to lower the issue processing time

<rekado>I’ll open the ticket anyway to confirm that the rules are identical.

<andreas-e>rekado, podiki[m]: Thanks for continuing to repair packages! Since all these are close to the leaves, they can as well go to the master branch. So even if they do not make it to core-updates before the merge, you can still apply them to master afterwards. However, there might be a short time where the package is not available on master, while it used to build up to now.

<apteryx>rekado: it used to work, a few months ago (December)

<andreas-e>Feel free to push packages with very few dependents on April 24.

<andreas-e>jpoiret: I do not feel competent on installer patches. I will let other people comment. In any case, it looks like they can go to master later.

<jpoiret>andreas-e: yes! I just wanted to get them out

<andreas-e>I am a bit worried about substitutes on aarch64; we have gone from 1 to 5 build machines again very recently, and there is a certain backlog.

<bienjensu>I'm trying to compile Godot 4.0.2 but scons keeps throwing an error about linux/errorno.h being missing despite having linux-libre-headers in the build inputs.

<jpoiret>apart from it being annoying, there's probably no rush to merge c-u.

<bienjensu>s/errorno/errno

<jpoiret>most of the hard work is done, I don't think the merge *has* to happen tomorrow

<jpoiret>but again, you're the one doing the hard work so it's up to you

<andreas-e>On the other architectures, there does not seem to be a big difference; also master is not in a very good state outside x86_64.

<andreas-e>For me it is tomorrow or in a few weeks ;-) I also think that it has to happen at some point; there is a certain suspense that is going to vanish with no clear perspective.

<andreas-e>And the rust team has been very patient, I am not sure we can hold them back much longer :)

<andreas-e>After all, we have started about two months ago now! Even a bit more I think.

<jpoiret>yes, this is long overdue

<jpoiret>hmmm, I wouldn't mind inheriting the core-updates branch if the problem is being available, but getting committer access might take a bit

<andreas-e>There will be more branches to take care of in the future :)

<rekado>does the error I pasted above mean that I cannot link libQt5Core.so and libQt5Xml.so (which were built with GCC 12) with scribus which was built with GCC 10?

<jpoiret>rekado: looks like it. if a dependency requires a higher ABI, I don't think you can link against a lower ABI

<andreas-e>rekado: I would also say it looks so. See here: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

<andreas-e>Apparently this stdc++ plays a bit the role of glibc, with the same problems of mixing different versions.

<andreas-e>There have been changes between 10 and 11, and then 12 and 13.

<jpoiret>andreas-e: yes, except for the fun fact that stdc++ is included in gcc, as opposed to glibc

<jpoiret>historical artefact probably

<jpoiret>meaning that, while we have a single glibc in guix at any point in time (for now), we might have multiple libstdc++

<jpoiret>maybe it could be unbundled? I don't know how reliant gcc is on libstc++ internals

<podiki[m]>andreas-e: thanks in advance for the merge! I'm just getting these python patches in better shape but it will be for a new branch after the core-updates merge. bug number still forthcoming as I whittle down the last of the problems

<andreas-e>rekado: I do not know why you need to build scribus with gcc@10. One (complicated) option could be to compile with gcc@10 and to link with gcc@11 (I think the distribution is built with @11, but it contains @12 as a package).

<jpoiret>maybe it doesn't build with newer gcc, that would be fun

<apteryx>has someone ever had 'guix deploy' hang on 'guix deploy: sending 0 store items (0 MiB) to '141.80.167.186'...' ?

<apteryx>guix offload test is fine

<apteryx>perhaps some ssh-agent hangup?

<apteryx>that's running from a remote machine to which I'm connected using SSH

<andreas-e>On aarch64 we are hitting the cuirass bug of removed derivations; as written earlier, we are trying to build packages from almosts three weeks ago, and I suppose many of the derivations have already been garbage collected.

<andreas-e>If they are still relevant for the current evaluation, they will automatically fail as well as all their dependents.

<bjc>is there any reason to not keep derivations for successful builds for months? is disk space too tight?

<andreas-e>The builds are part of the backlog, they have never been run.

<andreas-e>Would it help to run "./pre-inst-env guix weather" on berlin to create the derivations again?

<andreas-e>In any case, I can give it a try.

<andreas-e>I have built single packages "by hand", but this cannot be done easily on a large scale.

<apteryx>bjc: yes; after the builds are done, the nars are cached to /var/cache and this is all that is needed for serving substitutes. Running a garbage collection daily avoids multi-hour garbage collection runs after a few months, keeps it constant and predictable.

<andreas-e>(If they are not relevant for the current evaluation, they will also fail, but we do not care; or rather, we are happy since they will fail quickly.)

<bjc>apteryx: ah, i see. thanks for the explanation

<rekado>andreas-e: it does not build with the default GCC

<rekado>there are a number of errors in the pdf plugins

<rekado>and this is C++ type soup, so I don’t see any obvious ways to fix them

<andreas-e>What I wonder is whether one could compile the .cpp files to .o with gcc@10 and then link with gcc@11. But I would not even know how to set this up in a Guix recipe.

<rekado>perhaps we can set LD to gcc 11

<apteryx>compiling with a recent GCC but setting the CXX standard should work, perhaps?

<apteryx>CXX standard to that used by default in GCC 10

<jpoiret>yes, that would probably do it

<apteryx>when cloning the maintenance repo no berlin works, but git fetch hangs up; anyone else sees this?

<rekado>I’m building scribus with "-DWANT_CPP17=ON" (required because of poppler)

<apteryx>is this problem known upstream?

<rekado>apteryx: they say to use the development version from SVN

<apteryx>did you try?

<apteryx>if it fixes this hurdle, and this is what they recommend to fix it, I'd use it

<andreas-e>I wonder if there is an upstream. The stable version dates from 2019. The last unstable release is from January 2022.

<rekado>I’d rather not pull in a year of half-baked, untested stuff just to bypass a compilation problem

<rekado>or rather three years

<andreas-e>Why do we have to suffer poor maintenance by the software developers?

<rekado>(the comment to use the dev version was about the poppler problem, which I’ve worked around with a Gentoo patch)

<rekado>I don’t know what you’re suggesting

<rekado>1) remove it: Scribus users suffer; 2) patch it: I suffer; 3) upgrade to some untested development version: quality suffers

<apteryx>I think 3 is the most reasonable choice, if 2 is not simple.

<apteryx>quality suffers is an upstream issue (they were not able to put out a release that builds in current distros)

<andreas-e>Not sure. 1)? Is there no maintained alternative?

<rekado>Scribus is the only “popular” free application for print authoring

<apteryx>I think using a snapshot could even help them furthering a release

<apteryx>by having users report bug on something recent, not 3 years old

<apteryx>anyway, my 2 cents

<andreas-e>Actually we are already on the development release. So only 15 months old...

<rekado>I think it’s unwise to make release decisions on behalf of other teams.

<apteryx>what is their suggestion for the current problem you are facing?

<rekado>I only stumbled upon a bug report about popple incompatibility

<rekado>poppler*

<rekado>the response was: this is fixed in SVN

<rekado>this is as far as I got

<rekado>I have no interest in packaging a non-release

<rekado>we cannot assume that something that’s not even a release candidate would be of any value to us

<apteryx>it's of more value than 1) for sure

<rekado>perhaps we’ve all spent too much time with rolling-release folks to remember releases

<rekado>not if the software doesn’t work

<rekado>I won’t be able to test it all just to notice that it’s all sorts of broken

<rekado>anyway

<andreas-e>No, I am all for releases! But if the developers cannot be bothered to make a release that works, I am in favour of removing their software, not continuing the development for them.

<rekado>I go back to trying to fix this now

<rekado>well

<andreas-e>Your choice! :)

<apteryx>you can trade 2 hours of writing patches for 2 hours of testing a snapshot build ;-)

<rekado>if that’s our baseline we might as well kick out all that Python stuff that hasn’t been updated since 2019

<apteryx>and if looks good, done, with a message to upstream, "hey, works for me. could we please have a release?"

<rekado>apteryx: no, that’s not equivalent. If I spend 2 hours testing and find a serious bug … am I supposed to just stop?

<andreas-e>Good idea... With a message to upstream: "sorry, your think does not compile any more since 2021, could we have a release?"

<rekado>this is just one of many many packages I’m trying to fix before the core-updates merge

<rekado>I don’t have the capacity to engage in upstream relations

<rekado>looks like I just ran out of time anyway

<andreas-e>Well, I cannot really speak about scribus or any other particular software. But I do think we should maybe remove software a bit more aggressively from Guix.

<rekado>I really don’t think so

<rekado>we can go back to a cozy set of 600 packages, sure

<rekado>but I won’t be using Guix then

<apteryx>is someone looking at docker-compose?

<civodul>how long before someone throws machine learning at these packaging problems?

<ieure>no

<apteryx>strange, 'guix refresh' doesn't know about 2.x series of docker-compose

<RavenJoad>Can you increase the verbosity of the output when building a channel's derivation when performing 'guix pull'? I am getting an error on my channel related to a string-append, and I do not know which file is causing the problem.

<rekado>RavenJoad: you can build the derivation with “guix build”

<jpoiret>re: asking for upstream to release, then you get https://github.com/ipxe/ipxe/discussions/679

<jpoiret>with the usual "you should use binary blobs from the internet anyways because the distros have out of date software"

<jpoiret>you made the sandwich

<RavenJoad>rekado: Ok. I am doing "guix build -v 6 /gnu/store/...-channel-name.drv" and all I get is the same wrong-type-arg exception output, with nothing more helpful

<rekado>what’s it say?

<jpoiret>RavenJoad: I don't think it's possible to get such errors

<podiki[m]>apteryx: for docker there was some split or rejoining of docker-compose into/out of docker in recent versions (don't remember the way it changed exactly)

<RavenJoad>rekado: The whole exception is: "(exception wrong-type-arg (value "string-append") (value "wrong type (expecting ~A): ~S") (value "string" #f)) (value (#f)))"

<bjc>podiki[m]: patching setuptools in python worked. i'm going to run some more packages through before i update the bug report. do you want to be cc'd on it?

<podiki[m]>bjc: this one? https://issues.guix.gnu.org/63044

<bjc>that's the one

<podiki[m]>if you want, otherwise I'll just reply there later once I have the bug number for my python patches if they should be grouped together on a branch

<bjc>i'll spare your inbox this one email, then ;)

<RavenJoad>jpoiret: Can I evaluate a local checkout of the channel with guix to somehow find out the offending file then?

<podiki[m]>thanks bjc

IRC channel logs

2023-04-24.log