=== lesbraz is now known as sbraz === cpaelzer_ is now known as cpaelzer === klebers_ is now known as klebers [12:13] 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] tobhe: please carefully follow the instructions in comment 42. [12:24] Specifically, mention which package version you tested, what you verified, what the result was, and then flip the bug tags please. [12:55] 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] sru team: I'm looking at apport [13:11] (unapproved) [13:11] bdrung: ^ [13:31] bdrung: that's a whole lot of bugs being fixed in one upload, specially bionic [13:40] ahasenack: I think it's OK to release listserialportsc. I'll do that shortly, when it goes green. [13:43] hm? [13:51] ahasenack: just keeping you in sync with my SRU follow-up stuff from yesterday to avoid any clashing. [13:51] I'll also handle language-selector. That's on the Trello board so I grabbed it there. [13:53] k [14:06] 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] So I think if Debian published a language-selector package, we'd autosync it, which would definitely not be desirable. [14:06] Is that a bug? Asking here for a wider audience. [14:07] Or is this a pattern we use extensively already? [14:08] More immediately, what are the normative SRU version strings to use? [14:08] 0.219.1ubuntu0.22.04.1 and 0.219.1ubuntu0.22.10.1 maybe? [14:09] Though there of course the "ubuntu" isn't necessary. [14:10] I suspect GunnarHj won't have an opinion. I'm asking others generally :) [14:14] Right now we have this in the queue: [14:14] language-selector | 0.219.1 | jammy/unapproved/7e0382b | source [14:14] language-selector | 0.219.22.10.1 | kinetic/unapproved/f1dc2af | source [14:15] This will work in practice, so maybe I'll just accept this and kick this can down the road. [14:15] 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] 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] Unless someone can help me determine something normative. [14:16] GunnarHj: "ubuntu" does indicate a delta from Debian, but it also has important effect of stopping autosync. [14:16] rbasak: Ah, ok. [14:17] 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] But, I'm not sure about that now. [14:17] 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] rbasak: update-manager is a native Ubuntu package which comes to mind. No "ubuntu" in the version string. [14:20] Maybe we just accept that risk and it's never happened in practice :) [14:21] How about I accept these packages today unless someone else comments. [14:21] (as-is) [15:05] 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] /msg mn3m hello [15:49] /msg mn3m hello [15:49] aurgh [15:49] sorry [16:57] rbasak: looking at the sync-blacklist I see ubiquity but not update-manager so idk === smoser1 is now known as smoser [17:20] 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] bdrung: `You specified a core file which contains only binary data and is expected to fail.` [17:21] bdrung: was your intention for the fix to handle something like this as well? https://pastebin.ubuntu.com/p/6BKfJVHvZP/ [17:22] here "/bin/ls" is my "abritrary binary data" [17:28] * tsimonq2 has eyes on the vim ppc64el FTBFS [17:48] 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] we* [17:50] I'm not sure we came up with any kind of policy, no. [17:50] I'll add it to the agenda [17:50] 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] But I'm not very familiar with the technical details of that. [17:52] 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] the package is now 99.9% translated :) [17:52] instead of 10% [17:52] 100% [18:56] ahasenack, good catch. [18:58] 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] the existing fix is all the way up to lunar,right? [18:58] yes [18:59] the existing fix is better than nothing [19:00] the person from that bug ran apport-unpack on a core file directly, right? [19:00] that scenario exactly is unlikely to be fixed [19:01] nor in itself, alone, worth an sru, I think, but here it's bundled with many other more important fixes [19:01] this is one of the problems with bundling many fixes in one upload :) [19:02] 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] can you come up with a new fix for it, or would you prefer to drop this change for now? [19:04] the fix is a step in the right direction and needed as base for the other fixes. [19:06] so dropping it would mean reworking the other fix that use the MalformedProblemReport [19:07] isn't it just a matter of not trying to print the line that caused the problem? [19:08] It's not the printing of the line, it's generating the string for the exception [19:09] 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] you have a generic error message in another case, one that just says "+ raise MalformedProblemReport( [19:09] + f"Malformed problem report: {error}. " [19:09] + f"Is this a proper .crash text file?" [19:09] " [20:17] on systemd, for stable releases, the dep8 test history is quite poor, full of failed tests [20:17] and the tests take a very long time (hours) [20:17] https://autopkgtest.ubuntu.com/packages/s/systemd/kinetic/amd64 and https://autopkgtest.ubuntu.com/packages/s/systemd/kinetic/arm64 for example [20:18] 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] but it's just a lot of wasted time for SRUs (each run takes hours, and the dep8 queue is always exploding) [20:20] 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] 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] or have a hint, which will guarantee noone will look at the test log, and maybe miss a relevant failure? [20:26] 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] @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] vpa1977: thanks! [21:05] 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] I think that would fix the remaining "java: command not found" (non-fatal) error [21:06] as the hook actually updates PATH when it finds the java executable in the tested paths [21:09] 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] let me check, one second [21:23] ahasenack: I am mistaken, this only applies to keytool. Should I attach another patch? [21:24] hm [21:24] keytool is that other bug that you mentioned iirc? [21:24] under "out of scope"? [21:24] yes [21:24] 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] yes just tested that [21:25] excellent [21:25] I think an update is in order then [21:25] ok, I'll make another patch then and test it with ppa [21:25] I can sponsor the upload, as it will need to include the version in proposed currently, in the changes file [21:25] ok [21:25] since this is in proposed already, you will need a version bump [21:26] so, ...., 20190909ubuntu1.1 I think [21:26] let me check [21:26] yep [21:26] cool, thanks a lot for help!!!!!!! [21:30] maybe mark the bug as verification-failed then [21:30] as we will update it one more time [21:34] ok [23:47] 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] Two questions. One, why is Lunar accidentally getting skipped for security updates? (At least that's what looks like is happening.) [23:48] Two, does this not break package versioning policy? [23:48] s/accidentally// (if it is an accident, asking why is kinda silly :P) [23:49] 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] 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] 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] Oh tar. That explains it. [23:55] 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] so from a security point of view, it is definitely better to run one of the stable releases [23:56] Welp, alrighty then, I guess I'll probably be reinstalling my laptop pretty soon then. [23:56] 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.