[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse
Ryan Hill wrote: > If your build system sets -ffast-math or -fstrict-aliasing > then the user can disable this by setting -fno-fast-math > or -fno-strict-aliasing in their CFLAGS. Just because some flags have "counter"-flags by accident, this does not hold for all flags. It is more reasonable to have other means that the flags are not modified in the first place. In fact, when I first introduced adding of CFLAGS, there were lot of complaints that this is evil and must not be done. I can understand this point of view (even if I know that certain CFLAGS should be used with the code and I would also prefer to have them to find possibly hidden bugs), so we compromised by having an option: With this option everybody could live well, since users with special settings will not run into trouble because undesired flags are added, and other users could just select the USE flag and have the benefits of appropriately optimized code. Up to now, that is, when we have this IMHO needless discussion that an option should not be an option. I hope that this answers also the question of Alec Warner : : I am confused. If you want the users to use a default set of CFLAGS : you should set this in your build system (autotools, cmake, whatever). : [...] : I believe the above link seems to describe what you are looking to do : using autotools. Technically, I have no problem to force in configure.ac that certain CFLAGS are used (unless somebody patches the configure.ac, of course). The problem is that it is not good to force this if the user disagrees (or maybe even unless he explicitly agrees), i.e. it should be an option which the user really has. (If this option should only be documented in some INSTALL text or in the ./configure output, most users do not really have this option, because they would not even know about it.) Best Regards Martin
Re: [gentoo-dev] Council manifesto of sping
Hey Sebastian, On 30 June 2010 06:15, Sebastian Pipping wrote: > Arun, [...] >> And another one for "More direct democracy": >> >> a) How would you decide what questions go up for public vote and which >> ones stay with the council? > > Good question! I think a few voices from developers (say three) > requesting a vote should force a global vote. If the council were > deciding on that, the concept would be useless. At least that's my > current understanding. > > >> b) For questions like "- Should Python 3.x be stable?", isn't that for >> team leads to decide? And for the council to resolve in case of >> conflicts? > > It's too important to leave it to the Python team alone in my eyes. > Previous threads have shown that consensus is hard to find on Python 3.x > related topics. A direct vote from all developers would reveal what the > majority really wants for that topic. It is my opinion that dismissing the opinions of the people who are actually doing the work is not a good way to motivate the same people (I don't even disagree with you about the Python team's approach to 3.x in the tree, but I disagree with how you think it should be handled). >> c) For questions like "- Should developer X be banned?", would you be >> willing to do this if it meant a lot of washing of dirty linen in >> public, or protracted flamewars (and other reasons why we have a bunch >> of level-headed people in place to deal with this calmly and quietly)? >> If no, where would you draw the line? If yes, how would you deal with >> the fallout? > > I'm not understanding all of that, honestly. > On a part I understood: Solving isues on that front may be worth extra > "noise" as the goal is to noticably improve atmosphere after. > Please help me to understand the rest of your question. The problem is not noise. The problem is that an issue that needs to be escalated to Devrel could not be resolved by the involved developers or the people who were present at the time. Moreover, there are strong emotions from the devs (and often their friends too), and people will end up saying things that they may eventually regret. Dragging this out in public /will/ polarise the community, result in more public conflict, very likely without a complete picture of the story on both sides being available. Devrel's purpose is to avoid this, and I believe this does work (we can debate their efficacy or how things can improve, but saying it doesn't work is unfair, IMO). I don't see how your proposal would deal with this fallout. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
[gentoo-dev] Council manifesto of the bonsaikitten
With only a few hours left to vote y'all might be wondering "What happened to Patrick's manifesto?" Short version - I'm not in the mood to write long speeches about things I won't manage to do. We have lots of technical issues to discuss and decide on (like the recent as-needed discussion, again, for about the 3rd time since 2008). There's the social aspect - how do we want to interact with each other? Although I'm unsure how the council is the right place to solve personal issues. Etc. etc. Many things that need to get done, but which every one of you needs to present to the council. As far as I know we don't have telepaths around, so it's your job to remind us. And every single dev should vote. Or Else!!!1 The last years have had a rather low voter count. There's no reason for you to ignore such things, so use the last ~36h to vte. I guess I'll just continue spending most of the time picking up unmaintained herds and reviving them, recruiting awesome new people and fixing stuff where I see breakage. Fixing one bug a day still sounds like a good challenge to every dev (and everyone who might want to become one too ...) And I still won't care how you feel about bugs, because bugs are facts that can't be reasoned with. Just fix things, or get out of the way and let me/us/anyone get things into a better shape. My white unicorn, so to speak, is reviving the GWN/GMN. I've been wanting to do it, but then I know that it'll eat lots of time I won't have left for other things. But it used to be pretty neat when it still existed. Who am I? Just a random person. At the moment I'm a freelance admin/programmer/whateveryouneed, working as a recruiter for Linux Lancers, a Gentoo dev, and a few other things I guess. Feel free to hire / motivate / bribe me any way you want. So that's already more than I intended to write Be excellent to each other! Patrick
Re: [gentoo-dev] Council manifesto of sping
Arun, On 07/02/10 16:23, Arun Raghavan wrote: > The problem is not noise. The problem is that an issue that needs to > be escalated to Devrel could not be resolved by the involved > developers or the people who were present at the time. Moreover, there > are strong emotions from the devs (and often their friends too), and > people will end up saying things that they may eventually regret. > > Dragging this out in public /will/ polarise the community, result in > more public conflict, very likely without a complete picture of the > story on both sides being available. Devrel's purpose is to avoid > this, and I believe this does work (we can debate their efficacy or > how things can improve, but saying it doesn't work is unfair, IMO). I > don't see how your proposal would deal with this fallout. I think we're mixing up a few things by now: - What cases should be handled in public, which shouldn't - Does DevRel work effectively or not - The special case of banning people All I want to say right here is that: - Not everything needs to be handle loudly and public (if I made that impression) - I do believe in need for fundamental changes on DevRel (as introduced in a another thread earlier) For the rest I propose to take this offline. Best, Sebastian
Re: [gentoo-dev] Council manifesto of sping
On Fri, Jul 2, 2010 at 9:20 PM, Sebastian Pipping wrote: > I think we're mixing up a few things by now: > - What cases should be handled in public, which shouldn't > - Does DevRel work effectively or not > - The special case of banning people > > All I want to say right here is that: > - Not everything needs to be handle loudly and public > (if I made that impression) > - I do believe in need for fundamental changes on DevRel > (as introduced in a another thread earlier) > > For the rest I propose to take this offline. > I am interested in your viewpoint on the rest as well. If you do continue this discussion offline, I'd like the results of that to be reflected in a public way (as v2 of your manifesto perhaps?) so that me, as well as others who are interested in your view points as a council nominee are kept up-to-date on them. Thanks! -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Over using preserve_old_lib, don't do that
On Friday, July 02, 2010 01:51:25 Samuli Suominen wrote: > I've recently stumbled upon several packages unnecessarily using old > preserve_old_lib feature from eutils.eclass, namely: > > libgnomekbd > libproxy > > And then users hit issues like this: > > https://bugs.gentoo.org/show_bug.cgi?id=326517#c5 > > Please only use the preserve_old_lib function in case of breaking: > - or the library is so widely used that revdep-rebuilding the system > would be nearly impossible without having the old lib around since > revdep-rebuild (emerge) can't get the emerge ordering right (because of > overlinking and lack of asneeded by default, namely jpeg and png comes > into mind) i dont know how critical libgnomekbd is to the general running of GNOME, but if all GNOME apps break because of it, then that is a valid use case. upgrading a library that the whole desktop env cascades upon should not result in the inability to log in (i.e. being forced to work in a Linux console shell to recover things). that bug report looks to me like the user not reading the output where they have to delete the file themselves. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse
On Fri, 2 Jul 2010 15:29:44 +0200 (CEST) Vaeth wrote: > Ryan Hill wrote: > > > If your build system sets -ffast-math or -fstrict-aliasing > > then the user can disable this by setting -fno-fast-math > > or -fno-strict-aliasing in their CFLAGS. > > Just because some flags have "counter"-flags by accident, > this does not hold for all flags. It is more reasonable to have > other means that the flags are not modified in the first place. I can't think of any flags that don't have a corresponding counter flag, other than -m flags. At least, all -f and -W flags have opposite -fno and -Wno versions, even if they're not explicitly documented. > In fact, when I first introduced adding of CFLAGS, there were > lot of complaints that this is evil and must not be done. > I can understand this point of view (even if I know that > certain CFLAGS should be used with the code and I would also > prefer to have them to find possibly hidden bugs), so we > compromised by having an option: > With this option everybody could live well, since users with > special settings will not run into trouble because undesired > flags are added, and other users could just select the USE flag > and have the benefits of appropriately optimized code. > Up to now, that is, when we have this IMHO needless discussion > that an option should not be an option. If you as upstream have written your code in a way that it benefits from certain flags (like -ffast-math, -fstrict-aliasing, -fvisibility-hidden, etc.) then I think enabling those flags by default is the right thing to do. There are many packages in the tree that do this, so if people are complaining about it then it's their problem, not yours. ;) > I hope that this answers also the question of > Alec Warner : > > : I am confused. If you want the users to use a default set of CFLAGS > : you should set this in your build system (autotools, cmake, whatever). > : [...] > : I believe the above link seems to describe what you are looking to do > : using autotools. > > Technically, I have no problem to force in configure.ac that certain > CFLAGS are used (unless somebody patches the configure.ac, of course). > The problem is that it is not good to force this if the user disagrees > (or maybe even unless he explicitly agrees), i.e. it should be an > option which the user really has. (If this option should only be > documented in some INSTALL text or in the ./configure output, > most users do not really have this option, because they would not > even know about it.) Maybe the best option in this case really is to use "custom-cflags". This gives the user the option of explicitly opting out of your recommended configuration, while the majority would build the package to your specifications. I think this would make everyone happy (?). -- fonts, gcc-porting, and it's all by design toolchain, wxwidgetsto keep us from losing our minds @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse
On Friday, July 02, 2010 16:39:57 Ryan Hill wrote: > On Fri, 2 Jul 2010 15:29:44 +0200 (CEST) Vaeth wrote: > > Ryan Hill wrote: > > > If your build system sets -ffast-math or -fstrict-aliasing > > > then the user can disable this by setting -fno-fast-math > > > or -fno-strict-aliasing in their CFLAGS. > > > > Just because some flags have "counter"-flags by accident, > > this does not hold for all flags. It is more reasonable to have > > other means that the flags are not modified in the first place. > > I can't think of any flags that don't have a corresponding counter flag, > other than -m flags. At least, all -f and -W flags have opposite -fno and > -Wno versions, even if they're not explicitly documented. and this isnt "by accident", this is in the fundamental design of gcc argument processing. the only -f/-W flags that lack this are rare exceptions. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Gentoo Council 2010/2011 - Voting - Reminder
On 2010.06.19 20:56, Roy Bamford wrote: > Team, > > Everything is in place to allow voting in the above election commence > as planned on June 20th at 00:00:00 UTC. > > The polls will remain open until July 3rd 23:59:59 UTC. > [snip] Thats about 25 hours from now ... and so far, the turnout is only 29% -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/pedro: metadata.xml ChangeLog pedro-1.5.ebuild
On Fri, 2 Jul 2010 23:59:34 + (UTC), "Keri Harris (keri)"
wrote:
> Index: pedro-1.5.ebuild
> ===
> # Copyright 1999-2010 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: /var/cvsroot/gentoo-x86/net-misc/pedro/pedro-1.5.ebuild,v
> 1.1 2010/07/02 23:59:34 keri Exp $
>
> EAPI=1
>
> inherit eutils
Why do you need to inherit eutils? Nothing uses it.
>
> DESCRIPTION="Pedro is a subscription/notification communications system"
> HOMEPAGE="http://www.itee.uq.edu.au/~pjr/HomePages/PedroHome.html";
> SRC_URI="http://www.itee.uq.edu.au/~pjr/HomePages/PedroFiles/${P}.tgz
> doc? ( mirror://gentoo/${PN}-manual-${PV}.tar.gz )"
>
> LICENSE="GPL-2"
> SLOT="0"
> KEYWORDS="~amd64 ~ppc ~sparc ~x86"
> IUSE="doc examples"
>
> DEPEND="dev-libs/glib:2"
>
> S="${WORKDIR}"/${P}
>
> src_unpack() {
> unpack ${A}
> cd "${S}"
> }
This is the default src_unpack and can be dropped.
>
> src_compile() {
> econf || die "econf failed"
> emake || die "emake failed"
> }
econf() doesn't need "|| die" but furthermore, this is the default
src_compile and can be dropped.
>
> src_install() {
> emake DESTDIR="${D}" install || die "emake install failed"
>
> dodoc AUTHORS README
>
> if use doc ; then
> dodoc "${WORKDIR}"/${PN}.pdf
> fi
>
> if use examples ; then
> insinto /usr/share/doc/${PF}/examples
> doins src/examples/*.{c,tcl}
> doins src/java_api/*.java
> doins src/python_api/*.py
> fi
> }
Those are just cosmetic fixes above, but this should be fixed:
* QA Notice: Files built without respecting LDFLAGS have been detected
* Please include the following list of files in your report:
* /usr/bin/pedro
* /usr/bin/ptick
Thanks,
Jeremy
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/pedro: metadata.xml ChangeLog pedro-1.5.ebuild
On Saturday 03 July 2010 12:33:17 Jeremy Olexa wrote:
> On Fri, 2 Jul 2010 23:59:34 + (UTC), "Keri Harris (keri)"
>
> wrote:
> > Index: pedro-1.5.ebuild
> > ===
> > # Copyright 1999-2010 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> > # $Header: /var/cvsroot/gentoo-x86/net-misc/pedro/pedro-1.5.ebuild,v
> > 1.1 2010/07/02 23:59:34 keri Exp $
> >
> > EAPI=1
> >
> > inherit eutils
>
> Why do you need to inherit eutils? Nothing uses it.
>
> > DESCRIPTION="Pedro is a subscription/notification communications system"
> > HOMEPAGE="http://www.itee.uq.edu.au/~pjr/HomePages/PedroHome.html";
> > SRC_URI="http://www.itee.uq.edu.au/~pjr/HomePages/PedroFiles/${P}.tgz
> >
> > doc? ( mirror://gentoo/${PN}-manual-${PV}.tar.gz )"
> >
> > LICENSE="GPL-2"
> > SLOT="0"
> > KEYWORDS="~amd64 ~ppc ~sparc ~x86"
> > IUSE="doc examples"
> >
> > DEPEND="dev-libs/glib:2"
> >
> > S="${WORKDIR}"/${P}
> >
> > src_unpack() {
> >
> > unpack ${A}
> > cd "${S}"
> >
> > }
>
> This is the default src_unpack and can be dropped.
>
> > src_compile() {
> >
> > econf || die "econf failed"
> > emake || die "emake failed"
> >
> > }
>
> econf() doesn't need "|| die" but furthermore, this is the default
> src_compile and can be dropped.
>
> > src_install() {
> >
> > emake DESTDIR="${D}" install || die "emake install failed"
> >
> > dodoc AUTHORS README
> >
> > if use doc ; then
> >
> > dodoc "${WORKDIR}"/${PN}.pdf
> >
> > fi
> >
> > if use examples ; then
> >
> > insinto /usr/share/doc/${PF}/examples
> > doins src/examples/*.{c,tcl}
> > doins src/java_api/*.java
> > doins src/python_api/*.py
> >
> > fi
> >
> > }
>
> Those are just cosmetic fixes above, but this should be fixed:
>
> * QA Notice: Files built without respecting LDFLAGS have been detected
> * Please include the following list of files in your report:
> * /usr/bin/pedro
> * /usr/bin/ptick
Thanks for the comments. I'll take care of these.
Keri
