Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Mike Frysinger]

On Saturday 17 June 2006 01:22, Alin Nastac wrote:
> Thomas Cort wrote:
> > What is the proper quoting style for using epatch? In the tree there
> > are about 3 different styles...
> >
> > epatch ${FILESDIR}/some-fix.patch  # used by 7326 ebuilds
> > epatch "${FILESDIR}"/some-fix.patch# used by 3092 ebuilds
> > epatch "${FILESDIR}/some-fix.patch"# used by 1434 ebuilds
>
> 2 and 3 are fine.

correct ... personally i prefer the 2nd myself

> > What is the proper quoting style for defining the S variable? In the
> > tree there are about 3 different styles...
> >
> > S=${WORKDIR}/${MY_P}# used by 5270 ebuilds
> > S="${WORKDIR}"/${MY_P}  # used by 43 ebuilds
> > S="${WORKDIR}/${MY_P}"  # used by 2259 ebuilds
>
> ditto

not really ... all three will work fine, but i prefer the first myself as the 
quoting is not needed here
-mike


pgp2CKQP3l9gx.pgp
Description: PGP signature

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Mike Frysinger]

On Saturday 17 June 2006 01:34, Donnie Berkholz wrote:
> 2) When you set a variable to a string, you should use quotes.

dont need them, bash does not expand in setting variables
-mike


pgpVgd6PjFRxs.pgp
Description: PGP signature

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Mike Frysinger]

On Saturday 17 June 2006 02:02, Drake Wyrm wrote:
> Thomas Cort <[EMAIL PROTECTED]> wrote:
> > DEPEND="virtual/libc" # used by 809 ebuilds
>
> There are opinions on both sides of this subject, but I think that most
> devs are starting to see the value in this. If a package requires some
> other package, say so. It may be a bit more work (twelve keystrokes),
> but it's worth the extra effort (twelve keystrokes) to be complete.

virtual/libc has no value in DEPEND/RDEPEND

you cannot have a system without a system libc (well you can, but this *very 
edge* case doesnt matter in the portage world)
-mike


pgpDHMGKevvKR.pgp
Description: PGP signature

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Robin H. Johnson]

On Fri, Jun 16, 2006 at 11:02:27PM -0700, Drake Wyrm wrote:
> Thomas Cort <[EMAIL PROTECTED]> wrote:
> > What is the proper quoting style for using epatch? In the tree there
> > are about 3 different styles...
> 
> > What is the proper quoting style for defining the S variable? In the
> > tree there are about 3 different styles...
> It might be prudent to quote the variables, in case somebody, for
> whatever reason, has strange characters in assorted paths.
> 
> > What is the purpose of setting DEPEND and RDEPEND to "" if DEPEND and
> > RDEPEND are optional[1][2]? Isn't that just a waste of disk space /
> > bandwidth? DEPEND="virtual/libc" seems like a waste too as it is an
> > implicit system dependency[3], any reason for using it?
> > 
> > DEPEND="" # used by 1479 ebuilds
> > RDEPEND=""# used by 884 ebuilds
> These two are probably not necessary, but some devs might prefer to use
> them in their ebuilds for the sake of explicitly stating the implied.
> 
> > DEPEND="virtual/libc" # used by 809 ebuilds
> There are opinions on both sides of this subject, but I think that most
> devs are starting to see the value in this. If a package requires some
> other package, say so. It may be a bit more work (twelve keystrokes),
> but it's worth the extra effort (twelve keystrokes) to be complete.
If I have a package that produces a dynamic (non-static) binary, and it
has no other deps, then I throw in virtual/libc.

If it produces a static binary only, or no binary, then it gets "".

What I would like to see at some point, is a real way of differencing
packages that really have no runtime dependencies - not even anything in
the system packages. As to what the best way to go about it, I'm not
certain, but I do think specifying a few packages: virtual/compiler,
virtual/libc and a few limited things from system packages should be ok.
Or maybe even virtual/system (with the compiler removed from that
virtual).

-- 
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpDMVcp3uSSv.pgp
Description: PGP signature

[gentoo-dev] Re: variable quoting, setting optional variables to "", and depending on virtual/libc

[Duncan]

Mike Frysinger <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on  Sat, 17 Jun
2006 03:30:29 -0400:

>> > What is the proper quoting style for defining the S variable? In the
>> > tree there are about 3 different styles...
>> >
>> >S=${WORKDIR}/${MY_P}# used by 5270 ebuilds
>> >S="${WORKDIR}"/${MY_P}  # used by 43 ebuilds
>> >S="${WORKDIR}/${MY_P}"  # used by 2259 ebuilds
>>
>> ditto
> 
> not really ... all three will work fine, but i prefer the first myself as the 
> quoting is not needed here

What if someone has PORTAGE_TMPDIR="/tmp/portage temporary workspace" or
"/var/tmp/\$whatever" or some such (yes I know that's crazy, but...)?  I'd
agree with the ditto, not with the all three will work fine.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Kevin F. Quinn]

On Sat, 17 Jun 2006 00:35:30 -0400
Thomas Cort <[EMAIL PROTECTED]> wrote:

> What is the purpose of setting DEPEND and RDEPEND to "" if DEPEND and
> RDEPEND are optional[1][2]? Isn't that just a waste of disk space /
> bandwidth? DEPEND="virtual/libc" seems like a waste too as it is an
> implicit system dependency[3], any reason for using it?
> 
>   DEPEND="" # used by 1479 ebuilds
>   RDEPEND=""# used by 884 ebuilds
>   DEPEND="virtual/libc" # used by 809 ebuilds

Setting RDEPEND to "" indicates that the stuff in DEPEND isn't needed
to run the package, and can safely be pruned later.  If RDEPEND is not
set, it is defaulted to $DEPEND by portage.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: variable quoting, setting optional variables to "", and depending on virtual/libc

[Peper]

> What if someone has PORTAGE_TMPDIR="/tmp/portage temporary workspace" or
> "/var/tmp/\$whatever" or some such (yes I know that's crazy, but...)?  I'd
> agree with the ditto, not with the all three will work fine.
It makes no difference in assignments, so all of them will do.

-- 
Best Regards,
Peper
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Kevin F. Quinn]

On Sat, 17 Jun 2006 00:30:04 -0700
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:

