| cpete | Hello hello, would anyone be willing to look at my merge proposal against ubuntu-dev-tools? https://code.launchpad.net/~cpete/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/459002 ? I addressed some of your feedback from last time LocutusOfBorg if you want to take a look again | 00:54 |
|---|---|---|
| === pushkarnk1 is now known as pushkarnk | ||
| adrien | xz switches its core components from PD to 0BSD: https://raw.githubusercontent.com/tukaani-project/xz/master/NEWS (not that I believe it affects us much, if at all) | 08:20 |
| === pushkarnk1 is now known as pushkarnk | ||
| dnegreira | Hi, I would like to take maintainership of a package - sosreport - as our colleague unfortunately passed away last year. What would be the best way to go about moving the maintainership? | 08:40 |
| === JanC is now known as Guest1755 | ||
| === JanC_ is now known as JanC | ||
| ivoks | dnegreira: see https://wiki.ubuntu.com/nkshirsagar/UbuntuPerPackageUploaderApplication as an example and https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage | 09:20 |
| * sudip was also looking for PPU info.. thanks ivoks | 09:30 | |
| LocutusOfBorg | cpete fine for me now! | 10:30 |
| juliank | @pilot in | 10:33 |
| === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: juliank | ||
| juliank | Please ping me if I forgot to pilot out :) | 10:34 |
| juliank | I am busy going through the 46 or whatever patches in the queue though | 10:34 |
| rbasak | juliank: could you check the apt version string in your jammy unapproved upload please? | 10:57 |
| juliank | rbasak: Did I mess stuff up? Sorry, I checked building and suite but did not check version string | 10:58 |
| juliank | rbasak: Oh the apt | 10:58 |
| juliank | rbasak: This is correct, it's an apt upstream branch targetted at jammy | 10:59 |
| juliank | All LTS branches follow upstream maintenance and also have other downstream users | 10:59 |
| rbasak | Hmm. | 10:59 |
| rbasak | This is very unusual :-/ | 10:59 |
| juliank | You'll find going through the apt uploads it's always been this way since xenial | 10:59 |
| juliank | for lts | 10:59 |
| rbasak | What happens if Debian needs an upload with this version string? | 11:00 |
| rbasak | Then they'd mismatch in contents. | 11:00 |
| juliank | It doesn't | 11:00 |
| rbasak | Even if not this time, what about the pattern generally? | 11:00 |
| juliank | Debian is always off by 2 vs an LTS | 11:01 |
| rbasak | There are some other general assumptions this breaks | 11:01 |
| rbasak | Ubuntu developers might assume that '2.4.12' means that it was synced and therefore existed in Debian, but this won't. | 11:01 |
| rbasak | (though admittedly that situation does exist for some Ubuntu-only packages but that doesn't mean it's right, and this case is a different pattern to that one) | 11:02 |
| juliank | But it shows them this was an upstream apt upload | 11:02 |
| juliank | And it vastly simplifies the story when there's critical fixes to tell users upstream apt versions | 11:02 |
| juliank | And the other downstreams use the LTS branches too | 11:03 |
| rbasak | You could still do that - 2.4.12ubuntu0.1 would convey the upstream version | 11:03 |
| juliank | It would imply there is an Ubuntu specific delta when there isn't | 11:03 |
| rbasak | There is - in debian/changelog | 11:03 |
| rbasak | It says "jammy" | 11:04 |
| rbasak | That's Ubuntu-specific | 11:04 |
| juliank | I have purposefully aligned all apt versioning and branching schemes in 2016 to be able to directly deliver things like this | 11:04 |
| rbasak | This breaks Ubuntu's SRU versioning patterns though :-( | 11:05 |
| juliank | The versioning pattern is a suggestion, not a rule | 11:05 |
| juliank | snapd these days uploads all releases as <snapd release>+<ubuntu release>.1 | 11:06 |
| rbasak | I agree that it's currently not a rule. But by varying from the suggestion, I now have to consider all the implications to understand if it's acceptable. | 11:06 |
| rbasak | snapd is covered by my "admittedly that situation does exist for some Ubuntu-only packages" above. | 11:07 |
| rbasak | Anyway, I think I understand your position and you understand mine. Let's get a wider opinion on this and we can do whatever the consensus is. | 11:07 |
| juliank | So noble will release with 2.8.x, and it may even then get 2.8.x+1 synced from Debian (via way of fakesync to make it SRU-reviewable) | 11:07 |
| juliank | (as in, we upload the changes so you get a source diff) | 11:08 |
| juliank | But it's more likely I'll bump Debian to 2.9.0 straight away | 11:08 |
| rbasak | If it's agreed to do it this way, then we should document SRU team agreement under https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases so this doesn't get delayed next time by another SRU team member surprised/confused by this. | 11:08 |
| juliank | I usually just ping sil2100 and he accepts it :D | 11:09 |
| juliank | But bdmurray also accepted apt SRUs | 11:10 |
| juliank | and possibly various others | 11:11 |
| juliank | RAOF accepted 1.6.17 | 11:11 |
| rbasak | Fine, but new SRU team members aren't going to magically know. | 11:11 |
| rbasak | We need to get this stuff documented. | 11:11 |
| juliank | It's fine but you're the first one to raise this in 8 years | 11:11 |
| juliank | We also need to fix up a lot of SRU exception thingies for grub and fwupd and shim which all use signed UEFI binaries which can only ever land as binary copies from the UEFI proposed-public PPA | 11:14 |
| juliank | not to mention that those get binary copies of binaries built in latest stable release none of which has SRU team approval as a general practice | 11:14 |
| rbasak | I'm more sensitive to this kind of thing because of git-ubuntu. So many edge cases. *I* understand that version strings are more general than the simple view, but edge cases like this just makes it harder to onboard new people into packaging. It's no wonder many developers can never follow what's going on with package version strings. Sticking to established patterns would make things simpler for | 11:14 |
| rbasak | everybody, even if it's technically correct to vary it. | 11:14 |
| rbasak | s/correct/acceptable/ | 11:15 |
| rbasak | I haven't raised it yet, but one day I'd like to for us switch to ubuntu0.22.04.1 pattern always, instead of only when there could be two ubuntu0.1 for example. And stop doing ubuntu5 in an SRU, favouring ubuntu4.1 instead. | 11:16 |
| rbasak | That would just make simpler the rules new developers have to follow, even if the currently used system works fine. | 11:16 |
| rbasak | Part of that is to expect _everyone_ to stick to the pattern, even though the old ones work, because new developers also learn by observing what experienced people are doing. | 11:17 |
| juliank | And part of apt upstream versioning scheme is to discourage people from doing uploads themselves such that everything going into APT LTS uploads goes through APT LTS release process and QA | 11:18 |
| juliank | So if someone does do an ubuntu0.1 and I don't catch it you can see it does not have the APT team seal of approval | 11:18 |
| juliank | I'm running a very tight ship on the APT release pipeline :) | 11:19 |
| rbasak | We all know (or should know) it's preferable to avoid adding delta. That applies to every package. We should not damage/distort our versioning patterns for the sake of establishing that. | 11:20 |
| juliank | In python-apt you can see a mix of that, uploads from me go through the upstream release process and have the upstream version numbers, whereas the release team uploads ubuntu0.x uploads when doing point releases to refresh the mirror lists | 11:22 |
| juliank | Which is reasonable for us to not do an upstream release for because that's a data-only change | 11:23 |
| juliank | The separation was more meaningful when I was not biased by employment in what I accept in stable branches (I may be now I don't know :D) | 11:24 |
| rbasak | you're the first one to raise this in 8 years> IMHO, the SRU team is dying by a hundred papercuts like this. The old guard have this stuff in their heads; the newer members have to learn this obscure differences, for IMHO reasons that don't justify the edge cases. This doesn't scale. We should seek to find patterns that work for everyone, follow those, have fewer edge cases and document them all. | 11:25 |
| juliank | Now for most intents and purposes, APT pretty much is an in-house project | 11:25 |
| rbasak | *these | 11:25 |
| juliank | We should also get a better wiki | 11:28 |
| juliank | Anyhow can I do my patch pilot shift now? | 11:29 |
| juliank | rbasak: I wrote a wiki page to document it https://wiki.ubuntu.com/AptUpdates | 11:38 |
| rbasak | Thanks! Let's see what others' opinions are on this. Tha page will help. | 11:44 |
| juliank | rbasak: I forgot to do prepare-upload for https://code.launchpad.net/~vpa1977/ubuntu/+source/cava/+git/cava/+merge/460303 could you close that out for me? | 11:49 |
| * juliank uploaded non-git uploads in between and used wrong line in history | 11:50 | |
| rbasak | Done | 12:01 |
| juliank | Thanks! | 12:12 |
| juliank | @pilot out | 12:12 |
| === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A | ||
| juliank | That's my pilot shift for today, 8 uploads done | 12:13 |
| juliank | So we should be down from 46 to 34 or so with the additional unsubscribe review work | 12:14 |
| juliank | I should have done the syncs maybe but I went in order :( | 12:15 |
| sudip | juliank: thanks for looking at all my bug reports. but I see you rejected LP: #2052836, rbasak asked for that one at https://bugs.launchpad.net/ubuntu/+source/lcov/+bug/2051166/comments/5 | 12:38 |
| -ubottu:#ubuntu-devel- Launchpad bug 2052836 in lcov (Ubuntu) "Enable tests during build" [Undecided, Won't Fix] https://launchpad.net/bugs/2052836 | 12:38 | |
| -ubottu:#ubuntu-devel- Launchpad bug 2051166 in lcov (Ubuntu Mantic) "[SRU] lcov 2.0-1 FTBFS on Mantic" [Undecided, Fix Committed] | 12:38 | |
| juliank | sudip: I believe in context with the SRU following Debian for the SRU is better than introducing a delta in devel that we continuously need to maintain when it offers little value | 14:18 |
| juliank | Optimally as I said, get the change in Debian landed then you can just do the SRU with test cases enabled and it will match noble and we avoid committing to endless work | 14:19 |
| juliank | If I were to see this in noble+1 it would be a delta I'd drop with a force sync | 14:19 |
| rbasak | juliank: you would *regress* Ubuntu by disabling tests in a force sync?! | 14:23 |
| juliank | Yes if the package shows high on the merges list and that's the only delta I'd absolutely do this | 14:25 |
| juliank | If there's a person regularly merging the package it won't come to my attention | 14:25 |
| rbasak | I think you're resisting a delta too hard. | 14:25 |
| rbasak | It would be trivial to merge. | 14:25 |
| juliank | Doesn't mean it happens though, if it does all is well, if it stagnates half the cycle then nobody cares and we drop it | 14:26 |
| juliank | Especially for a universe package it can be dangerous | 14:26 |
| rbasak | Then I think the right question to ask the sponsoree is: "are you prepared to maintain the delta, or who is?" | 14:27 |
| juliank | Possibly | 14:27 |
| tjaalton | re: standardized sru version numbers? yesplease | 14:28 |
| sudip | well, I dont mind maintaining the delta, there is a MR for this in salsa, so delta will be dropped as soon as the maintainer accepts that (or rejects with a reason) | 14:31 |
| rbasak | Thanks | 14:31 |
| rbasak | I'll sponsor your upload to Noble, and ask juliank to refer to sudip to merge it rather than drop it. | 14:31 |
| rbasak | Seeing as you've already done the work, and otherwise you're just stuck between two Ubuntu developers with different opinions. | 14:31 |
| sudip | thanks rbasak | 14:33 |
| rbasak | sudip: so the only thing I'd do there is say that you're re-enabling tests in the changelog. That's the crucial bit that isn't mentioned. So for example "Re-enable tests by disabling threads while building. Tests are failing with multiple threads. (LP: #XXX). | 14:38 |
| rbasak | Are you OK with me just changing that? | 14:38 |
| sudip | rbasak: yeah, sure. thanks | 14:39 |
| rbasak | Because enabling tests is the entire purpose of this delta that we're adding, and the future person merging it will need to know that. | 14:39 |
| rbasak | Thanks. | 14:39 |
| rbasak | Hopefully there will be no need to merge it though because the next Debian upload will include this ;) | 14:39 |
| sudip | hopefully | 14:39 |
| ginggs | sudip: I suggest filing a bug report in Debian too, unless you know the maintainer looks at MRs in Salsa | 14:45 |
| sudip | ginggs: I was expecting the maintainer looks after seeing https://salsa.debian.org/mckinstry/lcov/-/merge_requests/1 | 14:46 |
| -ubottu:#ubuntu-devel- Merge 1 in mckinstry/lcov "d/control: add Depends on libdatetime-perl, libcapture-tiny-perl" [Merged] | 14:46 | |
| sudip | but I will open a bug today | 14:46 |
| rbasak | FWIW, I think my general rule is that we don't sit around in Ubuntu waiting for Debian to accept a patch *if* for some reason it's blocking progress in Ubuntu. Either we decide it's not worth it and don't do it at all (which in this case would correspond to not bothering with the SRU, but it seems worth doing the SRU given the package is completely unusable) or we should just add the delta. | 14:48 |
| juliank | I align with that rule but I'm 180° different on how that should work | 15:02 |
| juliank | SRU bug being solved by a different better approach than in devel is not necessarily enough grounds to change devel as well, that's clearly where I'd draw the line and say "let's submit it to Debian" but the bug is fixed in devel as required by SRU policy, so it's just annoying | 15:08 |
| === pushkarnk1 is now known as pushkarnk | ||
| rbasak | The sole purpose of the "fix in development release first" SRU policy is so that users won't face a regression on upgrade. Disabling tests seemed like something that is the opposite of that. I'm not sure if we can call any bug "fixed" if, to do so, we had to disable the entire test suite. That would mean that users still face a regression upgrading up to Noble - or at least we no longer even know if | 15:10 |
| rbasak | they do or not. | 15:10 |
| rbasak | The fact that the disabling of tests came as a sync from Debian is a complication, but from an SRU perspective I only care about the change that was applied to Noble, not who made it. | 15:10 |
| juliank | Also why do we disable threads for the entire build rather than just the tests | 15:11 |
| rbasak | Feel free to fix it better :) | 15:11 |
| rbasak | My philosophy here is that an incremental improvement is better than no improvement, so I'm not going to reject it just because we can imagine something better. Perfect is the enemy of the good. | 15:12 |
| === rkratky__ is now known as rkratky | ||
| cpete | LocutusOfBorg: Thank you for your review! | 16:37 |
| dbungert | LocutusOfBorg: I'm no perl expert but I'm looking at https://git.launchpad.net/ubuntu/+source/dpkg/commit/?id=b80bc1cb34e560281a030312eef7c16f4b0c2963 and I think it's logically equivalent? Am I missing something? | 21:28 |
| -ubottu:#ubuntu-devel- Commit b80bc1c in ubuntu/+source/dpkg "1.22.4ubuntu3 (patches unapplied) HEAD import/1.22.4ubuntu3 ubuntu/noble-proposed ubuntu/noble-devel ubuntu/devel" | 21:28 | |
| dbungert | LocutusOfBorg: disregard, I get it | 21:33 |
| rbasak | Oops. Sorry about the lcov changelog wrapping fail when I edited it. | 22:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!