On Wed, 20 Jun 2012 23:43:36 +0200
Justin wrote:
> On 20.06.2012 22:35, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400
> > Richard Yao wrote:
> >> Multilib (and/or multiarch) support
> >>The current binaries cause a great deal of pain,
> >> particularly when a user does not wan
El mié, 20-06-2012 a las 23:43 +0200, Justin escribió:
> On 20.06.2012 22:35, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400
> > Richard Yao wrote:
> >> Multilib (and/or multiarch) support
> >>The current binaries cause a great deal of pain, particularly
> >> when a user does no
On Wed, Jun 20, 2012 at 05:56:28PM -0400, Richard Yao wrote:
> On 06/20/2012 04:13 PM, Richard Yao wrote:
> >> Stop right there. That's just not going to happen, sorry. You aren't
> >> going to be able to get a user to replace their BIOS, nor should you
> >> ever want to. You are not going to be
Peter, thanks for the detailed email. I have a few questions.
1. As far as I know, Das U-Boot and Core Boot are mutually exclusive.
Why should Linux distribution developers want to use Core Boot instead
of Das U-Boot?
2. It seems to me that you do not need any Linux code. Exactly what is
the relat
On 06/20/2012 05:09 PM, Greg KH wrote:
>> Technical hurdles will likely prevent this unless we an get vendors to
>> release documentation. Is there any chance you could contact people at
>> Intel requesting programming documentation on their memory controller
>> and anything else we would need to w
On 20.06.2012 22:35, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:25:30 -0400
> Richard Yao wrote:
>> Multilib (and/or multiarch) support
>> The current binaries cause a great deal of pain, particularly
>> when a user does not want to upgrade something. I had this problem
>> with WINE and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2012 05:12 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 17:05:55 -0400 Richard Yao
> wrote:
The multilib-portage overlay already has this working.
>>>
>>> But there is no spec, nor is there a developer-centric
>>> description of i
On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao wrote:
> Here is my wishlist for EAPI 5:
>
> Multilib (and/or multiarch) support
> Automated epatch_user support
> Parallel make checks
> POSIX Shell compliance
>
> Here are some explanations:
>
> Multilib (and/or multiarch) support
> The curren
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Jun 2012 17:05:55 -0400
Richard Yao wrote:
> >> The multilib-portage overlay already has this working.
> >
> > But there is no spec, nor is there a developer-centric description
> > of it.
>
> I missed this tibbit. I am not sure what you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Jun 2012 17:02:10 -0400
Richard Yao wrote:
> >> Lets address POSIX compliance in the ebuilds first. Then we can
> >> deal with the package managers.
> >
> > Why? It's highly doubtful the package manglers could switch shells
> > even if the
On Wed, Jun 20, 2012 at 04:35:41PM -0400, Richard Yao wrote:
> On 06/20/2012 04:20 PM, Greg KH wrote:
> > On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
> >> On 06/20/2012 04:08 PM, Greg KH wrote:
> >>> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> I know that th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2012 04:54 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao
> wrote:
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
>>> wrote:
Multilib (and/or multiarch)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2012 04:54 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao
> wrote:
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
>>> wrote:
Multilib (and/or multiarch)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Jun 2012 16:50:33 -0400
Richard Yao wrote:
> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
> > wrote:
> >> Multilib (and/or multiarch) support The current binaries cause a
> >> great deal
On 06/20/2012 04:39 PM, Maxim Kammerer wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
>> Multilib (and/or multiarch) support
>
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?
It includes it n
On 06/20/2012 10:25 PM, Richard Yao wrote:
> Here is my wishlist for EAPI 5:
>
> Multilib (and/or multiarch) support
> Automated epatch_user support
> Parallel make checks
> POSIX Shell compliance
>
> Here are some explanations:
>
> Multilib (and/or multiarch) support
> The current binarie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
> wrote:
>> Multilib (and/or multiarch) support The current binaries cause a
>> great deal of pain, particularly when a user does not want to
>> upgrade so
On Wed, 20 Jun 2012 23:39:42 +0300
Maxim Kammerer wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
> > Multilib (and/or multiarch) support
>
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?
No
On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
> Multilib (and/or multiarch) support
Sorry for a possibly ignorant question. Does multilib support include
the ability to build Busybox against uclibc (on a glibc system)?
--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
On Wed, 20 Jun 2012 16:25:30 -0400
Richard Yao wrote:
> Multilib (and/or multiarch) support
> The current binaries cause a great deal of pain, particularly
> when a user does not want to upgrade something. I had this problem
> with WINE and glibc because I wanted to avoid the reverse memcpy(
On 06/20/2012 04:20 PM, Greg KH wrote:
> On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
>> On 06/20/2012 04:08 PM, Greg KH wrote:
>>> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
I know that there is a great deal of discussion on the effect that
UEFI Secure B
Here is my wishlist for EAPI 5:
Multilib (and/or multiarch) support
Automated epatch_user support
Parallel make checks
POSIX Shell compliance
Here are some explanations:
Multilib (and/or multiarch) support
The current binaries cause a great deal of pain, particularly when a
user does not
On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
> On 06/20/2012 04:08 PM, Greg KH wrote:
> > On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> >> I know that there is a great deal of discussion on the effect that
> >> UEFI Secure Boot will have on us. As far as I know, Sec
On 06/20/2012 04:08 PM, Greg KH wrote:
> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
>> I know that there is a great deal of discussion on the effect that
>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
>> implemented in the UEFI firmware and if we replace the
On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> I know that there is a great deal of discussion on the effect that
> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
> implemented in the UEFI firmware and if we replace the firmware,
> Secure Boot issues disappear.
On Wed, 20 Jun 2012 18:24:33 +0100
Ciaran McCreesh wrote:
> Can we all agree to just stop this and just restrict the arguing to
> being between SDEPEND and DEPENDENCIES? Cheers.
I clearly favour going with SDEPEND now as this fits better what people
are used to and the move to DEPENDENCIES is al
On Wed, 20 Jun 2012 19:11:33 +0200
hasufell wrote:
> On 06/20/2012 07:07 PM, Michał Górny wrote:
> > Please read the rationale. Again. The whole thing. Three times.
>
> Please read my suggestions. Again. The whole thing. Three times.
Can we all agree to just stop this and just restrict the argui
On 06/20/2012 07:07 PM, Michał Górny wrote:
> Please read the rationale. Again. The whole thing. Three times.
>
Please read my suggestions. Again. The whole thing. Three times.
On Wed, 20 Jun 2012 18:57:19 +0200
hasufell wrote:
> >> 2. Afais useflags that are already in IUSE and used for build-time
> >> stuff must not be used for IUSE_RUNTIME too.
> >> This is a random rule IMO. I don't have many cases in mind where
> >> this would be annoying (could think of "debug" en
On 06/20/2012 05:05 PM, Marien Zwart wrote:
> On di, 2012-06-19 at 18:53 +0200, hasufell wrote:
>>
>> 1. Optional deps are SUGGESTIONS from the dev which he considered
>> nice/good/sane at the time of writing the ebuild. Other people might
>> totally disagree with those suggestions.
>> As useflags
On Wed, 20 Jun 2012 18:45:31 +0200
Ulrich Mueller wrote:
> I'd say that EAPI 5 should provide an "apply_patches_here" function
> that can be called by ebuilds, but if the ebuild hasn't called the
> function, then it should fall back to applying user patches just after
> src_prepare.
But applying
> On Wed, 20 Jun 2012, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 17:44:36 +0200
> Ulrich Mueller wrote:
>> I disagree with this. As it is currently worded, every ebuild would
>> be required to call a special function in src_prepare. This is the
>> worst possible solution, IMHO.
> Every eb
On Wed, 20 Jun 2012 17:44:36 +0200
Ulrich Mueller wrote:
> > On Wed, 20 Jun 2012, Ciaran McCreesh wrote:
> > I believe we consider the user patches feature to be finalised,
> > [...]
>
> I disagree with this. As it is currently worded, every ebuild would be
> required would be required to cal
Meeting with bug: #409471 suggested that some ebuilds could benefit from
expanding -march=native to the actual flags the compiler use.
Cannot suggest where to use it at the moment, but implementation was
simple enough and possibly someone on this list could have a use for it.
# @FUNCTION: gcc-n
> On Wed, 20 Jun 2012, Ciaran McCreesh wrote:
> I believe we consider the user patches feature to be finalised, [...]
I disagree with this. As it is currently worded, every ebuild would be
required would be required to call a special function in src_prepare.
This is the worst possible solutio
On di, 2012-06-19 at 18:53 +0200, hasufell wrote:
> On 06/17/2012 10:31 PM, Michał Górny wrote:
> > Hello,
> >
> > A simple solution to a program long-unsolved. In GLEP form.
> >
> > Both attached and published as a gist:
> >
> > https://gist.github.com/2945569
> >
> > (please note that github
On Wed, 20 Jun 2012 13:22:22 +0200
Michał Górny wrote:
> > I believe we consider the user patches feature to be finalised, so
> > if you want something else, it should be treated as a new feature
> > rather than a change. But please don't rehash anything that's
> > already been covered.
>
> I sim
On Wed, 20 Jun 2012 12:14:38 +0100
Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 13:12:25 +0200
> Michał Górny wrote:
> > On Wed, 20 Jun 2012 12:02:42 +0100
> > Ciaran McCreesh wrote:
> > > Please don't. User patches were discussed on this list, and
> > > there's already wording written. We don'
On Wed, 20 Jun 2012 13:12:25 +0200
Michał Górny wrote:
> On Wed, 20 Jun 2012 12:02:42 +0100
> Ciaran McCreesh wrote:
> > Please don't. User patches were discussed on this list, and there's
> > already wording written. We don't need a bug to track it.
>
> So you want requests here or do I have do
On Wed, 20 Jun 2012 12:02:42 +0100
Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 11:07:55 +0200
> Michał Górny wrote:
> > Could someone open bugs for all of that? I was looking for user
> > patches on the future EAPI tracker, and I don't see it there.
>
> Please don't. User patches were discusse
On Wed, 20 Jun 2012 11:07:55 +0200
Michał Górny wrote:
> Could someone open bugs for all of that? I was looking for user
> patches on the future EAPI tracker, and I don't see it there.
Please don't. User patches were discussed on this list, and there's
already wording written. We don't need a bug
On Sat, 16 Jun 2012 14:12:13 +0200
Ulrich Mueller wrote:
> > On Sat, 16 Jun 2012, Pacho Ramos wrote:
>
> > I would like to know if there is some place where things going to be
> > included (or proposed to be included) for eapi5 are listed (if such
> > place exists). Currently, looks like the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/19/2012 08:14 PM, Thomas Sachau wrote:
>> and possibly split RDEPEND/DEPEND to have HDEPEND to list build
>> dependencies that need to be run on host.
>
> What should the difference between DEPEND and HDEPEND be?
Not library but program that h
43 matches
Mail list logo
