On 05-10-2010 03:55, Diego Elio Pettenò wrote:
> Il giorno lun, 04/10/2010 alle 11.19 -0400, Richard Freeman ha scritto:
>>
>> That said, supporting this use case should not interfere with more
>> mainstream use of the distro. I like the USE flag proposal because it
>> lets us have our cake and ea
Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto:
>
> Like Richard said "Gentoo is about choice...
>
> By removing .la files, you are taking away that choice from the user.
> For you they might be useless, for some user (or entire software
> house)
> it can be its holly grai
On 05-10-2010 12:03, Diego Elio Pettenò wrote:
> Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto:
>>
>> Like Richard said "Gentoo is about choice...
>>
>> By removing .la files, you are taking away that choice from the user.
>> For you they might be useless, for some user (or
Il giorno mar, 05/10/2010 alle 13.04 +0200, Angelo Arrifano ha scritto:
> There are a lot of packages that need this information to correctly link
> against libtool managed libraries, for example, there are packages that
> linked against GL but didn't set -lGL -lGLU because it was relying on
> libt
Il giorno mar, 05/10/2010 alle 13.25 +0200, Diego Elio Pettenò ha
scritto:
> Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
> and mesa did not use libtool for linking until very recently,
Actually, scratch that, mesa IS NOT USING LIBTOOL AT ALL.
So you hit the jackpot: yo
I was just looking at some random ebuilds recently, and noticed this
snippet in gcc-4.5* ebuilds:
SSP_STABLE="amd64 x86 ppc ppc64 arm
# uclibc need tls and nptl support for SSP support"
SSP_UCLIBC_STABLE=""
Please note how the #-starting comment is inside the SSP_STABLE variable
declaration. It l
On 10/05/2010 02:04 PM, Angelo Arrifano wrote:
> You can extract from a .la things like the library name, version and
> linking information (lib dependencies and paths). The information is
> there and nothing prevented anyone from using it.
>>
>> Can you provide any specific use case, or are you no
On 10/5/10 9:52 AM, Angelo Arrifano wrote:
By removing .la files, you are taking away that choice from the user.
For you they might be useless, for some user (or entire software house)
it can be its holly grail for library versioning and linking. I don't
really feel like forcing users to change
On 05-10-2010 13:28, Diego Elio Pettenò wrote:
> Il giorno mar, 05/10/2010 alle 13.25 +0200, Diego Elio Pettenò ha
> scritto:
>> Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
>> and mesa did not use libtool for linking until very recently,
>
> Actually, scratch that, mesa
Il giorno sab, 02/10/2010 alle 01.35 +, Robin H. Johnson ha scritto:
>
> Which is a date of 2010/10/02, that just rolled up a few hours ago.
> A constant value that was set >5 years ago come up :-).
>
> All LDAP and the script are fixed now.
fl...@yamato rar % cvs up
Connection closed by 81
On 05-10-2010 13:49, Luca Barbato wrote:
> On 10/5/10 9:52 AM, Angelo Arrifano wrote:
>
>> By removing .la files, you are taking away that choice from the user.
>> For you they might be useless, for some user (or entire software house)
>> it can be its holly grail for library versioning and linkin
$ euse --info system-sqlite
global use flags (searching: system-sqlite)
no matching entries found
local use flags (searching: system-sqlite)
[-] system-sqlite (mail-client/
On 15:52 Tue 05 Oct , "Paweł Hajdan, Jr." wrote:
> The meaning is identical in all those cases, and I think the number of
> packages may have hit the threshold for a global flag.
>
> However, we already have a very similar global USE flag: sqlite, which
> makes this a bit more tricky. The di
On Tue, Oct 5, 2010 at 7:41 PM, Donnie Berkholz wrote:
> On 15:52 Tue 05 Oct , "Paweł Hajdan, Jr." wrote:
>> The meaning is identical in all those cases, and I think the number of
>> packages may have hit the threshold for a global flag.
>>
>> However, we already have a very similar global USE
On Tue, 05 Oct 2010 13:49:43 +0200
Luca Barbato wrote:
> Bluntly put, you seem to not know how libtool exactly works and
> further down in the thread how linking exactly works. Please try to
> learn the fine Gentoo docs on the subject and feel free to ask more
> details on irc.
Ah, so you do know
On 10/05/2010 02:32 PM, "Paweł Hajdan, Jr." wrote:
> I was just looking at some random ebuilds recently, and noticed this
> snippet in gcc-4.5* ebuilds:
>
> SSP_STABLE="amd64 x86 ppc ppc64 arm
> # uclibc need tls and nptl support for SSP support"
> SSP_UCLIBC_STABLE=""
>
> Please note how the #-s
On Tuesday 05 October 2010 18.52.29 Petteri Räty wrote:
> On 10/05/2010 02:32 PM, "Paweł Hajdan, Jr." wrote:
> > I was just looking at some random ebuilds recently, and noticed this
> > snippet in gcc-4.5* ebuilds:
> >
> > SSP_STABLE="amd64 x86 ppc ppc64 arm
> > # uclibc need tls and nptl support
On 5 October 2010 02:55, Diego Elio Pettenò wrote:
> USE flags add complexity, and in real use cases there are near to no
> good reasons at all to keep .la files around.
That's why I initially suggested a variable rather than a USE flag, as
if it was implemented in a centralised function it would
Hello,
I'm attaching the latest scons-utils.eclass once again, and announcing
the last call for criticism. If there are no further complaints, I will
proceed with committing.
--
Best regards,
Michał Górny
scons-utils.eclass
Description: Binary data
signature.asc
Description: PGP signature
On Mon, Oct 04, 2010 at 09:45:32PM +0200, Sebastian Pipping wrote:
> Hey there,
>
>
> like etc-update and dispatch-conf _conf-update_ seems to be one of the
> more central tools in Gentoo.
>
> I have the impression that it is unmaintained because...
> - metadata.xml says maintainer-needed, and
>
On 10/5/10 4:33 PM, Ciaran McCreesh wrote:
On Tue, 05 Oct 2010 13:49:43 +0200
Luca Barbato wrote:
Bluntly put, you seem to not know how libtool exactly works and
further down in the thread how linking exactly works. Please try to
learn the fine Gentoo docs on the subject and feel free to ask mo
On Tue, 05 Oct 2010 21:59:41 +0200
Luca Barbato wrote:
> > Great! It should be easy for you to fix it to only specify direct
> > link dependencies then, thus solving the underlying problem in one
> > place rather than working around it by fixing thousands of
> > individual packages.
>
> Sadly tha
> "RHJ" == Robin H Johnson writes:
RHJ> Some more issues for you:
RHJ> 1. Increases the size of the Manifest by a minimum of 710 bytes _per_
RHJ>file. (4 bytes for 'GPG ', 700-900 for the hash, 1 for the field space,
5-12 bytes for the
RHJ>trailer).
RHJ> 1.1. 55907 Manifest2 entries
* Diego Elio Pettenò schrieb:
> http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points
ACK.
IMHO, removing the .la files should be under invididual ebuild
(or eclass) control, and we also should try to get it fixed
at the source (if possible).
> Also, I would like to
On 5 October 2010 23:38, Enrico Weigelt wrote:
> And for Distros, it doesnt make sense to try to support anything imaginable.
Not breaking things that already work would be a decent compromise.
> I'm now working in embedded area (where static linking is quite common)
> for about 10yrs, and pkg-c
On Tue, Oct 05, 2010 at 05:53:50PM -0400, James Cloos wrote:
> > "RHJ" == Robin H Johnson writes:
>
> RHJ> Some more issues for you:
> RHJ> 1. Increases the size of the Manifest by a minimum of 710 bytes _per_
> RHJ>file. (4 bytes for 'GPG ', 700-900 for the hash, 1 for the field
> space
On 10/05/2010 05:26 PM, Robin H. Johnson wrote:
> On Tue, Oct 05, 2010 at 05:53:50PM -0400, James Cloos wrote:
>> Have portage note in the ebuild log what was signed, by what key, and
>> whether the sigs were true.
> zmedico: can we include this in the repoman commit sig?
Sure. Currently, repoman
On Tuesday, October 05, 2010 10:35:57 Nirbheek Chauhan wrote:
> To fix this problem sqlite upstream made a specific change allowing a
> #pragma to be used to define where secure-delete is required, avoiding
> the need to use secure-delete *everywhere*.
so what you're saying is that this USE flag c
On Wed, Oct 6, 2010 at 7:36 AM, Mike Frysinger wrote:
> On Tuesday, October 05, 2010 10:35:57 Nirbheek Chauhan wrote:
>> To fix this problem sqlite upstream made a specific change allowing a
>> #pragma to be used to define where secure-delete is required, avoiding
>> the need to use secure-delete
We'll be unmasking GCC 4.5 soon. I was planning on this weekend but next
weekend is more likely. If you have open bugs on the tracker, please take a
look at them now.
https://bugs.gentoo.org/showdependencytree.cgi?id=296658&hide_resolved=1
Thanks.
--
fonts, gcc-porting, we hold ou
On Tue, 05 Oct 2010 15:52:42 +0200
"Paweł Hajdan, Jr." wrote:
> The meaning is identical in all those cases, and I think the number of
> packages may have hit the threshold for a global flag.
>
> <...>
>
> If we'd make system-sqlite a global USE flag, I'd suggest a description
> like "Use the sy
On Tuesday, October 05, 2010 23:04:32 Nirbheek Chauhan wrote:
> On Wed, Oct 6, 2010 at 7:36 AM, Mike Frysinger wrote:
> > On Tuesday, October 05, 2010 10:35:57 Nirbheek Chauhan wrote:
> >> To fix this problem sqlite upstream made a specific change allowing a
> >> #pragma to be used to define where
32 matches
Mail list logo
