multi-touch-dev team mailing list archive

[OXullo Intersecans <x@xxxxxxxxxxxxxxx>]

Dear Chase,
thanks to your suggestions, I'm getting on track!

On 05/feb/2011, at 00.17, Chase Douglas wrote:

>> Is there a practical way to leave the upstream codebase on libavg.de svn server (so we can keep the current workflow) and use launchpad just for packaging purposes?
> 
> Sure. In fact, there are many ways to go about this:
> 
> 1. Continue what you are doing with the source code, and push package
> branches to launchpad
> 2. As Mark mentioned, you can import your code into launchpad+bzr now
> and play around. This doesn't affect your svn repo at all. LP will just
> pull updates to synchronize with your svn repo every day or so. If you
> find that you like bzr, you can switch to it. Instructions available at
> https://help.launchpad.net/Code/Imports.

I evaluated the full span of options, including Mark's suggestion (@Mark: thanks to you too).
What stopped me to proceed with the automatic import was the initial lack of knowledge on the 'product' topic ( https://wiki.ubuntu.com/BzrMaintainerHowto ). Coming from the centralized school, it takes a while to digest everything!

At the end I focused into preparing a packaging repository that svn-pulls the upstream via get-orig-source rule, then the really handy bzr-builddeb plugin that does the magic of preparing the orig tar and build the package. No upstream sources on the repos, just the debian dir.
This also because I'm using the ~svn version tag: we're actively working on all the related projects right now and it's quite mandatory for us to have a super quick way to generate packages out of a svn commit.

Getting back into the product/project part, I chose to follow your implicit suggestion to push to utouch: it makes now definitely sense to me (please correct me) to have all these packages under the hood of the ubuntu multitouch stack project ( https://code.launchpad.net/~oxullo ).

>>> * I see you added a man page to your packaging, probably at the prodding
>>> of lintian :). I suggest moving the man page into your source tree
>>> itself and then installing the man page from there instead. That way
>>> other distros have access to the man page too.
>> 
>> Indeed it was only a choice dictated by lintian warnings. I suppose that, at least for the games, it would be more practical to get rid of the manpages.
> 
> Although I see your point, I don't see anything wrong with having a man
> page either. If you ever want to add cmd line options (say for
> debugging), a man page can be very useful.

I gathered your suggestion and I generated man pages for all games packages. Basically with name, description and two basic options.
Due to the fact that the underlying distribution system is the pythonic distutils, I felt like giving up on moving the man page to the upstream.

>> clear. I will follow this procedure for the other games as well, keeping in mind the changes you made.
>> May I apply this procedure to python-libavg (the library all the games depend on) as well?
> 
> Sure! Let me know if you need any help.

All the packages repos are pushed to my code branches, including libavg.
In addition I dput'd all of them to my ppa ( ppa:oxullo/libavg ).
In case you'd like to give them a try and the games don't start from the icon, it's possible that you need to set

LD_PRELOAD=/usr/lib/libstdc++.so.6

before starting them from the console. Runners: empcommand, mttroff, planarity, magictouch
They're already xinput2.1 aware (thanks to Uli) and multitouch works fine. They totally suck on a software renderer, though.

> Sorry for the confusion. You shouldn't have any debian packaging stuff
> in your upstream source code repo. So I'm referring only to your
> packaging branch here. When you upload to a ppa, you should append ~ppa#
> to the debian version, but this change shouldn't be committed anywhere.
> For example, if you check out our utouch-team ppa's you'll see all the
> packages are appended with ~utouch#. However, if you look at the code
> for all our packaging branches (like
> lp:~utouch-team/utouch-grail/packaging), you'll find that we never
> commit this version appendage to the branch.

Crystal clear.

> This is because the ~ppa# scheme is only useful for ppas as you test
> packages out before pushing to Ubuntu proper. The packaging branch
> should represent what is pushed to Ubuntu only (and/or Debian).

Uhm, what's about the UNRELEASED entries?

>>> When you are ready to push to the Ubuntu archive, create a release:
>>> 1. Run 'dch -r'
>>> 2. Run 'debcommit -r' (this will commit and tag the repository)
>> 
>> And then open bugs for new packages, upload to REVU?
> 
> This isn't my area of expertise, so I'll refer you to
> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. You'll want to go
> through the MOTU route, since Debian won't have the multitouch bits you
> need.


I'm presently making contact with the current python-libavg packager and hopefully I'll sort out at least the procedure for python-libavg update.
I'll seek for further info online.

Thanks!


--
OXullo Intersecans