Re: [gentoo-dev] Re: RFC: virtual/libudev

[Peter Stuge]

Duncan wrote:
> the responsibility of whatever organization to either follow 
> thru or repudiate, as it's the reputation and credibility of
> that organization on the line if they don't.

I think it's unreasonable to expect any third party to accept
responsibility for a receiver which is over-trusting a sender.

Receivers must be intelligent and diligent to not be fooled by
ignorant or outright malicious senders.

See also
http://en.wikipedia.org/wiki/The_War_of_the_Worlds_(radio_drama)

Society chose to make radio senders responsible by law. It's why
there are jingles. As with any free speech medium, that is not so
easy to enforce on the internet.

Just like you don't want to over-trust the guy on the corner dressed
up as a person of authority trying to disseminate whatever racist
propaganda you don't want to believe everything on the internet.

More than anything, please consider that what you have been told may
simply be a lie, and be prepared to rewind and re-evaluate the world
if you learn that this is the case. You may look like a fool for
believing someone who was telling a lie, but you'll look like a hero
for admitting that it happened and that you've learned something new.


//Peter

[gentoo-dev] Re: RFC: virtual/libudev

[Duncan]

Roy Bamford posted on Sat, 28 Jul 2012 17:51:47 +0100 as excerpted:

> You don't want to listen to Presidents too much.  Look at other real
> life examples.
> 
> Would you claim that the President of the Gentoo Foundation speaks for
> Gentoo?

If he were making claims of that nature, yes, barring information to the 
contrary, I'd assume he had authority/authorization to do so, and would 
definitely hold gentoo to a responsibility to either follow thru or 
remove him for cause for making such claims without authorization to do 
so (or at very minimum, to publicly repudiate the claims if they didn't 
intend to follow thru).  If none of that happened, I'd blame gentoo even 
more than the spokesperson that made the claim, without public 
repudiation.

You're right, they're PR people and as such, their claims must 
(unfortunately)  be taken with a grain of salt.  But that doesn't 
eliminate the responsibility of whatever organization to either follow 
thru or repudiate, as it's the reputation and credibility of that 
organization on the line if they don't.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Fraunhofer FDK license

[Ulrich Mueller]

> On Sat, 28 Jul 2012, Luca Barbato wrote:

> On 07/26/2012 12:45 PM, Andreas K. Huettel wrote:
>> Indeed, and this opens another can of worms since (as far as I can see) 
>> there 
>> are no specific license clauses in the AAC patent license for applications 
>> that may be distributed without cost. I.e., licensing fees still apply as 
>> "per 
>> unit fee".

> Tell me where I should categorize it =)

I believe that I can go to BINARY-REDISTRIBUTABLE. But please check if
the following rules apply here:

# - MAY require explicit inclusion of the license with
#   the distribution [1]
# - IFF there is an explicit inclusion requirement, USE=bindist
#   MUST cause a copy of the license to be installed in a file
#   location compliant with the license,

Ulrich

[1] 

Re: [gentoo-dev] Fraunhofer FDK license

[Luca Barbato]

On 07/26/2012 12:45 PM, Andreas K. Huettel wrote:
>>> On Thu, 26 Jul 2012, Luca Barbato wrote:
>>> I'd add it, it is a gpl incompatible opensource license.
>>
>> No problem to add it. But IMHO the usage restriction in section 3
>> makes it non-free:
>>
>> "You may use this FDK AAC Codec software or modifications thereto only
>> for purposes that are authorized by appropriate patent licenses."
>>
>> Ulrich
> 
> Indeed, and this opens another can of worms since (as far as I can see) there 
> are no specific license clauses in the AAC patent license for applications 
> that may be distributed without cost. I.e., licensing fees still apply as 
> "per 
> unit fee".

Tell me where I should categorize it =)

lu

PS: help in improving libav aac encoder by leveraging atouv would be
always welcome.

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Re: RFC: virtual/libudev

[Roy Bamford]

On 2012.07.27 03:37, Duncan wrote:
[snip]
> 
> Not that such promises hold much credibility anyway... see the kde 
> promise (from Aaron S when he was president of KDE e.v. so as 
> credible a  spokesperson as it gets) continued kde3 support as long 
> as there were 
> users.  (AFAIK, at least gnome didn't make /that/ sort of promise in
> the leadup to gnome3.  And no, AS cannot be properly argued to have 
> been 
> referring to others, like debian with its slow release cycles, as he
> was 
> president of kde ev, not president of debian, or of the trinity
> project, 
> which AFAIK didn't even exist at the time, and didn't specify support 
> from OTHERS, not kde, so he was clearly speaking for kde, not for
> other 
> entities.)
> 
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
> 
> 
Duncan,

You don't want to listen to Presidents too much.  Look at other real 
life examples.  

Would you claim that the President of the Gentoo Foundation speaks for 
Gentoo? 


