Packaging and PPA

[Anders Wallin]

I've set up a launchpad account for a PPA. I'm trying this for
opencamlib (https://github.com/aewallin/opencamlib)

However I'm having trouble building the files that launchpad wants.
The instructions tell me to create the files with "debuild -S -sa" but
that gives a number of error messages.

Does anyone have time to look at this and make it work?

If possible, I think it would be nicer to use cmake's CPack for this
too, instead of manually having to update the files in /debian.
With cmake, "make package" seems to produce a valid .deb package, but
that is not what launchpad accepts...

There's no /debian folder at all for openvoronoi or truetype-tracer,
so those are fresh projects to package if anyone wants to try.

Anders

[andyw]

If possible, I think it would be nicer to use cmake's CPack for this
too, instead of manually having to update the files in /debian.

I am now trying to make some progress following this:

http://cmake.3232098.n2.nabble.com/Release-of-new-Debian-Source-Package-Generator-td6297099.html

 

[Mark]

Hi Anders,

Do you use 'cdbs'?
If not, install it and copy https://github.com/Heeks/heekscad/blob/master/debian/rules

I that is all you need for binary packages. I think it works for source packages as well.

As far as I know, cpack does not support source packages. I'm pretty sure 'debuild -S' creates a source package, so cpack won't do what you want by itself.

Regards
Mark

[Anders Wallin]

>
> I am now trying to make some progress following this:
> http://cmake.3232098.n2.nabble.com/Release-of-new-Debian-Source-Package-Generator-td6297099.html
>

After some editing this purely cmake based approach seems to give some results:
https://launchpad.net/~anders-e-e-wallin/+archive/opencamlib

I guess we need to wait for launchpad to (succesfully?) build the
package now. And then it could be tried on a fresh ubuntu-install
(VM).

AW

[Anders Wallin]

> After some editing this purely cmake based approach seems to give some results:
> https://launchpad.net/~anders-e-e-wallin/+archive/opencamlib
> I guess we need to wait for launchpad to (succesfully?) build the
> package now. And then it could be tried on a fresh ubuntu-install
> (VM).

Well, predictably the build failed.
It seems the cmake-hack produces the right debian source package for
uploading to launchpad ONCE.
But when I try "dput" again with some modifications the cmake-scripts
generates changes which include all of the original source, while
launchpad will only accept "deltas" compared to the original source.
I'm not going to spend more time on this unless there are clear and
simple instructions somewhere...

Also, someone on IRC tried building on Ubuntu 10.04LTS, which has gcc
4.4.3 and boost 1.40. If someone can reproduce this and post an issue
then perhaps it will get fixed. (I might try 10.04lts in a VM at some
point).

AW

[Sebastian Kuzminsky]

I'll try to add a debian directory and get it to build on Lucid
tonight. I'll send you a pull request when i have something working.

--
Sebastian Kuzminsky

[andyw]

On Wednesday, January 18, 2012 8:40:17 PM UTC+2, SebKuzminsky wrote:

I'll try to add a debian directory and get it to build on Lucid
tonight.  I'll send you a pull request when i have something working.

Hi Seb,

I really like the cmake-based approach where everything is generated from settings in the cmakelists.txt. I think I figured out a thing or two, and running "cmake ../src" now partly generates a debian source packange in the build-directory. There is then a custom target "make dput" to build the source-package and upload it to launchpad. There is also "make dputs" for testing, where the upload is only simulated.

If I bump the version number launchpad seems to accept my uploads. There are now two versions over here:

https://launchpad.net/~anders-e-e-wallin/+archive/opencamlib

Is that how it is supposed to work? Will the old package-versions be automatically deleted or should I do that?

This new upload will obviously suffer from the same build-problem as the last one. Is there a way of checking that a debian source-package will build with the specified build-dependencies? It seems inefficient to change the depencies, upload a new package, and wait 2-5 hours for launchpad to generate the build-error...

 

Anders

[Sebastian Kuzminsky]

The best way i know of to do build-testing of debian source packages
is to use pbuilder. It builds inside a throw-away chroot containing a
minimal install. This will verify that your build dependencies are
specified correctly.

--
Sebastian Kuzminsky

[Anders Wallin]

> The best way i know of to do build-testing of debian source packages
> is to use pbuilder.  It builds inside a throw-away chroot containing a
> minimal install.  This will verify that your build dependencies are
> specified correctly.

Thanks! This will be useful (although pbuilder is quite slow also).

I now see the build going to 100%, but get an error on install:
https://launchpadlibrarian.net/90430482/buildlog_ubuntu-oneiric-amd64.opencamlib_11.10.12-ubuntu1~oneiric1_FAILEDTOBUILD.txt.gz

"make install" does work fine on a normal Ubuntu install, but it seems
installing fails with pbuilder and on launchpad with:
-- Installing: /usr/lib/python2.7/dist-packages/ocl.so
CMake Error at cmake_install.cmake:44 (FILE):
file INSTALL cannot copy file
"/build/buildd/opencamlib-11.10.12/build_dir/ocl.so" to
"/usr/lib/python2.7/dist-packages/ocl.so".

The install-directory is found out in the cmake script with:
execute_process(
COMMAND python -c "from distutils.sysconfig import get_python_lib;
print get_python_lib()"
OUTPUT_VARIABLE Python_site_packages
OUTPUT_STRIP_TRAILING_WHITESPACE
)

How should this be modified to work both on a normal install (it does
now), and with pbuilder/launchpad? suggestions?

AW

[Sebastian Kuzminsky]

On 01/19/2012 06:03 AM, Anders Wallin wrote:
> "make install" does work fine on a normal Ubuntu install, but it seems
> installing fails with pbuilder and on launchpad with:
> -- Installing: /usr/lib/python2.7/dist-packages/ocl.so
> CMake Error at cmake_install.cmake:44 (FILE):
> file INSTALL cannot copy file
> "/build/buildd/opencamlib-11.10.12/build_dir/ocl.so" to
> "/usr/lib/python2.7/dist-packages/ocl.so".
>
> The install-directory is found out in the cmake script with:
> execute_process(
> COMMAND python -c "from distutils.sysconfig import get_python_lib;
> print get_python_lib()"
> OUTPUT_VARIABLE Python_site_packages
> OUTPUT_STRIP_TRAILING_WHITESPACE
> )
>
> How should this be modified to work both on a normal install (it does
> now), and with pbuilder/launchpad? suggestions?

When you install ocl.so, do you use "install -D"? If not, you probably
have to create the destination directory first (with mkdir).

--
Sebastian Kuzminsky

[andyw]

The error (below) now looks the same both on launchpad and on my local machine.

cmake generates a file "cmake_install.cmake" that is run during the install with (pbuilder):

cd build_dir; cmake -DCOMPONENT=Unspecified -DCMAKE_INSTALL_PREFIX=../debian/tmp/usr -P cmake_install.cmake

the failing line in cmake_install.cmake is then:

FILE(INSTALL DESTINATION "/usr/lib/python2.7/dist-packages" TYPE MODULE FILES "/tmp/buildd/opencamlib-11.10.13/build_dir/ocl.so")

it seems that this line has "hard-coded" paths and doesn't take into account the CMAKE_INSTALL_PREFIX at all.

Not sure where to go from here. Maybe I should post to the cmake list?

Anders

[Anders Wallin]

Finally, I am able to build opencamlib both with pbuilder and on
launchpad. I'll try installing from launchpad later.

With openvoronoi pbuilder runs into trouble:

The following packages have unmet dependencies:
pbuilder-satisfydepends-dummy: Depends: libboost-graph which is a
virtual package.
Depends: libqd0 which is a virtual package.
Depends: libqd-dev which is a virtual package.
Depends: libboost-python-dev but it
is not going to be installed.
Unable to resolve dependencies! Giving up...

Looking in synaptic, "libqd0" and "libqd-dev" are the actual names of
the packages I have installed.
They are from section " Libraries (universe)"

Do I have to enable universe somehow in debian/control or rules ?

Anders

[Sebastian Kuzminsky]

Yes, universe is not enabled by default in pbuilder. You need
"--components 'main universe'" when you create it. You can update the
existing chroot tarball, but i dont remember the command-line for that
off the top of my head.

--
Sebastian Kuzminsky

[andyw]

Yes, universe is not enabled by default in pbuilder.  You need
"--components 'main universe'" when you create it.  You can update the
existing chroot tarball, but i dont remember the command-line for that
off the top of my head.

Thanks! I now got it to build with pbuilder, and it appears launchpad's builders already have 'universe'.

The openvoronoi ppa is now at:

https://launchpad.net/~anders-e-e-wallin/+archive/openvoronoi

And opencamlib at:

https://launchpad.net/~anders-e-e-wallin/+archive/opencamlib

These are for Oneiric. I don't think I will make a very big effort to produce packages for other Ubuntu releases - but I would gladly accept patches that make it work (e.g. for Lucid) and do not break the build or tests.

In principle DebSourcePPA.cmake (the scripts that makes the source-package) should be able to generate source-packages for many releases, but that is somehow broken right now.

You will notice that the install location has changed from

/usr/lib/python2.7/dist-packages

to

/usr/local/lib/python2.7/dist-packages

That was to make the pbuilder/launchpad-builder happy. On my machines it does not seem to make a difference.

Opencamlib now builds only a python-module, while OpenVoroni builds and installs both the python module and a pure c++ shared library.

Both packages do not install any demo/tutorial scripts or documentation, just shared libraries (and c++ headers). 

I haven't tried installing from the PPA yet, but I'll try it in a fresh install in a VM at some point (maybe the pbuilder environment can be used for testing also?)

I might make a PPA for my port of truetype-tracer also. Since I understood there was interest in V-carving from many. Obviously for existing EMC2/LinuxCNC installs on Lucid the build-problems would need to be resolved...

Anders

[Sebastian Kuzminsky]

I'll take a look at getting these to build and run on Lucid.

I'm super excited to get these packages usable by the LinuxCNC
community, thanks for all your work Anders. :-)

