Re: [gentoo-dev] Non-free software in Gentoo
On 12/30/2009 11:48 PM, Greg KH wrote: Heh, no, it does not, unless your BIOS, and your keyboard firmware, and your mouse firmware are all under a free license. The only thing close to this type of machine is the OLPC, and even then, I don't think all the microcode for the box was ever released. So it's a pointless effort. Actually, you describe the futility of the effort, not the pointlessness of the effort. The fact that an effort is difficult or even futile does not make it pointless. Some might disagree about it being impossible as well (there are open-source BIOS implementations, for example). I'm sure the people who have such philosophies try to run free software anytime that it is possible. They might not be able to run free software on their microwave, but if one came out with an open-source firmware they'd probably try to buy it. I don't see this as being inconsistent, just practical. The fact that they can't buy an open-source toaster or mouse doesn't mean that they can't use an open-source kernel. Hint, these firmware blobs do not run on your processor, so they have nothing to do with the license of your system. I'm not really sure where you're coming up with this argument. The purpose of a license is to ALLOW you to do something you otherwise wouldn't be allowed to do. Licenses don't actually take away rights, they grant them. Laws do take away rights. There is a law that says that if I write a program and give it to you, you can't copy it and give it to somebody else. However, if I give you a license to copy the file under some conditions, then you can copy it legally if you follow those conditions. Nowhere in copyright law is the word processor found or implied - the technology used to copy is also irrelevant except to the degree that it impacts fair use. When you run software you aren't distributing it. The concept of a use-license is a bit blurry - some people think that you don't need a license to use software, and other people think you do. I don't believe that court rulings are as uniform on the topic of use as they are on the concept of copying. In any case, the GPL v2 does not in any way attempt to restrict or grant the rights to use software - only to distribute it. GPL v3 is a bit murkier in this regard, but irrelevant to a discussion on the kernel. Again, no, the GPLv2 covers the license of all of the code you run in the kernel package. The concern isn't about RUNNING the software - it is about DISTRIBUTING the software. And again, you do not run those firmware images on your processor, so the point is moot. Sure you do - you run them on your sound card processor, or your video capture card processor, or whatever. However, the concern isn't running the software, it is redistributing it. And note, _I_ placed those images in the kernel image, after consulting lawyers about this issue, so it's not like I don't know what I am talking about here. Did they say that the GPLv2 applied to the entire tarball containing the firmware? Or did they simply state that building/running kernels using the tarball was legal? Nobody is saying that the presence of the proprietary bits violates the GPL (v1, v2, OR v3). You're not doing anything illegal. However, the tarball is not licensed under the GPLv2. I can't modify that tarball at will, for example, and redistribute it. If I modify 10 bytes in the middle of one of those firmware blobs, reassemble the tarball, and post that on my website, I can be sued by the maker of that firmware blob. I haven't violated the GPL in doing any of that - the problem is that the firmware blob isn't licensed under the GPL. The license to redistribute the gentoo-sources tarball is NOT GPLv2 - it is GPLv2 for 98% of it, and a mix of other licenses for the rest. I don't own a keyspan usb serial device, but that doesn't mean I can modify the usa28.fw file and put it in a kernel tarball on my website, as the license for that file SPECIFICALLY states that I'm not allowed to do this and it is copyrighted. Doing this doesn't violate the GPL, but the GPL doesn't apply to this file. The point of this thread is that the gentoo-sources package is mislabeled as GPLv2 when the entire package is not licensed under GPL v2. Nobody is saying that it is illegal to distribute gentoo-sources, only that it cannot be entirely distributed solely under GPLv2.
Re: [gentoo-dev] Qt3 deprecation and removal policy
On 12/30/2009 12:14 PM, Ben de Groot wrote: 2010-01-21: * Qt team meeting: discuss actions to be taken regarding remaining pkgs that use qt:3 2010-02-21: * mask qt:3 and depending ebuilds, pending removal 30 days isn't a long time. How about filing bugs against anything that currently uses qt3 right away, so that maintainers have an extra three weeks to resolve these issues? Granted, one would hope they've been paying attention. As a random example, the current stable version of mythtv uses qt3, but I don't see any open bugs about that (that package is probably an easy fix as the newer versions use qt3support, and that version is already stable upstream). Usually the approach in these situations is to have a big tracker bug for qt3 removal and a million blocker bugs against individual packages. I'm not saying you can't move forward until everybody else gets their acts together, but tracking this in bugzilla probably isn't a bad move if it isn't too much work. Plus, you might decide that one or two of the blockers really are critical, and decide to work with those maintainers more closely or escalate the issue.
Re: [gentoo-dev] Qt3 deprecation and removal policy
On 12/31/2009 02:39 PM, Richard Freeman wrote: On 12/30/2009 12:14 PM, Ben de Groot wrote: 2010-01-21: * Qt team meeting: discuss actions to be taken regarding remaining pkgs that use qt:3 2010-02-21: * mask qt:3 and depending ebuilds, pending removal 30 days isn't a long time. How about filing bugs against anything that currently uses qt3 right away, so that maintainers have an extra three weeks to resolve these issues? Granted, one would hope they've been paying attention. As a random example, the current stable version of mythtv uses qt3, but I don't see any open bugs about that (that package is probably an easy fix as the newer versions use qt3support, and that version is already stable upstream). Stable MythTV has more issues than just Qt3, as the current stable doesn't compile anymore, http://bugs.gentoo.org/show_bug.cgi?id=280303 which is about to get masked tomorrow with kdelibs-3... Just saying...
[gentoo-dev] Re: Qt3 deprecation and removal policy
Hi, Samuli Suominen ssuomi...@gentoo.org: Just saying... Please track progress somehow. I know it is a lot of work, but makes understanding the process easier. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Qt3 deprecation and removal policy
On 12/31/2009 03:13 PM, Christian Faulhammer wrote: Hi, Samuli Suominen ssuomi...@gentoo.org: Just saying... Please track progress somehow. I know it is a lot of work, but makes understanding the process easier. V-Li It's been done in, http://bugs.gentoo.org/show_bug.cgi?id=292791 Overall here's the current status of kdelibs-3.5 reverse deps: Old KOffice 1.x (2.x is marked stable): app-i18n/koffice-i18n =app-office/karbon-1.6* =app-office/kchart-1.6* =app-office/kexi-1.6* =app-office/kformula-1.6* =app-office/kivio-1.6* =app-office/koffice-data-1.6* =app-office/koffice-libs-1.6* =app-office/koffice-meta-1.6* =app-office/koshell-1.6* =app-office/kplato-1.6* =app-office/kpresenter-1.6* =app-office/krita-1.6* =app-office/kspread-1.6* =app-office/kugar-1.6* =app-office/kword-1.6* Unused KDE 3.5.x deps, was only needed for KOffice 1.x: =kde-base/kcminit-3.5* =kde-base/kcontrol-3.5* =kde-base/kde-i18n-3.5* =kde-base/kdebase-data-3.5* =kde-base/kdelibs-3.5* =kde-base/kdepasswd-3.5* =kde-base/kdesu-3.5* =kde-base/kdialog-3.5* =kde-base/kdnssd-3.5* =kde-base/kghostview-3.5* =kde-base/khotkeys-3.5* =kde-base/kicker-3.5* =kde-base/kmenuedit-3.5* =kde-base/libkonq-3.5* kde-misc/kdnssd-avahi Broken MythTV: ~media-plugins/mythbrowser-0.21_p17105 And these are really shame to lose, but they are going in a collateral damage, many of which have other bugs open as well, ones like If Qt4 is installed, it doesn't compile as it's linking to wrong lib -style bugs games-arcade/kamikaze games-board/hearts games-board/six games-board/slibo games-emulation/kvisualboyadvance games-mud/xpertmud games-simulation/kfreeflight games-strategy/boson
Re: [gentoo-dev] Re: Qt3 deprecation and removal policy
On 12/31/2009 08:24 AM, Samuli Suominen wrote: On 12/31/2009 03:13 PM, Christian Faulhammer wrote: Hi, Samuli Suominenssuomi...@gentoo.org: Just saying... Please track progress somehow. I know it is a lot of work, but makes understanding the process easier. V-Li It's been done in, http://bugs.gentoo.org/show_bug.cgi?id=292791 That is for kdelibs-3.5 - not for qt-3. However, it wouldn't shock me if the list is almost identical. If the opinion of those with more knowledge of such things it that the one effectively covers the other I have no objections to not duplicating work... If not maybe a tracker for any additional qt3 packages that aren't already tracked might not hurt, or we could lump them in together since from a work perspective they're almost the same.
Re: [gentoo-dev] Qt3 deprecation and removal policy
On 12/31/2009 07:51 AM, Samuli Suominen wrote: Stable MythTV has more issues than just Qt3, as the current stable doesn't compile anymore, http://bugs.gentoo.org/show_bug.cgi?id=280303 which is about to get masked tomorrow with kdelibs-3... Those of us who run it wouldn't mind seeing a STABLEREQ if cardoe thinks it is ready... :) I've been thinking about taking the plunge anyway. A news item about the utf-8 issues might not hurt though as doing the upgrade right involves backups/etc. The news item should be released BEFORE it goes stable. That is, unless the upgrade process has become seamless now.
[gentoo-dev] Re: Qt3 deprecation and removal policy
Ben de Groot yngwin at gentoo.org writes: As announced 5 months ago[1], Gentoo's Qt team now officially deprecates usage of x11-libs/qt:3 and packages depending on this version of Qt. # Policy for remaining ebuilds depending on qt:3 # * if Qt3 optional, remove this option * if Qt4 depending version stable, remove Qt3 depending versions * if Qt4 depending version in testing, mark stable, then remove older versions * if no Qt4 version in tree, get Qt4 version in testing by 2010-01-21 and stable by 2010-02-21 * if no Qt4 version exists, check for equivalent/replacement packages, and mask by 2010-02-21 Note: for packages that currently have no version marked stable, the references to stabling Qt4 versions obviously don't apply. 1: http://archives.gentoo.org/gentoo-dev-announce/msg_d851e05567d538b662f34de8dfdb7316.xml Cheers, QUCS is a qt3 only application. This is a fantastic electrical simulation package and is in active developement. There is a svn branch for the qt4 port but it isn't there yet. Removal of qt3 will break this app that is in the main tree If the policy is to then remove this app (which would be a very big shame since it will mean - based upon past experience - hard to get back in) could a hard-mask live ebuild for the svn/nightly be made until the next qucs is released
Re: [gentoo-dev] Re: Qt3 deprecation and removal policy
On 12/31/2009 03:38 PM, Richard Freeman wrote: On 12/31/2009 08:24 AM, Samuli Suominen wrote: It's been done in, http://bugs.gentoo.org/show_bug.cgi?id=292791 That is for kdelibs-3.5 - not for qt-3. However, it wouldn't shock me True, it's linked to http://bugs.gentoo.org/show_bug.cgi?id=283429, to which I've been opening new bugs about everyday... and I'm not part of qt@ in anyway, btw ;-) I really don't support anykind of USE=qt3 masking either before all the bugs are opened there, can't take such shortcuts. IMHO. Specially when it would break the tree, one second glance and I can see e.g. stable gnucash for alpha needing aqbanking with USE qt3 enabled.
Re: [gentoo-dev] Re: Qt3 deprecation and removal policy
On Thursday 31 of December 2009 14:43:54 Mark Bateman wrote: Ben de Groot yngwin at gentoo.org writes: As announced 5 months ago[1], Gentoo's Qt team now officially deprecates usage of x11-libs/qt:3 and packages depending on this version of Qt. # Policy for remaining ebuilds depending on qt:3 # * if Qt3 optional, remove this option * if Qt4 depending version stable, remove Qt3 depending versions * if Qt4 depending version in testing, mark stable, then remove older versions * if no Qt4 version in tree, get Qt4 version in testing by 2010-01-21 and stable by 2010-02-21 * if no Qt4 version exists, check for equivalent/replacement packages, and mask by 2010-02-21 Note: for packages that currently have no version marked stable, the references to stabling Qt4 versions obviously don't apply. 1: http://archives.gentoo.org/gentoo-dev-announce/msg_d851e05567d538b662f34de8 dfdb7316.xml Cheers, QUCS is a qt3 only application. This is a fantastic electrical simulation package and is in active developement. There is a svn branch for the qt4 port but it isn't there yet. Removal of qt3 will break this app that is in the main tree If the policy is to then remove this app (which would be a very big shame since it will mean - based upon past experience - hard to get back in) could a hard-mask live ebuild for the svn/nightly be made until the next qucs is released It could be moved to kde-sunset overlay where legacy KDE3 stuff (like KDE 3.5.10 itself) is being kept and maintained by the community. -- regards MM
Re: [gentoo-dev] Re: Qt3 deprecation and removal policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31-12-2009 13:10, Maciej Mrozowski wrote: On Thursday 31 of December 2009 14:43:54 Mark Bateman wrote: Ben de Groot yngwin at gentoo.org writes: As announced 5 months ago[1], Gentoo's Qt team now officially deprecates usage of x11-libs/qt:3 and packages depending on this version of Qt. # Policy for remaining ebuilds depending on qt:3 # * if Qt3 optional, remove this option * if Qt4 depending version stable, remove Qt3 depending versions * if Qt4 depending version in testing, mark stable, then remove older versions * if no Qt4 version in tree, get Qt4 version in testing by 2010-01-21 and stable by 2010-02-21 * if no Qt4 version exists, check for equivalent/replacement packages, and mask by 2010-02-21 Note: for packages that currently have no version marked stable, the references to stabling Qt4 versions obviously don't apply. 1: http://archives.gentoo.org/gentoo-dev-announce/msg_d851e05567d538b662f34de8 dfdb7316.xml Cheers, QUCS is a qt3 only application. This is a fantastic electrical simulation package and is in active developement. There is a svn branch for the qt4 port but it isn't there yet. Removal of qt3 will break this app that is in the main tree If the policy is to then remove this app (which would be a very big shame since it will mean - based upon past experience - hard to get back in) could a hard-mask live ebuild for the svn/nightly be made until the next qucs is released It could be moved to kde-sunset overlay where legacy KDE3 stuff (like KDE 3.5.10 itself) is being kept and maintained by the community. We can also get an ebuild for the live version in the KDE overlay (if it uses KDE) or the appropriate Qt overlay. Are you interested in contributing an ebuild for it? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks8u14ACgkQcAWygvVEyALG9gCfbIgFR3duBUZ4On0IXFPwHH65 Ch4AmwewWXcwOqZFwaHQ02/5QGYJKUCD =MzRW -END PGP SIGNATURE-
[gentoo-dev] package up for grabs (almost everything in the livecd herd)
[I'm resending this, because I never saw it come through last week.] In the olden days, the livecd herd was basically wolf31o2 and covered any packages that releng had a passing interest in, even if not directly used during the release building process. Since wolf31o2 retired over a year ago, many of the packages owned by the livecd herd have basically become unmaintained (except for the ones that I myself have an interest in). If you are interested in any of the below packages, feel free to steal it (and change the maintainer and herd bit in the metadata.xml). app-arch/pbzip2 - We pondered using it at some point to take advantage of all the shiny new multi-proc boxes that releng and its members had laying around app-admin/pwgen - This is used by the LiveCD to generate a random password. It looks like upstream hasn't touched this since it was last bumped in the tree. dev-python/pyparted - Used by the now defunct GLI sys-apps/hwdata-gentoo - Data used by sys-apps/hwsetup sys-apps/hwsetup - Used for hardware (video mostly) detection for LiveCD sys-apps/parted - Required by dev-python/pyparted sys-fs/squashfs-tools - Used by catalyst to create loop image sys-libs/libkudzu - needed by sys-apps/hwsetup -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] Qt3 deprecation and removal policy
2009/12/31 Richard Freeman ri...@gentoo.org: 30 days isn't a long time. How about filing bugs against anything that currently uses qt3 right away, so that maintainers have an extra three weeks to resolve these issues? Granted, one would hope they've been paying attention. We've already announced that 5 months ago and asked for any issues to be brought to our attention. If things haven't improved by now, it is doubtful they will with a few months extra time. Our current timeline gives maintainers another seven weeks to resolve issues, before x11-libs/qt:3 will be package.masked. Usually the approach in these situations is to have a big tracker bug for qt3 removal and a million blocker bugs against individual packages. There is a tracker bug, I should have mentioned it in the original mail: https://bugs.gentoo.org/show_bug.cgi?id=283429 Please file bugs blocking the tracker for any package you think is important and doesn't have a Qt4 version or replacement yet. If there is a Qt4 version, but not yet stable, then stable requests should be filed, which also block the tracker. The Qt team will also go through the tree and file bugs for all remaining packages within the next couple of weeks. Plus, you might decide that one or two of the blockers really are critical, and decide to work with those maintainers more closely or escalate the issue. Sure. As I said in the original mail: We are dedicated to do anything we reasonably can to make sure that Qt4 versions or equivalents of the remaining Qt3 packages in the portage tree are available. I believe we can work things out in the next seven weeks, and otherwise we could reconsider the timeline. But we need short-term goals, otherwise it will take forever to get things done. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: Qt3 deprecation and removal policy
2009/12/31 Maciej Mrozowski reave...@gmail.com: On Thursday 31 of December 2009 14:43:54 Mark Bateman wrote: QUCS is a qt3 only application. This is a fantastic electrical simulation package and is in active developement. There is a svn branch for the qt4 port but it isn't there yet. Removal of qt3 will break this app that is in the main tree If the policy is to then remove this app (which would be a very big shame since it will mean - based upon past experience - hard to get back in) could a hard-mask live ebuild for the svn/nightly be made until the next qucs is released Yes, a hardmasked live ebuild is a possibility. A snapshot ebuild would be even better, as that could be in ~arch. It could be moved to kde-sunset overlay where legacy KDE3 stuff (like KDE 3.5.10 itself) is being kept and maintained by the community. All packages depending on qt:3 should be moved to kde-sunset. A bug should be filed for this package, blocking the qt3 removal tracker. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] package up for grabs (almost everything in the livecd herd)
On Thu, Dec 31, 2009 at 16:55, Andrew Gaffney agaff...@gentoo.org wrote: app-arch/pbzip2 - We pondered using it at some point to take advantage of all the shiny new multi-proc boxes that releng and its members had laying around I'll take pbzip2. -- Dror Levin
Re: [gentoo-dev] package up for grabs (almost everything in the livecd herd)
On 31/12/09 15:55, Andrew Gaffney wrote: app-admin/pwgen - This is used by the LiveCD to generate a random password. It looks like upstream hasn't touched this since it was last bumped in the tree. I would take this one. Jeremy, would you proxy me the next time? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] package up for grabs (almost everything in the livecd herd)
On Thu, Dec 31, 2009 at 8:25 PM, Andrew Gaffney agaff...@gentoo.org wrote: If you are interested in any of the below packages, feel free to steal it (and change the maintainer and herd bit in the metadata.xml). dev-python/pyparted - Used by the now defunct GLI This has also not been updated since 2007 -- https://fedorahosted.org/releases/p/y/pyparted/ sys-libs/libkudzu - needed by sys-apps/hwsetup sys-apps/hwdata-gentoo - Data used by sys-apps/hwsetup sys-apps/hwsetup - Used for hardware (video mostly) detection for LiveCD I don't think these two (three?) are required anymore, what with the hardware detection by the kernel and udev becoming excellent. Maybe they should be tree-cleaned while archiving hwsetup-gentoo's distfiles somewhere? sys-apps/parted - Required by dev-python/pyparted And sys-apps/gparted -- if no one else takes this, gnome herd (or I) can take it I suppose sys-fs/squashfs-tools - Used by catalyst to create loop image And is useful for anyone who wants to use squashfs -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: RFC: clutter.eclass -- new eclass for packages related to Clutter
On Wed, Dec 30, 2009 at 3:10 PM, Christian Faulhammer fa...@gentoo.org wrote: Nirbheek Chauhan nirbh...@gentoo.org: The eclass is attached, and is very simple, consisting of just SRC_URI, DEPEND, LICENSE, DOCS, and src_install. No objections. Thanks to you (and the silent reviewers) for the review! I'll commit this on Monday if there are no objections. Regards, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-dev-announce] Election for the Gentoo Council empty seat
On 12/20/2009 11:43 PM, Fabian Groffen wrote: On 15-12-2009 23:57:41 -0100, Jorge Manuel B. S. Vicetto wrote: nomination: December 17th to 30th voting: January 1st to 14th To nominate anyone for the empty seat, please send an email to the gentoo-dev ml. Anyone can nominate for the Council, but only current Gentoo Developers can stand for and vote in the election. I nominate (in no particular order): lu_zero Thank you for the trust, I'd gladly accept but, as you can all see from this late reply, I'm in sorely need for either a better mail client and/or other ways to be more responsive. I think either Patrick or Tomáš could be a good asset for the council in my place. Hopefully in the mean time I'll focus on fixing what make me being slackered out of council and reply this late to your nomination =) lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
[gentoo-dev] Election for the Gentoo Council empty seat - nominations closed and voting delayed 24 hours
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello again. The nominations for the empty seat in the Council were closed 20 hours ago. All the details about this election can be found in the Council Elections Archives[1]. The information about the nominees can be seen in the 200912 nominees[2] page. If you think you're entitled to vote in this election, please check the list of voters[3]. The dates for voting in this election will be pushed back 24 hours as I failed to notice the start coincided with New Year's and the elections team is busy this night. Thus, the dates for voting are the following: voting: January 2nd to 15th The election officials for this election are going to be me, Roy Bamford (NeddySeagoon) and a 3rd person (we have candidates, but the position is still open) and the infrastructure contact for the election is going to be either Shyam Mani (fox2mike) or Robin H Johnson (robbat2). The rules for the Council election as well as details on how to vote for this election are available in the Council Elections Archives[1]. In any case, here is the quick procedure on how to vote using votify: * If you're eligible to vote in this election, log in to dev.gentoo.org * Type votify --new council200912 to create a new ballot file * Edit .ballot-council200912 file in your home directory and rank the candidates * Once you're finished, use votify --verify council200912 command to verify validity of your ballot file * If everything is okay, use votify --submit council200912 to submit your vote. Don't forget your vote doesn't count until you submit it. * If you run into problems, you can either work them out yourself using votify --help or contact election officials and ask them for help The elections for the Council now include the _reopen_nominations candidate. Any candidate that ranks below this candidate cannot be selected to fill the missing seat or any future seats that open until the next full council election. If the council remains with an open seat(s) and no candidates are eligible to fill that seat, a new election will be held to fill that seat / those seats. If you have any doubts, please contact one of the election officials in IRC, you can use the elections project channel[4], or email the Elections team[5]. [1] - http://www.gentoo.org/proj/en/elections/council/ [2] - http://www.gentoo.org/proj/en/elections/council/2009/council-200912-nominees.xml [3] - http://www.gentoo.org/proj/en/elections/council/2009/voters-council200912.txt [4] - #gentoo-elections in the Freenode or OFTC IRC networks [5] - electi...@gentoo.org For the election officials, - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks9DtwACgkQcAWygvVEyAJ/5gCfWT7CoQwpbGbuEsoWSCOr+0HT EB0An1VNSR5rqYhbq/OK00Ttzvdvo91Y =4t0j -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: use.local.desc
On 01/01/2010 12:07 AM, Robin H. Johnson (robbat2) wrote: +app-accessibility/flite:alsa - use alsa for audio output. +app-accessibility/flite:oss - Use Open Sound System for audio output. Why? USE alsa and oss are global flags.
Re: [gentoo-portage-dev] can an overlay force a USE flag on a host?
On 12/31/2009 11:57 AM, Zac Medico wrote: Other than IUSE defaults, the only way is to create a /etc/make.profile directory and list multiple profiles in the parent file. I forgot the mention that as a workaround for bug 238887 you might check for the required USE combination in pkg_setup and die if you requirements aren't met. For example, this is how the openldap ebuild ensures that sasl is enabled when cxx is enabled. It's not very friendly but it works. -- Thanks, Zac
