<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 15, 2013 at 7:41 PM, Jack O'Quin <span dir="ltr"><<a href="mailto:jack.oquin@gmail.com" target="_blank">jack.oquin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Apr 15, 2013 at 8:40 PM, Tully Foote <<a href="mailto:tfoote@osrfoundation.org">tfoote@osrfoundation.org</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Apr 15, 2013 at 2:43 PM, Jack O'Quin <<a href="mailto:jack.oquin@gmail.com">jack.oquin@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Apr 15, 2013 at 3:59 PM, Tully Foote <<a href="mailto:tfoote@osrfoundation.org">tfoote@osrfoundation.org</a>><br>
>> wrote:<br>
>> > Hi Jack,<br>
>> ><br>
>> > It looks like you fixed the issue in:<br>
>> ><br>
>> > <a href="https://github.com/ros-drivers/camera1394/commit/8568997546fa76e207d04798cb09e0e213609891" target="_blank">https://github.com/ros-drivers/camera1394/commit/8568997546fa76e207d04798cb09e0e213609891</a><br>
>> > However the job you linked us to was still building 1.9.0 not 1.9.1. If<br>
>> > you<br>
>> > update the version I'd expect it to work. You should just have to<br>
>> > submit a<br>
>> > pull request to ros/rosdistro for the new verslon.<br>
>><br>
>> Thanks, that's encouraging. I really hope that fix will work. When it<br>
>> appeared to fail, I was running out of ideas. But, I had missed one of<br>
>> the steps in the release process without realizing it.<br>
>><br>
>> I hope camera1394-1.9.1 does fix that problem. I've been unable to<br>
>> reproduce the failure any other way, and there was very little<br>
>> debugging information in the console output. Assuming the incorrect<br>
>> reference to roslib is indeed the bug, I can understand why it works<br>
>> on my development system because roslib is already installed there.<br>
<br>
</div>The new version is building correctly now on everything but Raring,<br>
where there seems to be some generic problem with the python tools:<br>
<br>
The following packages have unmet dependencies:<br>
python-rosdistro : Depends: python-vcstools which is a virtual package.<br>
Depends: python3-setuptools but it is not<br>
going to be installed. or<br>
python-setuptools but it is not going<br>
to be installed.<br>
Unable to resolve dependencies! Giving up...<br></blockquote><div><br></div><div style>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. </div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>> But, isn't this the sort of error pre-release tests are intended to<br>
>> find? Why did that also succeed? Is roslib getting installed there by<br>
>> mistake or as a side-effect of some other package? How much does the<br>
>> pre-release build differ from the binarydeb build?<br>
><br>
> The prerelease does a lot more than the debbuilds. It is doing the same as<br>
> a devel job does, building and testing from source. And afterwords it<br>
> builds and tests from source all packages which depend on the requested<br>
> package. There's another test we could run which would actually test the<br>
> debbuild process, but the debbuild process does not install the tests so you<br>
> cannot run the tests after installing the debs which is not as helpful.<br>
<br>
</div>Getting the dependencies exactly right in catkin is *difficult*. In<br>
order not to release things that break the build (like I did), we need<br>
an easy-to-run test to make sure the package builds and runs on a<br>
system with only the packages it explicitly depends upon (directly or<br>
indirectly). That is hard to do on a development system.<br>
<br>
I had naively expected the pre-release test to do that for me. When it<br>
worked, I thought that meant I was finally ready to do the release.<br>
<br>
Perhaps your following suggestion can be developed into a solution for<br>
this problem...<br></blockquote><div><br></div><div style>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> It's relatively simple to test the debian build process. Checkout the<br>
> branch specific to your current platform in the gbp. Make sure you have<br>
> installed all the dependencies listed in the debian/control file. And call<br>
> dpkg-buildpackage with -uc -us (to skip signing). The deb files and<br>
> .changes will pop out in the directory above.<br>
<br>
</div>I tried this (see below). But, I don't see how running it would prove<br>
that the list of dependencies is complete. I already have<br>
ros-hydro-roslib installed on my development machine, so how is it<br>
going to detect that missing dependency?<br></blockquote><div><br></div><div style>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. </div>
<div style><br></div><div style>Tully</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> git checkout debian/ros-hydro-camera1394_1.9.1-0_precise<br>
> dpkg-buildpackage -us -uc<br>
<br>
</div>[...]<br>
dh_clean: warning: ignored unknown options in DH_OPTIONS<br>
rm -f debian/ros-hydro-camera1394.substvars<br>
rm -f debian/ros-hydro-camera1394.*.debhelper<br>
rm -rf debian/ros-hydro-camera1394/<br>
rm -f debian/*.debhelper.log<br>
rm -f debian/files<br>
find . \( \( -type f -a \<br>
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \<br>
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \<br>
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \<br>
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \<br>
\) -exec rm -f {} \; \) -o \<br>
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} \; \) \)<br>
rm -f *-stamp<br>
dpkg-source -b camera1394-release<br>
dpkg-source: error: can't build with source format '3.0 (quilt)': no<br>
upstream tarball found at<br>
../ros-hydro-camera1394_1.9.1.orig.tar.{bz2,gz,lzma,xz}<br>
dpkg-buildpackage: error: dpkg-source -b camera1394-release gave error<br>
exit status 255<br>
<br>
<br>
--<br>
joq<br>
</blockquote></div><br></div></div>