[14:07] mwhudson: oh yeah, I did. I think I was thinking that I would give it a day or so then didn't get back to it [14:10] mwhudson: done [14:30] What's that fancy command for comparing two package version numbers to see which one is larger? [14:30] nvm, found it [14:33] Could I ask for sponsorship for the Manuskript bug fix here? https://bugs.launchpad.net/ubuntu/+source/manuskript/+bug/1989203 There's patches to fix the bug in both Jammy and Kinetic, and I believe the bug is already fixed in Lunar. [14:33] -ubottu:#ubuntu-devel- Launchpad bug 1989203 in manuskript (Ubuntu Kinetic) "Manuskript crashes on start" [High, Confirmed] [14:49] Also if someone with the necessary powers can add Lunar to the list of versions in the bug and set the bug status in Lunar to Invalid, that would be helpful (the bug is absent in Lunar). [14:51] arraybolt3: it should be Fix Released then. I'll set it. [14:51] Thanks! [14:51] (And *this* is why I don't have these powers myself yet :P) [14:56] arraybolt3: a 4MB diff to apply all the changes in 0.12.0 -> 0.14.0 is not appropriate [14:57] if it is you intention to completely update to 0.14.0 then it should be that backported as a source tar plus packaging [14:58] or if just to fix that crash in the bug, the fix as a single patch applied to 0.12.0 [14:58] The intention is a complete update. I do not know where the documentation is for doing a source tar plus packaging. [14:59] (It is mainly to fix the one bug, but there's a ton of other bug fixes that come with the full upgrade, and it appears to be a fully bug-fix-only update.) [15:00] is this the crash fix? https://github.com/olivierkes/manuskript/commit/15edb6efb7305b9d1a192712660857ca38facace [15:00] -ubottu:#ubuntu-devel- Commit 15edb6e in olivierkes/manuskript "Fixed issue #957 enforcing types supported by spec for QColor" [15:00] (Also FWIW I did have a core dev check my work, and he seemed to approve.) [15:01] RikMills: Yeah, that looks like it, but the full update would be preferable. [15:05] I am noticing now though, I can't find a documented QA process in the upstream code. I think this is something that may have gotten missed when I was told this looked OK. [15:06] Hmm. Then I may have to just backport that one fix. *Sigh.* Alright, thank you guys for helping! [15:06] also your patch updatyes debian/changelog to 0.14.0 to upload with the 0.12.0 tar. not going to work [15:08] if 0.12.0 is completely useless due to the crash, updating to 0.14.0 may be reasonable. see what the SRU team think [15:08] RikMills: Really? Hold on, that doesn't sound right. I just did the same thing I always do when upgrading a package to a new upstream release. Where is the docs about the tarballs? [15:08] (re: 0.12.0 tar) [15:09] I have the 0.14.0 tar in my working environment, so obviously I'm missing something. [15:10] if you intend to have the 0.14.0 tart uploaded, you don't need your 4MB diff [15:10] *tar [15:10] Right but *where do I upload it at*? [15:10] just packaging to sponsor with it [15:10] (This is a part of the world of packaging I have never encountered, so I may be a bit further behind the curve than you expect.) [15:11] arraybolt3: a ppa is usually good [15:11] Wait a minute, I think I just got it. You mean all of the source code files that are in the same folder with the debian folder, right? [15:12] The way I always package, I have a folder with just a debian folder inside it, I work on the packaging and use uscan to get the tarball. Then sbuild uses the upstream tarball and the packaging info and turns it into a package, and everything just works. [15:12] This has worked with ppas, and for Lubuntu packages, so I don't know what I'm missing for this one. [15:12] I mean the orig.tar for 0.14.0 and a debian.tar.xz with the debian folder [15:12] I upload those two things rather than the debdiff? [15:13] if you want to ship the actual new release, then a debdiff is not the thing to do [15:13] a debdiff with be if you are only patching the current release [15:14] *would be [15:14] OK. I didn't know that until now. Thank you for clarifying! [15:14] go one way or the other. either is good [15:15] but as said, check with the SRU team on shipping the whole 0.14.0 [15:15] Also is this process documented anywhere so I can bookmark it for later? [15:15] I don't see anything about upgrading to a new upstream release in the Packaging in Ubuntu guide. [15:15] That being said, that guide looks awfully old, I'm looking at https://packaging.ubuntu.com/html/ [15:18] long time since I had to look.... [15:21] the debian folder packaging delta between 0.12.0-1 and 0.14.0-1 looks very minimal, so it should be relatively simple to take the 0.14.0-1 and makes changes to make it a SRU [15:22] 0.12.0-1 -> 0.14.0-1 is a dropped patch, standards bump, and the changelog. that is all [15:22] for the packaging [15:23] Pretty much, I think I did almost exactly that, but then uploaded as a debdiff. [15:23] You'll see the packaging changes buried somewhere in there. [15:23] But at any rate, if I did it wrong on accident, I'll redo it the right way. Should be a matter of just uploading the right files (I have them all on my computer right now). [15:23] Shoot, let's upload them. [15:25] Thanks for your help! [15:26] hope it got you a bit further [15:27] OK can you check it again and tell me if that was right? [15:29] a ppa package would make it easier for a sponsor [15:30] they would just have to dget the .dsc and be able to see the build logs [15:31] and would demonstrate that it builds and works on the target release [15:31] That makes sense. [15:32] And I have the .dsc files so :D [15:32] I'll figure this out eventually. I thought you meant a PPA was good for learning what I was doing for some reason... [15:34] Er, the source.changes files. [15:40] RikMills: Thank you for all your help here! I have the PPA building. [15:40] (And I linked to it in the bug report.) [16:01] !dmb-ping [16:01] bdmurray, kanashiro, rbasak, seb128, sil2100, teward, utkarsh2102: DMB ping [23:16] Hah, wait so the reason xfwm4 won't migrate is a regression in ubiquity tests on ppc64el? :D