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

Bug#773212: unblock: 0xffff/0.6.1-1



On Fri, Dec 19, 2014 at 05:03:04PM +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Dec 19, 2014 at 02:18:28PM +0100, Pali Rohár wrote:
> > On Wednesday 17 December 2014 20:52:00 Jonathan Wiltshire wrote:
> > > On Wed, Dec 17, 2014 at 02:04:57PM +0100, Pali Rohár wrote:
> > > > > We're really looking at targetted fixes for RC bugs at
> > > > > this stage. Is there anything in the release that is
> > > > > worth cherry- picking with that in mind?
> 
> The release is 50% fixes of memory leaks and 50% fixes of return
> code and size checks being added. I guess at least the second part
> is RC stuff. TBH I'm not fond of backporting 50% of the minor
> release, though.
> 
> > > > Hello Jonathan, I'm main developer of 0xFFFF application and
> > > > I would say that everybody who use 0xFFFF 0.6 release
> > > > *must* upgrade to new version 0.6.1. It is really bugfix
> > > > version and it does not make sense to do any
> > > > cherry-picking. You should apply all patches from 0.6 to
> > > > 0.6.1, so if you generate & apply cherry- picked patches on
> > > > top of 0.6 you will have same tarball as 0.6.1.
> > > 
> > > Thanks for your input, but we really are looking for
> > > targetted, specific release-*critical* bug fixes now.
> > > "Because upstream said so" is, I'm afraid, not a good reason.
> > 
> > Jonathan, I do not know how you are tracking bugs critical bugs 
> > in Debian and how you consider what is critical and what is 
> > not... but you either has better knowledge of 0xFFFF code as 
> > upstream developers (= me) and you can ignore any info from 
> > upstream or you did not understand what new security dot release 
> > of 0xFFFF application mean.
> 
> ... or Debian does not rate some of your "security patches" as
> release critical ...
> 
> > [...]
> 
> > But if you decided and you want to have version of 0xFFFF in 
> > Debian repository for stable Debian releases which cause big 
> > problems with flashing firmwares on Nokia N900 (e.g software 
> > locks, device bricks, etc) I just start informing all my users of 
> > 0xFFFF flashing application to immediately *STOP* using Debian 
> > because software in their repository has security+critical bugs 
> > which case problems when communicating or flashing Nokia N900.
> 
> The release has worked for most people for 1+ years and one may
> flash broken images also with a properly working 0xffff release.
> Btw, I did not yet hear of somebody actually bricking his phone by
> flashing a new kernel.
> 
> > Please do not understand me bad, but I as developer of 0xFFFF I 
> > should inform people who distribute & use this SW about problems 
> > and security bugs...
> 
> Another option would be to remove 0xffff from jessie.

I have almost no familiarity with this package, so as maintainer and upstream
you have the advantage of me. I sugget you work it out between
yourselves and come back to me with a plan.

For the sake of clarity your options are:

 - migrate the new upstream if it's more practical than backporting, which
   is an option I'm certainly open to
 - backport actual fixes
 - remove the package from Jessie


-- 
Jonathan Wiltshire                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Attachment: signature.asc
Description: Digital signature


Reply to: