[00:04] <plugwash> how do I request a package is removed from Ubuntu?
[00:06] <tumbleweed> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removals
[01:15] <arraybolt3> plugwash: What package are you wanting removed? I might be able to help.
[01:16] <arraybolt3> (I can file bugs, or possibly fix whatever's wrong with it if it doesn't need removed but does need a fix.)
[01:16] <plugwash> the package is rust-rustls-0.20, it was removed from sid some time ago but is hanging around in Ubuntu for some reason and is blocking the migration of the new rust-ring out of proposed.
[01:23] <plugwash> I filed https://bugs.launchpad.net/ubuntu/+source/rust-rustls-0.20/+bug/2045596
[01:23] -ubottu:#ubuntu-devel- Launchpad bug 2045596 in rust-rustls-0.20 (Ubuntu) "rust-rustls-0.20 should be removed." [Undecided, New]
[01:29] <arraybolt3> plugwash: Ah. sounds like you have it taken care of already then.
[01:45] <mwhudson> i subscribed ~ubuntu-archive to the bug btw
[08:39] <xypron> lua-nvim and nvim have a cyclic build dependency leading to not building for riscv64. On the lua-nvim side the build dependency: "neovim <!nocheck>". How can we set build profile nocheck when uploading to proposed?
[08:41] <schopin> xypron: I'd just upload a version of lua-nvim with `neovim <!nocheck> [!riscv64]` and the tests disabled on riscv64 (not even sure that's needed though?) to break the cycle, and then revert that once it's bootstrapped.
[08:43] <xypron> schopin: https://wiki.debian.org/BuildProfileSpec describes that an environment variable  DEB_BUILD_PROFILES is used to control the build.
[08:45] <schopin> xypron: yes, and that's very useful when you build stuff locally or do archive-wide test rebuilds, but I'd wager you can't use a custom profile for a single package in the archive.
[10:56] <xypron> schopin: see LP #2045634. A ppa build worked fine.
[10:56] -ubottu:#ubuntu-devel- Launchpad bug 2045634 in lua-nvim (Ubuntu) "Missing riscv64 build due to cyclic dependency" [Undecided, New] https://launchpad.net/bugs/2045634
[12:07] <kjerome1> Hi everyone, just wondering - is it common to resubscribe sponsors if they were unsubscribed but the bug report went stale?
[13:34] <schopin> kjerome1: if the sponsors were unsubscribed it's usually because there were some actionable feedback on the debdiff/branch. Resubscribing them without any other change to the bug status is probably not the right thing to do :)
[13:34] <schopin> what's the bug on question?
[13:49] <kjerome1> schopin: this is the bug - https://bugs.launchpad.net/ubuntu/+source/cups-browsed/+bug/2028172
[13:49] -ubottu:#ubuntu-devel- Launchpad bug 2028172 in cups-browsed (Ubuntu) "Cups-browsed cannot bind to port 631 as non-root user on Ubuntu 23.04" [Undecided, Confirmed]
[14:04] <schopin> kjerome1: As far as I can see Simon's comment still applies: this is a raw patch, not something that's readily uploadable, so out of the scope of ubuntu-sponsors. Till will likely handle this in time, but please be patient. His last comment is not even a week old, it's a bit premature to call the bug "stale" :)
[16:30] <ogayot> dbus 1.14.10-3 in Debian added a dependency on usr-is-merged (>= 38~). While src:usrmerge is in main in Ubuntu, usr-is-merged is currently in universe. How does that work? And also, would moving usr-is-merged to main mandata a MIR of some sort?
[16:31] <ogayot> s/mandata/mandate/
[16:35] <schopin> It sounds like usr-is-merged should be seeded.
[16:35] <tsimonq2> I defer any judgement on usr-is-merged, but if you're looking to move things forward and not have this merge hung up on a MIR process, I'd revert that in Ubuntu.
[16:36] <tsimonq2> (No idea if it's a merge or sync, didn't look yet. :))
[16:36] <schopin> My guess is we're talking merge.
[16:36] <tsimonq2> Right you are: https://launchpad.net/ubuntu/+source/dbus/1.14.10-1ubuntu1
[16:37]  * schopin vaguely remembers having a dbus merge assigned to him in a previous cycle. And pawning it off somehow to someone else.
[16:37] <tsimonq2> Version: 1.14.10-3 Changed-By: Simon McVittie <smcv@debian.org>
[16:37] <tsimonq2> We've reached Peak Simon. :P
[16:41] <ogayot> tsimonq2: I don't think it's critical to rush the dbus merge right now (especially because 1.15.x is already in experimental). We would need to merge usrmerge 38 to make dbus 1.14.10-3ubuntu1 installable anyway.
[16:42] <ogayot> schopin: you mean seeding usr-is-merged would automatically move it to main?
[16:43] <schopin> ogayot: I mean that it would make sense for us to seed this to have it installed on all our systems, since this is true on all Ubuntu systems.
[16:44] <ogayot> schopin: that's fair.
[16:45] <schopin> ogayot: for your immediate problem, I'd remove the dependency in our delta, and consult the elders ;)
[16:46] <schopin> ogayot: I'd open a new bug on dbus and tag it rls-nn-incoming to discuss it in our thursday meeting.
[16:47] <ogayot> schopin: good idea, I'll go ahead and do that.
[16:47] <dbungert> @pilot in
[16:48] <schopin> slyon: with your MIR hat on, have a look at the last 15mn backlog ;)
[16:51] <slyon> schopin: ogayot: usr-is-merged seems to be an empty meta-package. It's source package src:usrmerge is already in main
[16:52] <schopin> does that mean we can just ask an AA to promote it, no paperwork?
[16:52] <slyon> so I'd say this doesn't need a MIR, as there is no new code. Maybe this new binary was added after the source package got promoted. You should not block on this.
[16:52] <slyon> I don't think paperwork would be involved. It might show up as a component-mismatch, but should be resolved on the fast-path, by asking an AA.
[16:53] <ogayot> slyon: excellent, thanks!
[16:53] <schopin> I had assumed it was a new source package, I should have checked. -_-
[16:54] <ogayot> schopin: I should have made it more obvious :)
[16:54] <slyon> ogayot: schopin: thanks for taking care of those details!
[18:24] <ogayot> :q
[21:09] <arraybolt3> bdmurray: If you're around, do you happen to know  where to download the britney-indexes-ppa script referenced in https://wiki.ubuntu.com/ProposedMigration/LocalSetup ? The download link in the wiki no longer works and I need that script for testing a package update.
[21:10] <dbungert> @pilot out
[21:15] <bdmurray> arraybolt3: nobody knows. What exactly are you trying to do?
[21:16] <arraybolt3> bdmurray: Set up a local Britney instance in a VM that uses a PPA as if it were the -proposed pocket so I can get a list of autopkgtest links so I can make sure a new version of a library doesn't clog up an entire network of reverse dependencies once it's uploaded.
[21:17] <bdmurray> arraybolt3: just query the autopkgtest.db for the package as a trigger?
[21:17] <arraybolt3> From my conversation with tsimonq2 I thought I'd need to test every reverse dependency of the package in question against a PPA, and the Britney setup would help me know what all needed testing? Perhaps he misunderstood me or I misunderstood him.
[21:18] <arraybolt3> It would probably be best to test the entire dependency network (all rdeps of the new package (several libraries in signond + all rdeps of those + all rdeps of those and so on).
[21:19] <arraybolt3> The new version of signond I'm hoping to sync from Debian is a lot newer and may or may not have API/ABI breaking changes, thus my desire to test everything before having a sponsor upload.
[21:20] <arraybolt3> bdmurray: how would I do that querying you're mentioning?
[21:25] <bdmurray> arraybolt3: something like this https://pastebin.ubuntu.com/p/fSYvhRYxFf/
[21:29] <bdmurray> although that result is a false positive b/c by regex was too general and caught signon-kwallet-extension
[21:32] <arraybolt3> bdmurray: and is there some place where the autopkgtest.db is publicly available for download?
[21:32] <arraybolt3> nvm found it
[21:32] <arraybolt3> oh grief it's huge :P
[21:32] <arraybolt3> alrighty, thanks for the advice!