On Mon, 2008-07-21 at 12:58 +0200, Loïc Minier wrote: > > > > It is a bootstrapping problem - to build packages, you need the > > dependencies. Ubuntu does not have any ARM packages and the packages > > that we need to use are the ones with the most changes between Debian > > and Ubuntu. The patches that we use are Debian-specific. > > I certainly hear you concerning missing binaries; this is likely to > change soonish with armel: I suppose Emdebian will move to armel > soonish (as arm will probably be dropped in favor of armel post lenny), ARM will be dropped in the same way as m68k (AFAICT) such that ARM packages will not suddenly disappear from the mirrors the moment Lenny is released. As long as ARM keeps up for the fraction of packages that I need, Emdebian can continue to support ARM. Armel will happen in due course. > and Ubuntu will soon start an armel port as well (based on Debian's). > However I don't quite get the "patches" part. Ubuntu basically > "rebases" on a new Debian snapshot every six months; this just happened > for Ubuntu "intrepid" suite, so anything which happened on the Debian > side should also be present in the Ubuntu side. Emdebian only cares about a fraction of the packages in the Debian archive - principally because Emdebian cannot hope to support certain kinds of packages like maths libraries or OOo that no sane person would expect to run on an embedded device. The packages that do matter to Emdebian are the main ones used by debootstrap (with a few omissions like perl and coreutils) and are also the main ones that Ubuntu would change as part of the Ubuntu installer and Ubuntu-isation (if that is a word) of the OS itself. The patches in Emdebian SVN are specific to the current version in Debian and whenever Ubuntu also makes changes to those packages, those patches would fail. I'm not a git-phile so I have no concept of rebasing stuff (I'm a complete git-phobe if I'm honest). I just know that many of the packages that I build have Ubuntu-specific changes described in their PTS entries. Any Ubuntu-specific change would cause the Emdebian patches to fail. The solution to that is to get the patches supported in Debian but this requires fixes to existing bugs in Debian (e.g. in debhelper and CDBS as described in earlier messages) to support things like "nodocs" in DEB_BUILD_OPTIONS to be able to produce packages compliant with Emdebian Policy. http://wiki.debian.org/EmdebianPolicy > Allow me to come back to your blog post now if you don't mind: > 1) you're saying Launchpad is another web-login to carry; I'm happy to > report that Launchpad is moving to openid [already commented in this > thread] Hmmm, ok. A step in the right direction, true. > 2) you're explaining that nobody cared about a bug filed against > emdebian-tools in Ubuntu in a long time; that's certainly sad, the same > could be said about many Debian bugs too, and many other Ubuntu bugs; > because Debian packages are automatically imported into Ubuntu, this > might happen; I personally think it's more beneficial for people > intereted in random Debian packages which have been auto-imported to > continue this way; this might be problematic for e.g. security > sensitive packages, but I don't see why it would be for emdebian Until recently, I had no way of knowing about the Ubuntu bug - as the blog post describes, once I was aware, I was (at that time) unable to do anything about it. That individual issue was subsequently resolved via a comment on that blog post. Equally, I am upstream for various projects that have packages in Debian - I am happy to use the BTS for upstream issues with those packages but I know of many upstreams who would not consider scanning the BTS and expect Debian to forward bugs to them. This is perfectly understandable and absolutely not a problem in Debian. Maybe Ubuntu should do more to communicate with Debian about Debian-native packages? Debian is the upstream of emdebian-tools, Debian is where I listen out for problems and issues with my native Debian packages. I am no more likely to go rummaging in Ubuntu than other upstream teams would be to go scanning the BTS. > 3) "emdebian-tools is not intended for Ubuntu but I don't have a way of > encoding that in the package"; I think it's hard to tell from your side > what derivatives would /not/ be interested in; I believe there are very > little packages which are truly distro specific: perhaps keyrings or > meta packages, and I'm not even sure. True (note that emdebian-tools does include a keyring package). There probably are very few packages in this kind of situation - typically native Debian packages that have a high dependency on Debian infrastructure. Identifying such packages is not trivial. > Consider debootstrapping Debian > from Ubuntu or vice versa, pbuilding in the same combinations, or > creating virtual machines. The same could apply to emdebian tools; of > course there's no official Ubuntu arm port, but did you know that Nokia > built many of the last Ubuntu releases for arm with almost zero > modifications? Ubuntu is also preparing an armel port. So I'm not > sure it's easy to tell whether emdebian is suitable for Ubuntu or not. Not sure if those builds were done natively or as cross-builds. Cross-building support is the issue here, in particular obtaining the cross-architecture dependencies as pre-built, compatible, binary packages. > Certainly using the criteria of native versionning of a package is not > a good criteria to decide. True, but there are areas where native Debian packages may need more support from Ubuntu: 1. Forwarding Ubuntu bugs to the BTS - treating Debian as the upstream. 2. Removing those few packages that are both native Debian and highly Debian dependent. This is a manual step. > > emdebian-tools is tightly integrated into Debian (and Debian unstable in > > particular) and is, naturally, a Debian native package (it was written > > to support Embedded Debian after all, not UbuntuMobile). > > I don't think bringing Ubuntu Mobile in there is related at all. Ubuntu > Mobile itself (nowadays also known as Ubuntu MID) is currently quite > unrelated to Emdebian; some reasons for this: > 1) Ubuntu Mobile targets lpia and only lpia for now; this is like x86 > 2) the UI is hildon and moblin based and images are built with moblin > tools and patches but moblin packages aren't in Debian at all > 3) arm isn't a target nor is cross-building; packages are built > natively > 4) special patches are applied on lpia and lpia only, hence any other > architecture wouldn't work without some porting; yes, that's ugly > :-( Quite - UbuntuMobile and Emdebian are clean different things. emdebian-tools supports Emdebian, it cannot hope to have any role in UbuntuMobile. > So, yes, Ubuntu Mobile wouldn't make a good use of Emdebian tools > because it's unrelated; however there might be interest for these tools > from an Ubuntu environment. To do so, the binaries must exist to prepare using apt-cross/dpkg-cross. Currently, that is not the case and I don't think that is going to change before ibex is released. (If it does, by the sound of it this would only happen for armel and the Emdebian patches would still fail to apply.) > i) all the packages you mention (patched packages and tools) are being > imported and updated in Ubuntu regularly but are not available in Ubuntu as ARM binaries. > ii) you might want to build Debian based images from an Ubuntu env debootstrap can do that. > iii) an Ubuntu arm port might as well exist outside of the Ubuntu > official mirrors, just like the Nokia one, or might come to life > later on And mips, mipsel, uClibc-arm, and the rest? emdebian-tools is not a one-architecture support package, it can support any architecture that Debian can support. Making Ubuntu support the same range is more than a little pointless. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part