[Bitpim-devel] Gentoo ebuild

[Sourav K. Mandal]

Hello,

FYI, I have created an ebuild for Gentoo; forum post:

http://forums.gentoo.org/viewtopic.php?p=1318855#1318855

It builds/installs from CVS source, not frozen code. A DSV ebuild is
included as well.

Any feedback would be appreciated.

I just received my LG VX6000 and data cables are on the way, so I
haven't even tested it myself, but there's at least one success story in
the forum thread.


Best,

Sourav

[Roger Binns]

Post by Sourav K. Mandal
http://forums.gentoo.org/viewtopic.php?p=1318855#1318855
It builds/installs from CVS source, not frozen code. A DSV ebuild is
included as well.
Any feedback would be appreciated.

As I run gentoo myself, I had tried to a do an ebuild as well, but
you got way further than I did. (And at the time - a few months ago -
wxPython 2.4.2.4 wasn't even listed in the ebuilds. Note that BitPim
won't actually work with wxPython earlier than 2.4.2.4 so you may
want to make the version more explicit).

Some comments in no particular order:

- It is really cool that you did this since it should also work for
people on non-x86 versions of Linux.

- I have no issue with installing from CVS. There won't be source tarballs
of BitPim unless someone provides code for automating the process of
uploading files to SourceForge, and filling out all the stupid forms they
have.

- There is a versioning issue, in that head of CVS gets you exactly that.
There is a 0.7 release every two weeks, so I don't know how that is handled
in Gentoo. I do tag each build (eg most recent tag is BITPIM_0_7_14) but
don't know if you want to create an ebuild for every single version every
two weeks.

- Please change the homepage to www.bitpim.org

- CVS_RSH should not be present. When you use pserver, rsh is not used so
the presence of the variable in the script will be confusing.

- qt is NOT used. wxPython uses gtk. I don't believe you need to mention
gtk in this ebuild since it is implicit in the use of wxPython.

- I have the same complaints as you for the docpr stuff in ebuilds :-)

- I now see why you mention Qt - for qtopiadesktop. BitPim just reads the
files directly which are in XML format, and so no part of the qt libraries
are used. Note that people are most likely to install qtopiadesktop
from tarballs or other things, so it is quite possible to have ~qt
yet be running qtopiadesktop. I would recommend always copying the
qtopiadesktop module since it doesn't bring in any other dependencies.

- You should junk the docs bit since they are not relevant. I will also
be rearranging some of that shortly.

- My preference is for BitPim to be installed below /usr/lib/bitpim-version
rather than in the site-packages directory. Stuff in site-packages
generally is done via distutils and is more of a "package" rather than
an application like BitPim.

- You will also need to make an ebuild for paramiko as I will be removing
the private copy in the bitpim source soon. It is distutils based and
should be a simple search and replace on the dsv ebuild :-)

- I would like the version.py file to be modified so that we can tell this
is a head of CVS gentoo version rather than an official build. I think
the version number should displayed by BitPim should look something like
0.7.14-gentoo-CVS-date

This will require some modifications of that file which I will do.

- I am happy for the ebuild script to live in BitPim cvs if that would
be of any use.

- I deliberately don't do support on all sorts of web forums, so people
who want their support questions answered need to use the bitpim-user
mailing list.

Roger

[Sourav K. Mandal]

First --

New ebuild stack is attached:

dev-python/dsv-1.4.0
dev-python/paramiko-0.9h
app-misc/bitpim-0.7.14

An urgent bug with this stack:

The code in bitfling wants to do an aliased import from paramiko_bp
which obviously no longer exists; I had to resort to an ugly hack to
smooth things over. This should be fixed upstream at your earliest
convenience.


Onto comments ---

[...] Note that BitPim
won't actually work with wxPython earlier than 2.4.2.4 so you may
want to make the version more explicit).

Done

- It is really cool that you did this since it should also work for
people on non-x86 versions of Linux.

It should; there might be some USB weirdness, and maybe the crypt libs
aren't validated for platforms other than x86.

- I have no issue with installing from CVS. There won't be source tarballs
of BitPim unless someone provides code for automating the process of
uploading files to SourceForge, and filling out all the stupid forms they
have.

*Shrug* The Gentoo folks care more about stability (performance and
maintainability) than these details.

- There is a versioning issue, in that head of CVS gets you exactly that.
There is a 0.7 release every two weeks, so I don't know how that is handled
in Gentoo. I do tag each build (eg most recent tag is BITPIM_0_7_14) but
don't know if you want to create an ebuild for every single version every
two weeks.

This could be a problem with the Gentoo devs. I am checking out tags
corresponding to releases, but if there's a release every two weeks they
won't want to deal with it, and they'll question the apps stability.

Perhaps it would be wise to hold off on submitting the ebuilds for
integration into Portage until you get to a slower release cycle.

- Please change the homepage to www.bitpim.org
- CVS_RSH should not be present. When you use pserver, rsh is not used so
the presence of the variable in the script will be confusing.

Done

- I have the same complaints as you for the docpr stuff in ebuilds :-)

