[01:43] -queuebot:#ubuntu-release- Unapproved: update-manager (jammy-proposed/main) [1:22.04.12 => 1:22.04.13] (core)
[01:55] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.13 => 1:20.04.10.14] (core)
[02:01] <pabs3> bdrung has changed chdist to use Ubuntu devel https://salsa.debian.org/debian/devscripts/-/commit/c4f65475d3549e81dfce56426e947e579afa92eb
[02:01] <pabs3> but this causes warnings from apt: W: Conflicting distribution: http://archive.ubuntu.com/ubuntu devel InRelease (expected devel but got lunar)
[02:01] <pabs3> would it be possible for the 'devel' symlink to be turned into a proper suite finally?
[02:01] <pabs3> this was requested in these two old ubuntu-archive/apt bugs:
[02:01] -ubottu:#ubuntu-release- Commit c4f6547 in debian/devscripts "chdist: Default to Ubuntu devel release in sources.list example"
[02:01] <pabs3> https://bugs.launchpad.net/ubuntu/+bug/1821272
[02:01] -ubottu:#ubuntu-release- Launchpad bug 1728616 in apt (Ubuntu) "using 'devel' in sources.list causes apt-get update to fail" [Undecided, Opinion] [duplicate: 1821272]
[02:01] <pabs3> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1728616
[02:01] -ubottu:#ubuntu-release- Launchpad bug 1728616 in apt (Ubuntu) "using 'devel' in sources.list causes apt-get update to fail" [Undecided, Opinion]
[02:09] <cjwatson> Requires non-trivial Launchpad work and is unlikely to happen any time soon.
[02:10] <cjwatson> IMO that chdist change should be reverted.
[02:11] <cjwatson> It's a nice idea, but it's not a priority - I'd rather do other archive rework that will make this sort of thing easier in future (as we are currently doing).
[02:17] <cjwatson> (Well, maybe not reverted.  But not done like that.)
[02:27] -queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.16 => 1:18.04.11.17] (core)
[02:34] <mwhudson> i just have a symlink in ~/.chdist :-)
[03:28] <pabs3> cjwatson: thanks for the info. since apt only warns not errors these days, maybe chdist can just be kept as-is until it gets fixed in the archive.
[07:44] <LocutusOfBorg> hello ubuntu-archive, uwsgi needs some NSB proposed cleanup, e.g.
[07:44] <LocutusOfBorg> old binaries left on amd64: uwsgi-plugin-jvm-openjdk-11, uwsgi-plugin-jwsgi-openjdk-11, uwsgi-plugin-rack-ruby3.0, uwsgi-plugin-ring-openjdk-11, uwsgi-plugin-servlet-openjdk-11 (from 2.0.20-4build1)
[07:45] <LocutusOfBorg> (every architecture except riscv64 where only uwsgi-plugin-rack-ruby3.0 has to go)
[07:47] <LocutusOfBorg> arraybolt3, the failure looks real
[07:47] <LocutusOfBorg> E: Unknown Error: '<class 'KeyError'>' ("The cache has no package named 'python3.11:ppc64el'")
[08:00] <LocutusOfBorg> arraybolt3, I think depending on python3.11 will fix the issue and it can be reverted once the big migration happens), for some reasons on my pc I can't install update-notifier-common without being forced to have python3.11
[08:01] <LocutusOfBorg> on testbed there is already python3.10, probably this is satisfying the dependency but not completely
[08:02] <LocutusOfBorg> maybe vorlon can hint that test for now?
[08:04] <LocutusOfBorg> and also python-cryptography can now go away on i386 maybe?
[08:04] <arraybolt3> LocutusOfBorg: I'd be happy to upload a new version of l-u-n with python3.11 as a dependency, if it works with python3.11.
[08:05] <LocutusOfBorg> arraybolt3, and then revert the upload? seems more a case of a one-time force badtest
[08:05] <arraybolt3> I'll test and make sure locally, and then push it. Really there's no need to undo it later in Lunar since python3.11 is what we're transitioning to anyway.
[08:05] <LocutusOfBorg> having an upload just to solve a temporary issue
[08:05]  * arraybolt3 looks at something real quick
[08:05] <LocutusOfBorg> arraybolt3, the problem is not in your package, its in every package using that apt-check as tool btw
[08:05] <LocutusOfBorg> so, fixing it looks meh
[08:06] <arraybolt3> Hmm, that makes sense.
[08:06] <arraybolt3> (Odd, if it's python3.11 that's missing... l-u-n depends on Python, should it not install python3.11 if -proposed is enabled or it's part of the autopkgtest triggers?)
[08:06] <arraybolt3> *enabled and pinned
[08:09] <arraybolt3> And I see the failure here (earlier test): https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/arm64/l/lubuntu-update-notifier/20230201_221430_39d9f@/log.gz Same failure presumably, full python3.11 installed as part of the autopkgtest. Maybe I'm misunderstanding the error message.
[08:32] <LocutusOfBorg> (and distro-info now wants mypy)
[08:33] <LocutusOfBorg> bdrung, can we avoid mypy on i386? ^^
[09:34] -queuebot:#ubuntu-release- New sync: pyatem (lunar-proposed/primary) [0.8.2-1]
[10:01] <ginggs> bdmurray: i wasn't looking at finalcif in particular, that was just part of a mass retry
[10:01] <ginggs> bdmurray: i have added finalcif to big_packages for arm64 also
[10:04] <ginggs> bdmurray: i'm not actively looking OOM failures, but if i find a package that regressed everywhere except armhf, then i'll investigate
[10:15] <bdrung> LocutusOfBorg, uploaded distro-info 1.5 to skip mypy on i386
[10:24] <LocutusOfBorg> <3
[10:44] -queuebot:#ubuntu-release- Unapproved: software-properties (jammy-proposed/main) [0.99.22.5 => 0.99.22.6] (core)
[11:32] -queuebot:#ubuntu-release- Unapproved: software-properties (focal-proposed/main) [0.99.9.10 => 0.99.9.11] (core)
[11:34] -queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32.20 => 0.96.24.32.21] (desktop-core, ubuntu-server)
[11:36] <seb128> tjaalton, hey, if you do a SRU shift today it would be great if you could checkout those ^ software-properties J/F/B uploads which are followup bugfixes updates to the recent SRU adding an Ubuntu Pro UI (which is currently halted due to some error reports)
[11:37] -queuebot:#ubuntu-release- Packageset: Added xdg-desktop-portal-lxqt to lubuntu in kinetic
[11:37] -queuebot:#ubuntu-release- Packageset: Added xdg-desktop-portal-lxqt to lubuntu in lunar
[11:47] <LocutusOfBorg> arraybolt3, the error changed
[11:47] <LocutusOfBorg> E: Unknown Error: '<class 'KeyError'>' ("The cache has no package named 'polkitd-pkla:amd64'")
[12:02] <seb128> tjaalton, and also update-manager J/F/B from Robert for similar reasons
[12:04] -queuebot:#ubuntu-release- New sync: xdg-terminal-exec (lunar-proposed/primary) [0~20221120-1]
[12:16] -queuebot:#ubuntu-release- New binary: harfbuzz [i386] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:17] -queuebot:#ubuntu-release- New binary: harfbuzz [amd64] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:17] -queuebot:#ubuntu-release- New binary: harfbuzz [s390x] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:18] -queuebot:#ubuntu-release- New binary: harfbuzz [arm64] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:19] -queuebot:#ubuntu-release- New binary: harfbuzz [ppc64el] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[12:22] -queuebot:#ubuntu-release- New binary: harfbuzz [armhf] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[13:15] -queuebot:#ubuntu-release- New binary: harfbuzz [riscv64] (lunar-proposed/main) [6.0.0+dfsg-3] (core, i386-whitelist)
[13:42] <vorlon> LocutusOfBorg: hi, what's the current state of things with pyqt5?
[13:48] <jbicha> vorlon: python-fabio/amd64 autopkgtest is giving us problems :(
[13:48] <LocutusOfBorg> this trigger worked for pyqt5
[13:48] <LocutusOfBorg> ['pyqt5/5.15.8+dfsg-2', 'lubuntu-update-notifier/0.5.3', 'python3-defaults/3.11.1-0ubuntu1', 'python3.11/3.11.1-2', 'policykit-1/122-3']
[13:53] <tjaalton> seb128: i'm actually off this week..
[13:55] <vorlon> LocutusOfBorg: done a run of NBS cleaning on -proposed
[13:56] <LocutusOfBorg> ta!
[14:01] <vorlon> LocutusOfBorg: python-cryptography: I tried to lose rsync and build-deps by dropping vestigial rsync dep from livecd-rootfs, but now https://people.canonical.com/~ubuntu-archive/germinate-output/i386.lunar/all shows linux also build-depends on it
[14:02] <vorlon> xnox: ^^ is that a real build-dep on rsync from linux or can it be dropped?
[14:02] <vorlon> xnox: oh.  Actually we only build linux-libc-dev from linux on i386, could the build-dep on rsync be arch-qualified?
[14:03] <vorlon> apw: ^^
[14:04] <jbicha> python-fabio worked :)
[14:05] <LocutusOfBorg> python-fabio worked
[14:05] <LocutusOfBorg> oops sorry
[14:06] <apw> vorlon, a good question.  we used to use rsync for copying source for linux-goldfish ... will check if it is still used.
[14:06] <vorlon> apw: thanks.  Trying to unpick python3-cryptography from i386 to avoid bootstrapping a mess of rust build-deps
[14:06] <apw> vorlon, very sensible.
[14:07] <LocutusOfBorg> thanks :D
[14:08] <apw> vorlon, ok it looks like we only actually use rsync in builds which have tools or docs
[14:09] <apw> vorlon, i believe i386 only produced linux-libc-dev which would not use either of those.
[14:09] <vorlon> apw: right
[14:09] <apw> vorlon, so i think the short answer should be we can arch limit it.
[14:10] <apw> vorlon, can you just assume we will do that, and i can push a change to our master for it
[14:10] <LocutusOfBorg> vorlon,
[14:10] <LocutusOfBorg> E: Unknown Error: '<class 'KeyError'>' ("The cache has no package named 'linux-headers-6.1.0-14:armhf'")
[14:10] <LocutusOfBorg> please hint lubuntu-update-notifier on armhf
[14:10] <LocutusOfBorg> I'm really tired to have to pick stuff randomly from proposed to let it pass
[14:11] <LocutusOfBorg> its not python3-defaults fault, and we need migration to see it auto heal
[14:11] <vorlon> apw: so from your perspective I can go ahead and nuke rsync/i386 from lunar?
[14:11] <vorlon> LocutusOfBorg: will look after I axe rsync
[14:11] <apw> vorlon, yeah, if we somehow are using it we will find something else to do the copy :)
[14:12] <LocutusOfBorg> vorlon, let me try another trigger with linux/6.1.0-14.14
[14:13] <vorlon> apw: thanks.  Cross-checking that nothing else that builds i386 binaries builds on it (which germinate won't tell me until the linux build-dep is gone..)
[14:15] <vorlon> hurray, nothing else needs it
[14:16] <apw> vorlon, proposing https://paste.ubuntu.com/p/T4Mc7yT4KV/ for the kernel
[14:17] <vorlon> apw: LGTM
[14:21] <seb128> tjaalton, no worry, I will try to see if there is any other SRU reviewers around, enjoy the rest of your holidays!
[14:22] <seb128> @SRUteam, could someone review the software-properties and update-manager SRU uploads in J/F/B queues? Those are bugfix followup updates to fix issues with the new Ubuntu Pro UIs (the current version in updates are halted due to new error reports so that's an attempt to get that feature unblock which is rather important)
[14:23] <vorlon> LocutusOfBorg: lubuntu-update-notifier/armhf badtest'ed
[14:24] <LocutusOfBorg> ta
[14:24] <vorlon> seb128: well I'm the other SRU vanguard for today, but as I'm in roadmap sessions I don't know whether I'll get to it before EOD
[14:25] <seb128> vorlon, right, well I tried at least, thanks
[14:36] <LocutusOfBorg> vorlon, it passed lubuntu-update-notifier with proposed pocket
[14:37] <LocutusOfBorg> so, unless I miss something, next britney run should see pyqt5 as candidate
[14:44] <vorlon> sweet
[14:47] <vorlon> looks like a britney run just finished and we're waiting for the next to kick off
[14:47] <vorlon> (otherwise I was going to kill any in-progress to not waste the time)
[15:05] <utkarsh21021> heey. Is there an example of a seed "inheriting" from another seed?
[15:12] <vorlon> utkarsh21021: STRUCTURE in any of the seed pods shows the inheritance; some of those seeds have associated Tasks, some do not
[15:17] <utkarsh21021> vorlon: is there any documentation around this?
[15:18] <vorlon> utkarsh21021: if there is it should be in germinate
[15:18] <utkarsh21021> I am looking for an example of seed (eg: server-minimal, desktop-minimal, et al), that'd be using other seeds as the base and then improving on top of it.
[15:21] <vorlon> utkarsh21021: an example of this might be the 'required' vs 'minimal' seeds in platform; required is a seed with no Task-* headers
[15:21] <vorlon> so its contents end up as direct dependencies of ubuntu-minimal when that package is germinated
[15:23] <vorlon> utkarsh21021: so e.g. you might move most of the contents of server-minimal into server-minimal-common and then have server-minimal and cloud-minimal both depend on it (in STRUCTURE) to have a common base definition that is itself not a metapackage
[15:27] <utkarsh21021> interesting!
[15:28] <utkarsh21021> I don't understand the headers (Task-*) at all, I'll look up to find more details about
[15:28] <utkarsh21021> also, to begin with, the cloud-minimal seed would look like:
[15:28] <utkarsh21021> * server-minimal
[15:28] <utkarsh21021> * openssh-server
[15:29] <utkarsh21021> that's what we want to try to see if images build and boot with that and then take it from there
[15:29] <vorlon> if you expect cloud-minimal to be a strict superset of server-minimal and you want both ubuntu-cloud-minimal and ubuntu-server-minimal to be installed as packages on the cloud images, yes
[15:30] <utkarsh21021> so perhaps server-minimal-common is not need at this point I believe, right?
[15:30] <vorlon> also you wouldn't list '* server-minimal' because that's not a package
[15:30] <vorlon> but '* ubuntu-server-minimal'
[15:32] <utkarsh21021> yes, correct. The metapackage.
[15:32] <vorlon> utkarsh21021: perhaps not needed, but there's certainly some stuff in server-minimal that you might think about not including in clouds; e.g. maybe multipath-tools doesn't belong?
[15:33] <utkarsh21021> yes!
[15:33] <vorlon> (and removing it has the nice benefit of not running that besotted daemon ;)
[15:33] <utkarsh21021> true.
[15:33] <vorlon> so based on past discussions, I would recommend you aim for a refactor into a -common
[15:35] <utkarsh21021> right now, we're using "server" as the base seed (ubuntu-server package in the cloud-image) and we'd like to go to server-minimal and then see how the seed behaves and then carve things out to make a cloud-minimal, should we have a lot of extra things
[15:36] <utkarsh21021> or do you think we should directly start with refactoring server-minimal into server-minimal-common and then make the two use it.
[15:36] <utkarsh21021> s/./?/ :)
[15:39] <vorlon> the latter is my suggestion.  you're going to wind up with a cloud-minimal package anyway, and there's no fundamental reason it should depend on server-minimal, the interdependencies can be left expressed in the seeds themselves
[15:47] <ricotz> LocutusOfBorg, hi, could you sync llvm-toolchain-16?
[15:52] <LocutusOfBorg> ricotz, why?
[15:53] <ricotz> LocutusOfBorg, I was looking for a clang-16 build to testing and noticed the recent debian upload
[15:56] <LocutusOfBorg> new britney run just started
[15:56] <LocutusOfBorg> lets see
[15:56] <LocutusOfBorg> ricotz, can't you upload in a ppa?
[15:56] <LocutusOfBorg> its an rc1
[15:56] <LocutusOfBorg> not sure if we should have it
[15:57] <LocutusOfBorg> vorlon, I think the uwsgi NBS cleanup didn't work?
[15:59] <vorlon> LocutusOfBorg: possibly it raced the publisher
[15:59] <LocutusOfBorg> oh... sad
[15:59] <LocutusOfBorg> also colord, what is preventing its migration? colord-sensor-argyll/i386 has unsatisfiable dependency
[16:00] <vorlon> $ m -s lunar-proposed -S uwsgi|grep 2.0.20-4build1
[16:00] <vorlon> $
[16:00] <vorlon> (m == rmadison)
[16:00] <ricotz> LocutusOfBorg, ok, I assumed llvm rc1 releases are usually uploaded
[16:00] <LocutusOfBorg> rmadison -u ubuntu uwsgi-plugin-jvm-openjdk-11 -s lunar
[16:00] <LocutusOfBorg>  uwsgi-plugin-jvm-openjdk-11 | 2.0.20-4 | lunar/universe | amd64, arm64, armhf, ppc64el, s390x
[16:00] <LocutusOfBorg> vorlon, ^^
[16:01] <vorlon> LocutusOfBorg: if it's dropped on all archs, it shouldn't need NBS removal from the release pocket until after the migration
[16:02] <LocutusOfBorg> oh ok
[16:02] <LocutusOfBorg> so it was blocked by tests not finish
[16:06] <LocutusOfBorg> so this run might be the good one to see big migration?
[16:06]  * LocutusOfBorg crosses fingers
[16:21] <utkarsh21021> vorlon: thank you! \o/
[16:24] <utkarsh21021> also, a fundamental question: if I want to depend on a seed, the (cleanest) way is to depend on its respective metapackage, no?
[16:24] <utkarsh21021> for eg: if I create a seed: cloud-minimal and I want to depend on server-minimal, the way to do so would be to add "* ubuntu-server-minimal" to it, no? or is there another way to inherit things?
[16:25] <utkarsh21021> do note that I'll go with the splitting route (server-minimal-common), but I am just asking the above to get my basics right. :)
[16:25] <vorlon> utkarsh21021: yes you would both declare the dependency on the metapackage and list the relationship in STRUCTURE
[16:27] <utkarsh21021> got it, thank you!
[16:40] <LocutusOfBorg> lets see what now is preventing migration
[17:22] -queuebot:#ubuntu-release- New binary: icu [amd64] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:22] -queuebot:#ubuntu-release- New binary: icu [i386] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:27] -queuebot:#ubuntu-release- New binary: icu [ppc64el] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:27] -queuebot:#ubuntu-release- New binary: icu [s390x] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:30] <bdmurray> ubuntu-sru: I'm looking at the update-manager SRU
[17:30] <ahasenack> update-notifier you mean?
[17:31] <ahasenack> we talked about it in standup, it looks like (to be verified) that most crashes are in the older version, not the new one
[17:31] <bdmurray> No, I mean update-manager per seb's ping
[17:31] <jbicha> ugh, graphviz rebuild is now in the way of the py3.11 migration
[17:31] <ahasenack> ah, ok
[17:32] <bdmurray> re update-notifier do you mean that the version numbering in the crash is wrong?
[17:33] <ahasenack> I have to look again, but the report was confusing. Even when you select a version in the dropdown menu, it shows crashes from other versions
[17:34] <bdmurray> Well if its something wonky with the Error Tracker or the data in it I'd be keen to hear / talk about it
[17:34] <ahasenack> so from here https://people.canonical.com/~ubuntu-archive/phased-updates.html
[17:34] <ahasenack> I click on the jammy +120 link
[17:34] <ahasenack> which lands me in https://errors.ubuntu.com/?release=Ubuntu%2022.04&package=update-notifier&period=day&version=3.192.54.5
[17:34] <ahasenack> the table however shows crashes from all over the place
[17:35] <ahasenack> then I click  on the top one, with most crashes
[17:35] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (jammy-proposed) [1:22.04.13]
[17:35] <ahasenack> and land at https://errors.ubuntu.com/problem/6eb58ea52b7701b979663a5c7bed4a8bac1c762d
[17:35] <ahasenack> so I started with jammy, 3.192.54.5
[17:36] <ahasenack> then I find the first one of that version, and now I'm looking at an actual crash from that version
[17:37] <ahasenack> that just has a list of libraries, and that it was a segfault, no furter useful info so far
[17:37] <bdmurray> Looking at the bucket / problem url my question would be is 54.4 crashier than other versions?
[17:37] -queuebot:#ubuntu-release- New binary: icu [armhf] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:37] <bdmurray> er 54.5
[17:38] <ahasenack> you mean this? https://errors.ubuntu.com/problem/6eb58ea52b7701b979663a5c7bed4a8bac1c762d
[17:39] <bdmurray> yes
[17:39] <ahasenack> that particular page lists this error for a multitude of versions of update-notifier
[17:39] <ahasenack> what does "<number> U" mean? The "U" in particular?
[17:39] <bdmurray> right and is it happening more often with the latest version?
[17:39] <bdmurray> U is the pocket the package is from
[17:40] <ahasenack> only .3 is the most recent previous version listed, .4 isn't there. .3 has 784, .5 (latest) has 305
[17:40] <ahasenack> the release version (3.192.54) has a staggering 17k crashes
[17:41] <ahasenack> the graph for 22.04 on https://errors.ubuntu.com/problem/6eb58ea52b7701b979663a5c7bed4a8bac1c762d is raising, but the values are zero for all datapoints, it must be an average over a large amount of samples
[17:42] <bdmurray> I would put little stock in the graph
[17:42] <ahasenack> there are crashes reported today on the release version (22.04 3.192.54)
[17:42] -queuebot:#ubuntu-release- New binary: icu [arm64] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[17:42] <ahasenack> ah, the page loads more if you scroll down
[17:43] <jbicha> kanashiro[m]: please don't do more rebuilds for the ruby transition until the massive python3-defaults transition makes it out of -proposed
[17:44] <vorlon> yeah, reverting graphviz
[17:45] <vorlon> kanashiro[m]: you need to pay attention to what packages are already in -proposed before you upload them, these uploads are actively setting back progress on the migration
[17:46] <vorlon> I have posted rebuild scripts before to ubuntu-devel that do this analysis
[17:46] <jbicha> vorlon: ignition-math also interrupts. not sure about kamailio and grpc
[17:46] <vorlon> ok looking
[17:48] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.13 => 1:20.04.10.14] (core)
[17:49] <kanashiro[m]> vorlon: sorry, my script is not smart enough to consider that (and I might have missed your script in ubuntu-devel). I am stopping the rebuild of non-ruby libraries (ruby-*)
[17:49] <vorlon> kamailio does via protobuf+libphonenumber
[17:50] <bdmurray> I reuploaded update-manager for focal due to debdiff noise
[17:53] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (focal-proposed) [1:20.04.10.14]
[17:55] <vorlon> kanashiro[m]: https://lists.ubuntu.com/archives/ubuntu-devel/2022-April/041994.html and there's the associated question about where such a tool should be distributed so people can find it :/
[17:58] <kanashiro[m]> vorlon: thank you for the link, I am saving the script locally for the future
[18:04] <tsimonq2> vorlon: IMO ubuntu-dev-tools
[18:05] <vorlon> tsimonq2: except ubuntu-dev-tools is being maintained in Debian (^_^) and doesn't get SRUed
[18:05] <vorlon> so it's fine to say "ubuntu-dev-tools" except for the bit where ubuntu-dev-tools as a whole is currently badly served by being a .deb
[18:15] <vorlon> reverts are published; killed current britney run
[18:16] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.10.14]
[18:17] <tsimonq2> vorlon: I'm not sure I see it going away as a deb but a snap could be useful... I wonder the same for ubuntu-archive-tools. I also wonder how common local modifications are
[18:18] <vorlon> ubuntu-archive-tools is less general audience and also takes frequent commits because of the i386 whitelisting stuff, I'm not keen to move that to a snap
[18:21] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.17]
[18:22] -queuebot:#ubuntu-release- New binary: icu [riscv64] (lunar-proposed/main) [72.1-3ubuntu1] (core, i386-whitelist)
[18:28] <jbicha> vorlon: do you think grpc might need to be reverted too?
[18:28] <vorlon> jbicha: it didn't look like it to me, I haven't reverted it yet
[18:30] <LocutusOfBorg> vorlon, missing ignition-math
[18:30] <LocutusOfBorg> Implicit dependency: python3-defaults ignition-math (not considered)
[18:31] <vorlon> LocutusOfBorg: see above discussion
[18:32] <vorlon> eh except somehow when I copied ignition-math back I copied back the same broken version
[18:32] <vorlon> sigh
[18:34] <LocutusOfBorg> vorlon, thanks for understanding :) I did read the backlog, but I found the wrong version being in proposed and you said you restarted britney already, this is why I asked :)
[18:34] <LocutusOfBorg> keep up the good work!
[18:45] <bdmurray> ginggs: Do you have a process for rerunning tests that have always failed? e.g. I've just added r-cran-rstanarm to big_packages but retry-autopkgtest-regressions won't find it because its always failed
[18:47] <bdmurray> Oh, just use a trigger of migration-reference/0 ...
[20:02] <LocutusOfBorg> this britney run looks like failed to do the job
[20:02] <LocutusOfBorg> lets hope for next one :)
[20:25] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (jammy-proposed) [0.99.22.6]
[20:27] <vorlon> seems it didn't pick up the published graphviz either.  Yes, fingers crossed for the next one
[20:27] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (focal-proposed) [0.99.9.11]
[20:30] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.21]
[20:36] <bdmurray> ^ I've reviewed software-properties too
[20:39] <LocutusOfBorg> vorlon, does your script work if the system where its run is not a devel release?
[20:40] <LocutusOfBorg> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_"$release"_*Packages"
[20:40] <LocutusOfBorg> can't we fix the script to download such files maybe? WDYT?
[20:42] <vorlon> LocutusOfBorg: probably better to make it use chdist?
[20:43] <vorlon> LocutusOfBorg: but I always run it in a chroot, which ensures the uploads are also prepared in the same environment as the devel series
[20:43] <tsimonq2> vorlon: what's the license on your script? ;P
[20:45] <vorlon> tsimonq2: GPL3
[21:02] <LocutusOfBorg> vorlon, sigh
[21:03] <LocutusOfBorg> grpc 1.51.1-3build2
[21:03] <LocutusOfBorg> is it a problem w.r.t. migration?
[21:03] <LocutusOfBorg> oh backlog
[21:04] <vorlon> LocutusOfBorg: it doesn't look like it to me.  protobuf is a lib transition, old soname should be retained and grpc in release pocket should still be installable?
[21:05] <LocutusOfBorg> maaaaaaybe, who knows?
[21:05] <LocutusOfBorg> migrating libphonenumber8/8.12.57+ds-3build2/amd64 to testing makes kamailio-phonenum-modules/5.6.2-1build2/amd64 uninstallable
[21:05] <LocutusOfBorg> this wasn't there...
[21:05] <vorlon> should be addressed by the sync of the previous kamailio
[21:06] <LocutusOfBorg> lets cross fingers
[21:35] <vorlon> LocutusOfBorg: britney is definitely /trying/ to migrate it
[21:36] <vorlon> (which is why this run is longer)
[21:36] <vorlon> I: [2023-02-03T21:35:36+0000] -     got: 682+0: a-121:a-125:a-116:i-1:p-105:r-108:s-106
[21:36] <vorlon> I: [2023-02-03T21:35:36+0000] -     * arm64: gqrx-sdr, i2masschroq, libgnuradio-analog3.10.3, libgnuradio-blocks3.10.3, libgnuradio-digital3.10.3, libgnuradio-fft3.10.3, libgnuradio-filter3.10.3, libgnuradio-network3.10.3, libgnuradio-runtime3.10.3, libpappsomspp-widget0, msxpertsuite, msxpertsuite-minexpert, xtpcpp
[21:44] <vorlon> fwiw glibc has been uploaded; so if anything else needs rebuilt for python3-defaults to go through, it may get entangled and require some more finessing
[21:48] <LocutusOfBorg> did it migrate?
[21:49] <LocutusOfBorg> W: [2023-02-03T21:40:40+0000] - failed: amgcl is not a valid candidate (or it already migrated)
[21:49] <LocutusOfBorg> WTF
[21:50] <LocutusOfBorg> oh... it went through
[21:50] <LocutusOfBorg> if I got it right
[21:54] <vorlon> yes it migrated
[21:54] <LocutusOfBorg> YAY!
[21:54] <vorlon> I: [2023-02-03T21:40:37+0000] - final:
[21:54] <vorlon> -libgdal31/armhf,-libgit2-1.3/armhf,-libgit2-1.3/ppc64el,-libgit2-1.3/s390x,-libgnuradio-analog3.10.3/amd64,-libgnuradio-analog3.10.3/arm64,-libgnuradio-analog3.10.3/armhf,-libgnuradio-blocks3.10.3/amd64,-libgnuradio-blocks3.10.3/arm64,-libgnuradio-blocks3.10.3/armhf,-libgnuradio-digital3.10.3/amd64,-libgnuradio-digital3.10.3/arm64,-libgnuradio-digital3.10.3/armhf,-libgnuradio-fft3.10.3/amd64,-libgn
[21:54] <vorlon> uradio-fft3.10.3/arm64,-libgnuradio-fft3.10.3/armhf,-libgnuradio-filter3.10.3/amd64,-libgnuradio-filter3.10.3/arm64,-libgnuradio-filter3.10.3/armhf,-libgnuradio-network3.10.3/amd64,-libgnuradio-network3.10.3/arm64,-libgnuradio-network3.10.3/armhf,-libgnuradio-pmt3.10.3/amd64,-libgnuradio-pmt3.10.3/arm64,-libgnuradio-pmt3.10.3/armhf,-libgnuradio-runtime3.10.3/amd64,-libgnuradio-runtime3.10.3/arm64,-l
[21:54] <vorlon> ibgnuradio-runtime3.10.3/armhf,-libgsoap-2.8.117/amd64,-libhmat-oss2/amd64,-libhmat-oss2/arm64,-libhmat-oss2/armhf,-libhmat-oss2/riscv64,-libhmat-oss2/s390x,-libldap-2.5-0/i386,-liblimesuite20.10-1/amd64,-liblimesuite20.10-1/arm64,-liblimesuite20.10-1/armhf,-liblimesuite20.10-1/ppc64el,-liblimesuite20.10-1/riscv64,-libopenimageio2.3/amd64,-libopenimageio2.3/arm64,-libopenimageio2.3/armhf,-libopenima
[21:54] <vorlon> geio2.3/ppc64el,-libopenimageio2.3/riscv64,-libopenimageio2.3/s390x,-libosmocore18/amd64,-libosmocore18/arm64,-libosmocore18/armhf,-libosmocore18/ppc64el,-libosmocore18/s390x,-libosmogsm17/amd64,-libosmogsm17/arm64,-libosmogsm17/armhf,-libosmogsm17/ppc64el,-libosmogsm17/s390x,-libpoppler123/armhf,-libprimesieve10/amd64,-libprimesieve10/arm64,-libprimesieve10/armhf,-libprimesieve10/riscv64,-libprimes
[21:54] <vorlon> ieve10/s390x,-librte-eal22/amd64,-librte-eal22/arm64,-librte-eal22/ppc64el,-librte-ethdev22/amd64,-librte-ethdev22/arm64,-librte-ethdev22/ppc64el,-librte-hash22/amd64,-librte-hash22/arm64,-librte-hash22/ppc64el,-librte-kvargs22/amd64,-librte-kvargs22/arm64,-librte-kvargs22/ppc64el,-librte-mbuf22/amd64,-librte-mbuf22/arm64,-librte-mbuf22/ppc64el,-librte-mempool22/amd64,-librte-mempool22/arm64,-librte
[21:55] <vorlon> -mempool22/ppc64el,-librte-meter22/amd64,-librte-meter22/arm64,-librte-meter22/ppc64el,-librte-net22/amd64,-librte-net22/arm64,-librte-net22/ppc64el,-librte-rcu22/amd64,-librte-rcu22/arm64,-librte-rcu22/ppc64el,-librte-ring22/amd64,-librte-ring22/arm64,-librte-ring22/ppc64el,-librte-telemetry22/amd64,-librte-telemetry22/arm64,-librte-telemetry22/ppc64el,-libuhd4.2.0/amd64,-libuhd4.2.0/arm64,-libuhd4
[21:55] <vorlon> .2.0/armhf,-libuhd4.2.0/ppc64el,-libuhd4.2.0/riscv64,-libuhd4.2.0/s390x,adacgi,adasockets,ahven,akonadi,amgcl,analitza,android-platform-frameworks-base,anet,angelfish,apbs,apertium,apertium-lex-tools,apriltag,astra-toolbox,astroidmail,astrometry.net,autofdo,avogadrolibs,berkeley-express,blueman,borgbackup,borgbackup2,bornagain,brian,broker,btrfs-progs,bup,cegui-mk2,ceph,cg3,chatty,chemps2,clementine
[21:55] <vorlon> ,cluster3,compiz,createrepo-c,cryptominisat,cubemap,cura-engine,cwiid,dbusada,dde-qt5integration,deepin-image-viewer,deepin-qt5dxcb-plugin,deepin-terminal,device-tree-compiler,displaycal-py3,distcc,drgn,dtkcore,dtkgui,dtkwidget,dune-common,dune-functions,dune-geometry,dune-grid,dune-grid-glue,dune-istl,dune-localfunctions,dune-typetree,dune-uggrid,dupeguru,enki-aseba,evolution,evolution-data-server,
[21:55] <vorlon> evolution-ews,faiss,fcitx-qt5,fcitx5-qt,fife,flightgear,fontforge,freecad,freesas,gammaray,gcin,gdcm,geis,gemmi,genomicsdb,gensio,getfem,gfal2-bindings,gi-docgen,gnat,gnss-sdr,gnucash,gnudatalanguage,gnuradio,gobject-introspection,gprbuild,gr-air-modes,gr-fosphor,gr-funcube,gr-gsm,gr-hpsdr,gr-iqbal,gr-limesdr,gr-osmosdr,gr-radar,gr-rds,gr-satellites,graphviz,grass,grpc-java,gst-plugins-bad1.0,gtk4,h
[21:55] <vorlon> alide,haruna,harvest-tools,heartbeat,hedgewars,hfst,hime,horizon-eda,hplip,hugin,ignition-fuel-tools,ignition-fuel-tools4,ignition-gazebo,ignition-gui,ignition-launch,ignition-math,ignition-msgs,ignition-msgs5,ignition-sensors,ignition-transport,ignition-transport8,imath,insighttoolkit4,isospec,itinerary,jack-mixer,kaidan,kamailio,ki18n,kicad,kiconthemes,kineticstools,kirigami-addons,kirigami2,kitin
[21:56] <LocutusOfBorg> vorlon is our new BAAB (Britney as a Bridge)
[21:56] <LocutusOfBorg> :)
[21:56] <LocutusOfBorg> SCNR
[21:57] <sarnold> that was less horrific than I feared :)
[21:58] <vorlon> the lp copies are happening now, enjoy your email
[21:58]  * arraybolt3 's head starts spinning trying to figure out what flags are being set on who
[21:58] <sarnold> oh bother I didn't realize i +q but -b :( sorry there
[21:59] <sarnold> arraybolt3: apparently me neither, lol
[21:59] <sarnold> definitely lunchtime
[21:59] <sarnold> (and the flood continued to ops due to +z, there was less of it than I feared, heh)
[22:00] <LocutusOfBorg> might be a good time to autosync?
[22:00] <arraybolt3> \o/ Woohoo! Did that just unstick qtbase too?
[22:01] <LocutusOfBorg> it did indeed
[22:01] <LocutusOfBorg> also protobuf, gsoap, and a ton of stuff
[22:03] <LocutusOfBorg> also gnat indeed!
[22:11] <bdmurray> I uploaded glibc on behalf of schopin a little bit ago
[22:27] <vorlon> LocutusOfBorg: no autosync yet; as usual there were a collection of packages that failed to copy due to launchpad api overload, so we should let a second run through to clean everything up before copying more in
[22:28] <vorlon> so what happened to cause all these rust uninstallables?
[22:28] <vorlon> smells like a wrong removal
[22:32] <vorlon> ah heh it was my removal of the NBS librust-ahash+compile-time-rng-dev that broke everything
[22:34]  * vorlon shakes his fist at reverse-depends not handling virtual packages
[22:35] <tumbleweed> do you have a strategy for hanlding them in mind?
[22:36] <tumbleweed> because multiple providers can often satisfy the virtual package
[22:37] <vorlon> tumbleweed: I would rather they report too much than too little; reverse-depends already doesn't distinguish alternative depends that might be satisfied by another package
[22:37] <tumbleweed> that's true
[22:39] <vorlon> anyway, in this case I manually checked for reverse-build-depends but not reverse-depends; I'm confused by why the first wasn't sufficient, but I guess lesson learned
[22:42] <vorlon> copied graphviz, protobuf, ignition-math, kamailio back to -proposed (kanashiro[m])
[22:43] <vorlon> now afk
[22:56] <kanashiro[m]> vorlon: thank you!
[23:13]  * Eickmeyer[m] prays for a successful Ubuntu Studio build tomorrow with this migration
[23:23] -queuebot:#ubuntu-release- New binary: tiff [amd64] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:23] -queuebot:#ubuntu-release- New binary: tiff [i386] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:25] -queuebot:#ubuntu-release- New binary: tiff [ppc64el] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:25] -queuebot:#ubuntu-release- New binary: tiff [s390x] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:25] -queuebot:#ubuntu-release- New binary: tiff [armhf] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:26] -queuebot:#ubuntu-release- New binary: tiff [arm64] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)
[23:59] -queuebot:#ubuntu-release- New binary: tiff [riscv64] (lunar-proposed/main) [4.5.0-4ubuntu1] (core, i386-whitelist)