Bug#926118: Alternative for Re: Bug#926118: unblock: libmspack/0.10.1-1
Hi Marc, Starting with this... > I have to say that in the last few years the relationship with the > release team has been of much better quality, more collaboration to > find a solutions together than the BOFH style that was when I first > joined. Here it looks like our arguments are just discarded out of > fear, not by rational analysis. So I feel quite disappointed by how > this BR (and #923885) have been handled so far. I am really sorry that you are perceiving it like this. Bear with me. There are more capable release team members then me, but we're all busy. I am not in the position to perform "deep analysis", mostly because I don't consider myself a programmer and limited time. I can code in scripting languages, but I have never learned to code in C. Obviously I am hesitant. We had more unblocks to deal with, and several weren't easy either. On 06-06-2019 04:23, Marc Dequènes (duck) wrote: > On 2019-06-04 03:53, Paul Gevers wrote: > >>> About this alternative version here: > > Thanks Jens for your help. Comments later on. > >> We prefer this route. > > I provided, as well as other maintainers, maximum information to give > the release team proper materials to get to a decision. > I'd like to have your rationale on this preferred route please. > Currently if feels like no deep analysis was done. Sorry, but also see the above. On top of that, we have had multiple difficult unblock requests and there is so much time in the free part of the day. Going left or right, your request didn't comply with the freeze policy so it requires an exception. So far, you haven't gotten it. I *am* spending time on it. The issue is that *I* am not confident to bless the version in unstable. The alternative version that Jens provided is much better review-able and *we* agreed that that version could be unblocked. >>> I assume a fix for #914794 (libmspack fails tests on big endian >>> architectures (s390x, mips)), reported against 0.9.1-1 is not necessary. >>> However if that was caused by a change in the toolchain instead of >>> changes in the package, I'll also add that fix here. > > This is what caused this situation in the first place, so unless the > release team decides to drop mips and other big endian architectures, > this is a no go. > I did not test the build on these architectures myself with 0.8 but I'm > basing this on upstream's comment that nothing had changed in this area. > Once again it feels the release team did not take time to check on this > case. Which is true on my part. >> Please align. I'll unblock the targeted fix you propose above. Seeing >> the progress on the current package, I don't think you should expect the >> current version to be unblocked before buster. > > I don't understand what progress you're expecting here. We were all > waiting for the release team's decision, or a proposal of what would be > an acceptable upload. > > Currently the current version has been sitting in unstable for three > months without any single bug reported, this feels like a good progress > towards saying this version is safe. It's a valid argument for sure. > I'm not committing to this plan for the above stated reasons. I also > feels uncomfortable uploading with a know security problem, so unless > upstream or our security team says it's low risk, I'm not taking such > responsibility. Sorry, I am mising something here. Can you please point me to it again? Paul signature.asc Description: OpenPGP digital signature
Bug#926118: Alternative for Re: Bug#926118: unblock: libmspack/0.10.1-1
Duck, On 2019-06-04 03:53, Paul Gevers wrote: About this alternative version here: Thanks Jens for your help. Comments later on. We prefer this route. I provided, as well as other maintainers, maximum information to give the release team proper materials to get to a decision. I'd like to have your rationale on this preferred route please. Currently if feels like no deep analysis was done. I assume a fix for #914794 (libmspack fails tests on big endian architectures (s390x, mips)), reported against 0.9.1-1 is not necessary. However if that was caused by a change in the toolchain instead of changes in the package, I'll also add that fix here. This is what caused this situation in the first place, so unless the release team decides to drop mips and other big endian architectures, this is a no go. I did not test the build on these architectures myself with 0.8 but I'm basing this on upstream's comment that nothing had changed in this area. Once again it feels the release team did not take time to check on this case. Please align. I'll unblock the targeted fix you propose above. Seeing the progress on the current package, I don't think you should expect the current version to be unblocked before buster. I don't understand what progress you're expecting here. We were all waiting for the release team's decision, or a proposal of what would be an acceptable upload. Currently the current version has been sitting in unstable for three months without any single bug reported, this feels like a good progress towards saying this version is safe. You can remove the moreinfo tag when the +really package is ready to be unblocked. I'm not committing to this plan for the above stated reasons. I also feels uncomfortable uploading with a know security problem, so unless upstream or our security team says it's low risk, I'm not taking such responsibility. I have to say that in the last few years the relationship with the release team has been of much better quality, more collaboration to find a solutions together than the BOFH style that was when I first joined. Here it looks like our arguments are just discarded out of fear, not by rational analysis. So I feel quite disappointed by how this BR (and #923885) have been handled so far. \_o< -- Marc Dequènes
Bug#926118: Alternative for Re: Bug#926118: unblock: libmspack/0.10.1-1
Control: tags -1 moreinfo confirmed Hi Jens, duck, On 01-06-2019 17:47, Jens Reyer wrote: > I'm posting this now because I'm really worried about the lack of > progress with this issue. However as stated before by me in this bug > here, and by the libmspack maintainer in #923885, we both think that > 0.10.1-1 is for various reasons better, and better tested and thus risk > free. I acknowledge your view. I don't think the freeze time (and process) is great for anybody. > About this alternative version here: > > +libmspack (0.10.1+really0.8-0.1) unstable; urgency=medium > + > + * Non-maintainer upload. > + * Revert back to libmspack/0.8-1. > + * Add build-dependency on quilt. > + * Add patch from upstream to fix regression when extracting cabinets > +using -F option (Closes: #912687). > + > + -- Jens Reyer Sat, 01 Jun 2019 14:32:06 +0200 > + > > > 1.) Versioning and targeted suite > > This proposal reverts the upstream version back from 0.10 (unstable) to > 0.8 (testing), therefore the "new" upstream version 0.10.1+really0.8. > For building I just symlinked the 0.8 orig.tar. > > It's based directly on 0.8-1, dropping all debian/ changes (including > the changelog) since then. > > So this version should be fine to go via unstable (not sure about the > reverted d/changelog)). We prefer this route. > Alternatively we could go via testing-proposed.> > > 2.) Code > > I took only the "fix" part from the upstream commit fixing this, but not > the documentation or updated testsuite (which includes changed binaries). > > I verified that the issue affecting winetricks is solved. > > I assume a fix for #914794 (libmspack fails tests on big endian > architectures (s390x, mips)), reported against 0.9.1-1 is not necessary. > However if that was caused by a change in the toolchain instead of > changes in the package, I'll also add that fix here. > > > > > I'm looking forward to get some feedback from the release team, > preferably by: > > unblock libmspack/0.10.1-1 > > Otherwise please tell us if we should go with this version (targeting > unstable or testing-proposed?), or something else (e.g. filing bugs for > every issue fixed in 0.10.1-1) > > Before (if at all) doing any upload I'll of course coordinate it with > the libmspack maintainer. Please align. I'll unblock the targeted fix you propose above. Seeing the progress on the current package, I don't think you should expect the current version to be unblocked before buster. You can remove the moreinfo tag when the +really package is ready to be unblocked. Paul signature.asc Description: OpenPGP digital signature
Bug#926118: Alternative for Re: Bug#926118: unblock: libmspack/0.10.1-1
control: affects -1 + winetricks cabextract libmspack
Hi,
please find attached a targeted fix for #912687 (libmspack0: Regression
when extracting cabinets using -F option fixed upstream, needs to be
patched). In my (winetricks maintainer) opinion that is the most
pressing issue with libmspack/buster.
I'm posting this now because I'm really worried about the lack of
progress with this issue. However as stated before by me in this bug
here, and by the libmspack maintainer in #923885, we both think that
0.10.1-1 is for various reasons better, and better tested and thus risk
free.
About this alternative version here:
+libmspack (0.10.1+really0.8-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Revert back to libmspack/0.8-1.
+ * Add build-dependency on quilt.
+ * Add patch from upstream to fix regression when extracting cabinets
+using -F option (Closes: #912687).
+
+ -- Jens Reyer Sat, 01 Jun 2019 14:32:06 +0200
+
1.) Versioning and targeted suite
This proposal reverts the upstream version back from 0.10 (unstable) to
0.8 (testing), therefore the "new" upstream version 0.10.1+really0.8.
For building I just symlinked the 0.8 orig.tar.
It's based directly on 0.8-1, dropping all debian/ changes (including
the changelog) since then.
So this version should be fine to go via unstable (not sure about the
reverted d/changelog)).
Alternatively we could go via testing-proposed.
2.) Code
I took only the "fix" part from the upstream commit fixing this, but not
the documentation or updated testsuite (which includes changed binaries).
I verified that the issue affecting winetricks is solved.
I assume a fix for #914794 (libmspack fails tests on big endian
architectures (s390x, mips)), reported against 0.9.1-1 is not necessary.
However if that was caused by a change in the toolchain instead of
changes in the package, I'll also add that fix here.
I'm looking forward to get some feedback from the release team,
preferably by:
unblock libmspack/0.10.1-1
Otherwise please tell us if we should go with this version (targeting
unstable or testing-proposed?), or something else (e.g. filing bugs for
every issue fixed in 0.10.1-1)
Before (if at all) doing any upload I'll of course coordinate it with
the libmspack maintainer.
Greets
jre
diff -Nru libmspack-0.8/debian/changelog libmspack-0.10.1+really0.8/debian/changelog
--- libmspack-0.8/debian/changelog 2018-10-24 03:03:13.0 +0200
+++ libmspack-0.10.1+really0.8/debian/changelog 2019-06-01 14:32:06.0 +0200
@@ -1,3 +1,13 @@
+libmspack (0.10.1+really0.8-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Revert back to libmspack/0.8-1.
+ * Add build-dependency on quilt.
+ * Add patch from upstream to fix regression when extracting cabinets
+using -F option (Closes: #912687).
+
+ -- Jens Reyer Sat, 01 Jun 2019 14:32:06 +0200
+
libmspack (0.8-1) unstable; urgency=medium
* New upstream release:
diff -Nru libmspack-0.8/debian/control libmspack-0.10.1+really0.8/debian/control
--- libmspack-0.8/debian/control 2018-04-12 12:20:00.0 +0200
+++ libmspack-0.10.1+really0.8/debian/control 2019-06-01 14:32:06.0 +0200
@@ -4,7 +4,7 @@
Maintainer: Marc Dequènes (Duck)
Standards-Version: 4.1.4
Build-Depends: dpkg-dev (>= 1.16.1.1), debhelper (>= 11)
-Build-Depends-indep: doxygen, graphviz
+Build-Depends-indep: doxygen, graphviz, quilt
Vcs-Browser: https://salsa.debian.org/debian/libmspack
Vcs-Git: https://salsa.debian.org/debian/libmspack.git
Homepage: https://www.cabextract.org.uk/libmspack/
diff -Nru libmspack-0.8/debian/patches/fix-cabd_extract.patch libmspack-0.10.1+really0.8/debian/patches/fix-cabd_extract.patch
--- libmspack-0.8/debian/patches/fix-cabd_extract.patch 1970-01-01 01:00:00.0 +0100
+++ libmspack-0.10.1+really0.8/debian/patches/fix-cabd_extract.patch 2019-06-01 14:32:06.0 +0200
@@ -0,0 +1,22 @@
+Description: Fix regression when extracting cabinets using -F option
+Origin: upstream, https://github.com/kyz/libmspack/commit/2d86d4e70026cd03730ce0b00b12579c2e21620a
+Bug: https://github.com/kyz/libmspack/issues/22
+Bug-Debian: https://bugs.debian.org/912687
+
+--- a/mspack/cabd.c
b/mspack/cabd.c
+@@ -1125,11 +1125,9 @@ static int cabd_extract(struct mscab_dec
+ * and pass back MSPACK_ERR_READ
+ */
+ self->d->outfh = NULL;
+-if ((self->d->comp_type & cffoldCOMPTYPE_MASK) != cffoldCOMPTYPE_LZX) {
+- if ((bytes = file->offset - self->d->offset)) {
+- error = self->d->decompress(self->d->state, bytes);
+- self->error = (error == MSPACK_ERR_READ) ? self->read_error : error;
+- }
++if ((bytes = file->offset - self->d->offset)) {
++error = self->d->decompress(self->d->state, bytes);
++self->error = (error == MSPACK_ERR_READ) ? self->read_error : error;
+ }
+
+ /* if getting to the correct offset was error free, unpack file */
diff -Nru libmspack-0.8/debian/patches/series
