[gentoo-dev] Re: [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[Ryan Hill]

On Sun, 15 May 2016 21:35:41 +0200
rindeal  wrote:

> apart from the tests, the patch now looks like this:

Please posts the tests too.

-- 


pgpudg4Ys0VCN.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ryan Hill]

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman  wrote:

> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:  
> > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> > >> On Sat, 7 May 2016 23:25:58 +0200
> > >> 
> > >> Michał Górny  wrote:  
> > >> > Do you seriously expect this code to work? How about testing? Or
> > >> > reading diffs before committing?  
> > > 
> > > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > > and Michal pointed that out very plainly.  
> > 
> > It is actually possible to communicate both plainly and politely at
> > the same time.  This does not require sacrificing any commitment to
> > quality at all.  Really the only downside is having more of an
> > appearance of professionalism.  
> 
> Please enlighten me as to what was impolite here?  The strong language of 
> "seriously" or definitively stating that the individual did not perform the 
> necessary QA actions before committing?  Both of which are completely called 
> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
> How would you have responded professionally?

I thought his response was pretty tame actually.  If you break the tree
because you couldn't be bothered to do the barest minimum of testing you
absolutely deserve to be called out on it.

But if you guys just want to hug it out that's cool too.

-- 


pgp6v204Sg7ZU.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ryan Hill]

On Sat, 7 May 2016 23:25:58 +0200
Michał Górny  wrote:

> On Sat,  7 May 2016 21:19:31 + (UTC)
> "Joerg Bornkessel"  wrote:
> 
> > commit: 66afcab271f65b97330e610040ad3acc1b812a03
> > Author: Joerg Bornkessel  gentoo  org>
> > AuthorDate: Sat May  7 21:18:48 2016 +
> > Commit: Joerg Bornkessel  gentoo  org>
> > CommitDate: Sat May  7 21:18:48 2016 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
> > 
> > fixed einstall vs. emake install for eapi=6
> > 
> >  eclass/vdr-plugin-2.eclass | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
> > index ae09a34..65f1409 100644
> > --- a/eclass/vdr-plugin-2.eclass
> > +++ b/eclass/vdr-plugin-2.eclass
> > @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
> > local SOFILE_STRING=$(grep SOFILE Makefile)
> > if [[ -n ${SOFILE_STRING} ]]; then
> > BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install 
> > }}
> > -   einstall ${BUILD_PARAMS} \
> > +   if [[ ${EAPI} == 6 ]]; then
> > +   emake install ${BUILD_PARAMS} \
> > +   else
> > +   einstall ${BUILD_PARAMS} \
> > +   fi
> > ${BUILD_TARGETS} \
> > TMPDIR="${T}" \
> > DESTDIR="${D}" \
> >   
> 
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?

I reverted this commit since it broke sourcing any ebuild inheriting the eclass.

I'm going to assume this commit was made by accident, since any dev that would
commit code to an eclass without testing that it works, or even that it's
_valid bash_, would not continue to have unsupervised commit rights for very
long.


-- 


pgpJLToyOs0hS.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: games.eclass policy

[Ryan Hill]

On Thu, 18 Feb 2016 08:08:48 +0100
Michał Górny  wrote:

> On Wed, 17 Feb 2016 18:06:29 -0700
> Denis Dupeyron  wrote:
> 
> > On Wed, Feb 17, 2016 at 11:38 AM, Michał Górny  wrote:  
> > >
> > > Well, maybe it's because you can talk to Python team, discuss and not
> > > get ignored by them.
> > 
> > We've already established the same is true for the games team. I'm a living
> > example of it and I can't imagine I'm the only one.  
> 
> Good for you. So... ignoring majority is fine as long as you can prove
> that they don't ignore one of their old fellows. Good.

I have never had a problem talking to the games team, and I suspect the same is
true for anyone who isn't just communicating with them to push their agenda.





-- 


pgppW1x55i9ei.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: RFC: intel-sdp-r1.eclass

[Ryan Hill]

On Mon, 15 Feb 2016 15:35:12 +0100
Michał Górny  wrote:
> On Mon, 15 Feb 2016 14:37:41 +0100
> "Justin Lecher (jlec)"  wrote:
> > On 15/02/16 13:59, Michał Górny wrote:  
> > > On Mon, 15 Feb 2016 09:16:53 +0100
> > > "Justin Lecher (jlec)"  wrote:
> > >> _isdp_big-warning() {
> > >>  debug-print-function ${FUNCNAME} "${@}"
> > >>  case ${1} in
> > >>  pre-check )
> > >>  echo ""
> > > Don't mix echo with ewarn.
> > Why?  
> Because they won't go through the same output channels.

That's kinda the point.  You want a blank (unstarred) space
to separate out the "important" messages from the generic
spew put out by the package manager/eclasses/build system
that you have no control over.

If you have several different messages you want a blank space
in between them so you can use e* to create whitespace within
the message to avoid the wall of text syndrome while still
making it clear where it begins and ends.

Let's take openrc for example (not picking on anyone, it's just
the last package with a bunch of different post-install messages
I happened to emerge).

Currently:

 * The OpenRC dependency data has already been migrated.
 * Caching service dependencies ... [ ok ]
 * In this version of OpenRC, the loopback interface no longer
 * satisfies the net virtual.
 * If you have services now which do not start because of this,
 * They can be fixed by adding rc_need="!net"
 * to the /etc/conf.d/ file.
 * You should also file a bug against the service asking that
 * need net be dropped from the dependencies.
 * The bug you file should block the following tracker:
 * https://bugs.gentoo.org/show_bug.cgi?id=439092
 * 
 * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
 * fixed correctly in earlier versions of OpenRC.
 * The correct fix is implemented in this version, but that
 * means netmount needs to be added to the default runlevel if
 * you are using nfs file systems.
 * 
 * You should now update all files in /etc, using etc-update
 * or equivalent before restarting any services or this host.

This is pretty much unreadable to me.

Better:

 * The OpenRC dependency data has already been migrated.
 * Caching service dependencies ... [ ok ]
 *
 * In this version of OpenRC, the loopback interface no longer
 * satisfies the net virtual.
 *
 * If you have services now which do not start because of this,
 * They can be fixed by adding rc_need="!net"
 * to the /etc/conf.d/ file.
 *
 * You should also file a bug against the service asking that
 * need net be dropped from the dependencies.
 *
 * The bug you file should block the following tracker:
 * https://bugs.gentoo.org/show_bug.cgi?id=439092
 * 
 * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
 * fixed correctly in earlier versions of OpenRC.
 *
 * The correct fix is implemented in this version, but that
 * means netmount needs to be added to the default runlevel if
 * you are using nfs file systems.
 * 
 * You should now update all files in /etc, using etc-update
 * or equivalent before restarting any services or this host.

This is better but you still have to read the whole thing to
make sure you didn't miss anything important.

Even better:

 * The OpenRC dependency data has already been migrated.
 * Caching service dependencies ... [ ok ]

 * In this version of OpenRC, the loopback interface no longer
 * satisfies the net virtual.
 *
 * If you have services now which do not start because of this,
 * They can be fixed by adding rc_need="!net"
 * to the /etc/conf.d/ file.
 *
 * You should also file a bug against the service asking that
 * need net be dropped from the dependencies.
 * The bug you file should block the following tracker:
 *
 * https://bugs.gentoo.org/show_bug.cgi?id=439092
 
 * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
 * fixed correctly in earlier versions of OpenRC.
 *
 * The correct fix is implemented in this version, but that
 * means netmount needs to be added to the default runlevel if
 * you are using nfs file systems.
 
 * You should now update all files in /etc, using etc-update
 * or equivalent before restarting any services or this host.

Here I can read the first line of the second block and know I can
skip the next 12 lines without missing anything.  The next block
isn't worded the greatest, but that's beside the point.  And now
I get an important message at the end that I previously never 
noticed because tl;dr.

You're right that using echo means the whitespace doesn't get
saved by the elog system.  A while back someone proposed we
add espace for exactly this reason but IIRC they were laughed
down, which is a shame.

-- 


pgpywRVygQn7V.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Uncoordinated changes

[Ryan Hill]

On Sun, 14 Feb 2016 10:58:10 -0500
Rich Freeman  wrote:

> Well, if debugging is your only concern, on the system you're going to
> debug from:
> touch herds.xml

Don't do that.

rhill@tundra /usr/portage/dev-util/creduce $ repoman

RepoMan scours the neighborhood...
[INFO] checking package dev-util/creduce
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.4/repoman", line 37, in 
repoman_main(sys.argv[1:])
  File "/usr/lib64/python3.4/site-packages/repoman/main.py", line 104, in
repoman_main qatracker, can_force = scanner.scan_pkgs(can_force)
  File "/usr/lib64/python3.4/site-packages/repoman/scanner.py", line 281, in
scan_pkgs self.pkgmeta.check(xpkg, checkdir, checkdirlist, self.repolevel)
  File
"/usr/lib64/python3.4/site-packages/repoman/checks/ebuilds/pkgmetadata.py",
line 165, in check self.repoman_settings)) File
"/usr/lib64/python3.4/site-packages/repoman/checks/herds/herdbase.py", line
111, in get_herd_base os.path.join(repoman_settings["PORTDIR"],
"metadata/herds.xml")) File
"/usr/lib64/python3.4/site-packages/repoman/checks/herds/herdbase.py", line 73,
in make_herd_base target=_HerdsTreeBuilder())) File
"/usr/lib64/python3.4/xml/etree/ElementTree.py", line 1187, in parse
tree.parse(source, parser) File
"/usr/lib64/python3.4/xml/etree/ElementTree.py", line 605, in parse self._root
= parser.close() xml.etree.ElementTree.ParseError: no element found: line 1,
column 0




-- 


pgpyF72G2zq4a.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [PATCH 0/5] RFC: Patches for wxwidgets.eclass

[Ryan Hill]

On Wed, 3 Feb 2016 10:21:40 +0100
"Justin Lecher (jlec)" <j...@gentoo.org> wrote:

> On 02/02/16 23:36, Ryan Hill wrote:
> > On Mon,  1 Feb 2016 12:08:28 +0100
> > Justin Lecher <j...@gentoo.org> wrote:
> >   
> >> while tracking down the following error when running "egencache"
> >>
> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> >>
> >> I found that the global scope get_libdir() usage of the wxwidgets.eclass
> >> doens't work on EAPI=6. The following patches correct some minor things
> >> and block EAPI=6 for now until the eclass is ready.
> >>
> >> Justin Lecher (5):
> >>   wxwidgets.eclass: Update Copyright year
> >>   wxwidgets.eclass: Fix whitespaces
> >>   wxwidgets.eclass: unset unneeded variables in global scope after usage
> >>   wxwidgets.eclass: Only inherit eclass ones
> >>   wxwidgets.eclass: Add EAPI support
> >>
> >>  eclass/wxwidgets.eclass | 33 -
> >>  1 file changed, 24 insertions(+), 9 deletions(-)
> >>  
> > 
> > 1. I don't think most of this is necessary but go ahead I guess.  
> 
> Most of them are trivial, but excluding EAPI=6 from supported EAPIs is
> essential. The usage of get_libdir needs to be moved to a phase
> function. Which should perhaps be coupled with an env variable which is
> checked in the later function to ensure the phase function has been run.

Yeah, it just kind of screws us from getting sane defaults just by inheriting
the eclass.  I guess we'll have to find another way.

> > 2. When did we start posting every @

[gentoo-dev] Re: [PATCH 0/5] RFC: Patches for wxwidgets.eclass

[Ryan Hill]

On Wed, 3 Feb 2016 17:07:48 -0800
Daniel Campbell  wrote:

> I see nothing wrong with discussing changes to parts of the tree that
> will affect other developers. Bugzilla is nice and all, but imo it's
> more of an AND thing instead of an OR thing. If the bug is already
> present, I see no real reason not to have a thread about it on g-dev.
> It keeps unrelated developers in the loop, as well, in the event that
> they come across weird eclass behavior or take on a project using a
> given eclass.
> 
> I guess if eclass discussion is a problem, one could always add a rule
> to whatever they use to filter their mail.

