On Fri, Feb 10, 2006 at 12:32:21AM +0100, Marco d'Itri wrote:
> Now that 2.6.15 kernels are in testing I'd like to raise the kernel
> requirement for the udev package from 2.6.12 to 2.6.15 as soon as a new
> version of udev will have entered testing.
> This will let me remove a lot of cruft from th
Steve Langasek wrote:
> > * Accepted albatross
> > * Accepted antiword
> > * Investigation of cernlib
> > * Investigation of clamav
> > * Accepted crawl
> > * Moved evms from further to accept
> > * Accepted mantis
> > * Accepted perl
> > * Accepted sudo
>
> Are you aware of the complaint
On Fri, Feb 10, 2006 at 07:57:25AM +0100, Sven Luther wrote:
> We need something which upgrades seamlessly, and the above solution is not
> acceptable for the etch release, as has been said already in the past.
Hmm. Are there problems with the following:
- Upgrade works but asks the not yet comple
On Thu, Feb 09, 2006 at 01:30:19PM -0500, Joey Hess wrote:
> Frans Pop wrote:
> > I'm not sure how the following package should be hinted as it used to have
> > a deb, but now only has a udeb:
> > network-console
> network-console-config needs to be removed from testing (should happen
> semiauto
On Thu, Feb 09, 2006 at 03:26:35PM +0100, Julien Cristau wrote:
> approx still depends on ocaml-base-nox-3.09.0 on hppa, m68k, mips,
> mipsel, s390. Could you trigger a binNMU on these architectures for the
> transition to 3.09.1?
Queued.
Thanks,
--
Steve Langasek Give me a le
On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote:
> We need something which upgrades seamlessly, and the above solution is not
> acceptable for the etch release, as has been said already in the past.
This would be nice, but so far nobody has been able to design anything
better, myself included.
>
On Fri, Feb 10, 2006 at 10:45:04AM +0100, Bastian Blank wrote:
> On Fri, Feb 10, 2006 at 07:57:25AM +0100, Sven Luther wrote:
> > We need something which upgrades seamlessly, and the above solution is not
> > acceptable for the etch release, as has been said already in the past.
> Hmm. Are there p
On Fri, Feb 10, 2006 at 02:37:21AM -0800, Steve Langasek wrote:
> Anyway, I don't see that this is a very good solution. Disabling all of the
> available boot options for the system doesn't prevent incidental breakage,
> it just changes the *kind* of incidental breakage you get.
It makes it impos
On Thu, Feb 09, 2006 at 04:13:54PM +0100, Frans Pop wrote:
> Now that 2.6.15 is in testing (Yay!) let's migrate the udebs that waited
> on that to happen.
>
> unblock user-setup/2.12r-6
> unblock cdebconf/0.97 # 8 days old currently
>
> I'm not sure how the following package should be h
On Fri, Feb 10, 2006 at 12:07:11PM +0100, Bastian Blank wrote:
> On Fri, Feb 10, 2006 at 02:37:21AM -0800, Steve Langasek wrote:
> > Anyway, I don't see that this is a very good solution. Disabling all of the
> > available boot options for the system doesn't prevent incidental breakage,
> > it jus
This one time, at band camp, Marco d'Itri said:
> On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote:
>
> > We need something which upgrades seamlessly, and the above solution is not
> > acceptable for the etch release, as has been said already in the past.
> This would be nice, but so far nobody ha
On Fri, Feb 10, 2006 at 11:27:12AM +0100, Marco d'Itri wrote:
> On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote:
>
> > We need something which upgrades seamlessly, and the above solution is not
> > acceptable for the etch release, as has been said already in the past.
> This would be nice, but so
On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote:
> The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot
> anyway, so, we only need something that :
>
> - don't mess up the currently running stuff, is it possible to have udev
> installed to take effect after the next r
[EMAIL PROTECTED] wrote:
>In this case, does itmake any sense to treat the two versions of udev
>similarly to how we treat library transitions? I.e., rename the new
>udev to udev-$min-kernel-ver or something? (the name is ugly, but you
It's not clear which problem this would solve, exactly.
--
On Fri, Feb 10, 2006 at 01:54:37PM +0100, Marco d'Itri wrote:
> On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote:
>
> > The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot
> > anyway, so, we only need something that :
> >
> > - don't mess up the currently running stuff, i
On Wed, Feb 08, 2006 at 08:48:57PM -0800, Steve Langasek wrote:
> On Wed, Feb 08, 2006 at 05:10:28PM +0100, Daniel Kobras wrote:
>
> > Peter S Galbraith <[EMAIL PROTECTED]>
> >gri
>
> Only needed on i386, it seems.
Not (automatically) binNMUable because tarball ships read-only
debian/changel
On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote:
> > > 1) sarge-udev & etch-udev install concurently, maybe using the divert or
> > > alternative mechanism to not overwrite their files.
> > As I explained, I do not believe that on-disk co-existence of two udev
> > packages is feasible.
> Mmm,
On Fri, Feb 10, 2006 at 03:45:28AM -0800, Steve Langasek wrote:
> Then what does this have to do with the problem people are trying to solve?
> The problem is that there is *no* kernel available in sarge that meets the
> needs of the etch udev and lvm packages, and as a result people have to
> inst
On Fri, Feb 10, 2006 at 04:52:50PM +0100, Marco d'Itri wrote:
> On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote:
>
> > > > 1) sarge-udev & etch-udev install concurently, maybe using the divert
> > > > or
> > > > alternative mechanism to not overwrite their files.
> > > As I explained, I do n
On Fri, Feb 10, 2006 at 01:41:55PM +0100, Sven Luther wrote:
> On Fri, Feb 10, 2006 at 11:27:12AM +0100, Marco d'Itri wrote:
> > On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote:
> > > We need something which upgrades seamlessly, and the above solution is not
> > > acceptable for the etch release,
On Fri, Feb 10, 2006 at 07:54:01PM +0100, Bastian Blank wrote:
> On Fri, Feb 10, 2006 at 03:45:28AM -0800, Steve Langasek wrote:
> > Then what does this have to do with the problem people are trying to solve?
> > The problem is that there is *no* kernel available in sarge that meets the
> > needs o
On Fri, Feb 10, 2006 at 01:21:22PM -0800, Steve Langasek wrote:
> - Doesn't fuck the system if you lose power part-way through the
>dist-upgrade after udev has been unpacked and no newer kernel has been
>installed.
Hehe, never thougth about that. i guess that having udev depend on a kerne
On Fri, Feb 10, 2006 at 01:30:51PM -0800, Steve Langasek wrote:
> > No, they need to reboot after installing udev/lvm, not before.
> Then you've once again left the user without any assurance that their system
> is bootable at the end of the udev/lvm install.
Which is the same than the other way a
On Fri, Feb 10, 2006 at 10:45:23PM +0100, Sven Luther wrote:
> On Fri, Feb 10, 2006 at 01:21:22PM -0800, Steve Langasek wrote:
> > - Doesn't fuck the system if you lose power part-way through the
> >dist-upgrade after udev has been unpacked and no newer kernel has been
> >installed.
> Heh
On Thu, Feb 09, 2006 at 10:37:38 +0100, Martin Schulze wrote:
> Martin Zobel-Helas wrote:
> > there was some discussion[1] wether the next stable update could have
> > some timezone data updated in the glibc package.
>
> Show me the changes.
>
> Unless large chunks of the world are affected I don
On Fri, Feb 10, 2006 at 10:57:27PM +0100, Bastian Blank wrote:
> On Fri, Feb 10, 2006 at 01:30:51PM -0800, Steve Langasek wrote:
> > > No, they need to reboot after installing udev/lvm, not before.
> > Then you've once again left the user without any assurance that their system
> > is bootable at t
On Fri, Feb 10, 2006 at 04:19:05PM +0100, Daniel Kobras wrote:
> On Wed, Feb 08, 2006 at 08:48:57PM -0800, Steve Langasek wrote:
> > On Wed, Feb 08, 2006 at 05:10:28PM +0100, Daniel Kobras wrote:
> > > Helen Faulkner <[EMAIL PROTECTED]>
> > >labplot
> Dep-Waits on current vtk on m68k. hppa bu
On Fri, Feb 10, 2006 at 04:52:50PM +0100, Marco d'Itri wrote:
> On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote:
> > > > 1) sarge-udev & etch-udev install concurently, maybe using the divert
> > > > or
> > > > alternative mechanism to not overwrite their files.
> > > As I explained, I do not
On Fri, Feb 10, 2006 at 04:20:02PM -0800, Steve Langasek wrote:
> This means you're not guaranteed to get /usr/sbin/sshd, which many admins
> use exclusively for system administration where remote kvm is not an
> affordable option. That's a pretty big problem.
Maybe we need a sshd in /sbin then,
29 matches
Mail list logo
