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