I had thought that this got sent to gentoo-dev but not to wxwidgets, and I got
the impression that patches were being proposed for our eclass only here, where
I would have missed them (I don't read this list).  I didn't notice until today
we were CC'd.  I didn't see these come through on that alias, but I think my
mailer is eating messages again.

Sorry for the noise.


-- 


pgp3wQ8xwjPzl.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [PATCH 0/5] RFC: Patches for wxwidgets.eclass

[Ryan Hill]

On Mon,  1 Feb 2016 12:08:28 +0100
Justin Lecher  wrote:

> while tracking down the following error when running "egencache"
> 
> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found
> 
> I found that the global scope get_libdir() usage of the wxwidgets.eclass
> doens't work on EAPI=6. The following patches correct some minor things
> and block EAPI=6 for now until the eclass is ready.
> 
> Justin Lecher (5):
>   wxwidgets.eclass: Update Copyright year
>   wxwidgets.eclass: Fix whitespaces
>   wxwidgets.eclass: unset unneeded variables in global scope after usage
>   wxwidgets.eclass: Only inherit eclass ones
>   wxwidgets.eclass: Add EAPI support
> 
>  eclass/wxwidgets.eclass | 33 -
>  1 file changed, 24 insertions(+), 9 deletions(-)
> 

1. I don't think most of this is necessary but go ahead I guess.
2. When did we start posting every 

[gentoo-dev] Re: [PATCH v1] enable gccgo for all platform

[Ryan Hill]

On Mon,  2 Nov 2015 12:17:26 -0500
Leno Hou <leno...@gmail.com> wrote:

> 1. go compiler only support x86 platform
> 2. gcc 5 includes go command to build go apps
> 3. for coreos enablement, it's use gcc 5 to build go apps

> diff --git a/app-admin/consul-template/consul-template-0.9.0-r1.ebuild
> b/app-admin/consul-template/consul-template-0.9.0-r1.ebuild index
> cbc1059..a24ec80 100644 ---
> a/app-admin/consul-template/consul-template-0.9.0-r1.ebuild +++
> b/app-admin/consul-template/consul-template-0.9.0-r1.ebuild @@ -14,7 +14,10
> @@ LICENSE="MPL-2.0" SLOT="0"
>  IUSE="test"
>  
> -DEPEND=">=dev-lang/go-1.4:=  
> +DEPEND="|| (
> + >=dev-lang/go-1.4:=
> + >=sys-devel/gcc-5.1.0:=[go]
> + )
>   test? ( dev-go/go-tools )
>   app-admin/consul
>   app-admin/vault"

You cannot simply have a dependency on gcc like this.  Just because there is a
compiler installed that satisfies the dependency doesn't mean that compiler is
the one currently being used.  I could have gcc 5 with go support installed
while using gcc 6 without go.  You need to either do a compile test or query
the compiler in some way to ensure the needed support is there.  Look at the
fortran virtual and fortran-2 eclass for an example.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgphr6MQ7TfOv.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

[Ryan Hill]

On Thu, 12 Nov 2015 12:12:28 +0100
Ulrich Mueller <u...@gentoo.org> wrote:

> >>>>> On Thu, 12 Nov 2015, Jason Zaman wrote:  
> 
> > On Thu, Nov 12, 2015 at 11:46:19AM +0100, Alexis Ballier wrote:  
> >> How should one report bugs ? to infra or portage ?
> >> From my just rsynced tree, I see changelogs in reverse order: oldest
> >> come first, latest come last  
> 
> > NOTABUG, it was changed because rsync can deal really well with
> > appending to the end of files. rsyncing a file where things were
> > things were added to the beginning of the file means rsync will copy
> > the whole file from scratch which is pretty sub-optimal.  
> 
> Our ChangeLogs were always in newest-first order, so why would this
> suddenly be an issue?
> 
> Also readability for users should take priority over technical
> matters. Newest first is the usual order (e.g. it agrees with the
> default of git log), and ChangeLog having different order from
> ChangeLog-20* seems rather confusing to me.

I imagine it breaks emerge --changelog output as well?


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpA6fWKfogxC.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: ssl vs openssl vs libressl vs gnutls USE flag foo

[Ryan Hill]

On Tue, 27 Oct 2015 22:46:35 -0400
Rich Freeman <ri...@gentoo.org> wrote:

> On Tue, Oct 27, 2015 at 10:06 PM, hasufell <hasuf...@gentoo.org> wrote:
> >
> > B) 1 feature flag, 3 strict provider flags
> > * ssl: enable any sort of SSL/TLS support
> > * gnutls: only to enable gnutls provided ssl support in case there
> >   is a choice
> > * openssl: only to enable openssl provided ssl support in case
> >there is a choice (should not be implemented as !gnutls?)
> > * libressl: only to enable libressl provided ssl support in case there
> > is a choice, must conflict with 'openssl' USE flag
> >
> > consequences:
> > * REQUIRED_USE="^^ ( openssl libressl )" is not only allowed, it is
> >   _mandatory_
> > * packages like media-video/ffmpeg _must_ switch the USE flag
> >   openssl->ssl to avoid breaking global USE flags
> > * !gnutls? ( dev-libs/openssl:0 ) will be bad form or even disallowed
> >
> > B will definitely be more work, but ofc is also a lot cleaner and
> > totally unambigous.
> >  
> 
> ++
> 
> The pain is for a short time.  Then we have to live with this for a
> long time.  USE flags should have one meaning.  The fact that this
> isn't the case right now is already a bug.  We don't need to
> perpetuate it.
> 
> Honestly, this just seems like "the right thing" so if there isn't
> opposition then I'd suggest to "just do it" and commit fixes to
> ebuilds that need the fix (ie if maintainer doesn't respond to bug
> quickly just take care of it).  If people object they should speak up
> now, and we can take it up at the next council meeting if necessary
> (which is right around the corner).

Agreed.  If there's one choice then "ssl" should be used.  openssl/libressl/etc
should really be considered sub-flags of ssl.

I really wish we had some way of specifying this to make things clearer to the
user, so they could see exactly how these flags interact with each other.
Something like (emerge -pv):

ssl [ (openssl) libressl gnutls ] 
 - if USE ssl then pick one of, default openssl if none chosen

ssl [[ (openssl) libressl gnutls ]]
 - if USE ssl then one or more of... etc.

But I suppose that's another topic.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgp616RCHiArF.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: gcc-5 news item wrt C++ ABI

[Ryan Hill]

On Sat, 3 Oct 2015 13:04:08 +0800
Jason Zaman <perfin...@gentoo.org> wrote:

> On Fri, Oct 02, 2015 at 10:13:09PM -0400, Mike Frysinger wrote:

> > GCC 5 uses the new C++ ABI by default.  When building new code, you might
> > run into link time errors like:
> > ...: undefined reference to
> > '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
> 
> Exactly what part of this line is the important part? I take it its the
> @GLIBCXX_3.4.17? or is it the lack of the __cxx11::? I have a feeling
> that posted like this and users will think anytime it says undefined
> reference then its a C++ issue which is likely not the case.

If it's got a GLIBCXX symbol version and a mangled name and it broke when you
switched compilers and revdep-rebuild fixes it then you know it's a C++ ABI
issue. :)

The __cxx11 errors look a little different:

cmGlobalGenerator.cxx:(.text+0x12c04): undefined reference to
`Json::Value::Value(std::__cxx11::basic_string<char, std::char_traits,
std::allocator > const&)'

kfilemetainfo.cpp:(.text+0xfb5): undefined reference to
`Strigi::AnalysisResult::AnalysisResult(std::__cxx11::basic_string<char,
std::char_traits, std::allocator > const&, long,
Strigi::IndexWriter&, Strigi::StreamAnalyzer&, std::__cxx11::basic_string<char,
std::char_traits, std::allocator > const&)'

Either way CXX is right there in the error message.  Compare it to something
that fails due to C99 inline:

../../src/tcs/libtcs.a(libtcs_a-tcsps.o): In function 
`psfile_get_parent_uuid_by_uuid':
tcsps.c:(.text+0x3e8): undefined reference to `read_data'

bwm-ng.o: In function `main':
bwm-ng.c:(.text.startup+0x1d3): undefined reference to `get_iface_stats'

Rebuilding won't help with these of course.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgp6GcJOlN1Kg.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: moving gcc-5.2 to unstable

[Ryan Hill]

On Thu, 1 Oct 2015 09:49:47 -0400
Mike Frysinger <vap...@gentoo.org> wrote:

> what do people want to have in place before we move gcc-5.2 into ~arch ?
> 
> the general list looks pretty good:
>   https://bugs.gentoo.org/536984

IMO these should be fixed before we unmask:

   546742: x11-apps/sessreg-1.1.0 fail to build with gcc5
   547626: dev-lang/python-3.3 / 3.4 test_faulthandler hangs with GCC 5.1
   547950: app-shells/zsh-5.0.7-r2 builds but has runtime errors with GCC 5
   555866: media-libs/phonon-4.8.3-r1[qt5] fails to build with gcc-5

Just because they're common packages that lots of people will have installed.
Also they all have patches.

> the only glaring issue is the C++11 ABI breakage:
>   https://bugs.gentoo.org/542482
> 
> we already posted a news item when the breakage started in gcc-4.7:
>   
> https://archives.gentoo.org/gentoo-dev/message/4fa0c84858b4df49668da20302fc5b6f
> 
> but since gcc-5.x makes this the new default standard, more people are going
> to run into it, so we probably want a reminder.  do we want any sort of
> automation otherwise here ?

I think we need a news item to remind people they really do have to emerge -e
@world after this one or they could have a bad time.

FWIW I updated one system from 4.9 to 5.2 by rebuilding ~700 packages in random
order just to see how bad the ABI breakage would be and only ran into it once.
I may have just gotten lucky though.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpIF6xgcchnn.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: gcc-5 news item wrt C++ ABI

[Ryan Hill]

On Fri, 2 Oct 2015 22:13:09 -0400
Mike Frysinger <vap...@gentoo.org> wrote:

> Title: GCC 5 Defaults to the New C++11 ABI 
> Author: Mike Frysinger <vap...@gentoo.org>
> Content-Type: text/plain
> Posted: 2015-10-02
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >=sys-devel/gcc-5
> 
> GCC 5 uses the new C++ ABI by default.  When building new code, you might run
> into link time errors like:
> ...: undefined reference to '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
> Or you might see linkage failures with "std::__cxx11::string" in the output.
> 
> These are signs that you need to rebuild packages using the new C++ ABI.
> You can quickly do so by using revdep-rebuild like so:
> # revdep-rebuild --library 'libstdc\+\+\.so\.6'
> 
> For more details, feel free to peruse:
> https://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
> https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/
> 

LGTM.

-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgp8sN8qTZUiO.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: ALLARCHES and the maintainer action(s)

[Ryan Hill]

On Sun, 20 Sep 2015 13:23:21 +0200
Tobias Klausmann <klaus...@gentoo.org> wrote:

> arch_A maintainer sees ALLARCHES keyworded bug, and tests
> everything on A. Upon keywording and running repoman, she finds
> that two other arches need additional deps. What to do?

Use common sense?  This isn't brain surgery.

> If anything, I'd say that the _maintainer_ can go ahead and
> stabilize on all[0] arches after the first arch-specific
> stabilization. Thus owning the decision and possible fallout.

The maintainer already owns the fallout - they requested ALLARCHES in the first
place.

> [0] I am pretty sure some arches will want to opt out of this
> scheme, at least for some more critical packages.

ALLARCHES shouldn't be used on critical packages. 



-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpqHyhT6qZ3g.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: how to add a new package with git?

[Ryan Hill]

On Thu, 3 Sep 2015 23:07:37 +0600 (NOVT)
gro...@gentoo.org wrote:

> WARNING: previous mirror push to host 'ituri.gentoo.org' failed, status 
> is:
> 2015-09-03.16:57:50 962 ssh: connect to host ituri.gentoo.org port 
> 22: Connection timed out
> 2015-09-03.16:57:50 962 fatal: Could not read from remote 
> repository.
> 2015-09-03.16:57:50 962
> 2015-09-03.16:57:50 962 Please make sure you have the correct 
> access rights
> 2015-09-03.16:57:50 962 and the repository exists.

Sorry if this has been discussed elsewhere, but what is this warning?  A couple
days ago I started seeing it every time I sync even though I've yet to push
anything to git.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpc6afeYWfel.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

On Thu, 13 Aug 2015 08:13:59 -0400
Rich Freeman ri...@gentoo.org wrote:

 If it is a URL, please make it whatever is already in my browser
 address bar.  A nice shorthand URL looks pretty but it isn't so pretty
 if I have to edit it instead of just hitting copy/paste.  When I'm
 fixing bugs I have the bug open in a browser already, since the next
 step after committing the fix is going to be closing the bug.

Same here, which is why I suggested the canonicalization.  I want to be able to
paste in whatever is handy and have it come out looking nice.

 Otherwise, I really don't care.  Bug gets the job done.

I don't care that much either.  We never had URLs in the changelogs before so
it's not like we're losing anything.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpOKZwJ7NJob.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

On Wed, 12 Aug 2015 18:03:52 +0200
Michał Górny mgo...@gentoo.org wrote:


 Can we make it clear whether we are allowed/supposed to use the short
 form:
 
   https://bugs.gentoo.org/333531
 
 ?

I'd like this to be the preferred form.  It's cleaner, the show_bug.cgi=id? is
just noise.

If we do go with a URI is it possible to do some kind of magic behind the scenes
to canonicalize it?  By that I mean is that any of these:

Gentoo-Bug: https://bugs.gentoo.org/333531
Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531
Gentoo-Bug: 333531

would automatically be converted to https://bugs.gentoo.org/333531 (or whatever
is decided on).  That way everyone can use whatever they like best and it'll
all come out consistent.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpZvwfTybaI_.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

