| bluca | bdmurray: 403 is back today on s390x, job on bos01: https://autopkgtest.ubuntu.com/results/autopkgtest-focal-upstream-systemd-ci-systemd-ci/focal/s390x/s/systemd-upstream/20220725_082147_60aa9@/log.gz | 09:47 |
|---|---|---|
| bdrung | graingert[m], I don't have a bug report for the KeyError, because it was i drive-by fix. I prepared SRUs for jammy and focal which contain the fix. See https://bugs.launchpad.net/apport/+bug/1982555 | 10:08 |
| ubottu | Launchpad bug 1982555 in apport (Ubuntu) "core dump file empty inside container" [Medium, Triaged] | 10:08 |
| bdrung | graingert[m], here is the commit where I initially applied the fix: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/apport/commit/?id=2073b90d5da4772306c467bda2d0b9c5edd9fb70 | 10:10 |
| ubottu | Commit 2073b90 in ~ubuntu-core-dev/ubuntu/+source/apport "Fix KeyError: 'CasperMD5json'" | 10:10 |
| graingert[m] | bdrung: Thanks! | 10:11 |
| bdrung | graingert[m], the ubuntu-core-dev git repository has the individual commits | 10:11 |
| graingert[m] | What's the general process to go from a launchpad issue to a commit code review? | 10:12 |
| bdrung | graingert[m], for apport or a general package? | 10:14 |
| graingert[m] | General package | 10:14 |
| graingert[m] | My inexperience with launchpad is slowing me down | 10:14 |
| bdrung | graingert[m], I normally try to find the packaging git repository (Vcs-* fields in debian/control), since that has normally the most fine grained commit history. If the package version is unchanged from Debian, I check on tracker.debian.org. | 10:16 |
| bdrung | e.g. apport has: Vcs-Browser: https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/apport/+git/apport | 10:16 |
| bdrung | Vcs-Git: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/apport | 10:17 |
| graingert[m] | How to I get from the vcs to the review? | 10:19 |
| graingert[m] | s/to/do/ | 10:19 |
| bdrung | graingert[m], to which review? | 10:20 |
| graingert[m] | Sorry I don't understand the question | 10:22 |
| graingert[m] | I'm used to a workflow that's like issue logged -> fix proposed -> fix approved -> fix released | 10:23 |
| graingert[m] | And there are hyperlinks between every stage | 10:24 |
| graingert[m] | So the review would be the part of the workflow between fix proposed and fix approved | 10:26 |
| bdrung | you can propose a fix by adding a patch to the bug report or open a merge request against the packaging branch or pointing a upstream commits that just needs to be cherry-picked | 10:28 |
| graingert[m] | no I mean I'm looking to find the review of a released patch | 10:36 |
| bdrung | graingert[m], it depends. If someone with upload privileges fixes a bug (like me in this case), I didn't need any review. | 10:39 |
| graingert[m] | like I find some code I don't understand, I use a mix of git annotate and git pickaxe to find what changed and then I find the associated issue tracker to find out what motivated a change and then I use the review to find out why a particular approach was chosen | 10:39 |
| bdrung | that's a good approach, but (like in this case) there is not always a bug report for an issue. then you won't find the information (besides what you find in the relevant commits) | 10:40 |
| graingert[m] | yeah so in that case I would comment on the review and ask for the context if it was missing | 10:46 |
| graingert[m] | eg is there a way to see which branches https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/apport/commit/?id=2073b90d5da4772306c467bda2d0b9c5edd9fb70 is in? | 10:48 |
| ubottu | Commit 2073b90 in ~ubuntu-core-dev/ubuntu/+source/apport "Fix KeyError: 'CasperMD5json'" | 10:48 |
| bdrung | graingert[m], you can check that in a local checkout: git branch -r --contains 2073b90d5da4772306c467bda2d0b9c5edd9fb70 | 10:54 |
| graingert[m] | yeah I just cloned it locally and now everything works | 10:54 |
| bdrung | graingert[m], but this will not show the branches that cherry-pick that fix (because the hash sum changes in that case) | 10:54 |
| graingert[m] | yeah that's fine, I can do that manually once I have the original commit | 10:55 |
| GunnarHj | Hi doko, are these observations on symbols files and LTO generally true? | 11:01 |
| GunnarHj | https://irclogs.ubuntu.com/2022/07/25/%23ubuntu-desktop.html#t08:45 | 11:01 |
| graingert[m] | <bdrung> "graingert, I don't have a bug..." <- is https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1982685 a dup of https://bugs.launchpad.net/apport/+bug/1982555 ? | 11:08 |
| ubottu | Launchpad bug 1982685 in apport (Ubuntu) "automatic bug reporting collects failure information then fails to submit to launchpad" [Undecided, New] | 11:08 |
| ubottu | Launchpad bug 1982555 in apport (Ubuntu) "core dump file empty inside container" [Medium, Triaged] | 11:08 |
| bdrung | graingert[m], no, that a different issue. | 11:11 |
| graingert[m] | ah dang ok | 11:11 |
| bdrung | graingert[m], let me comment your bug. | 11:11 |
| graingert[m] | thanks | 11:11 |
| graingert[m] | I managed to get another repeat today | 11:16 |
| graingert[m] | does apport stop intercepting core dumped after a number of cycles? | 11:16 |
| graingert[m] | * repeat today so I attached a screenshot | 11:16 |
| bdrung | graingert[m], apport will record identical crashes in just one file and count the occurrences | 11:17 |
| graingert[m] | ah so it stops reporting after the first crash even if I click "send"? | 11:20 |
| bdrung | graingert[m], yes. apport knows that is the same issues and it won't report the same issue again. | 11:21 |
| graingert[m] | even if I tick "ignore future problems of this program version" | 11:21 |
| graingert[m] | * if I do not tick "ignore | 11:21 |
| graingert[m] | * if I do not tick "ignore, * program version"? | 11:21 |
| bdrung | yes. if you tick that box, all other crashes of this program version will be ignored. if you don't tick it, it will present a windows to report crashes of that program that are different. | 11:23 |
| graingert[m] | ah | 11:29 |
| graingert[m] | I never want to tick that box and I always want to see apport | 11:29 |
| graingert[m] | is there a way to enable that behavior? | 11:29 |
| graingert[m] | eg in my case a reboot or a day passing seemed to make apport think it was a different crash | 11:30 |
| alexghiti | Hi here, could someone trigger this autopkgtest for me please? https://autopkgtest.ubuntu.com/request.cgi/?release=kinetic&arch=amd64&package=libisoburn&ppa=alexghiti%2Friscv&trigger=libisofs%2F1.5.4-1ubuntu1~ppa1 | 11:35 |
| alexghiti | Thanks | 11:35 |
| bdrung | alexghiti, done | 11:36 |
| alexghiti | brrung: Thanks! | 11:37 |
| alexghiti | bdrung sorry for the typo :) | 11:37 |
| bdrung | graingert[m], you can have a look in /var/crash and compare the crashes to see why apport thinks its different | 11:37 |
| bdrung | alexghiti, i have seen worse typos :D | 11:37 |
| graingert[m] | there's only one crash in there | 11:39 |
| bdrung | hm, that's strange | 11:39 |
| graingert[m] | I think I'm leaning dangerously into support territory rather than dev | 11:39 |
| graingert[m] | $ ls /var/crash/ | 11:40 |
| graingert[m] | _usr_bin_python3.10.1000.crash _usr_libexec_fprintd.0.crash _usr_share_mu-editor_mu-editor.1000.crash | 11:40 |
| graingert[m] | _usr_bin_python3.8.1000.crash _usr_libexec_fprintd.0.upload _usr_share_mu-editor_mu-editor.1000.upload | 11:40 |
| graingert[m] | _usr_bin_python3.9.1000.crash _usr_libexec_fprintd.0.uploaded _usr_share_mu-editor_mu-editor.1000.uploaded | 11:40 |
| graingert | sorry about that matrix decided not to pastebin that | 11:41 |
| graingert[m] | are there logs I can see of what apport tried to do yesterday | 11:43 |
| graingert[m] | * do yesterday? | 11:43 |
| graingert[m] | and is there a cli to upload just _usr_share_mu-editor_mu-editor.1000.crash ? | 11:56 |
| graingert[m] | ash there is | 12:09 |
| graingert[m] | * ah there is, same behaviour | 12:10 |
| graingert[m] | brekapoint time | 12:10 |
| alexghiti | Can someone trigger this autopkgtest for me please? https://autopkgtest.ubuntu.com/request.cgi/?release=kinetic&arch=amd64&package=libisoburn&ppa=alexghiti/riscv&trigger=libisoburn/1:1.5.4-2ubuntu3~ppa0 | 12:35 |
| alexghiti | Thanks! | 12:35 |
| amurray | alexghiti: done | 13:01 |
| alexghiti | amurray: Thanks! | 13:01 |
| ogayot | Hi, would a core dev mind triggering this autopkgtest? I'd appreciate it! | 14:27 |
| ogayot | https://autopkgtest.ubuntu.com/request.cgi?release=kinetic&arch=ppc64el&package=zfs-linux&trigger=python3-stdlib-extensions%2F3.10.5-2ubuntu2&trigger=linux-meta%2F5.19.0.10.10&trigger=linux-signed%2F5.19.0-10.10&trigger=linux%2F5.19.0-10.10 | 14:27 |
| Eickmeyer[m] | Hi vorlon ! Looks like digikam completely FTBFS against libavcodec59. | 15:29 |
| vorlon | yep | 15:30 |
| Eickmeyer[m] | I can look upstream and see if there's a patch or if it's being worked on. | 15:30 |
| vorlon | that would be ideal :) | 15:31 |
| Eickmeyer[m] | vorlon: Doesn't seem they're aware of the issue. I'll file a bug report in both Launchpad and upstream at KDE. | 15:39 |
| vorlon | Eickmeyer[m]: not ideal that they're not aware, the compiler has been spitting deprecation warnings with previous ffmpeg releases for a while now | 15:43 |
| vorlon | but ok | 15:43 |
| Eickmeyer[m] | This should make them aware. | 15:43 |
| KBar | Hello. Why does Ubuntu provide mawk as the default interpreter of AWK? Why the preference over gawk? | 15:47 |
| rbasak | KBar: I don't know of the actual reason (it's probably inheriting that decision from Debian) but gawk is about ten times bigger. | 15:55 |
| rbasak | And also pulls in other dependenciser | 15:55 |
| rbasak | It also claims to be much faster. | 15:55 |
| rbasak | So for a core system component I think that probably makes more sense? | 15:56 |
| jawn-smith | ogayot: done | 15:57 |
| rbasak | !dmb-ping | 16:00 |
| ubottu | bdmurray, kanashiro, rbasak, seb128, sil2100, teward, utkarsh2102: DMB ping | 16:00 |
| ogayot | jawn-smith: thanks! | 16:01 |
| teward | alive | 16:10 |
| teward | i was on a walk sorry rbasak | 16:10 |
| KBar | rbasak: hmm, Debian also defaults to mawk, so it's probably that. Claiming "to be much faster", however, doesn't always turn out to be true. For their size, are you going with the 'Installed-Size' control field? | 16:11 |
| rbasak | KBar: that's what I looked at, yes. I understand that doesn't necessarily accurate picture, but it's a starting point. AFAICT, the sense of your question is framed backwards. Why should gawk be the default? | 16:14 |
| KBar | rbasak: you're right. I was just curious, because Ubuntu uses many of GNU's utilities, and then bam, mawk for AWK :). Gawk seems to provide some nice features like true multidimensional arrays, asort() for sorting arrays, and I think '\x' escape sequences may come in handy (parsing and printing them directly, instead of converting to octal?). I believe it should have the --posix option which strips off these extra features, which i | 16:25 |
| KBar | n turn may speed up the execution? | 16:25 |
| rbasak | KBar: gawk is available though, and most uses of awk don't use advanced awk features. | 16:26 |
| KBar | There's probably some mawk scripts on Debian that could potentially break, and also it's the mysterious, unknown AWK :) | 16:26 |
| bdmurray | bluca: the bos01 issue still needs to be addressed by Canonical IS. I had disabled bos01 due to networking issues but then we ended up losing ground with the queue so I reenabled some workers there. My plan is to look at the code and see if we can selectively run tests in one region. | 16:40 |
| bluca | got it, thanks | 16:44 |
| Eickmeyer[m] | vorlon: Wanna get ready for a hard facepalm? https://bugs.kde.org/show_bug.cgi?id=457121 | 16:49 |
| ubottu | KDE bug 457121 in digikam "digikam 7.7.0 FTBFS against libavcodec59" [Grave, Unconfirmed] | 16:49 |
| dbungert | Would someone assist with some test runs? Needed another trigger. https://paste.ubuntu.com/p/n4HtP9tKR5/ | 17:11 |
| vorlon | Eickmeyer[m]: <shrug> FWIW I have found it difficult to migrate some packages to ffmpeg 5, too; one of my migrations went wrong despite following the upstream samples, but fortunately was caught by the robust test suite | 17:20 |
| bdmurray | dbungert: I can do that | 17:20 |
| Eickmeyer[m] | vorlon: Sure. I guess we can just wait for them to release a new version, whenever that is. | 17:21 |
| Eickmeyer[m] | Seems like that's what they're implying. | 17:21 |
| vorlon | Eickmeyer[m]: is that new upstream version available as a prerelease? If so I would just pull that branch in sooner rather than later; since the current package can't be shipped in kinetic | 17:22 |
| Eickmeyer[m] | vorlon: Right. I'll investigate, but I saw nothing in their git repo. | 17:23 |
| vorlon | ok | 17:23 |
| vorlon | fwiw if I *have* to, I stand half a chance of succeeding in porting it; I just figured for such a high-profile and actively maintained package it wouldn't be necessary so I had skipped over it when going through revdeps | 17:24 |
| Eickmeyer[m] | vorlon: Sure. The high-profile part (and that it's seeded in Studio) is one reason why I'm jumping on this sooner rather than later. It's pretty much the premiere photo management app in Studio now. | 17:26 |
| dbungert | bdmurray: thanks as always | 17:28 |
| === lucas_ is now known as lucascastro | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!