> If I have a package that produces a dynamic (non-static) binary, and
> it has no other deps, then I throw in virtual/libc.
> 
> If it produces a static binary only, or no binary, then it gets "".

If you're going to do that, static binaries would usually depend on
virtual/libc to be built (using libc.a) so it would be in DEPEND but
explicitly removed from RDEPEND.

> What I would like to see at some point, is a real way of differencing
> packages that really have no runtime dependencies - not even anything
> in the system packages. As to what the best way to go about it, I'm
> not certain, but I do think specifying a few packages:
> virtual/compiler, virtual/libc and a few limited things from system
> packages should be ok. Or maybe even virtual/system (with the
> compiler removed from that virtual).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

[gentoo-dev] Re: Re: variable quoting, setting optional variables to "", and depending on virtual/libc

[Duncan]

Peper <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted
below, on  Sat, 17 Jun 2006 11:09:45 +0200:

> It makes no difference in assignments, so all of them will do.

Noted that based on the other replies after posting.  Thanks, tho.  I
didn't know that until reading the thread.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Peper]

> Setting RDEPEND to "" indicates that the stuff in DEPEND isn't needed
> to run the package, and can safely be pruned later.  If RDEPEND is not
> set, it is defaulted to $DEPEND by portage.
If you inherit some eclass with deps, not set RDEPEND won't be defaulted to 
DEPEND from ebuild, but will also include deps from eclass, which is 
incorrect b/c these deps are needed for build time only(like sed, 
autotools...). One needs to make sure that RDEPEND is correct if not set 
manually in ebuild with eclasses.

-- 
Best Regards,
Peper
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: variable quoting, setting optional variables to "", and depending on virtual/libc

[Peper]

> Noted that based on the other replies after posting.  Thanks, tho.  I
> didn't know that until reading the thread.
No, it was genstef who pointed me that out when making my first ebuild.

-- 
Best Regards,
Peper
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Kevin F. Quinn]

On Sat, 17 Jun 2006 03:33:28 -0400
Mike Frysinger <[EMAIL PROTECTED]> wrote:

> On Saturday 17 June 2006 02:02, Drake Wyrm wrote:
> > Thomas Cort <[EMAIL PROTECTED]> wrote:
> > >   DEPEND="virtual/libc" # used by 809 ebuilds
> >
> > There are opinions on both sides of this subject, but I think that
> > most devs are starting to see the value in this. If a package
> > requires some other package, say so. It may be a bit more work
> > (twelve keystrokes), but it's worth the extra effort (twelve
> > keystrokes) to be complete.
> 
> virtual/libc has no value in DEPEND/RDEPEND
> 
> you cannot have a system without a system libc (well you can, but
> this *very edge* case doesnt matter in the portage world)

Agreed.

However "Package Dependencies" in the dev handbook
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap5
suggests adding it as it uses virtual/libc as an example of the use of
virtuals.

Regarding implicit system dependencies which can be omitted from *DEPEND
http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency
obviously USE flag settings affect what's pulled in by system as does
the profile.

So I think if we're to allow essential system dependencies to be
omitted, we should be very explicit; i.e. publish a strict list.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

[gentoo-dev] strict-aliasing rules, don't break them

[Luca Barbato]

You may aware or not that there is a nice optimization (more effective
if you have some registers to spare) based on how you access memory
thought variables. Since it wasn't that effective and didn't break
anything it is enabled since -O2.

Problem: recent gcc are doing some quite smart tricks with aliasing and
as result they will break in subtle way your code if you use
strict-aliasing rules optimization on type puns.

Quick solution: enforce -fno-strict-aliasing as global cflag.

Side effect: you may lose a bit in performance, but better safe than
sorry: the first package showing issues was openssl[1] mismatching
hashes, guess how discovered that and how (hint: ssh was refusing logins...)

Long term solution:
1- check your new package for aliasing compliance, and if you have time
fix it in the code or in the makefile, if you haven't append
-fno-strict-aliasing to the cflags and maybe send a notice about it upstream

2- append -fno-strict-aliasing to every source known to have such issue.

I'll do 2 on all packages in the tree showing the issue if you think is
ok, arches not yet affected will be in the future.

lu

[1]http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14725


-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Drake Wyrm]

Harald van D??k <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 16, 2006 at 11:31:27PM -0700, Drake Wyrm wrote:
> > Harald van D??k <[EMAIL PROTECTED]> wrote:
> > > Any is fine, there is no word splitting or wildcard expansion in
> > > shell variable assignments.
> > 
> > $ foo="bar   *   baz"
> > $ wombat=$foo
> > $ echo $wombat
> > bar somedir somefile baz
> 
> The wildcard expansion is not during the variable assignment, it's
> during the expansion of $wombat. Just try echo "$wombat" instead.

Right, you are! I do apologize.

-- 
Major premise: You can't handle the truth.
Minor premise: The truth is out there.
Conclusion: You can't handle what is out there.


pgp3sNQ4AuUNR.pgp
Description: PGP signature

Re: [gentoo-dev] Herds suck, fix them

[Jan Kundrát]

Christel Dahlskjaer wrote:
> On Thu, 2006-06-15 at 00:26 -0500, Lance Albertson wrote:
>> Alec Warner wrote:
>>> So apparently they suck, anyone have a new shiny idea on how to group
>>> packages and maintaining developers?
> 
> How exactly does one go about maintaining our developers? ;)

"developers maintaining $foo" == "those developers that are maintainers
of $foo", imho ;)

Blésmrt,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Diego 'Flameeyes' Pettenò]

On Saturday 17 June 2006 12:17, Luca Barbato wrote:
> Long term solution:
The best long term solution would have been to fix the code, but actually I 
didn't ever found a quick explanation of how to fix this kind of code...

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpy0mG0pHVmf.pgp
Description: PGP signature

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:
> On Saturday 17 June 2006 12:17, Luca Barbato wrote:
>> Long term solution:
> The best long term solution would have been to fix the code, but actually I 
> didn't ever found a quick explanation of how to fix this kind of code...
> 

you can use unions or rewrite completely the line using it in another
way, in certain case the type pun is the quickest solution so it's
better to append -fno-strict-aliasing in the Makefile.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Diego 'Flameeyes' Pettenò]

