[BitPim-devel] bitpim binary modules breaks Gentoo QA policies

I was the original author of BitPim (now a team of several)
and wrote/maintain the build and packaging system, as well as
make the releases. I also happen to be a user of Gentoo for
several years.

BitPim itself is written in Python, but needs a variety of
binary packages. One example is the wxPython windowing
system. Another is APSW (used for SQLite) and an interface
to libusb.

Since I don't expect users to install Python, wxPython,
compile several extensions etc to run BitPim (why should
they care what language it is written in?) I provide binary
packages for download. Under the hood, these are a directory
structure containing the Python interpretter, the Python bytecode
in a zip file, assets (icons, splashscreens, online help etc)
and dlls for the binary extensions.

Since every version of every Linux distro has different versions
of different libraries and random other quirks, the Linux
binary package is made on Redhat 9. Pretty much everything
can run Redhat 9 binaries, sometimes needing compat glibc.
The SourceForge file release process is so tedious and annoying
that I won't build and upload on more Linux platforms (ie
VmWare won't help).

As for this textrel message, I really don't care. The package
does work and that is what I care about. On the main web page
you can see that I tell people using Gentoo to just use rpm.

The correct fix and the Gentoo philosophy is that this should
be run/built from "source". However there are several problems.
Firstly the Gentoo release procedures cannot keep up. There
is a new BitPim release every three weeks (it used to be every two).
Consequently things will be long obselete by the time ~x86 is
removed.

The second problem is that ebuilds have to be put in place for
a number of other packages that belong to other herds. Some
already exist but are really badly maintained. For example
the wxPython ebuild is still tied to 2.4 (the last version
of that was released in 2003) and the 2.6 ebuild doesn't
produce something that works.

Given these problems with portage, someone started making
ebuilds that just grab the rpm and untar it. Even then
they haven't keep up with the release schedule.

Unless someone at Gentoo is prepared to own the effort and
put proper time into this, then I am not going to do anything
differently.

If someone will do that, then they need to do the following.
I will give them full assistance, and also make some code
changes that will help. Doing this will also get you
BitPim working on all architectures (there are no CPU or
32/64 bit dependencies)

- Stay on top of the BitPim release schedule. I am prepared
to have a template ebuild in the source tree (in fact there
already is one) and run a command that makes a release one
and mails it to someone. If you aren't going to keep up
with the BitPim releases then having anything in portage
is unfair to the users (the current rpm process works fine)

- Create and push through ebuilds for several of the
extensions used, as well as keep them up to date. (They
don't change that often). Altenatively you can make
a build system that builds private uptodate copies
of the extensions and keeps them in the BitPim deployment
directory

- BitPim has automatic checks for updates. Behind the scenes
this is done by grabbing an xml file off the web server and
doing pattern matching. I am prepared to change the code
to make it so that the update functionality is hidden if
built on Gentoo, or that it grabs the xml file from a Gentoo
server, or that Gentoo specific xml information is kept on
the site with Gentoo built versions looking for that.

The above is all about how to fix this properly (or not bother).

Post by Alin Nastac
TEXTREL usr/lib/bitpim-0.8.08/apsw.so
TEXTREL usr/lib/bitpim-0.8.08/native.usb._libusb.so

These are built using Python on Redhat 9 and use whatever
linker options are standard for that.

Post by Alin Nastac
I'd take a look at this but I can't seem to find
the source code in the sf bitpim cvs repo

We switched to Subversion last night. You can find details
at http://sourceforge.net/svn/?group_id=75211
The usb stuff is in trunk/bitpim/src/native/usb. apsw is
currently stored elsewhere (Google it). It will be moving
into the subprojects part of the BitPim Subversion. In
either case there is nothing you can do to the code to
change the message - you have to fix distutils on Redhat 9.

Post by Alin Nastac
executable stacks
RWX --- --- usr/lib/bitpim-0.8.08/helpers/bmp2avi.lbin
RWX --- --- usr/lib/bitpim-0.8.08/helpers/pngtopnm.lbin
RWX --- --- usr/lib/bitpim-0.8.08/helpers/pnmtopng.lbin
RWX --- --- usr/lib/bitpim-0.8.08/helpers/ppmquant.lbin

These are built on Redhat 9. Yadda yadda yadda. To fix the
first one would require BitPim to be compiled on Gentoo.
The bottom three are from netpbm. The code could be changed
to look in the helpers directory, and if they are not there
then look on the system and then have netpbm listed as a
dependency. If BitPim does end up being built on Gentoo
then I'll make this change.

Basically, if a Gentoo developer is prepared to put the
effort into making several things up to date and keep them
that way then I'll help. If not, you get what is built
on Redhat 9 just like all the other Linux distros.

Roger

Alin Nastac

2006-03-03 07:23:09 UTC

Post by Roger Binns
...
The correct fix and the Gentoo philosophy is that this should
be run/built from "source". However there are several problems.
Firstly the Gentoo release procedures cannot keep up. There
is a new BitPim release every three weeks (it used to be every two).
Consequently things will be long obselete by the time ~x86 is
removed.

that would be the preferred way, but since you do not provide the source
tarball in your releases, it cannot be done.
please add the source tarball to your future releases.

Post by Roger Binns
Given these problems with portage, someone started making
ebuilds that just grab the rpm and untar it. Even then they haven't
keep up with the release schedule.
Unless someone at Gentoo is prepared to own the effort and
put proper time into this, then I am not going to do anything
differently.
If someone will do that, then they need to do the following.
I will give them full assistance, and also make some code
changes that will help. Doing this will also get you
BitPim working on all architectures (there are no CPU or
32/64 bit dependencies)

who says that every release should be immediately available in all
distros? does Debian or Redhat include the update whenever you release a
new versions?

Roger Binns

2006-03-03 07:39:08 UTC

Post by Alin Nastac
that would be the preferred way, but since you do not provide the source
tarball in your releases, it cannot be done.

The tree is tagged - do a check out on the tag. For example the most
recent release was tagged BITPIM_0_8_08. We haven't done the first
release from the new Subversion repository yet but will do soon
at which point there will be a tag namespace there.

Post by Alin Nastac
please add the source tarball to your future releases.

No. The SourceForge file release process is far too annoying.
As I mentioned in the previous mail, that is why I don't
have builds for other versions of Linux distros.

If you are prepared to go through the SourceForge upload process with
each release I'll happily email you the tarball each time to
do so.

Post by Alin Nastac
who says that every release should be immediately available in
all distros?

I do and the users do. BitPim changes for the better noticeably
with each release. That is a major part of the reason why the
releases are so frequent. We update a lot of the phone model
support as well as features/functionality common to all phones.

Telling users there is a new version (ie removing ~x86) only
to have them find out it is 3 months old and the current release
works with their phone better doesn't help anyone.

ie there is something in place now that works well now, and is
always up to date. Proposing to make that significantly worse
isn't that interesting to me.

Post by Alin Nastac
Does Debian or Redhat include the update whenever you release
a new versions?

They don't supply BitPim. The users grab it from the BitPim
web site.

Roger

Alin Nastac

2006-03-03 08:00:38 UTC

Post by Alin Nastac
that would be the preferred way, but since you do not provide the source
tarball in your releases, it cannot be done.

not going to happen. I'm not willing to take this extra-work every time
I bump the version.

Post by Alin Nastac
please add the source tarball to your future releases.

No. The SourceForge file release process is far too annoying.
As I mentioned in the previous mail, that is why I don't
have builds for other versions of Linux distros.
If you are prepared to go through the SourceForge upload process with
each release I'll happily email you the tarball each time to do so.

c'mon, all the other open source projects release their source tarball
first! that is the way things work in this realm.
is it so hard to upload just one more file?

Post by Alin Nastac
who says that every release should be immediately available in all
distros?

I do and the users do. BitPim changes for the better noticeably
with each release. That is a major part of the reason why the
releases are so frequent. We update a lot of the phone model support
as well as features/functionality common to all phones.
Telling users there is a new version (ie removing ~x86) only
to have them find out it is 3 months old and the current release
works with their phone better doesn't help anyone.
ie there is something in place now that works well now, and is
always up to date. Proposing to make that significantly worse
isn't that interesting to me.

Post by Alin Nastac
Does Debian or Redhat include the update whenever you release a new
versions?

They don't supply BitPim. The users grab it from the BitPim
web site.

then you want us remove app-mobilephone/bitpim from our tree, leaving
Gentoo users install it from your rpm?

Roger Binns

2006-03-03 08:29:32 UTC

Post by Alin Nastac
not going to happen. I'm not willing to take this extra-work every time
I bump the version.

Err, ebuild already has a module that does this. You don't have to change
anything on each release:

==== 8< ====
# Source is distributed only by CVS
# We will check out a particular revision
ECVS_AUTH="pserver"
ECVS_SERVER="cvs.sourceforge.net:/cvsroot/${PN}"
ECVS_MODULE="${PN}"
ECVS_BRANCH="BITPIM_${PV//./_}"
ECVS_USER="anonymous"
ECVS_PASS=""
ECVS_CVS_OPTIONS="-dP"

inherit cvs
==== 8< ====

If you have that in your ebuild then it will automatically grab the right
source. Of course the next release will need to use Subversion instead
but the principle is the same. Look at this:

http://cvs.sf.net/viewcvs.py/bitpim/bitpim/unixpkg/bitpim.ebuild

The reason that didn't go any further is because the person who supplied
it couldn't get the other packages (eg wxPython) to be maintained
and updated.

Post by Alin Nastac
c'mon, all the other open source projects release their source tarball
first! that is the way things work in this realm.
is it so hard to upload just one more file?

I don't see you volunteering for this extra effort. I am not going to
do it. There is zero benefit to the users of a source tarball - the
source is sitting there in CVS and the users don't run from source. There
is zero benefit to developers since they will need to keep up to date
with changes.

The only benefit is to packagers. And we have already established that
they are not interested in keeping up or ensuring their users have
recent versions.

In fact the only packager who does keep up is me, putting up something
that is built on Redhat 9 and runs on all recent popular distros. And
I already have the source.

Post by Alin Nastac
then you want us remove app-mobilephone/bitpim from our tree, leaving
Gentoo users install it from your rpm?

It should either be maintained or removed. Having something that is
mostly ignored and out of date doesn't help anyone. It is especially
silly having it be something that just untars the rpm *and* have it
being out of date.(@)

I have volunteered to help "fix" all this, but it requires ongoing effort
from a Gentoo developer.

IMHO Gentoo can't cope with something that does change fairly frequently
even though people may think it does. (I've found this with a few other
packages as well.)

On the other hand, I am still waiting for a reply to my response to a
Debian developer in 2004 :-)

(@) What might be better is having a tool that given an rpm, untars
it, and installs it automatically updating the package database.
That tool won't need to be updated very often and users could just
run it when they have a new rpm.

Roger

Aaron M. Ucko

2006-03-04 22:58:50 UTC

Post by Roger Binns
On the other hand, I am still waiting for a reply to my response to a
Debian developer in 2004 :-)

Hi, everyone! I'll take that as my cue to delurk (which I would have
done somewhat earlier if not for an unfortunate misunderstanding with
regard to moderation, but never mind that...).

