mlt has an incomplete/incorrect tarball

Sat Aug 27 23:12:09 UTC 2022

Hi Erich,

Given the options the Debian maintainer presented, it sounds like they are
not planning themselves on fixing this in the current upstream version.

Having checked that this is the case, I think it's ok for us in Ubuntu to
upload with a new tarball versioned as +repack (or +us - ubuntu source,
analagous to the +ds extension used in Debian), relying on the fact that we
are unlikely to need to sync any critical fixes from Debian between now and
the packaging of the next upstream release.

On Sat, Aug 27, 2022 at 02:26:33PM -0700, Erich Eickmeyer wrote:
> 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

> -- 
> Ubuntu-release mailing list
> Ubuntu-release at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20220827/5bdb8cfb/attachment.sig>