On Saturday 17 June 2006 13:43, Luca Barbato wrote:
> you can use unions or rewrite completely the line using it in another
> way, in certain case the type pun is the quickest solution so it's
> better to append -fno-strict-aliasing in the Makefile.
Err give me an example of the line, a lot of strict aliasing breakage was due 
to double pointers.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpg5SjnSV15q.pgp
Description: PGP signature

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Michael Cummings]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kevin F. Quinn wrote:
> 
 If RDEPEND is not set, it is defaulted to $DEPEND by portage.

Alas, if only. If you inherit an eclass with deps this carry over won't
happen. (And I have the bugs to prove it ;)

~mcummings


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEk/gNq1ztTp5/Ti4RAkjIAJwKPLEKd+T/bHl1v7B850XXCHOP3gCeMF8x
1hosIlwmFZm2f96F9VE5DxI=
=qdGO
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Herds suck, fix them

[Christel Dahlskjaer]

On Sat, 2006-06-17 at 12:55 +0200, Jan Kundrát wrote:
> Christel Dahlskjaer wrote:
> > On Thu, 2006-06-15 at 00:26 -0500, Lance Albertson wrote:
> >> Alec Warner wrote:
> >>> So apparently they suck, anyone have a new shiny idea on how to group
> >>> packages and maintaining developers?
> > 
> > How exactly does one go about maintaining our developers? ;)
> 
> "developers maintaining $foo" == "those developers that are maintainers
> of $foo", imho ;)

Ah damn, and here I nearly got excited.


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Ciaran McCreesh]

On Sat, 17 Jun 2006 11:26:12 +0200 Peper <[EMAIL PROTECTED]> wrote:
| > Setting RDEPEND to "" indicates that the stuff in DEPEND isn't
| > needed to run the package, and can safely be pruned later.  If
| > RDEPEND is not set, it is defaulted to $DEPEND by portage.
|
| If you inherit some eclass with deps, not set RDEPEND won't be
| defaulted to DEPEND from ebuild, but will also include deps from
| eclass, which is incorrect b/c these deps are needed for build time
| only(like sed, autotools...). One needs to make sure that RDEPEND is
| correct if not set manually in ebuild with eclasses.

Incorrect.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Carsten Lohrke]

On Saturday 17 June 2006 14:39, Michael Cummings wrote:
> Kevin F. Quinn wrote:
>
>  If RDEPEND is not set, it is defaulted to $DEPEND by portage.
>
> Alas, if only. If you inherit an eclass with deps this carry over won't
> happen. (And I have the bugs to prove it ;)

Well, has been the job of the eclass the ensure that, of course. But since 
Portage 2.1 this is deprecated anyways and every developer is expected to set 
RDEPEND explicitly, including RDEPEND=$DEPEND, if necessary. Unfortunately 
the ebuild policy has still not been updated.

See also https://bugs.gentoo.org/show_bug.cgi?id=135945


Carsten



pgpdjW6YaQV7L.pgp
Description: PGP signature

Re: [gentoo-dev] Herds suck, fix them

[Carsten Lohrke]

On Saturday 17 June 2006 04:51, Christel Dahlskjaer wrote:
> How exactly does one go about maintaining our developers? ;)

It's devrel's cursed job. Ask them. :)


Carsten


pgpDHDEmEDUMI.pgp
Description: PGP signature

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Harald van Dijk]

On Sat, Jun 17, 2006 at 01:57:33PM +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 17 June 2006 13:43, Luca Barbato wrote:
> > you can use unions or rewrite completely the line using it in another
> > way, in certain case the type pun is the quickest solution so it's
> > better to append -fno-strict-aliasing in the Makefile.
> Err give me an example of the line, a lot of strict aliasing breakage was due 
> to double pointers.

Using your own example from
http://planet.gentoo.org/developers/flameeyes/2006/03/02/fixing_strict_aliasing_warnings

struct dl_node {
  struct dl_node *next;
  struct dl_node *prev;
};
struct dl_head {
  struct dl_node *first;
  struct dl_node *null;
  struct dl_node *last;
};
and then accessing {first, null}, or {null, last} as a struct dl_node
the way to fix the code would be to rewrite the code to use arrays
of pointers instead of simply three pointer members. There is no
valid way to do what the code does using pointer members (that's simple
logic: it relies on the padding between first and null to be exactly the
same as that between null and last, which is a guarantee standard C
doesn't make), so fixing it requires quite a bit of work.

If you don't mind keeping the code invalid, but in such a way that GCC
will compile it as intended, you could do

struct dl_head {
  union {
struct {
  struct dl_node *first;
  struct dl_node *null;
  struct dl_node *last;
};
struct {
  struct dl_node firstnode;
  struct dl_node *dummy1;
};
struct {
  struct dl_node *dummy2;
  struct dl_node secondnode;
};
  };
} h;

and then change
 (struct dl_node *) &h->first
to
 &h->firstnode

and similarly, change
 (struct dl_node *) &h->null
to
 &h->secondnode

Again, it's not valid, and it can still break if not handled with care
even with GCC.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Kevin F. Quinn]

Easiest way to find these is to stick -Wall in global CFLAGS (or just
-Wstrict-aliasing if you want to be more specific), and grep the build
log for 'will break strict aliasing' (LC_ALL=C obviously).  Such
issues should be filed upstream, I guess, to either get the Makefile to
forcibly set -fno-strict-aliasing or to rework the code.

FWIW here's a list of packages that show the warning, from my build logs
for packages I have installed:

