Bug#355554: squashfs: Building modules to out-of-tree
How long until you (or your sponsor) have uploaded it? -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Daniel Baumann wrote: How long until you (or your sponsor) have uploaded it? It's already uploaded, but in the NEW queue (new binary package names). See e.g. http://qa.debian.org/developer.php?package=squashfs bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Any news so far? -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Hello Daniel, Arnaud, Phillip, Following Daniel's suggest on Debian bug #34 to be able to build squashfs without patching kernel, I've tried to do the same thing he's already done for 2.6.15 with the latest 2.4 kernel patch. It's a bit trickier as some definitions don't exist in vanilla kernel if it's not patched... I've tried to workaround using some 'ext2' definitions, checked it works, but if you can review it, it would be nice. Daniel, Arnaud, if we want to support 2.4, we would give both 2.4 and 2.6 sources, perhaps in 2 separate packages ? I don't use / know module-assistant, so I don't have tried to integrate it with this tool. Hope it can help, with regards, Frédéric Boiteux. squashfs-2.4.tar.bz2 Description: application/bzip
Bug#355554: squashfs: Building modules to out-of-tree
Frédéric BOITEUX wrote: I've tried to workaround using some 'ext2' definitions, checked it works, but if you can review it, it would be nice. I'll look into it too. Daniel, Arnaud, if we want to support 2.4, we would give both 2.4 and 2.6 sources, perhaps in 2 separate packages ? No, there is no technical reason to not have both modules in one source package. It's actually even easier to keep them together. I don't use / know module-assistant, so I don't have tried to integrate it with this tool. Np, that is what Arnaud or I will do anyway :) -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Hello, I haven't answer to this bug report because i have discussed about this one with Daniel on IRC, following this discussion, a mail to the upstream author has been sent. I will take a look at module packaging (including m-a) in the next days ;). Regards, Arnaud Fontaine pgpWwyk2eFqVu.pgp Description: PGP signature
Bug#355554: squashfs: Building modules to out-of-tree
[EMAIL PROTECTED] wrote: Your release-tarball contains only the patches against specific kernel-versions, but we need the files in 'plain format'. In the first attempt[1] to build the debian package for that, I had to rebuild your release-tarball. We want to avoid that if possible, so.. what is your opinion/plan? Adding a directory with the Squashfs files in plain format (rather than as patches) to the release tarball is possible. I've had a look at [1] and this doesn't look too much extra work. There are a couple of issues: 1. The Makefile will be a simple build out of kernel Makefile suitable for most people. Invariably you'll have to replace this with your Makefile. 2. The Kbuild config options won't be available. I'll add a change to define CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE if the Kbuild system hasn't defined it, as I see you've had to do so. 3. The initrd support depends on patching the kernel. This won't be supported by the out of kernel build code. Phillip
Bug#355554: squashfs: Building modules to out-of-tree
Phillip Lougher wrote: Adding a directory with the Squashfs files in plain format (rather than as patches) to the release tarball is possible. I've had a look at [1] and this doesn't look too much extra work. There are a couple of issues: Thanks for your quick answer. When can you release a new version including that? Btw, I first though to patch the 2.4-2.6 diff for autobuild 2.4 modules, but it is easier, if you would provide 'unpacked' patches for both the latest 2.4 and 2.6 kernel. 1. The Makefile will be a simple build out of kernel Makefile suitable for most people. Invariably you'll have to replace this with your Makefile. No problem. 2. The Kbuild config options won't be available. I'll add a change to define CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE if the Kbuild system hasn't defined it, as I see you've had to do so. I'm fine with this. 3. The initrd support depends on patching the kernel. This won't be supported by the out of kernel build code. That is not needed, but just out of couriosity: why is that so? As far as I saw, only the mount routine gets an updated magic number for squashfs-images, is that the reason? Regards, Daniel -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Package: squashfs Severity: important Hi, [ Disclaimer: this mail should not be taken as an offense, I just want to get things done quickly. ] as I wrote you a few days ago, we want the module packages for squashfs autobuilt (needed for Debian Live[0]). As I didn't got any answer so far, I made the package[1] on my own. I tested it successfully on amd64, i386, powerpc and sparc. We have now two possibilities: * If you agree, I upload the package which replaces the current squashfs package (prefered). * If you don't agree, I upload the package with a different source name (making the squashfs package obselete) Please have a look at the package and tell me your opinion. Regards, Daniel [0] http://live.debian.net/ [1] http://ftp-master.debian-unofficial.org/live-archive/squashfs/ -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Hi Daniel, thanks for your work and sorry for the delay. Daniel Baumann wrote: as I wrote you a few days ago, we want the module packages for squashfs autobuilt (needed for Debian Live[0]). As I didn't got any answer so far, I made the package[1] on my own. I tested it successfully on amd64, i386, powerpc and sparc. We have now two possibilities: * If you agree, I upload the package which replaces the current squashfs package (prefered). * If you don't agree, I upload the package with a different source name (making the squashfs package obselete) No, please don't do neither. Arnaud is already investigating this issue. Please coordinate with him. Maybe your patch can just be applied to the current version (Arnaud, please check the diffs carefully because of other changes like docs etc.). You are welcome to be added to the list of comaintainers! Maybe it's time to create a team maintenance project at alioth? Arnaud? Thanks, bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Hello, Le lun 06 mar 2006 13:19:52 CET, Daniel Baumann [EMAIL PROTECTED] a écrit : Package: squashfs Severity: important Hi, [ Disclaimer: this mail should not be taken as an offense, I just want to get things done quickly. ] as I wrote you a few days ago, we want the module packages for squashfs autobuilt (needed for Debian Live[0]). As I didn't got any answer so far, I made the package[1] on my own. I tested it successfully on amd64, i386, powerpc and sparc. We have now two possibilities: * If you agree, I upload the package which replaces the current squashfs package (prefered). * If you don't agree, I upload the package with a different source name (making the squashfs package obselete) Please have a look at the package and tell me your opinion. Hello, I'm not the official maintener but have worked sometimes on this package and using it. I've looked a bit on your package, and seems not to give any kernel patch : are they no longer useful for 2.6.15 kernels ? Anyway, everybody doesn't use latest kernel version (nor 2.6 kernel), if you want to replace the current package, it should give support for 2.4 and older 2.6 kernels ! Fred.
Bug#355554: squashfs: Building modules to out-of-tree
Hi, Daniel Baumann wrote: No, please don't do neither. Arnaud is already investigating this issue. Please coordinate with him. Maybe your patch can just be applied to the current version (Arnaud, please check the diffs carefully because of other changes like docs etc.). one can't just apply a patch between the current one and my one, to be able to build it out-of-tree, you have to repackage it (like I did). Why would this be necessary? I would prefer to keep the orig.tar.gz identical to upstream (e.g. in case of new upstream releases, etc.). Otherwise, we wouldn't even need a orig.tar.gz anymore. (?) Feel free to give me the package for uploading, if both of you agree on a version. Thanks, bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Roland Stigge wrote: thanks for your work and sorry for the delay. np. No, please don't do neither. Arnaud is already investigating this issue. Please coordinate with him. Maybe your patch can just be applied to the current version (Arnaud, please check the diffs carefully because of other changes like docs etc.). one can't just apply a patch between the current one and my one, to be able to build it out-of-tree, you have to repackage it (like I did). Arnaud, did you already make a new package on your own? Maybe it's time to create a team maintenance project at alioth? Arnaud? I personally don't think that an alioth project is needed. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Frédéric BOITEUX wrote: I'm not the official maintener but have worked sometimes on this package and using it. I've looked a bit on your package, and seems not to give any kernel patch : are they no longer useful for 2.6.15 kernels ? There is no kernel-patch because we want to build it out-of-tree, not in-tree. Anyway, everybody doesn't use latest kernel version (nor 2.6 kernel), if you want to replace the current package, it should give support for 2.4 and older 2.6 kernels ! I beg to differ: * the modules which are autobuilt are for 2.6 only, etch will likely not ship any 2.4 kernel, so 2.4 autobuilt support would be useless anyway. * if you still want to built modules for 2.4, you can semi-autobuild them by using module-assistant (therefore, it has the squashfs-source package). Regards, Daniel -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Roland Stigge wrote: one can't just apply a patch between the current one and my one, to be able to build it out-of-tree, you have to repackage it (like I did). Why would this be necessary? I would prefer to keep the orig.tar.gz identical to upstream (e.g. in case of new upstream releases, etc.). Upstream puts just patches for in-tree compiliation in his tarball, we need them separately, for out-of-tree compiliation. Otherwise, we wouldn't even need a orig.tar.gz anymore. (?) Actually true, but imho there shouldn't be any native packages in Debian at all. As usual, the modified tarball is tagged +debian to indicate, that it was rebuild. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Le lun 06 mar 2006 14:15:54 CET, Daniel Baumann [EMAIL PROTECTED] a écrit : There is no kernel-patch because we want to build it out-of-tree, not in-tree. Ok, it's a nice goal anyway. Anyway, everybody doesn't use latest kernel version (nor 2.6 kernel), if you want to replace the current package, it should give support for 2.4 and older 2.6 kernels ! I beg to differ: * the modules which are autobuilt are for 2.6 only, etch will likely not ship any 2.4 kernel, so 2.4 autobuilt support would be useless anyway. mmm. But Etch isn't to be released soon ;-) * if you still want to built modules for 2.4, you can semi-autobuild them by using module-assistant (therefore, it has the squashfs-source package). What I don't understand well is : did you modify the squashfs sources to be able to build the module out of tree, or is it the 2.6.15 kernel which let you do it ? And do you think the same source (out of tree) could compile with a 2.4 kernel ? Thanks for your advices, Fred.
Bug#355554: squashfs: Building modules to out-of-tree
Frédéric BOITEUX wrote: * the modules which are autobuilt are for 2.6 only, etch will likely not ship any 2.4 kernel, so 2.4 autobuilt support would be useless anyway. mmm. But Etch isn't to be released soon ;-) So you are seriously suggesting to hack a crapped 2.4 support in it although that in about 4-5 month, the base system is freezed for etch? Hm, I don't think this is worthy when we have m-a to semi-autobuild the modules in a sane way anyway. * if you still want to built modules for 2.4, you can semi-autobuild them by using module-assistant (therefore, it has the squashfs-source package). What I don't understand well is : did you modify the squashfs sources to be able to build the module out of tree, or is it the 2.6.15 kernel which let you do it ? That has nothing to do with 2.6.15, the problem is that upstream provides just patches, so I had to unpack them, fix the include definitions (debian/patches/01-includes.dpatch) and set a variable (debian/patches/02-defaults.dpatch). And do you think the same source (out of tree) could compile with a 2.4 kernel ? yep (if one add a 2.4 specific patch containing the diff between 2.4 and 2.6). -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Le lun 06 mar 2006 14:51:13 CET, Daniel Baumann [EMAIL PROTECTED] a écrit : So you are seriously suggesting to hack a crapped 2.4 support in it although that in about 4-5 month, the base system is freezed for etch? Hm, I don't think this is worthy when we have m-a to semi-autobuild the modules in a sane way anyway. No, if your module source could be used with 2.4 ! In fact, I prefer (also) to build it out of tree ! ... That has nothing to do with 2.6.15, the problem is that upstream provides just patches, so I had to unpack them, fix the include definitions (debian/patches/01-includes.dpatch) and set a variable (debian/patches/02-defaults.dpatch). I thought it was more difficult ... And do you think the same source (out of tree) could compile with a 2.4 kernel ? yep (if one add a 2.4 specific patch containing the diff between 2.4 and 2.6). It could be nice... I'll try to have look in this direction... with regards, Fred.
Bug#355554: squashfs: Building modules to out-of-tree
Hi Daniel, Daniel Baumann wrote: one can't just apply a patch between the current one and my one, to be able to build it out-of-tree, you have to repackage it (like I did). Why would this be necessary? I would prefer to keep the orig.tar.gz identical to upstream (e.g. in case of new upstream releases, etc.). Upstream puts just patches for in-tree compiliation in his tarball, we need them separately, for out-of-tree compiliation. What you are doing is taking upstream's code and adjusting it to out-of-tree compilation. Since you are shipping patches (dpatch ...) anyway, it still seems to be possible to prevent repackaging (which should be tried as far as possible). Otherwise, we wouldn't even need a orig.tar.gz anymore. (?) Actually true, but imho there shouldn't be any native packages in Debian at all. This differs from common practice and standards within Debian. Feel free to discuss it on [EMAIL PROTECTED] ;-) bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Roland Stigge wrote: Upstream puts just patches for in-tree compiliation in his tarball, we need them separately, for out-of-tree compiliation. What you are doing is taking upstream's code and adjusting it to out-of-tree compilation. Since you are shipping patches (dpatch ...) anyway, it still seems to be possible to prevent repackaging (which should be tried as far as possible). No. Atm you have to repackage it, or how do you want to 'unpack' the patch when some files (kconfig) coulnd't be patched in a way, that it is still non-interactive for autobuild? But I agree with you, that it should be discussed with upstream for the longer term, but that is your task as you have to connection to them. Until this is done, an modified tarball is the only solution. Otherwise, we wouldn't even need a orig.tar.gz anymore. (?) Actually true, but imho there shouldn't be any native packages in Debian at all. This differs from common practice and standards within Debian. Feel free to discuss it on [EMAIL PROTECTED] ;-) Sorry, no. Native packages are for packages that are specifically developed for debian. If we just need to rebuild a tarball, common use is to add +dfsg for the version when we need to rebuild it due to license issues. For other reasons, mostly a +debian tag is used. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Hi, Debian Live[0] is the initiative to create the official live system for Debian. It is based on squashfs (and unionfs). As we will (and have to) use the normal linux-images from the Debian archive, we need to build the squashfs-module out-of-tree. Your release-tarball contains only the patches against specific kernel-versions, but we need the files in 'plain format'. In the first attempt[1] to build the debian package for that, I had to rebuild your release-tarball. We want to avoid that if possible, so.. what is your opinion/plan? Regards, Daniel [0] http://live.debian.net/ [1] http://ftp-master.debian-unofficial.org/live-archive/squashfs/ -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Hi, Daniel Baumann wrote: What you are doing is taking upstream's code and adjusting it to out-of-tree compilation. Since you are shipping patches (dpatch ...) anyway, it still seems to be possible to prevent repackaging (which should be tried as far as possible). No. Atm you have to repackage it, or how do you want to 'unpack' the patch when some files (kconfig) coulnd't be patched in a way, that it is still non-interactive for autobuild? Provide a kind of kernel source stub, apply the upstream patch and our new package specific patches/changes. Yes, ugly. Thanks for already contacting upstream. :-) Actually true, but imho there shouldn't be any native packages in Debian at all. This differs from common practice and standards within Debian. Feel free to discuss it on [EMAIL PROTECTED] ;-) Sorry, no. Native packages are for packages that are specifically developed for debian. If we just need to rebuild a tarball, common use is to add +dfsg for the version when we need to rebuild it due to license issues. For other reasons, mostly a +debian tag is used. We recently had a similar discussion on debian-devel. There are even packages which don't have an orig.tar.gz or diff.gz but nevertheless a Debian revision (which I didn't like, but needed to accept). It's common for cases where upstream is that inactive that the respective Debian developer took over development himself and the diff.gz would be much bigger than the orig.tar.gz, making the latter somehow useless. We need to accept native packages that were not specifically developed for Debian. Thanks for considering, bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355554: squashfs: Building modules to out-of-tree
Roland Stigge wrote: Provide a kind of kernel source stub, apply the upstream patch and our new package specific patches/changes. Yes, ugly. Thanks for already contacting upstream. :-) That is uglier than repackaging the orig.tar.gz. We need to accept native packages that were not specifically developed for Debian. Yes, but actually the question was the other way round.. does it *have* to be native if the upstream tarball was rebuild. I say, as before, no. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