On Mon, 10 Aug 2015 12:25:58 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
 What about:
 
 * bug number in summary strongly recommended
 ** summary bug number standardized to GB#xx or #xx or similar, 
 short enough for summary, easily identified. GB# would be distinctly 
 gentoo and could be expanded to KDEB#, GNB# (gnome), FDOB#, etc, for 
 projects where users likely to want to see the bug likely know what it is.
 ** summary lists gentoo bug if any, upstream only if no gentoo bug.
 
 * bug URL in description required.
 ** standardized to Gentoo-Bug: ...
 ** gives people wanting something to click a way to do so
 ** U in URL is universal, unambiguously identifies reference for those 
 unfamiliar with summary shorthand.
 ** Multiple allowed, for multiple gentoo bugs or to identify upstream 
 bugs (using FDO-Bug: or similar) as well.
 
 That seems a reasonable compromise, given people pulling both ways
 in-thread.

Making the bug number in the summary manditory or strongly encouraged leads to
wonderful commit messages like:

---
cat-pkg: Fix bug #504321.

Gentoo-Bug: 504321
---

I would like to see this be more common:

---
cat-pkg: Make the thingy work again.

Gentoo-Bug: https://bugs.gentoo.org/504321 or 504321 Idon'tcarewhich


If we're limiting the summary to 1 line, 70-75 chars, manditory cat/package
and bug number there's not a lot of room to summarize in.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpHa8xvvMufS.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Ryan Hill]

On Mon, 10 Aug 2015 23:43:29 +0300
Andrew Savchenko birc...@gentoo.org wrote:

 On Mon, 10 Aug 2015 15:11:02 +0200 Michał Górny wrote:
 2. Bug number can be easily typed, URL has to be copied or
 generated by some tool.

So, please remind me, how many times the 'easy typing' got the bug
number wrong? This is not a real argument, just another of Gentoo's
'I'm too lazy to do things right'.
   
   URLs are longer, so probability of error during typing increases
   compared to raw numbers.
  
  Not really. You are closer to the threshold when you are too lazy to
  type it and you just copy-paste it.
 
 Copy and pasting requires more time than typing 6 digits.
  
 3. Too many text, hard to read. Some bugs may refer to a dozen of
 URLs.

And how is a dozen numbers better?
   
   Less text, more readable.
  
  How is:
  
Bug: 123451, 453445, 344334, 343444
  
  more readable than:
  
Bug: https://bugs.gentoo.org/123451
Bug: https://bugs.gentoo.org/453445
Bug: https://bugs.gentoo.org/344334
Bug: https://bugs.gentoo.org/343444
  
  Readability is a matter of formatting, not contents.
 
 1. One line and 35 chars are certainly more readable than four lines
 and 140 chars.

It isn't.  There's a reason why lists of things are generally written top to
bottom.  I found the second form to be much more readable.  In fact I was
generally against the URIs until I saw this.

 2. Strings are read from left to right (at least in English), thus
 having most important information last on the line is not
 convenient.

Maybe if you were reading the whole line, but you're not.  You have built-in
pattern recognition.  Try it out.

 3. A lot of duplicated and useless information consumes time and
 space, irritating people.

Arg, that is so irritating how I have easily-clickable machine-parsable links in
my git log. Look at all the space we could have saved!  How much time have I
wasted reading every character?!  Sorry kids, can't play, daddy's busy reading
commit logs.

No matter what we decide three months from now we won't remember arguing about
it.  So let's save some time an irritability now and pick something.



-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpjwTP4s_CiU.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Git Migration: go-live!

[Ryan Hill]

On Sun, 9 Aug 2015 05:36:16 +
Robin H. Johnson robb...@gentoo.org wrote:

 On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote:
  On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote:
   2015/08/08 15:00 UTC - Freeze
   2015/08/08 19:00 UTC - Git commits open for developers
 This is going live in a few minutes. There was a lot of delays and snags
 that were hit. QA has a lot of reviewing to do of in-tree patches with
 long-standing CVS keyword damage. gkeys is also not sufficiently baked,
 so we're using some scripting for now instead [1].
 
 The new setup DOES enforce that commits AND pushes are signed.
 
 I'm only 90% sure that everything works, but I've spent almost the
 entire day on it, and there's more to go tomorrow.
 
 Other old CVS repos are still closed for the moment, they will re-open
 tomorrow.

So for someone who hasn't been following any of this, is there an idiot's guide
on how make the Gentoo?


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpgeqSe7dvLl.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Ryan Hill]

On Mon, 10 Aug 2015 00:44:09 +0300
Andrew Savchenko birc...@gentoo.org wrote:

 On Sun, 9 Aug 2015 21:56:05 +0200 Michał Górny wrote:
  Dnia 2015-08-09, o godz. 16:09:29
  hasufell hasuf...@gentoo.org napisał(a):
  
   On 08/09/2015 03:58 PM, Michael Weber wrote:
commit: 40b3fd64ec9c5d6d94f0f0897740bc77622c24a1
Author: Michael Weber xmw AT gentoo DOT org
AuthorDate: Sun Aug  9 13:58:26 2015 +
Commit: Michael Weber xmw AT gentoo DOT org
CommitDate: Sun Aug  9 13:58:26 2015 +
URL:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40b3fd64

sci-libs/opencascade: add USE=vtk (bug 557022, thanks Helmut Jarausch).

   
   I was wondering if we should set a standard for referencing bug reports.
   The portage team already does something like that:
   https://github.com/gentoo/portage/commit/b7149002bf23889f280c502afe6ceda0b1345ca3
   
   Following that, the commit could have been:
   =
   sci-libs/opencascade: add USE=vtk
   
   thanks to Helmut Jarausch
   
   X-Gentoo-Bug: 557022
   X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=557022
   =
  
  Which is terribly redundant. Just put the whole bug URL. Advantages:
  
  - keeps the bug namespaced to bugs.gentoo.org,
  - has the bug no inside,
  - is convenient -- you can click it instead of copy-pasting the no.
 
 1. URL may change in future, bug number — unlikely.
 2. Bug number can be easily typed, URL has to be copied or
 generated by some tool.
 3. Too many text, hard to read. Some bugs may refer to a dozen of
 URLs.
 4. It is easier to copy a number, than selecting and copying whole
 string. Not all terminals support running browser on URL click.
 5. Clicking is less convenient than typing bugs search $number —
 user have to move hands from a keyboard to a mouse — a terrible
 waste of time, at least in my case with my typing speed.
 
 Best regards,
 Andrew Savchenko
 

Also the URL should be https://bugs.gentoo.org/557022 so already that's wrong.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpSyBwzJyfPG.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Git Migration: go-live!

[Ryan Hill]

On Sun, 9 Aug 2015 13:22:43 +0200
hasufell hasuf...@gentoo.org wrote:

 On 08/09/2015 12:16 PM, Ryan Hill wrote:
  On Sun, 9 Aug 2015 05:36:16 +
  Robin H. Johnson robb...@gentoo.org wrote:
  
  On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote:
  On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote:
  2015/08/08 15:00 UTC - Freeze
  2015/08/08 19:00 UTC - Git commits open for developers
  This is going live in a few minutes. There was a lot of delays and snags
  that were hit. QA has a lot of reviewing to do of in-tree patches with
  long-standing CVS keyword damage. gkeys is also not sufficiently baked,
  so we're using some scripting for now instead [1].
 
  The new setup DOES enforce that commits AND pushes are signed.
 
  I'm only 90% sure that everything works, but I've spent almost the
  entire day on it, and there's more to go tomorrow.
 
  Other old CVS repos are still closed for the moment, they will re-open
  tomorrow.
  
  So for someone who hasn't been following any of this, is there an idiot's
  guide on how make the Gentoo?
  
  
 
 https://wiki.gentoo.org/wiki/Gentoo_git_workflow

There it is.



-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpCqTV_TJmdB.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

On Mon, 10 Aug 2015 03:02:43 +0200
hasufell hasuf...@gentoo.org wrote:

 On 08/10/2015 02:51 AM, Ulrich Mueller wrote:
  On Mon, 10 Aug 2015, Andrew Savchenko wrote:
  
  This is not a matter of going l33t, this is a matter of getting rid
  of redundant and pretty much useless data all the same through
  almost all commit messages.
  
  +1
  
  Gentoo-Bug: 123456 or even Bug: 123456 is enough to uniquely
  identify a bug. Also it is easier to read (and to type) than its URL
  equivalent.
  
 
 So, would this replace the bug number reference in the summary? Should
 we tell people to reference the bug only in the commit message description?
 
 Or do we say:
 * bug number in summary optional
 * bug number in description mandatory via Gentoo-Bug: 1234

The latter I hope.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgplEZSjsocFk.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Importance of SLOTs on Java dependencies

[Ryan Hill]

On Wed, 8 Apr 2015 16:25:20 +0100
James Le Cuirot ch...@gentoo.org wrote:

 On Wed, 8 Apr 2015 17:10:30 +0200
 Patrice Clement monsie...@gentoo.org wrote:
 
  Tuesday 07 Apr 2015 20:41:05, Pacho Ramos wrote :
   Wouldn't be possible to show a repoman warning when a dependency on
   any dev-java/${PN} doesn't specify a SLOT? That would save of from
   forgetting this in some years ;)
   
  Chewi suggested a similar solution in #gentoo-java. How do we get
  started with contributing to repoman?
 
 The change I intend to make is not to repoman but java-utils-2.eclass
 where there is already a check to ensure that a dependency has been
 added, it just doesn't check the SLOT at the moment. It outputs an
 error message by default but dies if you have JAVA_PKG_STRICT set,
 which all Java devs should do.

I just got this warning and had to do some digging to figure out where it
came from and what it wanted me to do. Can you add a comment to the eclass
(maybe a link to your mail which explained things well) and a pointer to the
eclass in the message?


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpFJ2VxJ9OCK.pgp
Description: OpenPGP digital signature

[gentoo-dev] Dropping GCC maintainership

[Ryan Hill]

Hey all, I'm stepping down as GCC maintainer.  I haven't been reading toolchain
bugmail since June, and keep telling myself I'll tackle it next weekend, which
never happens.  To be frank, I'm kinda sick of Gentoo.  I'm hoping it's
temporary but we'll see.  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

[gentoo-dev] Re: crossdev and multilib interference

[Ryan Hill]

On Tue, 17 Jun 2014 10:17:26 -0400
Joshua Kinard ku...@gentoo.org wrote:

 I'm a member of toolchain, but that's mostly historical because I used to
 play with a lot of the cross-compile stuff for MIPS and Sparc.  Mike and
 Ryan are the two primaries in toolchain right now.  If they don't see a
 problem with crossdev right now, then I do have to question just how big of
 a problem this really is.

Thanks for being a voice of reason in this thread. 

I just wanted to say that I'm not involved with crossdev development so any
opinions I might be spewing are mine alone 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

[gentoo-dev] Re: crossdev and multilib interference

[Ryan Hill]

On Mon, 16 Jun 2014 13:27:29 +
hasufell hasuf...@gentoo.org wrote:

 If you think having broken packages for months in stable arch is ok,
 then you are wrong.
 
 And btw., your funny threats don't impress me anymore.
 
 I'll bring this up to the council agenda if you like. This is a
 non-trivial tree-wide problem and if toolchain keeps ignoring it, then I
 will hardmask the thing.

Well, see, I'm trying funny threats because I don't know how else to get it
through your head that you have no right to start masking packages that don't
belong to you when we won't fix your stupid pet bug.  And if you do so there
will be consequences.  By masking crossdev you'd effectively be masking the
whole tree for any number of archs.  Not to mention anyone building a
cross-compiler for their own use outside of portage.  There are several
high-profile groups that rely on crossdev.  Hell, several arch teams rely on
it.  You're suggesting we mask it because your particular corner-case doesn't
work.  Maybe I should start threatening to remove games when they don't run
on my video card.

If doing something dumb like installing a 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

[gentoo-dev] Re: crossdev and multilib interference

[Ryan Hill]

On Sun, 15 Jun 2014 20:35:53 +
hasufell hasuf...@gentoo.org wrote:

 Steven J. Long:
  
  I'll see you when you get there, if you ever get there..
  
 
 No improvements so far. I am going to hardmask sys-devel/crossdev,
 unless someone can explain why we 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

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