Anyway, I can't speak to the earlier effort, as it predates my
interest in BitPim and I'm not personally acquainted with anyone
involved, but I'll be glad to comment on the current state of affairs.

I have prepared and uploaded packages of BitPim 0.8.08 for Debian
unstable (aka sid, and the usual entry point into our archive);
because they are completely new to the archive, they still need to
undergo formal ftpmaster approval, which probably ought to happen
before too much longer. (Future uploads should experience no such
delay).

Of course, unstable is not for everybody, and a lot of users prefer to
run official stable releases or the intermediate testing distribution,
which aims to stay reasonably up to date while avoiding a lot of the
problems that can plague unstable, and from which stable releases are
cut every so often.

It should be possible to keep the version of BitPim in testing
reasonably current (generally no more than one upstream release
behind) without too much special effort, especially if I set higher
priorities for uploads with particularly important fixes. Stable is
another matter, but there's an auxiliary archive at backports.org to
which newer versions could go.

The actual packages contain just BitPim, with dependencies on
everything else it needs (including DSV, which I had to upload
separately, but shouldn't need much subsequent attention.) The only
drawback of this is getting a slightly older version of wxPython than
BitPim wants because Debian's wxWidgets maintainer considers 2.6.2's
Gtk+ port too buggy to upload; however, it wasn't too hard to adjust
brewcompressedimage.py accordingly, and other code seems unaffected.

Incidentally, ReleaseForge (releaseforge.sf.net) claims to make the
file release process a lot less painful; I've never had reason to try
it, though.

--
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-03-08 06:16:08 UTC

Post by Aaron M. Ucko
behind) without too much special effort, especially if I set higher
priorities for uploads with particularly important fixes.

The vast majority of changes are to fix/update/add functionality
for phones, especially newer ones. If that happens for a phone
you don't have then it is irrelevant. If it happens for a phone
you have then you'll desperately want the updates. We have had
a very good track record of not introducing regressions.

Post by Aaron M. Ucko
The actual packages contain just BitPim,

Do you cx_Freeze it in any way or just run from the .py files?
I assume you compile the various modules inside BitPim such
as native.usb and native.strings. Note also that must run
python with -OO

Let us know if there is anything we can put in the released
packages that would make your life easier.

Aaron M. Ucko

2006-03-08 17:26:43 UTC

Post by Roger Binns
Do you cx_Freeze it in any way or just run from the .py files?

I just run from the .py files. (I don't believe Debian includes
cx_Freeze, or would approve of using it, as it would increase the set
of packages directly affected by [security-]critical Python bugs.)

Post by Roger Binns
I assume you compile the various modules inside BitPim such
as native.usb and native.strings.

Right; I also build bmp2avi from source, and symlink to Debian's
copies of ffmpeg and the relevant netpbm programs.

Post by Roger Binns
Note also that must run python with -OO

I've been using just -O, but that's easy enough to adjust.

Post by Roger Binns
Let us know if there is anything we can put in the released
packages that would make your life easier.

There are two things that would be nice:

- Official man pages, in either roff or DocBook format. It's okay if
these defer to the existing HTML documentation for most details, but
there should still be *something*. (Debian's policy requires a man
page for every program in the standard path; I've thrown minimal
ones together, but would appreciate it if you could take them over.
I'll be happy to send you copies of what I've written/cribbed.)

- A comprehensive top-level makefile would greatly simplify the Debian
build scripts, which currently have to handle all the subcomponents
that require native compilation individually.

Thanks!

Roger Binns

2006-03-09 06:28:53 UTC

Post by Aaron M. Ucko
Right; I also build bmp2avi from source, and symlink to Debian's
copies of ffmpeg and the relevant netpbm programs.

Note that ffmpeg needs to be built with mp3 support. Also I
believe that netpbm command line options and binary names
kept changing.

Post by Aaron M. Ucko
- Official man pages, in either roff or DocBook format. It's okay if
these defer to the existing HTML documentation for most details, but
there should still be *something*.

Please send me what you have, and I'll add it to the help
directory. However it is pretty much going to point to the
gui help. Once we have a command line version of BitPim then
this becomes more important.

Post by Aaron M. Ucko
- A comprehensive top-level makefile would greatly simplify the Debian
build scripts, which currently have to handle all the subcomponents
that require native compilation individually.

Can you send me the script have already and I will add that as
a Makefile. It won't do any dependency checking, just always
build everything on invocation.

BTW is there a need for it to be a Makefile, or is a shell script
ok?

Post by Aaron M. Ucko
2.3(.5) is the default, but 2.4(.2) is also available, and
coinstallable. The wxPython packages currently tie me to 2.3, though.

We are currently tied to 2.3 anyway. 2.4 on Windows uses a newer
version of Microsoft's compiler which requires new C library DLLs
which aren't redistributable with GPL applications.

I believe at some point we'll have to bite the bullet. Those Windows
users who don't already have the DLLs will have to be pointed at
Microsft.

ReleaseForge is a gui app using Qt. In that sense it is a marginal
improvement over the web page interface supplied by SourceForge,
but it just changes whose silly buttons you have to press.

Sigh. I take it there's no good way to rip out its GUI and just use
the underlying engine?

I didn't look. But given I asked the author and he wasn't interested
in a command line version, I'd expect that the code isn't remotely
structured in a useful way to make command line work.

Roger

Aaron M. Ucko

2006-03-09 16:33:28 UTC

Post by Roger Binns
Note that ffmpeg needs to be built with mp3 support. Also I

Due to patent concerns, no official Debian package may support mp3
encoding. :-/ However, there are unofficial LAME packages against
which certain official packages (ffmpeg included) can be rebuilt, with
the user assuming any liability. Also, some official packages (again
including ffmpeg) support encoding mp2s, which a lot of mp3 decoders
can handle; would that be an option here, or do phones specifically
require mp3s? (I can't readily test on mine [a VX5200] at the moment,
and don't know how typical it is anyway.)

Post by Roger Binns
believe that netpbm command line options and binary names
kept changing.

AFAICT, Debian's current netpbm binaries should support BitPim's
usage, so that at least is not a problem.

Post by Aaron M. Ucko
- Official man pages, in either roff or DocBook format. It's okay if
these defer to the existing HTML documentation for most details, but
there should still be *something*.

Please send me what you have, and I'll add it to the help
directory.

Attached; thanks!

Post by Roger Binns
However it is pretty much going to point to the gui help.

As I said, that's sufficient, and by no means unheard of.

Post by Roger Binns
Once we have a command line version of BitPim then
this becomes more important.

*nod*

Post by Roger Binns
Can you send me the script have already and I will add that as
a Makefile. It won't do any dependency checking, just always
build everything on invocation.

Also attached (as "rules"). The first and last few lines are
essentially Debian-specific boilerplate, but most of the stuff in the
middle could probably stand to be factored out. Anyway, a
"brute-force" approach is fine by me.

Post by Roger Binns
BTW is there a need for it to be a Makefile, or is a shell script
ok?

Either is okay, but casting it as a makefile may be more convenient
for everyone, as I'd like it to support build, clean, and install
modes, with user-specified target directories.

Thanks!

Post by Roger Binns
We are currently tied to 2.3 anyway. 2.4 on Windows uses a newer
version of Microsoft's compiler which requires new C library DLLs
which aren't redistributable with GPL applications.

Fun.

Post by Roger Binns
I didn't look. But given I asked the author and he wasn't interested
in a command line version, I'd expect that the code isn't remotely
structured in a useful way to make command line work.

Ah, well.

--
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-03-19 02:42:41 UTC

Also, some official packages (again including ffmpeg) support encoding
mp2s, which a lot of mp3 decoders can handle; would that be an option here,

I've tried on a phone or two and they don't support mp2.

Post by Roger Binns
Please send me what you have, and I'll add it to the help
directory.

Attached; thanks!

Now in the help directory. I am thinking of getting rid
of BitFling as a seperate user visible executable. It
is actually just bitpim with "bitfling" as a command line
argument and very rarely used.

Also attached (as "rules"). The first and last few lines are
essentially Debian-specific boilerplate, but most of the stuff in the
middle could probably stand to be factored out.

I've moved some of it out. What is the correct filename for
this? (eg for rpms it is bitpim.spec, should it be bitpim.rules?)

Checkout the main trunk and you can see the work I have been doing.
You'll find buildrelease/makedist.py interesting.

Roger

Aaron M. Ucko

2006-03-20 20:13:38 UTC

First off, I'm pleased to report that my initial packages recently
made it into the archive, so further uploads should encounter minimal
delay.

Post by Roger Binns
I've tried on a phone or two and they don't support mp2.

In that case, I'm afraid my only option is to document the
limitation. Thanks for testing (and no thanks to Frauenhofer and
their lawyers :-P).

Post by Roger Binns
Now in the help directory. I am thinking of getting rid
of BitFling as a seperate user visible executable. It
is actually just bitpim with "bitfling" as a command line
argument and very rarely used.

Thanks!

Incidentally, I had originally considered writing a unified man page,
but decided to split it up in part because I split BitFling off into a
separate binary package on account of its extra dependencies. (In
retrospect, though, they're a drop in the bucket compared to wxPython,
so [re]unification may well be in order.)

Post by Roger Binns
I've moved some of it out. What is the correct filename for
this? (eg for rpms it is bitpim.spec, should it be bitpim.rules?)

My preference would be to meet you in the middle: just give the file a
distribution-neutral name (such as Makefile or build.sh) and similarly
neutral contents and let me specify my preferred directory layout via
command-line arguments or environment variables. That way, you won't
have to worry about the details of Debian's packaging policy (which
shifts over time), and the contents may be more generally useful.

It's probably also worth noting that building Debian packages involves
consulting a number of files under the debian/ subdirectory (which,
again, you need not provide); that was the "rules" file, but there are
several others I didn't bother sending, including changelog, control,
and copyright.

Post by Roger Binns
Checkout the main trunk and you can see the work I have been doing.
You'll find buildrelease/makedist.py interesting.

I've taken a look at this script, but I'm still not sure how useful it
is when making unfrozen packages.

Anyway, thanks again for all the help.

--
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-03-21 07:18:56 UTC

Post by Roger Binns
I've tried on a phone or two and they don't support mp2.

In that case, I'm afraid my only option is to document the
limitation. Thanks for testing (and no thanks to Frauenhofer and
their lawyers :-P).

It is best to detect that the wrong binaries are present.
I think it can be done by running ffmpeg --formats,
looking for the mp3 line and seeing if D and E are
there. We can throw up a help page like this:

http://bitpim.org/help/error-nopvconv.htm

Post by Aaron M. Ucko
My preference would be to meet you in the middle: just give the file a
distribution-neutral name (such as Makefile or build.sh) and similarly
neutral contents and let me specify my preferred directory layout via
command-line arguments or environment variables. That way, you won't
have to worry about the details of Debian's packaging policy (which
shifts over time), and the contents may be more generally useful.

I am using buildrelease/makedist.py as the Makefile/build.sh.

Post by Aaron M. Ucko
It's probably also worth noting that building Debian packages involves
consulting a number of files under the debian/ subdirectory (which,
again, you need not provide);

I'd be happy to make that directory under packaging/. It will lessen
the amount of crud you have to carry around.

