On 7/24/07, Neil Williams <[EMAIL PROTECTED]> wrote:
"Chuan-kai Lin" <[EMAIL PROTECTED]> wrote: I am unsure whether emdebian-changelog.patch would actually contain enough useful data to make it worth inserting old entries - we have SVN to record the history of the patch file itself.
I agree that keeping old entries is not all that important. I think of Emdebian not as maintaining our own line of package development and maintenance, but as constantly producing embedded-variants of Debian packages. With this perspective 1.2-1em1 (for example) does not really grow out of 1.1-3em1, and having the 1.1-3em1 entry in the 1.2-1em1 changelog provides little useful information. What we do need is to tell 1.2-1em1 from 1.2-1em2... but without a new Debian version, emdebian-changelog.patch should apply cleanly.
> 22 have newer versions in sid, and some Emdebian patches fail to apply, > 12 do not have Emdebian patches in svn, OK, can you give package names for those 34 please?
Stale packages: adduser apt aptitude bzip2 cdebconf devmapper dhcp3 dialog diffutils dpkg e2fsprogs file gcc-4.2 glibc gzip libselinux libsepol module-init-tools nano shadow tzdata wget Packages not emdebianized: console-tools cyrus-sasl2 db4.2 db4.3 debconf debian-archive-keyring gdbm gnutls13 libcap libgcrypt11 libgpg-error libice lzma newt opencdk8 openldap2 openssl slang slang2 sysklogd ucf vim I miscounted yesterday -- there are 22 packages without Emdebian patches in svn, and only 34 packages (instead of 44) are current against sid.
If you get them to build, patches would be appreciated or if you can send your SSH key and preferred username to Wookey before he leaves, you could commit the revised patches yourself, as a branch.
I have sent an access request to Wookey, and I am planning to work through these packages in the coming weeks.
(I don't mean to yell). With lots of packages, using a branch in Emdebian SVN is quite useful because it makes it easier for me to test the revisions.
Hey, I was half joking. No offense taken. Are there existing branch naming conventions?
> 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. Please let me know what changes are required in emdebian-tools to achieve these native builds because it is something that Emdebian would like to be able to do.
So far I have done well with simply replacing the dpkg-cross version of dpkg-buildpackage and dpkg-shlibdeps with the ones from dpkg-dev. I replaced dpkg-shlibdeps because the dpkg-cross version checks for cross-building libraries in $crosslib with "dpkg --search" which is hard to fool (even symlinks would not work). I replaced dpkg-buildpackage because aptitude fails to build with the dpkg-cross version for some mysterious reason I have yet to uncover (pkg-config fails to find sigc++-2.0). Other than that, dh_make complains about missing or old cross toolchain, but it still seem to work (I have not looked at its output closely yet).
Some form of delta handling could be used for debian/control and debian/rules too. This is completely untested but I think that because we have the old Debian source backed up, we have the new Debian source unpacked and we have the current Emdebian patches, we should be able to calculate a patch that takes us from the old source through the new source to the final Emdebian version. e.g. if the Build-Depends line of foo_0-1 was changed in foo_0-1em1 and then foo_0-2 arrives with other changes to Build-Depends, it should be possible to isolate the changes from 0-1 to 0-2 (easy), diff against the changes for 0-1em1 and come up with a patch that goes from 0-2 to 0-2em1 ?
I have seen lots of discussions on these topics among the CMS crowd (e.g., developers of subversion, mercurial, monotone, darcs, ...), and I think the general consensus is that what you proposed is possible only if the delta-merge program knows about the syntax and semantics of the changes between merged. Line based diff and patch will not get us very far in this direction. -- Chuan-kai Lin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