On Fri, 13 Jun 2014 09:38:32 -0400
Rich Freeman ri...@gentoo.org wrote:

 On Fri, Jun 13, 2014 at 9:22 AM, Jeroen Roovers j...@gentoo.org wrote:
  The problem I see is that anyone who wants to switch to having
  -fstack-protector enabled by default early will run into the glibc
  problem (much as I did), when all the bug reports that point out the
  problem have been closed as INVALID. A simple `strip-flags
  -fstack-protector' in the appropriate (non-hardened?) cases should
  prevent more duplicate bug reports, I guess.

Ah, okay.  I agree.  Thanks for pointing this out.

 If we know everybody is going to be on -fstack-protector in a few
 months just add the strip-flags statement to the ebuild and be done
 with it.  Squabbling over whether those using the flag are bringing
 breakage upon themselves is like trying to hold back the sea.  We
 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 legitimate package bug.


-- 
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

[gentoo-dev] Re: svn{.overlays,}.gentoo.org hosting discontinued; git{.overlays,}.gentoo.org hosting merging

[Ryan Hill]

On Sat, 14 Jun 2014 07:26:47 +
Robin H. Johnson robb...@gentoo.org wrote:

 All remaining SVN repos will be migrated to Git.
 This applies to both svn.gentoo.org and svn.overlays.gentoo.org
 This is being tracked in bug #513182 [2]
 
 There are very few repos that still actively commit new content.
 Here are the only repos that have new content within the last 180 days.
 
 svn.g.o:
 linux-patches (today)
 baselayout (63 days ago)
 
 svn.overlays.g.o
 proj/toolchain (1 day ago)
 proj/vdr (14 days ago)
 dev/pauldv (29 days ago)
 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: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

On Wed, 11 Jun 2014 15:23:15 +0200
Jeroen Roovers j...@gentoo.org wrote:

 Will bug #332823 and its ilk somehow be mitigated? Emerging glibc with
 -fstack-protector still leads to similar problems. There doesn't
 currently seem to be a bug report about this that isn't marked INVALID.

Bugzilla seems to be down so I can't look up the bug, but I doubt it's a
problem since you can't build glibc with -fstack-protector.

glibc/files/eblits/common.eblit:
  gcc-specs-ssp  append-cflags $(test-flags-CC -fno-stack-protector)

Previously this was also dependent on `use hardened` so whatever that bug is
about it probably doesn't apply any more.

I've been running the ssp patches here for the last six months and have rebuilt
world a few dozen times with both 4.8 and 4.9 and haven't run into any
problems.  That doesn't mean there aren't any, 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: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

On Tue, 10 Jun 2014 09:48:53 -0400
Anthony G. Basile bluen...@gentoo.org 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 rh...@gentoo.org 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
  an error on hppa?  Maybe give 4.8.2-r1 a whirl.
  Setting -fstack-protector on HPPA does this:
 
  warning: -fstack-protector not supported for this target [enabled by
default]
 
  Setting -fno-stack-protector on HPPA causes no problems and is
  completely silent.
 
 
jer
  The arch that ssp will be enable by default is defined in the ebuild with
  SSP_STABLE or SSP_UCLIBC_STABLE.
 
  /Magnus
 
 
 
 Will that remove the flag from hppa?

Yes, the spec rule is applied only if the arch defines SSP_STABLE.


-- 
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

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

On Tue, 10 Jun 2014 14:22:11 +0200
Jeroen Roovers j...@gentoo.org wrote:

 On Mon, 9 Jun 2014 21:46:56 -0600
 Ryan Hill rh...@gentoo.org 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
  an error on hppa?  Maybe give 4.8.2-r1 a whirl.
 
 Setting -fstack-protector on HPPA does this:
 
 warning: -fstack-protector not supported for this target [enabled by
  default]
 
 Setting -fno-stack-protector on HPPA causes no problems and is
 completely silent.

Okay, we're good to go then.  Thanks for testing.


-- 
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

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

v2: Restrict by arch
--

Title: GCC 4.8.3 defaults to -fstack-protector
Author: Ryan Hill rh...@gentoo.org
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-If-Keyword: ppc
Display-If-Keyword: ppc64
Display-If-Keyword: x86

Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
enabled by default.  The 4.8 series will enable -fstack-protector
while 4.9 and later enable -fstack-protector-strong.

SSP is a security feature that attempts to mitigate stack-based buffer
overflows by placing a canary value on the stack after the function
return pointer and checking for that value before the function returns.
If a buffer overflow occurs and the canary value is overwritten, the
program aborts.

There is a small performance cost to these features.  They can be
disabled with -fno-stack-protector.

For more information these options, refer to the GCC Manual, or the
following articles.

http://en.wikipedia.org/wiki/Buffer_overflow_protection
http://en.wikipedia.org/wiki/Stack_buffer_overflow
https://securityblog.redhat.com/tag/stack-protector
http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong


-- 
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

[gentoo-dev] Re: The state and future of the OpenRC project

[Ryan Hill]

On Tue, 10 Jun 2014 13:09:26 -0400
Rich Freeman ri...@gentoo.org wrote:

 On Tue, Jun 10, 2014 at 12:45 PM, Andrew Savchenko birc...@gmail.com wrote:
 
  Why are you saying that git is inefficient with large projects? It
  was developed with efficiency in mind in the first place. And
  kernel guys will likely disagree with git is not great with crazy
  big projects statement.
 
 The kernel tree that everybody uses has only a single committer -
 Linus.  That is definitely a potential challenge that we may run into
 migrating gentoo-x86 - we have many committers and a fairly high
 commit rate.
 
 With Linux you have a million separate git repos and everybody
 cascades their changes up, which get merged into bigger and bigger
 patch sets.  So, Linus might get a set of updates to merge from the
 video driver maintainer and it might contain 400 bundled commits, but
 it isn't like the 400 committers have direct access to Linus's tree.
 They all commit to their own trees and cascade up to the next level
 via email.
 
 We already have a working method of migrating the entire portage
 history to git.  However, the infra tools/etc are all built around git
 and only a few people have access to update them.  The git repository
 needs to make it out to the mirrors/etc.
 
 There are also a bunch of process-related details to work out.  Does
 everybody try to rebase onto master, or do we have lots of merges?
 What happens if you do rebase onto master and then when you go to push
 it isn't a fast-forward any longer because somebody else pushed first?
 
 But, for the most part we just need to get the back-end re-written to
 work with 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

[gentoo-dev] [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

Title: GCC 4.8.3 defaults to -fstack-protector
Author: Ryan Hill rh...@gentoo.org
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 will enable -fstack-protector
while 4.9 and later enable -fstack-protector-strong.

SSP is a security feature that attempts to mitigate stack-based buffer
overflows by placing a canary value on the stack after the function
return pointer and checking for that value before the function returns.
If a buffer overflow occurs and the canary value is overwritten, the
program aborts.

There is a small performance cost to these features.  They can be
disabled with -fno-stack-protector.

For more information these options, refer to the GCC Manual, or the
following articles.

http://en.wikipedia.org/wiki/Buffer_overflow_protection
http://en.wikipedia.org/wiki/Stack_buffer_overflow
https://securityblog.redhat.com/tag/stack-protector
http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong


-- 
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

[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Ryan Hill]

On Tue, 10 Jun 2014 04:31:27 +0200
Jeroen Roovers j...@gentoo.org wrote:

 On Mon, 9 Jun 2014 18:16:02 -0600
 Ryan Hill rh...@gentoo.org wrote:
 
  Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
  enabled by default.[..]
 
 .. on supported architectures.
 
 
 Right?

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 an error on
hppa?  Maybe give 4.8.2-r1 a whirl.


-- 
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

[gentoo-dev] Re: RFC: Removing src_test from www-client/chromium

[Ryan Hill]

On Tue, 27 May 2014 09:02:37 +0200
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:

 It's more of a project-internal decision IMHO, but just wanted to get
 feedback from the larger community.
 
 Currently 11 out of 27 bugs assigned to chromium.g.o are related to test
 failures.
 
 I don't remember a single case where a test failure would point to a
 real bug in our package.
 
 I'm seriously considering just removing src_test to make the package
 more maintainable (less code, less bugs filed, can focus on things that
 *do* impact our users).
 
 If you decide to comment in favor of keeping src_test, please consider
 volunteering to help us with the bugs.
 
 Feel free to suggest solutions that fall somewhere in between - e.g.
 having src_test but not excluding any tests there and using
 RESTRICT=test, so that someone who really wants to run the tests FYI can
 do so.

I've said it before, but I think that by having packages in the tree that we
know consistently fail their testsuites, we create a situation where we are
worse off than if we simply disabled the tests for that package.

Let's look at what enabling tests gets you right now:

- additional dependencies
- longer compile times
- blockers
- lots of scrolly output
- devs ignore your bug reports
- absolutely no peace of mind because every third package fails for no good
  reason

If I wasn't a dev I would have 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

[gentoo-dev] Re: Adding -l (--ignore-whitespace) to EPATCH_COMMON_OPTS

[Ryan Hill]

On Thu, 15 May 2014 07:21:58 +0200
Ulrich Mueller u...@gentoo.org 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?
 
 Please don't. There are languages where whitespace is significant.

Fair enough.


-- 
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

[gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default

[Ryan Hill]

On Tue, 13 May 2014 19:11:18 +0200
Michał Górny mgo...@gentoo.org wrote:

 Dnia 2014-05-13, o godz. 09:28:49
 Andrew Savchenko birc...@gmail.com napisał(a):
 
  I tried network-sandbox — this is a disaster. It brokes distcc
  completely since distcc client can't connect to remote servers (and
  even to a local one if any).
 
 Calling something a disaster just because it breaks one thing is
 unpleasant at least.
 
 This is a corner case with no good solution at the moment. Though it is
 entirely doable to make FEATURES=distcc and FEATURES=network-sandbox
 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 are explicitly saying they want to access the network.


-- 
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

[gentoo-dev] Adding -l (--ignore-whitespace) to EPATCH_COMMON_OPTS

[Ryan Hill]

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 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default

[Ryan Hill]

On Sun, 11 May 2014 23:42:38 +0200
Michał Górny mgo...@gentoo.org wrote:

 Hi, everyone.
 
 Almost 9 months ago I've committed three new FEATURES for portage:
 cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose
 enabling at least the latter two by default.
 
 
 Firstly, I'd like to shortly remind you what they do:
 
 1. cgroup -- puts all processes spawned by ebuild to cgroup, and kills
 all of them once phase exits (prevents leaving orphans),
 
 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate
 IPC namespace, preventing them from interfacing other system services
 via IPC (message queues, semaphores, shared memory),
 
 3. network-sandbox -- puts all processes spawned by ebuild to
 a separate network namespace with a private loopback interface,
 preventing them from interfacing other system services, local network
 and the Internet.

[snip]

All three of these require kernel support.  It might be a good idea to add
the needed options to that Gentoo Linux menu we have in gentoo-sources and
enable them by default.  I think it would be non-obvious to a new user that
they would have to enable network and ipc namespaces for portage to work
properly out of the box (and if they disable the latter they get a bunch of
cryptic Unable to unshare: EINVAL messages every time they build something
which isn't very helpful).

Do we know of any packages broken by 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

[gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default

[Ryan Hill]

On Mon, 12 May 2014 11:39:10 +0200
Tom Wijsman tom...@gentoo.org wrote:

 On Mon, 12 May 2014 00:47:17 -0600
 Ryan Hill rh...@gentoo.org wrote:
 
   1. cgroup -- puts all processes spawned by ebuild to cgroup, and
   kills all of them once phase exits (prevents leaving orphans),
   
   2. ipc-sandbox -- puts all processes spawned by ebuild to a separate
   IPC namespace, preventing them from interfacing other system
   services via IPC (message queues, semaphores, shared memory),
   
   3. network-sandbox -- puts all processes spawned by ebuild to
   a separate network namespace with a private loopback interface,
   preventing them from interfacing other system services, local
   network and the Internet.
  
  All three of these require kernel support.  It might be a good idea
  to add the needed options to that Gentoo Linux menu we have in
  gentoo-sources and enable them by default. 
 
 Right, this skipped my mind when I enabled them yesterday; this should
 be documented, as well as have Portage check for missing support and
 test it and bail out with a proper error message if it doesn't already.
 
 Which options are these in particular? I'll cook a patch with them.

I believe they are CONFIG_IPC_NS, CONFIG_NET_NS, and CONFIG_CGROUPS.


-- 
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

[gentoo-dev] Re: LTO use in the tree

[Ryan Hill]

On Tue, 22 Apr 2014 11:10:19 -0700
Matt Turner matts...@gentoo.org 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 register pressure.  On others like alpha it's
  questionable if it'll even work at all...
 
 Worked for me on alpha, at least for what I tried. It cut eix's binary
 from 2 to 1.3 MB as well.

Cool, thanks for the info.  I was going by the request we had back in 4.6 to
turn off LTO for alpha because an upstream 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

[gentoo-dev] Re: LTO use in the tree

[Ryan Hill]

On Tue, 22 Apr 2014 08:45:31 + (UTC)
Martin Vaeth mar...@mvath.de wrote:

 Ryan Hill rh...@gentoo.org 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 register pressure.
 
 If this really is the case it is not the problem of LTO but
 of the optimizer: If the optimizer really produces *worse*
 code when he *can* see the full program instead of only parts of it,
 something is severely broken in the optimizer. Only decreasing the
 possibilities of the optimizer by removing LTO would be the wrong way
 to solve this problem.

Yes, this is a problem caused by aggressive inlining, and is being worked on
upstream[1].  I meant that currently released versions exhibit this behaviour.


[1] see for example http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01098.html

-- 
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

[gentoo-dev] LTO use in the tree

[Ryan Hill]

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 are incompatible with LTO.

- LTO causes .GCC.command.line sections to be discarded, which means your
  package will always be QA flagged as ignoring CFLAGS.

- LTO takes a _lot_ of memory.  That memory is required on the host arch.
  Distcc doesn't help things here, because linking happens locally.  Consider
  all the archs your package is built on, and if they all routinely have
  multiple GBs of memory installed.

- LTO in 4.7 is still fairly buggy.  There are no plans to fix it.  4.8 is
  better, but 4.9 moves to a different model, so bugs in 4.8 probably won't be
  fixed, especially regarding memory usage.

- I'm happy to backport patches to fix LTO problems if they'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: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: LTO use in the tree

[Ryan Hill]

On Sun, 20 Apr 2014 21:14:51 -0600
Ryan Hill rh...@gentoo.org 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 are incompatible with LTO.
 
 - LTO causes .GCC.command.line sections to be discarded, which means your
   package will always be QA flagged as ignoring CFLAGS.
 
 - LTO takes a _lot_ of memory.  That memory is required on the host arch.
   Distcc doesn't help things here, because linking happens locally.  Consider
   all the archs your package is built on, and if they all routinely have
   multiple GBs of memory installed.
 
 - LTO in 4.7 is still fairly buggy.  There are no plans to fix it.  4.8 is
   better, but 4.9 moves to a different model, so bugs in 4.8 probably won't be
   fixed, especially regarding memory usage.
 
 - I'm happy to backport patches to fix LTO problems if they'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.
 
 

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 register pressure.  On others like alpha it's questionable if it'll
even work at all...


-- 
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

[gentoo-dev] Re: [PATCH] waf-utils.eclass: respect CFLAGS in linking command

[Ryan Hill]

On Sun, 06 Apr 2014 15:45:34 +
hasufell hasuf...@gentoo.org wrote:

 respect CFLAGS in linking command
 https://bugs.gentoo.org/show_bug.cgi?id=506956
 
 --- eclass/waf-utils.eclass
 +++ eclass/waf-utils.eclass
 @@ -56,18 +56,18 @@
   [[ -z ${NO_WAF_LIBDIR} ]] 
 libdir=--libdir=${EPREFIX}/usr/$(get_libdir) 
   tc-export AR CC CPP CXX RANLIB
 - echo CCFLAGS=\${CFLAGS}\ LINKFLAGS=\${LDFLAGS}\
 \${WAF_BINARY}\ --prefix=${EPREFIX}/usr ${libdir} $@ configure
 + echo CCFLAGS=\${CFLAGS}\ LINKFLAGS=\${CFLAGS} ${LDFLAGS}\
 \${WAF_BINARY}\ --prefix=${EPREFIX}/usr ${libdir} $@ configure 
   # This condition is required because waf takes even whitespace as
 function # calls, awesome isn't it?
   if [[ -z ${NO_WAF_LIBDIR} ]]; then
 - CCFLAGS=${CFLAGS} LINKFLAGS=${LDFLAGS} ${WAF_BINARY} \
 + CCFLAGS=${CFLAGS} LINKFLAGS=${CFLAGS} ${LDFLAGS}
 ${WAF_BINARY} \ --prefix=${EPREFIX}/usr \
   ${libdir} \
   $@ \
   configure || die configure failed
   else
 - CCFLAGS=${CFLAGS} LINKFLAGS=${LDFLAGS} ${WAF_BINARY} \
 + CCFLAGS=${CFLAGS} LINKFLAGS=${CFLAGS} ${LDFLAGS}
 ${WAF_BINARY} \ --prefix=${EPREFIX}/usr \
   $@ \
   configure || die configure failed

Good.


-- 
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

[gentoo-dev] Re: RFD: new global USE flag gtk3

[Ryan Hill]

On Thu, 20 Feb 2014 11:26:18 +0200
Samuli Suominen ssuomi...@gentoo.org 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_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: RFD: new global USE flag gtk3

[Ryan Hill]

On Thu, 20 Feb 2014 05:16:55 -0500
Alexandre Rostovtsev tetrom...@gentoo.org wrote:

 The other unfortunate aspect of the gtk3 flag is that it encourages
 using flags instead of slotting for libraries that can support both gtk
 and gtk3, resulting in needless rebuilds of when one of the flags is
 switched on/off. But again, that could be addressed with a bit of
 documentation.

Slotting a library by toolkit rather than by version just doesn't work in a lot
of cases.  Having multiple versions of a library installed is common enough
practice and upstreams will often take that into account and version their
library names, include paths, pkgconfig files, etc.  Most don't do that for
different toolkits.  So if you're slotting by toolkit you have to start
installing one in a non-standard location to prevent file collisions (and it's
always the newer toolkit since you don't want to break existing packages), and
every new ebuild using that toolkit needs to be changed to look in the right
place, and you have to start futzing around with symlinks, and wrapper scripts,
and eselect, and eclasses, and every time some dev uses the wrong depend atom
you get a bug about it, and it goes on and on and on.

Or you can add USE=gtk3, deal with collisions internally, install one set of
headers, and go do something productive with your life.

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 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

[gentoo-dev] Re: RFD: new global USE flag gtk3

[Ryan Hill]

On Sat, 22 Feb 2014 16:09:53 -0500
Alexandre Rostovtsev tetrom...@gentoo.org 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
  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).
 
 Remember, a single process cannot load both gtk2 and gtk3 - you *will*
 get random crashes. If you think that dealing with interesting bug
 reports - e.g. caused by application foo which was built against your
 wxGTK[gtk3] and then crashed after enumerating its plugin directory
 because of the presence of binary plugin bar which links to libbaz which
 sometimes dlopens gtk2 at runtime when USE=wombat is enabled  - is more
 fun than doing a bit of work at the start and slotting wxGTK, then
 please go ahead ;)

Yeah and package built against wxGTK (gtk2) could dlopen gtk3 at runtime
today.  That's already the case.  But what does that have to do with slotting?


-- 
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

[gentoo-dev] Re: RFD: new global USE flag gtk3

[Ryan Hill]

On Sat, 22 Feb 2014 15:50:17 -0600
Ryan Hill dirtye...@gentoo.org wrote:

 On Sat, 22 Feb 2014 16:09:53 -0500
 Alexandre Rostovtsev tetrom...@gentoo.org 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
   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).
  
  Remember, a single process cannot load both gtk2 and gtk3 - you *will*
  get random crashes. If you think that dealing with interesting bug
  reports - e.g. caused by application foo which was built against your
  wxGTK[gtk3] and then crashed after enumerating its plugin directory
  because of the presence of binary plugin bar which links to libbaz which
  sometimes dlopens gtk2 at runtime when USE=wombat is enabled  - is more
  fun than doing a bit of work at the start and slotting wxGTK, then
  please go ahead ;)
 
 Yeah and package built against wxGTK (gtk2) could dlopen gtk3 at runtime
 today.  That's already the case.  But what does that have to do with slotting?

Oh.  The libs are named explicitly:

  /usr/lib64/libwx_gtk2u_core-3.0.so
  /usr/lib64/libwx_gtk3u_core-3.0.so

You can't load the wrong one.


-- 
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

[gentoo-dev] Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

[Ryan Hill]

On Wed, 12 Feb 2014 09:10:31 +0100
Gilles Dartiguelongue e...@gentoo.org wrote:

 Le mardi 11 février 2014 à 19:33 -0500, Chris Reffett a écrit :
  This doesn't make sense to me at all. I can't see why slotted
  libraries can't just use USE flags to specify what toolkit they're
  built against, just like any other package in the tree (so, for
  example, a package that needs webkit-gtk built against gtk3 would
  depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware
  that there could be limitations I'm unaware of (maybe the package only
  can build one at a time?), but this is how it looks to me. By
  switching to versioned gtk flags, this kills two birds with one stone:
  it makes it obvious to the end user which version they're trying to
  build their package against, and it gets rid of the need for (ab)using
  revision numbers to implement slots like that.
 
 And here comes the version abuse troll again. This discussion was
 settled months ago by exhaustion so please do not try to put some
 gasoline on it.

Using arbitrary 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

[gentoo-dev] Re: [RFC] Tightening EAPI rules

[Ryan Hill]

On Mon, 10 Feb 2014 20:43:41 +0800
Patrick Lauer patr...@gentoo.org wrote:

 At the time EAPI 0 was in limbo as toolchain required it
 (What's the current status of toolchain on that?)

GCC is now EAPI 2 except for gcc-apple and kgcc64.  I'm going to deprecate EAPI
0 and 1 soon but need to give 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 Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

[Ryan Hill]

On Tue, 11 Feb 2014 19:33:06 -0500
Chris Reffett creff...@gentoo.org wrote:

 This doesn't make sense to me at all. I can't see why slotted
 libraries can't just use USE flags to specify what toolkit they're
 built against, just like any other package in the tree (so, for
 example, a package that needs webkit-gtk built against gtk3 would
 depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware
 that there could be limitations I'm unaware of (maybe the package only
 can build one at a time?), but this is how it looks to me. By
 switching to versioned gtk flags, this kills two birds with one stone:
 it makes it obvious to the end user which version they're trying to
 build their package against, and it gets rid of the need for (ab)using
 revision numbers to implement slots like that.

Exactly.  For wxGTK my options are using a gtk3 USE flag, adding a whole new
wxGTK-gtk3 ebuild, or using a 3.0-gtk3 SLOT and some clumsy -r300 thing.
The second option brings along a nightmare of file collisions (we have enough
trouble supporting multiple installed versions, never mind multiple toolkits
within those versions), and 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

[gentoo-dev] Re: Default USE changes for fortran and mudflap?

[Ryan Hill]

On Sun, 12 Jan 2014 09:40:01 +0100
Pacho Ramos pa...@gentoo.org wrote:

 I was also wondering about what we prefer if Michal's suggestion is not
 possible:
 - Build support for other langs by default - More time when we need to
 emerge gcc or update it but less time as we don't need to rebuild for
 that (I remember when I needed to build pdftk and needed to wait for a
 gcc rebuild giving gcj support)
 - Build support for other langs disabled by default - Well, does it
 save so much time to compensate the rebuilds we would need to do in the
 future when 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: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: Default USE changes for fortran and mudflap?

[Ryan Hill]

On Sun, 12 Jan 2014 09:24:20 +0100
Michał Górny mgo...@gentoo.org wrote:

 Dnia 2014-01-12, o godz. 01:53:47
 Ryan Hill dirtye...@gentoo.org 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 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.
 
 Well, I'd say we should work on making 'other languages' buildable
 without rebuilding the whole giant gcc stack. Especially that
 the stacked build makes it impossible to use distcc at least partially.

Bootstrapping makes distcc impossible, and you can't bootstrap these days
without building C and C++.  Even if you're not bootstrapping, the back and
middle ends are shared.  You have to build them to build the front-ends.  Maybe
you could cut out a couple of the target libraries, so you're really not gaining
much.

If the build times really get to you then you could try something like:

GCC_MAKE_TARGET=all EXTRA_ECONF=--disable-bootstrap \
  emerge -av1 sys-devel/gcc:4.8

distcc should work for most of the build (the target libs must be built with
the just-built compiler so that can't be distributed).

Anyways, assuming we can't split out fortran, would you be for or against
enabling it by default?  I'm good either way.


-- 
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

[gentoo-dev] Re: Default USE changes for fortran and mudflap?

[Ryan Hill]

On Sun, 12 Jan 2014 01:53:47 -0600
Ryan Hill dirtye...@gentoo.org 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 and enabling it as a default
USE flag for gcc as requested in bug #372663.  Thanks for the feedback.


-- 
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

[gentoo-dev] Default USE changes for fortran and mudflap?

[Ryan Hill]

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.

mudflap:
This is currently enabled by default but I'd like to disable it.  It controls
libmudflap and the -fmudflap flag.  I think the only reason this flag exists is
so we can disable it in crossdev.  It's not required by anything in the tree,
the code is bitrotten and has been removed for GCC 4.9. If you know how to use
-fmudflap, you know how to set a USE flag.  

fortran:
Do we want to keep enabling fortran by 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 Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

On Fri, 10 Jan 2014 01:35:09 -0500
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:

 More to the point, this specific use flag appears to have no purpose
 what-so-ever.  If a user can do exactly the same with
 CFLAGS=-fno-stack-protector in make.conf, and it would be INSANE for a
 package to dep on gcc[nossp] then this is has got to be one of the most
 useless use flags in gentoo.

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
adds -fstack-check and -z,now to the linker by default as well.  The pie half
adds -fPIE but also a crtbeginP section for linking static libs with -pie.  So
there are situations where you want to disable one or both, if only for
testing.  But what I forgot is that hardened installs multiple gcc-config
profiles to switch these out on the fly.  So there goes that idea.

It might be useful to have these flags so we can mask them on archs that don't
support ssp/pie.  But that's always been true and it looks like sh is the only
place we've bothered for some reason.

 Not saying I would block this 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 common sense gets through.


-- 
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

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

On Fri, 10 Jan 2014 16:24:38 +0100
Magnus Granberg zo...@gentoo.org wrote:

 Hi
 Have patched toolchain.eclass with the patch and with your change.
 Updated 4.8.2 updated with the needed changes and commit it.
 The use hardened  gcc-specs-ssp  append-cflags $(test-flags-CC -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/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

On Fri, 10 Jan 2014 15:08:02 -0500
Anthony G. Basile bas...@opensource.dyc.edu 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
  adds -fstack-check and -z,now to the linker by default as well.  The pie
  half
 
 I'm pretty sure we're not adding -fstack-check unless something has 
 changed.  Where are you seeing that?
 
 The reason I'm concerned is because of situations like bug #471756. 
 stack-check incumbers a register which in some situations (like the asm 
 in ffmpeg) can get you into trouble with not enough GENERAL_REGS.

40_all_gcc48_config_esp.patch:

  54 +   #if defined ( EFAULT_SSP ) || defined ( EFAULT_PIE_SSP )
  55 +   #define ESP_OPTIONS_SSP_SPEC \
  56 +   %{nostdlib|nodefaultlibs|ffreestanding|fno-stack-protector| \
  57 +   fstack-protector|fstack-protector-all:;:-fstack-protector-all} 
\
  58 +   %{fstack-check|fstack-check=*:;: -fstack-check}

  It might be useful to have these flags so we can mask them on archs that
  don't support ssp/pie.  But that's always been true and it looks like sh is
  the only place we've bothered for some reason.
 
 Yes please.  I had this issue on mips where gcc didn't support ssp for 
 early versions of gcc 4.x.

There's a list of arches in every gcc ebuild that support PIE and SSP for
both glibc and uclibc.  AFAICT you would just have to remove mips from that
list.


-- 
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

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

On Thu, 09 Jan 2014 16:11:28 -0500
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 01/09/2014 03:58 PM, Magnus Granberg wrote:
  Hi
  
  Some time ago we discussed that we should enable stack smashing 
  (-fstack-protector) by default.  So we opened a bug to track this [1].  
  The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips,
  ppc, ppc64 and arm will be affected by this change. 
  
  You can turn off ssp by using the nossp USE flag or by adding 
  -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same 
  patch as Debian/Ubuntu but with some Gentoo fixes.
 
 Please avoid noblah use flags.
 
 http://devmanual.gentoo.org/general-concepts/use-flags/
 
 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

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

On Thu, 09 Jan 2014 17:29:26 -0500
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 01/09/2014 05:21 PM, Michał Górny wrote:
  Dnia 2014-01-09, o godz. 17:06:52
  Anthony G. Basile bluen...@gentoo.org napisał(a):
  
  On 01/09/2014 04:57 PM, Pacho Ramos wrote:
  What are the advantages of disabling SSP to deserve that special
  handling via USE flag or easily disabling it appending the flag?
 
  There are some cases where ssp could break things.  I know of once case 
  right now, but its somewhat exotic.  Also, sometimes we *want* to break 
  things for testing.  I'm thinking here of instance where we want to test 
  a pax hardened kernel to see if it catches abuses of memory which would 
  otherwise be caught by executables emitted from a hardened toolchain.  
  Take a look at the app-admin/paxtest suite.
  
  Just to be clear, are we talking about potential system-wide breakage
  or single, specific packages being broken by SSP? In other words, are
  there cases when people will really want to disable SSP completely?
  
  Unless I'm misunderstanding something, your examples sound like you
  just want -fno-stack-protector per-package. I don't really think you
  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 pointless.
 
 Personally I don't feel this is needed, and the added benefit of
 clearing up a bogus noblah use flag makes me smile.
 
 Zorry, do we really need this flag?

Yes, we do.  I want a way to disable it at a toolchain level.


-- 
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

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

On Thu, 09 Jan 2014 21:58:46 +0100
Magnus Granberg zo...@gentoo.org wrote:

 - use hardened  make_gcc_hard
 + if ( tc_version_is_at_least 4.8 || use hardened )  ! use vanilla ; 
 then

s/4.8/4.8.2

Or should we wait until the next release (4.8.3 or 4.9.0)?  I think I'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

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

On Thu, 9 Jan 2014 17:41:08 -0600
William Hubbs willi...@gentoo.org 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.

http://devmanual.gentoo.org/general-concepts/use-flags/

ssp flag that defaults to on is fine.
   
   This flag already exists and has always worked this way. 
  
  already exists and has always worked this way is not really a good
  argument. The rest of the tree sticks to guidelines, so why not here?
 
 Agreed again. Saying that something has always worked a certain way in
 the past is not justification for keeping it working that way,
 especially when there are preferred ways of doing the same thing that
 are different.

Sure, I'm just pointing out that nothing is changing here.  It sounded like
people were objecting to the addition of a new no* flag.  I agree we should
change them once we can but that shouldn't block this patch.


   We don't have USE defaults yet.
  
  Now if you had said we can't use USE defaults yet since current ebuilds
  are still at EAPI=0... that would have been slightly more informative. :)
  
  (Yes I've seen that there is work going on, and I think that's good. Being 
  careful when modernizing makes sense here of course.)
 
 Right, I thought someone had updated toolchain.eclass to use a modern
 eapi, but I hadn't seen any more on that in some time. What's the
 latest?

I did, but I can't start using new features until I bring all the ebuilds up to
a minimum EAPI.  I'm going to start that this weekend.



-- 
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

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

On Thu, 9 Jan 2014 17:30:46 -0600
Ryan Hill dirtye...@gentoo.org wrote:

 On Thu, 09 Jan 2014 17:29:26 -0500
 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On 01/09/2014 05:21 PM, Michał Górny wrote:
   Dnia 2014-01-09, o godz. 17:06:52
   Anthony G. Basile bluen...@gentoo.org napisał(a):
   
   On 01/09/2014 04:57 PM, Pacho Ramos wrote:
   What are the advantages of disabling SSP to deserve that special
   handling via USE flag or easily disabling it appending the flag?
  
   There are some cases where ssp could break things.  I know of once case 
   right now, but its somewhat exotic.  Also, sometimes we *want* to break 
   things for testing.  I'm thinking here of instance where we want to test 
   a pax hardened kernel to see if it catches abuses of memory which would 
   otherwise be caught by executables emitted from a hardened toolchain.  
   Take a look at the app-admin/paxtest suite.
   
   Just to be clear, are we talking about potential system-wide breakage
   or single, specific packages being broken by SSP? In other words, are
   there cases when people will really want to disable SSP completely?
   
   Unless I'm misunderstanding something, your examples sound like you
   just want -fno-stack-protector per-package. I don't really think you
   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 pointless.
  
  Personally I don't feel this is needed, and the added benefit of
  clearing up a bogus noblah use flag makes me smile.
  
  Zorry, do we really need this flag?
 
 Yes, we do.  I want a way to disable it at a toolchain level.

Let me clarify.  I would like to be able to disable it without relying on
CFLAGS or anything the user could fiddle with.  I need a big red off switch,
at least for now.


-- 
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

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Ryan Hill]

On Thu, 09 Jan 2014 21:58:46 +0100
Magnus Granberg zo...@gentoo.org wrote:

 Some time ago we discussed that we should enable stack smashing 
 (-fstack-protector) by default.  So we opened a bug to track this [1].  
 The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc, 
 ppc64 and arm will be affected by this change. 
 
 You can turn off ssp by using the nossp USE flag or by adding 
 -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same 
 patch as Debian/Ubuntu but with some Gentoo fixes.
 
 The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and 
 ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will 
 make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn 
 it on or off with hardened_gcc_works() that will make some sanity checks.

I went ahead and spun a new patchset for the compiler-side stuff if anyone
wants to start playing around.

- apply the eclass patch from bug #484714 (the one attached to Magnus' email
  wouldn't apply for me but maybe my mailer mangled it)
- in gcc-4.8.2.ebuild do:

-PATCH_VER=1.3
+PATCH_VER=1.4-ssptest
 
-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

[gentoo-dev] Re: RFC: new global USE flag srcdist

[Ryan Hill]

On Fri, 3 Jan 2014 00:53:17 +0100
Ulrich Mueller u...@gentoo.org 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.
 
 I don't get your point here. The licenses of a package have to be
 checked in any case. Why would it be more complicated to check the
 full set of files in the tarball, instead of the subset of files that
 the package will actually install?

I was trying to see how many packages contain licenses that aren't already in
LICENSES, assuming these would be ones that we would have to have a srcdist USE
flag for.  Rich said that is was rare.  I'm finding every package I've checked
so far would need one.

Either way I don't care what you do.


-- 
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

[gentoo-dev] Re: RFC: new global USE flag srcdist

[Ryan Hill]

On Wed, 1 Jan 2014 23:28:54 +0100
Ulrich Mueller u...@gentoo.org wrote:

 Hi,
 According to GLEP 23 [1], the LICENSE variable regulates the software
 that is installed on a system. There is however some ambiguity in
 this: should it cover the actual files installed on the system, or
 everything that is included in the package's tarball? This question
 was asked several times in the past and arose in bug 492424 [2] again.
 
 I've always preferred the first interpretation, because the second one
 would inevitably require us to repack many tarballs, in order to keep
 their license in @FREE. This would for example include the Linux
 kernel, where we could no longer use deblobbing, but would have to
 provide our own tarball with firmware blobs removed. Not sure if users
 would be happy if we wouldn't install from pristine sources any more.
 We also have mirror and fetch restrictions which allow us to control
 what tarballs we distribute, independent of the LICENSE variable.

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 source then we really
don't have to worry about it, and as you said we already have mechanisms to
deal with that.  What the user does with that source is their business, and
they are solely responsible for following the terms of the license(s).  IIRC
this is the stance we took back in 2006 with the cdrtools debacle [1].

So I don't understand why we would have to remove anything from the tarballs.
Unless there's a license in there that forbids mirroring then there's no need
to list other licenses that aren't relevant.  The user wants to know what
conditions he needs to follow to build and use the package, not what the
tarball happen to contain.  If you tell him that he can't install something
because of a license on a piece of code that is never used, built, or
installed, he isn't going to be very happy.

 Within existing EAPIs we have only one LICENSE variable available.
 (Extending it would be possible in future EAPIs, but we would end up
 with a very long transition period.) USE conditional syntax is allowed
 in LICENSE, though. So I wonder if this couldn't be used for the
 intended purpose. For example, for specifying licenses of distfiles:
 
   LICENSE=licenses of installed stuff
   srcdist? ( licenses of unused stuff in distfiles )
 
 This idea was discussed within the licenses team, and the overall
 reaction was positive.
 
 What do you think?

Wouldn't that just prevent you from installing the package altogether?
Some people might be okay with that, but if it's a package you need then you
are forced to choose between either disabling the USE flag or stop filtering the
license for that package. Either way you end up with 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

[gentoo-dev] Re: RFC: new global USE flag srcdist

[Ryan Hill]

On Thu, 2 Jan 2014 06:50:06 -0600
Ryan Hill dirtye...@gentoo.org 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 source then we
 really don't have to worry about it, and as you said we already have
 mechanisms to deal with that.  What the user does with that source is their
 business, and they are solely responsible for following the terms of the
 license(s).  IIRC this is the stance we took back in 2006 with the cdrtools
 debacle [1].

[1]  http://lwn.net/Articles/199061/



-- 
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

[gentoo-dev] Re: RFC: new global USE flag srcdist

[Ryan Hill]

On Thu, 2 Jan 2014 19:17:50 +0100
Ulrich Mueller u...@gentoo.org wrote:

  On Thu, 2 Jan 2014, Luis Ressel wrote:
 
  RESTRICT is somewhat complementary to LICENSE and cannot provide as
  much information. Especially, RESTRICT=mirror doesn't say under
  what license the restricted pieces are, and doesn't allow for
  ACCEPT_LICENSE filtering.
 
  But is this detailed information really neccessary? The use-case is
  ensuring the legality of distfiles mirroring -- you're either
  allowed to do it nor not, the exact license doesn't matter here.
 
 This is not primarily about distfiles mirroring, about about giving
 users a choice what distfiles they will accept on their systems (for
 whatever reasons, e.g. legal or philosophical). Besides, not all users
 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 user that might not actually exist.


-- 
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

[gentoo-dev] Re: RFC: new global USE flag srcdist

[Ryan Hill]

On Thu, 02 Jan 2014 11:10:54 -0500
Ian Stakenvicius a...@gentoo.org 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.  If the variable is unset then it's
  business as usual.
  
 
 ..or we could just do this, using the existing RESTRICT=mirror
 that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR,
 NODISTCACHEDIR defaults to DISTDIR; if RESTRICT=mirror then
 distfiles are saved to NODISTCACHEDIR, otherwise are saved to DISTDIR.

This I like (except the name, but mine sucks too ;p).  Portage should probably
check both dirs when searching for distfiles so it can find manually fetched
files the user may have dropped into the wrong one, and also to maybe warn if
sources are found in distdir for a mirror-restricted package (or just move them
to the right place itself).


-- 
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

[gentoo-dev] Re: RFC: new global USE flag srcdist

[Ryan Hill]

On Thu, 2 Jan 2014 16:20:09 -0500
Rich Freeman ri...@gentoo.org wrote:

 On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill dirtye...@gentoo.org 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
  basis of a theoretic user that might not actually exist.
 
 Why would we need to do that when we don't specify a LICENSE for every
 single file we install from a package.  LICENSE is a string of
 licenses that apply to all of the files installed by a package, and
 USE=srcdist LICENSE is a string of licenses that apply to all of the
 SRC_URIs.

That's what I said (or meant I guess).  When I say distfile it means
tarball/SRC_URI.  In order to make a decision about what distfiles you will
allow on your system, you need to know the licenses in those distfiles.  So we
would have to list all the licenses in that distfile, whether they apply or
not.  

 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
 more work than additionally specifying additional licenses for the
 rare tarball that contains extra stuff under a different license that
 we don't install.  I don't really see a downside to this approach - if
 you don't need the extra info then don't look at it - it won't pertain
 to 98% of the packages in portage anyway.

I don't think it's that rare, but I don't know.  To find out for sure we'd have
to check every distfile we distribute. :p


-- 
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

[gentoo-dev] Re: RFC: new global USE flag srcdist

[Ryan Hill]

On Thu, 2 Jan 2014 16:07:22 -0600
Ryan Hill dirtye...@gentoo.org wrote:

 On Thu, 2 Jan 2014 16:20:09 -0500
 Rich Freeman ri...@gentoo.org 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
  more work than additionally specifying additional licenses for the
  rare tarball that contains extra stuff under a different license that
  we don't install.  I don't really see a downside to this approach - if
  you don't need the extra info then don't look at it - it won't pertain
  to 98% of the packages in portage anyway.
 
 I don't think it's that rare, but I don't know.  To find out for sure we'd
 have to check every distfile we distribute. :p

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.

gcc-4.7.2.tar
ACAA ,ATT ,BSD ,BSD-2-Clause ,BSD-3-Clause ,BSD-lite ,BSD-possibility 
,BSD-style ,BSL-1.0 ,CC-BY-SA-3.0 ,CPL ,Docbook ,Dual-license ,FSF 
,FSF-possibility ,GFDL-1.1 ,GFDL-1.2+ ,GFDL-1.3 ,GNU-Manpages ,Gov't-rights 
,GPL ,GPL-2.0 ,GPL-2.0+ ,GPL-2.0-with-autoconf-exception 
,GPL-2.0-with-bison-exception ,GPL-2.0-with-classpath-exception ,GPL-3.0 
,GPL-3.0+ ,GPL-3.0-with-autoconf-exception ,GPL-3.0-with-GCC-exception 
,GPL-exception ,GPL-possibility ,IETF ,info-zip ,IPL-1.0 ,ISC ,JPEG/netpbm 
,LGPL ,LGPL-2.0+ ,LGPL-2.1 ,LGPL-2.1+ ,LGPL-3.0 ,LGPL-3.0+ 
,Microsoft-possibility ,MIT ,MIT-style ,MPL-1.1 ,No_license_found 
,Non-commercial! ,Non-profit! ,NOT-public-domain ,NotreDame-style 
,Public-domain ,Public-domain-ref ,Same-license-as ,SAX-PD ,See-doc(OTHER) 
,See-file(COPYING) ,See-file(README) ,Sun-possibility ,SunPro ,Sun(tm) 
,TeX-exception ,Trademark-ref ,UnclassifiedLicense ,W3C ,W3C-IP 
,W3C-possibility ,W3C-style ,X11 ,X11-possibility ,Zlib ,Zlib-possibility

eglibc-2.17
Artistic-1.0 ,BSD-3-Clause ,BSD-lite ,BSD-style ,BSL-1.0 ,Cisco-style ,CMU ,FSF 
,GNU-style(EXECUTE) ,GPL ,GPL-2.0 ,GPL-2.0+ ,GPL-3.0+ 
,GPL-3.0+-with-bison-exception ,GPL-exception ,GPL-possibility ,IBM 
,IBM-possibility ,IETF ,InnerNet-2.00 ,ISC ,LGPL ,LGPL-2.0 ,LGPL-2.0+ ,LGPL-2.1 
,LGPL-2.1+ ,LGPL-3.0+ ,LGPL-possibility ,Microsoft-possibility ,MIT ,MIT-style 
,No_license_found ,Oracle-Berkeley-DB ,Public-domain ,Public-domain-ref 
,Same-license-as ,See-doc(OTHER) ,Sun-possibility ,SunPro ,Trademark-ref 
,X11-possibility

apache2 version 2.2
Apache-2.0 ,Apache-possibility ,Bellcore ,BSD-2-Clause ,BSD-3-Clause 
,BSD-4-Clause-UC ,BSD-possibility ,Cisco ,CMU ,FSF ,GPL ,GPL-2.0+ 
,GPL-2.0-with-autoconf-exception ,GPL-exception ,ISC ,MIT ,MIT-style ,MPL 
,No_license_found ,OLDAP ,Public-domain ,Public-domain-ref ,RSA-Security 
,See-doc(OTHER) ,See-file(COPYING) ,See-file(LICENSE) ,Zeus ,Zlib

Ghostscript
AFPL-Ghostscript ,Aladdin(Closed-Source!) ,Aladdin-Ghostscript ,ATT-style 
,Bitstream ,BSD-style ,GNU-Ghostscript ,GPL ,GPL-2.0+ ,No_license_found 
,Not-for-sale! ,NOT-public-domain ,Public-domain ,See-doc(OTHER) 
,UnclassifiedLicense ,zlib/libpng

Perl
Apache-2.0 ,Artistic ,Artistic-2.0 ,Artistic-possibility ,Bellcore ,BSD 
,BSD-lite ,BSD-possibility ,BSD-style ,FSF ,GFDL-1.1 ,GPL ,GPL-1.0 ,GPL-1.0+ 
,GPL-2.0+ ,GPL-3.0 ,GPL-Bison-exception ,LGPL ,LGPL-2.1 ,LGPL-3.0 ,MIT 
,MIT-possibility ,MIT-style ,MPL ,MPL-1.1 ,No_license_found ,Non-commercial! 
,Perl-possibility ,Public-domain ,Public-domain-ref ,RSA-Security 
,Same-license-as ,See-doc(OTHER) ,See-file(LICENSE) ,See-file(README) 
,Trademark-ref ,UnclassifiedLicense ,Unicode ,zlib/libpng 
,zlib/libpng-possibility

util-linux-2.23.1.tar
BSD ,BSD-3-Clause ,BSD-4-Clause ,BSD-lite ,BSD-style ,Debian-SPI-style ,FSF 
,FSF-possibility ,GNU-Manpages ,GPL ,GPL-1.0+ ,GPL-2.0 ,GPL-2.0+ 
,GPL-2.0-with-autoconf-exception ,GPL-3.0+ ,GPL-exception ,LGPL ,LGPL-2.0 
,LGPL-2.0+ ,LGPL-2.0-possibility ,LGPL-2.1 ,LGPL-2.1+ ,MIT ,MIT-style 
,No_license_found ,NOT-public-domain ,Public-domain ,Public-domain(C) 
,Public-domain-ref ,Same-license-as ,UnclassifiedLicense ,X11

[1] http://www.fossology.org/projects/fossology


-- 
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

[gentoo-portage-dev] Re: [PATCH 2/2] repoman: Add check for missing slot operators (bug 493742)

[Ryan Hill]

On Wed,  1 Jan 2014 23:14:11 +0100
sebastianlut...@gmx.de wrote:

+   slot.operator.missing: The ebuild depends on package with several...
   ^ a

-- 
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

[gentoo-dev] Re: dev-lang/go

[Ryan Hill]

On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway em...@vfemail.net wrote:

 I really like working with Go, and would like to see a means of merging
 Go packages with Portage. In short I am asking if anyone else is
 interested in a Go project.
 
 
 For those who aren't familiar with 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 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/umurmur: metadata.xml ChangeLog

[Ryan Hill]

On Wed, 25 Dec 2013 18:37:24 +0100
Patrick Lauer patr...@gentoo.org wrote:

 On 12/25/2013 01:26 PM, hasufell wrote:
 
  You are interfering with my workflow and I already told you why I kept
  the useflag, so stop reverting my commits after I told you the reasons
  in a private mail.
  
  QA is more than just running repoman and doing random commits on other
  peoples ebuilds. (besides that you already managed to break the
  Manifest of this stable package last time)
  
 
 S 
 
   25 Dec 2013; Julian Ospald hasuf...@gentoo.org metadata.xml:
   revert pseudo-QA commit
 
   25 Dec 2013; Patrick Lauer patr...@gentoo.org metadata.xml:
   Remove unneeded useflag description from metadata.xml
 
   23 Dec 2013; Julian Ospald hasuf...@gentoo.org metadata.xml:
   add unused useflag since the breakage is expected to be temporary
 
 
 irker104 AutoRepomanReport for Wed Dec 25 17:22:16 UTC 2013
 irker104 AutoRepomanWarning: media-sound/umurmur/metadata.xml: unused
 local USE-description: 'polarssl'
 
 
 Why the bleeping bleep are you KNOWINGLY introducing a useless
 regression that serves no purpose but 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: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: How to support C++11 in libraries?

[Ryan Hill]

On Thu, 19 Dec 2013 10:18:55 +0100
Michał Górny mgo...@gentoo.org wrote:

 And that brings another issue in Gentoo -- gcc-config. AFAIR this tool
 is completely insane and switches libstdc++ along with gcc version.
 As a result, after switching to a gcc version with different C++ ABI,
 installed software gets broken. And you can't really fix it without
 going through the broken-system state or some hackery.

This hasn't been true for a while now.  The latest version of libstdc++ is
always used, no matter what version is selected.  I can't remember when this
was changed but we've gone through a couple GCC stabilizations since.

I have no opinion on how to support C++-11, except that it can't be globally
enabled.  We have to support compilers that predate the standard.

I wouldn't like any pkg-config hackery like ICU tried to pull a while back, but
now 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

[gentoo-portage-dev] Re: [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races

[Ryan Hill]

On Tue, 17 Dec 2013 18:28:12 -0500
Mike Frysinger vap...@gentoo.org wrote:

 Use $BASHPID which will be unique even in subshells.
 
 URL: https://bugs.gentoo.org/487478
 ---
  bin/phase-helpers.sh | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)
 
 diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
 index ec48c94..1a7ae03 100644
 --- a/bin/phase-helpers.sh
 +++ b/bin/phase-helpers.sh
 @@ -469,6 +469,7 @@ unpack() {
  
  econf() {
   local x
 + local pid=${BASHPID}

This requires bash 4.0.  I'm all for it, but haters gonna hate.


-- 
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

[gentoo-portage-dev] Re: [PATCH] make.conf.5: Document PYTHON_TARGETS, bug #493180

[Ryan Hill]

On Tue, 3 Dec 2013 13:43:49 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 User contribution, FWIW:  I'll stay neutral on having it in the manpage, 
 but I definitely agree PYTHON_TARGETS and PYTHON_SINGLE_TARGET need more 
 visibility, and I like the proposed explanation in the patch very much, 
 as it finally cleared up the relationship between the two of them for me.

+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

[gentoo-dev] Re: RFC: New Project: Bug Cleaners

[Ryan Hill]

On Sat, 16 Nov 2013 12:16:01 +0100
Tom Wijsman tom...@gentoo.org wrote:

 Hello
 
 This is a request for comments on a new project:
 
 http://wiki.gentoo.org/wiki/Project:Bug_Cleaners

Sounds like a good idea to me.

  * When is a bug considered still useful?
 
There are clear cases like a bug that's no longer reproducable and
thus clearly doesn't apply; however, there are cases where one might
be in doubt (eg. Do people still want it resolved? Do we still want
to add a package that stopped its development X years ago?) that
might not be so clear cut. I'd like to get clearer borders defined.

I'd like it if maintainer-wanted bugs stayed open.  They often have useful
discussion, ebuilds, patches, etc.  I have one from 2006 that just got pinged
yesterday.  One thing you could do is CC teams that you think might be
interested in the package.

Of course if the project is dead and buried then the bug should just be closed.

  * Do we need a mail alias so we can get assigned or CC-ed on bugs?
 
This one gets me in doubt, the only case I can come up with is that
being able to CC bug-clean...@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 track of them.  


-- 
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

[gentoo-dev] Re: Package removal without proper last-riting

[Ryan Hill]

On Mon, 11 Nov 2013 10:32:55 +0100
Manuel Rüger mr...@gentoo.org wrote:

 Hi,
 
 I recently noticed it twice, that it seems to be common practice to
 remove a package without using the methods described in [1], but just
 dropping it from cvs.
 
 From my observations packages removed without last-rites could be
 characterized by this:
 
 - it was a dependency of another package
 - this package dropped / incorporated the dependency
 - no other packages depend on it
 - there are possible forks or updates, but maintainer doesn't care^W^W
 has no interest
 
 This might work for the main tree, but it won't for overlays, that might
 also depend on these packages (because they have a patched / older
 version of your maintained package).
 
 Please stop killing user experience or document this feature in [1].
 
 Best regards,
 
 Manuel
 
 [1] http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

I wasn't aware last-riting had become general policy.  It was originally
started by the treecleaner team to give people time to object to
maintainer-needed removals, 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/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Looking for app-i18n/poedit maintainer

[Ryan Hill]

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 Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Thu, 12 Sep 2013 11:23:04 -0400
Anthony G. Basile bluen...@gentoo.org wrote:

 The hardened team has talked about this in IRC and our general feeling 
 is that adding *just* ssp to vanilla gcc specs is okay. While there are 
 some performance hits, it is generally safe and should cause little 
 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.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Wed, 11 Sep 2013 04:49:55 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 If I'm not mistaken, dirtyepic intends to patch gcc directly to enable 
 -fstack-protector, changing the default at that level so it'll be used 
 unless -fno-stack-protector is in CFLAGS.  At least, that's how I 
 interpret (dirtyepic):
 
   'filter-flags -fstack-protector [won't] actually work
   (we have to patch the compiler, not just add it to the
   default flags in the profiles or something).

Actually it turns out I was 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 weren't being disabled.


-- 
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

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Tue, 10 Sep 2013 18:41:34 -0400
Richard Yao r...@gentoo.org wrote:

 A few thoughts:
 
 1. The kernel expects -fno-stack-protector to be the default. What will
 the effect be on kernel configuration once -fstack-protector is the default?

The kernel has supported building with -fstack-protector since 2.6.19, (at least
on x86/x86-64).  It's controlled by CONFIG_CC_STACKPROTECTOR and if it's
disabled then -fno-stack-protector is explicitly added to the command line.

 2. We should make sure that -fno-stack-protector is a supported CFLAG.
 This will make it easier to handle complaints from the vocal minority of
 our user base that want every last percentage point of performance.

If by supported you mean that they won't be removed by things like strip-flags,
then yes, -fstack-protector -fstack-protector-all -fno-stack-protector and
-fno-stack-protector-all are all on the whitelist.

 3. I would like to point out that we are talking about deviating from
 upstream behavior and everyone is okay with it. Anyone who thinks we
 should stick to upstream when it is not good for us should speak now or
 risk being asked where were you when... 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

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Mon, 9 Sep 2013 08:21:35 -0400
Rich Freeman ri...@gentoo.org wrote:

 On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill dirtye...@gentoo.org 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 people who realize that
 100% protection might not be possible to raise an objection so that we
 end up with 0% protection instead?

No, all I've heard so far is support and wanted to give anyone with an opposing
viewpoint a chance to speak up.  I support it, but if there are any problems we
might run into it's best we know about them beforehand, no?  I wasn't looking
for a reason to veto it.
 
 Why not just do the sensible thing (IMHO) and make it a default, and
 then if it doesn't work for an individual package deal with it on an
 individual basis?  We already encourage maintainers to try to get
 custom CFLAGS to work when practical, but when not practical we filter
 them.  I don't see stack protection as any different.  If there is a
 fix, then fix it, and if not, then disable it.  I don't see a lack of
 stack-protection as a reason to keep something out of the tree.

Rich, that's exactly what I'm saying.

We have to make an effort to fix things properly, like we do with any supported
feature.  That's something I see as one of the key strengths of this group we
have.  Obviously there are cases where a fix isn't possible (glibc and gcc
itself are prime examples) and we need to disable it.  That's fine.  But we
need to discourage people sweeping problems under the rug because they're
inconvenient, especially when those problems may indicate security issues.

I'm just trying to set proper expectations - that this change may break
people's packages, and they may have to do some work to find out why and how to
fix it.  I don't like creating more work for people, so I want to be sure there
is consensus on this first.  So far it sounds like there is.


-- 
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

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Sat, 07 Sep 2013 19:08:57 -0400
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:

 Personally I think this would be a great stepping stone.  If we add
 - -fstack-protector to 4.8.1 it will improve security (only a little I
 know) and give us an idea of what issues we may have.  After a short
 enjoyment of fixing any issues which come up we could more to
 - -fstack-protector-strong in 4.9.

Okay it won't be available for 4.8.1.  It's going to require a couple minor
glibc changes and a lot of testing.  A bunch of packages stick workarounds
behind a hardened USE flag or do things like `filter-flags -fstack-protector`
which don't actually work (we have to patch the compiler, not just add it to
the default flags in the profiles or something).  I need to check the
interactions with hardened's spec files.  And I need to get 4.8.1 out the door
two weeks ago. Once we fix the fallout from the unmasking I'll get back to this.

I also want to make a comment on the implications of this change that people
may not have considered.  Bugs caused by -fstack-protector can no longer be
just dismissed as unsupported, invalid, or assigned to the hardened team and
forgotten about.  You will be expected to fix them, and `append-flags
-fno-stack-protector` is not an acceptable fix.  You can't champion for more
secure defaults and then just disable them when they get in your way.

So does anyone have any objections to making -fstack-protector 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

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Sun, 8 Sep 2013 11:05:16 + (UTC)
Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote:

 Ryan Hill dirtye...@gentoo.org 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).
 
 You get the same delay for lazy linking, only not necessarily
 everything immediately when the application starts up.
 And even then it is only faster (at startup) if only very few symbols
 are needed near the beginning.
 
 Quite the opposite, total time of loading huge projects like
 kde or libreoffice can even be faster with now, since you do
 not need administration overhead for keeping track of resolving.
 I did not realize a measurable difference for kde and libreoffice
 even on my slow machines - random things like location on harddisk
 apparently had a much bigger impact on startup.
 Please really try before you fix your opinion.

I'm basing my opinion on the experiences reported by other distros, by
openwall, and by our own hardened team.  In any case my opinion doesn't really
matter because in the end since I'm not the one who gets to make that
decision.  I misrepresented that and I apologize.  I would still be against
making this change.

  However, isn't it time to use gnu now for all users? [...]
 
  Sure, but the sysv hash is teeny and backward compatibility is
  always nice if it's next to free.
 
 But it is not completely free, and the majority of users
 will never have any need for it - in factõ I do not know
 any use-case, but of course I do not know all ancient software
 sitting around somewhere.
 Those few who need it can add the option without difficulties.

FWIW I agree but I am not the binutils maintainer.


-- 
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

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Thu, 05 Sep 2013 12:13:28 +0200
Agostino Sarubbo a...@gentoo.org wrote:

 Hello,
 
 during an irc debate, me and other people just noticed that the default 
 profile could use more flags to enhance the security.
 
 An hint is here:
 https://wiki.ubuntu.com/ToolChain/CompilerFlags
 
 Please argue about what we _don't_ use.
 
 Note: please CC me in your response.

* -fstack-protector{-all}
No thank you.  -fstack-protector has very limited coverage (which is why
Ubuntu felt they needed to mess with the min size) and -fstack-protector-all
has enough overhead that every distro that experimented with it dropped it in
the end.  If security is important enough to you that you are willing to take
the hit then you should be using hardened where it's the default.

There is a new option, -fstack-protector-strong, that's intended to be a
balance between the two extremes and something that distros can enable by
default.  It was just added to mainline so it should be in GCC 4.9.  So let's
revisit this a couple years down the line.

* -D_FORTIFY_SOURCE=2
Enabled by default since gcc-4.5.0 (patch)

* -Wformat -Wformat-security
Enabled by default since gcc 4.3.3 (patch)

* -Wl,-z,relro
Enabled by default since binutils 2.18 (and as far back as 2.15 for the HJL
releases). (patch)

* -Wl,--hash-style={both,gnu}
Enabled by default since binutils 2.18 except on mips where it is unsupported.
(patch sets it to both, developer profiles set it to gnu for ignored LDFLAGs
detection)

* -Wl,--no-copy-dt-needed-entries/-Wl,--no-add-needed
Enabled by default since binutils 2.22. (upstream default)

* -Wl,--as-needed
Enabled by default since July 2010 (in profiles).  I think this is the upstream
default now as well.

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

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Sat, 7 Sep 2013 18:10:42 + (UTC)
Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote:

 Ryan Hill dirtye...@gentoo.org 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 severe impact on execution time or code size.

The numbers I've seen show a maximum of 5% coverage for code that has a large
number of functions containing char arrays on the stack.  Most code doesn't fall
into that category.  Coverage of perl was 0.5%, xorg 5%, kernel 3%.  Those are
really old numbers though.  The most recent I've seen is Chromium's coverage is
2%.  There is an upper bound of 8% performance overhead using -fstack-protector
according to the design spec.  If you guys are okay with that then we can try
enabling it for 4.8.1.

  * -Wl,-z,relro
  Enabled by default since binutils 2.18
 
 This gives its real impact on secutiry only when combined with
 
 * -Wl,-z,now
 
 The latter is not enabled by default AFAIK.

That's a bit misleading.  Immediate binding does allow the GOT to be made
readonly but relro does a lot more than that.  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).  If you want full
relro, enable it yourself or use hardened.

 I would like to suggest also another flag
 
 * -Wl,-z,noexecstack
 
 This should be the default, but e.g. some broken gcc versions
 forgot this default when using -flto.
 I am using this flag since I realized this -flto bug and never
 had any problems with it.

Well, portage will already tell you if your package installed any binaries with
executable stacks and I don't see many of those warnings that aren't binary
packages so I think we're good.

 
  * -Wl,--hash-style={both,gnu}
 
 I don't know what this has to do with security.

I'm just responding to the list on the Ubuntu page.

 However, isn't it time to use gnu now for all users?  Except for
 very strange binary-only code it should not cause any problems.
 The majority of users would not realize a difference but profit
 from smaller binaries.

Sure, but the sysv hash is teeny and backward compatibility is always nice if
it's next to free.

Here are some more resources if anyone is interested:

https://wiki.debian.org/Hardening
https://bugs.archlinux.org/task/18864
https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart
http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html

-- 
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

[gentoo-dev] Re: GCC 4.8 unmasking

[Ryan Hill]

On Wed, 14 Aug 2013 17:56:42 +0200
Luca Barbato lu_z...@gentoo.org wrote:

  We don't build glibc with -O3.  Other libc's should either not use -O3 or
  use -fno-tree-loop-distribute-patterns where applicable.
 
 On certain arches the memcpy tranformation happens even on lower
 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 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: GCC 4.8 unmasking

[Ryan Hill]

On Tue, 13 Aug 2013 07:13:13 +0200
Luca Barbato lu_z...@gentoo.org 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.gentoo.org/416069  xorg-2.eclass: add
  --disable-selective-werror to configure https://bugs.gentoo.org/461954  GCC
  4.8 porting
 
 gcc-4.8 can miscompile libc
 
 http://gcc.gnu.org/bugzilla//show_bug.cgi?id=56888
 
 We should make sure we do not get bitten by this.

We don't build glibc with -O3.  Other libc's should either not use -O3 or
use -fno-tree-loop-distribute-patterns where applicable.


-- 
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

[gentoo-dev] GCC 4.8 unmasking

[Ryan Hill]

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 Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: check-reqs* vs CFLAGS=-g

[Ryan Hill]

On Fri, 2 Aug 2013 13:47:10 +0100
Diego Elio Pettenò flamee...@flameeyes.eu wrote:

 On Fri, Aug 2, 2013 at 1:08 PM, Andreas K. Huettel
 dilfri...@gentoo.orgwrote:
 
  I thought -O0 was generally discouraged, even for debugging?!
 
 
 As Michał said, it all depends on what you want to debug. I would say that
 for 90% of issues you *do not* want to use -O0. Your code might not even
 compile (libav for instance used to rely heavily in the DCE pass being
 executed, GCC disables DCE at -O0), and even if it, you're now given a
 different program altogether, so if you're looking for a crash, it might
 magically disappear (memory areas get cleared out at -O0 but they might be
 re-used without clearing at any other -O level).

If you're feeling adventurous you could try -Og -g with gcc 4.8.


-- 
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

[gentoo-dev] Re: check-reqs* vs CFLAGS=-g

[Ryan Hill]

On Thu, 1 Aug 2013 13:33:48 +0200
Michał Górny mgo...@gentoo.org wrote:

 What can we do to improve this? I'm not really happy to have LLVM
 ebuild analyze CFLAGS to set proper space constraints. Maybe we should
 make check-reqs-r1 automatically bump the constraints by some
 statistical multiplier when it detects -g?

The problem with that is there is no way to determine how much larger a -g
build will be.  It varies widely across GCC versions (eg. when var-tracking was
added the size of debug info exploded, in some cases up to an order of
magnitude), and different -g/-ggdb levels.  All 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

[gentoo-dev] Re: Global USE flag: git

[Ryan Hill]

On Sat, 03 Aug 2013 16:19:16 +0200
hasufell hasuf...@gentoo.org wrote:

 I find it a bit silly to require discussing global useflags on dev-ML.

The purpose of the discussion is to come up with a description that is general
enough to apply to most ebuilds that use that flag.  It's a throwback to when
global 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 @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature