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

Re: Target emdebian packaging update in branches



On Thu, 26 Jul 2007 14:05:57 -0700
"Chuan-kai Lin" <cklin@google.com> wrote:

> I have committed changes in branches that brings nano, shadow, tzdata,
> and wget up-to-date against sid.  The changes are at
> 
> n/nano/branches/refresh_2.0.6-2

Only a minor point - the build log is nano_2.0.6-1em1_arm.build - that
should be nano_2.0.6-2em1_arm.build to match the changelog patch.
(Don't just rename the file here, please check that the build
log is being created correctly). 

Removing the links file contents is correct. Thanks.

> s/shadow/branches/refresh_4.0.18.1-1

Same problem with the build log.

> t/tzdata/branches/refresh_2007f-9

hmm, the build log problem is becoming a theme

> w/wget/branches/refresh_1.10.2-3

same.

Please let me know if this is a bug or whether this is some aberration
at your end. I'm sure this area of emdebian-tools does contain bugs -
if you have any patches for those feel free to post them either to the
BTS for emdebian-tools or here or as a branch. I suspect a bug in
emdebian-changelog not being applied correctly or emdebuild not picking
up the updated patch. Seeing as the old changelog patch should not be
applied (because it will break), once the updated changelog patch is in
trunk/, the tools should be able to use that patch. Please check the
version strings of the built packages.

> Neil, can you please review and comment?  There are still quite a few
> more to go; please advise whether future changes can go into trunk
> directly, or you want them in branches for others to review and merge.

These are all fine - clean updates with one useful additional change,
plus a clean update where the new Debian version changed debian/rules
(to add O2) and we have retained that change. 

The updated patches can be transferred to trunk/, however, the problem
with the build log makes me suspect that the packages are being built
with the wrong version and this would lead to the .changes file being
rejected by the repository. If this is true, it would be a bug in
emdebian-tools and it needs to be fixed before the updated packages can
be uploaded. One workaround is to copy your updated patches to trunk/
and commit the changes, then use emsource -c <PACKAGE> to clean the
build directory. This will unpack the debian source again and commit
the updated patches. It may be that this is simply a missing step in
emsource - the updated Debian source needs to have a fresh emdebian
version entry created in debian/changelog to update
emdebian-changelog.patch. I'll take a look at this issue over the
weekend, hopefully. I was expecting to make an emdebian-tools update
anyway.

Updates to emdebian-tools and apt-cross are made via the Emdebian
toolchain repository and announced here (usually). Each update
increments the release number so Debian v0.3.0 becomes v0.3.1 in
Emdebian. A series of such changes are then collated into the next
Debian release by incrementing the minor version number so 0.3.x
becomes 0.4.0 in sid. apt takes care of all this because the Emdebian
toolchain repository is part of your sources list after installing
emdebian-tools - the normal apt-get update, apt-get upgrade cycle will
ensure everyone always has the latest tools. It keeps Emdebian
developers closer to the SVN whilst preventing needless churn in the
Debian mirrors.

Before you do any mass updates, just me know - especially if the update
requires more changes than these four packages. Clean, simple, rebuilds
like these are fine - providing that the build log issue is corrected. 

If you get time to document your experiences, feel free to update the
current Emdebian Wiki pages. In particular, it would be good to have a
page detailing the update process and what steps had to be done
manually. This will help improve emdebian-tools to support autobuilding
cleanly, where possible.

I need to refactor the update mechanisms in emdebian-tools to use the
apt-cache more intelligently. Emdebian should be able to arrange an
automated rebuild rather than tripping over an updated apt-get source
during an otherwise standard build.

Ideas and patches welcome . . . 

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpXBcA5mCLj_.pgp
Description: PGP signature


Reply to: