Re: mlt has an incomplete/incorrect tarball
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 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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: mlt has an incomplete/incorrect tarball
Thanks, Steve! I'll go ahead and proceed with the +us plan seeing as how +repack just simply didn't seem like a good description. :) On Saturday, August 27, 2022 4:12:09 PM PDT Steve Langasek wrote: > 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. > -- Erich Eickmeyer Project Leader - Ubuntu Studio Member - Ubuntu Community Council signature.asc Description: This is a digitally signed message part. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: mlt has an incomplete/incorrect tarball
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 > > 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@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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP
Re: mlt has an incomplete/incorrect tarball
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 > 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-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: mlt has an incomplete/incorrect tarball
Sure! That actually sounds reasonable. I'll contact the maintainer and see what they say. 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. > signature.asc Description: This is a digitally signed message part. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
mlt has an incomplete/incorrect tarball
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[1]), 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[2]. 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 [1] https://launchpad.net/bugs/1987934 [2] https://github.com/mltframework/mlt/releases/tag/v7.8.0 signature.asc Description: This is a digitally signed message part. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
