Discussion:
[BitPim-devel] Re: bitpim gentoo ebuild (and Debian notes)
Roger Binns
2006-04-24 04:55:30 UTC
Permalink
We (as in gentoo community) managed to make a source based bitpim
ebuild, available in http://bugs.gentoo.org/show_bug.cgi?id=127966 .
Corrections and improvements are more than welcomed.
I am a Gentoo user myself :-)

It looks like you intend to distribute by making a tarball from
svn export and then loading that tarball as the source on
the gentoo servers. For many CVS based projects the code would
be directly checked out when the user did the emerge. Has
there been a change in policy?

In the maketarball stage (or whatever it is replaced with), you
need to edit src/version.py like this:

sed -i 's/^vendor=".*/vendor="Gentoo"/' src/version.py

That will make Gentoo show up as the vendor name and will prevent
BitPim from looking for updates.

It is also a good idea to run 'src/version.py freeze' which will
embed the Subversion revision into the file.

I've added the .desktop file into packaging/ - you'll need to
perform substitions on it.

I am planning on making another target for buildrelease/makedist.py
which will give a tree that has the installation layout - it should
be useful for Gentoo and Debian.
As you know, *.lbin files have executable stacks and this break our QA
policies. You promised that, if a Gentoo dev make this transition, you
will fix the problem.
I promised that if Gentoo commit to keeping the ebuild up to date
I'd fix it (having an ebuild that significantly lags BitPim releases
doesn't help anyone). I'll work on it after this next build. It
should also help Debian.

The plan is to look for the netpbm programs on the system if they
can't be found in the helpers directory. I still need to check
the command line flags haven't changed.

Instead of manually building USB and strings, you can run
packaging/buildmodules.py

I am leaning towards buildmodules building usb and strings
if no parameters are supplied (ie the default we need for the
project) and if parameters are supplied then those are built
(params would be one of more of usb, strings and bmp2avi).

You definitely shouldn't need to set $PYTHONPATH in the wrapper.
The directory the script is in is automatically the first item
in the python path (that is how the interpretter works).

This line is also not ok:

einfo "For support information please visit http://bitpim.org/"

We *only* support installations directly downloaded from bitpim.org.
This is especially pertinent in this case as you are using different
versions of most components than we are. I think Debian has a nice
scheme where they filter bug reports etc to first establish if the
issue is caused by their system and then report back upstream if
it is an upstream issue.

I am expecting usb to be one of the issues and every Linux distro
is different for that. If you supply the text, I'd be happy to
add a Gentoo specific page in the online help. It would end up
being http://www.bitpim.org/help/support-gentoo.htm

It would need to have Gentoo specific information, and then point
to http://bitpim.org/help/support.htm

The patch will go away as it won't be needed. (The patch currently
patches a whole bunch of files that are only used as part of the
rpm build process anyway!)

Roger
Aaron M. Ucko
2006-04-26 00:36:39 UTC
Permalink
Post by Roger Binns
It is also a good idea to run 'src/version.py freeze' which will
embed the Subversion revision into the file.
I did this when packaging 0.8.13 for Debian, though it seems to have
had no visible effect given that I checked out a release tag as
usual. (I'm holding off on uploading it, both so that more folks can
confirm it's suitable for release and so that 0.8.12 can migrate to
testing, though the latter should almost certainly happen tonight.)
Post by Roger Binns
I've added the .desktop file into packaging/ - you'll need to
perform substitions on it.
I'll be deploying this as well; thanks!
Post by Roger Binns
I promised that if Gentoo commit to keeping the ebuild up to date
I'd fix it (having an ebuild that significantly lags BitPim releases
doesn't help anyone). I'll work on it after this next build. It
should also help Debian.
I don't use any of your prebuilt executables, but
Post by Roger Binns
The plan is to look for the netpbm programs on the system if they
can't be found in the helpers directory. I still need to check
the command line flags haven't changed.
would somewhat simplify my packaging.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger ***@monk.mit.edu (NOT a valid e-mail address) for more info.
Roger Binns
2006-04-26 04:35:25 UTC
Permalink
Post by Aaron M. Ucko
Post by Roger Binns
It is also a good idea to run 'src/version.py freeze' which will
embed the Subversion revision into the file.
I did this when packaging 0.8.13 for Debian, though it seems to have
had no visible effect given that I checked out a release tag as
usual.
For release checkouts there won't be any visible difference but
the subversion release number will be in the source file should
it ever be needed.

Roger

Loading...