Bugzilla Bug 136953

As subject says, gnupg-1.4.3-r1 brings a QA-message, it needs in some way
linguas_ru added to IUSE.

If this is the only lang supported, you'd probably just add it, if there are
more to come, it should likely look like kde-i18n or similar.

Erm, while at it... :P

app-accessibility/festival - all versions
app-accessibility/mbrola-3.0.1h-r{3,4}
app-office/openoffice - all versions
app-office/openoffice-bin - all versions
app-text/acroread-7.0.5-r{2,3}
app-text/bibletime - all versions
app-crypt/gnupg-1.4.3-r1
app-vim/cream - all versions
dev-util/eric - all versions
kde-misc/pwmanager - all versions
net-im/psi - all versions
media-fonts/acroread-asianfonts - all versions
sys-apps/man-pages-2.{32,33}
www-client/mozilla-firefox-1.5.0.4
www-client/mozilla-firefox--bin-1.5.0.4

pwmanager done.

app-accessibility/mbrola and app-accessibility/festival done

for app-text/bibletime,
IUSE.invalid                   9
   app-text/bibletime/bibletime-1.5.2.ebuild: linguas_nn_NO
   app-text/bibletime/bibletime-1.5.2.ebuild: linguas_no
   app-text/bibletime/bibletime-1.5.2.ebuild: linguas_ua
   app-text/bibletime/bibletime-1.6_beta2.ebuild: linguas_nn_NO
   app-text/bibletime/bibletime-1.6_beta2.ebuild: linguas_no
   app-text/bibletime/bibletime-1.6_beta2.ebuild: linguas_ua
   app-text/bibletime/bibletime-1.5.3.ebuild: linguas_nn_NO
   app-text/bibletime/bibletime-1.5.3.ebuild: linguas_no
   app-text/bibletime/bibletime-1.5.3.ebuild: linguas_ua

Do these just need to go into use.local.desc, or is there a different protocol
for adding the linguas flags to use.desc?

(In reply to comment #3)
> Do these just need to go into use.local.desc, or is there a different protocol
> for adding the linguas flags to use.desc?

AFAIK, profiles/desc/linguas.desc 

While going through profiles/desc/linguas.desc to add a few more LINGUAS
entries which we use in OpenOffice.org, I noted that a few entries there seem
to be wrong, they are:

be > be_BY
hi > hi_IN
pa > pa_IN
sr > sr_CS
ta > ta_IN

this means, according to unicode.org, there is no be-language just a be_BY, the
same with the other ones. As OOo uses all of the correct ones I ask myself what
the best way to solve this is here. I guess other ebuilds are using the "wrong"
ones, so should I just add "be_BY" next to "be" (with the same description) or
should we solve that another way?

*** Bug 138328 has been marked as a duplicate of this bug. ***

Could someone please comment to my last statement, I really don't know how to
handle this situation properly.

(In reply to comment #7)
> Could someone please comment to my last statement, I really don't know how to
> handle this situation properly.
> 

So if nobody wants to comment, I'll go ahead and just add the
openoffice-entries besides the old ones, no "clean" solution, but better than
nothing, I guess

Ok, have added the linugas in question, nothing to do for us here anymore, so
removing myself from the cc-list

www-client/mozilla-firefox{,-bin}, app-crypt/gnupg and the acroread stuff done.

*** Bug 141157 has been marked as a duplicate of this bug. ***

From bug #141157: sys-apps/man-pages

What's left:

app-text/bibletime - all versions
app-vim/cream - all versions
dev-util/eric - all versions
net-im/psi - all versions
sys-apps/man-pages - all versions

Cream should be fixed now thanks to Mark Loeser.

*** Bug 148866 has been marked as a duplicate of this bug. ***

*** Bug 148867 has been marked as a duplicate of this bug. ***

Hi!

Psi is fixed in CVS.

Regards,
Przemek

I still don't know what linguas to go with. Some packages has only sv (like
gtk+-1.*), some packages has only sv_SE (like firefox has have from time to
time). profiles/lang.desc only has sv listed, but still.
Why do not try for a unification here or at least go for a system which does
not leave out one or the other of them?

What's left:

app-text/bibletime - all versions
dev-util/eric - all versions
sys-apps/man-pages - all versions

app-text/bibletime - fixed

from bug #163835

sys-apps/man - all versions

app-portage/esearch

esearch fixed.

(In reply to comment #21)
> sys-apps/man - all versions

Nothing else left.

*** This bug has been marked as a duplicate of bug 133327 ***

*** Bug 205921 has been marked as a duplicate of this bug. ***

(In reply to comment #25)
> *** This bug has been marked as a duplicate of bug 133327 ***

Erm... this actually breaks dependencies for sys-apps/man-pages because the
stuff in PDEPEND will get depcleaned. Needs to get fixed.

i agree, the package manager needs to get fixed

*** This bug has been marked as a duplicate of bug 133327 ***

(In reply to comment #28)
> i agree, the package manager needs to get fixed

The package manager is not broken in any way here wrt Comment #27. You are
stating dependencies for undeclared USE flags.

implicit/automatic flags should be handled implicitly/automatically for the
package manager.  this is the only long term solution for keeping maintenance
burden down.

*** Bug 211554 has been marked as a duplicate of this bug. ***

(In reply to comment #30)
> implicit/automatic flags should be handled implicitly/automatically for the
> package manager.  this is the only long term solution for keeping maintenance
> burden down.

The meanings of "implicit" and "automatic" in that statement seem kind of
vague, and we're going to have to get more specific when it comes to solutions.

By "automatic" I guess you're referring to bug 133327 or something similar?

Flags considered as "implicit" members IUSE in portage-2.1.4:

 * Flags derived from ARCH
 * Flags derived from USE_EXPAND_HIDDEN variables
 * Masked flags, such as those from {,package}use.mask
 * Forced flags, such as those from {,package}use.force
 * build and bootstrap flags used by bootstrap.sh

These flags are exempt from being filtered and they are also exempt from the QA
notice that's embedded inside useq().