If you have a binary package in the tree, I would appreciate it if you
could make it DEPEND on =virtual/libstdc++-3.3, or if you need some
other version, let me know. I'd love to drop the PDEPEND on this from
the GCC ebuilds, but I can't do that sanely until I know that nothing in
the tree is goin
On Thursday 09 March 2006 05:28, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 09 March 2006 04:12, Mike Frysinger wrote:
> > this is kind of a pita in terms of maintenance and imo a hack ... why not
> > just have the splitelf code skip stripped binaries
>
> Because of the number of `file` calls n
On Thu, 2006-03-09 at 11:28 +0100, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 09 March 2006 04:12, Mike Frysinger wrote:
> > this is kind of a pita in terms of maintenance and imo a hack ... why not
> > just have the splitelf code skip stripped binaries
> Because of the number of `file` calls n
On Thursday 09 March 2006 04:12, Mike Frysinger wrote:
> this is kind of a pita in terms of maintenance and imo a hack ... why not
> just have the splitelf code skip stripped binaries
Because of the number of `file` calls needed to identify stripped and
non-stripped binaries, I'd say...
--
Diego
On Wednesday 08 March 2006 21:42, Diego 'Flameeyes' Pettenò wrote:
> One alternative is to add nostrip to the restrict of those packages, so
> that prepallstrip is skipped and extra files are not created.
> That is what I've done with emul-x86-* packages and mplayer-bin, but I'm
> not 100% sure how
Okay, this is a bit anticipated by my blog post and by what I've been doing
tonight instead of sleeping :P
Basically I'm trying to get cleaned up what I have in /usr/lib/debug when
using splitdebug, getting rid of stuff that gets stripped there... mostly
it's because of errors in packages or in
On Wednesday 08 February 2006 19:24, Jason Stubbs wrote:
> On Thursday 09 February 2006 08:19, Mark Loeser wrote:
> > Anyone that is maintaining a binary package in the tree, and requires
> > libstdc++-v3, please put a rdepend in your package on
> > =virtual/libstdc++-3.3. I'd like to drop the dep
Jason Stubbs <[EMAIL PROTECTED]> said:
> On Thursday 09 February 2006 09:30, Mark Loeser wrote:
> > Jason Stubbs <[EMAIL PROTECTED]> said:
> > > It was my understanding that it is needed for the 3.3 -> 3.4 upgrade.
> > > Various packages that will build fine against either are broken until
> > > be
On Thursday 09 February 2006 09:30, Mark Loeser wrote:
> Jason Stubbs <[EMAIL PROTECTED]> said:
> > It was my understanding that it is needed for the 3.3 -> 3.4 upgrade.
> > Various packages that will build fine against either are broken until
> > being recompiled after the upgrade and there is cur
Jason Stubbs <[EMAIL PROTECTED]> said:
> It was my understanding that it is needed for the 3.3 -> 3.4 upgrade.
> Various packages that will build fine against either are broken until
> being recompiled after the upgrade and there is currently no way to
> express this with dependencies.
You need ei
On Thursday 09 February 2006 08:19, Mark Loeser wrote:
> Anyone that is maintaining a binary package in the tree, and requires
> libstdc++-v3, please put a rdepend in your package on
> =virtual/libstdc++-3.3. I'd like to drop the dependency from gcc-3.4 and
> higher so that we do not needlessly fo
Anyone that is maintaining a binary package in the tree, and requires
libstdc++-v3, please put a rdepend in your package on
=virtual/libstdc++-3.3. I'd like to drop the dependency from gcc-3.4 and
higher so that we do not needlessly force the libstdc++ package on people
that do not need it.
Thank
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Loeser skrev:
> Bjarke Istrup Pedersen <[EMAIL PROTECTED]> said:
>
>>Does this mean that gcc-3.4 will no longer have libstdc++ as a
>>dependency? :-D
>
>
> That is what I hope to accomplish, yes.
>
Okay, you got my vote for this then.
btw. I
Bjarke Istrup Pedersen <[EMAIL PROTECTED]> said:
> Does this mean that gcc-3.4 will no longer have libstdc++ as a
> dependency? :-D
That is what I hope to accomplish, yes.
--
Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86)
email - halcy0n AT gentoo DOT org
Mark Loeser skrev:
> Mark Loeser <[EMAIL PROTECTED]> said:
>
>>Mark Loeser <[EMAIL PROTECTED]> said:
>>
>>>So, everyone that has a binary package in the tree, I would appreciate it if
>>>you could put the sys-libs/libstdc++-v3 depend into your package if
>>>necessary.
>>
>>Well, you can tell I did
Mark Loeser <[EMAIL PROTECTED]> said:
> Mark Loeser <[EMAIL PROTECTED]> said:
> > So, everyone that has a binary package in the tree, I would appreciate it if
> > you could put the sys-libs/libstdc++-v3 depend into your package if
> > necessary.
>
> Well, you can tell I didn't exactly think about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Loeser wrote:
| Mark Loeser <[EMAIL PROTECTED]> said:
|
|>So, everyone that has a binary package in the tree, I would appreciate
it if
|>you could put the sys-libs/libstdc++-v3 depend into your package if
|>necessary.
|
|
| Well, you can tell I d
Mark Loeser wrote:
>Well, you can tell I didn't exactly think about this too much beforehand,
>since its been brought to my attention a virtual would probably be best for
>this, so we would handle the || ( gcc-3.3.* libstdc++ ) inside of the
>virtual. I'll make one later unless anyone has strong
Mark Loeser <[EMAIL PROTECTED]> said:
> So, everyone that has a binary package in the tree, I would appreciate it if
> you could put the sys-libs/libstdc++-v3 depend into your package if
> necessary.
Well, you can tell I didn't exactly think about this too much beforehand,
since its been brought t
Currently we are forcing people to either have gcc-3.3 installed, or
libstdc++-v3 so that old packages that weren't recompiled yet don't break,
and binary packages that need libstdc++.so.5 don't break horribly as well.
I'd like to see this dependency in the gcc ebuilds go away and all of the
binary
One of the common complaints with revdep-rebuild is that it wants to
constantly rebuild binary packages (most notably openoffice-bin). To
assist in resolving this issue, I have released gentoolkit-0.2.1_pre9
which adds the capability for an ebuild maintainer to adjust how
revdep-rebuild behaves tow
21 matches
Mail list logo
