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
(ffmpeg/libav)
postproc - Enable image post-processing via libpostpr
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 this flag list only needs
to forsee the present—when AMD or Intel adds a ne
Dnia 2015-01-20, o godz. 08:36:56
Rémi Cardona napisał(a):
> Le 19/01/2015 23:40, Michał Górny a écrit :
> > 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
> > a lot of packages. If we changed the meaning, libav users will end up
> > switching '-ffmpeg libav' per-package.
Le 19/01/2015 23:40, Michał Górny a écrit :
> 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
> a lot of packages. If we changed the meaning, libav users will end up
> switching '-ffmpeg libav' per-package. Ugly.
>
> 2. Feature-oriented flags. USE=ffmpeg represents the gene
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 instead of telling the user to change USE
> > flags manually (I am talking
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 instead of telling the user to change USE
> > flags manually (I am talki
On Mon, Jan 19, 2015 at 08:31:45PM +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:= )
>
> For this reason, I would like to employ the solution use
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 flags
> will end up causing without read
On Mon, Jan 19, 2015 at 4:41 AM, Alexis Ballier wrote:
> On Sun, 18 Jan 2015 15:15:22 -0800
> Matt Turner wrote:
> > > mmx - Use the MMX instruction set
> > > mmxext - Use the Extended MMX instruction set (intersection of
> > > Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in
> > >
On Mon, Jan 19, 2015 at 4:40 PM, Michał Górny wrote:
> Dnia 2015-01-19, o godz. 23:09:55
> Rémi Cardona napisał(a):
>
> > Why not :
> >
> > libav? ( media-libs/libav:= )
> > ffmpeg? ( media-libs/ffmpeg:= )
> >
> > + REQUIRED_USE="^^ ( libav ffmpeg )"
> >
> > I for one would never expect USE=-lib
On Mon, Jan 19, 2015 at 5:32 PM, Jeroen Roovers wrote:
> On Mon, 19 Jan 2015 17:02:11 -0500
> Rich Freeman wrote:
>
>> You're complaining about how somebody made a fix that they wouldn't
>> have had to make but for the commit you made without consulting with
>> them.
>
> No, I didn't do that comm
El lun, 19-01-2015 a las 23:40 +0100, Michał Górny escribió:
> Dnia 2015-01-19, o godz. 23:09:55
> Rémi Cardona napisał(a):
>
> > Why not :
> >
> > libav? ( media-libs/libav:= )
> > ffmpeg? ( media-libs/ffmpeg:= )
> >
> > + REQUIRED_USE="^^ ( libav ffmpeg )"
> >
> > I for one would never expec
Dnia 2015-01-19, o godz. 23:09:55
Rémi Cardona napisał(a):
> Why not :
>
> libav? ( media-libs/libav:= )
> ffmpeg? ( media-libs/ffmpeg:= )
>
> + REQUIRED_USE="^^ ( libav ffmpeg )"
>
> I for one would never expect USE=-libav to enable ffmpeg (nor
> USE=-ffmpeg to enable libav FWIW).
Two reason
On Mon, 19 Jan 2015 17:02:11 -0500
Rich Freeman wrote:
> You're complaining about how somebody made a fix that they wouldn't
> have had to make but for the commit you made without consulting with
> them.
No, I didn't do that commit at all and only a little complaining. This
is between hasufell a
Why not :
libav? ( media-libs/libav:= )
ffmpeg? ( media-libs/ffmpeg:= )
+ REQUIRED_USE="^^ ( libav ffmpeg )"
I for one would never expect USE=-libav to enable ffmpeg (nor
USE=-ffmpeg to enable libav FWIW).
Rémi
On Mon, Jan 19, 2015 at 3:30 PM, Jeroen Roovers wrote:
> On Mon, 19 Jan 2015 10:21:15 -0500
> Rich Freeman wrote:
>
>> On Mon, Jan 19, 2015 at 4:40 AM, Jeroen Roovers
>> wrote:
>> >
>> > The only (QA) problem I see is the pointless removal of the ebuild
>> > in question and the subsequent additi
On 01/19/15 13:34, "Paweł Hajdan, Jr." wrote:
On 1/18/15 10:50 PM, Anthony G. Basile wrote:
Hi everyone, I'd like to make a commit to toolchain.eclass in a few
days. mgorny noticed some code which can be improved. Basically gcc
creates "fixed" include files from system headers because of the
r
On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský wrote:
> On Sat, 17 Jan 2015 18:33:45 +0300
> Andrew Savchenko wrote:
>
> > On Sat, 17 Jan 2015 14:45:51 + Ciaran McCreesh wrote:
> > > The problem isn't the constants, though. The problem is the
> > > resolution algorithm. There's not much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/19/2015 12:44 PM, Róbert Čerňanský wrote:
> On Sat, 17 Jan 2015 18:33:45 +0300 Andrew Savchenko
> wrote:
>
>> On Sat, 17 Jan 2015 14:45:51 + Ciaran McCreesh wrote:
>>> The problem isn't the constants, though. The problem is the
>>> resolut
On Mon, Jan 19, 2015 at 4:47 AM, Jeroen Roovers wrote:
>
> repoman doesn't check reverse dependencies for the package you're
> working on.
>
Indeed, it doesn't even check forward dependencies which are blockers.
kmod-19 was just stabilized accidentally despite having a blocker on
all stable versi
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 instead of telling the user to change USE
> flags manually (I am talking about bug #258371).
This is only possible in carefully selected ci
On Sat, 17 Jan 2015 18:33:45 +0300
Andrew Savchenko wrote:
> On Sat, 17 Jan 2015 14:45:51 + Ciaran McCreesh 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
On Mon, 19 Jan 2015 18:17:12 +0100
Arfrever Frehtes Taifersar Arahesis wrote:
> The broken libuv-1.2.1.ebuild was not disabling unwanted addition of
> -g to CFLAGS. The fix for this problem affected installed files, so
> revision bump was required.
Yes, and I was talking about ChangeLog entries
On Mon, 19 Jan 2015 10:21:15 -0500
Rich Freeman wrote:
> On Mon, Jan 19, 2015 at 4:40 AM, Jeroen Roovers
> wrote:
> >
> > The only (QA) problem I see is the pointless removal of the ebuild
> > in question and the subsequent addition of a pointless revision
> > bump with no clue as to why it was
On Sun, Jan 18, 2015 at 01:21:56PM +0100, Dirkjan Ochtman wrote:
> On Sat, Jan 17, 2015 at 9:00 PM, William Hubbs wrote:
> >> Why the heck do we ship both 3.3 and 3.4? I forget the exact situation
> >> with 2.x and 3.x, but I don't think setting PYTHON_TARGETS to 2.7-only
> >> is a great option if
> Any comments?
Sounds good!
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:= )
For this reason, I would like to employ the solution used by Exherbo.
More specifically, use:
libav? ( media-libs/libav:= )
!liba
On 2015-01-19 07:28, Patrick Lauer wrote:
> On 01/19/15 17:47, Jeroen Roovers wrote:
> > On Sat, 17 Jan 2015 19:35:09 +0800
> > Patrick Lauer wrote:
> >
> >> * AutoRepoman catches on average maybe 2 user-visible breakages.
> >> Mostly removing stable on HPPA ;)
> >> Fix: Make repoman fast
On 1/18/15 10:50 PM, Anthony G. Basile wrote:
> Hi everyone, I'd like to make a commit to toolchain.eclass in a few
> days. mgorny noticed some code which can be improved. Basically gcc
> creates "fixed" include files from system headers because of the
> requirement that it have ansi c compliant
On Mon, 19 Jan 2015 12:42:45 +0300
Sergey Popov wrote:
> 17.01.2015 18:51, Ciaran McCreesh пишет:
> > On Sat, 17 Jan 2015 19:49:24 +0400
> > Сергей wrote:
> >> Any random user can tell you: -u means UPDATE, -D means DEEP
> >> (follow dependencies).
> >
> > And what do those actually mean?
>
>
Hi all,
As I was the one wanting amd64-fbsd profiles 'stable' to ensure a sane
deptree, and seeing the number of (re)keywording bugs growing and
growing while I don't have time to process them and no-one else is doing
it, I just switched them to 'dev' state.
For users, this means they can no long
2015-01-19 10:40 Jeroen Roovers napisał(a):
> On Fri, 16 Jan 2015 15:26:55 +
> hasufell wrote:
>
> > Patrick Lauer (patrick):
> > > patrick 15/01/16 04:16:55
> > >
> > > Modified: ChangeLog
> > > Added:libuv-1.2.1.ebuild
> > > Log:
> > > Bump
> > >
Patrick Lauer:
> Here's a random unsorted list of things that it would make sense to be upset
> about. Some issues that people have successfully ignored for a few years ...
>
> In no way exhaustive list, feel free to remember a dozen things I forgot ;)
> (If you suggest other things please try to
Rich Freeman wrote:
> working out things 1:1 if possible
..
> it is probably better to let Comrel do their job, rather than
> having everybody bicker on the list.
Working out things 1:1 *on the list* is nice in that it adds transparency.
Of course, it is then also very easy for people to send unr
On Mon, Jan 19, 2015 at 4:40 AM, Jeroen Roovers wrote:
>
> The only (QA) problem I see is the pointless removal of the ebuild in
> question and the subsequent addition of a pointless revision bump with
> no clue as to why it was removed or why the revision bump was required:
>
You'd probably do w
On Mon, Jan 19, 2015 at 4:33 AM, Sergey Popov wrote:
>
> Do not get me wrong, Patrick. You, as QA team member, can touch other's
> packages without prior noticing, if fixing serious issues involved. But
> with great power comes great responsibility. Please, use your power more
> wisely next time.
On 01/19/15 17:47, Jeroen Roovers wrote:
> On Sat, 17 Jan 2015 19:35:09 +0800
> Patrick Lauer wrote:
>
>> * AutoRepoman catches on average maybe 2 user-visible breakages.
>> Mostly removing stable on HPPA ;)
>> Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours)
>> Fix: Remin
On Mon, 19 Jan 2015 08:13:46 +0800
Patrick Lauer wrote:
>
> So half of those are obsolete/dead, and the other half you need to do
> proper feature detection - why do we want that as useflags again?
>
http://article.gmane.org/gmane.linux.gentoo.devel/94299
On Sun, 18 Jan 2015 15:15:22 -0800
Matt Turner wrote:
> > mmx - Use the MMX instruction set
> > mmxext - Use the Extended MMX instruction set (intersection of
> > Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in
> > cpuinfo) padlock - Use VIA padlock instructions popcnt - Enable
> > p
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 find.
>
>
> 3dnow - Use the 3DNow! instruction set
> 3dnowext - Use the Enhan
On Sat, 17 Jan 2015 19:35:09 +0800
Patrick Lauer wrote:
> * AutoRepoman catches on average maybe 2 user-visible breakages.
> Mostly removing stable on HPPA ;)
> Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours)
> Fix: Remind people that using repoman is not optional
repoma
17.01.2015 18:51, Ciaran McCreesh пишет:
> On Sat, 17 Jan 2015 19:49:24 +0400
> Сергей wrote:
>> Any random user can tell you: -u means UPDATE, -D means DEEP (follow
>> dependencies).
>
> And what do those actually mean?
>
Do you need citation from 'man portage'? :-)
-D usually adds to deptre
On Fri, 16 Jan 2015 15:26:55 +
hasufell wrote:
> Patrick Lauer (patrick):
> > patrick 15/01/16 04:16:55
> >
> > Modified: ChangeLog
> > Added:libuv-1.2.1.ebuild
> > Log:
> > Bump
> >
>
> I expect people to ask me for review if they bump any of my p
17.01.2015 03:56, Patrick Lauer пишет:
> On Friday 16 January 2015 18:29:08 hasufell wrote:
>> Patrick Lauer:
>>> On 01/16/15 23:26, hasufell wrote:
Patrick Lauer (patrick):
> patrick 15/01/16 04:16:55
>
> Modified: ChangeLog
> Added:libuv-1.
On Mon, 19 Jan 2015 08:13:46 +0800 Patrick Lauer wrote:
> On Sunday 18 January 2015 21:44:05 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 find.
> >
>
45 matches
Mail list logo
