Re: [gentoo-dev] confusing ppp/rp-pppoe setup
Sven Köhler wrote: >at the moment, /usr/lib/pppd/2.4.2/rp-pppoe.so is installed by >net-dialup/ppp - nothing special - well, it's not a very recent version. >In the syslog it says: > >RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2 > >On the other hand, i've got net-dialup/rp-pppoe-3.8 installed and it >installs a symlink: > >/etc/ppp/plugins/rp-pppoe.so -> /usr/lib/pppd/2.4.2/rp-pppoe.so > >Is this symlink needed? And why is it installed by rp-pppoe? >(And is the /etc/ppp/plugins dir needed at all? What do plugins do in >/etc/ppp/plugins? Don't they belong to /usr/lib/pppd/2.4.2/ ?) > > That is the place where pppoe-server search for the plugin. Btw, the PPPoE server is the only useful part of net-dialup/rp-pppoe from Gentoo pov, the client part being surclassed by the generic pppd.sh net module available in baselayout-1.12*. > >Well, yet another question: >ppp-2.4.2 now includes the rp-pppoe.so plugins from rp-pppoe - do the >ppp-people maintain that module by themselfs now? Or do they just >download the plugin from the rp-pppoe-people and include it in their >sources? I can imagine a ppp-ebuild that downloads a more recent version >of rp-pppoe and builds the rp-pppoe.so-plugins directly from the >rp-pppoe sources instead of using the ppp-sources. > > rp-pppoe plugin had been within ppp tarball for quite some time (see for how long from upstream cvsweb at http://cvs.samba.org/cgi-bin/cvsweb/ppp/pppd/plugins/rp-pppoe/). It has been contributed by RoaringPenguin but from that day on, it has been maintained by Paul MacKerras (the ppp upstream). Maybe is just me, but I consider ppp to be the upstream when it comes to rp-pppoe pppd's plugin. I don't care that 3.3 < 3.8 since the actual rp-pppoe plugin is a modified version of the one original. Unless someone finds a bug or a new feature that needs to be implemented in rp-pppoe plugin (which I very much doubt it), I will change nothing (and even then, I will prefer to patch the ppp sources). signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: confusing ppp/rp-pppoe setup
>> /etc/ppp/plugins/rp-pppoe.so -> /usr/lib/pppd/2.4.2/rp-pppoe.so >> >> Is this symlink needed? And why is it installed by rp-pppoe? >> (And is the /etc/ppp/plugins dir needed at all? What do plugins do in >> /etc/ppp/plugins? Don't they belong to /usr/lib/pppd/2.4.2/ ?) > > That is the place where pppoe-server search for the plugin. *grmpf* silly pppoe-server :-( > Btw, the PPPoE server is the only useful part of net-dialup/rp-pppoe > from Gentoo pov, the client part being surclassed by the generic pppd.sh > net module available in baselayout-1.12*. Using it right now. Works very nice! > rp-pppoe plugin had been within ppp tarball for quite some time (see for > how long from upstream cvsweb at > http://cvs.samba.org/cgi-bin/cvsweb/ppp/pppd/plugins/rp-pppoe/). > It has been contributed by RoaringPenguin but from that day on, it has > been maintained by Paul MacKerras (the ppp upstream). > Maybe is just me, but I consider ppp to be the upstream when it comes to > rp-pppoe pppd's plugin. OK, so i'm a little bit scared, that it's maintained by two parties now. The plugin.c from rp-pppoe 3.8 differs slightly from the plugins.c included in ppp 2.4.2. Didn't check the plugin.c of ppp 2.4.3 yet. So as long as i don't experience any bugs, it will stick with the one included in ppp 2.4.2 signature.asc Description: OpenPGP digital signature
[gentoo-dev] net-analyzer/acid users: please migrate to net-analyzer/base
Hello there, net-analyzer/base is a web front-end for the net-analyzer/snort IDS. It is actively maintained and based on net-analyzer/acid, whose last release is from 2003. For this reason, migration from ACID to BASE is recommended. There is a guide [0] in the forums that you may find useful. There is one bug [1] related to ACID and old php ebuilds, but acid-0.9.6_beta23-r1.ebuild should work ok nonetheless, in case you want to try it. I just added net-analyzer/acid to package.mask and I intend to remove it in a month or so if nobody complains. Cheers, Marcelo [0]: http://forums.gentoo.org/viewtopic-t-399801.html [1]: http://bugs.gentoo.org/show_bug.cgi?id=130980 -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] mozilla herd needs you!!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you are a dev and would like to help with mozilla herd please step up and help in maintaining mozilla/seamonkey/thunderbird/enigmail and all other ebuilds owned by the herd. If your not a dev and would like to help out find me, you might be a canadite for recruitment, or you could assist by sending me your work for review and to have it commited if all is well. At present I am the only *active* dev in the herd and have to say doing all the security bumps is taking its toll on me. If interested reply to list or email me directly for more details. Thanks Jory -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFES87bGDfjNg8unQIRAivWAJ0Ul+ymkQ14U+VJx0qQBGHhoCiblwCgoto0 9wuEo6rj9HvDb1Y4YiGOnaQ= =0/TG -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 14970 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 218 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Proposal v3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Loeser wrote: > Here is the newest revision of my proposal. Not much has changed, but I > added and changed some small things. Constructive feedback is > appreciated. I'd like to get this voted on by the council at the next > meeting. > > * The QA team's purpose is to provide cross-team assistance in keeping > the tree in a good state. This is done primarily by finding and pointing > out issues to maintainers and, where necessary, taking direct action. describe what makes it necessary and what actions will be taken or if the paragraphs below are meant to do that, you can save that line in that paragraph > * In case of emergency, or if package maintainers refuse to cooperate, > the QA team may take action themselves to fix the problem. The QA > team does not want to override the maintainer's wishes by default, but only > wish to do so when the team finds it is in the best interest of users > and fellow developers to have the issue addressed as soon as possible. define emergency, define as soon as possible (some bugs might be quite tricky to track and might be put on back burner and what little time is available used on things not taking up equal times), how do you know ia dev is not cooperating or if i he/she is just prioritizing > * The QA team may also offer to fix obvious typos and similar minor > issues, and silence from the package maintainers can be taken as agreement > in such situations. Coding style issues fall under this category, and > while they are not severe, they can make automated checks of the tree more > difficult. thanks for the offer, sounds good > * There will be cases when our tools are incapable of handling a certain > situation and policy must be broken in order to get something working > completely. This will hopefully not occur very often but each time it > does occur, the QA team and the maintainer will come to some agreement > on an interim solution and it is expected that a bug will be opened with > the appropriate team to work towards a correct solution. sounds reasonable > * In the case of disagreement on policy among QA members, the majority > of established QA members must agree with the action. you shouldn't disagree about this policy, or you might as well not have this document, write disagree on the solution maybe? > * In the event that a developer still insists that a package does not > break QA standards, an appeal can be made at the next council meeting. The > package should be dealt with per QA's request until such a time that a > decision is made by the council. The default could be that the ebuild not be touched unless it is a issue that breaks the tree or is security related where time is of the essence. word it in that direction? > * Just because a particular QA violation has yet to cause an issue does > not change the fact that it is still a QA violation. Then you must be talking about coding style here? remove the point and add it above to coding style, as an example why you will deal with the coding style maybe? no other violation should be left to such vagueness > * If a particular developer persistently causes breakage, the QA team > may request that devrel re-evaluates that developer's commit rights. > Evidence of past breakages will be presented with this request to > devrel. define persistently, how do you presistently cause breakage? maybe this is one of those non native english speaker moments, but doesn't that mean like every commit is botched? > * The QA team will maintain a list of current "QA Standards" with > explanations as to why they are problems, and how to fix the problem. > The list is not meant by any means to be a comprehensive document, but > rather a dynamic document that will be updated as new problems are > discovered. The QA team will also do their best to ensure all developer > tools are in line with the current QA standards. as said in the other two posts, maybe write it is a comprehensive list, just that it is not finite? that might clear this point up. > * In order to join the QA team, you must be a developer for at least 4 > months and must ask the current lead for approval. that shouldn't be too hard > * The QA team will work with Recruiters to keep related documentation > and quizzes up to date, so that up and coming developers will have access > to all of the necessary information to avoid past problems. sounds good > * QA will take an active role in cleaning up unmaintained and broken > packages from the tree. It is also encouraged of members of the QA team to > assist in mentoring new developers that wish to take over unmaintained > packages/herds. > > i am not sure how to read this one, it could mean broken packages that are unmaintained, but how it is written it could also mean unmaintained || broken, not only unmaintained && broken, i really wish you would at least consi
Re: [gentoo-dev] QA Proposal v3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> * If a particular developer persistently causes breakage, the QA team >>> may request that devrel re-evaluates that developer's commit rights. >>> Evidence of past breakages will be presented with this request to >>> devrel. > > define persistently, how do you presistently cause breakage? maybe this > is one of those non native english speaker moments, but doesn't that > mean like every commit is botched? > defining 'breakage' here might also be a good idea, sorry for not adding this to the previous post, i really should have asked for that one Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETFpo/aM9DdBw91cRAsBvAKDABphEPy1zWVGaHqqZ8JhBYvOTEgCeNa5B mwUCZpBBis2TnK3gyejjn9Q= =/ig2 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: QA Proposal v3
Daniel Goller posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 23 Apr 2006 23:50:17 -0500: >> * In the case of disagreement on policy among QA members, the majority >> of established QA members must agree with the action. > > you shouldn't disagree about this policy, or you might as well not have > this document, write disagree on the solution maybe? Don't take this wrong but you did mention you weren't a native English speaker, and I think this the interpretation demonstrates that. (That isn't to say it couldn't be made clearer, just that your interpretation isn't likely to occur to a native English speaker, thus the discussion.) To me (as a native English speaker), it's strange to consider that a reference to /this/ policy. Rather, the reference is to QA policy and decision making in general -- how a disagreement on QA policy between members of the QA team is to be handled. That this is the case would be particularly obvious in context, coming after (as it does) the previous point, dealing with exceptions due to imperfect tools and mentioning that there /are/ such exceptions. The point in question above doesn't /only/ deal with that, thus it's its own bullet point, but the thought is clearly to provide some guidance in dynamic situations, where for whatever reason there's a difference of opinion within QA on how to proceed (as an imperfect tool exception could legitimately provoke, again, the handy example, not the only case, thus it's not a sub-point but its own bullet point). The other alternative would be unanimous agreement or the decision of the maintainer in question rules, altho there is of course the middle possibilities of say 3/5 or 2/3 or 3/4 super-majority required in ordered to overrule the maintainer. As I said, your interpretation, that it applied to /this/ policy, wouldn't be likely to occur to a native English speaker, and does in fact seem a bit odd. However, that's not to say the point isn't valid, as it's certainly best that the document be clear to all, including non-native English speakers to whom the point as now written obviously isn't entirely clear. Actually, the point about a 2/3 (or whatever) super-majority, vs. simple majority of the QA team needed to overrule a maintainer, is a good one to debate as well. Perhaps developers would be less worried about abuse if the majority required was stronger, thus improving the safety margin. Assuming that's the case, the policy as a whole could probably have more teeth in the case of a super-majority required, than would be possible if it's only a simple majority. If some sort of a super-majority was required, it should be easier to accept certain decisions, when they seriously impact a developer or Gentoo in general. I know if I had a disagreement and out of a five member team, two sided with me and three against, making it a majority-of-one, I'd be less comfortable with the outcome than if it had required a 2/3 majority, and thus 4 members of the team voting against me. Another way to approach it would be to state that for purposes of packages (s)he maintains, a developer gets one vote on the QA as well. Thus, in ordered to overrule h(im|er), the QA team would need 50%+2, since 50%+1 would be deadlock with the developer siding on the keep things as they are side. The idea in either case is to minimize the possibility of something occurring without enough of a majority opinion to make the decision look arbitrary or subject to immediate reversal upon the whims of a single QA team member, without making it impotent in certain cases due to a requirement for a unanimous decision. Reason in the middle ground? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: QA Proposal v3
Duncan posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 23 Apr 2006 23:30:41 -0700: > The idea in either case is to minimize the possibility of something > occurring without enough of a majority opinion to make the decision look > arbitrary or subject to immediate reversal upon the whims of a single QA > team member, without making it impotent in certain cases due to a > requirement for a unanimous decision. Reason in the middle ground? Argh! Make that: The idea in either case is to minimize the possibility of something occurring without enough of a majority opinion, SUCH THAT the decision looks arbitrary... IOW, it looks arbitrary if the majority is only a single person. Increasing the necessary majority decreases the appearance of arbitrariness. As such, given a suitable super-majority requirement, giving the QA team enough authority to be effective shouldn't be an issue, because all sides should be comfortable that the decision isn't in fact arbitrary, nor could it be, due to the super-majority requirement. Of course, if the QA team ends up being only a couple people... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