app-antivirus/clamav-0.88.2
app-editors/vim-6.4
app-text/enscript-1.6.4-r2
app-text/ghostscript-esp-8.15.1_p20060430
dev-db/mysql-4.1.20
dev-java/gnu-classpath-0.90
dev-lang/nasm-0.98.39-r3
dev-lang/ocaml-3.08.4
dev-libs/cyrus-sasl-2.1.21-r2
dev-libs/glib-2.8.6
dev-libs/nspr-4.6.1-r2
dev-libs/nss-3.11-r1
dev-tcltk/itcl-3.3-r1
dev-util/valgrind-3.1.1
gnome-base/orbit-0.5.17-r1
kde-base/kdm-3.5.1
kde-base/kopete-3.5.1-r1
media-libs/faad2-2.0-r11
media-libs/fontconfig-2.2.3
media-libs/libsdl-1.2.9-r1
media-libs/xine-lib-1.1.2_pre20060328-r9
media-sound/audacious-0.2.3
media-video/vlc-0.8.5-r1
net-dialup/ppp-2.4.2-r15
net-fs/samba-3.0.22
net-irc/bitchx-1.1-r2
net-nds/openldap-2.3.24-r1
sys-apps/coreutils-5.94-r1
sys-apps/dbus-0.60-r4
sys-apps/shadow-4.0.15-r2
sys-devel/autogen-5.7.1
sys-devel/gcc-* (libjava)
sys-devel/gdb-6.3-r5
sys-fs/e2fsprogs-1.38-r1
sys-libs/slang-1.4.9-r2
x11-apps/xdm-1.0.4
x11-libs/gtk+-2.8.12
x11-libs/gtkglarea-1.2.3-r1
x11-libs/libXScrnSaver-1.1.0
x11-libs/libXaw-1.0.2
x11-libs/libXt-1.0.2
x11-wm/twm-1.0.1

Whether any of these actually trigger real problems or not I don't
know; but then probaly neither do the upstream developers...

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Ciaran McCreesh]

On Sat, 17 Jun 2006 15:20:52 +0200 Harald van Dijk <[EMAIL PROTECTED]>
wrote:
| and then accessing {first, null}, or {null, last} as a struct dl_node
| the way to fix the code would be to rewrite the code to use arrays
| of pointers instead of simply three pointer members. There is no
| valid way to do what the code does using pointer members (that's
| simple logic: it relies on the padding between first and null to be
| exactly the same as that between null and last, which is a guarantee
| standard C doesn't make), so fixing it requires quite a bit of work.

It can be done using nested structs.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Harald van Dijk]

On Sat, Jun 17, 2006 at 03:32:36PM +0200, Kevin F. Quinn wrote:
> Easiest way to find these is to stick -Wall in global CFLAGS (or just
> -Wstrict-aliasing if you want to be more specific), and grep the build
> log for 'will break strict aliasing' (LC_ALL=C obviously).

That warning is given for valid code too. Please only add
-fno-strict-aliasing if you actually find a package misbehaves without
it, or if you have verified that there is indeed an aliasing violation
in the code.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Harald van Dijk]

On Sat, Jun 17, 2006 at 02:28:28PM +0100, Ciaran McCreesh wrote:
> On Sat, 17 Jun 2006 15:20:52 +0200 Harald van Dijk <[EMAIL PROTECTED]>
> wrote:
> | and then accessing {first, null}, or {null, last} as a struct dl_node
> | the way to fix the code would be to rewrite the code to use arrays
> | of pointers instead of simply three pointer members. There is no
> | valid way to do what the code does using pointer members (that's
> | simple logic: it relies on the padding between first and null to be
> | exactly the same as that between null and last, which is a guarantee
> | standard C doesn't make), so fixing it requires quite a bit of work.
> 
> It can be done using nested structs.

No, it can't: the two dl_nodes overlap.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Herds suck, fix them

[Ferris McCormick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 17 Jun 2006, Carsten Lohrke wrote:


On Saturday 17 June 2006 04:51, Christel Dahlskjaer wrote:

How exactly does one go about maintaining our developers? ;)


It's devrel's cursed job. Ask them. :)


Carsten



Um, whips and chains.  But we're nice about it. :)

Regards,
Ferris

- --
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Devrel, Sparc)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)

iD8DBQFElAsdQa6M3+I///cRAkw9AKCuLkwdVENA8Hy++xBOS76PLGPXywCfW977
N0yvQEPZNYLlpqlau54M18c=
=lWhc
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Sunrise: way forward, semi-official, review

[Stefan Schweizer]

To my fellow developers and users,

with the council meeting not much has changed for Sunrise:
"Sunrise is still suspended/closed in overlays until the details can be
hashed out"

And that is what we are doing now. We have moved the overlay to
gentoo-sunrise.org to analyze, improve and hash out the details. So the
Sunrise project is now "semi-official". While being an official Gentoo
Project run by Gentoo developers it is not currently hosted on gentoo.org.

We have also implemented review and added the overlay to layman. It works
like follows:
- users are only able to commit to sunrise/
- developers merge the commit to reviewed/ when they are happy with it
review/ is what is available in layman.

Adding ebuilds from bugzilla is regaining speed and we are looking for new
developers and users to help this project grow. Just drop by in
#gentoo-sunrise if you want to help reviewing or have comments and
suggestions.

Kind regards,
Stefan Schweizer

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Luca Barbato]

Harald van Dijk wrote:

> That warning is given for valid code too. Please only add
> -fno-strict-aliasing if you actually find a package misbehaves without
> it, or if you have verified that there is indeed an aliasing violation
> in the code.

Or just bug upstream to either avoid ugly code or just use
-fno-strict-aliasing when needed.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise: way forward, semi-official, review

[foser]

On Sat, 2006-06-17 at 17:05 +0200, Stefan Schweizer wrote:
> And that is what we are doing now. We have moved the overlay to
> gentoo-sunrise.org to analyze, improve and hash out the details. So the
> Sunrise project is now "semi-official". While being an official Gentoo
> Project run by Gentoo developers it is not currently hosted on gentoo.org.

It doesn't become an official Gentoo project by being run by 'official'
Gentoo developers. There is no such thing as 'semi-official' and as such
the move away from the gentoo domain indicates it has nothing to do with
Gentoo and makes this part of the several third-party Gentoo ebuild
sites around. Good luck with that, but don't try to put a Gentoo
stamp-of-approval on it.

- foser


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] embedded overlay on overlays.gentoo.org

[Stefan Schweizer]

Hi,
solar has requested an account on overlays.gentoo.org for the embedded
overlay for you.
Your password: DX7wnSe40Y

Kind regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] embedded overlay on overlays.gentoo.org

[Mike Doty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stefan Schweizer wrote:
> Hi,
> solar has requested an account on overlays.gentoo.org for the embedded
> overlay for you.
> Your password: DX7wnSe40Y
> 
> Kind regards,
> Stefan
> 
um, doesn't sending a password to a public mailing list defeat the
purpose of the password?

- --
===
Mike Doty  kingtaco -at- gentoo.org
Gentoo/AMD64 Strategic Lead
Gentoo Developer Relations
Gentoo Recruitment Lead
Gentoo Infrastructure
GPG: 0094 7F06 913E 78D6 F1BB  06BA D0AD D125 A797 C7A7
===
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFElClY0K3RJaeXx6cRAgb7AKCu5kXgiAsI1GndQyrukw4Kiq7xGQCglWlV
0E6ej3X75bmuU2N0JHGqTUM=
=w9rz
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] embedded overlay on overlays.gentoo.org

[Seemant Kulleen]

On Sat, 2006-06-17 at 18:04 +0200, Stefan Schweizer wrote:
> Hi,
> solar has requested an account on overlays.gentoo.org for the embedded
> overlay for you.
> Your password: DX7wnSe40Y
> 
> Kind regards,
> Stefan
> 

Was the list the intended recipient of this?

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: embedded overlay on overlays.gentoo.org

[Stefan Schweizer]

Seemant Kulleen wrote:

> On Sat, 2006-06-17 at 18:04 +0200, Stefan Schweizer wrote:
>> Hi,
>> solar has requested an account on overlays.gentoo.org for the embedded
>> overlay for you.
>> Your password: DX7wnSe40Y
>> 
>> Kind regards,
>> Stefan
>> 
> 
> Was the list the intended recipient of this?
> 
no, of course not. I wonder how it ended up there - the password is changed
and mailed to the right recipient now :)

Probably we should move to a key-based system for committers that are
already developers?

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] embedded overlay on overlays.gentoo.org

[Ned Ludd]

On Sat, 2006-06-17 at 18:04 +0200, Stefan Schweizer wrote:
> Hi,
> solar has requested an account on overlays.gentoo.org for the embedded
> overlay for you.
> Your password: DX7wnSe40Y

think you can change my pw and lets do this offlist?


-- 
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: embedded overlay on overlays.gentoo.org

[Stefan Schweizer]

Ned Ludd wrote:
> On Sat, 2006-06-17 at 18:04 +0200, Stefan Schweizer wrote:
>> Hi,
>> solar has requested an account on overlays.gentoo.org for the embedded
>> overlay for you.
>> Your password: DX7wnSe40Y
> think you can change my pw and lets do this offlist?

lol, you have not read accurately. The account was requested by you, it is
not your account :)

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] nss_* and system users

[Mike Frysinger]

On Friday 16 June 2006 10:00, Mike Kelly wrote:
> "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote:
> > On Friday 16 June 2006 05:03, Mike Frysinger wrote:
> > > nss is glibc-only, so such a solution would be inadequate
> >
> > Actually this is one of the strange and rare cases that's not only
> > glibc's. FreeBSD can use nss too :)
>
> Also, it seems that Solaris uses the same /etc/nsswitch.conf as well. I
> don't know about Darwin, though, as I don't have access to a machine.

ok, so in light of this let me rephrase:
working only with nss is not an adequate solution

thanks all for the corrections
-mike


pgpSj9HH7J1pj.pgp
Description: PGP signature

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Mike Frysinger]

On Saturday 17 June 2006 06:17, Luca Barbato wrote:
> Long term solution:
> 1- check your new package for aliasing compliance, and if you have time
> fix it in the code or in the makefile, if you haven't append
> -fno-strict-aliasing to the cflags and maybe send a notice about it
> upstream
>
> 2- append -fno-strict-aliasing to every source known to have such issue.

3 - include checking in portage
http://bugs.gentoo.org/111436
-mike


pgpyUdbtJZS9f.pgp
Description: PGP signature

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Mike Frysinger]

some more docs:
http://gcc.gnu.org/bugs.html#nonbugs_c
Casting does not work as expected when optimization is turned on
-mike


pgpnrnzc6upFu.pgp
Description: PGP signature

[gentoo-dev] Scientific Gentoo reorg

[George Shapovalov]

Hi everybody.

Sorry for crossposting, but many people whom I want to catch with this are not 
on gentoo-science. For the same reason lets keep this initial discussion 
here, on -dev. If we need to expand, lets take it to the gentoo-science, but 
then I would expect everybody interested to sign up ;).

Gentoo Science has been relatively quiet, even though we are making a steady 
progress on many fronts, but lately a few things has caught my attention and 
I think we can do better if create a bit more structure.

At present we count 10 categories containing 309 packages (wow! Considering 
that it all started with some 20 packages I put in sci back when we did not 
have a two-tier categories yet, quite impressive :)). However looking at 
herds.xml I see only 10 devs listed, which just cannot be true (considering, 
according to my experience with bugzilla, that majority of these packages are 
actually maintained). The real situation is that many devs are quietly 
supporting their own packages but are reluctant to join the sci team 
officially. And it is this situation that I want to address.

I see one reasonable rationale for this relctance to join: people are 
afraid "to get too much on theirs hands" by signing up. In reality the 
gentoo-science mailing list is really low on traffic (quite a relief in 
present times ;)), but nonetheless the sheer amount of packages may be 
frightening. Therefore I am proposing to recognize the fact that we 
(Scientific Gentoo project) became big and act accordingly:

1. We need more herds. The easiest possibility is to simply split them 
accordingly to categories. However, with 10 categories, this may be an 
overkill, or, with some categories having >50 packages an underkill, or 
simply may not correspond to maintenance reality (it will definitely fail on 
sci-libs for example). It is hard to tell without seing who does what, so I 
am going to ask for some feedback here (see below).

2. Should we create some subprojects? This really will have to be discussed in 
more detail when people respond and join corresponding teams I guess. 
However, while at it we may as well become a top-level project of our own. 
Right now Scientific Gentoo is under Dektop, which is at the very least 
strange (but all the other options back then were even less fitting..)

3. Mail aliases. Right now we have [EMAIL PROTECTED], which we should keep as 
an all 
encompassing alias for announcements or, well, I am not sure yet what else, 
but time will tell. In addition we should create new ones, one per herd. If 
by chance there are people interested in seeing *all* the bugs (which I 
somehow doubt, but theoretically?), we can reuse [EMAIL PROTECTED] for that as 
well..

