udev-149...
 

Am Wed, 2 Dec 2009 21:50:17 +0100
schrieb Andreas Radke <a.radke@arcor.de>:

> with more major changes...
>
> -Andy
>

and 149 is out.

Just a question: is our early boot stuff and kernel part well enough
maintained right now? I often see Tobias and Thomas away for longer
periods these days.

-Andy

udev-149...
 

On Thu, Dec 3, 2009 at 12:09 PM, Andreas Radke <a.radke@arcor.de> wrote:
> Am Wed, 2 Dec 2009 21:50:17 +0100
> schrieb Andreas Radke <a.radke@arcor.de>:
>
>> with more major changes...
>>
>> -Andy
>>
>
> and 149 is out.
>
> Just a question: is our early boot stuff and kernel part well enough
> maintained right now? I often see Tobias and Thomas away for longer
> periods these days.

Well, yes and no. We want to get rid of klibc and just stick glibc in
the image, and that's a big project that's on the plate.

What are you worried about specifically? The klibc build udev?

udev-149...
 

Am Thu, 3 Dec 2009 12:30:44 -0600
schrieb Aaron Griffin <aaronmgriffin@gmail.com>:

> What are you worried about specifically? The klibc build udev?
>

mkinitcpio is broken for my notebook with new .32 kernels and kms. I
mailed about the new kernel some time ago. Somebody had already asked
about a new release. Udev needs a lot of love these days and the new
kernel is also out.

But it's more a general feeling that has come over me that in the last
weeks the number of active developers has decreased again.

-Andy

udev-149...
 

Andreas Radke schrieb:

mkinitcpio is broken for my notebook with new .32 kernels and kms. I
mailed about the new kernel some time ago. Somebody had already asked
about a new release. Udev needs a lot of love these days and the new
kernel is also out.

But it's more a general feeling that has come over me that in the last
weeks the number of active developers has decreased again.


tpowa is already working on 2.6.32 and your problem with KMS is not a
problem in mkinitcpio.
About udev - we have a problem with cryptsetup that will cause
regressions if we move the current udev+device-mapper to core, and I
still have no solution for those.



That said, releasing a new mkinitcpio with a bugfix is not possible if
commits are being pushed that obviously break existing setups without
any reasonable upgrade path. The reason for that breakage is that some
people think sh-compatibility is more important than anything else:

http://projects.archlinux.org/mkinitcpio.git/commit/?id=984cbd4eb023001668eea530e2b5ed2e57ba3693
And then you also add a warning that is printed every time mkinitcpio is
run. So now before I can release anything, I have to clean up other
people's commits first.

udev-149...
 

Am Freitag 04 Dezember 2009 schrieb Thomas Bächler:
> Andreas Radke schrieb:
> > mkinitcpio is broken for my notebook with new .32 kernels and kms. I
> > mailed about the new kernel some time ago. Somebody had already asked
> > about a new release. Udev needs a lot of love these days and the new
> > kernel is also out.
> >
> > But it's more a general feeling that has come over me that in the last
> > weeks the number of active developers has decreased again.
>
> tpowa is already working on 2.6.32 and your problem with KMS is not a
> problem in mkinitcpio.
> About udev - we have a problem with cryptsetup that will cause
> regressions if we move the current udev+device-mapper to core, and I
> still have no solution for those.
>
>
> That said, releasing a new mkinitcpio with a bugfix is not possible if
> commits are being pushed that obviously break existing setups without
> any reasonable upgrade path. The reason for that breakage is that some
> people think sh-compatibility is more important than anything else:
> http://projects.archlinux.org/mkinitcpio.git/commit/?id=984cbd4eb023001668e
> ea530e2b5ed2e57ba3693 And then you also add a warning that is printed every
> time mkinitcpio is run. So now before I can release anything, I have to
> clean up other people's commits first.
>
Udev-149 removes /dev/hd* rules, the question is if we should add it as compat
rules, i don't know how stable the ata subsystem is on .27 lts series.
Also we can think of removing the old ide subsystem from kernel .32 series and
mkinitcpio.
I think it can stay until it's removed from kernel anyway, any other opinions?

thanks
greetings
tpowa

--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

udev-149...
 

On Fri, 2009-12-04 at 08:24 +0100, Tobias Powalowski wrote:
> Udev-149 removes /dev/hd* rules, the question is if we should add it
> as compat
> rules, i don't know how stable the ata subsystem is on .27 lts series.
> Also we can think of removing the old ide subsystem from kernel .32
> series and
> mkinitcpio.
> I think it can stay until it's removed from kernel anyway, any other
> opinions?

The libata framework is stable for 2.6.27, I'm using libata on 2.6.24
and 2.6.26 without problems, so 2.6.27 shouldn't be an issue.
Problem is the drivers. Not all drivers are bug-free in the libata
framework. With intel you won't notice any problems, but the sis driver
is a bit suspicious.

udev-149...
 

Loui Chang schrieb:

I was all for providing 'reasonable upgrade paths' but in reality they
are unreasonable and Aaron duly pointed that out to me. If maintainers
of preset files can't read mkinitcpio output and change a bash array
into a string they are being unreasonable. The alternative is to have
a series of hacks in mkinitcpio introduced and then removed over a
number of releases. The issue was really not so complicated as to
warrant that.

It would have been helpful if you shared your insights back when I
submitted the patches though.


Your "submission" didn't go through the appropriate channels (i.e. the
bugtracker) but through personal emails to Aaron and me (which I didn't
have the time to read back then which is my fault).


I don't see a reason to introduce such big breakage for something as
placebo-ish as sh-compatibility, when we use bash for the initscripts
anyway.
The fact that the presets are not sh-compatible is my fault though, I
didn't realize when I wrote them that the rest of mkinitcpio was
sh-compatible and arrays are not - but nobody complained either.

udev-149...
 

Jan de Groot schrieb:

The libata framework is stable for 2.6.27, I'm using libata on 2.6.24
and 2.6.26 without problems, so 2.6.27 shouldn't be an issue.
Problem is the drivers. Not all drivers are bug-free in the libata
framework. With intel you won't notice any problems, but the sis driver
is a bit suspicious.



The pata_sis driver never worked for my desktop - until the motherboard
went up in smoke, so I cannot test if this improved.


That said, I agree that we can remove IDE from 2.6.32 with the
appropriate warning signs set everywhere.

udev-149...
 

Am Freitag 04 Dezember 2009 schrieb Thomas Bächler:
> Loui Chang schrieb:
> > I was all for providing 'reasonable upgrade paths' but in reality they
> > are unreasonable and Aaron duly pointed that out to me. If maintainers
> > of preset files can't read mkinitcpio output and change a bash array
> > into a string they are being unreasonable. The alternative is to have
> > a series of hacks in mkinitcpio introduced and then removed over a
> > number of releases. The issue was really not so complicated as to
> > warrant that.
> >
> > It would have been helpful if you shared your insights back when I
> > submitted the patches though.
>
> Your "submission" didn't go through the appropriate channels (i.e. the
> bugtracker) but through personal emails to Aaron and me (which I didn't
> have the time to read back then which is my fault).
>
> I don't see a reason to introduce such big breakage for something as
> placebo-ish as sh-compatibility, when we use bash for the initscripts
> anyway.
> The fact that the presets are not sh-compatible is my fault though, I
> didn't realize when I wrote them that the rest of mkinitcpio was
> sh-compatible and arrays are not - but nobody complained either.
>
According to this, still not everything is migrated to new pata subsystem.
http://article.gmane.org/gmane.linux.ide/43151
Delaying removement of old ide subsystem for now.

greetings
tpowa
--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

udev-149...
 

On Fri, Dec 4, 2009 at 2:58 AM, Thomas Bächler <thomas@archlinux.org> wrote:
> Jan de Groot schrieb:
>>
>> The libata framework is stable for 2.6.27, I'm using libata on 2.6.24
>> and 2.6.26 without problems, so 2.6.27 shouldn't be an issue.
>> Problem is the drivers. Not all drivers are bug-free in the libata
>> framework. With intel you won't notice any problems, but the sis driver
>> is a bit suspicious.
>>
>
> The pata_sis driver never worked for my desktop - until the motherboard went
> up in smoke, so I cannot test if this improved.
>
> That said, I agree that we can remove IDE from 2.6.32 with the appropriate
> warning signs set everywhere.

Hell no, -300 on this. My second computer won't boot at *all* with the
newer drivers, it absolutely needs the older drivers. What is the rush
to kill these drivers from our kernel anyway? If upstream doesn't
remove them we shouldn't be...

-Dan