@Emmet: good points, perhaps I can sched some light on some of them. Indeed, using a non-native package when upstream ships a debian/ is a tad dangerous (for example it will silently ignore removals of upstream files below debian/). Historically, the packages started as native because it was easiest for the many UME modules to start as native as the packages were e.g. stored in bzr/git and autoreconfed. Nowadays, for promotion to main and because we try to follow good practices we're moving to non-native packages when possible, but when doing this we should actually repack tarballs without a debian/ (as is customary when upstream ships a debian/).
UME has two major upstream sites: maemo.org mostly for the Hildon stack done by Nokia and moblin.org for misc modules developped and maintained by Intel (some of these are forked from upstream projects such as Firefox). MIC comes from moblin.org and is developped mostly by Intel folks to create images of UME (and others). John is the upstream maintainer for MIC. Moblin uses Debian packages internally and whenever they push a new debian/changelog entry into their git repo, a build happens. Moblin doesn't have a "tarball release" concept and uses native packages with an upstream versionning scheme (0.39, 0.40 etc.). Basically we (Intel and UME folks) would like to have a single source tree for MIC in general, and not have to handle a debian/ for Moblin and another one for Ubuntu. One way to achieve this is to have UME folks have commit access upstream (which is what I assumed was the case when I did my first MIC uploads) and push new upstream "releases" into Moblin at the same time as Ubuntu; sadly, I was wrong, and this resulted in me pushing a release of MIC into Ubuntu with an upstream version number and upstream not pulling my changes and later on releasing the same upstream version number with different contents to Moblin -- big mess. The other way to share the source tree is to help Intel work directly in Ubuntu and/or push their new upstreams directly; which is what we're trying to do lately. So I'm not quite sure what to recommend at the moment, but wouldn't we have a special relationship with Intel folks, I'd handle this as a remote upstream project as follows: - grap native tarball with debian/ from Moblin's APT repo - repack without debian/ and perhaps keep the debian/changelog as debian/changelog.moblin - add our Ubuntu debian/, perhaps managed under bzr, git or whatever If we do this, handling of the Maintainer field is quite natural, and apart of the MOTU versus UME Maintainer: question, it's clear we should set Maintainer to a team and XSBC-OriginalMaintainer to John. Since packages are being promoted to main, I'll ask on our UME list whether we'd like to set Maintainer to UME or to Ubuntu Core Dev / MOTU. Concerning the drop of changelog entries, I think we will have to live with them for this upload, mostly my fault I guess, by making sure we rebase our changes atop of the new upstream release and document them in the changelog. @Steve: if you're still working on MIC, the list of things to do is: - repack upstream tarball without debian/; usually we change the version number in the process to reflect this, if it was 1.2.3 you can use e.g. 1.2.3.repack as upstream version, so it gives 1.2.3.repack-0ubuntu1 - set Maintainer to some team: either MOTU or UME - make sure we don't miss any Ubuntu specific change which we care about in the new source package (I'm sorry, I didn't check your actual packages, you might have done this already) -- Update moblin-image-creator to 0.39 https://bugs.launchpad.net/bugs/188130 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