So, right now I would like to ask for the feedback on the following:

Q1) I would like to hear about the reasons why people are afraid to join the 
sci team. You may respond to me personally or raise it on the list, but 
please let me/us know about the problems in any case, so that we may address 
them!

Q2) Please let me know if you are supporting or occasionally touching some 
package under sci-* and, assuming we create more herds, which herd it should 
belong to (just make it up as you see fit right now) and whether you would be 
willing to add yourself to the alias of that herd or join some subteam if we 
create one. I will collect the responces and then compile a proposal for the 
new structure.

Q3) Not relevant to this restructuring, but always usefull: if you know of 
some package that you think should really go under sci-something, please let 
us know!

And to finish it all up :)
Q4) If you are a user but would like to be involved more actively, or you have 
to run that particular package for your work but it sits in bugzilla for ages 
and no developer seems sensible enough to take it up, please let us know too. 
Best of all - subscribe to that gentoo-scie mailing list and ask somebody to 
mentor you. By the time it will be over we should have a new structure, so 
you won't end up with the whole 300+ sci packages on your hands (this was 
holding some people with whom I discussed it too).

This should be enough to start with, so, bring it on! :)

George
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Harald van Dijk]

On Sat, Jun 17, 2006 at 01:15:58PM -0400, Mike Frysinger wrote:
> On Saturday 17 June 2006 06:17, Luca Barbato wrote:
> > Long term solution:
> > 1- check your new package for aliasing compliance, and if you have time
> > fix it in the code or in the makefile, if you haven't append
> > -fno-strict-aliasing to the cflags and maybe send a notice about it
> > upstream
> >
> > 2- append -fno-strict-aliasing to every source known to have such issue.
> 
> 3 - include checking in portage
> http://bugs.gentoo.org/111436

Would this make builds fail by default, or would it provide a hook for
the user to allow builds to fail if specific conditions are matched ?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] using specific gcc-version in ebuild

[George Shapovalov]

Hi Sven

п'ятниця, 16. червень 2006 21:10, Sven Köhler Ви написали:
> i just wanted to ask, if the is an eclass or something else, that
> enables me to temporarly select a certain gcc-version? or perhaps just
> finding the path to the gcc and g++ executables of a specific
> gcc-versions (like gcc-3.*)?
Please take a look at gnat.eclass (you will need to check eselect-gnat too 
and, possibly, gnatbuild.eclass as well). These do not do anything about gcc 
or any system-wide changes at all, but do something resembling with gnat, as 
far as its libs are concerned.

However please note, it is better to avoid this unless you absolutely must. In 
your case it is porbably best (at present state of portage) to just check for 
the active version of gcc in pkg_setup and abort if it is not the one you 
need. You definitely cannot run gcc-config from within scr_* funcs and it is 
better not tu switch gcc behind user's back, even though you technically can 
in pkg_* (but as portage people do not expect you to do so, it may start 
failing in weird ways in the future)..

George

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] June Council meeting summary + log

[Mike Frysinger]

- GLEP49/GLEP50/Alternate package managers:
both GLEP49 and GLEP50 are inappropriate solutions.  the new proto-tree idea 
spawned by spb on the gentoo-dev mailing list looks like the correct path to 
move forward, so he will be doing the footwork and ironing out the details 
with the portage team.

- sunrise status:
one of the basic ideas of sunrise (opening up the dev process to newcomers) is 
wholeheartedly supported by the council.  however, the current implementation 
details are found to be lacking and the community concern is much too great 
to ignore.  so the project will stay suspended indefinitely until all such 
concerns can be fully addressed.

unadulterated log of the meeting will be synced out to the servers in a bit:
http://www.gentoo.org/proj/en/council/meeting-logs/20060616.txt
-mike


pgpCBrsKIwEcd.pgp
Description: PGP signature

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Mike Frysinger]

On Saturday 17 June 2006 13:20, Mike Frysinger wrote:
> some more docs:
> http://gcc.gnu.org/bugs.html#nonbugs_c
> Casting does not work as expected when optimization is turned on

and a follow up link:
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
-mike


pgppux3cNbTNQ.pgp
Description: PGP signature

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Mike Frysinger]

On Saturday 17 June 2006 13:28, Harald van Dijk wrote:
> On Sat, Jun 17, 2006 at 01:15:58PM -0400, Mike Frysinger wrote:
> > On Saturday 17 June 2006 06:17, Luca Barbato wrote:
> > > Long term solution:
> > > 1- check your new package for aliasing compliance, and if you have time
> > > fix it in the code or in the makefile, if you haven't append
> > > -fno-strict-aliasing to the cflags and maybe send a notice about it
> > > upstream
> > >
> > > 2- append -fno-strict-aliasing to every source known to have such
> > > issue.
> >
> > 3 - include checking in portage
> > http://bugs.gentoo.org/111436
>
> Would this make builds fail by default, or would it provide a hook for
> the user to allow builds to fail if specific conditions are matched ?

right now such behavior is not defined

i would lean on the FEATURES=stricter setting though to control warn/die 
behavior
-mike


pgpGnq6iQNh2w.pgp
Description: PGP signature

[gentoo-dev] Scientific Gentoo reorg

[George Shapovalov]

This seems to have never made it to the list, resending..

Hi everybody.

Sorry for crossposting, but many people whom I want to catch with this are not 
on gentoo-science. For the same reason lets keep this initial discussion 
here, on -dev. If we need to expand, lets take it to the gentoo-science, but 
then I would expect everybody interested to sign up ;).

Gentoo Science has been relatively quiet, even though we are making a steady 
progress on many fronts, but lately a few things has caught my attention and 
I think we can do better if create a bit more structure.

At present we count 10 categories containing 309 packages (wow! Considering 
that it all started with some 20 packages I put in sci back when we did not 
have a two-tier categories yet, quite impressive :)). However looking at 
herds.xml I see only 10 devs listed, which just cannot be true (considering, 
according to my experience with bugzilla, that majority of these packages are 
actually maintained). The real situation is that many devs are quietly 
supporting their own packages but are reluctant to join the sci team 
officially. And it is this situation that I want to address.

