Róbert Čerňanský posted on Tue, 20 Jan 2015 06:51:01 +0100 as excerpted:
> On Mon, 19 Jan 2015 20:51:31 + Ciaran McCreesh
> wrote:
>
>> On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský
>> wrote:
>> > From my point of view it would do much help if portage resolves USE
>> > dependencies au
Andrew Savchenko posted on Tue, 20 Jan 2015 23:59:23 +0300 as excerpted:
> On Tue, 20 Jan 2015 12:17:35 -0800 Christopher Head wrote:
>> On January 20, 2015 12:47:03 AM PST, Alexis Ballier
>> wrote:
>> >So, you're telling me that if you have a list of 90 cpu extensions,
>> >you will from time to
On Tue, Jan 20, 2015 at 2:17 PM, Christopher Head wrote:
> On January 20, 2015 12:47:03 AM PST, Alexis Ballier
> wrote:
> >So, you're telling me that if you have a list of 90 cpu extensions, you
> >will from time to time open that list to see if there is a 91st one
> >added ? I think most people
On 17/01/15 18:43, Anthony G. Basile wrote:
Hi everyone,
It looks like there aren't too many bugs against gcc-4.9 (bug #495124).
There are a couple having to do with lto and one which is hardened
specific, but its probably a good idea to start keywording on the
various arches so we can get more
Michał Górny posted on Tue, 20 Jan 2015 10:40:17 +0100 as excerpted:
> Display-If-Keyword: amd64 ~amd64 x86 ~x86
>
> The USE flags corresponding to intruction sets and other features
> specific to the x86 architecture are being moved into a separate USE
> flag group called CPU_FLAGS_X86.
So base
Dnia 2015-01-20, o godz. 09:13:19
Alexis Ballier napisał(a):
> > For this reason, I would like to employ the solution used by Exherbo.
> > More specifically, use:
> >
> > libav? ( media-libs/libav:= )
> > !libav? ( media-libs/ffmpeg:= )
> >
> > This has two advantages:
> >
> > 1. gives use
On Tue, 20 Jan 2015 12:17:35 -0800 Christopher Head wrote:
> On January 20, 2015 12:47:03 AM PST, Alexis Ballier
> wrote:
> >So, you're telling me that if you have a list of 90 cpu extensions, you
> >will from time to time open that list to see if there is a 91st one
> >added ? I think most peopl
On Sun, 18 Jan 2015, Patrick Lauer wrote:
On Saturday 17 January 2015 14:00:34 William Hubbs wrote:
On Sat, Jan 17, 2015 at 01:44:21PM +0100, Dirkjan Ochtman wrote:
On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer
wrote:
* Stage3 archives are too fat
See https://bugs.gentoo.org/show_bug
On January 20, 2015 12:47:03 AM PST, Alexis Ballier wrote:
>So, you're telling me that if you have a list of 90 cpu extensions, you
>will from time to time open that list to see if there is a 91st one
>added ? I think most people won't even notice, at best they'll look for
>the changelog.
No, act
On 01/20/2015 12:15 PM, Ciaran McCreesh wrote:
> On Tue, 20 Jan 2015 12:12:32 -0800
> Zac Medico wrote:
Regardless of whether or not (or how) we choose to apply
REQUIRED_USE to various cases, I think we should keep REQUIRED_USE
around, since having a machine-readable representation
On Tue, 20 Jan 2015 12:12:32 -0800
Zac Medico wrote:
> >> Regardless of whether or not (or how) we choose to apply
> >> REQUIRED_USE to various cases, I think we should keep REQUIRED_USE
> >> around, since having a machine-readable representation of these
> >> constraints can potentially be extrem
On 01/20/2015 12:05 PM, Ciaran McCreesh wrote:
> On Tue, 20 Jan 2015 12:02:38 -0800
> Zac Medico wrote:
>> On 01/20/2015 09:25 AM, Ciaran McCreesh wrote:
>>> On Tue, 20 Jan 2015 13:41:21 +0100
>>> Ulrich Mueller wrote:
Seriously? You expect users to figure out [1] what combinations of
U
On Tue, 20 Jan 2015 12:02:38 -0800
Zac Medico wrote:
> On 01/20/2015 09:25 AM, Ciaran McCreesh wrote:
> > On Tue, 20 Jan 2015 13:41:21 +0100
> > Ulrich Mueller wrote:
> >> Seriously? You expect users to figure out [1] what combinations of
> >> USE flags will work for such an ebuild?
> >
> > Why
On 01/20/2015 09:25 AM, Ciaran McCreesh wrote:
> On Tue, 20 Jan 2015 13:41:21 +0100
> Ulrich Mueller wrote:
>> Seriously? You expect users to figure out [1] what combinations of
>> USE flags will work for such an ebuild?
>
> Why don't we just admit that Brian was horribly wrong, scrap
> REQUIRED_
On 01/20/2015 10:20 AM, Alexis Ballier wrote:
> On Tue, 20 Jan 2015 09:28:21 -0800
> Zac Medico wrote:
>
>> On 01/20/2015 01:11 AM, Alexis Ballier wrote:
>>> I think we can only make the safest assumption. Even without
>>> subslot, if you consider this: || ( a b c d ), with a and c
>>> installed
On Tue, 20 Jan 2015 09:28:21 -0800
Zac Medico wrote:
> On 01/20/2015 01:11 AM, Alexis Ballier wrote:
> > On Tue, 20 Jan 2015 01:01:41 -0800
> > Zac Medico wrote:
> >
> >> On 01/20/2015 12:13 AM, Alexis Ballier wrote:
> >>> On Mon, 19 Jan 2015 20:31:45 +0100
> >>> Michał Górny wrote:
> 2.
On 01/20/2015 01:11 AM, Alexis Ballier wrote:
> On Tue, 20 Jan 2015 01:01:41 -0800
> Zac Medico wrote:
>
>> On 01/20/2015 12:13 AM, Alexis Ballier wrote:
>>> On Mon, 19 Jan 2015 20:31:45 +0100
>>> Michał Górny wrote:
2. Subslots work correctly. Rebuilds are forced when the chosen
libra
On Tue, 20 Jan 2015 13:41:21 +0100
Ulrich Mueller wrote:
> Seriously? You expect users to figure out [1] what combinations of
> USE flags will work for such an ebuild?
Why don't we just admit that Brian was horribly wrong, scrap
REQUIRED_USE in the next EAPI, and go back to the sensible,
tried-an
On Tue, 20 Jan 2015 09:13:19 +0100
Alexis Ballier wrote:
> More precisely: || ( a:= b c:= d ) is perfectly defined (in
> the "what it means" sense, not in PMS sense).
It really isn't... || ( a b c ) only "works" currently if a, b and c can
be switched at runtime. If you're using it for anything e
On Tue, 20 Jan 2015 12:01:13 +0100
Luca Barbato wrote:
> On 17/01/15 16:03, Ciaran McCreesh wrote:
> > On Sat, 17 Jan 2015 22:59:08 +0800
> > Patrick Lauer wrote:
> >>> The problem isn't the constants, though. The problem is the
> >>> resolution algorithm. There's not much point tweaking performa
On 01/20/2015 05:31 AM, Luca Barbato wrote:
>>
>> This triggered a repressed memory of a bug once filed against me:
>>
>> https://blog.flameeyes.eu/2009/01/tinderboxing-problems-missing-default-use-flags
>>
>> I vaguely agree, but please address any hate mail to Diego.
>>
>>
>
> Why?
>
It was a
On 01/20/2015 07:46 AM, Andreas K. Huettel wrote:
> Am Dienstag 20 Januar 2015, 08:57:43 schrieb Michał Górny:
>> So a package supporting both providers has:
>>
>> IUSE="ffmpeg libav"
>> RDEPEND="
>> ffmpeg? ( media-video/ffmpeg:= )
>> libav? ( media-video/libav:= [media-libs/libpo
Am Dienstag 20 Januar 2015, 08:57:43 schrieb Michał Górny:
>
> So a package supporting both providers has:
>
> IUSE="ffmpeg libav"
> RDEPEND="
> ffmpeg? ( media-video/ffmpeg:= )
> libav? ( media-video/libav:= [media-libs/libpostproc:=] )"
> REQUIRED_USE="^^ ( ffmpeg libav )"
>
> On Tue, 20 Jan 2015, Michał Górny wrote:
> REQUIRED_USE="
> avcodec? ( ^^ ( ffmpeg libav ) )
> postproc? ( ^^ ( ffmpeg libav ) )
> ffmpeg? ( || ( avcodec postproc ) )
> libav? ( || ( avcodec postproc ) )"
Seriously? You expect users to figure out [1] what combinati
On 19/01/15 16:47, hasufell wrote:
I think you forgot an important point:
* lack of practical QA: no review workflow and no appropriate tools for
reviewing
I could start a long text block about why reviewing is mandatory for QA,
but let's just think about it this way:
What do you think would ha
On 17/01/15 16:03, Ciaran McCreesh wrote:
On Sat, 17 Jan 2015 22:59:08 +0800
Patrick Lauer wrote:
The problem isn't the constants, though. The problem is the
resolution algorithm. There's not much point tweaking performance
until the resolver is fixed to produce a correct answer...
Patches we
El mar, 20-01-2015 a las 11:21 +0100, Hanno Böck escribió:
[...]
> maintainer-wanted or if they're likely broken anyway just removed.
s/-wanted/-needed/ :)
On Tue, 20 Jan 2015 11:08:19 +0300
Andrew Savchenko wrote:
> On Tue, 20 Jan 2015 07:46:32 +0100 Róbert Čerňanský wrote:
> > On Tue, 20 Jan 2015 00:14:29 +0300
> > Andrew Savchenko wrote:
> > > On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský wrote:
> > > > From my point of view it would do mu
On 20/01/15 03:07, Michael Orlitzky wrote:
On 01/19/2015 05:44 PM, Pacho Ramos wrote:
I agree with your suggestion but I would prefer the Remi's approach of
letting people to know if they want "ffmpeg" or "libav", otherwise it is
not so obvious to know what disabling/enabling one of that USE fl
Hi,
I'm listed on a number of packages as the maintainer that I don't
really care about any more.
Please if you want to take any of them add yourself as maintainer and
remove me. What's left will be re-assigned to herds if they exist,
maintainer-wanted or if they're likely broken anyway just remov
Due to mduft retirement the following packages are up for grabs now:
app-emulation/rex-client
net-proxy/cntlm
Thanks
Dnia 2015-01-18, o godz. 21:44:05
Michał Górny napisał(a):
> Hello,
>
> I would like to commit the following flags as cpu_flags_x86_desc.
> The list combines global USE flags with some local USE flags I've been
> able to find.
Following your suggestions, I'm attaching three files:
1. updated c
On Tue, 20 Jan 2015 01:01:41 -0800
Zac Medico wrote:
> On 01/20/2015 12:13 AM, Alexis Ballier wrote:
> > On Mon, 19 Jan 2015 20:31:45 +0100
> > Michał Górny wrote:
> >> 2. Subslots work correctly. Rebuilds are forced when the chosen
> >> library is upgraded. Moreover, USE flag change causes a re
On 01/20/2015 12:13 AM, Alexis Ballier wrote:
> On Mon, 19 Jan 2015 20:31:45 +0100
> Michał Górny wrote:
>> 2. Subslots work correctly. Rebuilds are forced when the chosen
>> library is upgraded. Moreover, USE flag change causes a rebuild when
>> user decides to change the ffmpeg provider.
>
>
>
On Tue, 20 Jan 2015 09:52:40 +0100
Michał Górny wrote:
> Dnia 2015-01-19, o godz. 11:38:26
> Alexis Ballier napisał(a):
>
> > On Sun, 18 Jan 2015 21:44:05 +0100
> > Michał Górny wrote:
> >
> > > Hello,
> > >
> > > I would like to commit the following flags as cpu_flags_x86_desc.
> > > The li
Dnia 2015-01-19, o godz. 11:38:26
Alexis Ballier napisał(a):
> On Sun, 18 Jan 2015 21:44:05 +0100
> Michał Górny wrote:
>
> > Hello,
> >
> > I would like to commit the following flags as cpu_flags_x86_desc.
> > The list combines global USE flags with some local USE flags I've been
> > able to
On Tue, 20 Jan 2015 00:29:22 -0800
Christopher Head wrote:
> On Tue, 20 Jan 2015 09:21:54 +0100
> Alexis Ballier wrote:
>
> > you will not see it if no package use it.
>
> I guess you mean I wouldn’t see it in emerge output if no package uses
> it, even if it is USE-expanded? Yes, I’m aware of
On Tue, 20 Jan 2015 09:21:54 +0100
Alexis Ballier wrote:
> you will not see it if no package use it.
I guess you mean I wouldn’t see it in emerge output if no package uses
it, even if it is USE-expanded? Yes, I’m aware of that. But if all the
flags are listed together in one place (I forget what
On Mon, 19 Jan 2015 23:43:19 -0800
Christopher Head wrote:
> On Wed, 14 Jan 2015 11:01:16 -0800
> Zac Medico wrote:
>
> > Why should we have to foresee the future? We can easily add support
> > for new flags in CPU_FLAGS_* variables at any time.
>
> Ah, what I meant was that whoever maintains
On Tue, 20 Jan 2015 08:57:43 +0100
Michał Górny wrote:
> Hi,
>
> Since you didn't like the previous hacky idea, here's a new one.
>
> The basic flags correspond to features and are used if the relevant
> support is optional:
>
> avcodec - Enables audio/video decoding support via libavcodec
>
On Mon, 19 Jan 2015 20:31:45 +0100
Michał Górny wrote:
> Hello,
>
> As we've discussed multiple times, the following kind of dependencies
> is completely broken and can't work:
>
> || ( media-libs/libav:= media-libs/ffmpeg:= )
See end of the email.
> For this reason, I would like to employ
On Tue, 20 Jan 2015 06:51:01 +0100 Róbert Čerňanský wrote:
> On Mon, 19 Jan 2015 20:51:31 +
> Ciaran McCreesh wrote:
>
> > On Mon, 19 Jan 2015 21:44:25 +0100
> > Róbert Čerňanský wrote:
> > > From my point of view it would do much help if portage resolves USE
> > > dependencies automatically
On Tue, 20 Jan 2015 07:46:32 +0100 Róbert Čerňanský wrote:
> On Tue, 20 Jan 2015 00:14:29 +0300
> Andrew Savchenko wrote:
>
> > On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský wrote:
> > > From my point of view it would do much help if portage resolves USE
> > > dependencies automatically ins
43 matches
Mail list logo