Post by Aaron M. Ucko
several others I didn't bother sending, including changelog, control,
and copyright.

I saw you make the changelog using lynx -dump. That is a good way
of doing it. What format is copyright in? I can put that in packaging
and then it can also be used for the other packaging systems.

Post by Aaron M. Ucko
I've taken a look at this script, but I'm still not sure how useful it
is when making unfrozen packages.

It will be more useful once I add another linuxbuild that makes a
"source" tree (ie without freezing). Looking at your rules file,
it seems like everything is dumped in /usr/share instead of
/usr/lib as I do for rpm. You can't put it in /usr/share because
there is a binary (avi2bin) and that is platform specific. I
am open to other locations. What would be nice is if you could
post a 'ls -lR' of the tree that you install.

Roger

Aaron M. Ucko

2006-03-21 15:29:30 UTC

Post by Roger Binns
It is best to detect that the wrong binaries are present.
I think it can be done by running ffmpeg --formats,
looking for the mp3 line and seeing if D and E are there. We can
http://bitpim.org/help/error-nopvconv.htm

Yeah, that would be a step up from the current passive documentation.

I am using buildrelease/makedist.py as the Makefile/build.sh.

This still seems to concern itself only with packing things up (in
frozen form, no less), rather than running swig and building native
code or ensuring that any output has been cleaned up properly.

Post by Aaron M. Ucko
It's probably also worth noting that building Debian packages involves
consulting a number of files under the debian/ subdirectory (which,
again, you need not provide);

I'd be happy to make that directory under packaging/. It will lessen
the amount of crud you have to carry around.

Thanks, but it is honestly saner to keep the Debian packaging separate
-- see, for instance,
http://lists.debian.org/debian-mentors/2005/04/msg00219.html .

Post by Aaron M. Ucko
several others I didn't bother sending, including changelog, control,
and copyright.

I saw you make the changelog using lynx -dump. That is a good way

Debian packages generally carry two changelogs: a Debian changelog in
a particular standardized format documenting changes to the packaging
and fixes to bugs reported through Debian's bug-tracking system, and
an upstream changelog that gives more detail on the changes to the
actual source code; it's the latter that lynx -dump produces.

Post by Roger Binns
of doing it. What format is copyright in? I can put that in packaging
and then it can also be used for the other packaging systems.

Plain text, with some formatting conventions. You can view it at
http://packages.debian.org/changelogs/pool/main/b/bitpim/bitpim_0.8.08.dfsg.2-3/bitpim.copyright
but a few lines are Debian-specific. (OTOH, maintaining a detailed
list of outliers in your LICENSE file would make it easier to ensure
that the Debian copyright file is complete and up to date.)

Post by Roger Binns
It will be more useful once I add another linuxbuild that makes a
"source" tree (ie without freezing). Looking at your rules file,
it seems like everything is dumped in /usr/share instead of
/usr/lib as I do for rpm. You can't put it in /usr/share because
there is a binary (avi2bin) and that is platform specific. I am open
to other locations. What would be nice is if you could
post a 'ls -lR' of the tree that you install.

I've attached a detailed listing, but the short answer is that I do in
fact put a handful of files under /usr/lib:

$ ls -R /usr/lib/bitpim
/usr/lib/bitpim:
bmp2avi.lbin* native/

/usr/lib/bitpim/native:
strings/ usb/

/usr/lib/bitpim/native/strings:
__init__.py __init__.pyc __init__.pyo jarow.so

/usr/lib/bitpim/native/usb:
__init__.py __init__.pyo libusb.py libusb.pyo usb.pyc
__init__.pyc _libusb.so libusb.pyc usb.py usb.pyo

To support this layout, I give /usr/share/bitpim/native a non-empty
__init__.py:

# Handle Debian's split-up layout
__path__.insert(0, '/usr/lib/bitpim/native')

--
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-03-22 07:52:59 UTC

Post by Roger Binns
I am using buildrelease/makedist.py as the Makefile/build.sh.

This still seems to concern itself only with packing things up (in
frozen form, no less),

The frozen form is just three of the three current ways of packaging
things up :-) There will be a fourth that just makes a tree below
dist.

Post by Aaron M. Ucko
rather than running swig and building native code

packaging/buildmodules.py

Post by Aaron M. Ucko
or ensuring that any output has been cleaned up properly.

What specifically are you referring to?

Post by Aaron M. Ucko
Thanks, but it is honestly saner to keep the Debian packaging separate

Ok. I do want to keep your seperate files as small as possible though
especially so they don't duplicate what should be in the BitPim source.

Post by Aaron M. Ucko
Plain text, with some formatting conventions. You can view it at
http://packages.debian.org/changelogs/pool/main/b/bitpim/bitpim_0.8.08.dfsg.2-3/bitpim.copyright
but a few lines are Debian-specific. (OTOH, maintaining a detailed
list of outliers in your LICENSE file would make it easier to ensure
that the Debian copyright file is complete and up to date.)

I am definitely not the only copyright holder - I think you'll
find others have written more code than I have!

The xyaptu.py file is based on code that was under the BSD license
not the Python license. The recipe pages at the ASPN cookbook
website do not say anything. However I happen to own the O'Reilly
book that was printed from all that together with editorial notes
and had this recipe in it. The foreword to the cookbook says they
contacted all the authors and that all the recipes in the book
are consequently under the BSD license.

Is the file allowed to include pointers to licenses (ie URLS) or
do you have to include the whole body as well. I'd like to get
to the point where you can lynx -dump the following pages:

http://bitpim.org/help/licenseandwarranty.htm
http://bitpim.org/help/3rdparty.htm

I can break these up so the first page is strictly about the code
in BitPim (ie the stuff you list) and second is what you get if
you freeze things.

Post by Aaron M. Ucko
I've attached a detailed listing, but the short answer is that I do in
$ ls -R /usr/lib/bitpim
bmp2avi.lbin* native/

You can't just put bmp2avi there without also modifying the code
that looks for helper binaries.

Can you also include a directory listing for /usr/share? Do you
version the directory (eg /usr/share/bitpim-versionnumber)

You need to be very careful having Python bytecode that is available
across multiple machines. The format will change between versions
and can be different depending on if the host is 32 or 64 bit,
as well as endianess I believe. It will try to recompile to new
.pyc/.pyo files but fail because /usr/share is readonly to users.

The FHS does read as BitPim should install in a single directory
below /usr/lib or in /opt.

Roger

Aaron M. Ucko

2006-04-08 22:06:45 UTC

Apologies for taking so long to respond; I was busy with other things
(including updating the Debian packages to 0.8.11, which I've just
uploaded to the archive).

Post by Roger Binns
packaging/buildmodules.py

Nice. This helps somewhat; however, it provides no way to get back to
a pristine source tree (not *that* difficult, mind you, but a
necessary step in producing the source package) and also completely
ignores bmp2avi.

It also doesn't install anything anywhere, though I suppose that's
what makedist.py is theoretically for.

Post by Roger Binns
Ok. I do want to keep your seperate files as small as possible though
especially so they don't duplicate what should be in the BitPim source.

Thanks. As far as that goes, buildmodules.py is definitely a step in
the right direction.

Post by Roger Binns
I am definitely not the only copyright holder - I think you'll
find others have written more code than I have!

Yeah, I accidentally left out the "and others" (though it was already
present two lines down).

Post by Roger Binns
The xyaptu.py file is based on code that was under the BSD license
not the Python license. The recipe pages at the ASPN cookbook

Thanks for clarifying that.

Post by Roger Binns
Is the file allowed to include pointers to licenses (ie URLS) or
do you have to include the whole body as well. I'd like to get to the

It's legal (and encouraged) to cite the (L)GPL and the BSD license by
reference to files under /usr/share/common-licenses, but everything
else must be included verbatim.

Post by Roger Binns
http://bitpim.org/help/licenseandwarranty.htm
http://bitpim.org/help/3rdparty.htm

I'll still need a Debian-specific header, if nothing else.

Post by Roger Binns
I can break these up so the first page is strictly about the code
in BitPim (ie the stuff you list) and second is what you get if
you freeze things.

That would make sense.

Post by Roger Binns
You can't just put bmp2avi there without also modifying the code
that looks for helper binaries.

I have symlinks from /usr/share/bitpim/helpers:

$ ls -l /usr/share/bitpim/helpers
total 0
lrwxrwxrwx 1 root root 32 2006-04-08 17:33 bmp2avi.lbin -> ../../../lib/bitpim/bmp2avi.lbin*
lrwxrwxrwx 1 root root 19 2006-04-08 17:33 ffmpeg.lbin -> ../../../bin/ffmpeg*
lrwxrwxrwx 1 root root 21 2006-04-08 17:33 pngtopnm.lbin -> ../../../bin/pngtopnm*
lrwxrwxrwx 1 root root 21 2006-04-08 17:33 pnmtopng.lbin -> ../../../bin/pnmtopng*
lrwxrwxrwx 1 root root 21 2006-04-08 17:33 ppmquant.lbin -> ../../../bin/ppmquant*

Post by Roger Binns
Can you also include a directory listing for /usr/share? Do you

I thought I did last time, but it appears to have been eaten. I'll
tack on an inline copy this time around.

Post by Roger Binns
version the directory (eg /usr/share/bitpim-versionnumber)

No, I see no reason to version any directories, as only one version of
a given .deb can be installed at a time anyway.

Post by Roger Binns
You need to be very careful having Python bytecode that is available
across multiple machines. The format will change between versions
and can be different depending on if the host is 32 or 64 bit,
as well as endianess I believe. It will try to recompile to new
.pyc/.pyo files but fail because /usr/share is readonly to users.

I was under the impression that the bytecode was machine-independent.
Even if not, though, I'm fairly certain that Python will simply ignore
incompatible or outdated bytecode files that it can't update.

Moreover, the main distinction between /usr/share and /usr/lib from a
Debian perspective is that use of the former signals that the contents
are architecture-independent and therefore don't need to be packaged
separately for every architecture. (The Python compiler runs at
installation time rather than build time, so the status of its output
files is largely a moot point.)

Anyway, here's the file breakdown:

bitpim_0.8.11.dfsg.1-1_all.deb
------------------------------
new debian package, version 2.0.
size 3827454 bytes: control archive= 8645 bytes.
677 bytes, 16 lines control
20779 bytes, 273 lines md5sums
649 bytes, 19 lines * postinst #!/bin/sh
160 bytes, 5 lines * postrm #!/bin/sh
103 bytes, 9 lines * prerm #!/bin/sh
Package: bitpim
Version: 0.8.11.dfsg.1-1
Section: comm
Priority: extra
Architecture: all
Depends: python (>= 2.3), python (<< 2.4), bitpim-lib, python-apsw, python-dsv, python-serial, python-wxgtk2.6
Recommends: netpbm
Suggests: bitfling, ffmpeg
Conflicts: bitfling (<< 0.8.11)
Installed-Size: 10859
Maintainer: Aaron M. Ucko <***@debian.org>
Description: utility to communicate with many CDMA phones
BitPim allows you to view and manipulate data on many phones from LG,
Samsung, Sanyo, and other manufacturers that use Qualcomm CDMA chips.
Depending on your phone model, you may be able to access the phone
book, the calendar, wallpapers, ring tones, and the filesystem.
drwxr-xr-x root/root 0 2006-04-08 21:40:59 ./
drwxr-xr-x root/root 0 2006-04-08 21:40:59 ./usr/
drwxr-xr-x root/root 0 2006-04-08 21:40:59 ./usr/bin/
-rwxr-xr-x root/root 69 2006-04-08 21:40:57 ./usr/bin/bitpim
drwxr-xr-x root/root 0 2006-04-08 21:40:58 ./usr/share/
drwxr-xr-x root/root 0 2006-04-08 21:40:58 ./usr/share/doc/
drwxr-xr-x root/root 0 2006-04-08 21:41:04 ./usr/share/doc/bitpim/
-rw-r--r-- root/root 1840 2006-03-17 23:17:09 ./usr/share/doc/bitpim/README.Debian
-rw-r--r-- root/root 9388 2006-04-08 21:31:59 ./usr/share/doc/bitpim/copyright
-rw-r--r-- root/root 21154 2006-04-08 21:40:57 ./usr/share/doc/bitpim/changelog.gz
-rw-r--r-- root/root 1129 2006-04-08 21:39:03 ./usr/share/doc/bitpim/changelog.Debian.gz
drwxr-xr-x root/root 0 2006-04-08 21:40:58 ./usr/share/man/
drwxr-xr-x root/root 0 2006-04-08 21:41:04 ./usr/share/man/man1/
-rw-r--r-- root/root 620 2006-02-22 17:41:14 ./usr/share/man/man1/bitpim.1.gz
drwxr-xr-x root/root 0 2006-04-08 21:40:58 ./usr/share/menu/
-rw-r--r-- root/root 108 2006-02-22 17:41:14 ./usr/share/menu/bitpim
drwxr-xr-x root/root 0 2006-04-08 21:41:00 ./usr/share/bitpim/
drwxr-xr-x root/root 0 2006-04-08 21:41:00 ./usr/share/bitpim/code/
-rw-r--r-- root/root 2474 2006-04-08 21:40:57 ./usr/share/bitpim/code/phone_media_codec.py
-rw-r--r-- root/root 23023 2006-04-08 21:40:57 ./usr/share/bitpim/code/csv_calendar.py
-rw-r--r-- root/root 35501 2006-04-08 21:40:57 ./usr/share/bitpim/code/vcard.py
-rw-r--r-- root/root 1459 2006-04-08 21:40:57 ./usr/share/bitpim/code/phonenumber.py
-rwxr-xr-x root/root 7898 2006-04-08 21:40:57 ./usr/share/bitpim/code/brewcompressedimage.py
-rw-r--r-- root/root 10782 2006-04-08 21:40:57 ./usr/share/bitpim/code/bitflingscan.py
-rw-r--r-- root/root 22597 2006-04-08 21:40:57 ./usr/share/bitpim/code/call_history.py
-rwxr-xr-x root/root 2701 2006-04-08 21:40:57 ./usr/share/bitpim/code/bp.py
-rw-r--r-- root/root 22405 2006-04-08 21:40:57 ./usr/share/bitpim/code/vcal_calendar.py
-rw-r--r-- root/root 98974 2006-04-08 21:40:57 ./usr/share/bitpim/code/importexport.py
-rwxr-xr-x root/root 13395 2006-04-08 21:40:57 ./usr/share/bitpim/code/usb_ids.py
-rw-r--r-- root/root 9634 2006-04-08 21:40:57 ./usr/share/bitpim/code/data_recording.py
-rw-r--r-- root/root 38219 2006-04-08 21:40:57 ./usr/share/bitpim/code/filesystem.py
-rw-r--r-- root/root 22652 2006-04-08 21:40:57 ./usr/share/bitpim/code/common.py
-rw-r--r-- root/root 4665 2006-04-08 21:40:57 ./usr/share/bitpim/code/field_color.py
-rw-r--r-- root/root 11664 2006-04-08 21:40:57 ./usr/share/bitpim/code/guihelper.py
-rw-r--r-- root/root 5204 2006-04-08 21:40:57 ./usr/share/bitpim/code/widgets.py
-rwxr-xr-x root/root 12023 2006-04-08 21:40:57 ./usr/share/bitpim/code/comdiagnose.py
-rw-r--r-- root/root 65272 2006-04-08 21:40:57 ./usr/share/bitpim/code/guiwidgets.py
-rw-r--r-- root/root 7523 2006-04-08 21:40:57 ./usr/share/bitpim/code/rangedslider.py
-rw-r--r-- root/root 7313 2006-04-08 21:40:57 ./usr/share/bitpim/code/midifile.py
-rw-r--r-- root/root 2157 2006-04-08 21:40:57 ./usr/share/bitpim/code/helpids.py
-rw-r--r-- root/root 5287 2006-04-08 21:40:57 ./usr/share/bitpim/code/bptime.py
-rw-r--r-- root/root 12275 2006-04-08 21:40:57 ./usr/share/bitpim/code/setphone_wizard.py
-rw-r--r-- root/root 39782 2006-04-08 21:40:57 ./usr/share/bitpim/code/database.py
-rw-r--r-- root/root 17340 2006-04-08 21:40:57 ./usr/share/bitpim/code/memo.py
-rw-r--r-- root/root 26139 2006-04-08 21:40:57 ./usr/share/bitpim/code/aggregatedisplay.py
-rw-r--r-- root/root 16619 2006-04-08 21:40:57 ./usr/share/bitpim/code/commport.py
-rw-r--r-- root/root 44229 2006-04-08 21:40:57 ./usr/share/bitpim/code/calendarentryeditor.py
-rw-r--r-- root/root 4699 2006-04-08 21:40:57 ./usr/share/bitpim/code/fixedscrolledpanel.py
-rw-r--r-- root/root 3628 2006-04-08 21:40:57 ./usr/share/bitpim/code/developer.py
-rw-r--r-- root/root 11787 2006-04-08 21:40:57 ./usr/share/bitpim/code/prototypeslg.py
-rw-r--r-- root/root 5177 2006-04-08 21:40:57 ./usr/share/bitpim/code/outlook_tasks.py
-rw-r--r-- root/root 48326 2006-04-08 21:40:57 ./usr/share/bitpim/code/prototypes.py
-rw-r--r-- root/root 26373 2006-04-08 21:40:57 ./usr/share/bitpim/code/todo.py
-rw-r--r-- root/root 79939 2006-04-08 21:40:57 ./usr/share/bitpim/code/gui.py
-rw-r--r-- root/root 22535 2006-04-08 21:40:57 ./usr/share/bitpim/code/sms_tab.py
-rw-r--r-- root/root 25158 2006-04-08 21:40:57 ./usr/share/bitpim/code/fileview.py
-rwxr-xr-x root/root 33436 2006-04-08 21:40:57 ./usr/share/bitpim/code/calendarcontrol.py
-rw-r--r-- root/root 24861 2006-04-08 21:40:57 ./usr/share/bitpim/code/outlook_calendar.py
-rw-r--r-- root/root 11040 2006-04-08 21:40:57 ./usr/share/bitpim/code/xyaptu.py
-rw-r--r-- root/root 56965 2006-04-08 21:40:57 ./usr/share/bitpim/code/phonebookentryeditor.py
drwxr-xr-x root/root 0 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/
drwxr-xr-x root/root 0 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/egroupware/
-rw-r--r-- root/root 7719 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/egroupware/egroupware.py
-rw-r--r-- root/root 43 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/egroupware/__init__.py
-rw-r--r-- root/root 3826 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/strings.py
-rw-r--r-- root/root 80 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/__init__.py
drwxr-xr-x root/root 0 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/evolution/
-rw-r--r-- root/root 8483 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/evolution/evolution.py
-rw-r--r-- root/root 42 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/evolution/__init__.py
drwxr-xr-x root/root 0 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/qtopiadesktop/
-rw-r--r-- root/root 3657 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/qtopiadesktop/qtopiadesktop.py
-rw-r--r-- root/root 46 2006-04-08 21:40:57 ./usr/share/bitpim/code/native/qtopiadesktop/__init__.py
-rw-r--r-- root/root 13007 2006-04-08 21:40:57 ./usr/share/bitpim/code/today.py
-rwxr-xr-x root/root 12272 2006-04-08 21:40:57 ./usr/share/bitpim/code/analyser.py
drwxr-xr-x root/root 0 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/
-rw-r--r-- root/root 70727 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx8000.py
-rw-r--r-- root/root 132155 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx8100.py
-rw-r--r-- root/root 167398 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgg4015.py
-rw-r--r-- root/root 2048 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo2300.py
-rw-r--r-- root/root 96250 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsung_packet.py
-rw-r--r-- root/root 21181 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungscha310.py
-rw-r--r-- root/root 25367 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx9800.py
-rw-r--r-- root/root 37664 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungscha650.py
-rw-r--r-- root/root 45349 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungscha670.py
-rw-r--r-- root/root 58492 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo.py
-rw-r--r-- root/root 21906 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungsphn200.py
-rw-r--r-- root/root 25237 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx3200.py
-rw-r--r-- root/root 58728 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungsphn400.py
-rw-r--r-- root/root 541 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo4900.py
-rw-r--r-- root/root 579 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo4920.py
-rw-r--r-- root/root 132684 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo4930.py
-rw-r--r-- root/root 105941 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_toshibavm4050.py
-rw-r--r-- root/root 39340 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgtm520.py
-rw-r--r-- root/root 194419 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx9800.py
-rw-r--r-- root/root 478 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo5300.py
-rw-r--r-- root/root 53348 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgpm225.py
-rw-r--r-- root/root 40267 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungspha460.py
-rw-r--r-- root/root 580 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo5400.py
-rw-r--r-- root/root 52958 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgpm325.py
-rw-r--r-- root/root 63195 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo8100_bell.py
-rw-r--r-- root/root 571 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo5500.py
-rw-r--r-- root/root 93266 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungspha620.py
-rw-r--r-- root/root 457 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungspha660.py
-rw-r--r-- root/root 524 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungspha680.py
-rw-r--r-- root/root 155580 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx3200.py
-rw-r--r-- root/root 497 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungspha740.py
-rw-r--r-- root/root 61462 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx4400.py
-rw-r--r-- root/root 497 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungspha840.py
-rw-r--r-- root/root 5731 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx4500.py
-rw-r--r-- root/root 10529 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_phone.py
-rw-r--r-- root/root 34465 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsung_packet.py
-rw-r--r-- root/root 4208 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx4600.py
-rw-r--r-- root/root 167960 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgc2000.py
-rw-r--r-- root/root 15463 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx4650.py
-rw-r--r-- root/root 5610 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvi5225.py
-rw-r--r-- root/root 1737 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo4900.py
-rw-r--r-- root/root 2196 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo4920.py
-rw-r--r-- root/root 2143 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo4930.py
-rw-r--r-- root/root 12113 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungsphn200.py
-rw-r--r-- root/root 4829 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx5200.py
-rw-r--r-- root/root 8694 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungsphn400.py
-rw-r--r-- root/root 1717 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo5300.py
-rw-r--r-- root/root 31875 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgg4015.py
-rw-r--r-- root/root 229149 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_brew.py
-rw-r--r-- root/root 1246 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo5400.py
-rw-r--r-- root/root 160859 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx4400.py
-rw-r--r-- root/root 1754 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo5500.py
-rw-r--r-- root/root 155127 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx4500.py
-rw-r--r-- root/root 41938 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx4600.py
-rw-r--r-- root/root 185764 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx4650.py
-rw-r--r-- root/root 266853 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyonewer.py
-rw-r--r-- root/root 541 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo7200.py
-rw-r--r-- root/root 45076 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvi5225.py
-rw-r--r-- root/root 23848 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lglg6190.py
-rw-r--r-- root/root 5915 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lglg6200.py
-rw-r--r-- root/root 6077 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx6000.py
-rw-r--r-- root/root 580 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo7300.py
-rw-r--r-- root/root 3328 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungspha460.py
-rw-r--r-- root/root 7678 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx6100.py
-rw-r--r-- root/root 107150 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo7400.py
-rw-r--r-- root/root 2309 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo8100_bell.py
-rw-r--r-- root/root 17672 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungspha620.py
-rw-r--r-- root/root 1564 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungspha660.py
-rw-r--r-- root/root 1817 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungspha680.py
-rw-r--r-- root/root 86601 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx5200.py
-rw-r--r-- root/root 1779 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungspha740.py
-rw-r--r-- root/root 72108 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_audiovoxcdm8900.py
-rw-r--r-- root/root 1779 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsungspha840.py
-rw-r--r-- root/root 38983 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_samsung.py
-rw-r--r-- root/root 45268 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo8100.py
-rw-r--r-- root/root 87790 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyomedia.py
-rw-r--r-- root/root 6291 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lglx5450.py
-rw-r--r-- root/root 571 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo8200.py
-rw-r--r-- root/root 25111 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgtm520.py
-rw-r--r-- root/root 3065 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyonewer.py
-rw-r--r-- root/root 4306 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx7000.py
-rw-r--r-- root/root 97560 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo8300.py
-rw-r--r-- root/root 165763 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lglg6190.py
-rw-r--r-- root/root 92724 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lglg6200.py
-rw-r--r-- root/root 125241 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx6000.py
-rw-r--r-- root/root 74208 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lg.py
-rw-r--r-- root/root 155648 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx6100.py
-rw-r--r-- root/root 1508 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo7200.py
-rw-r--r-- root/root 25649 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sk6100.py
-rw-r--r-- root/root 1318 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo7300.py
-rw-r--r-- root/root 2521 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo7400.py
-rw-r--r-- root/root 17319 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_audiovoxcdm8900.py
-rw-r--r-- root/root 8040 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgc2000.py
-rw-r--r-- root/root 3624 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_gsm.py
-rw-r--r-- root/root 747 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_othercdma.py
-rw-r--r-- root/root 57078 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungscha650.py
-rw-r--r-- root/root 20920 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_samsungscha670.py
-rw-r--r-- root/root 22331 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_toshibavm4050.py
-rw-r--r-- root/root 175401 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgpm225.py
-rw-r--r-- root/root 579 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo2300.py
-rw-r--r-- root/root 188326 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgpm325.py
-rw-r--r-- root/root 4202 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx8000.py
-rw-r--r-- root/root 125910 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lglx5450.py
-rw-r--r-- root/root 10344 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyomedia.py
-rw-r--r-- root/root 33637 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lgvx8100.py
-rw-r--r-- root/root 169792 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_lgvx7000.py
-rw-r--r-- root/root 2526 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo8100.py
-rw-r--r-- root/root 10644 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/__init__.py
-rw-r--r-- root/root 2030 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo8200.py
-rw-r--r-- root/root 4371 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sanyo8300.py
-rw-r--r-- root/root 22327 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_gsm.py
-rw-r--r-- root/root 49909 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_brew.py
-rw-r--r-- root/root 3421 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_sk6100.py
-rw-r--r-- root/root 47547 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/com_lg.py
-rw-r--r-- root/root 376826 2006-04-08 21:40:57 ./usr/share/bitpim/code/phones/p_sanyo.py
-rwxr-xr-x root/root 19128 2006-04-08 21:40:57 ./usr/share/bitpim/code/comscan.py
-rw-r--r-- root/root 9992 2006-04-08 21:40:57 ./usr/share/bitpim/code/phone_detect.py
-rw-r--r-- root/root 5680 2006-04-08 21:40:57 ./usr/share/bitpim/code/phoneinfo.py
-rw-r--r-- root/root 12421 2006-04-08 21:40:57 ./usr/share/bitpim/code/sms.py
-rw-r--r-- root/root 18419 2006-04-08 21:40:57 ./usr/share/bitpim/code/bphtml.py
-rw-r--r-- root/root 116767 2006-04-08 21:40:57 ./usr/share/bitpim/code/phonebook.py
-rw-r--r-- root/root 6246 2006-04-08 21:40:57 ./usr/share/bitpim/code/sms_imexport.py
-rw-r--r-- root/root 4241 2006-04-08 21:40:57 ./usr/share/bitpim/code/nameparser.py
-rw-r--r-- root/root 53664 2006-04-08 21:40:57 ./usr/share/bitpim/code/bpcalendar.py
-rw-r--r-- root/root 28290 2006-04-08 21:40:57 ./usr/share/bitpim/code/fileinfo.py
-rw-r--r-- root/root 10146 2006-04-08 21:40:57 ./usr/share/bitpim/code/update.py
-rw-r--r-- root/root 18824 2006-04-08 21:40:57 ./usr/share/bitpim/code/conversions.py
-rw-r--r-- root/root 17811 2006-04-08 21:40:57 ./usr/share/bitpim/code/auto_sync.py
-rwxr-xr-x root/root 48306 2006-04-08 21:40:57 ./usr/share/bitpim/code/hexeditor.py
-rw-r--r-- root/root 23941 2006-04-08 21:40:57 ./usr/share/bitpim/code/protogen.py
-rw-r--r-- root/root 2922 2006-04-08 21:40:57 ./usr/share/bitpim/code/pubsub.py
-rw-r--r-- root/root 10936 2006-04-08 21:40:57 ./usr/share/bitpim/code/package.py
-rw-r--r-- root/root 11011 2006-04-08 21:40:57 ./usr/share/bitpim/code/outlook_notes.py
-rw-r--r-- root/root 15420 2006-04-08 21:40:57 ./usr/share/bitpim/code/playlist.py
-rw-r--r-- root/root 9565 2006-04-08 21:40:57 ./usr/share/bitpim/code/fixedwxpTag.py
-rw-r--r-- root/root 26873 2006-04-08 21:40:57 ./usr/share/bitpim/code/common_calendar.py
-rw-r--r-- root/root 15531 2006-04-08 21:40:57 ./usr/share/bitpim/code/phone_root.py
-rw-r--r-- root/root 29503 2006-04-08 21:40:57 ./usr/share/bitpim/code/ringers.py
-rw-r--r-- root/root 4268 2006-04-08 21:40:57 ./usr/share/bitpim/code/version.py
-rw-r--r-- root/root 43095 2006-04-08 21:40:57 ./usr/share/bitpim/code/wallpaper.py
-rw-r--r-- root/root 4769 2006-04-08 21:40:57 ./usr/share/bitpim/code/call_history_export.py
-rw-r--r-- root/root 4676 2006-04-08 21:40:57 ./usr/share/bitpim/code/usbscan.py
drwxr-xr-x root/root 0 2006-04-08 21:41:01 ./usr/share/bitpim/helpers/
drwxr-xr-x root/root 0 2006-04-08 21:40:57 ./usr/share/bitpim/resources/
-rw-r--r-- root/root 1133 2006-04-08 21:40:57 ./usr/share/bitpim/resources/add_todo.png
-rw-r--r-- root/root 1256 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_wallpaper.png
-rw-r--r-- root/root 1378 2006-04-08 21:40:57 ./usr/share/bitpim/resources/delete_sms.png
-rw-r--r-- root/root 1359 2006-04-08 21:40:57 ./usr/share/bitpim/resources/add_sms.png
-rw-r--r-- root/root 1011 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_call_history.png
-rw-r--r-- root/root 1205 2006-04-08 21:40:57 ./usr/share/bitpim/resources/delete_picture.png
-rw-r--r-- root/root 1384 2006-04-08 21:40:57 ./usr/share/bitpim/resources/datagetphone.png
-rw-r--r-- root/root 557 2006-04-08 21:40:57 ./usr/share/bitpim/resources/phone_root.png
-rw-r--r-- root/root 2202 2006-04-08 21:40:57 ./usr/share/bitpim/resources/zerolen.wav
-rw-r--r-- root/root 1328 2006-04-08 21:40:57 ./usr/share/bitpim/resources/datasendphone.png
-rw-r--r-- root/root 290 2006-04-08 21:40:57 ./usr/share/bitpim/resources/data_history.png
-rw-r--r-- root/root 3621 2006-04-08 21:40:57 ./usr/share/bitpim/resources/styles.xy
-rw-r--r-- root/root 1130 2006-04-08 21:40:57 ./usr/share/bitpim/resources/add_contact.png
-rw-r--r-- root/root 507 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_file.png
-rw-r--r-- root/root 630 2006-04-08 21:40:57 ./usr/share/bitpim/resources/arrow_right.png
-rw-r--r-- root/root 3833 2006-04-08 21:40:57 ./usr/share/bitpim/resources/pblayout.xy
-rw-r--r-- root/root 456 2006-04-08 21:40:57 ./usr/share/bitpim/resources/mozilla.pdc
-rw-r--r-- root/root 523 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_log.png
-rw-r--r-- root/root 1225 2006-04-08 21:40:57 ./usr/share/bitpim/resources/delete_ringer.png
-rw-r--r-- root/root 1335 2006-04-08 21:40:57 ./usr/share/bitpim/resources/delete_memo.png
-rw-r--r-- root/root 1233 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_sms.png
-rw-r--r-- root/root 23 2006-04-08 21:40:57 ./usr/share/bitpim/resources/pbps-colourful.xy
-rw-r--r-- root/root 1158 2006-04-08 21:40:57 ./usr/share/bitpim/resources/delete_contact.png
-rw-r--r-- root/root 1054 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_calendar.png
-rw-r--r-- root/root 713 2006-04-08 21:40:57 ./usr/share/bitpim/resources/arrow_down.png
-rw-r--r-- root/root 241 2006-04-08 21:40:57 ./usr/share/bitpim/resources/palm.pdc
-rw-r--r-- root/root 1203 2006-04-08 21:40:57 ./usr/share/bitpim/resources/add_ringer.png
-rw-r--r-- root/root 956 2006-04-08 21:40:57 ./usr/share/bitpim/resources/bitfling.png
-rw-r--r-- root/root 806 2006-04-08 21:40:57 ./usr/share/bitpim/resources/ranged-slider-start.png
-rw-r--r-- root/root 888 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_message.png
-rw-r--r-- root/root 744 2006-04-08 21:40:57 ./usr/share/bitpim/resources/usb_needdriver.ids
-rw-r--r-- root/root 104 2006-04-08 21:40:57 ./usr/share/bitpim/resources/pbps-ledger.xy
-rw-r--r-- root/root 960 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_root.png
-rw-r--r-- root/root 4507 2006-04-08 21:40:57 ./usr/share/bitpim/resources/wallpaper.png
-rw-r--r-- root/root 648 2006-04-08 21:40:57 ./usr/share/bitpim/resources/arrow_left.png
-rw-r--r-- root/root 1314 2006-04-08 21:40:57 ./usr/share/bitpim/resources/add_memo.png
-rw-r--r-- root/root 12026 2006-04-08 21:40:57 ./usr/share/bitpim/resources/ringtone-watermark.png
-rw-r--r-- root/root 810 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_todo.png
-rw-r--r-- root/root 563 2006-04-08 21:40:57 ./usr/share/bitpim/resources/pbpl-view.xy
-rw-r--r-- root/root 270 2006-04-08 21:40:57 ./usr/share/bitpim/resources/ranged-slider-current.png
-rw-r--r-- root/root 776 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_ringers.png
-rw-r--r-- root/root 2216 2006-04-08 21:40:57 ./usr/share/bitpim/resources/editsettings.png
-rw-r--r-- root/root 952 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_today.png
-rw-r--r-- root/root 1090 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_protocol.png
-rw-r--r-- root/root 2097 2006-04-08 21:40:57 ./usr/share/bitpim/resources/editdetect.png
-rw-r--r-- root/root 949 2006-04-08 21:40:57 ./usr/share/bitpim/resources/add_field.png
-rw-r--r-- root/root 990 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_console.png
-rw-r--r-- root/root 672 2006-04-08 21:40:57 ./usr/share/bitpim/resources/arrow_up.png
-rw-r--r-- root/root 1119 2006-04-08 21:40:57 ./usr/share/bitpim/resources/cal_regular.xy
-rw-r--r-- root/root 912 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_calls.png
-rw-r--r-- root/root 757 2006-04-08 21:40:57 ./usr/share/bitpim/resources/ranged-slider-end.png
-rw-r--r-- root/root 1773 2006-04-08 21:40:57 ./usr/share/bitpim/resources/unknown.png
-rw-r--r-- root/root 149018 2006-04-08 21:40:57 ./usr/share/bitpim/resources/usb.ids
-rw-r--r-- root/root 723 2006-04-08 21:40:57 ./usr/share/bitpim/resources/cal_monthly_style.xy
-rw-r--r-- root/root 1044 2006-04-08 21:40:57 ./usr/share/bitpim/resources/private.png
-rw-r--r-- root/root 1092 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_playlist.png
-rw-r--r-- root/root 992 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_memo.png
-rw-r--r-- root/root 122542 2006-04-08 21:40:57 ./usr/share/bitpim/resources/wallpaper-watermark.png
-rw-r--r-- root/root 1148 2006-04-08 21:40:57 ./usr/share/bitpim/resources/delete_todo.png
-rw-r--r-- root/root 1108 2006-04-08 21:40:57 ./usr/share/bitpim/resources/delete_field.png
-rw-r--r-- root/root 2091 2006-04-08 21:40:57 ./usr/share/bitpim/resources/autosyncexecute.png
-rw-r--r-- root/root 979 2006-04-08 21:40:57 ./usr/share/bitpim/resources/cal_regular_style.xy
-rw-r--r-- root/root 432 2006-04-08 21:40:57 ./usr/share/bitpim/resources/bitpim.css
-rw-r--r-- root/root 2238 2006-04-08 21:40:57 ./usr/share/bitpim/resources/bitpim.ico
-rw-r--r-- root/root 2616514 2006-04-08 21:40:57 ./usr/share/bitpim/resources/bitpim.htb
-rw-r--r-- root/root 831 2006-04-08 21:40:57 ./usr/share/bitpim/resources/ringer.png
-rw-r--r-- root/root 545 2006-04-08 21:40:57 ./usr/share/bitpim/resources/bitpim_usb.ids
-rw-r--r-- root/root 949 2006-04-08 21:40:57 ./usr/share/bitpim/resources/editphoneinfo.png
-rw-r--r-- root/root 1193 2006-04-08 21:40:57 ./usr/share/bitpim/resources/add_picture.png
-rw-r--r-- root/root 924 2006-04-08 21:40:57 ./usr/share/bitpim/resources/cal_monthly.xy
-rw-r--r-- root/root 860 2006-04-08 21:40:57 ./usr/share/bitpim/resources/select_phonebook.png
-rw-r--r-- root/root 48958 2006-04-08 21:40:57 ./usr/share/bitpim/resources/splashscreen.jpg
lrwxrwxrwx root/root 0 2006-04-08 21:41:01 ./usr/share/bitpim/helpers/ffmpeg.lbin -> ../../../bin/ffmpeg
lrwxrwxrwx root/root 0 2006-04-08 21:41:01 ./usr/share/bitpim/helpers/ppmquant.lbin -> ../../../bin/ppmquant
lrwxrwxrwx root/root 0 2006-04-08 21:41:01 ./usr/share/bitpim/helpers/pngtopnm.lbin -> ../../../bin/pngtopnm
lrwxrwxrwx root/root 0 2006-04-08 21:41:01 ./usr/share/bitpim/helpers/bmp2avi.lbin -> ../../../lib/bitpim/bmp2avi.lbin
lrwxrwxrwx root/root 0 2006-04-08 21:41:01 ./usr/share/bitpim/helpers/pnmtopng.lbin -> ../../../bin/pnmtopng

bitfling_0.8.11.dfsg.1-1_all.deb
--------------------------------
new debian package, version 2.0.
size 47630 bytes: control archive= 1516 bytes.
778 bytes, 18 lines control
853 bytes, 12 lines md5sums
727 bytes, 25 lines * postinst #!/bin/sh
160 bytes, 5 lines * postrm #!/bin/sh
164 bytes, 7 lines * prerm #!/bin/sh
Package: bitfling
Version: 0.8.11.dfsg.1-1
Section: comm
Priority: extra
Architecture: all
Depends: bitpim (>> 0.8.11), python (>= 2.3), python (<< 2.4), python-crypto, python-paramiko
Installed-Size: 140
Maintainer: Aaron M. Ucko <***@debian.org>
Source: bitpim
Description: secure remote access to BitPim
BitPim allows you to view and manipulate data on many phones from LG,
Samsung, Sanyo, and other manufacturers that use Qualcomm CDMA chips.
Depending on your phone model, you may be able to access the phone
book, the calendar, wallpapers, ring tones, and the filesystem.
.
BitFling lets BitPim run on one machine while your phone is connected
to a different machine, even across the Internet. It uses a protocol
over a secure connection to ensure this is safe.
drwxr-xr-x root/root 0 2006-04-08 21:41:02 ./
drwxr-xr-x root/root 0 2006-04-08 21:41:03 ./usr/
drwxr-xr-x root/root 0 2006-04-08 21:41:03 ./usr/bin/
-rwxr-xr-x root/root 78 2006-04-08 21:40:57 ./usr/bin/bitfling
drwxr-xr-x root/root 0 2006-04-08 21:41:03 ./usr/share/
drwxr-xr-x root/root 0 2006-04-08 21:41:01 ./usr/share/doc/
drwxr-xr-x root/root 0 2006-04-08 21:41:05 ./usr/share/doc/bitfling/
-rw-r--r-- root/root 9388 2006-04-08 21:31:59 ./usr/share/doc/bitfling/copyright
-rw-r--r-- root/root 21154 2006-04-08 21:40:57 ./usr/share/doc/bitfling/changelog.gz
-rw-r--r-- root/root 1129 2006-04-08 21:39:03 ./usr/share/doc/bitfling/changelog.Debian.gz
drwxr-xr-x root/root 0 2006-04-08 21:41:02 ./usr/share/man/
drwxr-xr-x root/root 0 2006-04-08 21:41:05 ./usr/share/man/man1/
-rw-r--r-- root/root 449 2006-02-22 17:41:14 ./usr/share/man/man1/bitfling.1.gz
drwxr-xr-x root/root 0 2006-04-08 21:41:02 ./usr/share/menu/
-rw-r--r-- root/root 114 2006-02-22 17:41:14 ./usr/share/menu/bitfling
drwxr-xr-x root/root 0 2006-04-08 21:41:03 ./usr/share/bitpim/
drwxr-xr-x root/root 0 2006-04-08 21:41:03 ./usr/share/bitpim/code/
drwxr-xr-x root/root 0 2006-04-08 21:41:03 ./usr/share/bitpim/code/bitfling/
-rw-r--r-- root/root 5211 2006-04-08 21:40:57 ./usr/share/bitpim/code/bitfling/guihelper.py
-rwxr-xr-x root/root 21684 2006-04-08 21:40:57 ./usr/share/bitpim/code/bitfling/xmlrpcstuff.py
-rw-r--r-- root/root 29484 2006-04-08 21:40:57 ./usr/share/bitpim/code/bitfling/bitfling.py
-rw-r--r-- root/root 2441 2006-04-08 21:40:57 ./usr/share/bitpim/code/bitfling/client.py
-rw-r--r-- root/root 122 2006-04-08 21:40:57 ./usr/share/bitpim/code/bitfling/__init__.py
-rw-r--r-- root/root 1709 2006-04-08 21:40:57 ./usr/share/bitpim/code/bitfling/version.py