-- 
Regards,

Roy Bamford
(Neddyseagoon)

Gentoo Foundation Inc. (President)

[gentoo-dev] Re: Fwd: Heads up for Qt5

[Duncan]

Nikos Chantziaras posted on Sat, 28 Jul 2012 13:07:08 +0300 as excerpted:

> On 28/07/12 12:27, Ralph Sennhauser wrote:
>> On Sat, 28 Jul 2012 15:54:07 +0800 Ben de Groot 
>> wrote:
>>
>>> We do not have (nor want to support) a qt useflag. We have opted for
>>> "qt4" and "qt5" useflags as the most straightforward and least
>>> confusing.
>>
>> Indeed, the flag qt has almost disappeared from the tree. Good to know.
> 
> Why the different policies between the gtk and qt USE flags?  This just
> looks inconsistent.

Different gentoo projects.  Different people involved with their own 
preferences.  But I believe it's mostly an accident of history.

The gtk/gtk2 evolution went rather poorly as IIRC there really wasn't an 
original defined policy, so the gtk USE flags were ambiguous.  At first 
USE=gtk2 was discouraged for a lot of packages, since for them it meant 
favoring the still (at the time) less stable gtk2 over gtk1.  USE=gtk 
meanwhile, sometimes meant favor gtk1, while at other times it meant let 
the package maintainer pick the best one to support.  Of course that 
caused problems later on, after gtk2 matured and gtk1 was being phased 
out, so a general policy was adopted, that AFAIK remains today: USE=gtk 
meant support gtk in any form, with USE=gtk1/gtk2 (and now gtk3, with 
gtk1 phased out) meant prefer that specific version instead of letting 
the package maintainer choose a default.

But the key point there is that said policy was kind of fallen into by 
accident, and once in place, it was simply more convenient to maintain 
it, then to change it yet again.

When the qt3/qt4 case came along, they had the lessons of the gtk case to 
examine and decided to avoid the problem by switching to specific-
versioned qtX flags I believe before/as qt4 hit the tree.  Of course the 
fact that the existing in-tree support was already qt3 helped, since that 
was already more intuitive than gtk1.  From quite early on, then, simple 
qt was never allowed the ambiguity of gtk -- it always meant qt3 but was 
quickly deprecated in favor of the qt3 flag.

Of course also helping things was the fact that the qt3 ecosystem was 
much more monolithic and kde3 much more dominant within it than was the 
case with either gtk1/gnome1 or the now somewhat broader-ecosystem qt4/
kde4.  So getting buy-in for the quick deprecation of qt in favor of qt3 
was much closer to simply getting by-in from the gentoo/kde folks (with a 
large overlap between them and the gentoo/qt folks), as opposed to the 
wider cooperation needed in the gtk case.

So to a large extent the fact that gtk means any gtk while the versioned 
ones mean prefer that version, while there's ONLY the versioned qtX 
flags, is an accident of history.  And since then, the respective gtk/qt 
policies have remained in place due to inertia -- yes there's an 
inconsistency between them, but users of each quickly get comfortable 
with it, and the cost-benefit ratio of trying to change either one now, 
simply hasn't been considered worth it.  Thus as new versions appear, 
gtk3 and now qt5, they simply follow type.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Fwd: Heads up for Qt5

[Nikos Chantziaras]

On 28/07/12 12:27, Ralph Sennhauser wrote:

On Sat, 28 Jul 2012 15:54:07 +0800
Ben de Groot  wrote:


We do not have (nor want to support) a qt useflag. We have opted
for "qt4" and "qt5" useflags as the most straightforward and least
confusing.


Indeed, the flag qt has almost disappeared from the tree. Good to know.


Why the different policies between the gtk and qt USE flags?  This just 
looks inconsistent.

Re: [gentoo-dev] Re: Fwd: Heads up for Qt5

[Ralph Sennhauser]

On Sat, 28 Jul 2012 15:54:07 +0800
Ben de Groot  wrote:

> We do not have (nor want to support) a qt useflag. We have opted
> for "qt4" and "qt5" useflags as the most straightforward and least
> confusing.

Indeed, the flag qt has almost disappeared from the tree. Good to know.

Re: [gentoo-dev] Re: Fwd: Heads up for Qt5

[Ben de Groot]

