Re: KDE 3.1.5/3.2 Status Update - 20040219
Hi. :) > There have been some setbacks since the last status update. kdetoys had > an rc bug, so a new version was uploaded and still needs to build on 4 > archs. FWIW, this wasn't an RC bug (in fact the bug wasn't even in the debian BTS). It was however a bug that had been annoying me, and since kdetoys 3.1.5 is already in testing it made sense to fix it while we waited on everything else. b.
Re: KDE 3.1.5 Status Update - 20040217
debian-release@lists.debian.org Cc: Bcc: Subject: Re: KDE 3.1.5 Status Update - 20040217 Reply-To: In-Reply-To: <[EMAIL PROTECTED]> On Wed, Feb 18, 2004 at 05:06:19AM -0600, Colin Watson wrote: > As for the remaining things to happen before jack-audio-connection-kit > and alsa-lib can be promoted, which will include kdeaddons, kdebase, and > kdegames: Taking a liberty to reorder your list a bit: > ardour needs to be built on arm ardour waits for raptor which needs newer redland > redland is waiting for perl > perl needs to be built on m68k, but has problems (#233175) > libjackasyn has just had bug #232605 fixed, which needs to be built I think nothing depends on ardour libs or libjackasyn, so if take an aggressive aproach in killing this deadlock, we can remove those two from testing and let them back when they have recovered from their own problems (ardour-raptor-redland need their own set of hints anyway?) > spiralsynthmodular is 7 days old; needs 10 This seems no problem. > gst-plugins needs to be built on mipsel > gst-plugins is 2 days old; needs 10 That would leave us with these two problems. Removing gst-plugins from testing would brake alot, so it seems out of question. Eight days fingers crossed nobody chooses to reupload any packages depending on Jack. I wish I could be confident of the timely mipsel build too. > So, getting there ... If we are lucky yes. In a longer term we really need a less fragile way of getting largely interdependant packages timely to testing. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Re: KDE 3.1.5 Status Update - 20040217
On Tue, Feb 17, 2004 at 08:47:22AM -0500, Josh Metzler wrote: > (Cross posted to debian-kde, as many there are wondering why KDE 3.2 > isn't in unstable yet.) Here's a follow-up, as some slightly strange things happened in testing last night which bear explaining. > Chris hasn't done a status update for a while, so I'll try to make do. > But, first some exciting news - arts 1.2.0 (the version that was > released with KDE 3.2) is going into experimental today. I expect that > means KDE 3.2 will follow it in the near future. Thank you, Chris. > > Some more good news - only two packages still need to build - kdebase > and kdegraphics. And, two of the three builds should succeed when retried. > > * Packages that still need to build: > > kdebase 3.1.5-2 > --- > s390 - failed? Feb 5 due to buggy (#231972) kernel headers (not yet fixed) [...] > kdepim (3.1.4-1) - waits for libmal (5 of 10 days old) > kdebase (3.1.3-1) > kdegames (3.1.4-1) > both wait for alsa-lib which waits for jack-audio-connection-kit > kdegraphics (3.1.4-1) - waits for libusb (5 of 10 days old) > kdeaddons (2.2.2-4 !) - waits for kdegames and kdebase > > -- > > So, the main bottle-necks are linux-kernel-headers on s390 and > jack-audio-connection-kit moving into testing. kdebase/s390 was built - somehow, and I think by hand - so last night the testing scripts considered meta-kde, kdeaddons, kdebase, and kdegames as "valid candidates". (This means that they don't have obvious problems that bar them from testing, but they may still fail if promoting the new packages results in more uninstallable packages than beforehand.) While kdeaddons, kdebase, and kdegames are still waiting for other things to happen, meta-kde was upgraded in testing. The reason for this was that it was actually already uninstallable there, so upgrading it didn't make the situation any worse. You can see at http://ftp-master.debian.org/testing/testing_probs.html that it's still uninstallable. As for the remaining things to happen before jack-audio-connection-kit and alsa-lib can be promoted, which will include kdeaddons, kdebase, and kdegames: ardour needs to be built on arm gst-plugins needs to be built on mipsel gst-plugins is 2 days old; needs 10 libjackasyn has just had bug #232605 fixed, which needs to be built redland is waiting for perl perl needs to be built on m68k, but has problems (#233175) spiralsynthmodular is 7 days old; needs 10 So, getting there ... -- Colin Watson [EMAIL PROTECTED]
Re: KDE 3.1.5 Status Update - 20040209
Colin Watson wrote: >There's going to be one problem with these two, namely that they both >need newer alsa-lib which needs newer jack-audio-connection-kit than >what's in testing, and some things still need to be rebuilt for that. Having anticipated that, I worked out an extensive list of the issues currently holding up jack-audio-connection-kit and sent it to -release. :-) I figured, worry about that first, *then* look at the KDE packages with remaining problems. The good news is that gst-plugins is the only package in the jack dependency web with a known RC bug at the moment. (Spiralsynthmodular was fixed almost as soon as I reported the problem.) >I'm inclined to remove some packages from testing to speed the way, but >one of the affected packages is gst-plugins and that's a dependency of >meta-gnome2, so that can't be so easily swept aside ... Heh -- I guess it's unfortunate that gst-plugins is the one with the known RC bug The other bad news is the nasty state of the buildds, about which I have made a big, loud ruckus. Maybe things will be better when I get back from vacation in a week -- I can dream, can't I? :-)
Re: KDE 3.1.5 Status Update - 20040209
On Tue, Feb 10, 2004 at 11:36:14AM -0600, Colin Watson wrote: > On Mon, Feb 09, 2004 at 12:55:55PM -0600, Chris Cheney wrote: > > kdebase 3.1.5-2 > > --- > > mipsel - failed - needs retry with unbuilt qt-x11-free (see below) > > (Feb 4) > > s390- failed - bad kernel headers? (Feb 6) > > kdegames 3.1.5-1 > > > > arm - Needs-Build (Feb 9) > > mips- Needs-Build (Feb 9) > There's going to be one problem with these two, namely that they both > need newer alsa-lib which needs newer jack-audio-connection-kit than > what's in testing, Add kdemultimedia to that list, when it finally gets built on arm, (need to increase buildd idle timeout..) it will need the newer alsa on arm. > I'm inclined to remove some packages from testing to speed the way, but > one of the affected packages is gst-plugins and that's a dependency of > meta-gnome2, so that can't be so easily swept aside ... A newer upload of gst-plugins seems to be required in any case, since the latest gst-plugins does not compile with the latest alsa. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Re: KDE 3.1.5 Status Update - 20040208
> kdegames 3.1.5-1 > > arm- failed - needs recompile with current g++ (Jan 15) Looks like this was built again with the same version of gcc (3.3.3-0pre1) and failed at the same point. It isn't obvious to me from the build error that this is a g++ problem, but I suppose that if it built on almost all the other arches... Josh
Re: KDE 3.1.5 Status Update - 20040209
On Mon, Feb 09, 2004 at 12:55:55PM -0600, Chris Cheney wrote: > Some of the packages were changed to Needs-Build so hopefully they will > be built soon. Maybe I will be able to upload KDE 3.2.0 by the end of > the week. :) [...] > kdebase 3.1.5-2 > --- > mipsel- failed - needs retry with unbuilt qt-x11-free (see below) > (Feb 4) > s390 - failed - bad kernel headers? (Feb 6) > > kdegames 3.1.5-1 > > arm - Needs-Build (Feb 9) > mips - Needs-Build (Feb 9) There's going to be one problem with these two, namely that they both need newer alsa-lib which needs newer jack-audio-connection-kit than what's in testing, and some things still need to be rebuilt for that. I'm inclined to remove some packages from testing to speed the way, but one of the affected packages is gst-plugins and that's a dependency of meta-gnome2, so that can't be so easily swept aside ... Fun for all the family. -- Colin Watson [EMAIL PROTECTED]
Re: KDE 3.1.5 Status Update - 20040208
On Mon, Feb 09, 2004 at 09:43:26AM -0500, Josh Metzler wrote: > > If anyone wants to ever see KDE 3.2 get into sid someone will need to > > persuade the buildd admins to retry the packages below so that KDE > > 3.1.5 can go into sarge... > > > > Chris > > Actually, it looks to me like all of these packages have been building > since Thursday or Friday. What happened to the mips buildd? All the > kde packages were building, but now they are all set at Needs-Build with > "Previous state was Building until 2004 Feb 09 00:19:52" - did the > buildd crash? I don't see build logs for these, either. > > Package status with finished packages (and kdebindings) left out: Note the date those changed to building, many of them have been in building state for nearly a _month_. They failed long ago if you look at buildd.debian.org logs but have not been retried. Someone told me before that they get automatically retried if left in building state, but that doesn't appear to be the case. Regardless they have finally started being retried after sending out this last status report. Chris signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040208
> If anyone wants to ever see KDE 3.2 get into sid someone will need to > persuade the buildd admins to retry the packages below so that KDE > 3.1.5 can go into sarge... > > Chris Actually, it looks to me like all of these packages have been building since Thursday or Friday. What happened to the mips buildd? All the kde packages were building, but now they are all set at Needs-Build with "Previous state was Building until 2004 Feb 09 00:19:52" - did the buildd crash? I don't see build logs for these, either. Package status with finished packages (and kdebindings) left out: kdebase 3.1.5-2 (Too young, only 9 of 10 days old) --- mipsel - Building s390- Building kdegames 3.1.5-1 arm - Building mips- Needs-Build (Feb 9) kdegraphics 3.1.5-1 --- arm - Building mips- Needs-Build (Feb 9) mipsel - Building s390- Building kdemultimedia 3.1.5-1 - arm - Building kdenetwork 3.1.5-1 -- arm - Building mips- Needs-Build (Feb 9) kdepim 3.1.5-1 -- arm - Building mips- Needs-Build (Feb 9) mipsel - Building kdeutils 3.1.5-1 mips- Needs-Build (Feb 9) quanta 3.1.5-2 -- mipsel - Building Arch status (finished archs left out): arm - all Building -- kdegames kdegraphics kdemultimedia kdenetwork mips - all Needs-Build -- kdegames kdenetwork kdepim kdeutils mipsel - all Building -- kdebase kdegraphics kdepim quanta s390 - all Building -- kdebase kdemultimedia Josh
Re: KDE 3.1.5 Status Update - 20040201
Btw, I think it would be more usefull, if this would be in (rough) depency order instead of alphabetical. On Sunday 01 February 2004 10:06, Chris Cheney wrote: > A few of the packages finally got reset to Needs-Build but there are > still many more that need to be reset... The buildd infa appears been somewhat flaky during the auric -> newraff transition. > qt-x11-free 3.2.3-2 > --- > arm - Building (Jan 23) - appears done but the admin never uploaded > mipsel- Needs-Build (Jan 22) This is the biggest showstopper NOW. Has anyone nagged the arm/mipsel admins on these? > kdebase 3.1.5-2 > --- waits also for the alsa-lib/jack-audio-kit. no RC bugs thou, just a lot of stuff to buildds to churn. > kdemultimedia 3.1.5-1 > - > arm - failed - needs retry (possibly with longer timeout) (Jan 15) This looks more like the buildd admin canceling the build (probably realized it was using a broken g++). unfortunatly an arm compile *now* would result kdemm to wait for alsa-lib...
Re: KDE 3.1.5 Status Update - 20040129
On Thursday 29 January 2004 10:33 pm, Chris Cheney wrote: > > With KDE not even being built on various archs while in sid already, > what makes you think uploading to experimental will help find bugs on > other archs? If you didn't know already experimental isn't built by > buildds at all. And at the current rate that the buildds are retrying > KDE 3.1.5 it will be months before it goes into sarge as well. I don't really understand how this debian system build thing works - but I have noticed how you have complained about the speed of this buildd and the admins several times. Given the importance - not just to Debian of having KDE 3.1 (at least) in Sarge, BUT ALSO to KDE of being seen to have an up to date version on Debian just when many of the "big boys" are picking Gnome as the desktop to go with, wouldn't it be better to have some private discussions with whoever is holding things up and trying to work through with them just how to get over the blockage. You may be doing this privately already - but the impression I get by reading your posts is that you are throwing rocks from afar. -- Alan Chandler [EMAIL PROTECTED]
Re: KDE 3.1.5 Status Update - 20040129
On Thu, Jan 29, 2004 at 09:12:12PM -0500, Nathanael Nerode wrote: > Chris Cheney wrote: > >And at the current rate that the buildds are retrying > >KDE 3.1.5 it will be months before it goes into sarge as well. > The undeniable fact that other parts of the project are making it harder for > sarge to be release-ready is no reason for you to make it harder for sarge to > be release-ready. > > If KDE was actually ready to go into sarge except for buildds (which it > isn't), I would happily and loudly nag the buildd maintainers on the grounds > that they were the last people holding up an important release goal. I don't > feel I can legitimately do that yet. :-( The only part of KDE that wasn't 100% ready to go into sarge was kdebase due to dependency on lm-sensors. I uploaded a fixed kdebase 3.1.5-2 so now there is nothing left holding it back. Get to naggin ;) Chris signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040129
Chris Cheney wrote: >And at the current rate that the buildds are retrying >KDE 3.1.5 it will be months before it goes into sarge as well. The undeniable fact that other parts of the project are making it harder for sarge to be release-ready is no reason for you to make it harder for sarge to be release-ready. If KDE was actually ready to go into sarge except for buildds (which it isn't), I would happily and loudly nag the buildd maintainers on the grounds that they were the last people holding up an important release goal. I don't feel I can legitimately do that yet. :-(
Re: KDE 3.1.5 Status Update - 20040129
Josh Metzler wrote: >I propose that the initial upload of KDE 3.2 be made to experimental rather >than unstable. Anyonw who is tracking sid ought to be able to figure out how >to get 3.2 from experimental. I strongly second this idea. This way, KDE 3.1.5 can get into sarge *while* KDE 3.2 is being debugged and tested. And if sarge takes long enough, KDE 3.2 can go into sid, and probably sarge as well. ;-) Upload all versions of kdebase without the lm-sensors dependency while you're at it -- the lm-sensors problems are unfortunately not gonna be fixed in the near, or maybe even far, future. This is akin to XFree86 3.4.0 being uploaded to experimental, but less painful (because KDE 3.1.5 -> KDE 3.2 isn't as huge a difference as XFree86 4.1 -> Xfree86 4.3)
Re: KDE 3.1.5 Status Update - 20040129
On Thu, Jan 29, 2004 at 05:04:23PM -0500, Josh Metzler wrote: > I propose that the initial upload of KDE 3.2 be made to experimental rather > than unstable. Anyonw who is tracking sid ought to be able to figure out how > to get 3.2 from experimental. This would allow some initial testing to be > done on the packages to make sure there aren't intractable bugs that will > keep them in unstable for months, while also giving 3.1.5 time to make it to > sarge. With KDE not even being built on various archs while in sid already, what makes you think uploading to experimental will help find bugs on other archs? If you didn't know already experimental isn't built by buildds at all. And at the current rate that the buildds are retrying KDE 3.1.5 it will be months before it goes into sarge as well. Chris signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040129
(cross-posted to -devel, as I think people who don't track -qt-kde should be in on the discussion) >KDE is still not anywhere near ready to go into sarge. Most of it is >caused by the buildd admins. You can see the dates of last state change >on the various packages, many of them have been stuck for over 2 weeks! > >Chris > >BTW - KDE 3.2 is nearly ready to go into sid now. Please let KDE 3.1.5 get into sarge. While I use sid myself, and I am definitely looking forward to KDE 3.2, I would hate for the next Debian release to not have KDE 3.x in it. It looks to me like all that needs to happen for 3.1.5 to get into testing is rebuilds on many of the buildds. Of course, I would love for the next Debian release to contain 3.2, but with the size of KDE, I will be amazed if 3.2 doesn't initially have some bugs on some archs. I propose that the initial upload of KDE 3.2 be made to experimental rather than unstable. Anyonw who is tracking sid ought to be able to figure out how to get 3.2 from experimental. This would allow some initial testing to be done on the packages to make sure there aren't intractable bugs that will keep them in unstable for months, while also giving 3.1.5 time to make it to sarge. Josh Metzler
Re: KDE 3.1.5 Status Update - 20040120
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi... On Wed, 21 Jan 2004 10:24 pm, Dominique Devriese wrote: > Great, you seem to have fixed the gcj compilation stuff. Wasn't hard, it basically worked out of the box once the autoconf stuff was fixed to look for gcj. > I have been working on kdebindings packaging myself too a bit, can you > please update your patch against KDE_3_1_BRANCH ? Ok, new patch is at: http://www.hawkins.emu.id.au/kdebindings_KDE_3_1_BRANCH-20040122.diff > > There are fixes in there for various things like: > 1 the kde C bindings are internal binding libs, not meant for external > use I have gone through and made a bunch of changes that are needed for policy compliance. > have not heard from him since. Do you think your code is usable for > the general KDE release, or does it depend on Debian only stuff ( > which would not be the right thing to do, really, as other distro's > also need java libs linked against gcj stuff, and it makes maintenance > of the debian packages more difficult ). Well, it shouldn't break anything - the only patch which applies to a file outside of debian/ is the patch to admin/acinclude.m4.in, to make the configure script's java test find the javac which is provided in debian's gcj package. The j2sdk copy of java will be used if it is found first. There are also a couple of patches in debian/patches that possibly should be applied to the main tree as well (one adds an encoding option to javac's command line, the other moves dcop.py into the site-packages directory). > Also, are you a DD, and do you intend to take up maintenance of > kdebindings permanently ? Cause that would rock, kdebindings is not > receiving enough attention imho. I'm a DD but not a KDE developer, so I can't commit to cvs. I guess I should probably go and ask for KDE cvs access if I want to look after this in the longer term. =) Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADyTAXjDfzL4R9DcRAk0BAJ4kghlwdv0xux8OepOI02jYlAdgtgCfeBl0 CUK8FCV3UGpOBjY6GnK3ZkI= =OZRG -END PGP SIGNATURE-
Re: KDE 3.1.5 Status Update - 20040120
Peter Hawkins writes: > Hi... > On Wed, 21 Jan 2004 03:26 pm, Chris Cheney wrote: >> kdebindings --- probably should be packaged sometime... not >> blocking anything though > Strange you should mention it. Try: > http://www.hawkins.emu.id.au/kdebindings-20040121.diff > (diff against KDE_3_1_5_RELEASE). Great, you seem to have fixed the gcj compilation stuff. I have been working on kdebindings packaging myself too a bit, can you please update your patch against KDE_3_1_BRANCH ? There are fixes in there for various things like: 1 the kde C bindings are internal binding libs, not meant for external use 2 the various debian language policies all impose certain limitations on the names of packages, build dependencies etc. 3 better descriptions of the packages 4 etc Richard Dale told me he was working on making it work with gcj, but I have not heard from him since. Do you think your code is usable for the general KDE release, or does it depend on Debian only stuff ( which would not be the right thing to do, really, as other distro's also need java libs linked against gcj stuff, and it makes maintenance of the debian packages more difficult ). If so, it should probably be applied to HEAD. Also, are you a DD, and do you intend to take up maintenance of kdebindings permanently ? Cause that would rock, kdebindings is not receiving enough attention imho. Thanks domi
Re: KDE 3.1.5 Status Update - 20040120
> However, I do need to do another upload of kdemultimedia to > fix the libxine issue with kdeaddons. Not urgent, since I've just done a new kdeaddons upload with libxine-dev temporarily added to the build-depends until the issue can be resolved properly. Ben.
Re: KDE 3.1.5 Status Update - 20040120
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi... On Wed, 21 Jan 2004 03:26 pm, Chris Cheney wrote: > kdebindings > --- > probably should be packaged sometime... not blocking anything though Strange you should mention it. Try: http://www.hawkins.emu.id.au/kdebindings-20040121.diff (diff against KDE_3_1_5_RELEASE). =) Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADgbLXjDfzL4R9DcRApNcAJ9Xt1dqS0KYCqI0ZkTQ3Dt61uLwkgCgtD5f tlQVgB0Yz3rzxU4GBOV3f1I= =nE0U -END PGP SIGNATURE-
Re: KDE 3.1.5 Status Update - 20040119
On Mon, Jan 19, 2004 at 10:19:04PM -0600, Chris Cheney wrote: > qt-x11-free > --- > finished ... but has an RC bug due apparently to breakage in libxrender-dev. I've suggested a binary-only NMU workaround, since the bug appears to have manifested only on the maintainer's build machine and not on any buildds. -- Colin Watson [EMAIL PROTECTED]
Re: KDE 3.1.5 Status Update - 20040119
On Tue, Jan 20, 2004 at 01:23:38PM +0100, Wouter Verhelst wrote: > Actually, Ingo Juergensmann is just the local admin of arrakis. He > doesn't help because he's not a DD, that's all. That's why you was supposed to do the buildd stuff. I think we're forming a nice couple in that way... ;)) > This is my fault; I thought it had built on quickstep, but I seem to > have messed up things. For that reason, it's not in dep-ret or > needs-build ATM (where it should've been). I sent Goswin (see below) a > mail, clearing that up. It would also help when Goswin would have access to w-b. He could do the minor buildd stuff and let a DD sign the successful builds. *sigh* > [1] due to the fact that we don't have enough autobuilders ATM. There > are more being set up though, so it's being handled. Note to all, why don't already know it: When Goswin would have access to w-b, there would his two 060s and 3, maybe 4 more 060 buildds added in the next few days or weeks until mid of February. I don't know how many of them will become public machines, but usually accounts are available on request on most of them. -- Ciao... // Ingo \X/
Re: KDE 3.1.5 Status Update - 20040119
On Mon, Jan 19, 2004 at 10:19:04PM -0600, Chris Cheney wrote: > Everything is in sid now, but the buildds FUCKING SUCK! The buildd > admins must be incompetent or on crack. They failed all the builds that > failed due to the g++ RC enum bug instead of updating their buildd and > setting the packages back to Needs-Build. sbuild doesn't update packages if it's not asked to. If you know beforehand that a package *will* fail to build with a certain compiler, you should update your build-depends and/or build-conflicts likewise, so that there won't be a failed build in the first place. sbuild (the building component of buildd) isn't pbuilder; sbuild tries to build as many packages in as little time as possible. Therefore, installed packages aren't looked at (so that time isn't wasted on them) except to check that they satisfy versioned build-depends and/or build-conflicts. > The g++ RC enum bug was already fixed before I even uploaded the > packages which shows you how slow they are to fix problems on their > machines... However, people like IJ are refused to help maintain > buildds because they have too little experience, hah! Actually, Ingo Juergensmann is just the local admin of arrakis. He doesn't help because he's not a DD, that's all. [...] > kdebase > --- > m68k - failed - needs retry This is my fault; I thought it had built on quickstep, but I seem to have messed up things. For that reason, it's not in dep-ret or needs-build ATM (where it should've been). I sent Goswin (see below) a mail, clearing that up. [...] Note that most kde packages are still in the queue for m68k; we've got quite a backlog currently[1]. That said, Goswin von Brederlow is building them, ignoring their position in the queue, thereby special-casing KDE so that it gets built sooner. [1] due to the fact that we don't have enough autobuilders ATM. There are more being set up though, so it's being handled. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "Stop breathing down my neck." "My breathing is merely a simulation." "So is my neck, stop it anyway!" -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040119
> As far as I can tell the only thing that uses libxine is xine_artsplugin > which shouldn't be being linked into anything. libxine-dev is already in > the kdemultimedia Build-Depends due to xine_artsplugin using it. Nevertheless, having downloaded the alpha noatun package, it seems that for both alpha and i386, /usr/lib/noatun.la contains a dependency on /usr/lib/libxine.la. I'd argue then that, as well as kdemultimedia build-depending on libxine-dev, we should have kdemultimedia-dev depending on libxine-dev as well. Ben.
Re: KDE 3.1.5 Status Update - 20040119
On Tue, Jan 20, 2004 at 04:14:08PM +1100, Ben Burton wrote: > > > kdeaddons > > - -snip- > Of course this is all pure speculation - I haven't actually had a chance > to downloaded the kdemultimedia sources and take a look. As far as I can tell the only thing that uses libxine is xine_artsplugin which shouldn't be being linked into anything. libxine-dev is already in the kdemultimedia Build-Depends due to xine_artsplugin using it. Chris signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040119
> kdeaddons > - > alpha - failed - libxine missing(?) > hppa - failed - libxine missing(?) > mips - failed - libxine missing(?) > mipsel- failed - libxine missing(?) > powerpc - failed - libxine missing(?) > s390 - failed - libxine missing(?) > sparc - failed - libxine missing(?) > > not sure what is wrong here it built on several archs but failed the > same way on the rest... My first guess is that noatun might be built against libxine on those particular archs, which means that libtool looks for libxine.la when it builds the noatun plugins. In the particular plugin where kdeaddons is failing, the Makefile.am only has -lnoatun in addition to the usual KDE libraries. A quick grep in fact suggests that there's nothing at all in kdeaddons that could be dragging in libxine directly. An extension of this guess is that noatun might build in xine support if it happens to finds libxine on the system, but libxine-dev is not explicitly in the kdemultimedia build-depends. This would account for the fact that some archs have it and some don't, and the fact that it's not listed in the depends for kdemultimedia-dev. If this is true, presumably either (i) libxine-dev must be explicitly added to kdemultimedia build-depends and kdemultimedia-dev depends so that noatun always has xine support, or (ii) xine support must be explicitly disabled in noatun (hopefully through a configure flag, otherwise through a build-conflicts with libxine-dev) so that noatun never has xine support and no unexpected build-depends creep through to other packages. Of course this is all pure speculation - I haven't actually had a chance to downloaded the kdemultimedia sources and take a look. > quanta > -- > m68k - failed - due to automake 1.4, wtf? This has been a long-standing problem hasn't it - I'll do a new upload with a build-conflicts on automake1.4. Ben.
Re: KDE 3.1.5 Status Update - 20040116
On Sat, Jan 17, 2004 at 06:23:16PM +1100, Ben Burton wrote: > > > It looks like everything is at 3.1.5 now except for Ben's packages. > > I've just come back from a maths conference, and I haven't been treating > my modules as particularly urgent since the issues that prompted 3.1.5 > were not in my modules, and my modules have already had recent BRANCH > updates anyway. > > They should be uploaded in a few days. Ok no problem. Chris signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040116
> It looks like everything is at 3.1.5 now except for Ben's packages. I've just come back from a maths conference, and I haven't been treating my modules as particularly urgent since the issues that prompted 3.1.5 were not in my modules, and my modules have already had recent BRANCH updates anyway. They should be uploaded in a few days. Ben.
Re: KDE 3.1.5
Am Fr, den 16.01.2004 schrieb Chris Cheney um 09:45: > suppose the other maintainers will be following shortly. I am not sure > if Ralf is going to be doing the 3.1.5 backport packages or not. KRalf is still on holidays. He will return in two weeks or so. -- Noèl Köthe Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: KDE 3.1.5
On Thu, Jan 15, 2004 at 08:21:13PM +0100, Dirk Mueller wrote: > > Hi, > > will there be 3.1.5 packages? there have been numerous reports that the 3.1.4 > ones are too old, and apt-get update doesn't work on them (whatasurprise) All my KDE 3.1.5 packages are already in sid or in the new queue. I suppose the other maintainers will be following shortly. I am not sure if Ralf is going to be doing the 3.1.5 backport packages or not. Chris signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040114
Chris Cheney wrote: >There are currently two known bugs that will block KDE 3.1.5 from going >into sarge #226727 and #226738. It seems the GCC people don't think >their bug is important enough to fix... More, that it wasn't diagnosed enough to fix in a reasonable amount of time. :-( But kdelibs seems to have built on mips now, according to Riku Voipio. (http://lists.debian.org/debian-qt-kde/2004/debian-qt-kde-200401/ msg00344.html)Who knows what was going on with GCC. :-( So much for #226727. As for #226738, it looks like it will be fixed soon by a rebuild. Don't forget the lm-sensors dependency in kdebase. That will keep kde 3.1.5 out of "testing" until lm-sensors is fixed, unless it's manually forced in. I'm really not sure what to do about that, but I've discussed the lm-sensors issues on debian-devel.
Re: KDE 3.1.5 Status Update - 20040114
Am Do, den 15.01.2004 schrieb Chris Cheney um 04:00: > kdegames > > not uploaded yet is in incoming > kde-i18n > > not uploaded yet uploaded and is in incoming > qt-x11-free > --- > m68k - not uploaded yet is in incoming -- Noèl Köthe Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: KDE 3.1.5 Status Update -- 20040113
On Wed, Jan 14, 2004 at 01:39:12PM -0500, Nathanael Nerode wrote: > Chris Cheney wrote: > >kdelibs > >--- > >m68k - failed - needs retry (waiting on qt-x11-free) > >mips - failed - ICE #226727 > > Please try to find a workaround for this ICE (or help find & fix it). This appears to be moot, kdelibs compiled fine[1] on mips yesterday. The gcc version is same, but the building host different... The m68k porters are also very helpful and are compiling kde packages by hand as there are various issues bringing all the buildd's back post-compromise. The only thing I'm worried about (testing-wise) is the lm-sensors depency in kdebase. Which I assume you are working on already. > It's also not top priority for GCC since gcc-3.3 is still producing silently > wrong code in some situations (which comes first, of course). There's nothing new here. xlib6g/hppa for example doesn't[2] work in woody because of gcc miscompilation, which was fixed[3] in gcc-3.3... [1] http://buildd.debian.org/build.php?&pkg=kdelibs&ver=4%3A3.1.5-1&arch=mips&file=log [2] http://lists.debian.org/debian-hppa/2002/debian-hppa-200205/msg00085.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204844 -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Re: KDE 3.1.5 Status Update -- 20040113
On Wed, Jan 14, 2004 at 01:39:12PM -0500, Nathanael Nerode wrote: > Chris Cheney wrote: > >kdelibs > >--- > >m68k - failed - needs retry (waiting on qt-x11-free) > >mips - failed - ICE #226727 > > Please try to find a workaround for this ICE (or help find & fix it). > The GCC developers haven't tracked it down yet, which means it may well > not be fixed by sarge release time. (Unless of course it's already > fixed, which can be tested by trying a newer gcc-3.3 package). It's > also not top priority for GCC since gcc-3.3 is still producing silently > wrong code in some situations (which comes first, of course). Possible > workarounds include compiling with less optimization. Finding it, since > it's a segfault, probably means running gdb on the cc1plus process. :-P Why aren't the mips porters working on this, it seems to be ICEing on quite a few binaries on mips... How am I supposed to know how to fix this issue, aiui individuals still can't log into various debian boxes (or was that finally fixed). Is the less optimization fix a known fix or just a guess, and should it be -O0 or -O1. I think I will ask AJ to just push it through once m68k is done. Chris signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update -- 20040113
Chris Cheney wrote: kdelibs --- m68k- failed - needs retry (waiting on qt-x11-free) mips- failed - ICE #226727 Please try to find a workaround for this ICE (or help find & fix it). The GCC developers haven't tracked it down yet, which means it may well not be fixed by sarge release time. (Unless of course it's already fixed, which can be tested by trying a newer gcc-3.3 package). It's also not top priority for GCC since gcc-3.3 is still producing silently wrong code in some situations (which comes first, of course). Possible workarounds include compiling with less optimization. Finding it, since it's a segfault, probably means running gdb on the cc1plus process. :-P
Re: KDE 3.1.5 Status Update - 20040110
On Mon, Jan 12, 2004 at 03:42:00AM +0100, Rene Engelhard wrote: > Hi, > > Chris Cheney wrote: > > On Mon, Jan 12, 2004 at 11:26:32AM +1100, Ben Burton wrote: > > > > > > > kdeaddons > > > > - > > > > wait to upload until all else is finished > > > > > > FWIW, this is somewhat too great a restriction. > > > The kdeaddons module build-depends on kdebase, > > > kdemultimedia and kdegames, but IIRC nothing else. > > > > You know what I meant, not what I said. ;) I couldn't remember what all > > it depended on when I wrote the message. We just need to make sure those > > packages have finished compiling or are in good state before uploading > > Why not just Build-Depend on the needed version. If it is not available > it probably will fail at the first time but hey, that's what Dep-Wait is > for on the buildds. I am not i100% sure how the buildd admins handle that but > IIRC that is the theory ;) In theory yea it works good, in practice the buildd admins are very slow to react. Chris signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040110
Hi, Chris Cheney wrote: > On Mon, Jan 12, 2004 at 11:26:32AM +1100, Ben Burton wrote: > > > > > kdeaddons > > > - > > > wait to upload until all else is finished > > > > FWIW, this is somewhat too great a restriction. > > The kdeaddons module build-depends on kdebase, > > kdemultimedia and kdegames, but IIRC nothing else. > > You know what I meant, not what I said. ;) I couldn't remember what all > it depended on when I wrote the message. We just need to make sure those > packages have finished compiling or are in good state before uploading Why not just Build-Depend on the needed version. If it is not available it probably will fail at the first time but hey, that's what Dep-Wait is for on the buildds. I am not i100% sure how the buildd admins handle that but IIRC that is the theory ;) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 at it" -- Linus Torvalds signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040110
On Mon, Jan 12, 2004 at 11:26:32AM +1100, Ben Burton wrote: > > > kdeaddons > > - > > wait to upload until all else is finished > > FWIW, this is somewhat too great a restriction. > The kdeaddons module build-depends on kdebase, > kdemultimedia and kdegames, but IIRC nothing else. You know what I meant, not what I said. ;) I couldn't remember what all it depended on when I wrote the message. We just need to make sure those packages have finished compiling or are in good state before uploading kdeaddons. > (As an aside, I would actually expect kdeaddons 3.1.5 to > build just fine against KDE 3.1.4 given the bugfix-only > nature of the 3.1.x releases and the fact that > the module APIs for kate, noatun, etc. will almost > certainly not have changed.) Yea, that should probably work. Some packages won't really have changed at all since the packages that are already in sid, since we use branch patches. Its primarily just an update of the orig.tar.gz and version number. Chris signature.asc Description: Digital signature
Re: KDE 3.1.5 Status Update - 20040110
> kdeaddons > - > wait to upload until all else is finished FWIW, this is somewhat too great a restriction. The kdeaddons module build-depends on kdebase, kdemultimedia and kdegames, but IIRC nothing else. (As an aside, I would actually expect kdeaddons 3.1.5 to build just fine against KDE 3.1.4 given the bugfix-only nature of the 3.1.x releases and the fact that the module APIs for kate, noatun, etc. will almost certainly not have changed.) Anyway, this is immaterial since I'm not uploading it in the next few days anyway. b.
