/srv/irclogs.ubuntu.com/2023/07/20/#ubuntu-devel.txt

LocutusOfBorgvpa1977, sponsored.06:56
LocutusOfBorgin Debian :)06:56
vpa1977Thank you =)06:59
LocutusOfBorgI also uploaded as build1 in Ubuntu07:04
LocutusOfBorg<BTS> fdroidserver 2.2.1-1.1 uploaded by Gianfranco Costamagna (locutusofborg) (Closes: #1040629) https://tracker.debian.org/fdroidserver07:05
LocutusOfBorgit will autosync in some h07:05
juliank@pilot in08:04
=== 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
juliankseb128: you may want to pilot out 😄08:06
seb128juliank, oh right, thanks08:06
seb128@pilot out08:06
=== 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
dviererbeHello, 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
dviererbeIt's a really trivial merge, so it should not take much time to review it.08:21
=== cpaelzer_ is now known as cpaelzer
mirespaceHi, 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:53
mirespaceI ran it locally and I got a memory allocation error in a few ones (hoping that it was caused by my machine)08:54
cpaelzermirespace: typo ? - Unknown PPA mirespace/mre-dpdk-202635108:57
cpaelzeror a consequence of the changes to who can trigger test restarts08:57
mirespacecpaelzer: _checking.... but I ran the same command for jammy, mpw changing only the release_08:58
mirespaces/mpw/now/09:00
cpaelzeryeah and https://launchpad.net/~mirespace/+archive/ubuntu/mre-dpdk-2026351 looks correct relative to the URLs you provides09:00
mirespace:-/09:01
cpaelzerI'd ask paride and bdmurray ^^ to have a look if that might be due to the changes for ~autopkgtest-requestors09:01
mirespaceOk, thankyou09:02
cpaelzerI'm trying a different PPA of mine I used in the past09:03
cpaelzerhmm, no the other one works09:04
cpaelzertrying to create my own links for yours09:04
mirespace:(09:04
cpaelzerok, now I have one of yours restarted09:05
cpaelzerI need to disect the URl parameters, give me a bit09:05
mirespacesure09:06
cpaelzerok, found it - invisible UTF magic09:15
cpaelzerparide: bdmurray: ^^ no need to look further09:16
juliank@pilot out09:56
=== 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
juliankSorry I was a bit late to pilot in09:57
juliankdviererbe: I'll leave that to cpaelzer for tomorrow's patch piloting with the idea of focusing on cross-team sponsoring09:57
dviererbejuliank: Okay, thanks for telling me :)09:58
juliankmaybe someone else picks it up first09:58
cpaelzerjuliank: 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
juliankbut cross team sponsoring makes the dmb happy, so focusing on that for stuff following the ~ubuntu-sponsors process09:59
juliankcpaelzer: 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:00
cpaelzerI'm really fine10:01
cpaelzerdidn't want to hold you back10:01
juliankThere's like 4 actionable items in the backlog now10:02
dviererbemy merge proposal is more than a week old, so i don't think that a day makes a difference ^^10:04
rbasakcpaelzer: o/ how many patch piloting sessions have you done so far?11:11
rbasakI thought I was going to do one the other day but you were doing it. Did we just swap one, or all?11:11
rbasakBecause there's one tomorrow but it's on my calendar.11:11
rbasakBut then on Monday 31st it looks like you're taking my slot again?11:12
rbasakI 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:13
cpaelzerrbasak: we did swap one, this would be my third session11:24
cpaelzerrbasak: Monday 31st is what I thought I traded, I'm off that day11:24
rbasakcpaelzer: I thought you took 19 June instead of me.11:26
rbasakcpaelzer: then on 10 July I thought it was my session but you did it11:26
cpaelzerI see, there is the double11:26
cpaelzerindeed11:26
rbasakcpaelzer: and on 31 July your calendar still has you taking mine.11:26
rbasakI mean if you want to take all of mine then I'm fine with that :-P11:27
cpaelzerI fixed 31st now to correctly state you take over from me11:27
cpaelzeras I'm off I couldn't do anything there :-)11:27
cpaelzerI'm fine doing the one tomorrow even thought I think this would indeed be yours - it is a nice pre-sprint contrast11:27
rbasakcpaelzer: it's still recurring - see 21 August11:28
cpaelzerah calendars, curse of modern mankind ... on it11:28
* rbasak isn't sure he's actually done a shift in 2023 yet!11:29
cpaelzerok, here is the default11:29
cpaelzerI usually have the Fri slot, you the one on Mondays11:30
cpaelzerwe traded one for when I'm off on 31st11:30
rbasakOK11:30
cpaelzerbut by overzealous exitement I took it over from you when we are supposed to trade11:30
rbasak:)11:30
cpaelzerthat is why in the past you haven#t but i have done one11:30
cpaelzerso 31st is yours (taking over from me - thanks)11:30
cpaelzertomorrow is mine as it normally would be11:31
cpaelzerand after that all should be normal (you Mondays, me Fridays - all on 6 week pattern)11:31
ogayotrbasak: 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:31
cpaelzerrbasak: let us just remember I have one good with you in case my next conflict comes up :-)11:32
rbasakogayot: 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 reflecting11:33
rbasakcpaelzer: ack. Thanks!11:33
rbasakcpaelzer: well, two I think!11:33
rbasakcjwatson: ^ (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:35
* rbasak is heading to lunch now. Back later.11:36
ogayotrbasak: fair enough. I will wait before force-updating the new/debian tag I guess - we we understand what's going on11:36
cjwatson$ curl -s https://deb.debian.org/debian/dists/sid/main/source/Sources.xz | xzcat | grep-dctrl -nsVersion -PX dbus11:38
cjwatson1.14.6-111:38
cjwatsonrbasak: ^11:38
cjwatson1.14.8-2~deb12u111:38
cjwatson1.14.8-211:38
cjwatsonSo all three of those are currently recorded as being Published in debian/sid, which seems like an accurate reflection of reality11:39
cjwatsonHow does the importer handle the case where multiple versions are published in a suite at the same time?11:39
cjwatsonI 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.11:40
rbasakcjwatson: 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 order13:35
rbasakI think.13:36
rbasakWhy would Debian publish that in sid?13:36
rbasakYes 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:38
zhsj1.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~deb12u113:41
zhsjlast debian-installer-netboot-images is uploaded to bookworm, and then pop up to unstable.13:43
rbasakshould 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
rbasakIt will get force pushed on the next regular upload to sid.13:52
cjwatsonrbasak: 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:57
cjwatsonrbasak: 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
zhsji think ESO should be ignored13:58
rbasakcjwatson: I was unaware of this. Thanks. So what should I do instead? Take the highest version of everything still published?14:08
rbasakI'm not sure how to extract that from the API incrementally14:09
rbasakWould taking the highest version of everything still published also work for Ubuntu?14:09
cjwatsonI think so ...14:11
cjwatsonOr 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 importer14:13
cjwatson(It might be in a "misc extra fields" thing somewhere ...)14:13
cjwatsonI'm not sure there are any situations today where Ubuntu publishes multiple versions of a given source package in the same archive/suite14:14
cjwatsonExcept maybe for brief periods14:14
cjwatsonThough 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
rbasakI tried this: https://paste.ubuntu.com/p/fXYPQhypZC/14:17
cjwatson(I don't remember whether we do that today)14:17
rbasakIt's a surprising long answer14:18
cjwatsonDo you possibly need exact_match=True?14:18
rbasakAh14:18
cjwatsonFor annoying historical reasons the default is a substring match, IIRC14:18
rbasakThat's better thanks14:19
rbasakOut[2]: ['1.14.8-2', '1.14.8-2~deb12u1', '1.14.6-1']14:19
rbasakRight 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:21
rbasakTo 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
rbasakDoes that sound correct?14:22
rbasakIt 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*iteration14:24
rbasakAnd "one more" -> "one more per pocket"14:24
rbasakzhsj: ah that makes sense, thanks.14:26
cjwatsonI _think_ so but I don't know the algorithm particularly well ...14:30
rbasakcjwatson: 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?14:40
cjwatsonrbasak: I think so.  It's a big enough system that a dry-run test wouldn't go amiss though15:05
rbasakcjwatson: OK thanks!15:06
rbasakogayot, 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]16:46
tjaaltonsergiodj: next week when I'm back19:05
sergiodjtjaalton: ack, thanks19:23

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!