bitpim-lib_0.8.11.dfsg.1-1_i386.deb
-----------------------------------
new debian package, version 2.0.
size 81956 bytes: control archive= 1332 bytes.
721 bytes, 16 lines control
711 bytes, 10 lines md5sums
543 bytes, 20 lines * postinst #!/bin/sh
166 bytes, 7 lines * prerm #!/bin/sh
Package: bitpim-lib
Version: 0.8.11.dfsg.1-1
Section: comm
Priority: extra
Architecture: i386
Depends: python (>= 2.3), python (<< 2.4), libc6 (>= 2.3.5-1), libgcc1 (>= 1:4.1.0), libstdc++6 (>= 4.1.0), libusb-0.1-4 (>= 2:0.1.12)
Installed-Size: 236
Maintainer: Aaron M. Ucko <***@debian.org>
Source: bitpim
Description: architecture-dependent helper files for BitFling
BitPim allows you to view and manipulate data on many phones from LG,
Samsung, Sanyo, and other manufacturers that use Qualcomm CDMA chips.
Depending on your phone model, you may be able to access the phone
book, the calendar, wallpapers, ring tones, and the filesystem.
.
This package contains a handful of architecture-dependent helper files.
drwxr-xr-x root/root 0 2006-04-08 21:41:10 ./
drwxr-xr-x root/root 0 2006-04-08 21:41:11 ./usr/
drwxr-xr-x root/root 0 2006-04-08 21:41:11 ./usr/lib/
drwxr-xr-x root/root 0 2006-04-08 21:41:12 ./usr/lib/bitpim/
drwxr-xr-x root/root 0 2006-04-08 21:41:09 ./usr/lib/bitpim/native/
drwxr-xr-x root/root 0 2006-04-08 21:41:12 ./usr/lib/bitpim/native/usb/
-rw-r--r-- root/root 27745 2006-04-08 21:41:09 ./usr/lib/bitpim/native/usb/libusb.py
-rw-r--r-- root/root 81936 2006-04-08 21:41:12 ./usr/lib/bitpim/native/usb/_libusb.so
-rw-r--r-- root/root 11274 2006-04-08 21:41:09 ./usr/lib/bitpim/native/usb/usb.py
-rw-r--r-- root/root 500 2006-04-08 21:41:09 ./usr/lib/bitpim/native/usb/__init__.py
drwxr-xr-x root/root 0 2006-04-08 21:41:12 ./usr/lib/bitpim/native/strings/
-rw-r--r-- root/root 6368 2006-04-08 21:41:12 ./usr/lib/bitpim/native/strings/jarow.so
-rw-r--r-- root/root 428 2006-04-08 21:41:09 ./usr/lib/bitpim/native/strings/__init__.py
-rwxr-xr-x root/root 46904 2006-04-08 21:41:12 ./usr/lib/bitpim/bmp2avi.lbin
drwxr-xr-x root/root 0 2006-04-08 21:41:09 ./usr/share/
drwxr-xr-x root/root 0 2006-04-08 21:41:09 ./usr/share/doc/
drwxr-xr-x root/root 0 2006-04-08 21:41:12 ./usr/share/doc/bitpim-lib/
-rw-r--r-- root/root 9388 2006-04-08 21:31:59 ./usr/share/doc/bitpim-lib/copyright
-rw-r--r-- root/root 21154 2006-04-08 21:40:57 ./usr/share/doc/bitpim-lib/changelog.gz
-rw-r--r-- root/root 1129 2006-04-08 21:39:03 ./usr/share/doc/bitpim-lib/changelog.Debian.gz

