[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Good communication with upstream is good idea

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

>  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. 


>  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

>  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

>  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

>  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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: