| vorlon | Eickmeyer: merged and did a test build, fails because xorriso doesn't allow that option when invoked as mkisofs | 01:57 |
|---|---|---|
| Eickmeyer | vorlon: Ok, then I'm trying to figure out how I'm able to do it and ubuntu-cdimage is not. | 01:59 |
| vorlon | with the exact commandline as shown from the logs? | 01:59 |
| Eickmeyer | No, more like I'm trying to figure out how cubic is able to do it. | 02:00 |
| Eickmeyer | vorlon: Are we using "-iso-level 3"? | 02:07 |
| Eickmeyer | vorlon: Answered my own question. We're not. That's the factor, -iso-level 3 supports larger files. | 02:11 |
| Eickmeyer | vorlon: From the manpage: Level 3 allows ISO names with up to 32 characters and file size of up to 400 GiB - 200 KiB. (This size limitation is set by the xorriso implementation and not by ISO 9660 which would allow nearly 8 TiB.) | 02:23 |
| tarzeau | Eickmeyer: i managed to get in photoqt into 22.04, but it's probably too late for inclusion? (5 MB, qt photo tool), I'm aware of the recent discussions of size usage | 04:27 |
| tarzeau | wrong channel, sorry | 04:27 |
| juliank | tests results today so far: 2307 amd64 706 ppc64el 348 s390x 314 arm64 202 armhf 10 i386 | 08:10 |
| juliank | and we were apparently not running PPA tests | 08:11 |
| -queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.14-0ubuntu0.20.04.2 => 15.2.16-0ubuntu0.20.04.1] (desktop-core, ubuntu-server) | 08:48 | |
| juliank | armhf is moving slowly because it still does not respect timeouts and tests just hang for 13 hours | 10:03 |
| juliank | well, 24 hours eventually | 10:04 |
| juliank | I lowered the killing timeout to 12 hours | 10:04 |
| juliank | armhf is still running tests submitted 10 days ago | 10:08 |
| juliank | it's not working | 10:08 |
| juliank | the problem is that if tests get cancelled they stay at the front of the queue | 10:10 |
| juliank | I'm stopping the armhf testers, deleting everything from before 2022-03-2*, restart the workers and hope this gets things moving | 10:12 |
| juliank | armhf should be back shortly | 10:22 |
| juliank | (maintenance is done, it should boot now) | 10:22 |
| juliank | maybe this total armhf reboot also resolves the timeout issues, who knows | 10:23 |
| juliank | ugh I forgot to delete security ppa tests from 20202-02-25 and 2022-03-10 | 10:25 |
| juliank | apologies | 10:25 |
| -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [amd64] (jammy-proposed) [2.06-2ubuntu6] | 11:11 | |
| -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [arm64] (jammy-proposed) [2.06-2ubuntu6] | 11:11 | |
| xnox | doko: vorlon: juliank: some of the no-change rebuilds that sil2100 did for powerpc abi bump generated a tonne of autopkgtest and are not needed at all.for example meta rebuilds of boost-defaults cross-toolchain-base and similar. | 11:23 |
| xnox | would be nice to remove that from proposed, and nuke the autopkgtests for them. unless too late now. | 11:23 |
| juliank | xnox: we should nuke autopkgtests, please gather the names into a regex | 11:24 |
| juliank | xnox I'm deleting the boost and cross-toolchain ones | 11:26 |
| xnox | "triggers": ["lsb/11.1.0ubuntu4"]} | 11:27 |
| xnox | is also meta-only | 11:27 |
| xnox | it's like 700 tests | 11:27 |
| xnox | "triggers": ["boost-defaults/1.74.0.3ubuntu7"] | 11:27 |
| juliank | for arch in armhf arm64 amd64 i386 ppc64el s390x; do ./autopkgtest-cloud/tools/filter-amqp amqp://$RABBIT_USER:$RABBIT_PASSWORD@$RABBIT_HOST debci-huge-$rel-$arch '"(mesa/22.0.0-0ubuntu1|boost-defaults/1.74.0.3ubuntu7|cross-toolchain-base/59ubuntu3|lsb/11.1.0ubuntu4)' ; done | 11:28 |
| juliank | I'm running that now from autopkgtest-cloud-worker/0 | 11:29 |
| juliank | but I'm gonna disappear now, so you might want to run this yourself by ssh to wendigo, sudo to prod-proposed-migration, then juju ssh autopkgtest-cloud-worker/0; set -a; . rabbitmq.cred and then execute loop like above | 11:29 |
| juliank | note that things are slow | 11:30 |
| juliank | probably we should query for ["trigger" | 11:30 |
| juliank | to not prevent test runs triggered by other packages tha tjust happen to have .e.g lsb as 2ndary trigger | 11:30 |
| xypron | LP #1965260 is updating a package that has not been released before Jammy. It fixes an issue with RAM size detection? Does it need a feature freeze exception? Can such an exception be granted. | 12:03 |
| ubottu | Launchpad bug 1965260 in nezha-boot0 (Ubuntu) "FFE: Detect RAM size automatically" [Undecided, Confirmed] https://launchpad.net/bugs/1965260 | 12:03 |
| RikMills | sil2100: hi, FYI LP: #1966204 is needed for the Kubuntu beta | 12:13 |
| ubottu | Launchpad bug 1966204 in ubiquity (Ubuntu Jammy) "Kubuntu jammy install hangs at creating ext4 filesystem (33%)" [Critical, Fix Committed] https://launchpad.net/bugs/1966204 | 12:13 |
| sil2100 | o/ | 12:13 |
| RikMills | o/ | 12:13 |
| sil2100 | RikMills: is it still waiting on tests to finish to migrate? | 12:14 |
| RikMills | sil2100: yep | 12:14 |
| sil2100 | FWIW we also are waiting for the langpacks to migrate as well... | 12:14 |
| sil2100 | I pushed them to -proposed yesterday but those are still not fully passing | 12:15 |
| RikMills | the arm* queues are very backlogged also | 12:15 |
| sil2100 | I think because of so many things in flight, I anticipate Beta freeze might need to wait till much later today | 12:15 |
| RikMills | sounds likely | 12:16 |
| seb128 | doing archive rebuilds the week of beta seem to have become a sort of tradition... | 12:17 |
| seb128 | the autopkgtest backlog is going to make tricky trying to land any fix in time for beta | 12:18 |
| === mfo_ is now known as mfo | ||
| sil2100 | seb128: I think it was always the case. We actually always had archive rebuilds as a point in our beta milestone release process from what I know | 12:42 |
| sil2100 | Well, looking at it now, in the process those are in 'minus 3 days', so I guess we started a bit early | 12:44 |
| sil2100 | (per https://wiki.ubuntu.com/BetaProcess ) | 12:44 |
| seb128 | sil2100, sorry what I wrote was unclear, the archive rebuilds for ftbfs reports don't impact our autopktest queues and don't create delays, I was speaking about those bileto landing for ppc64el rebuilds | 12:53 |
| seb128 | or new qt | 12:54 |
| sil2100 | Those are indeed unfortunate. But better now than, like last time, before the actual final release! | 12:56 |
| seb128 | right | 12:57 |
| juliank | seb128, sil2100 I might still go through the uploads and move the remaining ones to the huge queue | 13:07 |
| juliank | Just didn't get around to it | 13:07 |
| juliank | Then normal queues are free for manual requests and normal uploads | 13:07 |
| xnox | seb128: i was gonna say doing it now, is better than last time. | 13:08 |
| xnox | vorlon: sil2100: but yeah, it sounds like large ABI rebuilds are always point regardless when one does them. Thus the thinking to "wait for organic rebuilds" and upload the rest "later" might not have been a good one. | 13:09 |
| xnox | i.e. uploading everything after toolchain bump, may have been better. A sort of 2-in-1 in-archive rebuild, plus powerpc abi bump. | 13:09 |
| xnox | or like uploading N-number of them every day over a month. | 13:09 |
| sil2100 | I'm not against leaving this out to wait a bit for some organic rebuilds, but I think what we did wrong is not putting this on the big-transition schedule | 13:09 |
| sil2100 | We probably should have remembered about this early, define some date by which we say 'enough waiting' and make sure it's on the schedule | 13:10 |
| sil2100 | Like a bit after FF or something | 13:10 |
| xnox | sil2100: also some of your uploads were very redudnant. like boost-defaults lsb cross-toolchain-base etc. Many of them are arch:any but in practice are metas that don't contain any arch-specific binaries...... because arch:all packages cannot have arch specific depends. | 13:10 |
| sil2100 | Right, maybe I could be a bit more specific while defining the list, I was basically just going though packages with ppc64el binaries, without considering what kind of binaries those are | 13:11 |
| sil2100 | But I don't know if that could have been determined by some automated way? | 13:12 |
| xnox | probably nothing automated. | 13:13 |
| xnox | maybe check package install size to be like more than some threshold. | 13:13 |
| xnox | which means it is likely not to have any binaries. | 13:13 |
| seb128 | xnox, earlier is better imho, even if we miss some 'free rebuilds' at least it's not creating delay which are preventing milestone fixes to land | 13:25 |
| seb128 | or at least let a week free before beta next time | 13:26 |
| sil2100 | seb128: which packages are you looking to land for beta that are still blocked in -proposed? | 13:26 |
| sil2100 | Maybe I can help out somehow | 13:27 |
| seb128 | sil2100, I need to check, the by_team report isn't even in a workable state atm, we have 135 items listed under desktop there | 13:27 |
| coreycb | does anyone know if there is a standard deadline in an ubuntu cycle for MIR approval? | 13:27 |
| seb128 | sil2100, I'm not even sure how to filter fixes from the team from the noise | 13:27 |
| seb128 | coreycb, there isn't, MIR by itself isn't impacting much, but usually you want a MIR to bring something new in so that would be covered by a FFe | 13:28 |
| coreycb | seb128: it's something that has been in jammy-proposed for a while, for my case. | 13:29 |
| coreycb | seb128: just waiting on security review and I want to coordinate with them to see how much time they have | 13:30 |
| seb128 | coreycb, I'm not sure it's covered specifically by our documentation, usually things uploaded before feature freeze don't need an exception, but technically you shrink your testing period by unblocking late | 13:31 |
| seb128 | I will let someone who is actually in the release team reply though | 13:31 |
| coreycb | ok, thanks seb128 | 13:33 |
| sil2100 | coreycb: the earlier the better. As seb128 mentioned, we don't really have any hard freezes for these (besides final freeze of course), but the 'perfect goal' would be to get as much in for the beta this week as possible, so that if it's to be pulled in, it's tested as part of the Beta | 13:37 |
| sil2100 | If, of course, you have an FFe approved for this already (if this is to be included by default on some Ubuntu installations) | 13:37 |
| seb128 | xnox, would it make sense to merge https://code.launchpad.net/~vorlon/ubiquity/+git/ubiquity/+merge/408964 ? | 14:13 |
| coreycb | sil2100: thank you, I will pass this along | 14:19 |
| xnox | seb128: left a comment with reasons why localechooser is so so so weird. | 14:21 |
| xnox | also what is going on with it | 14:22 |
| xnox | why does it ftbfs on most arches?! https://launchpad.net/ubuntu/+source/localechooser/2.89ubuntu3 | 14:23 |
| juliank | armhf is soo much better | 14:25 |
| juliank | xnox: it seems there's a bug where launchpad ignores the !noudeb profile when figuring out whether to build arch: any packages | 14:26 |
| juliank | xnox: like if there's only arch: all .deb + arch: any udeb, launchpad will schedule arch: any builds which then fail as there's no arch any to build | 14:26 |
| xnox | juliank: ah | 14:33 |
| xnox | juliank: and we can't do !noudeb everywhere yet, because we still have active series that build udebs, and launchpad is not actually aware of noudeb. | 14:33 |
| juliank | xnox: well I guess we need to have the build scheduling be aware of it | 14:34 |
| -queuebot:#ubuntu-release- Unapproved: horizon (impish-proposed/main) [4:20.1.1-0ubuntu1 => 4:20.1.1-0ubuntu2] (openstack) | 14:40 | |
| Eickmeyer | sil2100: In addition to everything else, Ubuntu Studio isn't building because the squashfs file size is exceeding what is allowed. vorlon and I are working on fixes to ubuntu-cdimage. bug 1966523 | 14:48 |
| ubottu | Bug 1966523 in Ubuntu CD Images "Ubuntu Studio ISOs are reaching hard ISO 9660 limit" [Undecided, New] https://launchpad.net/bugs/1966523 | 14:48 |
| sil2100 | Eickmeyer: hm, let me read up on this 'level 3 ISO' and maybe merge this + deploy | 14:51 |
| sil2100 | Maybe it's worth a try! | 14:52 |
| Eickmeyer | I've had success with it anecdotally. | 14:52 |
| -queuebot:#ubuntu-release- Unapproved: horizon (focal-proposed/main) [3:18.3.5-0ubuntu1 => 3:18.3.5-0ubuntu2] (openstack, ubuntu-server) | 15:03 | |
| sil2100 | Eickmeyer, vorlon: merged and deployed the -iso-level change. Per manpage it felt correct, so I'll run a studio build to see if it helped | 15:04 |
| Eickmeyer | sil2100: Thanks so much! | 15:05 |
| sil2100 | Maybe I'll re-use the existing livefs if possible, I'll see if there is one | 15:05 |
| vorlon | sil2100: perfect, thanks | 15:11 |
| vorlon | xnox: I still disagree wrt localechooser. The rationale for putting these in git subtrees was that they were no longer in the archive; this doesn't apply at all to localechooser; the handling of localechooser via both the archive and separately via git subtree that then has to be *patched* is meh | 15:14 |
| xnox | vorlon: rationale for git subtrees was more than just no longer in the archive. but also the insanity of maintaining git->bzr mirrors; and using bzr merge of those; which stopped working; to upload into archive; to then vendor into ubiquity; which often was too slow; and people were patching components inline; and then on release weak we did full uploads; and randomly were picking up more | 15:23 |
| xnox | changes unexpectadly. | 15:23 |
| xnox | vorlon: having all of them as subtrees helps a lot with sanity; but i do think we should be doing pull subtree on every clean/build of ubiquity; but that has never happened. | 15:23 |
| xnox | vorlon: and i.e. we are missing a tonne of fixes and translations in ubiquity for jammy now. | 15:23 |
| vorlon | yes, I don't think you socialized this particularly | 15:23 |
| xnox | vorlon: not sure if we want to merge all of those. | 15:23 |
| vorlon | anyway, the localechooser source package has a Launchpad Vcs-Git field, so git->bzr mirrors are not a consideration there | 15:24 |
| xnox | vorlon: yeah, it didn't quite catch on, and a couple of people who were trained in that / designed that; quit or otherwise moved on. | 15:24 |
| xnox | vorlon: what really confuses me is why we have patched localechooser in ubiquity only. | 15:25 |
| xnox | vorlon: or if ubiquity is now the only user of localechooser; we can apply that patch as ubuntu delta to localechooser now, no? | 15:25 |
| vorlon | the bit being patched is d-i specific so there's no reason not to include that patch in the localechooser source | 15:25 |
| vorlon | right | 15:25 |
| xnox | cool. let's do that. | 15:25 |
| xnox | but still want it as a subtree. | 15:25 |
| xnox | please =) | 15:25 |
| vorlon | eh | 15:26 |
| vorlon | if it's going to be in sync with the archive package, I still think using subtrees are a hindrance for this | 15:26 |
| vorlon | also you have a ubiquity/d-i/README and a ubiquity/d-i/source/README that contradict one another | 15:27 |
| Eickmeyer | sil2100, vorlon: It built! zsyncing now. | 15:32 |
| sil2100 | \o/ | 15:32 |
| xypron | bdmurray: what is your view on LP #1965260, see above? | 15:36 |
| ubottu | Launchpad bug 1965260 in nezha-boot0 (Ubuntu) "FFE: Detect RAM size automatically" [Undecided, Confirmed] https://launchpad.net/bugs/1965260 | 15:36 |
| dbungert | release team, please consider LP: #1966186, ping bdmurray sil2100 | 15:46 |
| ubottu | Launchpad bug 1966186 in subiquity "[FFe] Hide Ubuntu Advantage / Ubuntu Pro screen for 22.04" [Undecided, New] https://launchpad.net/bugs/1966186 | 15:46 |
| sil2100 | dbungert: looking o/ | 15:47 |
| bdmurray | that's in the same vein as things already approved so I'm a +1 | 15:47 |
| ginggs | britney isn't trying to migrate rebuilds of deal.ii and trilinos together. i've tried on amd64 and arm64 and was able to install libdeal.ii-dev and the entire stack was pulled in with no conflicts. can we try hint them together? i think 'easy deal.ii/9.3.2-1~exp1ubuntu1 trilinos/13.2.0-1ubuntu1' should do it | 15:55 |
| dbungert | bdmurray: OK thanks. So is there anything else that needs to happen or can I hit the merge button? | 15:58 |
| bdmurray | dbungert: let me comment on the bug and set it to triaged | 15:58 |
| Eickmeyer | sil2100, vorlon: Confirmed, it boots in both MBR and UEFI modes. We have a winner. | 16:01 |
| dbungert | subiquity build started for inclusion of the last few feature freeze exception things. | 16:09 |
| sil2100 | Eickmeyer: that is excellent news, thank you for submitting the fix! | 16:17 |
| juliank | ** The ppc64el rebuilds now all live in the huge queues, remaining in the normal queues are now 481 on arm64, 357 on armhf; this means that manually requested tests and hotfixes pass earlier now ** | 17:00 |
| juliank | (those tests went from the top of the normal queue to the *back* of the huge queues, fwiw) | 17:01 |
| juliank | I'm also gonna go and filter out duplicate test requests | 17:04 |
| juliank | it seems there were not many dupes | 17:12 |
| juliank | One day I guess we should implement merging of test requests, if same package triggered by multiple packages, merge triggers | 17:13 |
| juliank | then you need to migrate the triggers together though | 17:13 |
| juliank | however it's conceivable you can test multiple pools and then combine them to find the culprit? | 17:14 |
| juliank | I don't know! | 17:14 |
| juliank | A, B, C trigger; we have two requests {A,B} and {B,C} | 17:14 |
| juliank | I guess we only save 1 test? | 17:15 |
| juliank | I'm not good at stochastics | 17:16 |
| juliank | But if it works for COVID pool tests, it should work for autopkgtests? | 17:16 |
| bdmurray | Does zsync not work over https? `could not read control file from URL https://cdimage.ubuntu.com/daily-live/current/jammy-desktop-amd64.iso.zsync | 17:51 |
| Eickmeyer | bdmurray: I'll do a test and see. | 17:58 |
| Eickmeyer | bdmurray: Yeah, I got a "failed on url". | 17:59 |
| jbicha | bdmurray: yes, just change your URL to http , see bug 1927807 | 18:00 |
| ubottu | Bug 1927807 in zsync (Ubuntu) "'https' address causes zsync download to fail with error 'could not read control file from URL'" [High, Triaged] https://launchpad.net/bugs/1927807 | 18:00 |
| RikMills | bdmurray: that is a longstanding problem with zsync | 18:02 |
| kanashiro | could any SRU team member take a look at LP: #1960449? | 19:16 |
| ubottu | Launchpad bug 1960449 in runc (Ubuntu Impish) "Backport container stack in Jammy" [Medium, In Progress] https://launchpad.net/bugs/1960449 | 19:16 |
| sil2100 | dbungert: hey! Did you manage to push the new subiquity to the 22.04 branch? | 20:02 |
| sil2100 | Are we ready for beta from the POV of live-server? | 20:02 |
| dbungert | sil2100: will promote now | 20:04 |
| dbungert | sil2100: done | 20:07 |
| sil2100 | dbungert: thanks! | 20:17 |
| sil2100 | I need to go EOD now. Regarding jammy beta, seeing that there are still things in flight, we might build first Beta candidates tomorrow morning | 21:15 |
| sil2100 | But I'll leave it up to vorlon and bdmurray to decide if maybe they'll still try kicking those off today | 21:15 |
| sil2100 | o/ | 21:15 |
| vorlon | bdmurray: is this the right syntax and the right list to freeze? generate-freeze-block kubuntu lubuntu ubuntu ubuntu-budgie ubuntukylin ubuntu-mate ubuntustudio xubuntu | 21:59 |
| bdmurray | vorlon: I think you are missing ubuntu-server | 22:00 |
| vorlon | bdmurray: ok, wasn't clear on whether the "flavours" list went by images or seed pods | 22:01 |
| bdmurray | Oh and I modified it last release so make sure you are up to date | 22:02 |
| kc2bez | vorlon: may we please bump the Lubuntu iso warning size to 2.8G? | 22:09 |
| vorlon | kc2bez: done | 22:20 |
| vorlon | bdmurray: freeze block in place | 22:20 |
| bdmurray | vorlon: Should we also make the the launchpad.net/ubuntu/jammy change? | 22:23 |
| vorlon | bdmurray: ah; didn't recall that we still did both at beta. The latter requires IS intervention | 22:24 |
| bdmurray | vorlon: That's not exactly true | 22:24 |
| vorlon | ... | 22:25 |
| -queuebot:#ubuntu-release- Unapproved: 0ad (jammy-proposed/universe) [0.0.25b-1.1ubuntu1 => 0.0.25b-2] (no packageset) (sync) | 22:40 | |
| -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Jammy Beta] (20220328.1) has been added | 22:52 | |
| kc2bez | Thanks vorlon | 22:56 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (jammy-proposed/universe) [22.04.10 => 22.04.11] (ubuntu-mate) | 23:02 | |
| Wimpy | Please allow ubuntu-mate-artwork 22.04.11 | 23:07 |
| Wimpy | It is essential for the beta and depends on yaru-theme that was uploaded earlier this evening. | 23:07 |
| bdmurray | I'll have a look | 23:11 |
| Wimpy | ty bdmurray | 23:12 |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (jammy-proposed) [22.04.11] | 23:12 | |
| Wimpy | <3 | 23:12 |
| Eickmeyer | bdmurray: "...until final release in October" oops | 23:25 |
| bdmurray | Eickmeyer: there might be some point release then | 23:25 |
| Eickmeyer | bdmurray: Isn't final release in April for this one? | 23:26 |
| bdmurray | Yes, I was hoping I might somehow be correct | 23:26 |
| Eickmeyer | Hehe | 23:26 |
| sarnold | so we can't just take a nap for a few months? | 23:29 |
| Eickmeyer | sarnold: Ha! Fat chance. | 23:30 |
| mdeslaur | Oh, I thought October is when we thought the autopkgtest queue would catch up | 23:30 |
| Eickmeyer | mdeslaur: I mean, you're not wrong. | 23:30 |
| bdmurray | Such a tough crowd | 23:31 |
| mdeslaur | hehehe | 23:32 |
| Eickmeyer | HAHA | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!