I see one reasonable rationale for this relctance to join: people are 
afraid "to get too much on theirs hands" by signing up. In reality the 
gentoo-science mailing list is really low on traffic (quite a relief in 
present times ;)), but nonetheless the sheer amount of packages may be 
frightening. Therefore I am proposing to recognize the fact that we 
(Scientific Gentoo project) became big and act accordingly:

1. We need more herds. The easiest possibility is to simply split them 
accordingly to categories. However, with 10 categories, this may be an 
overkill, or, with some categories having >50 packages an underkill, or 
simply may not correspond to maintenance reality (it will definitely fail on 
sci-libs for example). It is hard to tell without seing who does what, so I 
am going to ask for some feedback here (see below).

2. Should we create some subprojects? This really will have to be discussed in 
more detail when people respond and join corresponding teams I guess. 
However, while at it we may as well become a top-level project of our own. 
Right now Scientific Gentoo is under Dektop, which is at the very least 
strange (but all the other options back then were even less fitting..)

3. Mail aliases. Right now we have [EMAIL PROTECTED], which we should keep as 
an all 
encompassing alias for announcements or, well, I am not sure yet what else, 
but time will tell. In addition we should create new ones, one per herd. If 
by chance there are people interested in seeing *all* the bugs (which I 
somehow doubt, but theoretically?), we can reuse [EMAIL PROTECTED] for that as 
well..

So, right now I would like to ask for the feedback on the following:

Q1) I would like to hear about the reasons why people are afraid to join the 
sci team. You may respond to me personally or raise it on the list, but 
please let me/us know about the problems in any case, so that we may address 
them!

Q2) Please let me know if you are supporting or occasionally touching some 
package under sci-* and, assuming we create more herds, which herd it should 
belong to (just make it up as you see fit right now) and whether you would be 
willing to add yourself to the alias of that herd or join some subteam if we 
create one. I will collect the responces and then compile a proposal for the 
new structure.

Q3) Not relevant to this restructuring, but always usefull: if you know of 
some package that you think should really go under sci-something, please let 
us know!

And to finish it all up :)
Q4) If you are a user but would like to be involved more actively, or you have 
to run that particular package for your work but it sits in bugzilla for ages 
and no developer seems sensible enough to take it up, please let us know too. 
Best of all - subscribe to that gentoo-scie mailing list and ask somebody to 
mentor you. By the time it will be over we should have a new structure, so 
you won't end up with the whole 300+ sci packages on your hands (this was 
holding some people with whom I discussed it too).

This should be enough to start with, so, bring it on! :)

George
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Harald van Dijk]

On Sat, Jun 17, 2006 at 01:44:34PM -0400, Mike Frysinger wrote:
> On Saturday 17 June 2006 13:28, Harald van Dijk wrote:
> > On Sat, Jun 17, 2006 at 01:15:58PM -0400, Mike Frysinger wrote:
> > > On Saturday 17 June 2006 06:17, Luca Barbato wrote:
> > > > Long term solution:
> > > > 1- check your new package for aliasing compliance, and if you have time
> > > > fix it in the code or in the makefile, if you haven't append
> > > > -fno-strict-aliasing to the cflags and maybe send a notice about it
> > > > upstream
> > > >
> > > > 2- append -fno-strict-aliasing to every source known to have such
> > > > issue.
> > >
> > > 3 - include checking in portage
> > > http://bugs.gentoo.org/111436
> >
> > Would this make builds fail by default, or would it provide a hook for
> > the user to allow builds to fail if specific conditions are matched ?
> 
> right now such behavior is not defined
> 
> i would lean on the FEATURES=stricter setting though to control warn/die 
> behavior

One reason I asked was because you'd have to force LC_ALL=C to make that
work, unless you want to check for every translation of the warning.

Another, as said earlier already, is that the warning is given for valid
code too sometimes, but as long as it's possible to state in the ebuild
that the warnings are safe to ignore for that package, I guess that's
okay.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: using specific gcc-version in ebuild

[Sven Köhler]

> I've been thinking about this recently.  What qemu does is compile a C
> implementation of the target processor's instruction set into an object
> file when qemu is built, then at run-time (JIT time) it cut-n-pastes
> bits of that object file when it "compiles" the target executable into
> native code that can be executed directly in the emulator.  This is
> pretty cool, as it means you have a cross-platform target emulator that
> is fast because it leverages the compiler to write the emulation code,
> without having to maintain separate implementations for each target.
> 
> However it does rely on the ability to snip the function
> prologue/epilogue reliably so you can stitch stuff together (in
> particular the return instruction is eliminated), and with gcc-4 this is
> no longer possible because the return is not always and only at the end
> of the function. I think the change to gcc that causes this is one of
> the reasons the major revision number was increased.
> 
> The reason for describing this is to illustrate that qemu is not
> "broken" as such; it just relies on implementation detail of the pre-4
> gcc series.  Since gcc-4 doesn't provide any option to force code
> generation to fit the requirements of qemu, the compilation of the
> affected code must use gcc-3 (which it does with a very specific set
> of CFLAGS). Note; the majority of qemu can be compiled with gcc-4 just
> fine, however the target implementation objects have to be built with
> gcc-3 because gcc-4 does not provide an option to get the old gcc-3
> behaviour.

You take the words out of my mouth. That is exactly, what i'm after.

Actually i know, that there are aware of problems that may be caused by
using different compilers for different parts of software. But for qemu,
this is possibly a must.

While gentoo-ebuilds will still complain and force people to switch gcc
by hand, other distros may simply offer a qemu built with a different
gcc-version than the system-wide one.

> Since we already have slotted gcc working just fine, it seems
> reasonable to me that we could support packages requiring the existence
> of more than one compiler version (although I'm not sure portage
> DEPENDs will cope - I'm guessing:
> 
> DEPEND=" >=sys-devel/gcc-4"
> 
> won't be interpreted to mean both a pre-4 and a post-4 compiler are
> required).

I think, this does what you don't expect it to do.

I remember a bug, where a maintainer wanted to depend on a package, but
only a certain version-interval. He used exactly something like you
wrote it above. In the end, two versions of the package were installed,
and some people agreed on the necessity for a syntax for a
version-interval. (which is still not in portage 2.1 afaik)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] using specific gcc-version in ebuild

[Mike Frysinger]

