Please remove vtkdata-installer from testing
vtkdata-installer was done to help the VTK 3.2 version packages in Woody. Now that VTK 4 versions are in line for Sarge, vtkdata-installer is obsolete. There's no reason to keep 161300 in the "Number concerning the next release" on re RC bug list. I've filed 272345 to ask that the vtkdata-installer package not be kept in unstable, and am asking here that it should not be part of a Sarge release. -Maitland
Re: proposed gpm uploads to testing-proposed-updates
Hi, On Thu, Sep 16, 2004 at 12:41:22AM -0700, Steve Langasek wrote: > Feedback on the combined patch: > > debian/rules -- > > Setting -D_REENTRANT here is odd, you normally want this in the > upstream Makefiles (particularly since not everything built by this > package is a library). Not new, though, just moved around, so this is > just a comment. We have not changed that, I don't want to get bite by that at this time. :> > Setting INSTALL_PROGRAM += -s is redundant, debhelper will strip (or > not) for you automatically. Yes, well it does not harm. :> > debian/gpm.postinst -- > > +# Remove leftover file from an old version > +if [ -e /etc/gpm-root.conf ]; then > + rm -f /etc/gpm-root.conf || true > +fi > > This seems like a questionable change for a t-p-u upload, considering > configuration files are normally only removed on package *purge*. Peter has removed that part. I've found as well that we didn't Build-Depends on debhelper 4, so I've changed that. And Peter has removed a stale and not used patch debian/read. We have tested it on several boxes with sarge and sid systems/chroots and I've upload just a few minutes ago. regards, guillem
Re: plans for d-i rc2 (and Oldenburg meeting)
Steve Langasek wrote: > I'd like to be able to commit to a release date sooner than the end of > next month, but that just doesn't seem feasible at this time. If we > make some forward progress on the current blockers, how much pain would > it be to drop the test candidate midstream and go straight for RC2? Hmm, it's probably possible to not let the test candidate block rc2's scheduling. This would probably involve starting a string freeze right after Oldenburg, and beginning preparation of the test candidate at the same time. Which kinda works because we won't want to be changing lots of strings right in the middle of preparing the test candidate anyway. Then the test candidate is releaed near the beginning of October, we have a week of user testing and feedback (still in the string freeze), and rc2 preparation begins. This does give us only a week to get user feedback on the test candidate and do bug fixes, and it preculdes fixing many strings based on user feedback. And it may delay rc2 by a week, since otherwise we could begin rc2 prep right after the 1 week string freeze. On the other hand, our translators may appreciate a longer string freeze for this final release for sarge. > Also, would the test candidate be seen as superseding RC1 on the > website, etc? Will this be considered enough of a "release" that we > could set about cleaning up the old kernel udebs, etc. currently in > testing? We could go either way. I'm not especially worried about preserving the usability of rc1 at this point, since it's highly unlikly we'll actually release with it. So we could do a full udeb sync at this point, which would aid testing of the test candidate. Or we could only provide CD and usb images and no netboot or floppy images and not touch the udebs in testing. I'm also unsure of whether we would build the images for a test candidate on the autobuilders, or use our daily builds for it. The autobuilders do not prioritise d-i builds highly, and until that's fixed[1] or unless the autobuilders are much less loaded than last time, it could take 2+ weeks to do a build there -- which is part of the reason I'm projecting so uch tie to get rc2 released. -- see shy jo [1] Technically the problem is that the autobuilders consider the debian-installer package to be of extra priority, and so permanatly at the bottom of the build queue, even though it also builds the very standard priority initrds used by the installer. signature.asc Description: Digital signature
util-linux bug severity
Hi, It seems a bug in util-linux (or as it handle the case) causes all virtual terminals (for some people even tty1) to hang for a while, if not forever on logout. Please see the lot of user reported cases: #224028, #224067, #226443, #229788 and #257487. It was hit Sid only, but as util-linux recently hit Sarge it is really annoying, can block users out of the system, happens with 2.4 and 2.6 kernels as well. Please raise the severity of this bug to RC and fix it somehow. The proposed changes have not helped me: deleting /var/run/utmp is not an option, editing /etc/inittab does not help, as I am not running devfsd and thus ttyX are real devices for me, not links etc. Regards, Laszlo/GCS
Re: Please remove vtkdata-installer from testing
On Sun, Sep 19, 2004 at 10:54:13AM -0400, A. Maitland Bottoms wrote: > vtkdata-installer was done to help the > VTK 3.2 version packages in Woody. > Now that VTK 4 versions are in line > for Sarge, vtkdata-installer is obsolete. > There's no reason to keep 161300 in the > "Number concerning the next release" on > re RC bug list. It isn't; the vtkdata-installer package is only present in stable, having been removed from unstable a year ago. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Classification of some arm builds that are 'Building'
On Tue, Sep 14, 2004 at 01:06:47PM +0200, Jeroen van Wolffelaar wrote: > Dear arm buildd-administrator, > > unison: Build-Depends uninstallable, should be Dep-Wait The version in sid should close this problem... There was a missing build deps long time ago, but since there was no new build. Once it will be build, it should go straight into sarge and close this bug Kind regard Sylvain Le Gall
Re: util-linux bug severity
On Sun, Sep 19, 2004 at 09:13:56PM +0200, Laszlo 'GCS' Boszormenyi wrote: > It seems a bug in util-linux (or as it handle the case) causes all > virtual terminals (for some people even tty1) to hang for a while, if > not forever on logout. Please see the lot of user reported cases: > #224028, #224067, #226443, #229788 and #257487. It was hit Sid only, but > as util-linux recently hit Sarge it is really annoying, can block users > out of the system, happens with 2.4 and 2.6 kernels as well. Um. I had been under the impression that the latest version *fixed* this bug, which was one of the reasons I pushed it through to sarge. LaMont? > Please raise the severity of this bug to RC and fix it somehow. I see it's RC now. -- Colin Watson [EMAIL PROTECTED]
Re: util-linux bug severity
On Sun, Sep 19, 2004 at 11:50:04PM +0100, Colin Watson wrote: > On Sun, Sep 19, 2004 at 09:13:56PM +0200, Laszlo 'GCS' Boszormenyi wrote: > Um. I had been under the impression that the latest version *fixed* this > bug, which was one of the reasons I pushed it through to sarge. > LaMont? The bug remains that getty is launched being told to use a tty that the kernel still has marked in use. I have yet to isolate just exactly _who_ the kernel thinks has it in use, so as to reassign the bug appropriately. lamont
I need help getting Mozilla FIrefox 0.9.3-5 into testing
If you take a look at http://bjorn.haxx.se/debian/testing.pl?package=mozilla-firefox I'm in pretty good shape. However, I definitely need mozilla-firefox-locale-es and mozilla-firefox-locale-gl removed from testing before the new version will go in. The other problem is that I build depend on the version of binutils in unstable. I thought the testing scripts did not consider the build-depends, but if they do that could pose a problem as well. Could any release/ftp-masters take care of the first issue, and someone enlighten me to the second. Thanks. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: I need help getting Mozilla FIrefox 0.9.3-5 into testing
On Sun, Sep 19, 2004 at 08:37:53PM -0400, Eric Dorland wrote: > If you take a look at > http://bjorn.haxx.se/debian/testing.pl?package=mozilla-firefox I'm in > pretty good shape. However, I definitely need > mozilla-firefox-locale-es and mozilla-firefox-locale-gl removed from > testing before the new version will go in. Hinted for removal, since mozilla-firefox looks like it's ready to go tomorrow. > The other problem is that I build depend on the version of binutils in > unstable. I thought the testing scripts did not consider the > build-depends, but if they do that could pose a problem as well. Build-Depends are not evaluated by the testing scripts, though it's important that missing build deps be taken care of prior to release. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
