| doko | sudip: no | 10:34 |
|---|---|---|
| sudip | thanks doko | 11:13 |
| rbasak | adrien: "hard customer deadline" (from ubuntu-devel@) is not a community concern. If you need priority from Canonical members of the SRU team (currently that's all of them) then that's something that needs to be taken up internally within Canonical. | 15:53 |
| rbasak | I can help with that too, but please start internally for that - not the public ML. | 15:53 |
| adrien | rbasak: right; for context, I've relented to mention that for the past 4 months or so precisely for that reason and I feel like there's no perfect solution and I've been given various answers when asked how to proceed there; if we disregard the current composition of the SRU team, I don't know of a proper way to contact all SRU team members who are also canonical employees (no ML or channel for | 16:10 |
| adrien | instance) | 16:10 |
| adrien | the fix is not customer-specific though, I just don't have hard data about the exact spread of the issue | 16:10 |
| adrien | also, I guess you moderate mails on ubuntu-devel@; if so, do you know who else does? long-timers didn't know and I think it would be valuable to know (and I changed my settings to avoid the need to moderate my mails on -discuss even though the issue was probably on mailman's side) | 16:13 |
| rbasak | adrien: there's the Canonical-internal ~Ubuntu channel which is for discussion relating to Ubuntu development that cannot be public (eg. customer specifics, deadlines, etc). I suggest you start there. | 16:38 |
| rbasak | I don't know exactly who else moderates ubuntu-devel@. But it is primarily intended for Ubuntu developers whose emails go through without moderation. Moderation shouldn't take more than a day. You can ask for moderation here if needed. | 16:39 |
| adrien | ok, I'll stick to ~Ubuntu for that; I don't know of a highlight like ubuntu-${group} but the channel traffic is probably light enough that it doesn't matter much | 16:41 |
| adrien | regarding list moderation, I've been very pleasantly surprised by the speed at which mails are moderated since in my experience it's quite a painful task for moderators (and that matched the not more than a day that you mention); there was one exception to the delay during december and I think I asked here (again, having to ask seems like an uncommon scenario but it's good to know) | 16:44 |
| bdmurray | I moderate ubuntu-devel daily when I'm around | 16:50 |
| bdmurray | listadmin makes it less painful | 16:51 |
| sergiodj | jbicha: Trevinho_: hey, would you like me to prepare uploads for gdm3 on Debian/Ubuntu to backport https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/230 ? | 16:58 |
| -ubottu:#ubuntu-devel- Merge 230 in GNOME/gdm "gdm-pam-extensions: Install gdm-custom-json-pam-extension.h header" [Merged] | 16:58 | |
| jbicha | sergiodj: if it's not urgent, I'd prefer to have Marco review since he was doing some recent gdm3 maintenance. But he's out for a few days | 17:06 |
| sergiodj | jbicha: ACK, thanks. it can wait a few days | 17:06 |
| jbicha | enr0n: btw there are some packages that will fail to build until systemd is updated. See https://launchpad.net/ubuntu/+source/modemmanager/1.22.0-2ubuntu1 | 17:07 |
| jbicha | I think this change is relevant: https://salsa.debian.org/systemd-team/systemd/-/commit/ee83b5721 | 17:07 |
| -ubottu:#ubuntu-devel- Commit ee83b57 in systemd-team/systemd "Drop pkgconfig-keep-unmerged-paths-for-udevdir.patch, no longer needed" | 17:07 | |
| enr0n | jbicha: thanks for the heads up. I mostly prepped 255.2-3ubuntu1 yesterday, so I will try and get that uploaded today | 17:12 |
| vpa1977 | rbasak: I have updated LP: #1930541 as per comments. Please advice if there are some other details/tests added? | 20:24 |
| -ubottu:#ubuntu-devel- Launchpad bug 1930541 in maven (Ubuntu Focal) "[SRU] Maven 3.6.3-1 fails to run with OpenJDK 17" [Undecided, Fix Committed] https://launchpad.net/bugs/1930541 | 20:24 | |
| vpa1977 | *need to be added | 20:24 |
| === sudip_ is now known as sudip | ||
| adrien | working on a package I got in a state where I couldn't build the source package because dpkg-source would dream of differences between my source tree and the orig tarball; a previous time I did a clean checkout in order to solve that because I ran out of ideas but this time I debugged the issue and found that if I emptied d/patches/series, built the source package and restored d/p/series, I could fix | 20:49 |
| adrien | the situation | 20:50 |
| adrien | do that ring a bell to anyone? I rm'ed .pc at some point but I was already in a broken situation (because the build had failed mid-way due to unexpected changes which were real [ this is for openssl, it's not easy to fix ]) | 20:51 |
| rbasak | Are you using MoM? That leaves behind cruft relating to quilt. | 20:54 |
| tsimonq2 | If the diff is irrelevant, you could simply do a patch -R as well. | 20:56 |
| adrien | no, not using MoM there and that was in a git repo where everything was commited (except maybe under debian/) so I guess patch -R can be worth a try | 20:59 |
| adrien | in any case, I definitely have no idea where the "state" for this was but when this happens again I can probably copy the directory showing the issue, fix it and diff everything | 21:00 |
| tsimonq2 | I'll throw out diffoscope as a tool you may be interested in using for that. | 21:01 |
| adrien | I had "diff" in mind but that's a good point, thanks :) | 21:04 |
| tsimonq2 | adrien: I keep the fun in my reviews. ;) | 21:07 |
| tsimonq2 | (I saw your email footer and thought that was awesome.) | 21:07 |
| adrien | (: | 21:12 |
| arraybolt3 | @pilot in | 21:14 |
| === 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, arraybolt3 | ||
| tsimonq2 | @pilot in | 21:14 |
| === 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, arraybolt3, tsimonq2 | ||
| * arraybolt3 slaps an "in training" sticker on the plane | 21:15 | |
| tsimonq2 | "Welcome aboard your flight on Spirit Airlines." | 21:15 |
| arraybolt3 | one moment while I power on the controls (VM and whatnot) | 21:16 |
| Eickmeyer | tsimonq2: Spirit Airlines? That's just asking for trouble (and nickle-and-diming everyone here) | 21:16 |
| tsimonq2 | Eickmeyer: Sorry, cheap joke. | 21:16 |
| Eickmeyer | HAHAHAHAHAHAHA | 21:17 |
| arraybolt3 | alrighty, I'm going to stay away from dbus for the moment (and xorg-server) since those are a bit too high-risk... | 21:17 |
| arraybolt3 | let's start with bluez, that looks like it won't blow up too badly | 21:17 |
| tsimonq2 | That's in Main, but I certainly won't stop you. :) | 21:18 |
| arraybolt3 | that's a good point though | 21:19 |
| arraybolt3 | alright. libtrace3 it is | 21:19 |
| tsimonq2 | Oooooh, that one is *great* training material. | 21:20 |
| arraybolt3 | tsimonq2: ok, question, why is there a merge proposal here? https://code.launchpad.net/~sudipmuk/ubuntu/+source/libtrace3/+git/libtrace3/+merge/457861 | 21:20 |
| arraybolt3 | I've never seen that on a sponsorship request. | 21:20 |
| * sudip checks what he has done with libtrace3 | 21:21 | |
| tsimonq2 | arraybolt3: There's a new workflow called git-ubuntu which aims to simplify uploads. | 21:21 |
| vorlon | juliank: ^^ did you forget to outpilot | 21:21 |
| arraybolt3 | tsimonq2: ah ok | 21:22 |
| tsimonq2 | arraybolt3: rbasak is really (who I at least see as) one of the key drivers for that. I'll try to find docs, but your guess may be as good as mine. | 21:22 |
| tsimonq2 | What I do with those is (and I probably need to do better!), I go through the listed commands to merge it (after running `git ubuntu clone PKG`), then upload it from there. | 21:22 |
| Eickmeyer | vorlon: He's been pilot-in'd the entire holiday break. 😂 | 21:23 |
| tsimonq2 | As I understand it, the intended workflow is eventually to push a signed Git tag and have that automatically upload it. | 21:23 |
| arraybolt3 | I'll do further research there later on and for now ignore it. Looks useful though. | 21:23 |
| vorlon | "automatically upload it" is not anywhere near being on the roadap | 21:23 |
| vorlon | *map | 21:23 |
| vorlon | we need the staging branch support to land first as a prerequisite | 21:23 |
| arraybolt3 | sounds like Julian works way too hard :) | 21:23 |
| tsimonq2 | vorlon: Thanks for clarifying, my knowledge around git-ubuntu is obviously somewhat cloudy. :) | 21:24 |
| vorlon | https://canonical-git-ubuntu.readthedocs-hosted.com/en/latest/ | 21:24 |
| vorlon | which has a https://canonical-git-ubuntu.readthedocs-hosted.com/en/latest/howto/patch-pilot.html | 21:24 |
| tsimonq2 | arraybolt3: ^^^^ | 21:25 |
| arraybolt3 | nice | 21:26 |
| Eickmeyer | vorlon, Fallen: Why are those docs not on https://ubuntu.com/community/contribute/ubuntu-development/ubuntu-patch-pilots? | 21:26 |
| arraybolt3 | Changes on libtrace3 look right to me at first glance. Building and potentially autopkgtesting. | 21:27 |
| arraybolt3 | sigh, my IRC client is threatening to lag-lock. One sec... | 21:28 |
| vorlon | they're not *on* that page because the documentation is maintained in git-ubuntu source rather than in discourse; but they ought to be linked | 21:28 |
| rbasak | arraybolt3: if you wish, you can ignore git-ubuntu entirely. Just look at the final commit of the MP as the thing that the sponsoree wishes to upload, using plain git. | 21:28 |
| Eickmeyer | vorlon: Exactly what I meant. | 21:28 |
| vorlon | Eickmeyer: ack | 21:28 |
| arraybolt3_ | alright, much better | 21:28 |
| rbasak | arraybolt3: and then, if you're happy, you can build and upload that the traditional way. You can use the MP for review comments, including inline comments. | 21:29 |
| arraybolt3 | nice | 21:29 |
| === arraybolt3 is now known as arraybolt3_tl | ||
| === arraybolt3_ is now known as arraybolt3 | ||
| rbasak | I mean that is basically what git-ubuntu is - my point is that it's not special magic really, just git. The magic is how the starting commit got there, but you don't need to worry about that part. | 21:29 |
| tsimonq2 | arraybolt3: Historical hint I don't expect you to know coming in: GCC 5's ABI change meant a mass package rename. The v5 suffix is no longer relevant (I'd say in the vast majority of cases). | 21:32 |
| tsimonq2 | (I don't quite remember *what* was special about GCC 5, just that we did that.) | 21:32 |
| tsimonq2 | sudip: ^^^ | 21:32 |
| tsimonq2 | And that's why I was glad you chose that. :) | 21:33 |
| arraybolt3 | well it keeps the package name consistent, so I'm fine with it still being there. | 21:33 |
| arraybolt3 | (to keep the rename I mean) | 21:33 |
| arraybolt3 | at any rate, sudip, tsimonq2: https://termbin.com/2zld this is the Lintian output I get from building the package. It's very messy, *but* none of it has to do with the delta AFAICT. | 21:33 |
| arraybolt3 | (Some of those are false-positives from my sbuild environment, including the error at the start) | 21:33 |
| tsimonq2 | arraybolt3: The argument against | 21:34 |
| arraybolt3 | I would ACK this as it's mostly a sync and the Ubuntu delta has no Lintian problems. | 21:34 |
| sudip | uhhh.. how did you get that "libtrace3 changes: bad-distribution-in-changes-file noble-amd64-shm" ? | 21:34 |
| arraybolt3 | sudip: sbuild's doing, ignore | 21:34 |
| tsimonq2 | (use -c instead of -d) | 21:34 |
| arraybolt3 | my sbuild schroot it noble-amd64-shm | 21:34 |
| sudip | arraybolt3: I use sbuild and I never get that | 21:34 |
| arraybolt3 | tsimonq2: oh really? nice | 21:34 |
| arraybolt3 | sudip: I get it all the time, and it sounds like tsimonq2 just told me why. | 21:34 |
| tsimonq2 | arraybolt3: Anyway, I pressed Enter too early... | 21:34 |
| tsimonq2 | arraybolt3: Essentially, there isn't an argument for keeping deltas specific to this transition. If a delta doesn't have to exist, a sync should be considered. | 21:35 |
| tsimonq2 | That being said, a sync can't be considered in this case, because of Breaks/Replaces. | 21:35 |
| arraybolt3 | I was just starting to think something along those lines. | 21:35 |
| vorlon | tsimonq2: well the v5 suffix is relevant in the sense that you don't want to DROP it and force a needless library transition... | 21:36 |
| arraybolt3 | package naming needs to be preserved, I was wondering if Breaks/Replaces could be used to get around that, but it sounds like not. | 21:36 |
| arraybolt3 | sudip: keep in mind this is my first patch pilot session and it's mostly training, so a lot of the debate between me and tsimonq2 is *me* learning | 21:37 |
| sudip | imho, the delta can not be dropped, otherwise it needs to be a transition. not sure what you call that here in Ubuntu | 21:37 |
| tsimonq2 | vorlon: I agree with that as a general rule. That being said, in this case, the only reverse dependency for the source package is Python bindings which don't depend on this binary. | 21:37 |
| tsimonq2 | This wouldn't really cause a transition, in this specific case. | 21:37 |
| arraybolt3 | sudip: it's called a transition here too | 21:37 |
| arraybolt3 | I think dropping the delta would require a transitional package, which sounds like a lot of work? | 21:39 |
| arraybolt3 | otherwise 22.04 upgraders will run into problems | 21:39 |
| tsimonq2 | It could be renamed back to libpacketdump3 and the Conflicts/Replaces could be adjusted. | 21:39 |
| vorlon | tsimonq2: I don't think that's relevant to a review of a request for sponsorship of a merge. Deciding to undo the v5 suffix is orthogonal to the merge from Debian. You at least couldn't make this a sync, because you'd have to add the reverse Conflicts/Replaces | 21:39 |
| vorlon | amusingly, `apt-cache search --names-only v5` returns more results for sid than for noble | 21:40 |
| arraybolt3 | hah | 21:40 |
| vorlon | so I don't know why, in 2015, this particular package didn't get a rename | 21:40 |
| tsimonq2 | If the package rename is done now (to be consistent with Debian), that means when 24.10 is opened, this package can just be synced (LTS -> LTS). If the package rename is put off further, that means keeping a delta (and more work) in 24.10+. | 21:41 |
| arraybolt3 | but yeah, I tend to agree with vorlon here - there's no reason to block the merge. I *would* have as input that perhaps a bug should be opened against the package in Debian and updated packaging be provided so as to fix some of the Lintian issues like the old version of debhelper. But for now, I'd merge and upload this. | 21:41 |
| vorlon | but don't worry, I'm going to be renaming it to libpacketdump3t64 shortly | 21:42 |
| arraybolt3 | ow | 21:42 |
| tsimonq2 | I mean, vorlon (or another AA) would have to accept it anyway. Given that 64-bit time will need its own similar thing, yeah I'm not inclined to block. | 21:43 |
| tsimonq2 | Great point of discussion though I think, because I doubt this is the last time someone will run into this dilemna. | 21:43 |
| tsimonq2 | arraybolt3, sudip: I concur and see no other reason to block, uploading. Thank you both :) | 21:44 |
| vorlon | but also, hah, this makes me realize the debhelper time_t auto-provides: support doesn't dtrt for library packages with other existing abi annotations, sigh | 21:44 |
| sudip | tsimonq2: ooi, which one did you use? the git-ubuntu or the debdiff ? | 21:45 |
| arraybolt3 | I used the debdiff | 21:45 |
| vorlon | because libpam0t64 will try to Provide: libpam0 instead of libpam0g | 21:45 |
| tsimonq2 | Niceeeeee | 21:45 |
| tsimonq2 | sudip: I'd say as a "general rule of thumb," try to do one or the other. They should be the same anyway, no? (And you can still create a bug report, I'm specifically talking about the debdiff.) | 21:46 |
| vorlon | I think my earlier debian/rules-based approach might've handled this automatically, but then you have the ugliness of having to patch debian/rules everywhere | 21:46 |
| arraybolt3 | sudip: Looking at them I see now there are some differences between them... | 21:46 |
| tsimonq2 | arraybolt3: So you tell me: which one should I use? :) | 21:46 |
| arraybolt3 | I reviewed the debdiff one. sudip: which one should I have reviewed? | 21:47 |
| sudip | arraybolt3: what difference do you see? I am also quite new to git-ubuntu so it can have problems. | 21:47 |
| tsimonq2 | Trick question, look closer, they're both the same. :P | 21:48 |
| vorlon | nope my debian/rules approach also got this wrong | 21:48 |
| arraybolt3 | tsimonq2: not that I can tell, I'm looking at them | 21:48 |
| arraybolt3 | oh... wait... | 21:48 |
| sudip | afait, debdiff has been generated from that same repo, so there should not be any difference | 21:48 |
| arraybolt3 | hahahahahahaha | 21:48 |
| tsimonq2 | vorlon: I'm sure someone has some old v5 scripts ;P | 21:48 |
| arraybolt3 | I see it, one has renames, one has deletions and additions | 21:48 |
| vorlon | tsimonq2: wouldn't be relevant here? | 21:49 |
| tsimonq2 | arraybolt3: Anyway, feel free to move on (and leave an approval comment if you'd like). | 21:49 |
| arraybolt3 | I like the way git-ubuntu does it better | 21:49 |
| vorlon | the 64-bit time_t stuff is special because we're trying to magic up Provides: on architectures where the ABI hasn't changed | 21:49 |
| tsimonq2 | Ahhh, got it. | 21:49 |
| sudip | arraybolt3: git-ubuntu workflow generates lots of tags, so it becomes easier to check the diff | 21:50 |
| arraybolt3 | nice | 21:51 |
| arraybolt3 | I'll learn how to use it after this session. | 21:51 |
| arraybolt3 | also tmux makes viewing diffs in Vim horrible :P | 21:51 |
| arraybolt3 | dunno what it's doing to my colors but just yikes | 21:52 |
| arraybolt3 | with that complete, let's pick... hmm, I can do another one of sudip's, I can tackle a package in Main (scary), or I can work with some obscure-looking Perl thingy. | 21:53 |
| arraybolt3 | sudip: want me to grab another one of yours? | 21:53 |
| vorlon | hah also I missed v5 as one of the suffixes to handle here | 21:53 |
| sudip | arraybolt3: sure, do I still have any ? | 21:54 |
| arraybolt3 | several of them (weex, zeitgeist, and horst) | 21:54 |
| sudip | :) | 21:54 |
| sudip | only 3 | 21:55 |
| sudip | arraybolt3: zeitgeist might be interesting for your training ;-) | 21:55 |
| arraybolt3 | Very well then, let's see what it's about. | 21:55 |
| sudip | there is debdiff and also git-ubuntu | 21:56 |
| sudip | git-ubuntu has lots of comments and replies | 21:56 |
| arraybolt3 | grief, that package looks terrifying XD | 21:56 |
| arraybolt3 | (based on what it does, not on the diff) | 21:56 |
| sudip | lol | 21:56 |
| arraybolt3 | Looks good so far, building | 22:00 |
| tsimonq2 | arraybolt3: Check patch headers one more time :) | 22:02 |
| tsimonq2 | (Non-blocking minor nitpick, concur with "looks good" thus far.) | 22:03 |
| arraybolt3 | The patch headers could be more verbose, but they're there. | 22:05 |
| arraybolt3 | what's more worrying is I see bits of "lunar" in here somehow | 22:05 |
| arraybolt3 | might be a mistake on my end, investigating... | 22:05 |
| arraybolt3 | how on earth...? | 22:06 |
| arraybolt3 | sbuild -c noble-amd64-shm is somehow building it against Lunar...?! | 22:06 |
| arraybolt3 | that can't be right, hold up | 22:06 |
| arraybolt3 | no, it's using noble, so | 22:06 |
| arraybolt3 | idk | 22:07 |
| arraybolt3 | going back to using sbuild -d :P | 22:07 |
| tsimonq2 | Something's up with your aliases, we can deal with that later if you have something working now. :) | 22:07 |
| arraybolt3 | it's probably an old sbuildrc | 22:07 |
| arraybolt3 | $distribution = 'lunar' | 22:07 |
| tsimonq2 | There it is. | 22:07 |
| arraybolt3 | so sbuild thinks it's building for lunar when it's really building for noble | 22:07 |
| arraybolt3 | so I should use sbuild -d noble -c noble-amd64-shm but that's long to type | 22:08 |
| tsimonq2 | I have no such setting in my sbuildrc. It's likely safe to remove and let sbuild fallback to the $distribution for the chroot. | 22:08 |
| arraybolt3 | in which case I should just set a script that lets me say "s noble" and it figures it out | 22:08 |
| arraybolt3 | hmm, that sounds like a good idea | 22:09 |
| tsimonq2 | arraybolt3: Another hint on the patch header: I explicitly look for machine-readability if at all possible. | 22:09 |
| arraybolt3 | I hadn't done an in-depth check yet | 22:10 |
| arraybolt3 | I have it on my list to do | 22:11 |
| tsimonq2 | No rush. | 22:11 |
| arraybolt3 | (ahem: now :P) | 22:11 |
| arraybolt3 | (as I didn't have it on the list a bit ago) | 22:11 |
| arraybolt3 | Patch itself is Lintian-clean, no errors or warnings in the whole package, very nice. | 22:12 |
| arraybolt3 | tsimonq2: the only potential problem I see in the patch that sudip added is its verbosity, and IMO that's no big deal. The one patch with a weird header is one carried over from before in the delta - is that the one you're mentioning? | 22:14 |
| arraybolt3 | namely pre_populator.patch? | 22:14 |
| tsimonq2 | Yep. :) | 22:14 |
| tsimonq2 | What would you do if you caught that and were the one sponsoring? | 22:14 |
| arraybolt3 | delete the === modified file line and the blank line above it | 22:15 |
| arraybolt3 | so it would go Description, Bug-Ubuntu, Forwarded | 22:15 |
| tsimonq2 | Followup: would you make the sponsoree do this, or would you do it? | 22:15 |
| arraybolt3 | I'd just do it. | 22:15 |
| tsimonq2 | Right answers. :) | 22:15 |
| arraybolt3 | before saying LGTM... | 22:15 |
| arraybolt3 | ...lemme make sure it builds against -proposed :) | 22:15 |
| arraybolt3 | oh wait, I did, I have -proposed builds enabled | 22:16 |
| arraybolt3 | so in that instance, LGTM | 22:16 |
| arraybolt3 | adding comment, tsimonq2: feel free to upload | 22:16 |
| tsimonq2 | I concur. Uploading. Feel free to continue if you'd like. | 22:16 |
| arraybolt3 | tsimonq2: https://code.launchpad.net/~sudipmuk/ubuntu/+source/zeitgeist/+git/zeitgeist/+merge/456270 I used "Comment Only" here, not "Approve" since the one patch header needed tweaked. How exactly should I handle this sort of thing? | 22:19 |
| tsimonq2 | arraybolt3: I'd still go with Approve, since it's a change you'd do on your end, not something you're asking for the sponsoree to iterate on. | 22:20 |
| arraybolt3 | right, but then of course the branch never is merged since there was a needed tweak. | 22:20 |
| arraybolt3 | unless of course the sponsor's tweak-and-upload counts as a merge in LP? | 22:21 |
| tsimonq2 | That... might be a Robie question. | 22:21 |
| tsimonq2 | My guess is you're right about a manual step needed. | 22:21 |
| arraybolt3 | rbasak: ^ | 22:22 |
| arraybolt3 | for now, leaving as comment only and moving to... | 22:22 |
| sudip | I think the branch itself can not be merged. not sure how the git-ubuntu workflow is supposed to end. the merge request is against debian/sid branch. | 22:22 |
| arraybolt3 | hmm, that sorta makes sense but leaves me with more questions than answers | 22:23 |
| arraybolt3 | I guess git-ubuntu is on my list of things to learn | 22:23 |
| arraybolt3 | alright, do I dare take on an SRU extending all the way back to Focal? | 22:23 |
| arraybolt3 | (looking at horst) | 22:24 |
| arraybolt3 | I'm gonna take it, I've done SRUs before, may as well see how it looks from the opposite side. | 22:25 |
| arraybolt3 | starting with the Noble package, just going to treat it as a normal patch | 22:27 |
| vorlon | tsimonq2: https://bugs.debian.org/1059941 enjoy | 22:28 |
| -ubottu:#ubuntu-devel- Debian bug 1059941 in debhelper "dh_makeshlibs: time_t automatic provides are wrong for libs with previous ABI transition" [Normal, Open] | 22:28 | |
| tsimonq2 | CC LocutusOfBorg ^^^ :) | 22:30 |
| arraybolt3 | horst_noble.debdiff looks *perfect* to me (after comparing it with my checklist). Building, let's see how this works. | 22:30 |
| arraybolt3 | tsimonq2: horst_noble.debdiff builds properly against Noble, has no Lintian tags related to the patch in it, and looks correct to me. Would you agree it looks ready to upload? | 22:34 |
| rbasak | arraybolt3: there's no good answer right now, sorry, just various lengthy options none of which are great. | 22:37 |
| tsimonq2 | arraybolt3: If I wanted to be pedantic I'd add Origin: vendor (or similar), and Author, but neither of those are mandatory per DEP-3 and the sponsoree authored the patch. Concur, LGTM, onward. | 22:39 |
| tsimonq2 | arraybolt3: Oh, right, this is an SRU bug too. Do you think those patches look good as well? | 22:40 |
| arraybolt3 | Haven't reviewed them yet. | 22:40 |
| arraybolt3 | This is why I specified horst_**noble**.debdiff. | 22:40 |
| arraybolt3 | which implicitly excludes all the rest | 22:40 |
| arraybolt3 | (the first one has to get all the way into the archive and make the bug Fix Released in Noble first before the others can be uploaded anyway) | 22:41 |
| arraybolt3 | as per https://wiki.ubuntu.com/StableReleaseUpdates General Requirements - Development Release Fixed First | 22:41 |
| tsimonq2 | You passed another trick question. ;) | 22:42 |
| arraybolt3 | heh, I had a twinge of a feeling that trap might be sprung on me :) | 22:43 |
| arraybolt3 | so for now, the rest of that bug isn't actionable, but it should be either tomorrow or later today. | 22:43 |
| arraybolt3 | And with that... | 22:43 |
| arraybolt3 | @pilot out | 22:44 |
| === 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, tsimonq2 | ||
| arraybolt3 | whew! | 22:44 |
| tsimonq2 | @pilot out | 22:44 |
| === 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 | ||
| arraybolt3 | didn't crash and burn :D | 22:44 |
| tsimonq2 | arraybolt3: Congrats, and thank you. :) | 22:44 |
| arraybolt3 | tsimonq2: thank you! That was awesome. | 22:44 |
| === arraybolt3 is now known as arraybolt3_kde | ||
| === arraybolt3_tl is now known as arraybolt3 | ||
| arraybolt3 | back on my normal IRC client | 22:44 |
| tsimonq2 | In case any other sponsoree is saying "oh wow, that was cool, I want to do this!" - just PM me or a pilot you trust, we'll work it out. :) | 22:45 |
| * sudip is tempted to say "oh wow, that was cool" ;-) | 22:46 | |
| tsimonq2 | sudip: If you feel like you can handle it, PM me :) | 22:49 |
| tsimonq2 | adrien, ogayot, mkukri: Open offer ^^^^ | 22:50 |
| tsimonq2 | arraybolt3: Not so fast, you forgot just one thing. ;) | 23:12 |
| arraybolt3 | uhoh | 23:13 |
| tsimonq2 | arraybolt3: Please make your first post here :) https://discourse.ubuntu.com/t/patch-pilot-hand-off-24-04/39509 | 23:13 |
| arraybolt3 | ohhhh, didn't realize that was part of it | 23:13 |
| tsimonq2 | Mostly optional, I'd say you really should this time around :) | 23:14 |
| tsimonq2 | (Alright, I shouldn't say that, because we *want* people to submit responses there! I'd only call it optional if you did like, one.) | 23:15 |
| tsimonq2 | FTR: https://discourse.ubuntu.com/t/patch-pilot-hand-off-24-04/39509/42 | 23:21 |
| tsimonq2 | @pilot in | 23:27 |
| === 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, tsimonq2 | ||
| tsimonq2 | mkukri: cryptsetup> Just needs some minor tweaks so we can review the diff better. :) | 23:29 |
| tsimonq2 | If there's docs telling you to do it the way you did, I'd be curious. | 23:29 |
| tsimonq2 | I'm really conflicted on bug 2047780. Part of me wants to let it slide, since it's a member of the Desktop Team, but the other part of me wants to reject and ask for an actual *debdiff*, not just debian.tar.* | 23:32 |
| -ubottu:#ubuntu-devel- Bug 2047780 in bluez (Ubuntu) "BlueZ release 5.71" [Medium, In Progress] https://launchpad.net/bugs/2047780 | 23:32 | |
| tsimonq2 | I think I'll be nice. :P | 23:32 |
| tsimonq2 | Oh wonderful, depwait on i386. | 23:43 |
| tsimonq2 | cpete: I see you linked bug 2047961 to its Debian counterpart, any reason it shouldn't be uploaded there instead? | 23:46 |
| -ubottu:#ubuntu-devel- Bug 2047961 in libcgi-application-plugin-authentication-perl (Ubuntu) "build time tests fail with libcgi-pm-perl >=4.58" [Undecided, New] https://launchpad.net/bugs/2047961 | 23:46 | |
| tsimonq2 | I seeeee. https://salsa.debian.org/perl-team/modules/packages/libcgi-application-plugin-authentication-perl/-/merge_requests/1 | 23:47 |
| -ubottu:#ubuntu-devel- Merge 1 in perl-team/modules/packages/libcgi-application-plugin-authentication-perl "Update tests to be compatible with libcgi-perl-pm >=4.58" [Opened] | 23:47 | |
| tsimonq2 | "Upload fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress: 0 days" https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu | 23:48 |
| tsimonq2 | That definitely qualifies, since it hasn't been in Testing since 20231128. NMUing to Debian instead. | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!