Re: What is keeping 'kde' metapackage out of Woody?
Thanks for your info below. (See a few questions there.)
You missed this question at the very beginning of the message, :)
which refers to the subject of this message:
Subject: What is keeping 'kde' metapackage out of Woody?
Q: And, where exactly in the Debian package system database web info pages
can this info be found?
[Perhaps you want to answer this question at a reasonable spot below.]
--- Chris Cheney <firstname.lastname@example.org> wrote:
> On Mon, Feb 04, 2002 at 01:23:13AM -0800, tluxt wrote:
> > I guess the relevant item here is "meta-kde", right?
> Yes, all packages that are built from a source have to go into testing
> (woody) at the same time.
> > Yow! That looks like a _lot_ of work needing to be done on meta-kde!
> > All those things have to go away before meta-kde can get into W, right?
> It isn't as bad as it looks, currently the reason it is being held out I
> believe is due to a bad NMU that was numbered as a source NMU instead of
> binary only NMU. With the next upload of the various packages that I do
> it should fix that problem.
When do you think you will have that next upload done?
What, very briefly, is the chain of reasoning from the above data
that leads you to your conclusion that "the reason it is being held out I
believe is due to a bad NMU"?
[I ask this so I can be informed how to trace such erros, so that
perhaps I could do that on my own eventually, so I could perhaps contribute
to helping fix such problems.]
> > Who does the work of getting all those packages built for all those
> > different processors? You? Someone who supports those other processors?
> > If you, when do you think you'll have all that work done?
> > alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
> > Seriously: Is it _worth_ doing all that effort?????
> We have buildd maintainers that partially automate the process of
> building the packages for all the various archs. The only requirement
> of the package maintainer is to insure that bugs keeping it from being
> built on the other archs are fixed.
> In this particular case I think the entire problem was due to a bad NMU.
> I have turned on enable-final in my test packages, which I hope
> to upload soon, that will probably help reduce the time to build on all
> the archs.
In order to inform persons who want to know the process to use to keep up
with what needs to be done for kde in Debian, would you state briefly the
chain of evidence that one follows to know where holdup-causing problems lie
in getting package kde into a state satisfactory for it to be moved to woody?
As an example of that I mean, something like:
we see meta-kde shows:
kde/alpha unsatisfiable Depends: kghostview ['kdegraphics']
In the same file we see:
nothing about kghostview
Also, in the same file we see:
kdegraphics (4:2.1.1-6 to 4:2.2.2-6)
Maintainer: Daniel Stone
39 days old (needed 10 days)
out of date on i386: kamera, kcoloredit, kfract, kghostview, kiconedit,
kooka, kpaint, kruler, ksnapshot, kview, libkscan-dev, libkscan1 (from
So, what do we look into next? Something about kghostview, or kdegraphics?
And what, at that following link, gives the next clue as to what to
look at? Do we search on the packages kghostview or kdegraphics at:
If no, then what do we look at next to find out where the holdup is?
or, maybe starting from:
kde/i386 unsatisfiable Depends: kdict ['kdenetwork']
kdenetwork (4:2.1.1-7 to 4:2.2.2-13)
Maintainer: Daniel Stone
24 days old (needed 5 days)
out of date on hppa: kdict, kit, klisa, kmail, knewsticker, knode, korn,
kppp, ksirc, ktalkd, libkdenetwork1, libmimelib-dev, libmimelib1 (from
kdenetwork (source) is buggy! (1 > 0)
Thanks. I appreciate your taking your time to inform me how to keep up
with where KDE needs work. :)
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!