Roger Binns
2006-04-24 04:55:30 UTC
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 :-)ebuild, available in http://bugs.gentoo.org/show_bug.cgi?id=127966 .
Corrections and improvements are more than welcomed.
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 datepolicies. You promised that, if a Gentoo dev make this transition, you
will fix the problem.
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