Hi there! I would prefer kernel-related questions posted to the smartphones-kernel mailing list: I did so with this mail, but I have not set any Reply-To or Mail-Followup-To, so people can disagree with my judgement :-)
On Mon, 26 Jan 2009 21:26:42 +0100, Joachim Breitner wrote: > Am Montag, den 26.01.2009, 20:30 +0300 schrieb Nikita V. Youshchenko: >> Is't it the time to switch Debian to 2.6.28-based andy-tracking >> kernel? It should give better power management at least. I would disagree: we should stick with the 'stable' branch, or whatever branch the official FSO stable kernels are built from. It is funny because two days before your mail I locally pulled the Openmoko 'stable' branch into my local one! >> I see existing kernel package is not a proper debian package built >> from debian source, it looks like a dpkg-deb -b hack instead. I will not discuss what does "a propoer Debian package" means, but IIRC the kernel package is more lintian-clean than other packages in the official Debian archive... I agree that the build process is not the best one, but frankly speaking I will not invest more time until the pkg-fso and kernel teams have reach a consensus (read below for more details). FYI I started investigating about building the kernel package through make-kpkg (surely a saner way than the actual build), but then stopped for the very same reason above. >> It's unclear who and when will be able to integrate freerunner >> support into debian linux-2.6 package. This is bug #503292: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503292 AFAIK no one from the kernel team has shown interest on this subject. And FYI the debian-arm mailing list was unresponsive as well: http://lists.debian.org/debian-arm/2008/10/msg00111.html http://thread.gmane.org/gmane.linux.debian.devel.kernel/42431/focus=6671 I will be at FOSDEM next week-end, so I can try to discuss about it with Neil Williams (the Emdebian guy) and Martin Michlmayr (the guy behind most of the Debian work to support NAS devices). It would also be interesting to have Riku Voipio's advice, IIRC he was the guy who pushed for armel. Basically, as soon as the Openmoko patches will be integrated upstream (at least at a point where the Linux kernel can boot without any external and/or Openmoko-specific patch), we should clearly stop building our own kernel and better collaborate with the Debian kernel team. What is still unclear is how the Debian kernel package for the Openmoko should behave WRT the U-Boot image (I have not touched Qi yet). a) the cleanest solution would be to generate the U-Boot image at installation time, which helps having a kernel binary package which does not differ from a stock "desktop" one (i.e. not for embedded devices). This however requires that every FR would have installed uboot-mkimage: not a big deal (it occupies only 57.3kB). b) OTOH, the (probably) more clever solution suggests to create the kernel binary package like it is ATM: it ships a U-Boot image instead of the plain Linux one. The major drawback of this solution would be for Samsung S3C-based devices requiring plain Linux kernels (i.e. not U-Boot images): however, I do not know it they ever exist. While this option seems apparently the best choice, it requires more work at the package building level, something I do not really like: just imagine if the linux-2.6 package should contain specific rules for various embedded devices... >> So for now, maybe just create a package for andy-tracking kernel in >> the same way as current package has been made? > > although I haven’t touched it, I’m pretty sure the Debian package is > built properly. AFAIK, gismo took the regular linux-2.6 package as a > base for his work. [...] > He is busy with other stuff these days, it seems, so if you want you > can give it a shot. Joachim, you are right, but I am slowly catching up with Openmoko stuff because of the talk I will give at FOSDEM: http://www.fosdem.org/2009/schedule/events/debian_openmoko Going back to Nikita's question about andy-tracking kernel: we can provide both (stable and andy-tracking), but then we grow diversity, thus debugging problems will be more difficult. It is already a pain trying to cope with all different software we have (and you know how much the manpower is), adding another level (this time the more important one) to it is IMHO overkill. Thx, bye, Gismo / Luca
pgptVVY2M2jVS.pgp
Description: PGP signature
_______________________________________________ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
