[gentoo-dev] last rites for net-dialup/gigaset-isdn
I've masked net-dialup/gigaset-isdn for the following reasons: - base and M105 driver are part of the standard kernel since 2.6.17 - frontend tools current version != current driver version, which means it should be splitted in 2 packages - frontend tools are experimental I will remove it in about 2 months. If someone still needs either gigaset-drives-0.5.2 or gigaset-frontend-0.5.3, file a bug requesting that. Otherwise I will *not* add those to the tree because I think this package don't have any user left (no one reported build failure for quite awhile). signature.asc Description: OpenPGP digital signature
[gentoo-dev] last rites for net-proxy/dansguardian-dgav
I've masked dgav and I will remove it from the tree in about a month. The new version of dansguardian (net-proxy/dansguardian-2.9) has a better anti-virus support hence making dgav hack obsolete. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking
Daniel Gryniewicz wrote: We (gnome) are not going to maintain gtk+-1. We would very much prefer it get removed. If some other person or group wants to maintain it, I guess it's fine with me; it will only cause Jakub and company headaches for re-assigning all the bugs that mistakenly get assigned to gnome. Note that maintaining it basically means being upstream, as there is no upstream for it. I have at least one package depending on it. Feel free to make me the maintainer of the gtk+-1. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking
Paul de Vrieze wrote: On Friday 10 November 2006 16:28, Daniel Gryniewicz wrote: On Fri, 2006-11-10 at 08:56 +0100, Marius Mauch wrote: Ok, the list definitely isn't accurate. If there is a legitimate reason to mask sylpheed-claws-1.x you also have to mask it's reverse deps. However I'm still waiting for the explanation why it is on that list. (I don't mind if it's masked for a good reason, but I need to know that reason). There is no immediate reason, of course. However, gtk+-1 and glib-1 will be removed as soon after the big cleanup as is feasible, and sylpheed-clasws-1.x is a gtk+-1 app, and therefore must go as well. I didn't generate the list, but my understanding was that it was intended to include all packages with a hard dep on gtk+-1, in addition to gnome 1.x. Gtk1 actually is broken for --as-needed. It's linking is broken thanks to a libtool which refuses to link against a non-installed libgdk. I think gtk+-1.2.10-r12 solved this problem. Hope you guys aren't seriously considering dropping gtk+1. As long as we have packages that depend on it (packages that has nothing to do with gnome herd/team), gtk+1 should stay in the tree. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Diego 'Flameeyes' Pettenò wrote: On Wednesday 08 November 2006 21:01, Kurt Lieber wrote: So, in other words, spammers aren't abusing anything related to SPF. They're sending mail using forged return-paths and SPF is highlighting that. Which is exactly what SPF is designed to do. If I were to send my gentoo mail through a mail.flameeyes.is-a-geek.org, with its own SPF record, (I'm not as this is not a real domain I have access to, nor a mailserver for what it's worth), with a From: [EMAIL PROTECTED] and a Sender: [EMAIL PROTECTED], would it be a PASS or a FAIL in SPF? It doesn't matter what From, Sender or whatever else in the message header. The part that counts is the Return-Path (the mail from: part of the SMTP protocol). Of course, MUAs such as Thunderbird don't give you the possibility to set that and it will be the same as your From address. A SPF-capable MTA will PASS your message to the recipient. However, SA will add 1.1 to the message spam score because of the SPF_NEUTRAL test. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Diego 'Flameeyes' Pettenò wrote: Of course, MUAs such as Thunderbird don't give you the possibility to set that and it will be the same as your From address. Shouldn't be your provider's mail server to set it? Both of my SSL-enabled mail servers, that are authenticated (GMail and the Italian postal service) set this correctly, thus I don't have the SPF_NEUTRAL error on them. Return-Path header field is introduced by the MTA when it receives the mail from the other party. The protocol is like this: ... mail from: [EMAIL PROTECTED] 250 Ok rcpt to: [EMAIL PROTECTED] 250 Ok data 354 End data with CRLF.CRLF Subject: test From: John Doe [EMAIL PROTECTED] To: Suzy [EMAIL PROTECTED] test message . 250 Ok: queued as 9EE1A64798 quit 221 Bye Here you have [EMAIL PROTECTED] as Return-Path. Please note the fact that submitted message does not have such field yet and even if it had, it would be overridden by the MTA with what I specified in mail from: command. Because I used telnet, I was able to specify 2 different addresses for the From and Return-Path addresses, but all the MUAs I worked with have no such fine grained settings. For Thunderbird, when I say I want to send mail as [EMAIL PROTECTED], the same address will go also in the Return-Path. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Ciaran McCreesh wrote: Kurt didn't back up his views back then. Rather typically, he just told Method that he disagreed and that he wasn't going to budge no matter what anyone said... In the year 2005, the only gentoo-core discussion related to SPF was between me and lcars. Probably you are talking about an IRC conversation. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Lance Albertson wrote: I'm sorry, but when people automatically want to go to the council first and ask questions later I have a hard time wanting to help them. I can't control what Kurt does/says so that's out of my control. For the record, I've asked the council first because I thought it might be reckoned as Gentoo policy. You seem to be the only one who took this honest mistake the wrong way. :-\ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Mike Frysinger wrote: On Monday 06 November 2006 17:09, Alin Nastac wrote: I re-stated my case in comment #14 most of your dislike for SPF centers around the idea you dont want to send mail via gentoo.org mail servers ... is this really a problem ? seems like it's pretty trivial to do so I admit I dislike SPF, but this isn't the issue. I don't ask Gentoo to join me in a crusade against SPF (I have better things to do with my life). The issue is we shouldn't have this TXT record for the g.o domain. While I could use smtp.g.o to send my email, others might be less lucky than me. Devs should have a choice whether they use Gentoo SMTP server or not, or at least this is opinion on the matter. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. I have a problem with our current SPF record. I wanna see a +all in this record for 2 reasons: a) SPF is really worthless b) spamassassin have a SPF_NEUTRAL test, with a score bigger than 1 See http://thread.gmane.org/gmane.linux.gentoo.devel/43707/focus=43707 . signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Mike Frysinger wrote: that's nice, but again, why arent these being directed to infra ? It could be considered as organization policy, so I assumed council had to be involved in this decision. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Mike Frysinger wrote: On Sunday 05 November 2006 05:39, Alin Nastac wrote: Mike Frysinger wrote: that's nice, but again, why arent these being directed to infra ? It could be considered as organization policy, so I assumed council had to be involved in this decision. it isnt ... so file a bug for infra done in bug 154120 . signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Mike Frysinger wrote: On Sunday 05 November 2006 07:36, Jakub Moc wrote: I'd like to resubmit it to the council... :/ not until it pans out with infra Now would be a good time to bring the problem before the council? It has been permanently closed as WONTFIX by klieber (our SMTP admin). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Mike Frysinger wrote: On Sunday 05 November 2006 10:00, Alin Nastac wrote: Mike Frysinger wrote: On Sunday 05 November 2006 07:36, Jakub Moc wrote: I'd like to resubmit it to the council... :/ not until it pans out with infra Now would be a good time to bring the problem before the council? It has been permanently closed as WONTFIX by klieber (our SMTP admin). personally i'm just going to go with klieber -mike Well, I'm not against the others winning the debate while they have good arguments. Till now, no real contra-arguments were emitted against my request. Could someone point me to the warehouse where those precious arguments are saved for better use? signature.asc Description: OpenPGP digital signature
[gentoo-dev] SPF at g.o
Facts: a) current SPF TXT record of our domain is v=spf1 mx ptr ?all b) I use my own MTA to send my @g.o messages. c) Probably I am not the only one who does that I've just evaluated SPF support in spamassassin and I've discovered that SPF_NEUTRAL has a big fat score of 1.1. I don't know about you guys gals, but I'm not used to have spamassassin scores 1 assigned to messages sent by me. Yes, I know, it is only a statistical score, but if SPF_NEUTRAL has such a big probability of being spam, that could only means it is used more by spammers than honest folks. Btw, I don't think SPF's failure to become a industry standard is a secret to anyone. Conclusion: The proper TXT record for our domain would be v=spf1 +all, which translates (according to http://new.openspf.org/SPF_Record_Syntax ) as the domain owner thinks that SPF is useless. And it really is useless, at the very least for our widespread organization. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: remove my address
David Shakaryan wrote: George Prowse wrote: Mike Frysinger wrote: On Wednesday 25 October 2006 01:53, Drake Wyrm wrote: I think someone is yanking your chain, vapier. i doubt it ... other people on irc mentioned receiving said e-mail as well Haven't seen said email here... From my understanding, it wasn't sent to the actual mailing list, but to a few specific @gentoo.org addresses. Infra team, please block anything from [EMAIL PROTECTED] I could do it for my mailbox, but since there are many of us spammed by that moron, I think it would be best to block it on mail from SMTP command. signature.asc Description: OpenPGP digital signature
[gentoo-dev] implicit vs explicit dependencies
Up till now, I relied on implicit dependencies (dependencies of my dependencies). Apparently now (see https://bugs.gentoo.org/show_bug.cgi?id=152534) we should add every atom that an ebuild depends on to (R)DEPEND. Which is the right way? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GeNUS : how I currently manage my gentoo network (200+ machines)
Hubert Mercier wrote: Since this work saved me a lot of work / time / money in the past two years, I thought maybe it could help others. Just let me know if we could do something with this, if it sounds usefull/less to you, etc... Sounds pretty useful to me :-P signature.asc Description: OpenPGP digital signature
[gentoo-dev] amd64 and ia64 keywords
Please correct me if I'm wrong, but isn't amd64 and ia64 architectures nearly the same? Beside 3dnow/sse instruction sets of course. If so, shouldn't we have the same kewords (amd64 ia64, ~amd64 ~ia64 or none) on every package that don't use 3dnow/sse instructions? I only ask this because I think the arch teams' could be better spent than double-checking the packages. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] amd64 and ia64 keywords
Mike Frysinger wrote: my guess is you're confusing EM64T and IA64 ... in that case, people with EM64T cpu's use the amd64 KEYWORD yeah, I confused those 2 arches :-[ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Natanael Copa wrote: Nobody has ever showed interest and I'm not pushing my services on anyone. Why exactly you don't want to become a Gentoo dev? The whole proxy maintainer thing is a bunch of crap. The Gentoo developer will still be expected to be responsible of his/her commits, which means 2 maintainers will spend (approximately) same amount of time testing it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proxy maintainers
Natanael Copa wrote: Because of gentoo devs always seems to fight? You don't have to fight. Its funny, I use gentoo much more that FreeBSD, I'm a freebsd port maintainer, but nothing for Gentoo (well, im an active bugreporter...) When I submit a fix/version bumb (I submit as maintainer update) to freebsd ports, its normally committed within hours, even if its not a popular port. When I submit fixes for packages in Gentoo bugzilla it get stuck for months. They must have done something right. I don't know anything about freebsd, but I think they have a lot less packages than us. Since we have a vast territory to cover with just 200 (semi-)active developers, there are portions of the tree neglected by the dev corpus. The solution is quite simple: new devs assigned to those part of the tree. The only problem is that is very hard to find motivated peeps. As a guy that maintains stuff for which I don't have the slightest interest (other than serving Gentoo community, of course), I find the let the others do the job attitude pretty infuriating. signature.asc Description: OpenPGP digital signature
[gentoo-dev] How default route should be set by pppd
Hi fellow devs, I discovered that ppp-2.4.4 set a default route without a gateway. It is totally fine from IP routing point of view (the simple fact that route is through the point-to-point link is enough to know the next hop), except that openswan's %defaultroute need a default gateway in order to work. I'm about to apply a patch that would reverse to the old way of setting the default route. Any objections? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How default route should be set by pppd
Roy Marples wrote: So how does that look in the routing table? default dev ppp0 scope link instead default via a.b.c.d dev ppp0. If say a DHCP client renewed it's lease and it set a new default route, would this have any effect? I guess a DHCP client would override the default route set through defaultroute pppd option (or not, depends on the client). If it's p.masked then none :) Why p.mask when the way I wanna set defaut route is as in stable version of net-dialup/ppp? Of course, 2.4.4-r2 will still be marked as testing for all arches. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC about another *DEPEND variable
Mike Frysinger wrote: On Thursday 21 September 2006 13:15, Alin Nastac wrote: Unless you save the specific compatibility version of the net-dialup/ppp used by net-dialup/pptpd for building the package, I don't see how can it help me. Judging after /var/db/pkg content, I have no such information. it is all there right now actually :) check out the NEEDED file ... combine that with CONTENTS of other packages, and you have all the binding info you want ... I see only libraries in NEEDED and it is probably generated automatically. There is no way for the automatic tools to discover the dependency between pptpd and ppp version. Besides, even if I would have somehow /usr/lib/ppp/2.4.3 in NEEDED file of the pptpd, the amount of computation needed to discover which package offers such thing would be prohibitive. The reciprocal operation (find which packages use the old path before upgrade) would also be prohibitive. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New project: Gentoo Seeds
Dice R. Random wrote: What control mechanisms are there within the Gentoo community to keep a few bad apples from spoiling the whole barrel, as it were? I do not wish to name any names, but it seems to me from having skimmed this list for the past few years that there are a couple people who are continually embroiled in flame wars and, in my opinion, are bringing discredit to Gentoo in general and the developers in particular. Enough is enough! Just because some devs are more temperamental than the others, doesn't make them bad apples! Our civilized disputes are taken place in public because we are an open organization. If this looks bad in the eyes of some, so be it, but please keep your opinions out of this list. signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC about another *DEPEND variable
I'm annoyed about impossibility to fix a certain class of breakages (other than reemerging the failing package). I am referring to the breakages occurred when foo has been upgraded, but the bar package cannot work with it because it was build against the old foo version. We all had to run revdep-rebuild once in awhile, for fixing dynamic linkage problems, but unfortunately revdep-rebuild cannot fix another kind of incompatibility, namely dynamic version check implemented in some packages. For instance, the recent openssl-0.9.8* update broke dev-libs/neon (and consequently subversion) because neon library isn't happy just by linking with libssl.so.0.9.7 but also check the libssl version when loads the ssl library. Another example is the subtle dependency between the pppd version and pppd plugins (net-dialup/pptpd needs to be rebuild every time you change PV of the net-dialup/ppp because pptpd builds a plugin for the ppp daemon). I reckon this could be solved by yet another *DEPEND variable. The only atoms accepted by this variable would be CATEGORY/PN. Every time when a package gets updated from PV1 to PV2 (distinct versions, revisions will not count), portage will automatically re-emerge those packages that depend on it. Thoughts? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC about another *DEPEND variable
Luca Barbato wrote: Alin Nastac wrote: I reckon this could be solved by yet another *DEPEND variable. The only atoms accepted by this variable would be CATEGORY/PN. Every time when a package gets updated from PV1 to PV2 (distinct versions, revisions will not count), portage will automatically re-emerge those packages that depend on it. Thoughts? It would require revdep resolution on emerge... how painful would be? I don't know anything about portage intricacies, but I guess it would be fairly easy to have a map of CATEGORY1/PN1 - CATEGORY2/PN2 key-values, where package 2 depends on package 1 (package 2 is the one that defines the xxxDEPEND variable). In order to add such (key, value) in the map the following assumptions must be satisfied: - package 2 must be installed (mandatory) - package 1 must be a direct or indirect RDEPEND dependency of the package 2 (optional). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC about another *DEPEND variable
Brian Harring wrote:
On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote:
There is one flaw with this though; packages can provide both
libraries _and_ binaries. Our dependencies don't represent whether
the dep is actual linkage, or just commandline consuming, so (using
the openssl example) any package that invokes openssl via the
commandline to do a few simple chksum ops gets rebuilt, despite the
fact it wasn't affected by linkage change ups.
I like BINCOMPAT proposal but it solves only half of the problem. You
assume that all dependent packages cares about binary compatibility.
Why not using a BDEPEND var in those dependent packages affected by the
BINCOMPAT values of their dependencies?
For instance, I would set the following:
- in net-dialup/ppp ebuild: BINCOMPAT=${PV}
- in net-dialup/pptpd ebuild: BDEPEND=net-dialup/ppp
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC about another *DEPEND variable
Brian Harring wrote: BDEPEND was actually a seperate proposal/idea, intention there was to have that be the deps that *must* be CHOST (gcc would be an example); bits that are used to actually build the pkg, not data it consumes in building (headers would be data). Well, until now I didn't thought at the build compatibility. My concern was only the runtime compatibility. Meanwhile, for this I don't see the point in using a seperate metadata key. Overload DEPEND and add a marker char that is used to indicate that a particular dependency is 'binding', ie, it is linkage. Lets suppose we use as 'binding' dependency marker. What sense would DEPEND=net-dialup/ppp have in a context of an ebuild. It certainly don't specify the necessity of package rebuild whenever net-dialup/ppp version is changed. Unless you save the specific compatibility version of the net-dialup/ppp used by net-dialup/pptpd for building the package, I don't see how can it help me. Judging after /var/db/pkg content, I have no such information. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC about another *DEPEND variable
Mike Frysinger wrote: i think you're merging the two issues you brought up ... there is binary ABI issues (which should not require a new DEPEND variable as portage can extract that information out at runtime) and there is runtime plugin issues with packages using dlopen() (which portage cannot extract as the dependency cannot ever be extracted) Okay, maybe I hijacked BINCOMPAT purpose. As I said in a previous reply, my original message was about runtime compatibility, not compilation compatibility. I want to be able to save in a package metadata that it was build using some version (as in compatibility version, not necessarily PV) of another package and I want emerge to automatically rebuild my package whenever this version is changed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Orphaned packages
Gustavo Felisberto wrote: net-mail/sendEmail Took this one. signature.asc Description: OpenPGP digital signature
Re: [gentoo-core] Re: [gentoo-dev] Global USE flags bite the dust...
Doug Goldstein wrote: dba dio ingres msession mcve are all used by 1 ebuild... and that's dev-lang/php... they should be moved to local's. Consequence: php eclasses code should be moved in dev-lang/php ebuild. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: Globalness of some USE flags
Simon Stelling wrote: I think we agreed at least 3 times on that the logrotate use flag shouldn't exist at all because those files add 4kb to the package. Please look at http://article.gmane.org/gmane.linux.gentoo.devel/35754 . I said it once, I'm saying again: squid need this USE flag. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Gentoo activity graphs
Every now and then someone get sick of Gentoo and suddenly became prophet, preaching that the end of the distro is near. I wanted to see how much should we worry about it so I've made a perl script to find the history of the following characteristics: - no. of active developers (active dev := did at least a commit in that month) - no. of commits / month The data and the perl script used to obtain it are available at http://dev.gentoo.org/~mrness/gentoo-activity-2006-06/ . I am aware those characteristics are quantitative and don't say anything about the quality of the distribution. However, judging after those graphs, even the worst basher will recognize that we are far from being dead. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo activity graphs
Chris Bainbridge wrote: It may be a better metric to look at the bugzilla stats. How has the number of bugs being filed changed? What ratio of filed bugs are resolved, vs the ones that are left open? bugs.gentoo.org has some facilities for graphing stats back to December 2005... Bugzilla cannot plot ratios. I find active devs metric a useful one.Until a year ago, the number of active devs was linearly rising, but in last year we seem to hit a ceil (175) - either recruiter team is understaffed or our organization reached the maximum number of individuals who can work together without stepping (too much) on each other toes. Anyway, a thing is certain... Gentoo didn't loosed dev's attention. signature.asc Description: OpenPGP digital signature
[gentoo-dev] QA Notice: pre-stripped files found
I have a question for portage devs. Is appending -g to CFLAGS tolerable from your pov? I ask this because net-dialup/freeradius allow me to install unstripped binaries but the correspondent configure option (--enable-developer) also append -g to CFLAGS. Otherwise, I will have to patch configure.in and execute eautoreconf. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Notice: pre-stripped files found
Mike Frysinger wrote: On Saturday 01 July 2006 02:34, Alin Nastac wrote: I have a question for portage devs. Is appending -g to CFLAGS tolerable from your pov? you're confusing things adding debugging symbols has nothing to do with the stripping of a binary the warning is because the binaries are stripped (`strip foo` or -s in CFLAGS) -mike I know the debug information is more than just simple symbols, but without symbols I don't see how you could have debug info. Anyway, that is beside the point... Freeradius configure doesn't allow me to install unstripped binaries unless I also add -g to CFLAGS (which means that the binary will contain . Please re-read my initial message: I ask this because net-dialup/freeradius allow me to install unstripped binaries but the correspondent configure option (--enable-developer) also append -g to CFLAGS. Otherwise, I will have to patch configure.in and execute eautoreconf. signature.asc Description: OpenPGP digital signature
[gentoo-dev] last rites for app-mobilephone/openobex-apps
app-mobilephone/openobex-apps has been masked and it will be removed from the tree in 30 days. Those who want a OBEX server should use app-mobilephone/sobexsrv. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] variable quoting, setting optional variables to , and depending on virtual/libc
Thomas Cort wrote:
What is the proper quoting style for using epatch? In the tree there
are about 3 different styles...
epatch ${FILESDIR}/some-fix.patch # used by 7326 ebuilds
epatch ${FILESDIR}/some-fix.patch# used by 3092 ebuilds
epatch ${FILESDIR}/some-fix.patch# used by 1434 ebuilds
2 and 3 are fine.
What is the proper quoting style for defining the S variable? In the
tree there are about 3 different styles...
S=${WORKDIR}/${MY_P}# used by 5270 ebuilds
S=${WORKDIR}/${MY_P} # used by 43 ebuilds
S=${WORKDIR}/${MY_P} # used by 2259 ebuilds
ditto
What is the purpose of setting DEPEND and RDEPEND to if DEPEND and
RDEPEND are optional[1][2]? Isn't that just a waste of disk space /
bandwidth? DEPEND=virtual/libc seems like a waste too as it is an
implicit system dependency[3], any reason for using it?
DEPEND= # used by 1479 ebuilds
RDEPEND=# used by 884 ebuilds
DEPEND=virtual/libc # used by 809 ebuilds
If the package don't have dependencies, then don't set *DEPEND.
virtual/libc dependency is probably futile, unless the package is part
of the system class or is a dependency of a package which is part of the
system class.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Signing everything, for fun and for profit
Chris Bainbridge wrote: ... Do we really have many users on dialup that it would inconvenience? Surely the massive size of the distfiles you have to download makes the impact of rsyncing the portage tree negligible compared to actually fetching everything you want to install? It is hardly a matter of bandwidth. A reduced to the minimum tree would sync faster because the thousands of files checked (and pottentially updated) by rsync are cutted in half. Also, the other emerge operations will work faster because of that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] default RDEPEND?
Carsten Lohrke wrote: RDEPEND=cvs? ( dev-util/cvs ) svn? ( dev-util/subversion ) !cvs? ( ! svn? ( dev-util/cvs ) ) Huh? How about: RDEPEND=|| ( dev-util/cvs dev-util/subversion ) IMO, your example is a USE flag abuse. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: The council should not vote on gleps are provide policy. They should be there to handle the money and world-wide problems. The developers should drive innovation; not the council. As in all democracies things get done slowly. We don't need a democracy within Gentoo, just a clear way of creating progress. Just because we have some elections in our process don't make Gentoo a democracy. Since we don't have a leader to make the important decisions, we need some other form of authority to do the job. A council is the best solution to the decisional problem. Obviously it has nothing to do with innovation. As always, this is the realm of developers. In the rest, I basically agree with avenj. No point in repeating what Jon already said... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo: State of the Union
Tim Yamin wrote: On Fri, Apr 28, 2006 at 01:55:01PM -0500, Grant Goodyear wrote: CVS doesn't do branching nor tags very well... __Problem: CVS__ CVS is one of the worst application ever created. The portage tree needs to move to subversion. A lot of the problems within the project would be solved by using a better SCM system. The previous problems regarding the Live Tree and Developer Growth would be solved, IMHO, by just switching. Branches Work. Tags Work. Reverts work. Moves work. I don't see any reason not to use it. It just plain works. Have you tried using SVN for the portage tree? I don't know if anybody has recently, but in the past when people tried there were two significant problems: SVN requires at least 2x the tree size for storage on the local machine, and checkouts take something akin to an order of magnitude longer than CVS. The former is annoying, but liveable, but the latter is a deal-breaker. Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org) And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare checkout performance on it as well. Since it is derived from svn, I think it would be x times slower than svn. Besides, why would we need a decentralized SCM? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Herds, Teams and Projects
Kevin F. Quinn (Gentoo) wrote: It would be useful to know how many people think herds are not maintainers - if only a few people think this then I suggest it would be better to accept the common interpretation of herd as a group of people who can maintain a package. I've always considered herd == maintainer. When a package is related to one of the herd I'm part of, I prefer setting it in metadata.xml instead of adding myself as the maintainer of the package. A herd should be more responsive than a single individual (depending on the size of the herd, of course). Also, it would mean less things to do when the maintainer leaves from Gentoo dev community. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Which license?
A. Khattri wrote: Im working on an ebuild for a package and Im not sure what license to use. The package is Copyright Company X but has this underneath: ## This software may be freely copied, modified and redistributed ## without fee for non-commerical purposes provided that this license ## remains intact and unmodified with any distribution. ## ## There is no warranty or other guarantee of fitness of this software. ## It is provided solely as is. The author(s) disclaim(s) all ## responsibility and liability with respect to this software's usage ## or its effect upon hardware, computer systems, other software, or ## anything else. ## Last time I looked, there were some 800 or so files in /usr/portage/license/ - so which one would I use? LICENSE=as-is ? IANAL signature.asc Description: OpenPGP digital signature
[gentoo-dev] DEPEND/RDEPEND question
Lets say a package foo depends on bar, both at compile time and run time. Shouldn't DEPEND _and_ RDEPEND of the foo package reflect that dependency? I usually set DEPEND=$RDEPEND ... or vice-versa (depending on which is the most demanding). Am I utterly wrong here? I know that when a package is installed the usual way (not from a binary tarball) dependencies==RDEPEND+DEPEND, but portage functionality could change in the future. It may not be the wisest decision ever made, but portage could very well remove whatever dependencies are found in DEPEND - RDEPEND, once the package is installed. signature.asc Description: OpenPGP digital signature
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
Re: [gentoo-dev] Re: last rites for app-mobilephone/openobex-apps
Henrik Brix Andersen wrote: On Sat, Apr 15, 2006 at 02:06:00AM +0300, Alin Nastac wrote: dev-libs/openobex-1.2 is now in the tree. Why did you p.mask openobex-apps before openobex-1.2 is stable? For forcing users to test openobex-1.2 ;) I think openobex-1.2 should be unmasked, but I am waiting for ticho to actually do this. See bug 122262 http://bugs.gentoo.org/show_bug.cgi?id=122262 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: last rites for app-mobilephone/openobex-apps
Henrik Brix Andersen wrote: On Mon, Apr 17, 2006 at 11:21:29AM +0200, Henrik Brix Andersen wrote: Please solve this mess - don't package.mask openobex-apps until openobex-1.2 has the same KEYWORDS as openobex. ... as openobex-apps, of course. ./Brix OK, I've removed the hard mask on openobex-apps. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: last rites for app-mobilephone/openobex-apps
Simon Holm Thøgersen wrote: tor, 13 04 2006 kl. 22:55 +0300, skrev Alin Nastac: Unless someone has a really good reason not to, app-mobilephone/openobex-apps will be removed from the tree on April 20th. Most programs found in this package were included in =dev-libs/openobex-1.2. The only exception, obexserver, have a better replacement in app-mobilephone/sobexsrv. One would expect =dev-libs/openobex-1.2 to be in the tree when you say so, but I see no trace of it. Opps... I thought ticho already add it to the tree. I will bump openobex ASAP. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: last rites for app-mobilephone/openobex-apps
Simon Holm Thøgersen wrote: tor, 13 04 2006 kl. 22:55 +0300, skrev Alin Nastac: Unless someone has a really good reason not to, app-mobilephone/openobex-apps will be removed from the tree on April 20th. Most programs found in this package were included in =dev-libs/openobex-1.2. The only exception, obexserver, have a better replacement in app-mobilephone/sobexsrv. One would expect =dev-libs/openobex-1.2 to be in the tree when you say so, but I see no trace of it. dev-libs/openobex-1.2 is now in the tree. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: who renamed adsl-start to pppoe-start and why
Curtis Napier wrote: And that change was duly noted and acted upon by almost everyone. We had several threads in the forums plus the einfo warnings. Most people made the transition without any problems. Good work on the adsl mrness, it works so much better than rp-pppoe now, thanks! Thank you for your kind words, but I didn't contribute anything to the adsl baselayout module (or if I did, I don't remember). ;-) I am the main contributor to the ppp module available in baselayout-1.12*, which support any kind of PPP link known to mankind. I strongly believe this module support for PPPoE is better than rp-pppoe from the Gentoo point of view, but unfortunately baselayout-1.12 isn't stable yet. :-( signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making the developer community more open
Daniel Drake wrote: We have a large expense on both sides when adding a developer to the project. I personally have lost developer candidates, undoubtedly more technically experienced than myself, who simply did not have the time to go through a month-long recruitment process which involved studying various documents not even relevant to the small area they would be contributing to. On the other side, it's a fair expense to add a developer to the project due to all of the quizzing/assessing/account-creating/access-elevation/... Technical ability isn't the only requirement for gentoo devs. They also must be motivated individuals and these high barriers you are talking about test this quality of the candidates. If they quit just because recruitment process is long, what makes you think they will stay active long enough to actually worth adding them to dev corpus? Additionally, a significant percentage of developers who have joined recently have gone AWOL after a few months. That hurts us, given the expense we went through recruiting and adding them, and the time needed to reverse that and retire them. Yes, it is hard to find the right people. Yes, a big percentage of recruiting team's time will be lost on useless additions/removals. But the only solution is scaling the recruiting team to gentoo needs. IMO recruiting team is too small to cope with the current size of the project. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Change layout of distfiles
Simon Stelling wrote:
Alec Warner wrote:
Taking the earlier comment ( changing files only on the mirrors )
there are no portage changes that are technically required. However,
you'd need to change about 1 ( random number I pulled out of my
ass, but there are many affected ) SRC_URI's to point to the new
format, or produce some sort of hack that translates between the two,
and I wouldn't be to fond of the latter effort, mostly because it
would probably rot in the tree for way too long ;)
I don't see how making portage translate
mirror://gentoo/${P}.patch.bz2 to
http://distfiles.gentoo.org/distfiles/${firstchar}/${P}.patch.bz2 is
worse than changing 1 SRC_URIs.
Better yet, the new portage could download files by trying both kind of
URLs (of course, only during the transition period).
After portage team mark the new portage version stable on all arches and
give the folks a chance to update their systems (6 months perhaps),
infra team could make the transition to the new URLs the same way
they're doing releases - historical transitions (namely using hardlinks).
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Change layout of distfiles
Stuart Herbert wrote:
Why not have the directory structure follow the package category
structure? E.g. the distfiles for package foo/bar goes into the
directory ${MIRROR_ROOT}/foo/bar?
This should be easy enough to support in Portage, and if applied to
the /usr/portage/distfiles directory too, would solve a few other
problems. It also has the advantage of grouping the distfiles in a
way that users would find natural to browse.
There is the problem of what happens when a package moves, but I think
that's easily solved too.
this has been discussed before.
summary: tarballs could be used by more than one package. this way
you'll manage to increase the disk space demands for our mirrors.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Change layout of distfiles
Jan Kundrát wrote: Alin Nastac wrote: this has been discussed before. summary: tarballs could be used by more than one package. this way you'll manage to increase the disk space demands for our mirrors. This one is about sorting by first letter of filename. It won't solve multiple different files with same filename, though. I know what is this about, but Stuart was trying to reopen that old thread. You can't solve the name conflict in a generic fashion without increasing required resorces from our mirrors (either disk space or CPU + RAM). Since probability of such conflict is very low, I say better solve one conflict at a time, by hosting a renamed version of those files on mirror://gentoo. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
[deleted] All seems fair enough, but please fix portage qa issues before this policy is applied (see bug http://bugs.gentoo.org/show_bug.cgi?id=123733). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Manifest2 decision delayed
Ciaran McCreesh wrote: On Fri, 10 Feb 2006 10:14:26 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: | Interesting, yes... but ebuilds are read by humans and it is necessary | to be comprehensible a lot more than the Manifest files are. Sure. But the comparison would show whether or not it's going to make a substantial difference. And if it does, there're other things that can be done in the Manifest file that'll save a whole load of space too (e.g. using $ to represent $PN, ! to represent files/, * to represent ChangeLog and so on, since these characters aren't allowed in any filename in the tree). When you have thousands of small files (1-4 blocks), the space saved by removing all unnecessary whitespaces is minimal at best. Minimizing the number of files is another story. Unifying manifests with digest files will save a considerably amount of disk space. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Default Ebuild behaviour
Chris Gianelloni wrote: Basically, if the package *requires* something to function, such as a cron script, then it should install it unconditionally. If it does not, then it shouldn't install it. Having to change USE to get a stupid cron/logrotate file is definitely not the best option. Why not install it to /usr/share/doc/$package as $package.logrotate and tell the user about it instead? The only case mentioned where the logrotate USE flag changes functionality is squid, so it should keep the logrotate local USE and everything else should drop it, then copy the logrotate files into /usr/share/doc. That way I don't have to --newuse and recompile a package just to get a simple example logrotate file, things don't get shoved into /etc without consent, and everybody is happy, right? (Yeah right... :P) Well, the only reason squid installs a cron/logrotate file is because of the sentence quoteyour package ... is supposed to just work for the end-user/quote, which at that moment I understood it as a requirement. Without it, a fresh squid install needs to be tweaked by the user (unless you don't mind to have an ever increasing /var/log/squid/* log files). As for --newuse forced recompilation of squid, do you think people will just keep switching logrotate USE flag? Agreed, it could happen once, but that's it! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make logrotate a global USE flag?
Marcelo Góes wrote: If INSTALL_MASK is the correct way to prevent logrotate stuff from being installed, then those 8 ebuilds I mentioned earlier should drop the USE flag and install it by default. That's probably easier to fix, too. This cannot be done for squid, because this useflag selects the rotation method: logrotate or the native method (through a cron job). While it is easy to filter logrotate files through INSTALL_MASK, it isn't so for /etc/cron.* files. signature.asc Description: OpenPGP digital signature
[gentoo-dev] net-proxy/squid should be demoted to ~mips
Given the lack of interest manifested by mips team regarding net-proxy/squid and its security bumps, I propose to remove the last mips-stable version of this package - 2.5.10-r2 - marked as such by hardave on September the 4th 2005. Objections anyone? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-proxy/squid should be demoted to ~mips
Mike Frysinger wrote: On Friday 06 January 2006 08:07, Alin Nastac wrote: Given the lack of interest manifested by mips team regarding net-proxy/squid and its security bumps, I propose to remove the last mips-stable version of this package - 2.5.10-r2 - marked as such by hardave on September the 4th 2005. Objections anyone? any reason you felt the need to e-mail gentoo-dev ? this is a pure security/mips issue, the rest of gentoo dev could care less -mike I've already been informed about the procedure in this case. Sorry for the hassle, I thought I should inform gentoo-dev before breaking keywords policy. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Developer: Peter Volkov
George Shapovalov wrote: Well, I was going to suggest that, but then I realized that he would have to be 35+ at this point and to be from Kiev ;). What is wrong with being over 30? I'm one of those guys... ;-) Judgind after the fact that is a PhD student, it might be 8-) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Binary packages in the tree
Mark Loeser wrote: Well, you can tell I didn't exactly think about this too much beforehand, since its been brought to my attention a virtual would probably be best for this, so we would handle the || ( gcc-3.3.* libstdc++ ) inside of the virtual. I'll make one later unless anyone has strong objections to this for people to use in DEPEND, instead of writing the `or` dep out. Since gcc-3.4 is the stable version now, the best would be || ( libstdc++ gcc-3.3.* ) . signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: emerge =net-dialup/ppp-2.4.3-r10 will fail requesting for user action
Volkov Peter wrote: I think it's good idea to add some *reasons* why that files are obsoleted. fex: * Gentoo is moving toward common configuration file for all network * interfaces. Thus starting from =ppp-2.4.3-r10 the following files * are obsoleted and should be removed to avoid future confusion: sounds great, message replaced. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] my apologies for the mess with this release of MySQL 5.0.16
Herbie Hopkins wrote: On Fri, 2005-11-25 at 17:32 +0100, Simon Stelling wrote: version 5 does not work on clean install A very descriptive changelog... Any idea what does not work means? . Seems to work pretty well here. same here. anyway, a dev-db/mysql-5 in /etc/portage/package.mask should do. signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: emerge =net-dialup/ppp-2.4.3-r10 will fail requesting for user action
Hi all, I plan to release a new version of net-dialup/ppp that will add support for the pppd net module found in sys-apps/baselayout-/baselayout-1.12.0_pre11. This version, however, cannot work with the old /etc/init.d/net.ppp0, hence I plan to die in pkg_setup with following messages: * Following files installed by previous versions of net-dialup/ppp * are obsoleted and need to be removed: * /etc/conf.d/net.ppp0 - conflict with baselayout * /etc/init.d/net.ppp0 - conflict with baselayout * /etc/ppp/chat-default - unused by this version * /etc/ppp/options-pppoe - unused by this version * /etc/ppp/options-pptp - unused by this version * If you use the old net.ppp0 script, you need to: *- upgrade to =sys-apps/baselayout-1.12.0_pre11 *- set ppp0 parameters in /etc/conf.d/net (see example file) *- remove conflicting files *- upgrade net-dialup/ppp * If you never used net.ppp0 script, just run the following commands: * rm //etc/conf.d/net.ppp0 //etc/init.d/net.ppp0 //etc/ppp/chat-default //etc/ppp/options-pppoe //etc/ppp/options-pptp * emerge --resume !!! ERROR: net-dialup/ppp-2.4.3-r10 failed. !!! Function pkg_setup, Line 72, Exitcode 0 !!! Conflicts with baselayout support detected !!! If you need support, post the topmost build error, NOT this status message. Please help me to improve the quality of these messages, grammatically or otherwise ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
Marius Mauch wrote: If not, i *personally* could go slowly removing the entries, along with other people willing to help, or any other _better_ suggestion to deal with this? Don't do this without explicitly checking with the maintainer for a package (if existant). Generally redundant entries in package.mask don't hurt, so if it's not absolutely clear that the entry is not needed anymore keep it. Hmm.. I fail to see why package.mask shouldn't be cleaned without everyone's consent. Assuming the script is correct, why would you contact the maintainer of package foe when the oldest version in the current tree is bigger than the masked one? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK
Georgi Georgiev wrote: I can only think of a couple of solution: - Remove these unnecessary checks completely: Follow the example of all other distributions and do not depend on anything kernel-ish for such packages. A recompilation of the kernel with different options can easily cause what the checks are trying to avoid anyway. - Make the checks in linux-info non-fatal. I.e., don't die but issue warnings instead. That's the *least* that I'd be happy with. What do you people think the proper solution is? see https://bugs.gentoo.org/show_bug.cgi?id=103878 I am still waiting for a response. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] C++ herd proposal
Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] C++ herd proposal
Georgi Georgiev wrote: maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. So that's why my overlay got screwed up! But seriously, this only supports my point -- category moves are evil. portage isn't supposed to offer eternal functionality status for personal overlays. what if an eclass gets obsoleted and eventually is removed from the tree? the only problem is binary packages screw up. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ROX: maintainer-wanted and apps out of date
Aron Griffis wrote: Alin Nastac wrote: [Sun Sep 11 2005, 05:02:27PM EDT] Gentoo history is full of such individuals who only want to be sure that they could become devs but are not willing to put any effort behind it. Gentoo's history is full of hard-working devs. The slackers are simply forgotten. ;-) true. my appologies :-[ what I was trying to say is that I'm not willing to spend my time on someone who will vanish shorty afterward. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ROX: maintainer-wanted and apps out of date
Peter Hyman wrote: Firstly; to be asked to become a developer you should either apply to an opening, or just help out whether in the form of user support or filing bug reports - we notice frequent contributors making contributions to Gentoo and we attempt to reward them by giving them the chance to become a Gentoo developer. Gentoo has many paths, and the Gentoo Developer Relations Recruitment Team is always looking out not just for developers - documentation writers and infrastructure maintainers are just as important too for our distribution to run smoothly. You should look out for openings for developers in the GWN, as well as the /topic of #gentoo-bugs on irc.freenode.net - if you feel you could fill in one of those positions, try to find a mentor who is willing to sponsor you, or contact the Gentoo Recruiters who may be able to find a mentor for you. Please do not file New Developer bugs on yourself since this task is designated for the mentor and any such bugs will be closed. - Certainly, I am others have fulfilled this. I have emailed the two maintainers offering to assist. No response. For some reason, rox does not show up as a staffing need. That should be corrected. I'm not going to bloat this thread. I am here to help, and I know at least one other fellow who probably would be willing to help too. It's easy, quick, and will make what users there are for rox happy. As I noted, the intent here was not to add any additional work for developers. On the contrary, the work is done already. We're already helping out we're filing bug reports, we're creating ebuilds that work. All that needs to be done is get them into portage. If you are unable to find a suitable developer to maintain rox, then please let me know and I will see about assembling a herd for it. Indeed, your name is everywhere when it comes down to rox thing. Because your dedication on rox subject, I am willing to help you become a dev, but I need to be sure you are not going to dissapear in the very next moment. Gentoo history is full of such individuals who only want to be sure that they could become devs but are not willing to put any effort behind it. Do you want be a dev? Are you sure you could take the heat? What do you expect from Gentoo and what do you have to offer in exchange? Please email me the answers to these questions on my private address. I need to know you a bit before I decide if I could mentor you or not. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Proper commit messages
Mike Frysinger wrote: also, four tabs rule you are obviously wrong. three is the magic number ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New global USE flag: logrotate
Donnie Berkholz wrote: Tom Martin wrote: | Hi list, | | Bug 97447 wants a logrotate USE flag, which is used by about five | packages locally. Unless there are any objections, I'll globalify it | later today. I think this flag is a bad idea. Why should I have to recompile a package to get some files that go in /etc? Either install them unconditionally or don't install them at all. This useflag is useful in net-proxy/squid at least. It also controls whether a cron script that use native squid log rotation is installed or not. You cannot select your preferred rotation mechanism (logrotate or cron job) through other way than useflags. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Changelogs
Michael Cummings wrote: On Wed, 27 Jul 2005 14:13:12 +0200 Simon Stelling [EMAIL PROTECTED] wrote: Please don't make portage a news reader. Compelling - I tend to agree. It'd be nice if some python-wise individual(group) wrote a tool that could interact with the portage api enough to get the update list to see what would be updated, then parse the changelogs - separate from portage, but interacting just enough to know what's on the list for upgrades/downgrades/reinstalls. Of course, this still wouldn't account for the massive developer tax effort for rewriting changelogs to adapt to the tool - or remembering to write changelogs with new markers. Changelogs are beggining to be too large already. sooner or later, portage team will move 'em somewhere outside the portage tree. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: app-portage/genlop: 9 open bugs, dead upstream
Michael Cummings wrote: As the original handler of genlop (it was assigned to perl herd when it first was asked to be added, since its written in perl) I strongly vote against dropping the package (ok, I didn't even realize it had been switched over to the portage-tools group for maintenance, and as such that there were even bugs open against it). The funny thing about no more activity upstream is this: why would there be? Except for bug fixes, it does a simple job, and it does it damned well: it parses your emerge log and gives you just the output you want and need. Don't abandon a tool just because it has reached its final state ;) Well, a homepage would be a nice thing to have. I also think that is a very useful tool. If no one will step forward, I will take its maintainership. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo/FreeBSD] enewuser and /bin/false shells
Diego 'Flameeyes' Pettenò wrote: As Gentoo/FreeBSD is always improving, I'm thinking is just the case of telling everyone how to correctly use enewuser without bailing out Gentoo/FreeBSD :) enewuser is often used with /bin/false as shell to create an user who can't login. Unfortunately this doesn't work on Gentoo/FreeBSD (and AFAIK also Gentoo/OSX has its own problem). To avoid this, please pass -1 as option for shell to create a no-login account, which is then expanded to the right shell for the right system. I've made the change for app-mobilephone, net-dialup and net-proxy categories, but I believe no one will blame you if you make it yourself. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild development (vpopmail, etc.)
Casey Allen Shobe wrote: I'm planning to edit the vpopmail ebuild Real Soon Now to add the mysteriously missing postgres USE flag and thus end up with a package compiled with the support we need. Instead of wasting my time re-adding this every time a new version of vpopmail comes along, I'd much rather use this as an opportunity to get into Gentoo development and add this to the central ebuild repository so that all future versions inherit it. What do I need to do to get started on this? Do I simply mail a patch to this list, or ask somebody for a CVS account and commit changes directly? You should file a bug in http://bugs.gentoo.org. I'm also a bit confused about the portdir_overlay thing - If there exists a -r15, do I then add a -r16 to make emerge realize an update is available. What happens then when an -r16 hits the regular portage tree? if r15 exists in portdir_overlay, it will be preferred over the official r15 version. signature.asc Description: OpenPGP digital signature
[gentoo-dev] ppp-2.4.3 ready for stable state
I want to mark net-dialup/ppp-2.4.3-r6 as stable on x86 and amd64 (the arches tested by me). Does anyone have a reason why it shouldn't be marked as such? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE_EXPAND and IUSE
Jason Stubbs wrote: On Monday 20 June 2005 01:48, Alin Nastac wrote: net-dialup/pppconfig-2.3.11-r1 depends on LINGUAS, but the list of supported languages is created in pkg_unpack, based on what tarball contains. What happened to determinism and predictability? From the user's standpoint, there is no way to know what is going to be installed until it is actually installed. I don't really understand why you consider pppconfig unpredictable. the ebuild displays what languages will be installed. The IUSE thing would raise 2 problems: - lower maintainability - not really a major problem - if user wants all languages, it will be forced to select them one by one - now if LINGUAS is empty, all available languages gets installed. FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS INPUT_DEVICES LINGUAS Do any of these not follow the same pattern of empty var == all installed? Any objections to making that a requirement for adding a new USE_EXPAND variable? If so, the emerge *display* issue would be no problem. This would be fine as long as LINGUAS do not appear in IUSE. When LINGUAS var is empty, the equery uses report would be an abomination . signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE_EXPAND and IUSE
Jason Stubbs wrote: So there have been many complaints about how USE_EXPANDed flags don't belong in IUSE. There haven't actually been any reasons given though. :P net-dialup/pppconfig-2.3.11-r1 depends on LINGUAS, but the list of supported languages is created in pkg_unpack, based on what tarball contains. The IUSE thing would raise 2 problems: - lower maintainability - not really a major problem - if user wants all languages, it will be forced to select them one by one - now if LINGUAS is empty, all available languages gets installed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New developer: Stefan Briesenick (sbriesen)
Tom Martin wrote: Please welcome Stefan on board. Regards, Tom The source of ISDN-related bugs has been shut down :) Congratulatons, Stefan! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] where goes Gentoo?
Chris Gianelloni wrote: On Mon, 2005-06-06 at 19:55 -0400, Aron Griffis wrote: Also I find it amusing when people say that Gentoo exists for the users. I think that is wrong. Gentoo exists for the *developers*. This is the reason why *I* use/develop Gentoo. I love it. I could care less if every single user we have drops us for Ubuntu. I would still develop Gentoo so long as it is still fun. You might reconsider this statement. Suppose the entire user base will migrate to Ubuntu. The direct consequence will be that the active dev corpus will grow thin, which will lead to a dramatic decrease of distro's merits. The dev and user communities are very close tighted together, but if analyze who needs whom, you'll realize that dev community depends on user community, not the other way around. No dev is irreplaceable, as long as we have our cluefull user base in place. Not every gentoo dev has a selfish motivation (at least not as selfish as having fun or being cool motivations). For example, my reason to becoming dev was to maintain unpopular (in dev world, of course) packages and keep b.g.o as clean as I could. I ended up taking care of 100+ ebuilds, from which only 2 (ppp and squid) interests me as a person. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: sys-pam category
Mike Doty wrote: I wonder if there is a svn interface to cvs, or if one could be written. rename/move is a feature of the svn database, not of the svn interface. also support symlinks, btw. signature.asc Description: OpenPGP digital signature
[gentoo-dev] New global useflag proposal: radius
at the moment, there are 2 radius local useflags: [+ C ] radius (net-dialup/ppp): Enables RADIUS support [+ C ] radius (net-misc/gnugk): Enables radius support but seems that net-misc/ser should also have such flag. any objections? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: New global useflag proposal: radius
Michael Sterrett -Mr. Bones.- wrote: Nothing wrong with having three packages with a local use flag. Global use flags are for use flags with global appeal/usage. So far, to me it looks like radius should stay a local use flag. Enables RADIUS support isn't general enough for ya? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev]
Henrik Brix Andersen wrote: On Sun, 2005-05-08 at 19:53 -0400, Mike Frysinger wrote: app-mobile sounds good to me ... then just use metadata.xml to include a 'fuller' description :P Please don't use app-mobile as it may be confused with mobile computing, not mobile phones. Any reason why these packages can not go into app-pda? Most modern mobile phones can be considered a handheld computer (and many of them can be thought of as either a phone with integrated PDA - or a PDA with integrated phone). I think I will call it app-mobphone. Please explain what do you understand as mobile computing. You keep using this term. From what I see in herds.xml, mobile == Wireless (802.11a/b/g, bluetooth, etc) related items Mobile phones are far from PDAs. I don't see anything you can't do with a PDA (since it _is_ a computer). Compared to them, _normal_ mobile phones are very limited devices. signature.asc Description: OpenPGP digital signature
[gentoo-dev] New category proposal
Hi folks, I think we should make a new category called app-cellphone containing the following packages: net-dialup/gammu net-dialup/gnokii net-dialup/wammu net-wireless/gnome-phone-manager Yes, I know. It is a short list, but shouldn't be a category representative for its content? Alin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: New category proposal
R Hill wrote: this doesn't include anything like VOIP of course. btw i think cellphone is an Americanism. i worked for ATT Wireless before they were bought by Cingular and the term cellphone was discouraged for that reason. maybe just app-phone? hmm... I think it should include cell or mobile in one way or the other - phone is just too generic. I am not a native English speaker (duh, what a surprise :)), so I'm open to suggestions. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] upcoming mirror cleansing
Brian Harring wrote: Why this matters- around 10,000 files out of 28,600 files will be removed from the mirrors network. Either A) no ebuild claims that distfile. it's orphaned on our mirrors B) RESTRICT=fetch is set for the ebuild. We don't mirror those files. C) RESTRICT=mirror is set for the ebuild. Again, we don't mirror those files, in this case we defer to another network (I don't make the rules, that's just how it's done) You should not erase files newer than an arbitrary amount of time (a week maybe?). Don't forget about dev.g.o:/space/distfiles-local; a dev first put the tarball in that folder _then_ submit the ebuild who use it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE_EXPAND in fritzcapi, fcdsl
Chris Gianelloni wrote: On Sat, 2005-04-23 at 08:42 +0200, Stefan Schweizer wrote: Hi, USE_EXPAND is now available to be set in the profiles. I would like to use it to allow only downloading the needed drivers in SRC_URI when FRITZCAPI_CARDS or FCDSL_CARDS is set. Any comments or objections? See http://bugs.gentoo.org/show_bug.cgi?id=84873 for the proposed ebuild. What will it do when they are unset? I surely don't want to have to set these for CD building. It will install all available drivers inside that package. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] cleaning out 'bc' and 'ed' from system
Philip Webb wrote: Ed is there because it's needed for Sed, which is useful for sysadmin; Bc has a similar usefulness. all at basic console level. sed does not depend on ed, nor does the ed depend on sed. sed should remain in system since tons of ebuild heavily depends on it. when was the last time you used ed? it is a completely useless editor, peeps use vim instead. anyway, who says you cannot install ed if you want it so bad? signature.asc Description: OpenPGP digital signature
