Re: 185 Packages that look orphaned
Thanks for your quick reply.
Guus Sliepen <guus@sliepen.eu.org> writes:
> On Tue, Jan 27, 2004 at 12:58:33AM +0100, Goswin von Brederlow wrote:
>
> > 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.
>
> I'd rather see you looked at each bug before sending your email. There
> are good reasons for some bugs to be open for a long time.
I just went by the sarge/sid differences not by bugs. No bug is
holding your vic package back so looking into your bugs is pointless.
> > If you maintain one of thses packages then tell me (including the
> > names of packages you maintain) during the next week. If you are using
> > one of these packages and could maintain (or NMU some fixes) you
> > should contact the maintainer and me to work things out. If I hear
> > nothing about a package soon I will start with the oldest and do a few
> > packages every day.
>
> I don't see how this is productive.
Maybe I should have clarified the "do a few". That means I look into
the package in detail and then decide if I should pursue fixing bugs,
getting the package into sarge as it or getting it orphaned. There is
not much point sending in a patch for a package if its orphaned, thats
why I want to sort that out first.
> > palo-installer peacock pgi pgplot5 php4-interbase php4-vpopmail pja
> > plib1.7 pose-skins povray pwlib pydb python-fixedpoint
>
> The povray package has been replaced with povray-3.5. If all goes well
> the current povray package will be replaced with a dummy package.
>
> > vcr vdkbuilder vflib3 vic vipec vlad vmailmgr vpopmail
>
> That vic is not in testing is not the fault of the package, the ia64
> buildd just never attempted to compile it. It's not my problem.
If a package was never build for an architecture that architecture
does not stop the package from entering sarge. So that can't be the
reason.
As maintainer it is your duty to care for your package on all
arches. Of cause nobody can make you.
Looking at
http://www.buildd.net/cgi/package_status?ia64_pkg=vic&searchtype=go
net/vic_1:2.8ucl1.1.5-2: Failed by buildd-caballero [optional:out-of-date]
Reasons for failing:
[Category: none]
bug #205246 (conflicting declarations of inet_ntop)
and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205246
Debian Bug report logs - #205246
FTBFS: conflicting declarations of inet_ntop
Severity: serious; Package: libuclmmbase1-dev; Reported by: Matthew Wilcox <willy@debian.org>; Date: Wed, 13 Aug 2003 16:18:03 UTC;
Tags: fixed; merged with #194300, #200710; Done: David MartÃnez Moreno <ender@debian.org>;
Your package has been build and failed on ia64. A bug has been filed
and resolved. Since your package wasn't to blame for the failure there
was no new upload to trigger a rebuild. All thats left to do is to
nudge the ia64 buildd admin to rebuild your package. Or log into on of
debians ia64 systems and do so yourself.
> There. The only two packages I know of should not be orphaned. You
> could've known if you'd actually read the bugs or excuses. You just
> annoyed me, and probably many others as well.
Sorry to have annoyed you.
MfG
Goswin
PS: Bdale: Are you maintaining caballero.debian.org? http://www.buildd.net/index-ia64.html doesn't have an email for it.
PPS: debian-ia64: If Bdale is the wrong guy who is doing it?
Reply to: