Hello,
As some of you may have noticed, lately introduced 'double include
preventions' have caused changes in effective phase functions in a few
ebuilds. Also, often it is undesirable that change in inherits of
an eclass may cause an undesired change of exported functions. To solve
these problems,
On 14.08.2012 00:24, Diego Elio Pettenò wrote:
On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
"/usr/lib// is a directory like /usr/libexec/ or even /bin. It
shares absolutely zero things with the arch-specific $libdir ,or lib64/.
Yes I know that FHS allows it. I still think it would be clean
On 14.08.2012 03:24, Olivier Crête wrote:
On Mon, 2012-08-13 at 17:56 -0400, Mike Gilbert wrote:
On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
wrote:
On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote:
Beside the fact that these would probably have looked better in
/usr/libex
On Mon, Aug 13, 2012 at 11:24 PM, Greg KH wrote:
> On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote:
>> On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés wrote:
>> >
>> > I agree with Greg Kroah-Hartman: I actually like (and want) a
>> > "vertically integrated, tightly coupled way o
I've stumbled onto an interesting little problem trying to build my
64->32 cross-prefix, which I bootstrapped with a no-multilib 32-bit
crossdev toolchain.
Please see https://bugs.gentoo.org/show_bug.cgi?id=430722, especially
the final two posts.
I'd appreciate input on the correctness/feasi
On 14/08/2012 02:57, Samuli Suominen wrote:
> I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/
> on "daily basis"
So instead of discussing this you just decide you don't like the path
and go with your preference?
Honestly I would have preferred for this to go through counci
On Tue, 14 Aug 2012 12:57:13 +0300
Samuli Suominen wrote:
> On 14.08.2012 00:24, Diego Elio Pettenò wrote:
> > On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
> >> "/usr/lib// is a directory like /usr/libexec/ or
> >> even /bin. It shares absolutely zero things with the arch-specific
> >> $libdi
On 14.08.2012 16:35, Diego Elio Pettenò wrote:
On 14/08/2012 02:57, Samuli Suominen wrote:
I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/
on "daily basis"
So instead of discussing this you just decide you don't like the path
and go with your preference?
Honestly I wou
On 13.08.2012 19:55, Samuli Suominen wrote:
[ ... ]
I should mention that we have discussed this already,
https://bugs.gentoo.org/show_bug.cgi?id=364375
Which was a result of long gentoo-dev ML thread, unfortunately my search
foo failed and I couldn't find straight link to it
Why should we t
On 14.08.2012 17:05, Michał Górny wrote:
On Tue, 14 Aug 2012 12:57:13 +0300
Samuli Suominen wrote:
On 14.08.2012 00:24, Diego Elio Pettenò wrote:
On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
"/usr/lib// is a directory like /usr/libexec/ or
even /bin. It shares absolutely zero things with
On 14.08.2012 17:05, Michał Górny wrote:
On Tue, 14 Aug 2012 12:57:13 +0300
Samuli Suominen wrote:
On 14.08.2012 00:24, Diego Elio Pettenò wrote:
On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
"/usr/lib// is a directory like /usr/libexec/ or
even /bin. It shares absolutely zero things with
On 14.08.2012 19:57, Samuli Suominen wrote:
On 14.08.2012 16:35, Diego Elio Pettenò wrote:
On 14/08/2012 02:57, Samuli Suominen wrote:
I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/
on "daily basis"
So instead of discussing this you just decide you don't like the path
On 14/08/2012 09:57, Samuli Suominen wrote:
>
> Sorry I was vague in that statement, I meant moving to both /usr/lib/
> when suitable (and usually the default from upstream lately) and
> /usr/lib64/xfce* (Location of .so Xfce plugins)
> Xfce had compability code for finding plugins from /usr/libex
Bug 345351 (ready patch and active user intrested in proxy maintainership)
And there is one more, search bugzie for lomoco
(Would do it myself but seriously got no time.)
On Tue, 14 Aug 2012 20:03:50 +0300
Samuli Suominen wrote:
> On 13.08.2012 19:55, Samuli Suominen wrote:
> [ ... ]
>
> I should mention that we have discussed this already,
>
> https://bugs.gentoo.org/show_bug.cgi?id=364375
>
> Which was a result of long gentoo-dev ML thread, unfortunately my
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
# Aaron W. Swenson (14 Aug 2012)
# Obsolete. Superseded by dev-db/pgpool2. Removal 14 Sep 2012.
# (Bug #431414)
dev-db/pgpool
- --
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email: titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E3
On Tue, Aug 14, 2012 at 5:31 AM, Rich Freeman wrote:
> On Mon, Aug 13, 2012 at 11:24 PM, Greg KH wrote:
>> On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote:
>>> On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés
>>> wrote:
>>> >
>>> > I agree with Greg Kroah-Hartman: I actually lik
Canek Peláez Valdés wrote:
> You can get as much vertical integration with Gentoo as with any other
> distro. The problem (and I think this is the point Greg is trying to
> make) is that it will be harder (not impossible, just harder) if most
> of Gentoo developers really believe that every single
On 08/14/2012 09:14 PM, Peter Stuge wrote:
> But it means nothing for someone who wants to open a box, switch on
> the power, and go online to $socialmediasite or $emailprovider.
Sabayon does a decent job for them.
lu
On 08/14/2012 02:44 AM, Michał Górny wrote:
> Hello,
>
> As some of you may have noticed, lately introduced 'double include
> preventions' have caused changes in effective phase functions in a few
> ebuilds.
Can't that be avoided by putting the EXPORT_FUNCTIONS call outside of
the ifndef block? T
On Tue, 14 Aug 2012 12:46:30 -0700
Zac Medico wrote:
> On 08/14/2012 02:44 AM, Michał Górny wrote:
> > Hello,
> >
> > As some of you may have noticed, lately introduced 'double include
> > preventions' have caused changes in effective phase functions in a
> > few ebuilds.
>
> Can't that be avoi
On Tue, 14 Aug 2012 11:44:49 +0200
Michał Górny wrote:
> As some of you may have noticed, lately introduced 'double include
> preventions' have caused changes in effective phase functions in a few
> ebuilds. Also, often it is undesirable that change in inherits of
> an eclass may cause an undesire
On Tue, 14 Aug 2012 21:45:56 +0100
Ciaran McCreesh wrote:
> On Tue, 14 Aug 2012 11:44:49 +0200
> Michał Górny wrote:
> > As some of you may have noticed, lately introduced 'double include
> > preventions' have caused changes in effective phase functions in a
> > few ebuilds. Also, often it is un
On Tue, 14 Aug 2012 22:54:13 +0200
Michał Górny wrote:
> On Tue, 14 Aug 2012 21:45:56 +0100
> Ciaran McCreesh wrote:
> > On Tue, 14 Aug 2012 11:44:49 +0200
> > Michał Górny wrote:
> > > As some of you may have noticed, lately introduced 'double include
> > > preventions' have caused changes in e
On 08/14/2012 10:56 PM, Ciaran McCreesh wrote:
>
> We can't change inherit behaviour in EAPI 5 anyway since it's a
> global scope function, so I was planning to ignore it and hope that
> by the time EAPI 6 comes along, people will have learned not to
> write huge eclasses that do more than one thi
On 08/14/2012 01:54 PM, Michał Górny wrote:
> On Tue, 14 Aug 2012 21:45:56 +0100
> Ciaran McCreesh wrote:
>
>> On Tue, 14 Aug 2012 11:44:49 +0200
>> Michał Górny wrote:
>>> As some of you may have noticed, lately introduced 'double include
>>> preventions' have caused changes in effective phase
On Tue, 14 Aug 2012 21:56:38 +0100
Ciaran McCreesh wrote:
> On Tue, 14 Aug 2012 22:54:13 +0200
> Michał Górny wrote:
> > On Tue, 14 Aug 2012 21:45:56 +0100
> > Ciaran McCreesh wrote:
> > > On Tue, 14 Aug 2012 11:44:49 +0200
> > > Michał Górny wrote:
> > > > As some of you may have noticed, lat
On Tue, 14 Aug 2012 23:09:55 +0200
Michał Górny wrote:
> > We can't change inherit behaviour in EAPI 5 anyway since it's a
> > global scope function, so I was planning to ignore it and hope that
> > by the time EAPI 6 comes along, people will have learned not to
> > write huge eclasses that do mor
On Tue, 14 Aug 2012 23:01:05 +0200
hasufell wrote:
> On 08/14/2012 10:56 PM, Ciaran McCreesh wrote:
> >
> > We can't change inherit behaviour in EAPI 5 anyway since it's a
> > global scope function, so I was planning to ignore it and hope that
> > by the time EAPI 6 comes along, people will have
On Tue, 14 Aug 2012 14:09:17 -0700
Zac Medico wrote:
> On 08/14/2012 01:54 PM, Michał Górny wrote:
> > On Tue, 14 Aug 2012 21:45:56 +0100
> > Ciaran McCreesh wrote:
> >
> >> On Tue, 14 Aug 2012 11:44:49 +0200
> >> Michał Górny wrote:
> >>> As some of you may have noticed, lately introduced 'do
On Tue, 14 Aug 2012 23:51:17 +0200
Michał Górny wrote:
> But you're aware that this 'reasonable approach' just made the whole
> problem by changing exported functions, right?
No, what made the whole problem is awful eclasses that do far too many
things.
--
Ciaran McCreesh
signature.asc
Descri
On 08/14/2012 02:51 PM, Michał Górny wrote:
> On Tue, 14 Aug 2012 14:09:17 -0700
> Zac Medico wrote:
>
>> On 08/14/2012 01:54 PM, Michał Górny wrote:
>>> On Tue, 14 Aug 2012 21:45:56 +0100
>>> Ciaran McCreesh wrote:
>>>
On Tue, 14 Aug 2012 11:44:49 +0200
Michał Górny wrote:
> As s
32 matches
Mail list logo
