Re: linux-2.6 - subarch and patches
On Wed, Aug 03, 2005 at 07:57:22PM +0200, Christoph Hellwig wrote: On Wed, Aug 03, 2005 at 07:55:12PM +0200, Bastian Blank wrote: - Each arch may specify an architectury specific patch, each image package may specify another patch, it may shared between more than one image. Or fix the architectures to not require them. The mips changes are fine for any other architecture, although they should be split into a few more. The m68k patch as-is isn't, but we hope to have m68k compiling from mainline sources soon after the 2.6.14 tree opens. I hope the powerpc/apus patch will be fine soon, but what about things like the (upcoming ?) powerpc/nubus patch ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
On Mon, Aug 08, 2005 at 10:47:53AM +0200, Sven Luther wrote: On Wed, Aug 03, 2005 at 07:57:22PM +0200, Christoph Hellwig wrote: On Wed, Aug 03, 2005 at 07:55:12PM +0200, Bastian Blank wrote: - Each arch may specify an architectury specific patch, each image package may specify another patch, it may shared between more than one image. Or fix the architectures to not require them. The mips changes are fine for any other architecture, although they should be split into a few more. The m68k patch as-is isn't, but we hope to have m68k compiling from mainline sources soon after the 2.6.14 tree opens. I hope the powerpc/apus patch will be fine soon, but what about things like the (upcoming ?) powerpc/nubus patch ? Let's just work with the people to sort it out early enough. It's not like it'll be stable enough for a distro as soon as the port is mostly running anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
On Mon, Aug 08, 2005 at 09:00:01PM +0200, Christoph Hellwig wrote: On Mon, Aug 08, 2005 at 10:47:53AM +0200, Sven Luther wrote: On Wed, Aug 03, 2005 at 07:57:22PM +0200, Christoph Hellwig wrote: On Wed, Aug 03, 2005 at 07:55:12PM +0200, Bastian Blank wrote: - Each arch may specify an architectury specific patch, each image package may specify another patch, it may shared between more than one image. Or fix the architectures to not require them. The mips changes are fine for any other architecture, although they should be split into a few more. The m68k patch as-is isn't, but we hope to have m68k compiling from mainline sources soon after the 2.6.14 tree opens. I hope the powerpc/apus patch will be fine soon, but what about things like the (upcoming ?) powerpc/nubus patch ? Let's just work with the people to sort it out early enough. It's not like it'll be stable enough for a distro as soon as the port is mostly running anyway. I have big hopes for the apus case to be cleanly integrated in the near future, but the nubus case is more problematic. But we will see. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
On Sat, Aug 06, 2005 at 07:43:06AM +0200, Thiemo Seufer wrote: apt-get install linux-headers-$(uname -r) Fun, yet another thing in the common package which doesn't work for mips (mipsel machines have mips as uname). uname -r != uname -m | $ uname -r | 2.6.10-1-s390x | $ uname -m | s390x Bastian -- It would seem that evil retreats when forcibly confronted. -- Yarnek of Excalbia, The Savage Curtain, stardate 5906.5 signature.asc Description: Digital signature
Re: linux-2.6 - subarch and patches
Bastian Blank wrote: On Sat, Aug 06, 2005 at 07:43:06AM +0200, Thiemo Seufer wrote: apt-get install linux-headers-$(uname -r) Fun, yet another thing in the common package which doesn't work for mips (mipsel machines have mips as uname). uname -r != uname -m | $ uname -r | 2.6.10-1-s390x | $ uname -m | s390x Right, but it still fails: hattusa:~$ uname -r 2.4.27-sb1-swarm-bn is also the same for both endiannesses. Thiemo
Re: linux-2.6 - subarch and patches
On Sat, Aug 06, 2005 at 09:32:33AM +0200, Thiemo Seufer wrote: Right, but it still fails: hattusa:~$ uname -r 2.4.27-sb1-swarm-bn is also the same for both endiannesses. And the headers package is available for both the debian mips and mipsel architecture. Bastian -- A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, The Menagerie, stardate 3012.4 signature.asc Description: Digital signature
Re: linux-2.6 - subarch and patches
Bastian Blank wrote: On Sat, Aug 06, 2005 at 09:32:33AM +0200, Thiemo Seufer wrote: Right, but it still fails: hattusa:~$ uname -r 2.4.27-sb1-swarm-bn is also the same for both endiannesses. And the headers package is available for both the debian mips and mipsel architecture. It needs different .configs since endianness is a config option on mips. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
On Sat, 6 Aug 2005, Thiemo Seufer wrote: Bastian Blank wrote: On Sat, Aug 06, 2005 at 09:32:33AM +0200, Thiemo Seufer wrote: And the headers package is available for both the debian mips and mipsel architecture. It needs different .configs since endianness is a config option on mips. Ok, so what's the problem then? Different configs mean different flavours. Flavour name is encoded in the output of uname -r, so the flavour-specific header file will just have to depend on the correct common subarch header file. That's the reason for a requirement that flavour names would be unique. Then we can name the flavour-specific header package linux-headers-$(version)-$(abiname)-$(flavour) and uname -r will return $(version)-$(abiname)-$(flavour). This header package will depend on linux-headers-$(subarch)-$(version)-$(abiname), which is the common headers package for this subarch. Is there any case that is not taken into account by this scheme? Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
On Wed, 3 Aug 2005, Bastian Blank wrote: Hi folks linux-2.6 currently supports something called subarch. It should be used for incompatible patches. This is needed for m68k and I think mips. Problems with this - mostly unimplemented, I can't say that I have extensively tested the subarch cases, but I definitely had it in mind, and I'd rather describe its state as very poorly tested than mostly unimplemented :-) - namingschema differs from anything else: linux-image-$subarch-2.6-$flavour. Proposal: Replace with patch definitions. - Each arch may specify an architectury specific patch, each image package may specify another patch, it may shared between more than one image. There is actually code for that in $(kdir) target in debian/Makefile: patches := $(wildcard patches-arch/$(subarch).*) patches += $(wildcard patches-arch/$(subarch)_*) patches += $(wildcard patches-arch/$(karch).*) patches += $(wildcard patches-arch/$(karch)_*) patches := $(strip $(patches)) [...] $(kdir): post-install-$(subarch) $(wildcard templates/control.*.in) [...] if [ -n '$(patches)' ]; then\ cd $(tkdir); \ cat $(addprefix ../,$(patches)) | patch -p1; \ fi Definitely there is room for improvement, but your proposal is (at least partially) implemented. - Generated packages: - Patches: - linux-patch-debian-$version (the same than now) - linux-patch-debian-$version-$arch - linux-patch-debian-$version-$arch-$name With the common source package I see absolutely no reason to split the patches up. And the code which will collect all the arch/subarch specific patches and put it into a single linux-patch-debian package is already there. - Header: Any of the package contains the same, just with the patches applied. That is also taken into account already: the subarch-specific header packages are built (or rather, would be built) from the patched tree, so all the header files are correct. If we have want to code something more, we may produce packages which just links most of the files to the more generic version. - linux-headers-$version-$abiname (as known) - linux-headers-$version-$abiname-$arch - linux-headers-$version-$abiname-$arch-$name I don't have any objections to this naming scheme (generally, I don't care about naming so much :-). The only thing which in my opinion _must_ be guaranteed, is that running apt-get install linux-headers-$(uname -r) will install the full set of packages for the currently running kernel. If you have a clear picture on how to do that in your naming scheme, just go ahead and make the necessary changes. - linux-header-$version-$abiname-$flavour depends against the main header package which the correct patches. Bastian It turns out that I will not be available on Saturday to discuss these things, sorry about that. Hopefully we can talk on Sunday. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
Jurij Smakov wrote: [snip] I don't have any objections to this naming scheme (generally, I don't care about naming so much :-). The only thing which in my opinion _must_ be guaranteed, is that running apt-get install linux-headers-$(uname -r) will install the full set of packages for the currently running kernel. Fun, yet another thing in the common package which doesn't work for mips (mipsel machines have mips as uname). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
On Wed, 03 Aug 2005 19:55:12 +0200, Bastian Blank wrote: Hi folks linux-2.6 currently supports something called subarch. It should be used for incompatible patches. This is needed for m68k and I think mips. Problems with this - mostly unimplemented, - namingschema differs from anything else: linux-image-$subarch-2.6-$flavour. Proposal: Replace with patch definitions. I'm in the Christoph school of thought; I'd rather see archs get their patches upstream. I'm willing to tolerate subarchs (and get them working if no one else does) after a rather long argument w/ Sven. If you want to implement your proposal in a branch and get it working 100%, we can replace the subarch stuff w/ it. I would recommend doing it sooner rather than later, however; if I get around to doing the subarch stuff, and it works, I won't be overly excited about dealing w/ more package renaming. I must admit that I do prefer your proposal's naming convention for header packages, however. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-2.6 - subarch and patches
Hi folks linux-2.6 currently supports something called subarch. It should be used for incompatible patches. This is needed for m68k and I think mips. Problems with this - mostly unimplemented, - namingschema differs from anything else: linux-image-$subarch-2.6-$flavour. Proposal: Replace with patch definitions. - Each arch may specify an architectury specific patch, each image package may specify another patch, it may shared between more than one image. - Generated packages: - Patches: - linux-patch-debian-$version (the same than now) - linux-patch-debian-$version-$arch - linux-patch-debian-$version-$arch-$name - Header: Any of the package contains the same, just with the patches applied. If we have want to code something more, we may produce packages which just links most of the files to the more generic version. - linux-headers-$version-$abiname (as known) - linux-headers-$version-$abiname-$arch - linux-headers-$version-$abiname-$arch-$name - linux-header-$version-$abiname-$flavour depends against the main header package which the correct patches. Bastian -- A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, The Menagerie, stardate 3012.4 signature.asc Description: Digital signature
Re: linux-2.6 - subarch and patches
On Wed, Aug 03, 2005 at 07:55:12PM +0200, Bastian Blank wrote: - Each arch may specify an architectury specific patch, each image package may specify another patch, it may shared between more than one image. Or fix the architectures to not require them. The mips changes are fine for any other architecture, although they should be split into a few more. The m68k patch as-is isn't, but we hope to have m68k compiling from mainline sources soon after the 2.6.14 tree opens. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
