<apteryx>I think the aalib problem on ppc64le has to do with the configure script or libtool: checking dynamic linker characteristics... no \n checking if libtool supports shared libraries... no \n checking whether to build shared libraries... no \n checking whether to build static libraries... yes
<mirai>but oh my… its hard to justify that price tag to just fool around with a different piece of silicon (which I don't think would translate in any improved productivity, in fact I'm inclined to think that the opposite might be likely 😅 since broken packages)
<mirai>apteryx: a very dead package from the looks of it
<makads>It seems that I can't afford it for this price :')
<dan>So guys, given the nature of Guix if I wanna build a "sway devel" linked against bleeding edge wlroots and mesa , all I have to do is create a channel on my github with modified papckages, and the system will naturally handle the proper libs, no ?
<dan>meaning I still get to use "sway" linked against tested libs and sway-devel linked against what i want
<nckx>A set of protocols that aim to replace X11, but unlike X11 there's no 'Wayland server', but things called 'compositors' like Sway that implement the protocols. They are like combination servers + window managers, roughly.
<unmatched-paren>even if it did, surely that doesn't mean it'd 'end up using it'? it's not propagated, after all.
<bumble>iyzsong: earlier I sent my patch this way `git send-email --to="email@example.com" HEAD^` do you think it would be "safer", this time, if I tried creating an issue first, then sent the patch to the issue link?
<bumble>or should I send the patch using the same git send-email to firstname.lastname@example.org?
<unmatched-paren>bumble: btw it's better to use `git send-email -1` than `git send-email ^HEAD`
<bumble>I did get a cc'd copy of the patch that was sent earlier today
<Wurt>Could someone check my patch (https://issues.guix.gnu.org/65538)? I think that I sent it wrong, it is the second version of another patch, but I did not reply to the original thread... sorry. I sent it 6 days ago. What should I do?
<iyzsong>Wurt: you can close the old one, by send a mail to email@example.com
<bumble>nckx: nevermind me all seems to be well. thank you and see you later
<xelxebar>unmatched-paren: I'm jumping in the middle of the discussion here so not exactly sure what the topic is. However, when building compilers, you generally need to think about *three* different levels: 1) the build platform, i.e. the one on which you're compiling the compiler, 2) the host platform, i.e. the machine on which the built compiler will run, and 3) the target platform, i.e. the platform for
<xelxebar>which the built compiler generates code.
<bienjensu>How would I include a different system's version of openal within a container? That is, without changing the system of the entire container.
<xelxebar>bienjensu: --with-input? guix shell also accepts pretty much all the args that guix build offers.
<bienjensu>xelxebar: I'm not sure that package specifications allow you to specify the architecture of a package. The nasty way to do it using non-guix-shell utils is something like 'guix package -i `guix build -s [system] openal`'. This errors on guix shell, however, as it doesn't accept store paths
<bienjensu>I can see why it shouldn't work like this, but it is a little frustrating not just being able to `guix shell openal.i686-linux`
<xelxebar>bienjensu: guix shell takes the --sytem argument just fine. Can't really spec that just for a single package, AFAIU, though.
<xelxebar>Could probably get some dirty guile expression to do it, though.
<bienjensu>nested guix-shell'ing doesn't even work because the root container is in FHS emulation mode and a subshell doesn't link the new libs to /lib
<gabber`>i set my PS1 env var in my home-bash-service-type's environment-variables field but it remains set to the value set in /etc/bashrc. it works (as expected) when i add a file-like to the bashrc clause. is that intended and to be expected?
<andreas-e>And this with a fraction of the build power for x86.
<andreas-e>I wonder, for instance, if we should not attach one of the powerpc machines to QA rather than CI.
<andreas-e>Looking at https://ci.guix.gnu.org/workers most of the aarch64 machines have dropped out of the build farm actually: overdrive1, dover and lieserl; kreuzberg needed repair work and might not be up again yet.
<apteryx>I don`t think the picture is as bad as it looks for Cuirass; most problems seems to have to do with it fetching substitutes from nginx <-> guix publish
<apteryx>causing spurious build "failures" and making the weather look bad
<apteryx>as for aarch64, QA has more machines, I think
<andreas-e>apteryx: 3 in QA (which also do armhf), 5 in CI (plus kreuzberg)
<andreas-e>I really think the main problem is not being able to restart builds, and them not being executed in topological order.
<andreas-e>Plus the bug about missing derivations, indeed. Three things to fix!
<apteryx>maybe we should do a cuirass bug fix spree!
<apteryx>do we have issues reported to all of these?
<cbaines>there are design things that the build coordinator does differently to Cuirass, like problems substituting derivations being tracked as setup failures rather than build failures, and the ability to build derivations more than once
<cbaines>I think we're getting there with canceling builds as well, as QA does this regularly now
<aitzkora>Hi, somebody had this kind of error trying to build a recipe : guix build: error: corrupt input while restoring archive from #<closed: file ...>
<cbaines>on connecting more powerpc64 machines to the bordeaux build farm, assuming they're always on, that would really help as then we'd be able to start QA testing with powerpc64le-linux
<andreas-e>cbaines, apteryx: From what I have heard, I am indeed more convinced by the QA design decisions. But tens of thousands of lines of Guile code are too frightening to start looking at them...
<andreas-e>There are two powerpc machines at CI, one of them could be "moved", I would say. None of them are physically in berlin.
<apteryx>aitzkora: I think these are network related crashes... already reported on the issue tracker
<andreas-e>apteryx: It would be nice to get the current core-updates branch out of the way. I have new gmp and mpfr versions in the wip-gmp branch. And right now I am trying to add the coreutils version released two days ago.
<cbaines>andreas-e, I have been slowly working on reducing the amount of code, but it's quite a slow job to push things upstream or pull bits out in to other libraries
<andreas-e>cbaines: I am mystified by how you were able to write so much code :)
<andreas-e>janneke: So do I just unconditionally add this configure flag to coreutils-mesboot? Where exactly? It is strange that the problem occurs only now while the configure flag was already added before.
<janneke>andreas-e: yes, that's strange -- could it be that the check has changed?
<andreas-e>janneke: It is possible that it was a warning and has become an error. But I am still surprised the flag would be added for a non-error.
<janneke>it wouldn't hurt to try, but yeah, it's possible that adding the flag won't help...
<RavenJoad>Ahh. Then does it make sense to change the fetch interval to something higher? I had it set to fetch sources every 3 minutes. Does that just overwhelm Cuirass with tasks? (I also get OOM messages).
<apteryx>I think the build farms use 15 minutes, that is, derivations group all the commits in that time window
<andreas-e>janneke: Could you tell me how to add it without overwriting the complete "arguments" field?
<apteryx>and IIRC it often takes 30 minutes or more for an evaluation, so if master is busy it could accumulate a backlog
<janneke>andreas-e: the release notes for 9.3 has:
<janneke>+ Coreutils programs no longer fail for timestamps past the year 2038
<janneke>+ on obsolete configurations with 32-bit signed time_t, because the
<janneke>+ build procedure now rejects these configurations.
<RavenJoad>apteryx: Since this is for a CI server for my personal projects, it does not have a huge number of jobs/builds (right now each project has just 1 build job). So 15 minutes makes sense as a fetch interval?
<apteryx>do we have a way to check if a x86-64 target supports avx2 at build time?
<RavenJoad>apteryx: Would it make sense to add that to the interval field for the cuirass-configuration documentation? The default value is just 60 seconds. Saying something like "Cuirass has to build Guix before handling the build jobs, which can take several minutes. Consider setting this to <insert-threshold> minutes?"
<andreas-e>apteryx: Yes, we should not use it as input to anything else then. And users will be confused if they install it on too old a machine.
<bumble>In the process of trying to submit a patch and have made a mess (I'm sorry). First, I sent two patches because of worry when the first patch did not appear. This morning both patches appeared and I sent a "close" email to one of them which never appeared in the issue page, in the mean time someone else closed the remaining issue that I did not close...
<mirai>hmmm… if this is within the context of GST, I guess it would be fine as a package by itself (not a part of any of the big gst-* plugin bundles)
<mirai>but the ffmpeg case is tricky since it has to be present at ffmpeg compile time
<ulfvonbelow>I'm trying to do some rather in-depth package transformations in my manifest, and finding that it's causing a lot of breakage. Namely, when I try to transform all the way down to (gnu packages commencement)-level packages, I get errors about allowed references, for example in glibc-final. It seems that package-mapping doesn't make an effort to recurse into the package arguments. Can anything be done about that?
<mirai>apteryx: I was thinking on doing something somewhat related on that matter, this is the plan I've come up with though I haven't tried it yet
<andreas-e>RavenJoad: I think it counts hard links multiple times when determining how much to free, so in reality it frees less.
<mirai>perhaps you might find some value in it? (i.e. build variants of ffmpeg and use an interposer that is responsible for calling them?)
<mirai>no idea what will happen with the libav** libraries tho
<mirai>or simply provide ffmpeg and ffmpeg-avx2, where the avx2 variant is inherited from ffmpeg with appended inputs, etc.
<andreas-e>mirai: The really elegant solution would be to write what is known as a "fat binary". It is more or less the same thing, but the function dispatching is done directly inside the C library without an additional Guile wrapper.
<janneke>andreas-e: sent a working patch now, i believe
<janneke>not tested with the actual upgrade, but the flag is now there
<andreas-e>In gmp, as far as I can tell from quickly browsing the code, it is all handmade: a table of function pointers, which are initialised depending on the architecture the code is run on. And then I think that every function call uses an additional indirection.
<andreas-e>core-updates does not really exist any more, so I do not know. I started to update gmp and mpfr, and saw that there was also a new coreutils and thought this would be a good occasion to break things.
<andreas-e>Will send you the error message. We do not *have* to update coreutils.
<janneke>ok; yeah i figure that proper locales are one of the things we least care about in the bootstrap phase...
<bumble>andreas-e: a message was sent to me from firstname.lastname@example.org essentially saying that the command was processed. but the issue is still closed when viewed from the url. Did I do something wrong or do I just need to wait a bit?
<mirai>bumble: why is that package not built from source?
<mirai>or is it? That release page lists multiple archives
<bumble>I think it builds from source using ./configure && make && make install
<dissoc>when i run guix pull it gets stuck on Computing Guix derivation for 'x86_64-linux'. any ideas how to resolve this?
<RavenJoad>andreas-e: Ahh... That might be it. I knew about htop, but I always forget I do not have it installed and tend to default to top for quick things. It does not help I have too many cores for top to display correctly.
<andreas-e>Yes, the old top was more friendly with many cores.
<andreas-e>There must be a way to toggle what it displays.
<RavenJoad>Does guix have the xen guest tools packaged? I could not find them with some "guix search"s, but I may have missed them.
<Guest96>https://paste.debian.net/1290624/ everytime I reconfigure my system, my system isn't booting anymore since it changes stuff in the 1. partition. The first partition has rpi4-uefi files. Did I do something wrong? Since I doubt that this is how it is intended