On Friday 16 June 2006 20:10, Kevin F. Quinn wrote:
> The reason for describing this is to illustrate that qemu is not
> "broken" as such; it just relies on implementation detail of the pre-4
> gcc series.

then it's broken by design ... sure the idea about how qemu goes about its 
emulation is pretty goddamn cool, but gcc has never said that you can rely on 
certain behavior
-mike


pgpm7mEj14C7x.pgp
Description: PGP signature

[gentoo-dev] Re: June Council meeting summary + log

[Ryan Hill]

Mike Frysinger wrote:

> unadulterated log of the meeting will be synced out to the servers in a bit:
> http://www.gentoo.org/proj/en/council/meeting-logs/20060616.txt

I got http://www.gentoo.org/proj/en/council/meeting-logs/20060615.txt
Also the council project page links to 20060620.txt (?).

--de.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: using specific gcc-version in ebuild

[Sven Köhler]

> then it's broken by design ... sure the idea about how qemu goes about its 
> emulation is pretty goddamn cool, but gcc has never said that you can rely on 
> certain behavior

very right!

but you cannot change the world :-(



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sunrise: way forward, semi-official, review

[Henrik Brix Andersen]

On Sat, Jun 17, 2006 at 05:31:19PM +0200, foser wrote:
> It doesn't become an official Gentoo project by being run by 'official'
> Gentoo developers. There is no such thing as 'semi-official' and as such
> the move away from the gentoo domain indicates it has nothing to do with
> Gentoo and makes this part of the several third-party Gentoo ebuild
> sites around. Good luck with that, but don't try to put a Gentoo
> stamp-of-approval on it.

I agree with foser on this. You are of course free to run Project
Sunrise on non *.gentoo.org - this is what I have suggested all along
- but this also means that the project is not official.

Meanwhile, we've had an interesting brain-storm in #gentoo-userrel on
freenode IRC about other ways to improve the user-developer
relations. Stay tuned for more information.

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpkGveipuMkh.pgp
Description: PGP signature

Re: [gentoo-dev] Re: June Council meeting summary + log

[Mike Frysinger]

On Saturday 17 June 2006 16:26, Ryan Hill wrote:
> Mike Frysinger wrote:
> > unadulterated log of the meeting will be synced out to the servers in a
> > bit: http://www.gentoo.org/proj/en/council/meeting-logs/20060616.txt
>
> I got http://www.gentoo.org/proj/en/council/meeting-logs/20060615.txt
> Also the council project page links to 20060620.txt (?).

i clearly suck at dates

everything should refer to 20060615 now, thanks
-mike


pgpxryupGyH7b.pgp
Description: PGP signature

Re: [gentoo-dev] strict-aliasing rules, don't break them

[pvdabeel]

On Sat, Jun 17, 2006 at 03:35:10PM +0200, Harald van D??k wrote:
> On Sat, Jun 17, 2006 at 03:32:36PM +0200, Kevin F. Quinn wrote:
> > Easiest way to find these is to stick -Wall in global CFLAGS (or just
> > -Wstrict-aliasing if you want to be more specific), and grep the build
> > log for 'will break strict aliasing' (LC_ALL=C obviously).

http://dev.gentoo.org/~pvdabeel/strict-aliasing.log

It seems that roughly 10% of the ebuilds tested with strict-aliasing
in cflags warn about type punned pointers breaking strict aliasing
rules. A few ebuilds did not make it through testing with strict
aliasing, but did with -fno-strict-aliasing. Those should be obvious 
candidates for appending the fno-strict-aliasing flag (or an
attempt at fixing the violation by patching the code).

> That warning is given for valid code too. Please only add
> -fno-strict-aliasing if you actually find a package misbehaves without
> it, or if you have verified that there is indeed an aliasing violation
> in the code.

Right now we have -fno-strict-aliasing in the default cflags and are
considering auditing the tree for aliasing violations.

Pieter Van den Abeele

> -- 
> gentoo-dev@gentoo.org mailing list
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] baselayout-1.11.15-r3 testing for stable

[Mike Frysinger]

hrm ... i sent this like a week ago, but seems it never got through ...

can people give 1.11.15-r3 a run through ?

as always, 1.11.x is a bugfix version only (for the most part :D)
-mike


pgpCHKfpV0WRF.pgp
Description: PGP signature

Re: [gentoo-dev] Re: June Council meeting summary + log

[Lance Albertson]

Mike Frysinger wrote:

> i clearly suck at dates

That's what Jeff said after your date with him. Said goats were better
than you! :-)

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] variable quoting, setting optional variables to "", and depending on virtual/libc

[Peper]

> | If you inherit some eclass with deps, not set RDEPEND won't be
> | defaulted to DEPEND from ebuild, but will also include deps from
> | eclass, which is incorrect b/c these deps are needed for build time
> | only(like sed, autotools...). One needs to make sure that RDEPEND is
> | correct if not set manually in ebuild with eclasses.
>
> Incorrect.
What's incorrect? Made some tests and that's how it seems to work for me. If i 
am wrong be more specific plz.

-- 
Best Regards,
Peper
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] strict-aliasing rules, don't break them

[Diego 'Flameeyes' Pettenò]

So, just for people to know..

On Saturday 17 June 2006 15:32, Kevin F. Quinn wrote:
> kde-base/kdm-3.5.1
Fixed in latest ~arch (and upstream)

> media-libs/faad2-2.0-r11
Fixed in latest ~arch

> media-libs/xine-lib-1.1.2_pre20060328-r9
Fixed in latest ~arch (and upstream)

> media-video/vlc-0.8.5-r1
Testing in progress, will be fixed for tomorrow.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgphvpIH3hhk2.pgp
Description: PGP signature

Re: [gentoo-dev] Herds suck, fix them

[Christel Dahlskjaer]

On Sat, 2006-06-17 at 14:00 +, Ferris McCormick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sat, 17 Jun 2006, Carsten Lohrke wrote:
> 
> > On Saturday 17 June 2006 04:51, Christel Dahlskjaer wrote:
> >> How exactly does one go about maintaining our developers? ;)
> >
> > It's devrel's cursed job. Ask them. :)
> >
> >
> > Carsten
> >
> 
> Um, whips and chains.  But we're nice about it. :)

*grin* That's more what I was hoping for ;)


signature.asc
Description: This is a digitally signed message part