headers
Anthony G. Basile | 1 Feb 01:58
Picon
Favicon

Re: Can we get PIE on all SUID binaries by default, por favor?

On 01/29/2012 02:14 PM, Mike Frysinger wrote:
> On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
>> I've run nbench on two amd64 systems both running the same kernel
>> vanilla-3.2.2.
> i don't think nbench is a good benchmark for this as it isn't really testing
> what you think it's testing.  it's very good at validating math support in the
> ISA/ABI, optimized compiler output, and supplementary math implementations in
> libgcc.  PIE vs non-PIE will still be able to multiply/divide in pretty much
> the same amount of time.

I know, but the problem is, what benchmark best approximates common 
every day use?  So I wrote the following which really hits the problem 
hard on x86:

int modfac(int n)
{
     if(n==0) return 1;
     return n * modfac(n-1);
}

int main()
{
     int i;
     for( i = 0 ; i < 4096*4096 ; i++ ) modfac(4096);
     return 0;
}

Using vanilla kernel 3.2.2, userland built with vanilla toolchain, 
gcc-4.5.3-r1, glibc-2.13-r4, binutils-2.21.1-r1, compiling my code 
simply as gcc -o test modfac.c, CFLAGS="-O2 -march=i686 -pipe" I get:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sebastian Pipping | 1 Feb 07:01
Picon
Favicon

[rfc] Which ebuild category should these ebulds go into?

Hello!

Anthoine and I are working on some new ebuilds related to a 3D mouse at
the moment.  For two of these I wonder what package category makes a
good fit.  While I would save your time on such a simple thing, I would
like to avoid moving around things later, too.  I have inspected the
related metadata.xml files already.

Which categories do you advise for?

  spacenavd
    driver daemon (with optional X support)
      --> sys-apps/spacenavd ?
      --> app-misc/spacenavd ?
      --> .. ?

  libspnav
    library accessing before-mentioned daemon
      --> dev-libs/libspnav ?
      --> media-libs/libspnav ?
      --> sys-libs/libspnav ?
      --> .. ?

  spnavcfg
    X11/GTK GUI tool for configuration
      --> x11-misc/spnavcfg seems right

Thanks in advance!

Best,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Samuli Suominen | 1 Feb 09:10
Picon
Favicon

Lastrite: FlowScan, CUFlow, and JKFlow

# Sammuli Suominen <ssuominen <at> gentoo.org> (01 Feb 2012)
# Masked for removal in 30 days for having unallowed depend for
# unslotted <net-analyzer/rrdtool-1.2 in the same stabilization
# level
net-analyzer/FlowScan
dev-perl/CUFlow
dev-perl/JKFlow
Permalink | Reply | 0 comments |
headers
Alexandre Rostovtsev | 1 Feb 09:16
Picon
Favicon

Re: [rfc] Which ebuild category should these ebulds go into?

On Wed, 2012-02-01 at 07:01 +0100, Sebastian Pipping wrote:
>   spacenavd
>     driver daemon (with optional X support)
>       --> sys-apps/spacenavd ?
>       --> app-misc/spacenavd ?
>       --> .. ?

I would suggest either sys-apps or x11-drivers.

>   libspnav
>     library accessing before-mentioned daemon
>       --> dev-libs/libspnav ?
>       --> media-libs/libspnav ?
>       --> sys-libs/libspnav ?
>       --> .. ?

dev-libs seems reasonable.

sys-libs definitely feels wrong, libspnav would look out of place in
that exclusive company of core system libraries.

-Alexandre
Permalink | Reply | 1 comment |
headers
ScytheMan | 1 Feb 09:42
Picon

Re: [rfc] Which ebuild category should these ebulds go into?

Take a look at g15daemon (useful for some logitech keyboards).

There you have:

app-misc/g15daemon
dev-libs/libg15
Permalink | Reply | 0 comments |
headers
Matthew Thode | 1 Feb 18:33
Picon
Favicon

Re: Can we get PIE on all SUID binaries by default, por favor?

On Tue, 31 Jan 2012 19:58:32 -0500
"Anthony G. Basile" <blueness <at> gentoo.org> wrote:

