On Mon, 23 Jul 2007 11:58:50 -0700 "Chuan-kai Lin" <cklin@google.com> wrote: > On 7/21/07, Neil Williams <linux@codehelp.co.uk> wrote: > > 1. Copyright Google ? With no declaration that this is actually under > > the same licence as the package itself, a bare Copyright line is > > unacceptable - it implies All Rights Reserved. > > This is "work for hire", so what I wrote belongs to Google, and I need > to put the copyright line there for non-trivial changes. However, I > have management approval to contribute the changes back to emdebian, > so releasing the code under a free license is not a problem. All > Rights Reserved is definitely not what we want, but I was at a loss on > how to license the script because I did not see a license statement in > the file either. Perhaps use the same style as translators : # Copyright (C) 2007 Miguel Figueiredo <elmig@debianpt.org> # This file is distributed under the same license as the pilot-qof package. # Miguel Figueiredo <elmig@debianpt.org>, 2007. I'm not sure if that third line is necessary so if changes do require a Copyright statement where one has not existed before, a simple declaration should be sufficient. (It is particularly important if emdebian changes are to be eventually migrated into the Debian package.) The package referred to should be the Debian package - emdebian should not try to change licensing details. Therefore, the changes could be under any licence that meets the DFSG and the choice of that licence is entirely at the behest of the upstream developers. However, please consider that the changes required to cross-build a Debian package are not particularly large - I haven't sought to declare copyright on any done so far - and changes to these changes are even smaller. In future, Emdebian seeks to make these changes smaller still until all relevant packages in Debian can be cross-built without any changes whatsoever. In the context of the whole package and in the context of all packages that have been emdebianised so far, is it *really* a "significant" amount of code being changed? I'm not sure that "touching" so many packages with "Copyright Google" for such a small amount of code (per package) is such a good idea. If Emdebian has claimed no copyright on our changes, I wonder about the need for any explicit copyright statement. IMHO the details in emdebian-changelog.patch are sufficient - I remain unconvinced that changes to debian/rules should include any "Copyright" lines at all. Don't forget, the Emdebian or Debian changes and the Copyright notices that may or may not be attached are neither included in any Emdebian binaries nor installed on any Emdebian machine. > > 2. What is this patch against? The emdebian patch files? If so, what is > > this line all about: > > -include /usr/share/cdbs/1/rules/debhelper.mk > > em_make replaces that line with the Emdebian debhelper makefile but > > that file is still necessary. > > This patch is against svn head, so you are reading a patch of a patch. > The line you are concerned about is a context line (starts with > space), not a patch line (starts with + or -). Oops. My fault - I did indeed misread that. > What is the preferred > format of communicating changes to emdebian packaging? Untested right now. ;-) You are the first to work with these packages outside Emdebian. Reading a patch of a patch is quite difficult so it may be better to provide an interdiff -z after the build. This compares the .diff.gz from the emdebian build with the .diff.gz from your build and should result in a simpler format. If you are planning on doing lots of these builds, it may be wise to use an SVN repository of your own although that may well involve copying the patch files into a separate working copy because emdebian-tools is currently hardcoded for the emdebian SVN. I would think that at least a page on the Debian wiki under the category Emdebian would be advisable. Feel free to add a link to it from the Emdebian FAQ. > > 3. The changes to debian/rules don't use the debhelper routines nor the > > normal CDBS methods. We need to avoid manual 'cp' rules at all costs - > > these cause problems for us in other packages, there is no reason to > > use them ourselves. > > I can easily remove the single $(CURDIR)/debian/tmp/bin copy and use > debhelper instead. I learn mostly from existing emdebian packages -- > the loop to move the translations into the locale is adapted from > debian/rules in the emdebian aptitude package. If that is not the > preferred emdebian-way, I can easily stop doing that too. The translations should be handled by emlocale and updates to apt-cross and emdebian-tools since your patch was posted should make this easier. CDBS packages do not require the translation loop detailed in the Wiki and used in other packages - CDBS likes extra files in debian/ and emlocale creates these for you. Indeed, this is why your original patch looked wrong to me - the symptoms you noticed were more likely to be due to a missing grep.install file which will allow CDBS to do all the work for us. The reason this is important is that the more we stick with how CDBS expects to work, the easier it will be to apply our patches to the next release of the package concerned (and the easier it should be to migrate at least some of our changes to Debian). This means that packaging for Emdebian frequently requires in-depth knowledge of all existing methods of building Debian packages, including dbs, cdbs, debhelper and raw dpkg commands. Unless there is an overriding reason, no Emdebian changes should use commands from methods that are "foreign" to the Debian package and wherever possible, Emdebian changes should use the highest level implementation available so as to improve the chances of compatibility with future releases. > > Thanks for spotting the problems with the grep package - I'll sort it > > out at this end. Got a few other things to sort out first to do with > > fixes in apt-cross stopping emlocale from working properly. > > It looks like you already have the grep package taken care of. I have > been working my way through other packages; sometimes just refreshing > emdebian patches against newer debian packages, and occasionally > fixing problems here and there as well. Is it a useful thing for me > to post more patches here? YES! :-) This is exactly the kind of work I have wanted to do recently but I've been held up by bugs in the tools and infrastructure scripts. I would love to know how the upgrades have gone - perhaps some stats on a DebianWiki page or some indication of how many upgrades broke, how many manual changes and fixes were needed etc. Emdebian needs an autobuilder for the packages (as well as the toolchain) so if you can provide any insight into how this could work, it would be very much appreciated. > If people think contributions like this are useful, this is a good > time to establish a protocol on contributing changes. A few points here: 1. Updating emdebian packages against new Debian releases should be as automatic as possible. Changes should be only required rarely. dpkg filtering and other methods (like separate translation .deb files) will assist in this area in the future, as will other changes within Debian itself. 2. Emdebian infrastructure is changing rapidly - sometimes packages simply need to be rebuilt with the latest versions of emdebian-tools etc. Some of the very early packages may still not include all the changes necessary to actually build the package in the archive due to bugs in the early scripts. There is still a lot more work needing to be done on the Emdebian infrastructure. 3. Previously, all such contributions have been handled by simply allowing SVN commit access but the idea was to divide the current access into SVN-only and Emdebian-developer access. Unfortunately, this has not yet been implemented. Wookey (project lead) is currently on vacation and he normally organises access to the Emdebian machines. 4. I am currently trying to sort out powerpc toolchains and this involves including .deb package files from a remote server into the Emdebian toolchain repository and the same methods could be used to update Emdebian packages from a location on one of your machines. In effect, we could start the process of updating emdebian packages and get some information on just how to run an autobuilder for cross-built packages for Emdebian. The simplest way to do this is to make the .changes files (with all listed files) available in a directory that can be either rsync'd to or read directly from the Emdebian server. (i.e. the same files that would need to exist to use dput, only in this case it would be more like a dpull until access is sorted out.) 5. Documentation for all of this is simply non-existent. :-( Wiki pages and home-grown documentation on a website of your own would be welcome (GPL2|3 or later please and preferably DocBook). 6. Real data on how many emdebianised packages can actually be upgraded automatically would be very useful. The latest emdebian-tools (0.3.0) includes outline support for cleaning an existing directory and I've been thinking that this could form the basis of an update mechanism that is triggered when apt-get source locates a new Debian version. Automation of these updates would be very welcome. I will be making a 0.3.1 release of emdebian-tools to the Emdebian repository in the next few days - with emdebian-tools installed, this will be available under a normal 'sudo apt-get upgrade'. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpVOFANAZ2uo.pgp
Description: PGP signature