Re: [gentoo-dev] Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)
On 05-06-2008 22:47:28 -0700, Donnie Berkholz wrote: On 14:52 Thu 05 Jun , Samuli Suominen wrote: # Samuli Suominen [EMAIL PROTECTED] (05 Jun 2008) # Masked for removal in ~30 days by treecleaners. # Replaced by USE libffi in sys-devel/gcc. Bug 163724. dev-libs/libffi dev-lang/squeak x11-libs/gtk-server The latest version of g-wrap (1.9.11) requires the external libffi released a month or two ago, because it looks for the pkgconfig file installed by that and not gcc: - libffi is no longer distributed with g-wrap, as it is available as a stand-alone package now (instead of being burried in the GCC sources). Thoughts? They might refer to this: http://sourceware.org/libffi/ which had a recent release (3.0.5). The libffi that's in our tree right now (3.4.3) is pretty old, matching GCC-3.4.3. It originally was used for GNUstep, but that package can also work with GCC's libffi, and ffcall these days. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
On 02:35 Thu 05 Jun , Josh Saddler wrote: Now that nominations are officially open, I nominate the current council members (again): dberkholz Yes. I'd like to continue trying to make the council more effective. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Leverton wrote: | On Thursday 05 June 2008 19:21:24 Albert Zeyer wrote: | Are you sure that Squeak really depends on libffi? | | I just compiled it (squeak-3.9.7) fine without having libffi on my | system and with disabled libffi USE-flag. | | According to my reading of the code, it doesn't use libffi on x86-linux, | ppc-linux and ppc-darwin, but does on all other platforms. In any case, it | should be fine with the libffi in gcc, it's just a case of the maintainer | finding time to update the ebuild. It used to strictly depend on libffi for some earlier versions of squeak, so the DEPEND was there long before I added myself as the maintainer of the package. It isn't needed right now _unless_ you have squeak packages requiring so (and we don't have those in the tree), so it is safe to remove such a dependency and probably add a libffi USE flag conditional for those willing to use the GCC one. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhI5VQACgkQNir3WYj9aLro2QCbBm14/mBTjL0UEuSSBZwP1BSm KJEAn0EA4mzQZutzefHfsGEWIDg6LbKF =q2lC -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
On Thu, Jun 5, 2008 at 11:26 AM, Alex Howells [EMAIL PROTECTED] wrote: 2008/6/5 Ali Polatel [EMAIL PROTECTED]: I want to nominate: Fernando J. Pereda -- ferdy Bo Ørsted Andresen -- zlin Is there a method for objecting to a nomination, kinda like the opposite of seconding it? :P That would be voting...no? ;p -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
Ciaran McCreesh wrote: On Thu, 05 Jun 2008 02:35:16 -0700 Josh Saddler [EMAIL PROTECTED] wrote: Now that nominations are officially open, I nominate the current council members (again): amne betelgeuse dberkholz flameeyes jokey lu_zero vapier As per GLEP 39, I'd like all of the above to justify their slackerness. GLEP 39 is of type Informational. GLEP 1 defines Informational as follows: An Informational GLEP describes provides general guidelines or information to the Gentoo Linux community, but does not propose a new feature. Informational GLEPs do not necessarily represent a Gentoo Linux community consensus or recommendation, so users and implementors are free to ignore Informational GLEPs or follow their advice. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Ferris McCormick [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 06 Jun 2008 01:37:21 +: 2. As one of the first priorities will be setting policy for pending appeals what policy do you propose ? I'd also add two new requirements: 1. Any appeal must be heard and decided within xxx days; Not to seem disrespectful, but Or what? Seriously, or the appeal automatically succeeds.? Or, or the appeal automatically fails.? Does it matter what the appeal is (the scope of the question wasn't limited to the current situation, so the answer must apply in broad scope as well)? I'd urge being careful here, because it a similar failure to spell out the details that triggered what amounted to a bit of a constitutional crisis, tho the worst now seems past, I believe with the correct decision being made. (My thanks to all involved.) So the or what matters, as does the scope, which is why I'm asking about it. -- 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 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
Alex Howells wrote: In short: vote for me if you want less bullshit, less asshats and a more fun distribution. That is all. Damn! Astinus for PM! :) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Fri, 6 Jun 2008 01:48:03 +0100 Richard Brown [EMAIL PROTECTED] kirjoitti: On Thu, Jun 5, 2008 at 10:35 AM, Josh Saddler [EMAIL PROTECTED] wrote: Łukasz Damentko wrote: Hi guys, Nominations for the Gentoo Council 2008/2009 are open now and will be open for the next two weeks (until 23:59 UTC, 18/06/2008). Now that nominations are officially open, I nominate the current council members (again): This was the first of many nominations for the incumbent council that gave no reason as to why they should be voted for in this election, as several of them have accepted their nominations with no further qualification, and flameeyes seems to think himself above having to justify why he should be elected, so I provide, for your entertainment, the following blog posts: That's right. When a developer has certain amount of technical and /non-trivial/ commits to the tree why should he explain himself over and over again? Please, don't waste time of developers on nonsense politics. Thanks, Samuli -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
After having written this, I realized I might be telegraphing a bit too much in places. So take the amplifications for what they are worth. They are more lawyer like than my original response, but I don't see how to put them into a manifesto. On Fri, 2008-06-06 at 01:37 +, Ferris McCormick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 05 Jun 2008 19:33:34 +0100 Roy Bamford [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2008.06.05 01:00, Łukasz Damentko wrote: Hi guys, Nominations for the Gentoo Council 2008/2009 are open now and will be open for the next two weeks (until 23:59 UTC, 18/06/2008). Team, I don't want to nominate anyone who hasn't been nominated already. I would like to address all the candidates who have or will accept council nominations. 1. Please tell us how/if you plan to fix GLEP 39. (You may not consider it broken) Mostly it's not broken. However, I think the intent of the rule If any meeting has less than 50% attendance by council members,... is to prevent the council from meeting without a quorum. If at a meeting they don't have a quorum and thus don't meet, I'd consider that to be a non-meeting and treat those who did not make it just as absent under normal meeting rules. And the bit about hearing appeals assumes that devrel initiated the disciplinary action being appealed. I'd make it explicit that Council is not itself a disciplinary body --- resolving conflicts is what devrel is for among other things. 2. As one of the first priorities will be setting policy for pending appeals what policy do you propose ? Any developer making an appeal would explain why the appeal should be successful using any information he chooses, then Council would decide (deny, grant on the merits, grant on procedural grounds, whatever). I'd also add two new requirements: 1. Any appeal must be heard and decided within xxx days; 2. Any Council member who is on record as to the merits of the action being appealed could not take part in the appeal process unless the developer making the appeal allows it. Probably this would mean a discussion between that developer and the Council. Of course Council members have opinions of devrel actions, but I think it creates a potential conflict of interest if they broadcast them. Plus a few more: 3. When I say explains I mean publicly on IRC; 4. And the explanation is a dialogue --- people may ask questions of each other, request further information, and so on. 5. Procedural grounds refers to failure to follow procedure, not letting the developer appealing know what he's done to merit the discipline, not giving the developer an opportunity to respond, and such like. 6. I don't see much merit in giving devrel a role in the appeal. Whatever they have done should already have been documented. However in any specific appeal, Council should have the option to involve devrel. 3. If you are not on the council already, how will you make time for the extra work? I already have the time, really. Although I am a member of several projects in Gentoo, right now only Trustees require much time. 4. How do you think the council and trustees can work together to make Gentoo better? Not just the code base but the cooperative environment we all work together in too. Disclosure - I have a personal interest in responses as a trustee. I'm already a trustee, so having a council member who is a trustee is a start. Trustees and Council together are responsible for the smooth working of Gentoo, but with largely complementary areas of authority. So I think the two groups should begin by looking for places they both can usefully contribute and work to put cooperation there in place (Code of Conduct comes to mind because it applies to the entire community but Council is pretty much limited to developers). Then set out to put such cooperation in place. There's a lot of hand-waving in that statement because I don't have any specific mechanism for carrying it out in mind. Another idea is to sit down and look at just what Gentoo's business model is. We know there is one because the Foundation owns things like trademarks or funds (as it must because you have to have some sort of legal entity in place to do that). But the Foundation is not much involved directly in performing technical guidance, say (although I can think of cases where it might be). I personally think it makes sense to look at bringing the two closer together to look more like a traditional business (although this is perhaps a minority view). For our continued health I think we have to work toward this goal. This is badly stated. Perhaps it would help if I mentioned that in my view, Gentoo exists for its community, not just for the developers. 5. Tell us a little about yourself - the skills and experience you can bring to the council?
[gentoo-dev] Nominations open for the Gentoo Council 2008/2009
I also nominate: NeddySeagoon Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-project] Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
On 13:32 Fri 06 Jun , Ferris McCormick wrote: On Fri, 2008-06-06 at 01:37 +, Ferris McCormick wrote: And the bit about hearing appeals assumes that devrel initiated the disciplinary action being appealed. I'd make it explicit that Council is not itself a disciplinary body --- resolving conflicts is what devrel is for among other things. Yes, that is one thing devrel does. Devrel's authority to do this is delegated from the council, so it is also within the council's abilities if the council sees such action as necessary but not happening. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations for council
William L. Thomson Jr. wrote: On Tue, 2008-06-03 at 18:17 +0100, Ciaran McCreesh wrote: On Tue, 3 Jun 2008 19:11:44 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: Also, I would have thought there was a requirement to have been a developer for at least a year, just like we require mentors to have been a developer for six months. Thoughts? You're confusing Foundation and Council rules. For the Council, there aren't any restrictions on who can nominate or who can run -- GLEP 39 doesn't even include the restriction on only nominating developers. IMHO the Council should be written into the Foundation Bylaws. Replacing and deprecating GLEP 39. Which one of the first things wrt to the Council that would be mentioned in the Bylaws is the Council has full authority and veto power over the project. That means the board nor officers can dictate to the Council. Council remains on top of it all. Just legally declared, and with other rules, regulations, etc, stipulated in detail. Unlike GLEP 39 Put in a legal document, giving the Council legal power. Not just power per some GLEP or other unofficial doc, being used for a purpose other than it's intention. Much less make it easier to see and understand the structure of Gentoo to an outsider. The Gentoo Foundation and the Gentoo Council are two different entities. For further reference please refer to the FreeBSD Foundation and the FreeBSD Project. What you're implying is that the Gentoo Foundation is over/owns the Gentoo Council. Which is completely and categorically wrong. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OT Foundation - Council was - Nominations for council
On Fri, 2008-06-06 at 15:35 -0400, Doug Goldstein wrote: The Gentoo Foundation and the Gentoo Council are two different entities. But the one Gentoo Two heads one body. Usually doesn't work for most animals or humans. One ends up being a parasite to the other. For further reference please refer to the FreeBSD Foundation and the FreeBSD Project. Ok http://www.freebsdfoundation.org/about.shtml The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting the FreeBSD Project. It's clear the that BSD Foundation is directly tied to the BSD project. I am not sure what you are reading to thing otherwise. The FreeBSD Foundation will support both the development and the popularization of FreeBSD, the world's best open source operating system More so when in that page it goes into things like Development of software for FreeBSD to benefit the user and developer community, including contract development of critical system infrastructure, porting of closed source applications such as Java(TM). IMHO I would like the council to have say over matters like that with trustees/the foundation only being a liaison. What you're implying is that the Gentoo Foundation is over/owns the Gentoo Council. That is a issue of power, which has no bearings on what I am talking about. I am implying the two area attached to the same body. Thus the they should work together as a whole unit/single organization. Not this two entities crap, one body. Which is completely and categorically wrong. Provide facts to prove that. -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] OT Foundation - Council was - Nominations for council
On 15:53 Fri 06 Jun , William L. Thomson Jr. wrote: http://www.freebsdfoundation.org/about.shtml The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting the FreeBSD Project. It's clear the that BSD Foundation is directly tied to the BSD project. I am not sure what you are reading to thing otherwise. I looked through the articles of incorporation and the bylaws, under the documents section of their website. Nowhere is mentioned anything related to how the project itself is governed. It's very much a boilerplate template saying we're a nonprofit related to computers, and that's about it. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OT Foundation - Council was - Nominations for council
On Fri, 2008-06-06 at 14:13 -0700, Donnie Berkholz wrote: On 15:53 Fri 06 Jun , William L. Thomson Jr. wrote: http://www.freebsdfoundation.org/about.shtml The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting the FreeBSD Project. It's clear the that BSD Foundation is directly tied to the BSD project. I am not sure what you are reading to thing otherwise. I looked through the articles of incorporation and the bylaws, under the documents section of their website. Nowhere is mentioned anything related to how the project itself is governed. So we would be different from BSD in this regard. Are we trying to be like others? Our current structure is unlike any others. Our entire distro is unlike any other. So why are we trying to compare apples to oranges? Where is BSD's GLEP 39? Or where is their council talked about or mentioned? It's very much a boilerplate template saying we're a nonprofit related to computers, and that's about it. Instead of all this speculation. Would you all like me to open a dialog with the BSD folks and get details from within? With regard to how their foundation and project relate to each other. As for their Bylaws, if they aren't cover things we are. Is that reason for us to omit those things from ours? The BSD foundation doesn't seem to be accounting for sponsors services and etc. Does that mean we should not either? Possibly but that particular decision should be made by a Certified Public Accountant. Which I don't think any Gentoo Developer is currently. -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] OT Foundation - Council was - Nominations for council
On 17:55 Fri 06 Jun , William L. Thomson Jr. wrote: On Fri, 2008-06-06 at 14:13 -0700, Donnie Berkholz wrote: On 15:53 Fri 06 Jun , William L. Thomson Jr. wrote: http://www.freebsdfoundation.org/about.shtml The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting the FreeBSD Project. It's clear the that BSD Foundation is directly tied to the BSD project. I am not sure what you are reading to thing otherwise. I looked through the articles of incorporation and the bylaws, under the documents section of their website. Nowhere is mentioned anything related to how the project itself is governed. So we would be different from BSD in this regard. Are we trying to be like others? Our current structure is unlike any others. Our entire distro is unlike any other. So why are we trying to compare apples to oranges? Like comparing Gentoo to a single-brained animal with multiple heads? No comparisons are perfect, but that doesn't mean there's nothing to learn from them because we're so unique. Where is BSD's GLEP 39? Or where is their council talked about or mentioned? Some related pages: http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/model-orgstruct.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/sect-hats.html#ROLE-CORE http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/process-core-election.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/process-reactions.html It's very much a boilerplate template saying we're a nonprofit related to computers, and that's about it. Instead of all this speculation. Would you all like me to open a dialog with the BSD folks and get details from within? With regard to how their foundation and project relate to each other. As for their Bylaws, if they aren't cover things we are. Is that reason for us to omit those things from ours? The BSD foundation doesn't seem to be accounting for sponsors services and etc. Does that mean we should not either? Possibly but that particular decision should be made by a Certified Public Accountant. Which I don't think any Gentoo Developer is currently. It might be part of restricted income contributions on the profit loss report. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OT Foundation - Council was - Nominations for council
On Fri, 2008-06-06 at 15:23 -0700, Donnie Berkholz wrote: Like comparing Gentoo to a single-brained animal with multiple heads? But that it is. You have two entities, that both are related to Gentoo in some form. Overlapping membership, staff, interests, etc. No comparisons are perfect, but that doesn't mean there's nothing to learn from them because we're so unique. I agree 100%. My logic is cherry pick what we like from each. Thus ideas from Gnome Foundation ( paid business bull$hit advisory members ), some from BSD Foundation ( dev travel grants, equipment/infra funding ), and some from Debian ( Debconf ) It might be part of restricted income contributions on the profit loss report. I believe it has to be accounted for in some form as in kind donations. Non tangible goods and services that still have a value. Definitely if we receive them on a re-occurring basis. Even more so if other companies are using that as write off as a charitable expenses. IRS will want to compare what they are deducting is showing up on the other end. :) -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Joe Peterson wrote: The problem with a simple echo is that no * appears on the left to maintain continuity with the rest of the output - and in a color that makes sense in the context (maybe this isn't a problem - it depends on whether that visual continuity is desired). The far biggest problem of echo is IMHO that it's not part of the elog framework, which means you will see only it if you are watching the thing build. But it won't be processed by anything else set in PORTAGE_ELOG_SYSTEM, for example the echo system which reprints all gathered elog stuff from all built packages when emerge finishes, and which I find very useful. Absence of newlines there makes that however often hardly readable. Using elog commands instead of plain echo helps this, but as you mentioned, could be done better. So I'm also for some *unified* way to specify separators in elog commands. I would prefer something that doesn't add extra lines to ebuild. So how bout some switch to elog commands that adds extra newline after the message, might look better than wltjr's proposal. There could be also switch to add newline before the message but I can't think of a use for it myself. The question is how to name the switch :) -n could be confusing as echo -n has the opposite effect. Maybe -b for blank? -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OT Foundation - Council was - Nominations for council
Can you take this off-topic thread to the appropriate list? I'm pretty tired with hearing the Foundation's self-promotional comments on how important it is to development on this list. You guys have your own list for that crap, as it is. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
On Sat, 2008-06-07 at 00:42 +0200, Vlastimil Babka wrote: Joe Peterson wrote: The problem with a simple echo is that no * appears on the left to maintain continuity with the rest of the output - and in a color that makes sense in the context (maybe this isn't a problem - it depends on whether that visual continuity is desired). The far biggest problem of echo is IMHO that it's not part of the elog framework, Well I mostly included echo as a joke/pun per one of the other comments :) So how bout some switch to elog commands that adds extra newline after the message, might look better than wltjr's proposal. Crude I agree, but at least point for shorthand was understood :) There could be also switch to add newline before the message but I can't think of a use for it myself. The question is how to name the switch :) -n could be confusing as echo -n has the opposite effect. Maybe -b for blank? Or -p for preceding -t for trailing. Which would make one liner elog -pt One line with blank ones before and after -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
Doug Goldstein wrote: An clearly motivation explanation that I didn't add, which I'm going to add once I send this is the fact that as per the QA Project, use.local.desc can not contain a USE flag that already appears globally in use.desc. This would allow a description for that USE flag to be contained in the metadata. What reason does the QA Project have to disallow such thing? Is it just so that package-specific info does not concentrate in one huge file? Or is it the danger that the meaning of package-specific flags would drift too far from the global flag's meaning and lead to confusion? If it's the first, then metadata.xml seems like a good place. If the latter, then it wouldn't make much sense to approve the syntax and then disallowing it by QA :) I encourage any and all _technical_ feedback. Technically, I think linking to blogs, especially outside of g.o domain is not the best thing durability-wise :) -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
Marius Mauch wrote: It's not about forcing anyone to do something but giving people enough information on how to implement it _if they choose to do so_. With the current GLEP they'd have to make arbitrary decisions if e.g. a flag is defined in both use.local.desc and metadata.xml, or some people might think that it replaces use.local.desc completely. Really, all I'm looking for is something like This proposal does not intend to replace the existing use.local.desc format. If a flag is defined for a package in both use.local.desc and metadata.xml the latter should be preferred by tools ++ I suppose you want people to read the package-specific information and not e.g. fill bug reports caused by wrong assumptions about the flag's meaning. -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
On Sat, 07 Jun 2008 01:40:36 +0200 Vlastimil Babka [EMAIL PROTECTED] wrote: Doug Goldstein wrote: An clearly motivation explanation that I didn't add, which I'm going to add once I send this is the fact that as per the QA Project, use.local.desc can not contain a USE flag that already appears globally in use.desc. This would allow a description for that USE flag to be contained in the metadata. What reason does the QA Project have to disallow such thing? Is it just so that package-specific info does not concentrate in one huge file? Or is it the danger that the meaning of package-specific flags would drift too far from the global flag's meaning and lead to confusion? If it's the first, then metadata.xml seems like a good place. If the latter, then it wouldn't make much sense to approve the syntax and then disallowing it by QA :) As I recall, the logic was that global use flags have a single, well defined global meaning. Using use.local.desc for *refinements* wouldn't go against that, but it's a fairly badly defined line. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
On Thu, 05 Jun 2008 15:42:24 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Here's a GLEP for the addition of USE flag descriptions to package metadata. It does not address any future ideas that others may have had or suggested. It merely gives developers the necessary tools to document their USE flag usage it better detail on a per package basis. There should also be a way of referring to a use flag owned by either this or another package. For example: flag name=fooEnables support for fooing. Ignored unless flagref name=barplugin/flagref support is enabled for this package and flagref restrict=app-misc/foo name=bindingsbindings/flagref is enabled for pkgapp-misc/foo/pkg./flag But that's rather ugly... There's probably a nicer way of marking it up using XML. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
William L. Thomson Jr. wrote: On Sat, 2008-06-07 at 00:42 +0200, Vlastimil Babka wrote: There could be also switch to add newline before the message but I can't think of a use for it myself. The question is how to name the switch :) -n could be confusing as echo -n has the opposite effect. Maybe -b for blank? Or -p for preceding -t for trailing. Which would make one liner elog -pt One line with blank ones before and after The comment from Vlastimil about echo not being part of the elog system is a very valid point indeed. As for how to specify that a newline should be inserted, I think that using elog switches like -n, -p, etc., as well as putting more than one string on a line present two problems: the newline would be connected with the elog or ewarn (or whatever style of output was chosen) and it would also potentially make the ebuild code harder to read/debug. For example, if you have a block of ewarn lines, then a blank line, then a block of elog lines, you would have to decide in which style to place the special switch (so portage would not have the opportunity to do auto-context coloring/formatting). I personally would prefer a new command like eseparator that could be treated smartly by portage, taking on the appropriate color based on what is before and after. It could also avoid multiple newlines in the case in which two eseparator lines occur together due to pattern of conditional blocks in the ebuild invoked under certain circumstances (I have found this hard to code in a way that covers all possibilities, as I mentioned before). Also, separators at the very beginning or very end of all lines output by the ebuild could be handled consistently (either ignored or collapsed into an implicit separator, as appropriate) by portage to produce nice output. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Joe Peterson wrote: The comment from Vlastimil about echo not being part of the elog system is a very valid point indeed. As for how to specify that a newline should be inserted, I think that using elog switches like -n, -p, etc., as well as putting more than one string on a line present two problems: the newline would be connected with the elog or ewarn (or whatever style of output was chosen) In the ebuild it would look like connected but in fact portage could just note that there was a newline switch and output it in whatever style it wants. and it would also potentially make the ebuild code harder to read/debug. Well you can always insert a completely blank line in the ebuild after a -n message. That's easier to read than a eseparator line. For example, if you have a block of ewarn lines, then a blank line, then a block of elog lines, you would have to decide in which style to place the special switch (so portage would not have the opportunity to do auto-context coloring/formatting). Like I said above, it still has the oportunity to do whatever it wants. I personally would prefer a new command like eseparator that could be treated smartly by portage, taking on the appropriate color based on what is before and after. It could also avoid multiple newlines in the case in which two eseparator lines occur together due to pattern of conditional blocks in the ebuild invoked under certain circumstances (I have found this hard to code in a way that covers all possibilities, as I mentioned before). Also, separators at the very beginning or very end of all lines output by the ebuild could be handled consistently (either ignored or collapsed into an implicit separator, as appropriate) by portage to produce nice output. That should all be possible with the switches, unless I miss something. My idea is that a switch for post-newline is enough, and there's no need for pre-newline. You use that switch whenever you end a logical block of elog lines. Portage just notes you used it, and when another elog comes, newline is emitted first. Multiple newlines should not even happen (and if yes, could be easily collapsed). Last newline of the ebuild is just consumed. Or perhaps use this processing only for the elog post-processing system (which I personally think matters more), and during the build itself emit the newlines immediatelly so that non-elog output is not tied too closely to ends of elog blocks. -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
[gentoo-dev] Council Idea
I have an strange idea, it will probably get shot down by everyone or people will point out that it has been discussed and thought it was a bad idea but anyway... ...why not invite a developer from another distribution to join the council? I think inviting co-operation from other areas would only be of benefit. Ideas could get a fresh view, decisions would be completely unbiased and previous politics would never come into play. It may have some ancillary benefits. Close co-operation with another distribution could lead to a lasting co-operation of mutual help and collaboration and could well be a format that other distros use in the future. flame away... George (sorry if the post sounds hippie-ish) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Ferris McCormick wrote: I also nominate: NeddySeagoon Regards, Ferris I completely agree. Few people have done more behind the scenes as Roy. I would also like to nominate zmendico for his excellent work with portage. George -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council Idea
George Prowse wrote: [stuff] Take it to gentoo-project, please. This list is s'posed to be for technical discussion. gentoo-project is more appropriate for this kind of query. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
Ferris McCormick [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 06 Jun 2008 14:21:16 +: On Fri, 2008-06-06 at 09:28 +, Duncan wrote: Ferris McCormick [EMAIL PROTECTED] posted: I'd also add two new requirements: 1. Any appeal must be heard and decided within xxx days; Not to seem disrespectful, but Or what? Or it succeeds. Council may not pocket veto an appeal. Thanks. That (and the any appeal bit) has the necessary specificity. -- 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 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
Ciaran McCreesh wrote: On Thu, 05 Jun 2008 15:42:24 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Here's a GLEP for the addition of USE flag descriptions to package metadata. It does not address any future ideas that others may have had or suggested. It merely gives developers the necessary tools to document their USE flag usage it better detail on a per package basis. There should also be a way of referring to a use flag owned by either this or another package. For example: flag name=fooEnables support for fooing. Ignored unless flagref name=barplugin/flagref support is enabled for this package and flagref restrict=app-misc/foo name=bindingsbindings/flagref is enabled for pkgapp-misc/foo/pkg./flag But that's rather ugly... There's probably a nicer way of marking it up using XML. What about just nesting them? flag name foo flag name barTurns on hawt chicks/flag flag name bazTurns on welp/flag /flag Of course, you probably couldn't tell that just by looking at them, but it's an idea. Steve -- gentoo-dev@lists.gentoo.org mailing list