> On 01/29/2012 02:14 PM, Mike Frysinger wrote:
> > On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
> >> I've run nbench on two amd64 systems both running the same kernel
> >> vanilla-3.2.2.
> > i don't think nbench is a good benchmark for this as it isn't
> > really testing what you think it's testing.  it's very good at
> > validating math support in the ISA/ABI, optimized compiler output,
> > and supplementary math implementations in libgcc.  PIE vs non-PIE
> > will still be able to multiply/divide in pretty much the same
> > amount of time.
> 
> I know, but the problem is, what benchmark best approximates common 
> every day use?  So I wrote the following which really hits the
> problem hard on x86:
> 
> int modfac(int n)
> {
>      if(n==0) return 1;
>      return n * modfac(n-1);
> }
> 
> int main()
> {
>      int i;
>      for( i = 0 ; i < 4096*4096 ; i++ ) modfac(4096);
>      return 0;
> }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sebastian Pipping | 1 Feb 19:26
Picon
Favicon

Re: [rfc] Which ebuild category should these ebulds go into?

On 02/01/2012 09:42 AM, ScytheMan wrote:
> Take a look at g15daemon (useful for some logitech keyboards).
> 
> There you have:
> 
> app-misc/g15daemon
> dev-libs/libg15
> 

Great, thanks!

Best,

Sebastian
Permalink | Reply | 0 comments |
headers
Nirbheek Chauhan | 1 Feb 20:25
Picon
Favicon
Gravatar

RFC: New eclass: mozlinguas.eclass

Hello folks,

We in the mozilla team got tired of duplicating the same 50 lines of
code across 6 ebuilds, and decided to consolidate them inside one
eclass.

The eclass is specific to Mozilla products (no one else can or should use it).

It generates SRC_URI using a list of supported language packs
${LANGS[@]}, and exports src_unpack and src_install to install
language packs.

I'd love to have the attached eclass reviewed before I commit it. For
those using gmail, here's a web copy: http://i.cx/ahp
(git.o.g.o/mozilla)

Thanks!

--

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
Attachment (mozlinguas.eclass): application/octet-stream, 4005 bytes
Permalink | Reply | 7 comments |
headers
Mike Frysinger | 1 Feb 21:05
Picon
Favicon
Gravatar

unpacker.eclass

any feedback before merging this initial version ?
	https://bugs.gentoo.org/399019
-mike

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v 1.377 2012/01/03 08:45:36 jlec Exp $

# @ECLASS: unpacker.eclass
# @MAINTAINER:
# base-system <at> gentoo.org
# @BLURB: helpers for extraneous file formats and consistent behavior across EAPI's
# @DESCRIPTION:
# Some extraneous file formats are not part of PMS, or are only in certain
# EAPI's.  Rather than worrying about that, support the crazy cruft here
# and for all EAPI versions.

# Possible todos:
#  - merge rpm unpacking
#  - support partial unpacks?

if [[ ${___ECLASS_ONCE_UNPACKER} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_UNPACKER="recur -_+^+_- spank"

# @ECLASS-VARIABLE: UNPACKER_BZ2
# @DEFAULT_UNSET
# @DESCRIPTION:
# Utility to use to decompress bzip2 files.  Will dynamically pick between
# `pbzip2` and `bzip2`.  Make sure your choice accepts the "-c" option.
# Note: this is meant for users to set, not ebuilds.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Mike Frysinger | 1 Feb 21:08
Picon
Favicon
Gravatar

Re: Can we get PIE on all SUID binaries by default, por favor?

On Tuesday 31 January 2012 19:58:32 Anthony G. Basile wrote:
> On 01/29/2012 02:14 PM, Mike Frysinger wrote:
> > On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
> >> I've run nbench on two amd64 systems both running the same kernel
> >> vanilla-3.2.2.
> > 
> > i don't think nbench is a good benchmark for this as it isn't really
> > testing what you think it's testing.  it's very good at validating math
> > support in the ISA/ABI, optimized compiler output, and supplementary
> > math implementations in libgcc.  PIE vs non-PIE will still be able to
> > multiply/divide in pretty much the same amount of time.
> 
> I know, but the problem is, what benchmark best approximates common
> every day use?  So I wrote the following which really hits the problem
> hard on x86:
> 
> int modfac(int n)
> {
>      if(n==0) return 1;
>      return n * modfac(n-1);
> }
> 
> int main()
> {
>      int i;
>      for( i = 0 ; i < 4096*4096 ; i++ ) modfac(4096);
>      return 0;
> }
> 
> Using vanilla kernel 3.2.2, userland built with vanilla toolchain,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane