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.
