On Wednesday, December 12, 2012 18:50:45, Nick Andrik wrote:
> >> If there are any bugs reported on functionality (which I doubt) then
> >> it makes no sense trying to fix the 2008 version.
> > 
> > Ubuntu has several SIGSEGV crashes reported on kismet 2008-05-R1-4.3:
> >    https://launchpad.net/ubuntu/+source/kismet/+bugs
> 
> I think that the ubuntu situation is orthogonal to the debian one.
> Since ubuntu takes its packages from unstable, whether or not we
> remove the package from stable is irrelevant.

The bugs for the kismet package in Ubuntu are irrelevant IFF the package in 
Wheezy doesn't have these SIGSEGV bugs.  ;-)  [The package versions are 
essentially identical, and Ubuntu starts with the packages in Debian.]

> Removing it from unstable is a different story.

Concerning Unstable I'm only suggesting updating the version of Kismet, which 
is what you've already been working on.  ;-)  [Thanks for this, BTW.]

> > Upstream (Mike Kershaw, who I see at MHVLUG meetings) is frustrated by
> > the fact that this old version of kismet is still being shipped in
> > Ubuntu, because he regularly gets bugs reported to him directly from
> > users that he isn't able to help with because the version is ancient. 
> > I'm adding Mike to the list of recipients so that he can have a chance
> > to offer an opinion on whether 2008-06-R1-4.3 should be shipped in
> > Wheezy (and thus shipped for another two years in Debian).
> > 
> > It'll be good to get a newer Kismet package in Unstable, since Ubuntu is
> > based on Unstable.
> 
> My package is almost ready, I expect only minor comments from the
> review process which will take quite much time since the package is
> huge and the changes really extensive.

Yes, I got bogged down trying to understand the .diff in the existing package 
(and that's before even trying to do a diff between the old and new package), 
so I know what you mean.

> >> All other bugs are OK.
> >> 
> >> BTW, I guess there is no chance to have the new package in wheezy once
> >> it gets released, is this correct?
> > 
> > To get a new version in it would have had to have been in Unstable before
> > the freeze in June.  Around that time I made a newer Kismet package
> > using debhelper v9, but it wasn't ready before the freeze and the
> > package I made still needs a couple of tweaks, which is why I hadn't
> > tried to file an ITA.
> 
> OK, this opportunity has passed, but at least I can aim to have the
> package in unstable in time for the ubuntu 13.04 release.
> This is first week of March, 2013.

That looks like the feature freeze date, yes.

> > Nick -- let me know if you'd like to see what I did re: /debian/* files. 
> > The main thing that needs tweaking in the package I came up with had to
> > do with the menu shortcut and how to handle access permissions
> > correctly.
> 
> Thanks for your offer, but I think I'm ok for now.
> I think I have already taken care of these two things.

Ok, cool.

> >> If we need to fix anything then I will have to keep different branches,
> >> i.e. one for stable and one for testing, right?
> > 
> > Maybe.  There will be different package versions, but "branches" implies
> > using a version control system which isn't a requirement AFAIK.
> 
> Branches can be even two directories in my disk :)

Well... /usually/ the versions of a package in Unstable, Testing, and Stable 
are all slightly different.  snapshot.debian.org keeps a copy of all of these 
versions, so you effectively "automatically" get these "branches" in a way.  
For instance for kismet:

   http://snapshot.debian.org/package/kismet/

> In any case, I'm planning to put the package in a VCS after the review
> process is finished.
> 
> BTW, something I'm curious in, is how many people will keep using the
> old 2008 version in stable (if it is shipped after all) if ubuntu and
> unstable/testing have the most recent one.
> What would be your estimation?

Popcon shows 1472 installs of the current package, and 4 kismet installs of a 
newer version that is "not in sid" (I'm one of the latter).

> Is there any way to get statistics for
> usage (popcon) depending on the release?

Sort of -- this deliniation is not reported on popcon.debian.org, but I 
believe these are statistics that do exist within Debian internally.  This 
recently came up in tech-ctte bug #688772:

   https://lists.debian.org/debian-ctte/2012/09/msg00077.html
   https://lists.debian.org/debian-ctte/2012/09/msg00090.html

> Would a response like "please use the recent version in testing " be
> acceptable?

IMHO, no.  To install the package in Testing on a Stable box requires 
switching Debian trees temporarily and usually ends up requiring upgrading 
other packages due to version dependencies, and thus results in the box being 
in a "mixed tree" state; then the admin switches trees back to Stable, whereby 
the box doesn't get security updates for the packages that came from Testing.  
[I occasionally do this, and so far I've gotten away with it, but it wouldn't 
be something I'd advise someone else to do.]

A better plan for this, IMHO, would be to use backports.debian.org for having 
an upgraded package for Stable available, which could thus stick with the 
packages in Stable as much as possible, and thus continue to get security 
updates.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to