--
Sebastian Kuzminsky

[andyw]

I decided all the packages can live in one PPA.

I've now made the script-magic produce source-packages for a number of releases. This page should show successful and failed builds:

https://launchpad.net/~anders-e-e-wallin/+archive/cam/+packages

at least -Werror must be turned off with the older compilers. In opencamlib there's an attempt at detecting the gcc-version, and setting warnings/errors based on that.

Anders

[andyw]

It appears that Lucid/launchpad does not have the package "git".

If I add this PPA: ppa:git-core/ppa  as a dependency to my PPA, it seems I can get truetypetracer to build under Lucid.

BUT, does this have the undesirable effect of making my oneiric/natty/maverick packages also depend on ppa:git-core/ppa ?

The next problem seems to be libqd0. If I look here:

https://launchpad.net/ubuntu/+source/qd

it seems Lucid has "libqd-dev" (just like Oneiric), but the run-time dependency which is "libqd0" on oneiric is called "libqd2c2a" on older releases..

Anders

[Anders Wallin]

> The next problem seems to be libqd0. If I look here:
> https://launchpad.net/ubuntu/+source/qd
> it seems Lucid has "libqd-dev" (just like Oneiric), but the run-time
> dependency which is "libqd0" on oneiric is called "libqd2c2a" on older
> releases..

