mlt has an incomplete/incorrect tarball

[Erich Eickmeyer]

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<eeickmeyer at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20220827/8356b9e8/attachment.sig>