Re: [arch-dev-public] Discussion about optional dependencies

2016-07-18 Thread Daniel Micay via arch-dev-public
On Tue, 2016-07-19 at 03:39 +0200, Balló György via arch-dev-public wrote: > I agree with this, and the same apply for vlc I think, which recently > lost > its qt4 dependency: > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packag > es/vlc=b1a56bb8d107ebb51a6f2e32c67f866e2693517b

Re: [arch-dev-public] signoffs are dead

2016-07-01 Thread Daniel Micay via arch-dev-public
On Fri, 2016-07-01 at 21:24 +0200, Florian Pritz via arch-dev-public wrote: > Am 2016-06-30 09:41, schrieb Johannes Löthberg via arch-dev-public: > > That has actually come up on IRC a lot of times over the last > > couple > > years, users asking how to sign-off packages / if they can help > >

Re: [arch-dev-public] i686 and SSE2

2016-09-16 Thread Daniel Micay via arch-dev-public
On Fri, 2016-09-16 at 21:44 +0200, Bartłomiej Piotrowski wrote: > Actually, why don't raise the bar higher? SSE2 has been introduced in > 2001 – that's 15 years to upgrade one's hardware and given my sad > experiences with computers, I find it hard to believe anyone has that > old PC that happens

Re: [arch-dev-public] i686 and SSE2

2016-09-28 Thread Daniel Micay via arch-dev-public
On Wed, 2016-09-28 at 21:12 +0200, Bartłomiej Piotrowski wrote: > On 2016-09-28 05:10, Allan McRae wrote: > > > > The most pressing issue is #1.  So lets get back to the issue of the > > increasing amount of software requiring SSE2.  How do we solve this? > > I thought about it, and I lean

Re: [arch-dev-public] Changing compilation flags

2016-12-13 Thread Daniel Micay via arch-dev-public
> I need time to fix this.  It is probably just test suite assumptions > rather than errors. Could we start with the changes other than PIE? Those won't need any immediate rebuilds. signature.asc Description: This is a digitally signed message part

Re: [arch-dev-public] Changing compilation flags

2017-06-30 Thread Daniel Micay via arch-dev-public
On Fri, 2017-06-30 at 11:07 +0200, Bartłomiej Piotrowski wrote: > On 2016-10-24 05:56, Allan McRae wrote: > > 1) building gcc to enable PIE by default > > I am in the middle of rebuilding gcc with --enable-default-pie. When > it > finishes, I will start a todo for rebuilding packages with static

Re: [arch-dev-public] Changing compilation flags

2017-07-02 Thread Daniel Micay via arch-dev-public
Anyway, I think -Wl,-z,now, --enable-default-pie and --enable-default- ssp are a good starting point. Could enable -fstack-check=specific now, but it's not going to save a mass rebuild by doing it now (if the goal is to rebuild everything important with it) because they'll be improving it. Using

Re: [arch-dev-public] Changing compilation flags

2017-07-02 Thread Daniel Micay via arch-dev-public
On Sun, 2017-07-02 at 08:32 +1000, Allan McRae wrote: > On 02/07/17 06:51, Bartłomiej Piotrowski wrote: > > On 2017-06-30 23:44, Allan McRae wrote: > > > On 30/06/17 19:07, Bartłomiej Piotrowski wrote: > > > > On 2016-10-24 05:56, Allan McRae wrote: > > > > > 1) building gcc to enable PIE by

Re: [arch-dev-public] Changing compilation flags

2017-07-05 Thread Daniel Micay via arch-dev-public
On Wed, 2017-07-05 at 21:06 +0300, Evangelos Foutras wrote: > On 5 July 2017 at 19:51, Daniel Micay <danielmi...@gmail.com> wrote: > > On Wed, 2017-07-05 at 12:36 +0300, Evangelos Foutras wrote: > > > On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public > > &g

Re: [arch-dev-public] Changing compilation flags

2017-07-05 Thread Daniel Micay via arch-dev-public
On Wed, 2017-07-05 at 12:36 +0300, Evangelos Foutras wrote: > On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public > <arch-dev-public@archlinux.org> wrote: > > Using -fno-plt would be a nice tiny little performance boost at > > runtime > > but then it's imp

Re: [arch-dev-public] Changing compilation flags

2017-07-05 Thread Daniel Micay via arch-dev-public
> So I think it would be a good idea to flip the default to -z,now in > the > linker if we're going to use -fno-plt. I think they'd take a patch for > that upstream. Clang issue could be avoided with a 1 line patch adding > another no-op flag and they'd take that upstream. It's harmless to use >