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

Re: 185 Packages that look orphaned

Thanks for your quick reply.

Javier =?iso-8859-15?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <jfs@computer.org> writes:

> On Tue, Jan 27, 2004 at 12:58:33AM +0100, Goswin von Brederlow wrote:
> > Hi,
> > 
> > I looked through the differences between testing and unstable and
> (...)
> > Noone has cared enough about these packages to get them compiled,
> > fixed or pushed into sarge so I am assuming the packages don't have a
> > caring maintainer or fan community. Ergo they should be orphaned.
> Not having a caring maintainer is not equal to not being autobuilt. Given 
> the fact that for those non-free packages I maintain, some have been 
> autobuilt at _some_ point

Buildd admins and DDs have build them manually from time to time. "You
see that nice package and it not build for your arch? Lets build it,
try it out and upload it." And if they loose interest and dont build
future versions your stuck in sid.

> > bass
> Don't touch this unless you are willing to work on it, thanks

# 414 days old (needed 10 days)
# out of date on alpha: bass (from 1.0.7-2)
# out of date on arm: bass (from 1.0.7-2)
# out of date on ia64: bass (from 1.0.7-2)
# out of date on powerpc: bass (from 1.0.7-2)
# out of date on s390: bass (from 1.0.7-2)

> > lmbench
> Ditto.

#  The current maintainer is looking for someone who can take over
   maintenance of this package. If you have some interests in this
   package, please consider taking it over. Alternatively you may want
   to be co-maintainer in order to help the actual maintainer. Please
   see bug number #216883 for more information.

Is that still true?

# 579 days old (needed 2 days)
# out of date on alpha: lmbench (from 2.0-patch2-2)
# out of date on mips: lmbench (from 2.0-patch2-2)
# out of date on mipsel: lmbench (from 2.0-patch2-2)
# out of date on s390: lmbench (from 2.0-patch2-3)
# out of date on sparc: lmbench (from 2.0-patch2-2)

> > satan
> Ditto.

# 373 days old (needed 10 days)
# out of date on alpha: satan (from 1.1.1a-3)
# out of date on arm: satan (from 1.1.1a-3)
# out of date on ia64: satan (from 1.1.1a-2)
# out of date on s390: satan (from 1.1.1a-3)
# out of date on sparc: satan (from 1.1.1-18)
> Now, I really don't remember seeing a mail on d-announce saying that
> autobuilders would not build non-free packages, but maybe I've missed it. 

It was mentioned in Bug number #216883 of yours so you must have
forgotten about it since last October. But a number of DDs are
surprised to hear that so your not alone not knowing.

> Since I don't see in the Policy or Devel's reference [1] why/when this
> changed I don't intend to play the game and start begging autobuilders to
> do what they have previously done before. Now, this was discussed in -devel
> [2], with no consensus AFAIK.
> If you think that QA would do a better job at mantaining these packages
> (which I don't) please do explain yourself. I find it funny that some think
> that we should not waste inexpensive (autobuilders=machine) resources in
> non-free packages but we are willing to waste expensive (QA=people)
> resources in them.

Some packages can't be autobuild for legal reasons. All of those are
in non-free. There is no flag in the source packages saying what can
be legally build and what not and no list is provided otherwise. Also
some people don't want to support non-free software.

I think what would work best currently is if you get a comaintainer
for every arch you can't build the package on or at least a steady
group of sponsors. If noone is willing to build the package you can
file a bug against ftp.debian.org to get obsolete versions removed.
> Regards
> Javi
> [1] 
> http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-porter-automation
> [2] 
> http://lists.debian.org/debian-devel/2002/debian-devel-200211/msg00270.html
> And please don't tell me it shouldn't be documented because both the Policy 
> and Reference talk about non-free. 


Reply to: