On 7/23/07, Neil Williams <[EMAIL PROTECTED]> wrote:
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.
Point taken. I agree that this is more about giving credit where & when credit is due, and should not be about plastering copyright statements unnecessarily.
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.
Point taken. This should increase the fun factor somewhat :)
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.
I have selected 94 packages that I think a useful base system should contain, and here is the breakdown: 44 are current against sid, 15 have newer versions in sid, but Emdebian patches (other than against changelog) applies successfully, 22 have newer versions in sid, and some Emdebian patches fail to apply, 12 do not have Emdebian patches in svn, 1 is obsolete (linux-kernel-headers is replaced by linux-libc-dev). Note that some false-positives in the "current" set. For example, zlib1g counts as "current" only because all its svn Emdebian patches are empty, and the built packages still contain man pages and changelogs.
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.
Are there any ongoing projects toward achieving this goal?
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.
For the moment, I think me posting interdiffs here and you yelling at me when I do things wrong seems to work for me, and the messages in the list archives would serve as a guide for perspective developers.
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.)
I am not planning to make any built packages public because I am not building them through the standard procedure. I build Emdebian packages natively, and I currently find it more convenient to hack Emdebian tools to use the native toolchain instead of building and installing an i386 -> i386 cross toolchain.
6. Real data on how many emdebianised packages can actually be upgraded automatically would be very useful.
See above in the post. Unless there are tools I am not aware of, the Emdebian-patch-based approach requires human intervention when a new Debian version changes one of debian/rules, debian/control, and friends and makes a patch fail to apply. -- Chuan-kai Lin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
