When I start pppconfig I get: "/etc/ppp/peers doesn't exist" and it quits. Also, if there is no "pap-secrets" file, it complains and quits with message: Can't open /etc/ppp/pap-secrets pppconfig archive contains translation files (po files). Updated ebuild make use of them. Added nls into IUSE. Note: I am not aware of "localesdir" env. variable that we can replace hardcoded /usr/share/locale path?
Created attachment 60814 [details] updated pppconfig-2.3.11 ebuild This fixes three issues I noticed and explained above
Created attachment 60878 [details] Latest updated ebuild Found "touch" command makes /etc/ppp/pap-secrets world readable (644). Added fperms line to fix this behavior. Thanks goes to Jeffrey0 at #gentoo-bugs for pointing this out.
first 2 issues aren't pppconfig's problems. I've fixed those in ppp-2.4.2-r12 and ppp-2.4.3-r6. the last problem had been fixed in pppconfig-2.3.11-r1. thanks for your contribution.
Created attachment 67716 [details] revision bump Alin, - You use MY_LOCALE_LANGUAGES in src_compile() and src_install() butthat variable is not exported from src_unpack(). - pppconfig package need to depend on gettext with or without nls USE flag cause it is bundled with translation files that need to be converted to binary .mo files and this is done by msgfmt that is part of gettext. Do we really need nls use flag here? Translation files for GNOME are installed when we have -nls. Also, seems nls use flag is not for all this and it is used for other purposes. So, my wrong when suggesting introducing it. Ssl
Reopening bug
(In reply to comment #4) > Created an attachment (id=67716) [edit] > revision bump > > Alin, > > - You use MY_LOCALE_LANGUAGES in src_compile() and src_install() butthat > variable is not exported from src_unpack(). doesn't need to be exported. as far as I know, both functions are executed by the same bash process. > > - pppconfig package need to depend on gettext with or without nls USE flag > cause it is bundled with translation files that need to be converted to > binary .mo files and this is done by msgfmt that is part of gettext. Do we where exactly did you saw msgfmt used besides the case nls flag is set? > really need nls use flag here? Translation files for GNOME are installed when > > we have -nls. Also, seems nls use flag is not for all this and it is used for > > other purposes. So, my wrong when suggesting introducing it. I quote: nls - Adds Native Language Support (using gettext - GNU locale utilities) seems to me this is *exactly* for this kind of files (namely *.mo files). the fact that GNOME herd chooses to ignore such flag (or maybe they don't have --enable-nls in their config) isn't a reason to remove such functionality from pppconfig, isn't it?
> > - You use MY_LOCALE_LANGUAGES in src_compile() and src_install() butthat > > variable is not exported from src_unpack(). > > doesn't need to be exported. as far as I know, both functions are executed by > the same bash process. I thought so, too -- it is the same bash process. Actually when preparing ebuild for #71179 I remembered your solution for handling LINGUAS and tried to apply the same. But it didn't work. Have you tried to put LINGUAS="es de" into /etc/make.conf for pppconfig? Result: no one locale will be installed. > > > > > - pppconfig package need to depend on gettext with or without nls USE flag > > cause it is bundled with translation files that need to be converted to > > binary .mo files and this is done by msgfmt that is part of gettext. Do we > > where exactly did you saw msgfmt used besides the case nls flag is set? Nowhere, you are right. It is just I believe installing locale files should be handled by LINGUAS variable that users put into /etc/make.conf. If there is no LINGUAS set, then install all locale. In both cases we need gettext as clear dep. However it is just my opinion. > I quote: nls - Adds Native Language Support (using gettext - GNU locale utilities) > seems to me this is *exactly* for this kind of files (namely *.mo files). > > the fact that GNOME herd chooses to ignore such flag (or maybe they don't have > --enable-nls in their config) isn't a reason to remove such functionality from > pppconfig, isn't it? Sorry, I am not familiar enough with what --enable-nls do and how it is handled inside gentoo so can't comment.
I've verified with LINGUAS="en ro" (en does not exist in this package, only ro gets installed). as for nls flag... this is a super flag sort of speak. if it isn't set, it will not install mo files at all. LINGUAS decides what mo files are installed and if nls is set and LINGUAS is unset/empty, all mo files are installed. really, I don't see why you reopened this bug, but I will publish a new revision of pppconfig that use eutils.eclass for stripping unsupported languages, which seems to be the right thing to do at the moment.
you're right! I've re-tested the ebuild and see with my own eyes ( portage ver is 2.0.51.22-r2 and bash ver is 3.0-r12). Apparently, global variables defined in src_unpack (or any other function for that matter) will be empty in subsequent functions.
forgot to mention... I've fixed the problem in net-dialup/pppconfig-2.3.11-r2 by moving all locale messages code in src_install. also, I've removed -r1 from the tree.
