Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

This version was the last based on a binary rpm and has obsolete dependencies:
   =x11-libs/gtk+-2.8.8

The new versions are build from source (a figure of speach since most of source
tarball is composed from python source files and images), but have an unsolved
problem described in bug #130914. The issue is minor, but it blocks other
versions to reach stable status.

I want to remove bitpim-0.8.08 from the tree even though is the latest x86
ebuild and I want your approval (you == x86 herd).
If I don't hear anything from you for about a week, I will consider the silence
as agreement.

Does this version work?  Do new versions work?  We should have a new version to
go stable before you pull the only stable version of this package.

I have positive feedback from users. In fact, this convinced me not to drop the
package (is a pita to maintain it). 

I suspect all its users selected ~arch in their package.keywords - either that
or they've masked >=x11-libs/gtk+-2.8.8 which is very unlikely. Therefore, I
think removal of the latest stable version will be of no consequence.

(In reply to comment #2)
> I have positive feedback from users. In fact, this convinced me not to drop the
> package (is a pita to maintain it). 
> 
> I suspect all its users selected ~arch in their package.keywords - either that
> or they've masked >=x11-libs/gtk+-2.8.8 which is very unlikely. Therefore, I
> think removal of the latest stable version will be of no consequence.
> 

This still has not answered my question.  Does the new version work?  Does the
current stable version work?  Why are we just pulling one version without
trying to replace it?  What is the rush to drop it all of a sudden if the
current stable version somewhat works?

(In reply to comment #3)
> This still has not answered my question.  Does the new version work?  Does the
> current stable version work? 

Let me rephrase: I have positive feedback (as in "known to work") from users
regarding version 0.8.08 (old version) and 0.8.13 (new version).

> Why are we just pulling one version without
> trying to replace it?  What is the rush to drop it all of a sudden if the
> current stable version somewhat works?

Because of the =x11-libs/gtk+-2.8.8 dependency. It may work but at what costs?
Sorry, but I just don't see users rushing to downgrade their Gnome for that.
Isn't it obvious?

(In reply to comment #4)
> (In reply to comment #3)
> > This still has not answered my question.  Does the new version work?  Does the
> > current stable version work? 
> 
> Let me rephrase: I have positive feedback (as in "known to work") from users
> regarding version 0.8.08 (old version) and 0.8.13 (new version).

Awesome, thanks.


> > Why are we just pulling one version without
> > trying to replace it?  What is the rush to drop it all of a sudden if the
> > current stable version somewhat works?
> 
> Because of the =x11-libs/gtk+-2.8.8 dependency. It may work but at what costs?
> Sorry, but I just don't see users rushing to downgrade their Gnome for that.
> Isn't it obvious?
> 

Sorry, but it isn't obvious :)  If the new version works a lot better than the
current stable version, mark that one stable.  It may have an open bug, but it
sounds like that bug was already present, and the new version solves other
problems.  I don't like pulling the only stable version when we have another
alternative.

The problem is new version depends on many ~x86 keyworded packages:
 >=dev-python/paramiko-1.5.4
 >=dev-python/python-dsv-1.4.0
 >=dev-python/wxpython-2.6.3.2
Stabilizing first 2 will be easy, but the last one could be PITA (it has an
avalanche effect).

Aye, wxpython has a avalanche effect. However, its something we need to take
care of. I'm attaching python to this to get their opinion about the status of
wxpython at or beyond 2.6.3.2. As both members of the wxwindows herd are
currently away.

Python please advise about the status of wxpython.

Adding a note that having talked with lilo (upstream) about this issue that
after GUADAC a new version of wx* will be coming out. I'm of the opinion to
wait for this now as there are a large ammount of fixes to it that are
currently in the 2.6.3.2.

More a note for myself then anything.

(In reply to comment #4)
> (In reply to comment #3)
> > This still has not answered my question.  Does the new version work?  Does the
> > current stable version work? 
> 
> Let me rephrase: I have positive feedback (as in "known to work") from users
> regarding version 0.8.08 (old version) and 0.8.13 (new version).
> 
> > Why are we just pulling one version without
> > trying to replace it?  What is the rush to drop it all of a sudden if the
> > current stable version somewhat works?
> 
> Because of the =x11-libs/gtk+-2.8.8 dependency. It may work but at what costs?
> Sorry, but I just don't see users rushing to downgrade their Gnome for that.
> Isn't it obvious?

It's not even a downgrade, it's worse than that: I know of one person who has
this application installed, and this dependancy causes their gtk version to
flip back and forth between latest and 2.8.8.  Most recently, an emerge of
world wanted to install two different versions at once.

This is really broken.  How about just coming up with a -p1 version that has
>=x11-libs/gtk+-2.8.8 instead.

(In reply to comment #9)
> This is really broken.  How about just coming up with a -p1 version that has
> >=x11-libs/gtk+-2.8.8 instead.

It cannot work with >x11-libs/gtk+-2.8.8.

For the sake of clarity, I'm going to summarize the current situation:

There are two relevant bitpim versions available, 0.8.08 and 0.8.13.

bitpim is stable at 0.8.08.  However, 0.8.08 requires =gtk+-2.8.8, which is a
downgrade from the current gtk+.  It is only known to work with this version.

There are reports bitpim is stable at 0.8.13.  However, 0.8.13 requires, among
other things, >=dev-python/wxpython-2.6.3.2, which is masked and has many
effects.

The resulting problem is that both bitpim versions depend on undesirable
components.  Anyone installing the unmasked bitpim will downgrade their gtk+.

The proposed solution is to mask the one stable version of bitpim, so that
users don't unnecessarily downgrade gtk+ or constantly flip between versions
because of different build requirements.

Well, I wanted to remove bitpim-0.8.08 from the tree, but Mark used his veto
right.
I'm tired to argue with other devs so I leave x86 team to decide what needs to
be done.

(In reply to comment #10)

> It cannot work with >x11-libs/gtk+-2.8.8.

it also doesn't work with expat-2.0.0, and if it did it would just fail with
something else.

# ldd ~/portage/bitpim-0.8.08/work/usr/lib/bitpim-0.8.08/* | grep "not found"
        libdb-4.0.so => not found
        libssl.so.4 => not found
        libcrypto.so.4 => not found
        libexpat.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libreadline.so.4 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud_gizmos-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found
        libwx_gtk2ud_stc-2.6.so.0 => not found
        libwx_gtk2ud-2.6.so.0 => not found


> Well, I wanted to remove bitpim-0.8.08 from the tree, but Mark used his veto
right.

Veto right?  You asked. ;)

I know it sucks to leave stable without an ebuild, but there's no way this can
stay in.

There is 0.9.05 out since 2006-07-16, does that solve anything wrt this bug?

Sorry, but you can't have a stable ebuild that depends on ebuild that is gone.
Remove this and stabilize something else - or don't stabilize, but this needs
to go :)

app-mobilephone/bitpim-0.8.08: rdepends  x86: unsolvable
default-linux/x86/no-nptl/2.4, solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends  x86: unsolvable
default-linux/x86/2006.1, solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends  x86: unsolvable
default-linux/x86/2006.1/desktop, solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends  x86: unsolvable
default-linux/x86/no-nptl, solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends  x86: unsolvable hardened/x86/2.6,
solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends  x86: unsolvable hardened/x86,
solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends ~amd64: unsolvable
default-linux/amd64/2006.1, solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends ~amd64: unsolvable
default-linux/amd64/2006.1/desktop, solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends ~amd64: unsolvable
default-linux/amd64/2006.0/no-symlinks, solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends ~amd64: unsolvable
hardened/amd64/multilib, solutions: [ =x11-libs/gtk+-2.8.8* ]
app-mobilephone/bitpim-0.8.08: rdepends ~amd64: unsolvable hardened/amd64,
solutions: [ =x11-libs/gtk+-2.8.8* ]

Since the gtk+ version no longer exists in portage, I've removed bitpim-0.8.08
from the tree.

Also, I've bumped the version to 0.9.07, which appears to solve bug #130914.

Hmmm... I'd already put gtk+-2.8.8 back.  If removing this is the final
decision, I'll take it back out again, but I have no objection to leaving it
until some other version goes stable.

bitpim-0.9.07 seems to be stable (all known bug have been fixed).
the only thing that keeps it from being marked as such is the fact that
dependencies aren't stable yet (this and the fact that it didn't passed the
trial period of one month yet).

I'm against revival of bitpim-0.8.08. my reasons are exposed in comment #2 and
comment #4.