| === lesbraz is now known as sbraz | ||
| === cpaelzer_ is now known as cpaelzer | ||
| === klebers_ is now known as klebers | ||
| 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:13 | |
| 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:24 |
| 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 | 12:55 |
| ahasenack | sru team: I'm looking at apport | 13:11 |
| ahasenack | (unapproved) | 13:11 |
| ahasenack | bdrung: ^ | 13:11 |
| ahasenack | bdrung: that's a whole lot of bugs being fixed in one upload, specially bionic | 13:31 |
| rbasak | ahasenack: I think it's OK to release listserialportsc. I'll do that shortly, when it goes green. | 13:40 |
| ahasenack | hm? | 13:43 |
| 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:51 |
| ahasenack | k | 13:53 |
| 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:06 |
| rbasak | Or is this a pattern we use extensively already? | 14:07 |
| 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:08 |
| rbasak | Though there of course the "ubuntu" isn't necessary. | 14:09 |
| rbasak | I suspect GunnarHj won't have an opinion. I'm asking others generally :) | 14:10 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:20 |
| rbasak | How about I accept these packages today unless someone else comments. | 14:21 |
| rbasak | (as-is) | 14:21 |
| 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:05 |
| enyc | /msg mn3m hello | 15:49 |
| enyc | /msg mn3m hello | 15:49 |
| enyc | aurgh | 15:49 |
| enyc | sorry | 15:49 |
| bdmurray | rbasak: looking at the sync-blacklist I see ubiquity but not update-manager so idk | 16:57 |
| === smoser1 is now known as smoser | ||
| 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:20 |
| ahasenack | bdrung: was your intention for the fix to handle something like this as well? https://pastebin.ubuntu.com/p/6BKfJVHvZP/ | 17:21 |
| ahasenack | here "/bin/ls" is my "abritrary binary data" | 17:22 |
| * tsimonq2 has eyes on the vim ppc64el FTBFS | 17:28 | |
| 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:48 |
| ahasenack | we* | 17:49 |
| 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:50 |
| 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% | 17:52 |
| bdrung | ahasenack, good catch. | 18:56 |
| 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:58 |
| bdrung | the existing fix is better than nothing | 18:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| ahasenack | can you come up with a new fix for it, or would you prefer to drop this change for now? | 19:03 |
| bdrung | the fix is a step in the right direction and needed as base for the other fixes. | 19:04 |
| bdrung | so dropping it would mean reworking the other fix that use the MalformedProblemReport | 19:06 |
| ahasenack | isn't it just a matter of not trying to print the line that caused the problem? | 19:07 |
| bdrung | It's not the printing of the line, it's generating the string for the exception | 19:08 |
| 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 | " | 19:09 |
| 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:17 |
| 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:18 |
| 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:20 |
| 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:26 |
| 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:29 |
| ahasenack | vpa1977: thanks! | 20:30 |
| 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:05 |
| ahasenack | as the hook actually updates PATH when it finds the java executable in the tested paths | 21:06 |
| 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:09 |
| vpa1977 | let me check, one second | 21:11 |
| vpa1977 | ahasenack: I am mistaken, this only applies to keytool. Should I attach another patch? | 21:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| ahasenack | maybe mark the bug as verification-failed then | 21:30 |
| ahasenack | as we will update it one more time | 21:30 |
| vpa1977 | ok | 21:34 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:54 |
| 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:55 |
| 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. | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!