Re: What is keeping 'kde' metapackage out of Woody?
On Mon, Feb 04, 2002 at 11:02:27PM -0800, tluxt wrote:
> 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.]
See this and look at kdelibs:
http://ftp-master.debian.org/testing/update_excuses.html
summary:
kdeadmin -> rpm -> doesn't build on m68k currently (will be fixed RSN)
kdegraphics -> bad NMU
kdelibs -> depends on glib1.3 (will be removed when I upload package)
kdenetwork -> build failed on hppa (patch avail and will be applied)
kdepim -> has RC bugs
kdeutils -> bad NMU
> --- Chris Cheney <ccheney@cheney.cx> 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?
Hopefully within this next week. There are some other changes I want to
make along with fixing that issue.
> 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.]
If a NMU is numbered like X.X it is considered a source NMU, but if it
is numbered X.0.X it is considered a binary NMU. The person did a
binary NMU with X.X numbering which caused the problem on those two
packages.
> > > 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?
Steps to get package into Woody:
1. Build package
2. Upload package to ftp-master
3. At approximately 1:52pm (CST) dinstall installs package into sid
4. Build daemons download package and attempt to build.
5. After building build daemons upload package to ftp-master
6. Installed into Woody if all of the following occur.
a. Correct number of days have passed (according to priority)
b. No RC (serious or above) bugs exist for package.
c. If all daemons have built and uploaded package (for archs
that were available for previous version).
> =====
> As an example of that I mean, something like:
>
> >From http://ftp-master.debian.org/testing/update_excuses.html
> we see meta-kde shows:
> kde/alpha unsatisfiable Depends: kghostview ['kdegraphics']
>
> In the same file we see:
> nothing about kghostview
The ['kdegraphics'] part lists the name of the source, which is what is
listed in the webpage.
>
> 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
> 4:2.2.2-6.1)
> Not considered
>
> 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:
> http://www.debian.org/distrib/packages ?
>
> If no, then what do we look at next to find out where the holdup is?
All of those packages listed after the "out of date on i386" are
packages that the kdegraphics source builds. You see the part about it
being out of date on i386, this is due to that bad NMU issue I mentioned
earlier.
> ==========================================================================
> 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
> 4:2.2.2-9)
> kdenetwork (source) is buggy! (1 > 0)
> Not considered
This is because there is a RC bug in casting that is seen on the hppa
platform you can look up the bug and read about it if you want. It
keeps it from compiling properly currently, and will be fixed soon.
Chris
Reply to: