On Mon, Aug 29, 2005 at 09:43:33PM -0700, Steve Langasek wrote:
> > > 1) upgrade your kernel
> > > 2) dist-upgrade
>
> > > That doesn't seem terribly elaborate to me? And if people choose not to
> > > read, well, they get a failure on dist-upgrade and get to figure it out
> > > for themselves, I
Theodore Ts'o wrote:
> What's the schedule for 3.1r2? I think that this is serious enough
> that we should get it into 3.1r1, and have the updated package
> prepareds, but I accept that I might be biased on the matter, and in
> the end it's really up to the stable release management team. What
>
On Mon, Aug 29, 2005 at 11:35:03PM -0400, Roberto C. Sanchez wrote:
> On Mon, Aug 29, 2005 at 07:56:32PM -0700, Steve Langasek wrote:
> > > The kernel is likely going to be upgraded automatically because users will
> > > be using the kernel-image-2.6-xxx packages.
> > Is that a problem for some r
On Mon, Aug 29, 2005 at 07:56:32PM -0700, Steve Langasek wrote:
>
> > The kernel is likely going to be upgraded automatically because users will
> > be using the kernel-image-2.6-xxx packages.
>
> Is that a problem for some reason?
>
> > So we're going to have another release with a very elabora
Steve Langasek <[EMAIL PROTECTED]> writes:
> apt-cache rdepends can sometimes miss things, because it won't report
> reverse-dependencies for a package that it believes doesn't exist. A
> tool that gives more consistent results is grep-dctrl; i.e.,
> $ grep-dctrl -FDepends -sPackage libmpich1.0
On Mon, Aug 29, 2005 at 01:56:10PM +0200, Sven Luther wrote:
> On Mon, Aug 29, 2005 at 03:06:04AM -0700, Steve Langasek wrote:
> > Requiring that users reboot to 2.6.12 before installing the new version
> > of udev from etch *is* a valid upgrade path. There were similar upgrade
> > path choices th
Hi Russ,
On Sat, Aug 27, 2005 at 09:10:12PM -0700, Russ Allbery wrote:
> I've volunteered to try to help coordinate the mpich C++ transition. I'm
> still just learning how to do this, so this first message is just an
> outline of what I think the current state is and what actions are needed
> nex
On Mon, Aug 29, 2005 at 01:35:52PM -0700, Steve Langasek wrote:
>
> If you think this is a fix that can't wait for 3.1r2, then yes, please
> go ahead.
>
The nature of the bug is that if you are using something which uses
extended attributes (Samba, SELinux, ACL's, for example), and your
filesyst
On Sat, Aug 27, 2005 at 02:41:07PM -0400, Theodore Ts'o wrote:
> On Tue, Aug 23, 2005 at 10:08:55PM -0700, Steve Langasek wrote:
> > On Tue, Aug 23, 2005 at 02:43:31PM +0200, Martin Schulze wrote:
> > > Theodore Ts'o wrote:
> > > > On Tue, Aug 23, 2005 at 06:58:27AM +0200, Martin Schulze wrote:
> >
On Monday 29 August 2005 12:35, Marco d'Itri wrote:
> On Aug 29, Frans Pop <[EMAIL PROTECTED]> wrote:
> > In effect this means that any user having udev installed will have to
> > put udev on hold.
>
> No, if the kernel has not been upgraded yet then preinst will fail.
Hmm. Won't that fail the who
On Mon, Aug 29, 2005 at 11:26:09AM +0200, Bastian Blank wrote:
> reassign 325484 udev
> retitle 325484 udev lacks sarge->etch upgrade path
> thanks
> On Mon, Aug 29, 2005 at 01:46:49AM +0200, Marco d'Itri wrote:
> > udev >= 0.060-1 and kernels >= 2.6.12 should enter testing at the same
> > time.
On Aug 29, Frans Pop <[EMAIL PROTECTED]> wrote:
> In effect this means that any user having udev installed will have to put
> udev on hold.
No, if the kernel has not been upgraded yet then preinst will fail.
> If this really does have to happen this way, the user should be somehow
> presented w
On Monday 29 August 2005 11:06, Sven Luther wrote:
> > * reboot
> > * upgrade udev
>
> This is definitively not a user-friendly procedure.
In effect this means that any user having udev installed will have to put
udev on hold. Because of versioned dependencies on udev, this will
probably make
Andreas Barth <[EMAIL PROTECTED]> wrote:
> Further transitions
> ===
> Please don't do.
>
> Any further transition has the potential to make it even harder to bring
> packages to testing, as this makes the barrier for packages to go to
> testing even higher.
Would it be acceptabl
14 matches
Mail list logo
