[gentoo-dev] Re: Fwd: Heads up for Qt5
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?
Re: [gentoo-dev] Re: Fwd: Heads up for Qt5
On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com 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 ) or: qt4? ( x11-libs/qt-gui:4 ) qt5? ( x11-libs/qt-gui:5 ) Other thoughts? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: Fwd: Heads up for Qt5
On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot yng...@gentoo.org wrote: On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com 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 ) 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. Thanks, Pesa
[gentoo-dev] Re: Fwd: Heads up for Qt5
On 28/07/12 09:46, Davide Pesavento wrote: On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot yng...@gentoo.org wrote: On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com 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.
Re: [gentoo-dev] Re: Fwd: Heads up for Qt5
On Fri, Jul 27, 2012 at 11:56 PM, Nikos Chantziaras rea...@gmail.com wrote: On 28/07/12 09:46, Davide Pesavento wrote: On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot yng...@gentoo.org wrote: On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com 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
Re: [gentoo-dev] Re: Fwd: Heads up for Qt5
On Sat, 28 Jul 2012 14:27:49 +0800 Ben de Groot yng...@gentoo.org wrote: On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com 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
On 28 July 2012 15:43, Ralph Sennhauser s...@gentoo.org wrote: On Sat, 28 Jul 2012 14:27:49 +0800 Ben de Groot yng...@gentoo.org wrote: On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com 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
On Sat, 28 Jul 2012 15:54:07 +0800 Ben de Groot yng...@gentoo.org 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.
[gentoo-dev] Re: Fwd: Heads up for Qt5
On 28/07/12 12:27, Ralph Sennhauser wrote: On Sat, 28 Jul 2012 15:54:07 +0800 Ben de Groot yng...@gentoo.org 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.
[gentoo-dev] Re: Fwd: Heads up for Qt5
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 yng...@gentoo.org 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
Re: [gentoo-dev] Re: RFC: virtual/libudev
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)
Re: [gentoo-dev] Fraunhofer FDK license
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] Fraunhofer FDK license
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] http://archives.gentoo.org/gentoo-dev/msg_6c950b46c50fe72ebc5e650bbf70f77c.xml
[gentoo-dev] Re: RFC: virtual/libudev
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] Re: RFC: virtual/libudev
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
