[12:13] <tobhe> hey! can someone help me with https://bugs.launchpad.net/ubuntu/jammy/+source/arduino/+bug/1916278 . The fix has been sitting in -proposed for a while now and seems to work fine. Is there anything more I can do to signal that it is ready?
[12:13] -ubottu:#ubuntu-devel- Launchpad bug 1916278 in listserialportsc (Ubuntu Jammy) "Arduino fails to start: undefined symbol: sp_get_port_usb_vid_pid" [Undecided, Fix Committed]
[12:24] <rbasak> tobhe: please carefully follow the instructions in comment 42.
[12:24] <rbasak> Specifically, mention which package version you tested, what you verified, what the result was, and then flip the bug tags please.
[12:55] <tobhe> rbasak: thx! i think most of those were answered in #43, I edited the comment to add the exact version and flipped the tags
[13:11] <ahasenack> sru team: I'm looking at apport
[13:11] <ahasenack> (unapproved)
[13:11] <ahasenack> bdrung: ^
[13:31] <ahasenack> bdrung: that's a whole lot of bugs being fixed in one upload, specially bionic
[13:40] <rbasak> ahasenack: I think it's OK to release listserialportsc. I'll do that shortly, when it goes green.
[13:43] <ahasenack> hm?
[13:51] <rbasak> ahasenack: just keeping you in sync with my SRU follow-up stuff from yesterday to avoid any clashing.
[13:51] <rbasak> I'll also handle language-selector. That's on the Trello board so I grabbed it there.
[13:53] <ahasenack> k
[14:06] <rbasak> GunnarHj: so in working out the ideal correct SRU versions for language-selector, I noticed that it's a native package exclusive to Ubuntu (not synced from Debian) but doesn't have 'ubuntu' in it and isn't in the sync blocklist.
[14:06] <rbasak> So I think if Debian published a language-selector package, we'd autosync it, which would definitely not be desirable.
[14:06] <rbasak> Is that a bug? Asking here for a wider audience.
[14:07] <rbasak> Or is this a pattern we use extensively already?
[14:08] <rbasak> More immediately, what are the normative SRU version strings to use?
[14:08] <rbasak> 0.219.1ubuntu0.22.04.1 and 0.219.1ubuntu0.22.10.1 maybe?
[14:09] <rbasak> Though there of course the "ubuntu" isn't necessary.
[14:10] <rbasak> I suspect GunnarHj won't have an opinion. I'm asking others generally :)
[14:14] <rbasak> Right now we have this in the queue:
[14:14] <rbasak> language-selector | 0.219.1       | jammy/unapproved/7e0382b   | source
[14:14] <rbasak> language-selector | 0.219.22.10.1 | kinetic/unapproved/f1dc2af | source
[14:15] <rbasak> This will work in practice, so maybe I'll just accept this and kick this can down the road.
[14:15] <GunnarHj> rbasak: Once upon a time I think they hoped that language-selector would attract other distros. But that didn't happen, so it keeps being an Ubuntu native thing.
[14:15] <GunnarHj> As regards the version string, my thought is that "ubuntu" indicates a delta from Debian, and since that's not the case here (and as you know already) I proposed 0.219.22.10.1 for the kinetic SRU.
[14:15] <rbasak> Unless someone can help me determine something normative.
[14:16] <rbasak> GunnarHj: "ubuntu" does indicate a delta from Debian, but it also has important effect of stopping autosync.
[14:16] <GunnarHj> rbasak: Ah, ok.
[14:17] <rbasak> So I was under the impression that everything in the archive that is exclusive to Ubuntu should have "ubuntu" in the package version string (or a sync blocklist entry) to avoid an accident if Debian were to adopt the package, or package it independently.
[14:17] <rbasak> But, I'm not sure about that now.
[14:17] <rbasak> There might be some other tradition in these cases that I don't know about. Since my experience is mainly with packages with upstreams.
[14:20] <GunnarHj> rbasak: update-manager is a native Ubuntu package which comes to mind. No "ubuntu" in the version string.
[14:20] <rbasak> Maybe we just accept that risk and it's never happened in practice :)
[14:21] <rbasak> How about I accept these packages today unless someone else comments.
[14:21] <rbasak> (as-is)
[15:05] <bdrung> ahasenack, the apport bionic SRU contains the same changes than the focal and jammy SRUs that went through. see https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/apport/+git/apport for a breakdown of the changes
[15:49] <enyc> /msg mn3m hello
[15:49] <enyc> /msg mn3m hello
[15:49] <enyc> aurgh
[15:49] <enyc> sorry
[16:57] <bdmurray> rbasak: looking at the sync-blacklist I see ubiquity but not update-manager so idk
[17:20] <ahasenack> bdrung: in https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1996040 the user gave apport-unpack a core file, instead of a crash file
[17:20] -ubottu:#ubuntu-devel- Launchpad bug 1996040 in apport (Ubuntu Kinetic) "apport-unpack cannot load gitkraken crash report - 'ascii' codec can't decode byte 0xfc in position 56" [Undecided, New]
[17:20] <ahasenack> bdrung: `You specified a core file which contains only binary data and is expected to fail.`
[17:21] <ahasenack> bdrung: was your intention for the fix to handle something like this as well? https://pastebin.ubuntu.com/p/6BKfJVHvZP/
[17:22] <ahasenack> here "/bin/ls" is my "abritrary binary data"
[17:28]  * tsimonq2 has eyes on the vim ppc64el FTBFS
[17:48] <ahasenack> rbasak: if still around, I'm seeing a patch in a SRU that is adding new strings, to a package that is translated. The pot file is not updated with that new string, so it won't benefit from a future language pack update. We never reached a conclusion about these cases in SRUs, did ve?
[17:49] <ahasenack> we*
[17:50] <rbasak> I'm not sure we came up with any kind of policy, no.
[17:50] <ahasenack> I'll add it to the agenda
[17:50] <rbasak> For new strings, I suppose it would make sense to make sure that they are probably translatable, so that new translations will be able to appear in language pack updates?
[17:50] <rbasak> But I'm not very familiar with the technical details of that.
[17:52] <ahasenack> new strings wouldn't be a regression in the sense that they were not there before, but from a pkg pov, now there is an untranslated message there
[17:52] <ahasenack> the package is now 99.9% translated :)
[17:52] <ahasenack> instead of 10%
[17:52] <ahasenack> 100%
[18:56] <bdrung> ahasenack, good catch.
[18:58] <bdrung> ahasenack, I am not sure if we should open a new bug report or reopen this one since the existing fix is only partial.
[18:58] <ahasenack> the existing fix is all the way up to lunar,right?
[18:58] <bdrung> yes
[18:59] <bdrung> the existing fix is better than nothing
[19:00] <ahasenack> the person from that bug ran apport-unpack on a core file directly, right?
[19:00] <ahasenack> that scenario exactly is unlikely to be fixed
[19:01] <ahasenack> nor in itself, alone, worth an sru, I think, but here it's bundled with many other more important fixes
[19:01] <ahasenack> this is one of the problems with bundling many fixes in one upload :)
[19:02] <ahasenack> if one of them isn't super important, but also doesn't fully fix the problem, but the others are fine, what do we do
[19:03] <ahasenack> can you come up with a new fix for it, or would you prefer to drop this change for now?
[19:04] <bdrung> the fix is a step in the right direction and needed as base for the other fixes.
[19:06] <bdrung> so dropping it would mean reworking the other fix that use the MalformedProblemReport
[19:07] <ahasenack> isn't it just a matter of not trying to print the line that caused the problem?
[19:08] <bdrung> It's not the printing of the line, it's generating the string for the exception
[19:09] <bdrung> My plan is to fix that in apport for lunar. You could drop that kinetic SRU and I could include that fix for the kinetic SRU once it landed in lunar.
[19:09] <ahasenack> you have a generic error message in another case, one that just says "+                    raise MalformedProblemReport(
[19:09] <ahasenack> +                        f"Malformed problem report: {error}. "
[19:09] <ahasenack> +                        f"Is this a proper .crash text file?"
[19:09] <ahasenack> "
[20:17] <ahasenack> on systemd, for stable releases, the dep8 test history is quite poor, full of failed tests
[20:17] <ahasenack> and the tests take a very long time (hours)
[20:17] <ahasenack> https://autopkgtest.ubuntu.com/packages/s/systemd/kinetic/amd64 and https://autopkgtest.ubuntu.com/packages/s/systemd/kinetic/arm64 for example
[20:18] <ahasenack> unless there are objections, I will want to commit a badtest hint for it. Which is a shame, because there are tons of tests there
[20:18] <ahasenack> but it's just a lot of wasted time for SRUs (each run takes hours, and the dep8 queue is always exploding)
[20:20] <ahasenack> we can look at each run and determine if the failure is due to a particular sru or not, and then release the sru or not, but at the same time we are supposed to commit hints, right? To have a clean dep8 run
[20:20] <ahasenack> so which is better/worse: not hint, and inspect the failure each time, and manually determine if the failure is relevant or not,
[20:20] <ahasenack> or have a hint, which will guarantee noone will look at the test log, and maybe miss a relevant failure?
[20:26] <ahasenack> for the particular sru I'm looking at (swtpm, #1989100), it just by chance didn't fail on amd64, but the track record of the systemd tests there also seems bad. It feels odd to add a hint just for the arm64 arch which is what is currently blocking the SRU, when the amd64 test could have failed just as likely
[20:29] <vpa1977> @ahasenack: Sorry for missing the comment on https://bugs.launchpad.net/ubuntu/jammy/+source/ca-certificates-java/+bug/1998065, I've replied to it.
[20:30] <ahasenack> vpa1977: thanks!
[21:05] <ahasenack> vpa1977: rbasak: I added a comment to that bug about the java version checks in /etc/ca-certificates/update.d/jks-keystore, if they don't need updating
[21:05] <ahasenack> I think that would fix the remaining "java: command not found" (non-fatal) error
[21:06] <ahasenack> as the hook actually updates PATH when it finds the java executable in the tested paths
[21:09] <vpa1977> ahasenack: it will fail with the different error. When we install java for the first time, all property files have this .dpkg_new extensions (unconfigured) and java will fail to initialize security provider
[21:11] <vpa1977> let me check, one second
[21:23] <vpa1977> ahasenack: I am mistaken, this only applies to keytool. Should I attach another patch?
[21:24] <ahasenack> hm
[21:24] <ahasenack> keytool is that other bug that you mentioned iirc?
[21:24] <ahasenack> under "out of scope"?
[21:24] <vpa1977> yes
[21:24] <ahasenack> and with the version update to the /etc hook, is that last "java not found" also gone? I didn't quite test that, just inspected the code
[21:24] <vpa1977> yes just tested that
[21:25] <ahasenack> excellent
[21:25] <ahasenack> I think an update is in order then
[21:25] <vpa1977> ok, I'll make another patch then and test it with ppa
[21:25] <ahasenack> I can sponsor the upload, as it will need to include the version in proposed currently, in the changes file
[21:25] <ahasenack> ok
[21:25] <ahasenack> since this is in proposed already, you will need a version bump
[21:26] <ahasenack> so, ...., 20190909ubuntu1.1 I think
[21:26] <ahasenack> let me check
[21:26] <ahasenack> yep
[21:26] <vpa1977> cool, thanks a lot for help!!!!!!!
[21:30] <ahasenack> maybe mark the bug as verification-failed then
[21:30] <ahasenack> as we will update it one more time
[21:34] <vpa1977> ok
[23:47] <arraybolt3> According to https://packages.ubuntu.com/search?keywords=linux-image-generic, Kinetic's linux-image-generic package is at version 5.19.0.26.23, while Lunar's is 5.19.0.21.21.
[23:48] <arraybolt3> Two questions. One, why is Lunar accidentally getting skipped for security updates? (At least that's what looks like is happening.)
[23:48] <arraybolt3> Two, does this not break package versioning policy?
[23:48] <arraybolt3> s/accidentally// (if it is an accident, asking why is kinda silly :P)
[23:49] <arraybolt3> And actually, a third question - if this is normal, does Lunar typically miss security updates? Would it be wise for me to reinstall my system with Kinetic so that I get security updates properly?
[23:54] <amurray> the security team does not officially support the dev release - we do try to patch this where it makes sense but sometimes it is better to wait for say debian to patch and then we can get the fix without introducing a merge conflict
[23:55] <amurray> I can't speak directly for the kernel team but I think they also do not focus on doing security fixes for the devel release either
[23:55] <arraybolt3> Oh tar. That explains it.
[23:55] <arraybolt3> And I see that the "linux" package has been held up for over two months in -proposed due to a purposefully imposed block.
[23:55] <amurray> so from a security point of view, it is definitely better to run one of the stable releases
[23:56] <arraybolt3> Welp, alrighty then, I guess I'll probably be reinstalling my laptop pretty soon then.
[23:56] <arraybolt3> I've been daily-driving the development release since I do development, and thought that the way packaging worked meant that I would get all of the updates, including security ones.