Re: OT: [gentoo-dev] Nazi symbols on Gentoo (and other offending content)
On 02:27 Mon 28 Apr , Mike Frysinger wrote: > On Sunday 27 April 2008, Santiago M. Mola wrote: > > Anyway, next time I'll use @-project, and let's see if someone > > actually cares about that mailing list. > > unfortunately (fortunately?), that's the way the Gentoo community wants it. > gentoo-dev is for development only. any non-development stuff goes to the > gentoo-project list. you're most likely right there are a lot less people > subscribed there, but that is because the people who arent subscribed there > dont care about non-development issues. > > even if there may be a set of people not on the -project list but on the -dev > list, and they have an opinion on this particular topic, putting the thread > here is not appropriate. if they truly care, they can signup, fetch the > relevant mails from the archive, and respond. Here's one way to help get some more attention for the discussion you want to have, even if it's on a list with a smaller audience. As with any other topic, feel free to post a pointer on gentoo-dev-announce to tell people: what (the topic), when (when you will start the discussion), and where (the list/channel). As long as it is an announcement (and not an opinion), -dev-announce should be a good place. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Dependencies that're available at pkg_*inst
On Mon, 28 Apr 2008 05:57:04 +0100
Steve Long <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Sun, 27 Apr 2008 10:41:57 +0100
> > Steve Long <[EMAIL PROTECTED]> wrote:
> >> Use PDEPEND.
> >
> > PDEPEND has a different meaning, and isn't suitable for runtime
> > dependencies.
> >
> "PDEPEND should be avoided in favour of RDEPEND except where this will
> create circular dependency chains."[1]
> Sounds very much like it is used for runtime deps, and breaking
> RDEPEND cycles has often been given as its purpose in #-portage and
> #-dev-help, as well as in the devmanual.
Yup, but it can't break all circular dependency chains.
> >> While I like labels they need to be discussed more on-list as well
> >> as on bugzilla (it's not reasonable for you simply to advertise
> >> them and then close down discussion.) For instance, there is no
> >> reason everything has to be loaded into just one extant metadatum,
> >> not do they preclude new metadata (such as a SRC_DEP here.)
> >
> > Labels can be discussed on-list whenever there's a chance in hell of
> > Portage implementing any non-trivial new features.
> >
> That's not exactly in the spirit of collaboration (nor are your
> continuous snipes at portage.) New features should be discussed with
> a wider audience than bugzilla, not just used to advertise one impl
> and slipped in via an overlay. Further, having a consensus would
> allow pkgcore to move ahead with a more solid spec, and that /is/
> conducive to quicker implementation in portage, since those two teams
> do know how to collaborate effectively.
And if there's any chance that labels will ever be usable in the main
tree, that discussion will happen.
> 2b) seemed better. With use of PDEPEND in the manner outlined, it
> simply means pkg_{pre,post}inst can't rely on the PDEPEND'ed pkgs,
> only those in RDEPEND.
2b) isn't an option, since it's wrong. 2) is an option.
> Build-time dependencies wouldn't appear to cover the use-cases
> brought up, nor are they relevant for binary installs.
Which means in some cases binary packages are unusable where source
packages wouldn't be.
> I can see how it would be easier for the PM to be able to go for one
> or the other, but it doesn't give an ebuild author a consistent base.
> The intersection does but doesn't allow a package to call itself (one
> of the use case brought up.)
No, it means ebuilds have to be careful with dependencies if calling
themselves.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] DevRel policy update
On Sun, Apr 27, 2008 at 11:12 PM, Chrissy Fullam <[EMAIL PROTECTED]> wrote: > Wulf C. Krueger wrote: > As this change directly affects developers only, please take further > discussion to the Gentoo-core ML. I'd like to, but I appear to have been unsubscribed from that list. Assuming that my retirement and this change in policy are not unrelated, I'm afraid you appear to have not followed your own policy. The new policy reads: "The critical nature of an escalation may be determined by the Developer Relations Lead or Infrastructure, for security-related issues, that which would endanger Gentoo, or our reputation. An issue that is deemed critical does not need further justification in addition to stating which of the above situations it falls under." In the email you sent kindly sent me informing me of my retirement: > In light of the escalation and review of recent issues, you have had your > developer rights revoked for your repeated and aggravated behavior despite > numerous attempts to correct that. Gentoo will not tolerate these continued > repeat offenses and as such Developer Relations has acted under Developer > Policy: > > http://www.gentoo.org/proj/en/devrel/policy.xml. Per that policy you have > the right to appeal this decision to Gentoo Council. > You make no mention of the issue being critical, or under which of the two criteria I should have been retired under. Please ask infra to restore my access until such time as you are able to follow your own policy for conflict resolution. I'll be waiting for a proper bug that I can read that explains what I did to whom, and when and how they complained. Regards, -- Richard Brown -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: gcc-4.2 / gcc-4.3 plans
On Mon, 21 Apr 2008 18:14:37 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > the x86 cld revert is in now as well as some more upstream pr fixes. > i'll probably let things settle for this week and pending any > craziness, move gcc-4.3.0-r1 into ~arch in a week. i'll prob commit > some "obvious" gcc-4.3 bugs at the same time. > > last chance to speak up peeps. > -mike Can I get you bump the glibc req to 2.7-r2 so people don't hit the multilib bug? texinfo should be >=4.4 too (if we even use it, not sure). I want to get 4.3 running on mips sometime. We would need binutils-2.18 minimum once the gnuhash stuff gets removed. Other than that, let it loose. I'll try to get some work done on the remaining tracker bugs sometime soon. -- fonts, gcc-porting, by design, by neglect mips, treecleaner,for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