On 28 July 2012 15:43, Ralph Sennhauser  wrote:
> On Sat, 28 Jul 2012 14:27:49 +0800
> Ben de Groot  wrote:
>
>> On 28 July 2012 13:59, Nikos Chantziaras  wrote:
>> > On 28/07/12 08:22, Ben de Groot wrote:
>> >>
>> >> In preparation for that, we want to ask maintainers of all ebuilds
>> >> in the tree with dependencies on Qt4, to make sure that they have
>> >> the proper slot. Otherwise your package may pull in Qt5 while it
>> >> may not in fact support it.
>> >
>> >
>> > This can be trouble if the application actually works with Qt5.  It
>> > might depend on Qt4 but has no problems with Qt5 (contrary to Qt3
>> > vs Qt4, Qt5 is mostly compatible with much of existing Qt4 code),
>> > needlessly pulling-in Qt4.  Many applications simply build and run
>> > as-is and no code changes are necessary.
>> >
>> > So what would be the methodology of making sure a package has the
>> > proper slot?
>>
>> Obviously you would need to make sure that the package actually does
>> support Qt5. Then, as I see it, we could do either:
>>
>> || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )
>
> Never prefer an old version in an || ( ) block, this makes for a poor
> update experience. Also the || ( ) construct can only be used if they
> are runtime switchable, which I really doubt here, as otherwise you
> build against one, the user install the other and portage depcleans the
> one you have built against.

Yes, that was a brainfart. Davide already said it was wrong.

>>
>> or:
>>
>> qt4? ( x11-libs/qt-gui:4 )
>> qt5? ( x11-libs/qt-gui:5 )
>>
>
> A qt5 useflag will do more harm than good. If I enable qt, I do not
> care which version, I just want the gui for the particular app. If the
> app works with qt:5 the usflag qt means qt:5, if it only works with
> qt:4 the useflags means qt:4. In case it works with both and the
> maintainer thinks it's worth to let the user choose, use the useflag qt4
> to let the user opt out of the latest and greatest.

We do not have (nor want to support) a qt useflag. We have opted
for "qt4" and "qt5" useflags as the most straightforward and least
confusing.

It is up to package maintainers if they want to offer to build both
versions where applicable, or prefer one over the other if both
useflags are set.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] Re: Fwd: Heads up for Qt5

[Ralph Sennhauser]

On Sat, 28 Jul 2012 14:27:49 +0800
Ben de Groot  wrote:

> On 28 July 2012 13:59, Nikos Chantziaras  wrote:
> > On 28/07/12 08:22, Ben de Groot wrote:
> >>
> >> In preparation for that, we want to ask maintainers of all ebuilds
> >> in the tree with dependencies on Qt4, to make sure that they have
> >> the proper slot. Otherwise your package may pull in Qt5 while it
> >> may not in fact support it.
> >
> >
> > This can be trouble if the application actually works with Qt5.  It
> > might depend on Qt4 but has no problems with Qt5 (contrary to Qt3
> > vs Qt4, Qt5 is mostly compatible with much of existing Qt4 code),
> > needlessly pulling-in Qt4.  Many applications simply build and run
> > as-is and no code changes are necessary.
> >
> > So what would be the methodology of making sure a package has the
> > proper slot?
> 
> Obviously you would need to make sure that the package actually does
> support Qt5. Then, as I see it, we could do either:
> 
> || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )

Never prefer an old version in an || ( ) block, this makes for a poor
update experience. Also the || ( ) construct can only be used if they
are runtime switchable, which I really doubt here, as otherwise you
build against one, the user install the other and portage depcleans the
one you have built against.

> 
> or:
> 
> qt4? ( x11-libs/qt-gui:4 )
> qt5? ( x11-libs/qt-gui:5 )
> 

A qt5 useflag will do more harm than good. If I enable qt, I do not
care which version, I just want the gui for the particular app. If the
app works with qt:5 the usflag qt means qt:5, if it only works with
qt:4 the useflags means qt:4. In case it works with both and the
maintainer thinks it's worth to let the user choose, use the useflag qt4
to let the user opt out of the latest and greatest.

> Other thoughts?

Re: [gentoo-dev] Re: Fwd: Heads up for Qt5

[Davide Pesavento]

On Fri, Jul 27, 2012 at 11:56 PM, Nikos Chantziaras  wrote:
> On 28/07/12 09:46, Davide Pesavento wrote:
>>
>> On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot  wrote:
>>>
>>> On 28 July 2012 13:59, Nikos Chantziaras  wrote:

  [...]

 So what would be the methodology of making sure a package has the proper
 slot?
>>>
>>>
>>> Obviously you would need to make sure that the package actually does
>>> support Qt5. Then, as I see it, we could do either:
>>>
>>> || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )
>>>
>>
>> This is wrong because qt4 and qt5 are not binary compatible.
>>
>>> or:
>>>
>>> qt4? ( x11-libs/qt-gui:4 )
>>> qt5? ( x11-libs/qt-gui:5 )
>>>
>>
>> This is the only alternative AFAICS.
>
>
> In that case, if Qt5 is installed, the application might depend on Qt4, but
> when building it, might link against Qt5.
>
>

No, that would be a bug in the ebuild or somewhere else.

BTW, I'm planning to write a qt5-utils.eclass, which will provide an
eqmake5 function similar to eqmake4 in qt4-r2.eclass.

Cheers,
Pesa