you can really do is warn people
they may run out of space if they're using debugging options.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
obal and local flags had to be exclusive so you had to be careful about the
wording. Nowadays where you can have a local description override a global
one it's less important, but not completely so.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gen
I don't see any reason to keep this masked other than bug #416069, which
needs to be fixed anyways. How does Friday sound?
https://bugs.gentoo.org/416069 xorg-2.eclass: add --disable-selective-werror
to configure
https://bugs.gentoo.org/461954 GCC 4.8 porting
--
Ryan
On Tue, 13 Aug 2013 07:13:13 +0200
Luca Barbato wrote:
> On 13/08/13 03:41, Ryan Hill wrote:
> > I don't see any reason to keep this masked other than bug #416069, which
> > needs to be fixed anyways. How does Friday sound?
> >
> > https://bugs.gento
gt; optimization levels or so I saw reported.
I don't see how that could happen without -ftree-loop-distribute-patterns. Can
you dig up a link?
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 9
In addition to these we also enable -Wtrampolines and warn on DT_TEXTRELs.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
On Sat, 7 Sep 2013 18:10:42 + (UTC)
Martin Vaeth wrote:
> Ryan Hill wrote:
> >
> > * -fstack-protector{-all}
> > No thank you. -fstack-protector has very limited coverage
>
> I'd say it covers most cases where bugs can be made,
> practically without a
otector the default?
Now is the time to speak up.
(and for the record I've changed my mind and would like to see this go forward,
so please stop emailing me)
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
On Sun, 8 Sep 2013 11:05:16 + (UTC)
Martin Vaeth wrote:
> Ryan Hill wrote:
> > In any case this is a firm no.
> > The increase in loading times for apps that link lots of libraries is
> > significant (if it wasn't, we wouldn't need lazy loading :p).
&g
On Mon, 9 Sep 2013 08:21:35 -0400
Rich Freeman wrote:
> On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill wrote:
> > So does anyone have any objections to making -fstack-protector the default?
> > Now is the time to speak up.
>
> So, in this world of all-or-nothing we want pe
..." whenever they try to use
> upstream as an excuse to hold back progress. ;)
In this case it seems every other distro is already doing this, so we're in
good company.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
completely wrong about this. The hardened flag
filtering in flag-o-matic dumps the compiler specs (the rules that
determine what flags to use) to check if hardened features are enabled
and only negates them if they are. The quick hack I did for my testing was
failing that check so the flags w
ttle
> problems to our users. The other hardened features, however, have more
> of an impact and probably don't belong in vanilla as already discussed.
https://bugs.gentoo.org/484714
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo
Is anyone interested in maintaining poedit? It's currently covered by
wxwidgets and I check in on it a couple times a year for bumps/stabilization,
but I don't use it myself. Feel free to add yourself or take it over if you're
interested.
Thanks.
--
Ryan Hill
s, and others thought it was a good idea, but it was
always up to the discretion of the maintainer back then.
I'm not one of the offenders, just pointing out maybe some people missed the
policy change as I did.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain
.@gentoo.org allows users to effectively
>help us out as well by marking bugs they consider old.
>
>Another reason might be that we can assign related trackers to it.
Well, once you touch an old bug it won't be old anymore, so you're going to
need some way of keeping t
w that we have a version of gcc that at least understands the flag in
stable at least it wouldn't instantly break everything.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
ut to annoy some people, and then add
> a passive-agressive Changelog entry?
>
> Fix your workflow, man ... and don't cause useless warning spam if you
> can avoid it.
Oh FFS it's a USE flag. You guys have bigger fish to fry.
--
Ryan Hillpsn:
Go, I will sumarise why Portage and
> Go do not play well together.
What's wrong with gccgo? (serious question, other than making sure it builds
I haven't used it).
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864
h non-distributable stuff in
your distfiles.
Maybe we could add RESTRICT=srcdist which would cause ebuilds to save
their distfiles in a separate directory controlled by PORTDIR_NODIST or
something. If the variable is unset then it's business as usual.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
On Thu, 2 Jan 2014 06:50:06 -0600
Ryan Hill wrote:
> I've always believed that when it comes down to it all Gentoo basically does
> is provide a link to some source code and a script to build and install it.
> Unless we violate someone's license by redistributing that sour
gt; are under the same legislation, which may affect their choice.
Well, your subject line says "srcdist" ;).
That's only possible if we enumerate every license in every distfile we
distribute, which I don't think is a good idea. Or at least not on the
basis of a theoretic use
On Thu, 02 Jan 2014 11:10:54 -0500
Ian Stakenvicius wrote:
> On 02/01/14 07:50 AM, Ryan Hill wrote:
> >
> > Maybe we could add RESTRICT=srcdist which would cause ebuilds to
> > save their distfiles in a separate directory controlled by
> > PORTDIR_NODIST or something
On Thu, 2 Jan 2014 16:20:09 -0500
Rich Freeman wrote:
> On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill wrote:
> > That's only possible if we enumerate every license in every distfile we
> > distribute, which I don't think is a good idea. Or at least not on the
> >
On Thu, 2 Jan 2014 16:07:22 -0600
Ryan Hill wrote:
> On Thu, 2 Jan 2014 16:20:09 -0500
> Rich Freeman wrote:
> > Personally I don't have any use for ACCEPT_LICENSE at all, and having
> > to specify the LICENSE for every single package in the tree is a lot
> >
On Fri, 3 Jan 2014 00:53:17 +0100
Ulrich Mueller wrote:
> >>>>> On Thu, 2 Jan 2014, Ryan Hill wrote:
>
> > In case it's helpful here's what FOSSology[1] has to say about some
> > common packages that people have uploaded to their demo server.
>
&g
> ssp flag that defaults to on is fine.
This flag already exists and has always worked this way. We don't have USE
defaults yet.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
actually want to rebuild whole gcc just to do some testing on a single
> > package...
> >
> Or just as easily set -fno-stack-protector in CFLAGS in make.conf.
>
> I never felt manipulating cflags with use flags was a great idea, but in
> this case is does feel extra poi
d
prefer it but I don't have a good reason.
What gcc-config profiles get installed after this patch?
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
On Thu, 9 Jan 2014 17:41:08 -0600
William Hubbs wrote:
> On Fri, Jan 10, 2014 at 12:30:04AM +0100, Andreas K. Huettel wrote:
> > Am Freitag, 10. Januar 2014, 00:26:03 schrieb Ryan Hill:
> > >
> > > > Please avoid "noblah" use flags.
> > > >
On Thu, 9 Jan 2014 17:30:46 -0600
Ryan Hill wrote:
> On Thu, 09 Jan 2014 17:29:26 -0500
> "Rick \"Zero_Chaos\" Farina" wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 01/09/2014 05:21 PM, Michał Górny wrote:
>
quot;
-PIE_VER="0.5.8"
+PIE_VER="0.5.9-ssptest"
BTW Magnus, thanks for doing this.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
his patch, not saying it has to be this
> second, but I see this use flag as a small example of things in
> toolchain which could probably be cleaned up if fresh eyes were to see
> things.
Yes, and believe it or not I appreciate the input. I know I'm stubborn as hell
but eventually c
-fno-stack-
> protector) in glibc's common.eblit is fixed to.
Cool, I forgot about that. ;)
> So default ssp is out in the tree :)
FYI it's masked for testing for now. I will send out a news item
soon.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain
On Fri, 10 Jan 2014 15:08:02 -0500
"Anthony G. Basile" wrote:
> On 01/10/2014 10:50 AM, Ryan Hill wrote:
> > Having slept on it I'm starting to agree. My first argument was that on
> > hardened ssp is -fstack-protector-all, which is much more expensive, and it
>
y default? The majority of users will
never get the urge to install a fortran package, and the fortran eclass handles
those that do. I think it should be treated as all the other optional
languages and disabled by default, but I'd like to know if there are other
opinions.
--
Ryan Hill
en we need to emerge some package some time?
I think for most people the number of times they've upgraded gcc far outweighs
the number of times they've had to rebuild it to install a fortran package.
We should optimize for the common case.
--
Ryan Hillpsn: dirtyep
On Sun, 12 Jan 2014 09:24:20 +0100
Michał Górny wrote:
> Dnia 2014-01-12, o godz. 01:53:47
> Ryan Hill napisał(a):
>
> > fortran:
> > Do we want to keep enabling fortran by default? The majority of users will
> > never get the urge to install a fortran pack
On Sun, 12 Jan 2014 11:08:18 +0100
Michał Górny wrote:
> Dnia 2014-01-12, o godz. 03:50:53
> Ryan Hill napisał(a):
> > Bootstrapping makes distcc impossible, and you can't bootstrap these days
> > without building C and C++. Even if you're not bootstrapping, the
On Sun, 12 Jan 2014 01:53:47 -0600
Ryan Hill wrote:
> While I'm adding USE defaults to toolchain.eclass and moving them out of the
> profiles, I thought now would be a good time to review a couple default flag
> settings.
Okay, we'll be dropping fortran from the profiles a
e people time to update overlays afterwards. It
won't be hard to move to 4 after that but it'll need another deprecation cycle.
You'll have to ask Mike about glibc and binutils.
Personally I think we should always keep the latest three EAPIs around, so 4, 5,
and 6 (and 0).
--
Ryan
nd the last option isn't actually feasible because
everything in the eclass/eselect is tied directly into the SLOT.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
y revision numbers to make up for the fact that you can't
install multiple SLOTs of the same version of a package is a fucking
travesty.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
On Thu, 20 Feb 2014 11:26:18 +0200
Samuli Suominen wrote:
> Bye bye distribution level consistency :-(
The last time we had distribution level consistency was the moment between the
first and second packages getting committed to the tree.
--
Ryan Hillpsn: dirtyepic
LOTs rather than USE flags we
would need eight of them for 2.8 alone. And I don't know how we would name the
ebuilds (-r100,-r200,... ugh).
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
On Sat, 22 Feb 2014 16:09:53 -0500
Alexandre Rostovtsev wrote:
> On Sat, 2014-02-22 at 14:57 -0600, Ryan Hill wrote:
> > wxGTK not only splits up libraries by version and toolkit, but also by
> > charset and debug/release. If we had to use different SLOTs rather than
> > US
On Sat, 22 Feb 2014 15:50:17 -0600
Ryan Hill wrote:
> On Sat, 22 Feb 2014 16:09:53 -0500
> Alexandre Rostovtsev wrote:
>
> > On Sat, 2014-02-22 at 14:57 -0600, Ryan Hill wrote:
> > > wxGTK not only splits up libraries by version and toolkit, but also by
> > >
IX}/usr" \
> "${libdir}" \
> "$@" \
> configure || die "configure failed"
> else
> - CCFLAGS="${CFLAGS}" LINKFLAGS="${LDFLAGS}" "${WAF_BINARY}" \
&
ey're available, but
you'll generally have to do the legwork. And like I said, most aren't going
to be backportable.
Please take these things into consideration when deciding whether or not this
feature is worth it.
Thanks.
--
Ryan Hillpsn: di
On Sun, 20 Apr 2014 21:14:51 -0600
Ryan Hill wrote:
> Hey all,
>
> As more and more packages are starting to add LTO flags automatically through
> their build systems, I thought I'd point out a couple things:
>
> - LTO utterly destroys debug info. Flags like -g ar
stream developer mentioned it wasn't
expected to work.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
On Tue, 22 Apr 2014 08:45:31 + (UTC)
Martin Vaeth wrote:
> Ryan Hill wrote:
> >
> > One thing I forgot to mention - LTO can also have detrimental effect on
> > certain architectures. On some (eg. ppc), performance can actually
> > be degraded due to increased
y these features? Maybe we can add them to
the dev profiles for a while before we dump it on everyone.
Otherwise +1.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
On Mon, 12 May 2014 11:39:10 +0200
Tom Wijsman wrote:
> On Mon, 12 May 2014 00:47:17 -0600
> Ryan Hill wrote:
>
> > > 1. cgroup -- puts all processes spawned by ebuild to cgroup, and
> > > kills all of them once phase exits (prevents leaving orphans),
> > &g
conflict, or the former disable the latter implicitly. As Rich noted,
> we do not enable distcc by default so there's no reason why we can't
> enable conflicting options by default.
Probably best to make FEATURES=distcc disable network-sandbox then. People
enabling it a
I'm a lazy bum and I'm tired of rebasing patches that fail due to whitespace.
Is this doable or would it make the universe explode?
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49
On Thu, 15 May 2014 07:21:58 +0200
Ulrich Mueller wrote:
> >>>>> On Wed, 14 May 2014, Ryan Hill wrote:
>
> > I'm a lazy bum and I'm tired of rebasing patches that fail due to
> > whitespace. Is this doable or would it make the universe explode?
&
turned it off long long ago (and I suspect many
already have).
Test coverage is a good thing, so it'd be nice to give people an actual
incentive to do it.
So +1.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
Title: GCC 4.8.3 defaults to -fstack-protector
Author: Ryan Hill
Content-Type: text/plain
Posted: 2014-06-10
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: >=sys-devel/gcc-4.8.3
Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
enabled by default. The 4.8 series w
On Tue, 10 Jun 2014 04:31:27 +0200
Jeroen Roovers wrote:
> On Mon, 9 Jun 2014 18:16:02 -0600
> Ryan Hill wrote:
>
> > Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
> > enabled by default.[..]
>
> .. on supported architectures.
>
>
>
On Tue, 10 Jun 2014 09:48:53 -0400
"Anthony G. Basile" wrote:
> On 06/10/14 10:35, Magnus Granberg wrote:
> > tisdag 10 juni 2014 14.22.11 skrev Jeroen Roovers:
> >> On Mon, 9 Jun 2014 21:46:56 -0600
> >>
> >> Ryan Hill wrote:
> >>>
On Tue, 10 Jun 2014 14:22:11 +0200
Jeroen Roovers wrote:
> On Mon, 9 Jun 2014 21:46:56 -0600
> Ryan Hill wrote:
>
> > Yes. But now you've got me worried. We have to build gcc itself with
> > -fno-stack-protector. Does compiling something with that flag give
> &g
v2: Restrict by arch
--
Title: GCC 4.8.3 defaults to -fstack-protector
Author: Ryan Hill
Content-Type: text/plain
Posted: 2014-06-10
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: >=sys-devel/gcc-4.8.3
Display-If-Keyword: amd64
Display-If-Keyword: arm
Display-If-Keyword: mips
Display
a git repo. Actually migrating the tree itself to git is
> largely a solved problem.
Weren't we also waiting for some gpg signing stuff to land?
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
y, but that's why we added 4.8.2-r1
half a year ago so people could test it. Did anyone actually try it out? I
honestly want to know - if no one is testing masked versions then there's no
point keeping them masked for as long as I usually do.
--
Ryan Hillpsn: dirt
gt; should be encouraging people to add the flag and report bugs, and if a
> package doesn't work with it and doesn't strip it I think we should
> consider it a package bug now.
I think if a package breaks with any of the -f/-g flags that strip-flags
considers safe it's a legitim
gt; dev/vapier (96 days ago)
> dev/dirtyepic (113 days ago)
> proj/gnustep (129 days ago)
> proj/alt (148 days ago)
Are only these being migrated? That's what the bug implies but I'm confused by
"all remaining repos" above.
--
Ryan Hillpsn: dirty
are still in broken stage.
Do that and we'll have to take you out behind the woodshed.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
i686 crossdev toolchain on
x86_64 breaks things, it's because you've done something dumb. Stop doing
that and things should work better.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
lone and shouldn't be considered an
"upstream" response.
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
In the meantime I don't want to be responsible for
holding up any work while I figure things out.
Thanks,
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc
Description: PGP signature
Michael Cummings wrote:
> OK, I attempted this in November of 05 (then forgot?), but since no one
> responded to my last round, it has been removed. Happy gentoo'ing,
*yay*
--de.
signature.asc
Description: OpenPGP digital signature
Harald van Dijk wrote:
> On Wed, Jun 21, 2006 at 05:20:47PM +0200, Carsten Lohrke wrote:
>> On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote:
>>> qt3 - enable optional qt3 support
>>> qt4 - enable optional qt4 support
>> That will be a mess to support in the long run.
>
> Why?
Ditto. Can a
Donnie Berkholz wrote:
> My options are either missing important announcements or creating this
> list. I would prefer the list.
What important announcements are you expecting to find at the bottom 50-100
posts of random relevance? The announcements are at the top, being the thing
that triggered
Chris Gianelloni wrote:
> OK, guys, I was speaking with vapier earlier about the possibility of
> getting gcc 4.1.1 stable for the 2006.1 release. We've managed to build
> some release media with it, and are planning on doing more testing with
> it. What we really need is for more people to test
Denis Dupeyron wrote:
> In bug #139412, I ask Paul de Vriese why he thinks python should die
> on --fast-math instead of just filtering it. Here's his answer :
>
> "Denis, quite simple. -ffast-math is broken and short-sighted for a
> global flag.
> Filtering gives the shortsighted message that it
Denis Dupeyron wrote:
> Correct me if I'm wrong, but this has nothing to do with being
> interactive or not. To me, an ebuild that dies (intentionally or due
> to a build error) isn't interactive at all.
Their phrase, not mine. ;) I think the idea is you should be able to emerge -e
world and wal
Denis Dupeyron wrote:
> Well yes, but an ebuild that dies, whatever the reason, hasn't much to
> do with interactivity.
Fine. Call it the don't-kill-the-emerge-for-silly-reasons philosophy if you
like. I personally don't prefer it, but a lot of people think it's a good idea.
> What will follow
Ryan Hill wrote:
> 2.95.3, 3.1.1, 3.2.2, 3.2.3, 3.3.2, 3.3.5, 3.3.6, 3.4.1, 3.4.4, 3.4.5, 3.4.6,
My bad, 3.2.2 is masked for everyone ATM.
--de.
signature.asc
Description: OpenPGP digital signature
Chris Gianelloni wrote:
> On Sat, 2006-07-01 at 12:18 -0600, Ryan Hill wrote:
>> Should arch testers start working with 4.1.1 then? And do you want bugs to
>> block #117482?
> Arch testers should contact their architecture's leads or Release
> Engineering Architectur
Paul de Vrieze wrote:
> My argument is that we must not filter -ffast-math or any other dangerous
> cflags. The reason being that people will request more filters for all
> packages that don't work with it. Many users will either ignore or miss the
> warning messages. Filtering the flag basical
Ryan Hill wrote:
> Just an update - I've finished most major desktop stuff for x86 without any
> problems. I'm moving onto stuff that's already on the tracker and is fixed in
> testing but not stable. Rather than open and track a ton of new bugs, I'd
> like
>
Simon Stelling wrote:
> Hi all,
>
> I just noticed that the USE flag 'firefox' is a local one. I think it should
> be
> global, though:
If this happens, could you also close
https://bugs.gentoo.org/show_bug.cgi?id=96473 :)
--de.
signature.asc
Description: OpenPGP digital signature
Chris Gianelloni wrote:
> (stuff)
"Me too!"
Seriously, you nailed it on the head. How many times have you had this
conversation:
u: "Why is it taking so *!#$!@ long to get KDE/Gnome/XFCE stabilized?!
Fedora/Debian/Ubuntu got it a whole week ago! OMG!!1!"
d: "It'll be stabilized once it's a
Richard Fish wrote:
On 7/27/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
The "majority" of packages are also the ones that need more extensive
testing. Sure, we could probably stabilize a bunch of the fringe
packages that hardly anyone uses and it wouldn't affect anything.
The majority
Luis Francisco Araujo wrote:
The 'modus-operandi' would go like this:
1 - We setup a mailing list (yes, yet another one, but this one is gonna
be useful!) , call it , [EMAIL PROTECTED] , or [EMAIL PROTECTED]
2 - Developers interested to serve as a proxy , subscribe to the list.
3 - Users ask
Alec Warner wrote:
Another class of packages I wish to discuss (not remove quite yet, just
talking ;) ) are older packages with stable markings. By Stable I mean
debian stable, IE we stabled it in 2004 and no one has touched it since.
Do these packages still work with a current system (linux 2
Alec Warner wrote:
I'm not sure if I'm misreading here, I'm not advocating we dump older
gcc versions. Moreso I'm advocating we dump code that doesn't compile
with newer gcc/toolchain versions that no one is willing to fix. We
have had devs in the past bring in far too many packages and then j
Ciaran McCreesh wrote:
On Sun, 30 Jul 2006 23:20:16 -0500 "Alex Tarkovsky"
| This "no QA" accusation is a complete myth. QA led by actual Gentoo
| developers is indeed in place at Sunrise [1].
Did you look at *which* actual Gentoo developers are on the list?
You know, that was a completely u
Ciaran McCreesh wrote:
On Sun, 30 Jul 2006 23:22:33 -0600 Ryan Hill <[EMAIL PROTECTED]>
| Ciaran McCreesh wrote:
| > Did you look at *which* actual Gentoo developers are on the list?
|
| You know, that was a completely unnecessary personal attack. God
| forbid anyone take th
Raphael Marichez wrote:
> app-doc/chmlib is without an active ebuild maintainer and has an open
> security
> bug [1]
>
> Anyone willing to take care of this package in the future, please update
> metadata.xml and CC yourself on the bug.
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=143181
Chris Gianelloni wrote:
No. It really should be inline. I'm sorry if you think that 5K seems
like a lot of "spam" but having to open a browser just to look at
"emerge --info" is a complete waste of time.
*ding*
it's also nice to have that information actually _in_ my mailbox and not
of at
Duncan wrote:
Matti Bickel <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
excerpted below, on Thu, 10 Aug 2006 23:59:51 +0200:
Thomas Cort <[EMAIL PROTECTED]> wrote:
Why do arch testers need to post `emerge --info` if everything works?
Shouldn't we be able to trust that they have sane CFLAGS,
Jeroen Roovers wrote:
On a minor note, I'd also like to see bug reporters use canonical
package names in bug descriptions, including the category (and
preferably the specific version, not some >=foo-3*!!!one, not to
mention specifying no version at all). Including the category means
arch devs won
Just a reminder that GCC 4.1 will be going stable on x86 and amd64 very
shortly (according to GWN at least), and is already stable on PPC. If
you have any bugs blocking bug #140707 [i] please have a look and CC the
relevant arch teams for stabilization. I'll be pinging bugs that
haven't seen
Wernfried Haas wrote:
As far i am concerned, i find seperate sections quite good as it's a
clear solution as it's easy to see who is an official Gentoo monkey
who did all the quiz stuff etc. May be subject to personal taste though.
Some of the unofficial monkeys have also done the quiz stuff e
Carsten Lohrke wrote:
we're understaffed, partly - and this is my very personal opinion - the
problem is that releasing with GCC 4.x has been rushed
I'd have to agree with you on that. I understand the appeal of exciting
press releases but there were over 75 GCC 4.1 bugs still open for
prob
Alec Warner wrote:
needs as far as QA. Last year Halcy0n petitioned for power for the QA
team; it was quite like a ball crushing power (fix it or we will) and it
seemed to have all kinds of frictional issues. This being a global
issue I would like to hear thoughts on how this could be done bett
Stuart Herbert wrote:
GCC I suspect is surrounded by more confusion. Either the package
maintainers or the arch teams could have made an announcement giving
fair warning; alas, neither did.
It was announced on June 27th and was in more than one issue of the GWN
since then.
--de.
--
gentoo
Kevin F. Quinn wrote:
If you don't care whether a package is stable or not, just let the arch
team go ahead and do what they need to do to stabilise when they wish
to. The role of package maintainer has nothing to do with
stabilisation, which is the preserve of the arch teams.
Um, sure it does
301 - 400 of 906 matches
Mail list logo