setting the dependency to "libqd0 | libqd2c2a" and turning off some
gcc errors/warnings for older versions of gcc now results in
successful builds!
https://launchpad.net/~anders-e-e-wallin/+archive/cam/+packages

I've put the py-scripts that are meant to be run from LinuxCNC/AXIS
over here: https://github.com/aewallin/linuxcnc-scripts

If someone with a 10.04/LinuxCNC install could test installing from
the PPA and running those py-scripts that would be great.

thanks,
Anders

[andyw]

https://launchpad.net/~anders-e-e-wallin/+archive/cam/+packages

OK, now everything seems to build, but I have problems with installing.

$ sudo add-apt-repository ppa:anders-e-e-wallin/cam

$ sudo apt-get update

$ sudo apt-get install truetypetracer

And I get (similar for ocl and ovd):

Reading package lists... Done

Building dependency tree       

Reading state information... Done

Some packages could not be installed. This may mean that you have

requested an impossible situation or if you are using the unstable

distribution that some required packages have not yet been created

or been moved out of Incoming.

The following information may help to resolve the situation:

The following packages have unmet dependencies:

 truetypetracer : Depends: libboost-python (>= 1.40) but it is not installable

E: Unable to correct problems, you have held broken packages.

for ovd/ocl I didn't specify a version number for libboost-python, but the error message is similar.

AW

[Anders Wallin]

On Sun, Jan 22, 2012 at 9:06 PM, andyw <anders.e...@gmail.com> wrote:
>>
>> https://launchpad.net/~anders-e-e-wallin/+archive/cam/+packages

Here's the current state of things (on oneiric). I don't understand
why dpkg -l does not find a package "libboost-python"
Is the exact version number required in the debian/control file? How
is that doable when there are 4-5 different releases to build packages
for and each one has their own libboost-python version?

$ sudo apt-get install truetypetracer openvoronoi opencamlib

Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:

opencamlib : Depends: libboost-python but it is not installable
openvoronoi : Depends: libboost-python but it is not installable

truetypetracer : Depends: libboost-python (>= 1.40) but it is not installable
E: Unable to correct problems, you have held broken packages.

anders@anders-i7:~$ dpkg -i libboost-python*
dpkg: error: requested operation requires superuser privilege

$ dpkg -l libboost-python*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Description
+++-==================================-==================================-====================================================================================
ii libboost-python-dev 1.46.1.1
Boost.Python Library development files (default version)
un libboost-python1.42-dev <none>
(no description available)
ii libboost-python1.46-dev 1.46.1-5ubuntu2
Boost.Python Library development files
ii libboost-python1.46.1 1.46.1-5ubuntu2
Boost.Python Library

dpkg -l libboost-python
No packages found matching libboost-python.

[Sebastian Kuzminsky]

I think the done thing is to have the source package build-depend on
libboost-python-dev (which is a version-independent virtual package),
and then use "Depends: ${python:Depends}" to make the binary package
depend on whatever python packages it ended up using and "Depends:
${shlibs:Depends}" for regular shared libraries.

I don't know how to convince cmake to do that, though... In general
I'm a bit leery of non-Debian tools writing Debian metadata files...

--
Sebastian Kuzminsky