On Sat, Feb 18, 2006 at 01:03:53AM -0800, Steve Langasek wrote:
> On Sat, Feb 11, 2006 at 08:11:34AM +0100, Sven Luther wrote:
> > 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 fo
On Sat, Feb 11, 2006 at 08:11:34AM +0100, Sven Luther wrote:
> 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
On Sat, Feb 11, 2006 at 11:07:02AM +0100, Marco d'Itri wrote:
> On Feb 11, Sven Luther <[EMAIL PROTECTED]> wrote:
>
> > As the install media are built our of main though, this is probably not
> > going
> > to cut it without proof that it can be done on a technical point of view.
> It could be mai
On Sat, Feb 11, 2006 at 10:33:32AM +0100, Marco d'Itri <[EMAIL PROTECTED]>
wrote:
> I also plan a GR to accept in main "less free" artwork which if removed
> does not change the functionality of the software using it (e.g. the
> firefox logo).
The main problem with the firefox logo is not its non
On Feb 11, Sven Luther <[EMAIL PROTECTED]> wrote:
> As the install media are built our of main though, this is probably not going
> to cut it without proof that it can be done on a technical point of view.
It could be main or a subset of non-free or a new section, it's just a
detail which I do not
On Sat, Feb 11, 2006 at 10:33:32AM +0100, Marco d'Itri wrote:
> On Feb 11, Steve Langasek <[EMAIL PROTECTED]> wrote:
>
> > Why temporary, out of curiosity? This doesn't seem like a temporary
> > problem; I think this is an issue that will be just as applicable for etch+1
> > as it is for etch, an
On Feb 11, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Why temporary, out of curiosity? This doesn't seem like a temporary
> problem; I think this is an issue that will be just as applicable for etch+1
> as it is for etch, and I think we should be honest about that.
Because maybe in 5-10 years fr
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,
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 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 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 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 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 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: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 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 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 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 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 Fri, Feb 10, 2006 at 02:01:05PM +0100, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 10 Feb 2006 13:41:55 +0100
> Sven Luther <[EMAIL PROTECTED]> wrote:
>
> > 1) sarge-udev & etch-udev install concurently, maybe using the
> > divert or alternative mech
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 10 Feb 2006 13:41:55 +0100
Sven Luther <[EMAIL PROTECTED]> wrote:
> 1) sarge-udev & etch-udev install concurently, maybe using the
> divert or alternative mechanism to not overwrite their files.
Beware that some packages depend versioned on
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
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 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
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 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 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 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 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
On Fri, Feb 10, 2006 at 01:54:42AM +0100, Marco d'Itri wrote:
> On Feb 10, Otavio Salvador <[EMAIL PROTECTED]> wrote:
>
> > But udev will refuse to start or to install if the running kernel is
> > older then it?
> As it currently happens, it will either:
> - refuse to be upgraded
> - be installed
On Feb 10, Otavio Salvador <[EMAIL PROTECTED]> wrote:
> But udev will refuse to start or to install if the running kernel is
> older then it?
As it currently happens, it will either:
- refuse to be upgraded
- be installed but not started if it was not installed yet
- not be started at boot time if
[EMAIL PROTECTED] (Marco d'Itri) writes:
> 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 the package.
> Does an
32 matches
Mail list logo
