| === ubuntu_4321 is now known as ubuntu4321 | ||
| adrien | paride: openmpi/prrte can "overcommit" slots, and I expect that previous versions did that by defaults and newer ones don't | 06:45 |
|---|---|---|
| paride | adrien, I see. so everything adds up, apparently? | 08:26 |
| adrien | paride: I can't say for sure that this is the reason but there were larges changes in openmpi/pmix and I think I saw something about that in some changelog even though I can't find it again now | 08:34 |
| paride | adrien, for those packages, are you adding to big_packages to make them get 4 cores, or what else? | 08:35 |
| paride | adding *them | 08:35 |
| adrien | I've instead modified them to limit themselves to the number of cores available: https://code.launchpad.net/~adrien/ubuntu/+source/gpaw/+git/gpaw/+merge/477858 for gpaw | 08:41 |
| adrien | and another one coming in a couple minutes | 08:41 |
| adrien | my scripting failed during the night so the tests for parmetis weren't triggered but I'll create the MR without waiting | 08:42 |
| adrien | I'll push the changes debian-side afterwards rather than immediately because I think we want to get the openmpi transition done as quickly as possible now | 08:43 |
| adrien | paride: sigh, I wasn't building using proposed for parmetis so I'd need a new loop iteration to confirm the fix I think but the one for gpaw is ready and tested | 08:48 |
| adrien | great: adios2 needs a change too | 08:52 |
| ginggs | adrien, paride: the name of the environment variables for oversubscription changed in openmpi 5 | 09:17 |
| ginggs | https://salsa.debian.org/science-team/petsc/-/commit/21f8e199f3c563ac0119ffc797cdf1075b931b38 | 09:17 |
| -ubottu:#ubuntu-devel- Commit 21f8e19 in science-team/petsc "OpenMPI 5.0 changed the name of the environment variables OMPI_MCA_rmaps_base_oversubscribe and OMPI_MCA_plm_rsh_agent. Use the new variable name in debian/rules and debian/tests." | 09:17 | |
| adrien | ginggs: ha! thanks! I'll re-do my changes, that should be quick | 09:22 |
| sudip | eztrace tests are also failing | 09:33 |
| ginggs | eztrace looks like another tsimonq2 syncpackage -f | 09:40 |
| * sudip looks | 09:47 | |
| sudip | I will add the delta now | 09:49 |
| adrien | It looks like britney is not seeing the petsc amd64 build which finished 20 hours ago; that's unexpected, right? And I guess that this can be caused by LP's publisher is having troubles? | 10:20 |
| sudip | adrien: it was waiting for the NEW which was approved approx an hour ago. should be available in next few minutes | 10:24 |
| ginggs | yeah, there was a binary NEW on amd64 | 10:25 |
| adrien | sudip: thanks; never really had to look at the queue so far | 10:25 |
| adrien | Where can I look at the new queue? I think I looked at it at some point but I'm completely unable to find it again now. | 10:30 |
| seb128 | adrien, https://launchpad.net/ubuntu/plucky/+queue?queue_state=0 | 10:38 |
| adrien | ta! I need to bookmark this because ff's wonderbar won't help here :) (it took me 15 years to start loving the wonderbar, apparently long enough that it changed names 3 times) | 10:40 |
| adrien | (it was actually awesomebar, it didn't change name that many times :) ) | 10:42 |
| sudip | seb128: ooi, what is queue_state ? for SRU queues I use queue_state=1, never realised it can be 0 also | 10:46 |
| seb128 | sudip, you have a combo box in the UI listing the different values possible | 10:46 |
| seb128 | 0 is unapproved, 1 is new | 10:47 |
| seb128 | just play with the combo, click the update button and check the url | 10:47 |
| sudip | yeah, I realised now. I changed the combo before but never clicked on the update button after that and expected it to update automatically. | 10:48 |
| sudip | thanks seb128 | 10:48 |
| adrien | also, the API is at https://api.launchpad.net/devel.html#package_upload and I think numerical values stem from the order of the values listed for "status" | 10:49 |
| sudip | adrien: do you have mpi4py in your list? it has same autopkgtest failure | 10:58 |
| adrien | sudip: I'm not seeing the same error for mpi4py, which test/trigger/log was that? However I have a merge for mpi4py that needs sponsoring and fixes errors at least on s390x: https://code.launchpad.net/~adrien/ubuntu/+source/mpi4py/+git/mpi4py/+merge/477530 ; it looks like it has a merge conflict now however | 11:36 |
| sudip | oops, sorry. I was looking at the one triggered for 3.1.6-9ubuntu1, not the one you triggered | 11:37 |
| ginggs | adrien: you can also see binary new packages in the package builds | 11:38 |
| ginggs | https://launchpad.net/ubuntu/+source/petsc4py/3.22.1-2ubuntu1 | 11:38 |
| ginggs | Plucky: [FULLYBUILT] amd64 (New) [FULLYBUILT] arm64 (New) [BUILDING] armhf [FULLYBUILT] ppc64el (New) [BUILDING] riscv64 [FULLYBUILT] s390x (New) | 11:39 |
| ginggs | and you can go further | 11:39 |
| ginggs | https://launchpad.net/ubuntu/+source/petsc4py/3.22.1-2ubuntu1/+build/29332756 | 11:39 |
| ginggs | Binary packages / Binary packages awaiting approval in NEW queue | 11:40 |
| sudip | adrien: in your merge for mpi4y, you have also committed the rebase errors | 11:40 |
| sudip | in debian/changelog and debian/tests/mpi4py-test | 11:40 |
| ginggs | adrien, sudip: what about a sync for mpi4py, and then merge in the change if still needed? | 11:41 |
| adrien | ginggs: I think that could work, I just went for a middle-ground that reduces the number of uploads as I said in the MR (since I can't upload, I have to optimize for that) | 11:42 |
| sudip | I will sync now and see what happens | 11:43 |
| adrien | ginggs: I was reading the build pages too quickly and hadn't noticed the mentions of "new", thanks :) | 11:44 |
| adrien | sudip: actually I think the mistake is that I "targetted" pkg/ubuntu/devel instead of pkg/debian/sid | 11:44 |
| adrien | yes, that was it; I kept the changelog entries from ubuntu | 11:45 |
| sudip | mpi4py synced, I can upload your merge if the synced mpi4py fails | 11:47 |
| adrien | sounds good, thanks (lunch time now) | 11:47 |
| sudip | eztrace also uploaded with the old delta as a merge | 11:48 |
| sudip | adrien: we will need the mpi4y merge, armhf build failed | 12:03 |
| jbicha | doko: do you know what is going wrong with this build? https://launchpad.net/ubuntu/+source/libimobiledevice/1.3.0-8.1ubuntu1 | 14:14 |
| ginggs | jbicha: cython-legacy is gone | 14:17 |
| jbicha | oh I see, thanks | 14:17 |
| adrien | sudip: have you been able to look at my change for mpi4py and upload it? do you need me to change something? | 14:57 |
| sudip | adrien: no, sorry, went for a meeting in $dayjob, had a look and also built it. uploading now. | 14:58 |
| adrien | thanks :) | 15:05 |
| ginggs | wow, the autosync-er seems to have been very confused by debian re-using a version number in unstable, that was previously used in experimental | 15:08 |
| ginggs | https://launchpad.net/ubuntu/+source/mpich/4.2.1-2 | 15:08 |
| ginggs | https://tracker.debian.org/news/1591680/accepted-mpich-421-2-source-into-unstable/ | 15:08 |
| adrien | only kept the first one; should it "forget" about the first one and pick the one from unstable? | 15:11 |
| ginggs | i would have expected that | 15:14 |
| cjwatson | Probably too late, debusine will already have a record for it | 15:23 |
| cjwatson | Debian should really not have done that! | 15:23 |
| cjwatson | err s/debusine/Launchpad/ :-) | 15:23 |
| cjwatson | IMO it's ridiculous for dak to allow that but the least confusing fix would be to get the Debian mpich maintainer to upload a new non-ambiguous version | 15:24 |
| ginggs | i can upload 4.2.1-2ubuntu1 (as soon as it builds in my PPA) | 15:32 |
| ginggs | . | 16:30 |
| adrien | only gpaw and parmetis left for openmpi and I have sponsorship requests for both (they're both simple) so hopefully openmpi itself will be seen as good by britney afterwards :) | 17:06 |
| sudip | no, there are still many. I just triggered the level 6 builds, another needs a merge which I built in a PPA, waiting to autopkgtest before pushing | 17:11 |
| sudip | all the risv64 builds are still waiting for vtk9 to complete | 17:12 |
| adrien | yeah, what I meant was that openmpi itself may be written as fine by britney but the transition is far from complete indeed | 17:20 |
| adrien | vtk9 took hours on my laptop and I think that translates to days on riscv64 builders, maybe half a week... | 17:20 |
| sudip | yeah, last build took around 23 hours and then that failed without a log, I triggered a rebuild which should complete in next 5-6 hours :) | 17:21 |
| sudip | adrien: did you trigger any autopkgtest for gpaw? the last log from your ppa for amd64 still fails with the same error | 17:24 |
| sudip | https://autopkgtest.ubuntu.com/results/autopkgtest-plucky-adrien-plucky-gpaw-too-many-procs/plucky/amd64/g/gpaw/20241206_123032_35d90@/log.gz | 17:24 |
| adrien | I didn't manage to trigger the tests with the right environment; actually, as you can see, it's pulling an older openmpi in that log | 17:27 |
| adrien | and nothing from proposed | 17:27 |
| adrien | generally speaking, I haven't been able to use -proposed from the tests in PPas | 17:28 |
| adrien | PPAs* | 17:28 |
| sudip | triggered one, lets see | 17:31 |
| sudip | adrien: https://autopkgtest.ubuntu.com/results/autopkgtest-plucky-adrien-plucky-gpaw-too-many-procs/plucky/amd64/g/gpaw/20241206_174312_9317f@/log.gz | 17:45 |
| sudip | you do not have proposed enabled in your ppa, if you see the build log it only takes from plucky not from plucky-proposed | 17:46 |
| sudip | the autopkgtest problem is happening from my ppa also | 17:57 |
| ginggs | in the past, triggering tests in my PPA twice; once with &all-proposed=1 and once without, has been useful for e.g. python transitions | 18:06 |
| sudip | ginggs: tried that. all are failing. with allproposed its trying to fetch plucky-proposed for ppa also | 18:08 |
| sudip | https://autopkgtest.ubuntu.com/results/autopkgtest-plucky-sudipmuk-test-ppa/plucky/amd64/s/slepc4py/20241206_175404_30040@/log.gz | 18:08 |
| sudip | and proposed disabled, its failing to install | 18:08 |
| sudip | which is https://autopkgtest.ubuntu.com/results/autopkgtest-plucky-sudipmuk-test-ppa/plucky/amd64/s/slepc4py/20241206_180201_87f56@/log.gz | 18:08 |
| sudip | adrien: tested gpaw autopkgtest locally, looks ok with 2 cpu, will upload now | 19:34 |
| adrien | sudip: thanks | 19:46 |
| adrien | and indeed, the ppa was without proposed; I use ppa-dev-tools to create the PPAs and unfortunately there is no API to enable proposed so it has to be done by hand and I sometimes failed to do so :/ | 19:46 |
| sudip | that fix should also go to Debian, right? | 19:47 |
| adrien | also, there has been changes to autopkgtest repos in the past few days (less than a week) so it's possible something broke for all-proposed=1 in PPAs | 19:47 |
| adrien | I don't have the diffs in front of my eyes right now but IIRC, all of these should go to debian too, yes | 19:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!