[Ros-release] Troubles releasing a wet package to Hydro

[Tully Foote]

On Mon, Apr 15, 2013 at 7:41 PM, Jack O'Quin <jack.oquin at gmail.com> wrote:

> On Mon, Apr 15, 2013 at 8:40 PM, Tully Foote <tfoote at osrfoundation.org>
> wrote:
> >
> >
> >
> > On Mon, Apr 15, 2013 at 2:43 PM, Jack O'Quin <jack.oquin at gmail.com>
> wrote:
> >>
> >> On Mon, Apr 15, 2013 at 3:59 PM, Tully Foote <tfoote at osrfoundation.org>
> >> wrote:
> >> > Hi Jack,
> >> >
> >> > It looks like you fixed the issue in:
> >> >
> >> >
> https://github.com/ros-drivers/camera1394/commit/8568997546fa76e207d04798cb09e0e213609891
> >> > However the job you linked us to was still building 1.9.0 not 1.9.1.
>  If
> >> > you
> >> > update the version I'd expect it to work.  You should just have to
> >> > submit a
> >> > pull request to ros/rosdistro for the new verslon.
> >>
> >> Thanks, that's encouraging. I really hope that fix will work. When it
> >> appeared to fail, I was running out of ideas. But, I had missed one of
> >> the steps in the release process without realizing it.
> >>
> >> I hope camera1394-1.9.1 does fix that problem. I've been unable to
> >> reproduce the failure any other way, and there was very little
> >> debugging information in the console output. Assuming the incorrect
> >> reference to roslib is indeed the bug, I can understand why it works
> >> on my development system because roslib is already installed there.
>
> The new version is building correctly now on everything but Raring,
> where there seems to be some generic problem with the python tools:
>
>     The following packages have unmet dependencies:
>      python-rosdistro : Depends: python-vcstools which is a virtual
> package.
>                         Depends: python3-setuptools but it is not
> going to be installed. or
>                                  python-setuptools but it is not going
> to be installed.
>     Unable to resolve dependencies!  Giving up...
>

Sorry vcstools had not been propogated into raring. It's fixed now.  With
those dependency issues "virtual package" is apt's way of saying does not
exist.  Which is not really straight forward.


>
> >> But, isn't this the sort of error pre-release tests are intended to
> >> find? Why did that also succeed? Is roslib getting installed there by
> >> mistake or as a side-effect of some other package? How much does the
> >> pre-release build differ from the binarydeb build?
> >
> > The prerelease does a lot more than the debbuilds.  It is doing the same
> as
> > a devel job does, building and testing from source.  And afterwords it
> > builds and tests from source all packages which depend on the requested
> > package.  There's another test we could run which would actually test the
> > debbuild process, but the debbuild process does not install the tests so
> you
> > cannot run the tests after installing the debs which is not as helpful.
>
> Getting the dependencies exactly right in catkin is *difficult*. In
> order not to release things that break the build (like I did), we need
> an easy-to-run test to make sure the package builds and runs on a
> system with only the packages it explicitly depends upon (directly or
> indirectly). That is hard to do on a development system.
>
> I had naively expected the pre-release test to do that for me. When it
> worked, I thought that meant I was finally ready to do the release.
>
> Perhaps your following suggestion can be developed into a solution for
> this problem...
>

So we talked about this a little bit and there's actually two tests we
should be running.  First is the prerelease which will do like we do now
and test from source against itself and reverse dependencies for
regressions.  The second is a predistribution test which will basically
verify that the debbuild process will succeed. It will check these minimum
requirements etc.  This one in particular is hard because unless you are
only doing the debbuild you will always have the core tools like roslib in
your environment.  We'll try to develop these tests separately as they
complete two different roles.


>
> > It's relatively simple to test the debian build process.  Checkout the
> > branch specific to your current platform in the gbp.  Make sure you have
> > installed all the dependencies listed in the debian/control file.  And
> call
> > dpkg-buildpackage with -uc -us (to skip signing).  The deb files and
> > .changes will pop out in the directory above.
>
> I tried this (see below). But, I don't see how running it would prove
> that the list of dependencies is complete. I already have
> ros-hydro-roslib installed on my development machine, so how is it
> going to detect that missing dependency?
>

Yes this usually won't detect undeclared dependencies unless you run it in
a chroot. You can have this build the source deb and then invoke pbuilder,
it's only a couple lines but then we're getting into basically the debbuild
script so this can be wrapped up into the predistribution test above. Maybe
even have bloom offer to run them for you.

Tully


>
> > git checkout debian/ros-hydro-camera1394_1.9.1-0_precise
> > dpkg-buildpackage -us -uc
>
> [...]
> dh_clean: warning: ignored unknown options in DH_OPTIONS
> rm -f debian/ros-hydro-camera1394.substvars
> rm -f debian/ros-hydro-camera1394.*.debhelper
> rm -rf debian/ros-hydro-camera1394/
> rm -f debian/*.debhelper.log
> rm -f debian/files
> find .  \( \( -type f -a \
>        \( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
> -o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
> -o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
> -o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
> \) -exec rm -f {} \; \) -o \
> \( -type d -a -name autom4te.cache -prune -exec rm -rf {} \; \) \)
> rm -f *-stamp
>  dpkg-source -b camera1394-release
> dpkg-source: error: can't build with source format '3.0 (quilt)': no
> upstream tarball found at
> ../ros-hydro-camera1394_1.9.1.orig.tar.{bz2,gz,lzma,xz}
> dpkg-buildpackage: error: dpkg-source -b camera1394-release gave error
> exit status 255
>
>
> --
>  joq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20130415/a1b7264a/attachment-0009.html>