Hi all, I emailed the Debian maintainer, and he came back with 3 options for himself:
1. Wait for the next upstream release - Not an option for us, the release cadence on this is ~3 months, meaning the next would be due in October, post beta-freeze, and considering we're beyond feature freeze, this is still a no-go. 2. Adding a permanent epoch - This doesn't solve the problem as an epoch doesn't fix the tarball necessarily. Simply adding a suffix, as Gianfranco pointed out, would. Besides that, I'd avoid this at all costs. 3. Upload a new git snapshot - A git snapshot would also be ill-advised as that's the problem already. What we have is basically a git snapshot of the release *without* the required submodules, therefore an incomplete release tarball. I found the response I got interesting and questionable, and not one I'd expect from someone I'd think to be a seasoned packager. I explained to him that none of his proposals would work and why, but did explain that a re- upload with a +repack suffix on the correct tarball would work. I'm awaiting his next response, which is why I'm willing to give this a few more days. Honestly, the interaction didn't leave me with a whole lot of confidence that the issue will be fixed, so I'm wholly prepared to fix the issue myself. using option #2 that Gianfranco gave and just maintain it until Debian releases a new version in the future, assuming the same mistake doesn't happen again. As I said, I'm willing to give it a few more days, but as I said, I'm not 100% confident we can rely on Debian in this case. Erich On Saturday, August 27, 2022 4:36:00 AM PDT Gianfranco Costamagna wrote: > Hello, I suggest to ask Debian maintainer how to better solve it. > You can1 ask upstream to do a new release and tag 2 repack the source adding > it with +repack suffix3 pack the complete tarball with a different > compression algoritm4 use multiple tarballs for your source (e.g. Nodejs) > In any case better ask and do it on Debian first and then sync, otherwise > we will be bitten by mismatches of tarball checksums. G. > > Sent from Yahoo Mail on Android > > On Sat, Aug 27, 2022 at 6:57, Erich Eickmeyer<eeickme...@ubuntu.com> > wrote: Hi all, > > > During my testing this evening of kdenlive 22.08, I found two issues: > > > kdenlive now needs a recommends on mediainfo. No big deal, bug filed (LP: > #1987934), I can practically take care of that in my sleep. > > > However, it also needs a module in mlt: glaxnimate. Upon investigation, > glaxnimate requires a build-dep on qt5base-dev and a build flag enabled > (-DMOD_GLAXNIMATE=ON). It was at this point that I discovered that the > glaxnimate submodule is *entirely missing* from the source tarball, and > that the wrong tarball was grabbed by the Debian maintainer upstream from > https://github.com/mltframework/mlt/releases/tag/v7.8.0. It seems as though > the maintainer grabbed the github tagged source code tarball (released June > 22nd) and not the intended tarball with all submodules, which came later > (July 3rd). > > > Since this tarball is obviously incorrect, how do we fix this situation? The > maintainer will obviously have to be alerted to the error, but that doesn't > solve the immediate problem with versioning in the archive. As this is a > universe package, I'm more than happy to take care of it as long as I know > how to version it. > > > I can take care of all the necessary steps to write a bug report on this, > but this seemed like a unique situation that I needed some advice on first, > and seemed like it needed more explanation than I can provide on IRC. > > > Thanks, > > Erich -- Erich Eickmeyer Project Leader - Ubuntu Studio Member - Ubuntu Community Council
signature.asc
Description: This is a digitally signed message part.
-- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