Yeah, I don't know what's up with that

- I now see why you mention Qt - for qtopiadesktop. BitPim just reads the
files directly which are in XML format, and so no part of the qt libraries
are used. Note that people are most likely to install qtopiadesktop
from tarballs or other things, so it is quite possible to have ~qt
yet be running qtopiadesktop. I would recommend always copying the
qtopiadesktop module since it doesn't bring in any other dependencies.

qtopiadesktop is static, so you're right

- You should junk the docs bit since they are not relevant. I will also
be rearranging some of that shortly.

Done

- My preference is for BitPim to be installed below /usr/lib/bitpim-version
rather than in the site-packages directory. Stuff in site-packages
generally is done via distutils and is more of a "package" rather than
an application like BitPim.

Done

- You will also need to make an ebuild for paramiko as I will be removing
the private copy in the bitpim source soon. It is distutils based and
should be a simple search and replace on the dsv ebuild :-)

Done; the authors obnoxious patch names cause Portage to barf (I think
for good reason) -- I just give it explicitly in the ebuild.

- I would like the version.py file to be modified so that we can tell this
is a head of CVS gentoo version rather than an official build. I think
the version number should displayed by BitPim should look something like
0.7.14-gentoo-CVS-date
This will require some modifications of that file which I will do.

Yeah, the few manipulations I tried caused big runtime breakage, so
leaving as is.

- I am happy for the ebuild script to live in BitPim cvs if that would
be of any use.

Yes (see above).

- I deliberately don't do support on all sorts of web forums, so people
who want their support questions answered need to use the bitpim-user
mailing list.

A message to this effect is displayed at the end.


Best,

Sourav

[Roger Binns]

Post by Sourav K. Mandal
The code in bitfling wants to do an aliased import from paramiko_bp
which obviously no longer exists; I had to resort to an ugly hack to
smooth things over. This should be fixed upstream at your earliest
convenience.

I have just fixed that in the last 30 seconds :-)

Post by Sourav K. Mandal
It should; there might be some USB weirdness, and maybe the crypt libs
aren't validated for platforms other than x86.

The crypt libs work on Windows, Linux and Mac (PPC), and they do a self test
on import so I am confident that they will be fine. Even then BitFling
is a rarely used feature.

Post by Sourav K. Mandal

Post by Roger Binns
- There is a versioning issue, in that head of CVS gets you exactly that.
There is a 0.7 release every two weeks, so I don't know how that is handled
in Gentoo. I do tag each build (eg most recent tag is BITPIM_0_7_14) but
don't know if you want to create an ebuild for every single version every
two weeks.

This could be a problem with the Gentoo devs. I am checking out tags
corresponding to releases, but if there's a release every two weeks they
won't want to deal with it, and they'll question the apps stability.
Perhaps it would be wise to hold off on submitting the ebuilds for
integration into Portage until you get to a slower release cycle.

That won't happen for a really long time. BitPim is kept stable
*because* of the frequent release cycle.

Post by Sourav K. Mandal

Post by Roger Binns
- You will also need to make an ebuild for paramiko as I will be removing
the private copy in the bitpim source soon. It is distutils based and
should be a simple search and replace on the dsv ebuild :-)

Done; the authors obnoxious patch names cause Portage to barf (I think
for good reason) -- I just give it explicitly in the ebuild.

He is a really nice guy when I have dealt with him. Just a slight
pokemon obsession :-)

Post by Sourav K. Mandal

Post by Roger Binns
0.7.14-gentoo-CVS-date

Yeah, the few manipulations I tried caused big runtime breakage, so
leaving as is.

I'll be making the mods in the next few days so you can easily do that.

Post by Sourav K. Mandal

Post by Roger Binns
- I am happy for the ebuild script to live in BitPim cvs if that would
be of any use.

Yes (see above).

Do you know if the ebuild command can accept a URL instead of a filename?

Ideally what I want to tell gentoo people to do is:

ebuild http://www.bitpim.org/bitpim.ebuild merge

I assume you will be able to get the paramiko and python-dsv ebuilds
submitted to portage.

Roger

[Sourav K. Mandal]

Post by Roger Binns

Post by Sourav K. Mandal
Perhaps it would be wise to hold off on submitting the ebuilds for
integration into Portage until you get to a slower release cycle.

That won't happen for a really long time. BitPim is kept stable
*because* of the frequent release cycle.

I understand -- "early, often" works for young software.

Post by Roger Binns
Do you know if the ebuild command can accept a URL instead of a filename?
ebuild http://www.bitpim.org/bitpim.ebuild merge

Alas, it is not that simple. Two options, first the easy one then the
hard one:

* Users can do a CVS checkout of module "ebuilds" or something into
their overlay dir, retrieving ebuilds, Manifest files, digest files,
etc. (basically like tar.gz distributions of ebuilds, but more elegant)

* You can set up a full blown rsync server, and do it like breakmygentoo
with gensync:

http://breakmygentoo.net/archives/000130.html

Post by Roger Binns
I assume you will be able to get the paramiko and python-dsv ebuilds
submitted to portage.

Sure, but since they're not "hot" they'll be low priorities for the
devs.

The plan?

* Let me know when you fix the version.py in CVS, and I'll update the
ebuild

* At that point I'll submit the DSV and paramiko ebuilds to Gentoo
bugzilla and then we'll observe ...


Sourav

[Roger Binns]

Post by Sourav K. Mandal

Post by Roger Binns
Do you know if the ebuild command can accept a URL instead of a filename?
ebuild http://www.bitpim.org/bitpim.ebuild merge

Alas, it is not that simple. Two options, first the easy one then the
* Users can do a CVS checkout of module "ebuilds" or something into
their overlay dir, retrieving ebuilds, Manifest files, digest files,
etc. (basically like tar.gz distributions of ebuilds, but more elegant)

On a Linux user would call that easier/elegant :-)

I will settle for nothing more than two commands to type in, preferably
only one. See if you can figure out a way of doing it.

Post by Sourav K. Mandal
* You can set up a full blown rsync server, and do it like breakmygentoo
http://breakmygentoo.net/archives/000130.html

That is even funnier!

Post by Sourav K. Mandal
* Let me know when you fix the version.py in CVS, and I'll update the
ebuild

I have now done that. There is a line like this in version.py:

vendor="official"

Change it to something like

vendor="gentoo-CVS-BITPIM_0_7_14"

And then do the freezing.

It shows up in the splash screen as well as the About dialog.

Post by Sourav K. Mandal
* At that point I'll submit the DSV and paramiko ebuilds to Gentoo
bugzilla and then we'll observe ...

Go for it.

The ebuild you supplied is now in the BitPim CVS in the unixpkg
directory. (The filename doesn't include the version number).

It can be placed somewhere as part of the build process and
have the version number included in the filename at that
point.

What I desperately need is some way of automating the
whole release process. It is really annoying uploading
everything and filling out endless forms on the site.

I have only found one program so far that claims to
do the automation. http://sfutils.sourceforge.net/
However I fell out of my chair laughing on seeing the dependencies:
http://sfutils.sourceforge.net/dependencies.html
(I have done a significant amount of Java development,
and that is just so "Java".)

Roger

[Sourav K. Mandal]

Post by Roger Binns
I will settle for nothing more than two commands to type in, preferably
only one. See if you can figure out a way of doing it.

*Shrug* Gentoo users are pretty self-sufficient, so just making the
ebuilds available (none of accoutrement) in a prominent way should be
fine. Maybe put the following README in the dir (or note on the
website):

"Rename the ebuild to bitpim-<version>.ebuild, and install it in your
overlay"

Post by Roger Binns
vendor="official"

I don't see it in HEAD ...

Post by Roger Binns
The ebuild you supplied is now in the BitPim CVS in the unixpkg
directory. (The filename doesn't include the version number).
It can be placed somewhere as part of the build process and
have the version number included in the filename at that
point.

That wouldn't buy anything for the users; might be helpful to
maintainers (like you) who are creating various distribution packages.

[Roger Binns]

Post by Sourav K. Mandal

Post by Roger Binns
I will settle for nothing more than two commands to type in, preferably
only one. See if you can figure out a way of doing it.

*Shrug* Gentoo users are pretty self-sufficient, so just making the
ebuilds available (none of accoutrement) in a prominent way should be
fine. Maybe put the following README in the dir (or note on the
"Rename the ebuild to bitpim-<version>.ebuild, and install it in your
overlay"

Is that two steps or less :-?

Post by Sourav K. Mandal

Post by Roger Binns
vendor="official"

I don't see it in HEAD ...

Anonymous CVS takes up to 5 hours to update from the authenticated
one.

Post by Sourav K. Mandal

Post by Roger Binns
The ebuild you supplied is now in the BitPim CVS in the unixpkg
directory. (The filename doesn't include the version number).
It can be placed somewhere as part of the build process and
have the version number included in the filename at that
point.

That wouldn't buy anything for the users; might be helpful to
maintainers (like you) who are creating various distribution packages.

I was figuring it would be useful if you could ebuild a URL.

Roger

[Sourav K. Mandal]

Post by Roger Binns

Post by Sourav K. Mandal
"Rename the ebuild to bitpim-<version>.ebuild, and install it in your
overlay"

Is that two steps or less :-?

Roughly -- it's harder than "rpm <whatever>" but on par with the binary
install.

Post by Roger Binns

Post by Sourav K. Mandal
I don't see it in HEAD ...

Anonymous CVS takes up to 5 hours to update from the authenticated
one.

You're right; sorry.

Post by Roger Binns
I was figuring it would be useful if you could ebuild a URL.

Perhaps it would, but that flies in the face of the philosophy of
Portage: to ensure the integrity of the body of software by validating
all interdependencies, all such considerations should be made by the
Portage maintainers and not the individual package developers. So you
are free to throw in your own stuff locally, but it requires an override
(overlay).

I believe this is comparable to BSD ports, or Debian's attempts at the
binary level.