[06:56] <LocutusOfBorg> vpa1977, sponsored.
[06:56] <LocutusOfBorg> in Debian :)
[06:59] <vpa1977> Thank you =)
[07:04] <LocutusOfBorg> I also uploaded as build1 in Ubuntu
[07:05] <LocutusOfBorg> <BTS> fdroidserver 2.2.1-1.1 uploaded by Gianfranco Costamagna (locutusofborg) (Closes: #1040629) https://tracker.debian.org/fdroidserver
[07:05] <LocutusOfBorg> it will autosync in some h
[08:04] <juliank> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: juliank, seb128
[08:06] <juliank> seb128: you may want to pilot out 😄
[08:06] <seb128> juliank, oh right, thanks
[08:06] <seb128> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: juliank
[08:21] <dviererbe> Hello, can someone review my Merge Proposal to merge dash 0.5.12-6 from debian? (See https://code.launchpad.net/~dviererbe/ubuntu/+source/dash/+git/dash/+merge/446503)
[08:21] <dviererbe> It's a really trivial merge, so it should not take much time to review it.
=== cpaelzer_ is now known as cpaelzer
[08:53] <mirespace> Hi, Still working on dpdk MRE... I need someone that could trigger the following test for me (Thanks in advance :) ):
[08:53] <mirespace>     + @amd64: https://autopkgtest.ubuntu.com/request.cgi?release=lunar&package=dpdk&arch=amd64&trigger=dpdk%2F22.11.2-0ubuntu0.23.04.1&ppa=mirespace%2Fmre-dpdk-2026351♻️
[08:53] <mirespace>     + @arm64: https://autopkgtest.ubuntu.com/request.cgi?release=lunar&package=dpdk&arch=arm64&trigger=dpdk%2F22.11.2-0ubuntu0.23.04.1&ppa=mirespace%2Fmre-dpdk-2026351♻️
[08:53] <mirespace>     + @ppc64el: https://autopkgtest.ubuntu.com/request.cgi?release=lunar&package=dpdk&arch=ppc64el&trigger=dpdk%2F22.11.2-0ubuntu0.23.04.1&ppa=mirespace%2Fmre-dpdk-2026351♻️
[08:54] <mirespace> I ran it locally and I got a memory allocation error in a few ones (hoping that it was caused by my machine)
[08:57] <cpaelzer> mirespace: typo ? - Unknown PPA mirespace/mre-dpdk-2026351
[08:57] <cpaelzer> or a consequence of the changes to who can trigger test restarts
[08:58] <mirespace> cpaelzer: _checking.... but I ran the same command for jammy, mpw changing only the release_
[09:00] <mirespace> s/mpw/now/
[09:00] <cpaelzer> yeah and https://launchpad.net/~mirespace/+archive/ubuntu/mre-dpdk-2026351 looks correct relative to the URLs you provides
[09:01] <mirespace> :-/
[09:01] <cpaelzer> I'd ask paride and bdmurray ^^ to have a look if that might be due to the changes for ~autopkgtest-requestors
[09:02] <mirespace> Ok, thankyou
[09:03] <cpaelzer> I'm trying a different PPA of mine I used in the past
[09:04] <cpaelzer> hmm, no the other one works
[09:04] <cpaelzer> trying to create my own links for yours
[09:04] <mirespace> :(
[09:05] <cpaelzer> ok, now I have one of yours restarted
[09:05] <cpaelzer> I need to disect the URl parameters, give me a bit
[09:06] <mirespace> sure
[09:15] <cpaelzer> ok, found it - invisible UTF magic
[09:16] <cpaelzer> paride: bdmurray: ^^ no need to look further
[09:56] <juliank> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: N/A
[09:57] <juliank> Sorry I was a bit late to pilot in
[09:57] <juliank> dviererbe: I'll leave that to cpaelzer for tomorrow's patch piloting with the idea of focusing on cross-team sponsoring
[09:58] <dviererbe> juliank: Okay, thanks for telling me :)
[09:58] <juliank> maybe someone else picks it up first
[09:59] <cpaelzer> juliank: hehe, you leave it to the one that already complained (but learned since then) it might be a bit too much cross-team :-)
[09:59] <juliank> but cross team sponsoring makes the dmb happy, so focusing on that for stuff following the ~ubuntu-sponsors process
[10:00] <juliank> cpaelzer: So I don't usually touch foundations sponsorship requests via the process during my shift, but I would sponsor them internally outside the process. I could do here because I haven't sponsored anything from dominik or vladimir yet, but I also need to leave :(
[10:01] <cpaelzer> I'm really fine
[10:01] <cpaelzer> didn't want to hold you back
[10:02] <juliank> There's like 4 actionable items in the backlog now
[10:04] <dviererbe> my merge proposal is more than a week old, so i don't think that a day makes a difference ^^
[11:11] <rbasak> cpaelzer: o/ how many patch piloting sessions have you done so far?
[11:11] <rbasak> I thought I was going to do one the other day but you were doing it. Did we just swap one, or all?
[11:11] <rbasak> Because there's one tomorrow but it's on my calendar.
[11:12] <rbasak> But then on Monday 31st it looks like you're taking my slot again?
[11:13] <rbasak> I don't mind either way. Just want to know which ones I'm doing. Because right now it looks like I don't do any, and that seems wrong :)
[11:24] <cpaelzer> rbasak: we did swap one, this would be my third session
[11:24] <cpaelzer> rbasak: Monday 31st is what I thought I traded, I'm off that day
[11:26] <rbasak> cpaelzer: I thought you took 19 June instead of me.
[11:26] <rbasak> cpaelzer: then on 10 July I thought it was my session but you did it
[11:26] <cpaelzer> I see, there is the double
[11:26] <cpaelzer> indeed
[11:26] <rbasak> cpaelzer: and on 31 July your calendar still has you taking mine.
[11:27] <rbasak> I mean if you want to take all of mine then I'm fine with that :-P
[11:27] <cpaelzer> I fixed 31st now to correctly state you take over from me
[11:27] <cpaelzer> as I'm off I couldn't do anything there :-)
[11:27] <cpaelzer> I'm fine doing the one tomorrow even thought I think this would indeed be yours - it is a nice pre-sprint contrast
[11:28] <rbasak> cpaelzer: it's still recurring - see 21 August
[11:28] <cpaelzer> ah calendars, curse of modern mankind ... on it
[11:29]  * rbasak isn't sure he's actually done a shift in 2023 yet!
[11:29] <cpaelzer> ok, here is the default
[11:30] <cpaelzer> I usually have the Fri slot, you the one on Mondays
[11:30] <cpaelzer> we traded one for when I'm off on 31st
[11:30] <rbasak> OK
[11:30] <cpaelzer> but by overzealous exitement I took it over from you when we are supposed to trade
[11:30] <rbasak> :)
[11:30] <cpaelzer> that is why in the past you haven#t but i have done one
[11:30] <cpaelzer> so 31st is yours (taking over from me - thanks)
[11:31] <cpaelzer> tomorrow is mine as it normally would be
[11:31] <cpaelzer> and after that all should be normal (you Mondays, me Fridays - all on 6 week pattern)
[11:31] <ogayot> rbasak: hi, I'm working on the dbus merge from Debian unstable with git-ubuntu. It looks like the debian/sid branch got updated with stuff from bookworm: https://git.launchpad.net/ubuntu/+source/dbus/commit/?h=applied/debian/sid&id=af24fc9e8b84d7f85659f1fee9d8dc5084f0a610 Is this expected?
[11:31] -ubottu:#ubuntu-devel- Commit af24fc9 in ubuntu/+source/dbus "1.14.8-2~deb12u1 (patches applied) applied/1.14.8-2_deb12u1 applied/debian/sid"
[11:32] <cpaelzer> rbasak: let us just remember I have one good with you in case my next conflict comes up :-)
[11:33] <rbasak> ogayot: that seems surprising but according to https://launchpad.net/debian/+source/dbus/+publishinghistory it got published in Sid, so that's what git-ubuntu is reflecting
[11:33] <rbasak> cpaelzer: ack. Thanks!
[11:33] <rbasak> cpaelzer: well, two I think!
[11:35] <rbasak> cjwatson: ^ (dbus) this seems surprising to me. https://tracker.debian.org/pkg/dbus doesn't seem to suggest that it was published in sid, but that's what Launchpad says. Is this expected?
[11:36]  * rbasak is heading to lunch now. Back later.
[11:36] <ogayot> rbasak: fair enough. I will wait before force-updating the new/debian tag I guess - we we understand what's going on
[11:38] <cjwatson> $ curl -s https://deb.debian.org/debian/dists/sid/main/source/Sources.xz | xzcat | grep-dctrl -nsVersion -PX dbus
[11:38] <cjwatson> 1.14.6-1
[11:38] <cjwatson> rbasak: ^
[11:38] <cjwatson> 1.14.8-2~deb12u1
[11:38] <cjwatson> 1.14.8-2
[11:39] <cjwatson> So all three of those are currently recorded as being Published in debian/sid, which seems like an accurate reflection of reality
[11:39] <cjwatson> How does the importer handle the case where multiple versions are published in a suite at the same time?
[11:40] <cjwatson> I don't think the importer should have wound the debian/sid branch back to 1.14.8-2~deb12u1 in this case, since 1.14.8-2 is still Published.
[13:35] <rbasak> cjwatson: How does the importer handle the case where multiple versions are published in a suite at the same time> it just does what Launchpad says in publication order
[13:36] <rbasak> I think.
[13:36] <rbasak> Why would Debian publish that in sid?
[13:38] <rbasak> Yes the importer algorithm is just going to result in debian/sid pointing to the most recent thing that Launchpad says is published in sid.
[13:41] <zhsj> 1.14.8-2~deb12u1 in unstable is `Extra-Source-Only: yes`. some packages (for example debian-installer-12-netboot-amd64) in unstable has built-using dbus = 1.14.8-2~deb12u1
[13:43] <zhsj> last debian-installer-netboot-images is uploaded to bookworm, and then pop up to unstable.
[13:52] <rbasak> should have wound the debian/sid branch back to 1.14.8-2~deb12u1> FWIW it's actually ahead, since 1.14.8-2~deb12u1's changelog lists 1.14.8-2, even though the versions go the other way.
[13:52] <rbasak> It will get force pushed on the next regular upload to sid.
[13:57] <cjwatson> rbasak: I don't think "most recent publication" is quite the right algorithm here, at least not for the way that Debian's archive management software works.  My understanding is that Debian sometimes propagates publications from earlier suites like proposed-updates to later suites like sid, and then relies on garbage-collection machinery to clean those up if they aren't needed.
[13:58] <cjwatson> rbasak: So this behaviour where an earlier-versioned publication arrives in sid chronologically after a later-versioned publication is definitely possible, but shouldn't be interpreted to mean that the package has been rewound to that earlier version (unless the later-versioned publication is removed).
[13:58] <zhsj> i think ESO should be ignored
[14:08] <rbasak> cjwatson: I was unaware of this. Thanks. So what should I do instead? Take the highest version of everything still published?
[14:09] <rbasak> I'm not sure how to extract that from the API incrementally
[14:09] <rbasak> Would taking the highest version of everything still published also work for Ubuntu?
[14:11] <cjwatson> I think so ...
[14:13] <cjwatson> Or maybe ignore anything with Extra-Source-Only as zhsj suggests, though that would probably require fetching the actual Sources stanza, and I'm not entirely sure that's preserved anywhere by LP's importer
[14:13] <cjwatson> (It might be in a "misc extra fields" thing somewhere ...)
[14:14] <cjwatson> I'm not sure there are any situations today where Ubuntu publishes multiple versions of a given source package in the same archive/suite
[14:14] <cjwatson> Except maybe for brief periods
[14:17] <cjwatson> Though it is definitely a logically coherent thing to do.  Consider the case where we've deliberately chosen to allow a package to be out of sync across architectures, forcing proposed-migration.  In that case, both source versions ought to be published in the given suite.
[14:17] <rbasak> I tried this: https://paste.ubuntu.com/p/fXYPQhypZC/
[14:17] <cjwatson> (I don't remember whether we do that today)
[14:18] <rbasak> It's a surprising long answer
[14:18] <cjwatson> Do you possibly need exact_match=True?
[14:18] <rbasak> Ah
[14:18] <cjwatson> For annoying historical reasons the default is a substring match, IIRC
[14:19] <rbasak> That's better thanks
[14:19] <rbasak> Out[2]: ['1.14.8-2', '1.14.8-2~deb12u1', '1.14.6-1']
[14:21] <rbasak> Right now the importer algorithm processes all publications in date order. For every publication it updates the branch pointer corresponding to the suite it was published in. The result when it's done is that the branch pointer always points to the most recent publication.
[14:22] <rbasak> To change this, I could move the branch pointer out of that loop, and update all branch pointers at the end. For all known suites, run getPublishedSources() against that distro_series and pocket, take the highest version, and set the branch pointer to that.
[14:22] <rbasak> Does that sound correct?
[14:24] <rbasak> It would mean one more interation every six months. Perhaps I could add an importer CLI option to ignore suites older than some date, so that regular production runs could skip EOL suites.
[14:24] <rbasak> *iteration
[14:24] <rbasak> And "one more" -> "one more per pocket"
[14:26] <rbasak> zhsj: ah that makes sense, thanks.
[14:30] <cjwatson> I _think_ so but I don't know the algorithm particularly well ...
[14:40] <rbasak> cjwatson: understood, but setting aside the algorithm, do you think the branch pointers would always be as you would expect if we determined them as above?
[15:05] <cjwatson> rbasak: I think so.  It's a big enough system that a dry-run test wouldn't go amiss though
[15:06] <rbasak> cjwatson: OK thanks!
[16:46] <rbasak> ogayot, cjwatson, zhsj: I recorded this all in https://bugs.launchpad.net/git-ubuntu/+bug/2028288 if you're interested. Thank you for the report and discussion.
[16:46] -ubottu:#ubuntu-devel- Launchpad bug 2028288 in git-ubuntu "debian/sid branch incorrect when multiple versions are published" [Medium, Triaged]
[19:05] <tjaalton> sergiodj: next week when I'm back
[19:23] <sergiodj> tjaalton: ack, thanks