--
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-08 23:37:28 UTC

Post by Roger Binns
packaging/buildmodules.py

Nice. This helps somewhat; however, it provides no way to get back to
a pristine source tree (not *that* difficult, mind you, but a
necessary step in producing the source package)

Mmm. The source package should be what you start with, not what
you end up with. The rpm system definitely works that way.
(eg You don't really want to undo the result of running ./configure)

Post by Aaron M. Ucko
and also completely ignores bmp2avi.

I view bmp2avi as an external helper binary. It just so happens
that the source is part of BitPim. The code hasn't changed in
the last year. There isn't any need to rebuild it all the time.
I'll ponder this one some more.

Post by Aaron M. Ucko
It also doesn't install anything anywhere, though I suppose that's
what makedist.py is theoretically for.

Correct. Makedist needs another method added that makes an install
tree suitable for slurping up by the Debian tools.

On the license front, BitPim isn't actually pure GPL. It is GPL
plus allowing linking to OpenSSL. (There was a short phase when
I attempted to use OpenSSL to talk to BitFling and changed the
license accordingly. It would be way too hard to contact all
people to remove that relaxation now.) On Mac and Linux, OpenSSL
is distributed with the OS and the GPL allows linking with that
anyway so this distinction is immaterial.

Post by Aaron M. Ucko
I thought I did last time, but it appears to have been eaten. I'll
tack on an inline copy this time around.

Last time it was only part of what got installed.

Post by Aaron M. Ucko
No, I see no reason to version any directories, as only one version of
a given .deb can be installed at a time anyway.

Really? That seems to be a pretty major restriction! All the
other packaging systems I am familiar with do allow mulitple
versions to be installed. This is used for example to have
gcc3 and gcc4 on the same system, or multiple concurrent versions
of Berkeley DB.

Post by Aaron M. Ucko
I was under the impression that the bytecode was machine-independent.
Even if not, though, I'm fairly certain that Python will simply ignore
incompatible or outdated bytecode files that it can't update.

I believe that is the case. It would only bite people who distributed
and ran from only the bytecode.

Post by Aaron M. Ucko
649 bytes, 19 lines * postinst #!/bin/sh
160 bytes, 5 lines * postrm #!/bin/sh
103 bytes, 9 lines * prerm #!/bin/sh

Anything existing in those (I assume they deal with the bytecode
compilation and removal).

Post by Aaron M. Ucko
Architecture: all

BTW do you know of anyone running on non-i386? Everything should
work fine (we run on differently endianess Mac/PPC without problem).

Post by Aaron M. Ucko
bitfling_0.8.11.dfsg.1-1_all.deb

I thought you were dumping bitfling as a seperate package?

Post by Aaron M. Ucko
bitpim-lib_0.8.11.dfsg.1-1_i386.deb
-----------------------------------
Description: architecture-dependent helper files for BitFling

I think you mean BitPim there :-)

Roger

Aaron M. Ucko

2006-04-09 02:03:37 UTC

Post by Roger Binns
Mmm. The source package should be what you start with, not what
you end up with. The rpm system definitely works that way.

One can, and often does, take a source package and go from there, but
Debian policy mandates being able to produce one from a working tree,
which I find a lot saner than generating patches by hand each time.
Some packages take the brute-force approach of copying everything to a
subdirectory which can then be wiped out to return to a clean state,
but that's at least not necessary here.

Post by Roger Binns
(eg You don't really want to undo the result of running ./configure)

It really depends on what you're doing.

Post by Roger Binns
I view bmp2avi as an external helper binary. It just so happens
that the source is part of BitPim. The code hasn't changed in
the last year. There isn't any need to rebuild it all the time.

There is if you care about multiple CPU architectures....

Post by Roger Binns
On the license front, BitPim isn't actually pure GPL. It is GPL
plus allowing linking to OpenSSL. (There was a short phase when

Yeah, I include that paragraph in the Debian documentation directory;
such exceptions are fairly common, and I have no problem with them.

Post by Roger Binns
Really? That seems to be a pretty major restriction! All the other
packaging systems I am familiar with do allow mulitple
versions to be installed. This is used for example to have
gcc3 and gcc4 on the same system, or multiple concurrent versions
of Berkeley DB.

Version numbers can always be embedded in package names as necessary;
for instance, there are packages named gcc-4.0 and libdb4.4. I'd
consider that to be overkill for BitPim, though, especially since any
package with a new name requires official ftpmaster approval.

Post by Roger Binns
I believe that is the case. It would only bite people who distributed
and ran from only the bytecode.

OK, then, it doesn't apply here.

Post by Roger Binns
Anything existing in those (I assume they deal with the bytecode
compilation and removal).

Right, largely boilerplate, and mostly automatically generated at that
(though I had to start generating the bitpim package's scripts by hand
to force use of -Wignore.

Post by Roger Binns
BTW do you know of anyone running on non-i386? Everything should

I run on amd64,and haven't hit any 64-bit cleanliness issues AFAICT.
I wouldn't be surprised to learn of users on other non-i386
architectures (particularly good old PowerPC).

Post by Roger Binns
I thought you were dumping bitfling as a seperate package?

I considered that, but held off for now.

Post by Aaron M. Ucko
Description: architecture-dependent helper files for BitFling

I think you mean BitPim there :-)

Yeah, oops. I have to watch out for those typos. :-)

--
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.

Alin Nastac

2006-03-03 08:00:38 UTC

Post by Alin Nastac
that would be the preferred way, but since you do not provide the source
tarball in your releases, it cannot be done.

not going to happen. I'm not willing to take this extra-work every time
I bump the version.

Post by Alin Nastac
please add the source tarball to your future releases.

No. The SourceForge file release process is far too annoying.
As I mentioned in the previous mail, that is why I don't
have builds for other versions of Linux distros.
If you are prepared to go through the SourceForge upload process with
each release I'll happily email you the tarball each time to do so.

c'mon, all the other open source projects release their source tarball
first! that is the way things work in this realm.
is it so hard to upload just one more file?

Post by Alin Nastac
who says that every release should be immediately available in all
distros?

I do and the users do. BitPim changes for the better noticeably
with each release. That is a major part of the reason why the
releases are so frequent. We update a lot of the phone model support
as well as features/functionality common to all phones.
Telling users there is a new version (ie removing ~x86) only
to have them find out it is 3 months old and the current release
works with their phone better doesn't help anyone.
ie there is something in place now that works well now, and is
always up to date. Proposing to make that significantly worse
isn't that interesting to me.

Post by Alin Nastac
Does Debian or Redhat include the update whenever you release a new
versions?

They don't supply BitPim. The users grab it from the BitPim
web site.

then you want us remove app-mobilephone/bitpim from our tree, leaving
Gentoo users install it from your rpm?

Mike Frysinger

2006-03-04 03:37:45 UTC

<snip>

i wont address this because i have no idea what bitpim is let alone try and
take over maintenance for it :)

Post by Alin Nastac
TEXTREL usr/lib/bitpim-0.8.08/native.usb._libusb.so

this fix is simple ... just change build.sh to pass -fPIC to gcc
libusb-pic-love.patch

Post by Alin Nastac
TEXTREL usr/lib/bitpim-0.8.08/apsw.so

hmm, i'll have to do some research to figure out what's wrong with this, but i
would guess that it's as simple as the fix for libusb.so ...

Post by Alin Nastac
executable stacks
RWX --- --- usr/lib/bitpim-0.8.08/helpers/bmp2avi.lbin

These are built on Redhat 9. Yadda yadda yadda. To fix the
first one would require BitPim to be compiled on Gentoo.

hmm, what version of binutils does your Redhat 9 box have ? see if the
version of ld on it supports exec stack markings (i havent the foggiest when
support was first integrated into binutils for it):
$ ld --help | grep execstack
if you do get stuff back, i'd simply ask you rebuild these programs by passing
-Wl,-z,noexecstack to `gcc`:
gcc foo.c -o foo -Wl,-z,noexecstack

Post by Alin Nastac
RWX --- --- usr/lib/bitpim-0.8.08/helpers/pngtopnm.lbin
RWX --- --- usr/lib/bitpim-0.8.08/helpers/pnmtopng.lbin
RWX --- --- usr/lib/bitpim-0.8.08/helpers/ppmquant.lbin

The bottom three are from netpbm. The code could be changed
to look in the helpers directory, and if they are not there
then look on the system and then have netpbm listed as a
dependency.

i maintain netpbm and make sure that it stays up-to-date ... so the proposed
idea seems like it'll work just dandy ... ive attached a patch, but some
warnings:
- i dont really know python
- i dont know bitpim at all
- patch is totally untested :)
bitpim-search-path-for-helpers.patch
-mike

Roger Binns

2006-03-04 05:12:33 UTC

Post by Mike Frysinger
i wont address this because i have no idea what bitpim is

http://www.bitpim.org :-)

Post by Mike Frysinger
let alone try and take over maintenance for it :)

The problem isn't really with BitPim. Gentoo doesn't currently
handle a package that updates as quickly as BitPim does (and
in doing so obsoletes earlier releases). Additionally there
are a number of dependencies that are non-existent or poorly
maintained in portage. They need to be maintained.

Post by Mike Frysinger
this fix is simple ... just change build.sh to pass -fPIC to gcc

Done.

Post by Alin Nastac
TEXTREL usr/lib/bitpim-0.8.08/apsw.so

hmm, i'll have to do some research to figure out what's wrong with this, but i
would guess that it's as simple as the fix for libusb.so ...

This is built as a Python extension. Python has something called
distutils which hides how programs are built on the platform. I
provide this as a setup.py file:

setup(name="apsw",
version=version,
author="Roger Binns",
author_email="***@rogerbinns.com",
description="Another Python SQLite Wrapper",

ext_modules=[Extension("apsw",
["apsw.c"])]

Distutils compiles and links it without me caring how.

Post by Mike Frysinger
hmm, what version of binutils does your Redhat 9 box have ?

2.13.90.0.18

Post by Mike Frysinger
see if the version of ld on it supports exec stack markings

It doesn't.

Post by Mike Frysinger
i maintain netpbm and make sure that it stays up-to-date ...
so the proposed idea seems like it'll work just dandy

It won't unless whoever provides the bitpim ebuild makes it
remove those binaries before the install phase. I haven't
seen anyone commit to keeping that up to date. (The only
thing needed is to bump the version every 3 weeks and
remove ~x86)

I can make the code look for /etc/gentoo release and then
use the system netpbm. However that will still cause the
QA whining message on install and doesn't really improve
things (the binaries we ship run fine, the images are
small).

My other suggestion was a seperate package (eg gentoo-rpm)
that will install an rpm and keep the contents known to
portage synthesizing the existence of an ebuild. I am
happy to then put scripts into the rpm that tool could read.
For example the scripts would remove the netpbm binaries
we supply.

Roger

Mike Frysinger

2006-03-04 06:13:19 UTC

Post by Mike Frysinger
i wont address this because i have no idea what bitpim is

http://www.bitpim.org :-)

it doesnt support sony ericsson phones does it ? ive got a T226 that supports
like OBEX or something ... never really looked into it, just refuse to pay
retarded fees for simple crap i can d/l off the internet

Post by Mike Frysinger
let alone try and take over maintenance for it :)

The problem isn't really with BitPim. Gentoo doesn't currently
handle a package that updates as quickly as BitPim does

right ... i wasnt trying to imply that the trouble rested anywhere else than
over here in Gentoo Land ...

Post by Mike Frysinger
this fix is simple ... just change build.sh to pass -fPIC to gcc

Done.

thanks

Post by Alin Nastac
TEXTREL usr/lib/bitpim-0.8.08/apsw.so

hmm, i'll have to do some research to figure out what's wrong with this,
but i would guess that it's as simple as the fix for libusb.so ...

This is built as a Python extension. Python has something called
distutils which hides how programs are built on the platform. I
<snip>
Distutils compiles and links it without me caring how.

odd ... downloading the apsw source zip (apsw-3.2.7-r1.zip) and proceeding to
run `python setup.py build` produces a proper apsw.so for me ... you say
you're building this on the Redhat 9 box ? wonder if the distutils that you
have installed on there are outdated and dont build proper shared objects
with -fPIC ...

Post by Mike Frysinger
hmm, what version of binutils does your Redhat 9 box have ?

2.13.90.0.18

Post by Mike Frysinger
see if the version of ld on it supports exec stack markings

It doesn't.

fun ! i'll have to ponder hard on this one ... is there no package which
provides the `bmp2avi` util ?

Post by Mike Frysinger
i maintain netpbm and make sure that it stays up-to-date ...
so the proposed idea seems like it'll work just dandy

It won't unless whoever provides the bitpim ebuild makes it
remove those binaries before the install phase.

this shouldnt be a problem

Post by Roger Binns
I can make the code look for /etc/gentoo release and then
use the system netpbm. However that will still cause the
QA whining message on install and doesn't really improve
things (the binaries we ship run fine, the images are
small).

right; typically the issues we're raising here do not affect the day-to-day
usuability of applications one way or the other ... we're just being
pessimistic and trying to cover the extraneous cases

Post by Roger Binns
My other suggestion was a seperate package (eg gentoo-rpm)
that will install an rpm and keep the contents known to
portage synthesizing the existence of an ebuild. I am
happy to then put scripts into the rpm that tool could read.
For example the scripts would remove the netpbm binaries
we supply.

an interesting concept ... and i doubt the basic implementation would present
too much trouble ... simply unpacking an rpm, inserting relevant portage
information, and not worrying about crap like dependencies ...
-mike

Roger Binns

2006-03-04 06:54:14 UTC

Post by Mike Frysinger
it doesnt support sony ericsson phones does it ?

Nope.

Post by Mike Frysinger
ive got a T226 that supports like OBEX or something

OBEX is actually a standard, although you'll find quirks
with each model. If the phone supports SyncML (higher
numbered models do) then you are in luck:

http://multisync.sourceforge.net/news.php

All it takes to get your phone supported in BitPim is someone with
the phone and some time.

Post by Mike Frysinger
odd ... downloading the apsw source zip (apsw-3.2.7-r1.zip) and proceeding to
run `python setup.py build` produces a proper apsw.so for me ... you say
you're building this on the Redhat 9 box ? wonder if the distutils that you
have installed on there are outdated and dont build proper shared objects
with -fPIC ...

That would likely be the case.

Post by Mike Frysinger
fun ! i'll have to ponder hard on this one ... is there no package which
provides the `bmp2avi` util ?

That is in the bitpim code.
http://svn.sf.net/viewcvs.cgi/bitpim/trunk/bitpim/src/native/av/bmp2avi/

It just uses g++ -o foo foo.o (on Redhat 9).

Post by Roger Binns
My other suggestion was a seperate package (eg gentoo-rpm)

The existing BitPim ebuild does exactly that! It inherits rpm.eclass
which basically unpacks the rpm into the source directory (using
rpm2cpio). The trick is to then get the files into the installed
packages list. Have a look at app-portage/g-cpan
What it does is creates a new ebuild on the fly. It is overengineered
for our purposes since it also creates dependent CPAN module ebuilds
and a whole bunch of other crud. If someone wants to write a
tool like this then I am prepared to help (primarily with testing).

Rant mode on: For some bizarre reason, none of the various Linux
packaging systems provide a binary that can be run that lets
you add a file to the installed files database. This makes it
impossible for post install scripts to adjust to the installed
system. For example you can't do this:

if .... some random condition ...
then
add-to-filedatabase MyPackageName /etc/foo.conf
else
add-to-filedatabase MyPackageName /var/etc/foo.conf
fi

The SVR4 packaging system has had this for years. The command name
is installf:

http://docs.sun.com/app/docs/doc/806-0625/6j9vfiloh?a=view

If something like this existed, it would make the tool we
are talking about trivial. Expand the rpm and then run
installf with the relevant files. Instead you have to go
through hoops making dummy ebuilds.

RPM doesn't this kind of command either. It would have been a
great help when I used to supply man pages with earlier software
I did. No two systems could decide if man pages were gzipped or
bzipped, or where they lived. Consequently the postinstall
could easily have compressed them the right way and put them in
the right directory for that system.

Here is another good example usage:

http://www.redhat.com/archives/rpm-list/2001-November/msg00308.html

Roger

Mike Frysinger

2006-03-04 08:24:46 UTC

Post by Mike Frysinger
odd ... downloading the apsw source zip (apsw-3.2.7-r1.zip) and
proceeding to run `python setup.py build` produces a proper apsw.so for
me ... you say you're building this on the Redhat 9 box ? wonder if the
distutils that you have installed on there are outdated and dont build
proper shared objects with -fPIC ...

That would likely be the case.

is apsw required to be bundled ? i'm wondering if i add a quick ebuild for
apsw to portage, if we can get bitpim to use that ... doesnt seem like you do
apsw releases nearly as often as bitpim, so i could just add myself to the
notify in the sf release page for it ...

Post by Mike Frysinger
fun ! i'll have to ponder hard on this one ... is there no package which
provides the `bmp2avi` util ?

That is in the bitpim code.
http://svn.sf.net/viewcvs.cgi/bitpim/trunk/bitpim/src/native/av/bmp2avi/
It just uses g++ -o foo foo.o (on Redhat 9).

so we're back to square one ...

Post by Roger Binns
My other suggestion was a seperate package (eg gentoo-rpm)

an interesting concept ... and i doubt the basic implementation would
present too much trouble ... simply unpacking an rpm, inserting relevant
portage information, and not worrying about crap like dependencies ...

mmm we're not quite on the samepage here ... i was thinking of a tool where
you feed it an rpm and it'll basically convert it on the fly and treat it
like a binary Gentoo package ... no random ebuild needed in a portdir overlay
if done right ...

Post by Roger Binns
Rant mode on: For some bizarre reason, none of the various Linux
packaging systems provide a binary that can be run that lets
you add a file to the installed files database. This makes it
impossible for post install scripts to adjust to the installed

that's what happens when no standard exists for how things should be done ...
every distro has a "better" idea than the next as to how to manage packages

Post by Roger Binns
if .... some random condition ...
then
add-to-filedatabase MyPackageName /etc/foo.conf
else
add-to-filedatabase MyPackageName /var/etc/foo.conf
fi

being a general noob, i really have no idea what installf does ...
consequently, i'm not sure what you're going for here :)
-mike

Roger Binns

2006-03-04 22:30:41 UTC

Post by Mike Frysinger
is apsw required to be bundled ?

It needs to exist is all.

Post by Mike Frysinger
i'm wondering if i add a quick ebuild for apsw to portage, if we can
get bitpim to use that

It is a standard Python package. It does have a dependency on SQLite.
Unfortunately SQLite is yet another one of those poorly maintained
packages. The most recent revision not marked ~x86 is 3.2.1-r3
and dates from almost a year ago. It is fortunately trivial
to make apsw use a private copy of SQLite. That will be desireable when
apsw is being used by BitPim. It won't be when other people use
it though since they will expect the system one to be used.

(The issue here is that SQLite 3.3 changed the file format. If
it is just used then people will unexpectedly find problems
if they rollback to earlier versions or on another machine.
I will be adding the pragma to BitPim code at some point to
keep to the old format. At that point BitPim will no longer
about the SQLite version as much.)

Post by Mike Frysinger
... doesnt seem like you do apsw releases nearly as often as bitpim,

Correct. They only need to be done when the SQLite C api changes.

Post by Mike Frysinger
mmm we're not quite on the samepage here ... i was thinking of a tool where
you feed it an rpm and it'll basically convert it on the fly and treat it
like a binary Gentoo package ... no random ebuild needed in a portdir overlay
if done right ...

We are on the same page! I have never dealt with the binary packages
so I don't know how that is all done. That is an even better way
of doing it.

Post by Mike Frysinger
that's what happens when no standard exists for how things should be done ...
every distro has a "better" idea than the next as to how to manage packages

Ultimately they all boil down to the same thing. Some sort
of archive (cpio, zip etc), metadata (versions, authors)
and a system database of installed files and which packages
they belong to. My rant is that none of the ones on Linux
let you update the system database without a full package
install. Even the SVR4 one does.

Roger

Stephen Wood

2006-03-04 13:45:59 UTC

Post by Mike Frysinger
i maintain netpbm and make sure that it stays up-to-date ...
so the proposed idea seems like it'll work just dandy

It won't unless whoever provides the bitpim ebuild makes it
remove those binaries before the install phase.

this shouldnt be a problem

There was a reason why we put in such old netpbm binaries, which I forget.
It might have been the size of the files, or just being able to find
binaries for WIndows, Mac, Linux. I'll look at this again, and check
wxPython perhaps has the capability that we need yet.

Stephen

--
Stephen Wood

One of the "Steves" of Project Steve at http://www.ncseweb.org/.

Roger Binns

2006-03-04 20:57:03 UTC