[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#717420: update reSIProcate in stable from 1.8.5 -> 1.8.12



On 21/07/13 20:15, Adam D. Barratt wrote:
> On Sat, 2013-07-20 at 20:26 +0200, Daniel Pocock wrote:
>> Package: release.debian.org
>> Severity: important
> Nope. Bugs in packages may have all kinds of severities, requests to
> update packages in stable are "normal" at best. (It would also be
> helpful if you used reportbug or otherwise normalised the usertags and
> titles when making such requests.)
>
> For the record, I had to dig the mail to which I'm replying out of a BTS
> mbox; it never reached the debian-release list, presumably due to the
> size of the diff.


Ok, if I submit something like this again, I'll include a link to the
git web diff


>
>> We've found that versions of reSIProcate < 1.8.11-4 are not reliable on
>> non-Intel platforms.
> Does anyone actually use the package on such architectures?

I don't know

However, I understand it is important to ensure people have a positive
experience with Debian and even if just one person tries this package on
PowerPC or S/390 I wouldn't want to knowingly let them waste time on a
flawed version of the package.


>> In particular, essential code such as the MD5 implementation was not
>> being compiled the right way for big endian systems.  The code may
>> appear to compile and run but as soon as a user tries to engage in a
>> DIGEST authentication they will find that it fails to operate correctly.
> [...]
>> A long list of other bug fixes is also included, several of them
>> eliminate bugs that can cause a crash
>>
>> The cumulative effect of all bug fixes on the 1.8.x release branch
>> brings a significant improvement in quality and convenience for end users.
> The _filtered_ diffstat is "189 files changed, 5819 insertions(+), 2235

A lot of that is because the autotools artifacts (e.g. Makefile.in) are
quite big and have been regenerated on each release

Other things can also be ignored, for example, there are lots of XML
files for the Windows build system (Visual Studio) but those are ignored
on Linux builds.  All the changes in those files are ignored.

I could provide a diff that eliminates changes in such files.

> deletions(-)" and adds two new packages. We'd need a lot of convincing
> that the latter is worth doing, rather than just proving updates via
> backports (fwiw, I'm only aware of one occasion where a new package was
> introduced to a release once it was stable, and that was
> openssh-blacklist via security.d.o, which is a somewhat different
> situation).

That is because I diffed the tag for the wheezy package against the tag
on the unstable package

If you are comfortable with the basic aim of updating this package, then
I will merge the 1.8.12 upstream release with the original wheezy
packaging artifacts and submit a more precise diff for final approval. 
The set of packages will then remain the same, no new package will be added.


Reply to: