On Tue, Aug 25, 2009 at 5:18 PM, Andreas Radke wrote:

i686 version is now also available.

to the devs: please post your opinions where it should go after the testing period? do you want it in extra or as official alternative even in core?

I'd prefer extra but would also like to see this kernel as a 2nd choice on our future iso snapshots.

I agree it might be nice to have a choice, but I also think that if we're going to make sure something is stable, we should try to enforce some sort of signoff process, just to ensure it's all working ok

On Wed, Aug 26, 2009 at 3:34 AM, Ronald van Haren wrote:

On Wed, Aug 26, 2009 at 12:20 AM, Aaron Griffin wrote:

...

On Tue, Aug 25, 2009 at 5:18 PM, Andreas Radke wrote:

...

i686 version is now also available.

to the devs: please post your opinions where it should go after the testing period? do you want it in extra or as official alternative even in core?

I'd prefer extra but would also like to see this kernel as a 2nd choice on our future iso snapshots.

I agree it might be nice to have a choice, but I also think that if we're going to make sure something is stable, we should try to enforce some sort of signoff process, just to ensure it's all working ok

agreed, it should go into core where we have to signoff. It would be funny to find out that our lts kernel is broken at some time... people expect something more 'stable' than the latest kernel so we have to make sure that it works fine.

Ronald

I don't think that it needs to go in core to get signoffs. We could put it in extra and make an exception (i.e. require signoff). The only advantage of putting it in core is to offer it as an alternative kernel for the iso.

Dale Blount a écrit :

...

I don't think that it needs to go in core to get signoffs. We could put it in extra and make an exception (i.e. require signoff). The only advantage of putting it in core is to offer it as an alternative kernel for the iso.

Is there a disadvantage to putting it in core? I'd say if I was going to install the lts kernel on a server, It'd be annoying to have to install using kernel26 then install lts from extra later. Having it available on the install CD would be useful. Not to mention core explicitly requires signoffs which solves that problem also.

Dale

+1 from me for putting it in core

Andreas Radke schrieb:

I can boot my ext4 / filesystem with a clean dmesg :)

I don't care if I will maintain it in core or extra with additional signoff. Maybe our ISO makers should say if they have enough space for this kernel for both arches in core or if they would like to put it manually as bonus to the disc and how the selection will work (remember the scsi/ide years?).

To me core would be the more logical place stating it's of the same quality and importance.

This may mean the end of the multi-arch images unless we can compress the squashfs better.

On Wed, Aug 26, 2009 at 5:31 PM, Aaron Griffin wrote:

On Wed, Aug 26, 2009 at 5:14 PM, Thomas Bächler wrote:

...

Andreas Radke schrieb:

...

I can boot my ext4 / filesystem with a clean dmesg :)

I don't care if I will maintain it in core or extra with additional signoff. Maybe our ISO makers should say if they have enough space for this kernel for both arches in core or if they would like to put it manually as bonus to the disc and how the selection will work (remember the scsi/ide years?).

To me core would be the more logical place stating it's of the same quality and importance.

This may mean the end of the multi-arch images unless we can compress the squashfs better.

We can. squashfs-lzma is a significant improvement, but it can't be built out of tree, I don't think (last I checked was a while ago, this may have changed)

http://www.squashfs-lzma.org/ method block size Slax data size percent uncompressed - 668 MB 100% mksquashfs+gzip 64KB 227 MB 34% mksquashfs+gzip 1024KB 222 MB 33% mksquashfs+lzma 64KB 191 MB 28% mksquashfs+lzma 128KB 184 MB 27% mksquashfs+lzma 512KB 172 MB 26% mksquashfs+lzma 1024KB 167 MB 25%

On Wed, Aug 26, 2009 at 5:32 PM, Thomas Bächler wrote:

Aaron Griffin schrieb:

...

We can. squashfs-lzma is a significant improvement, but it can't be built out of tree, I don't think (last I checked was a while ago, this may have changed)

It has been discontinued when squashfs was merged into the kernel. Now lzma is also merged into the kernel, but neither squashfs nor the squashfs-tools support lzma.

I guess OpenWRT has patches for it.

From a mailing list port:

Phillip Lougher Jun 17, 2009

Since lzma is in kernel 2.6.30 now, is it going to be added into kernel 2.6.31 or 2.6.32 merger window?

I started working on LZMA support a couple of days ago. I'm hoping to get it finished for the 2.6.31 merge window, though I may miss this. It depends on whether I hit any problems, and how soon the merge window closes. ------ So this is on the docket. When it's supported, we'll have more space to play with. We can also play with the blocksize for squashfs, to see if it'd make a difference