[gentoo-dev] Why do packages which will not build remain in the distribution list?
For the last week or so, there have been packages in the world distribution list which previously installed fine which currently do not, these include ruby-gdkpixbuf2, ruby-pango, ruby-gtk2, ruby-gnomecanvas2, ruby-gnome2 and ruby-libglade2 (this is on an x86 system). My reading of the bug reports suggest that this is a problem with the ruby/gentoo config scripts. If so, ok fine, then pull them from the world distribution until such scripts/ebuilds/patches are available. Please do not leave them in the world distribution list when they are known to be defective. It appears that there may be some oversight/direction lacking with respect to what makes up the QA with respect to distributed (e.g. approved) packages which have known problems. For people who attempt to update their systems on a nightly basis and provide feedback to the Gentoo developers, this can be an annoying situation (it may require the expansion/contraction of scripts which enable/disable nightly builds). I understand if there is a problem with the upstream source which may take months to fix for the bug reports to percolate up and solutions to percolate down, but in the mean time end users should not be subjected to packages known to be problematic (and thus the packages should be pulled from the world distribution list). Robert
[gentoo-dev] Re: RFC: clutter.eclass -- new eclass for packages related to Clutter
Hi, 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. 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] Why do packages which will not build remain in the distribution list?
On 12/30/2009 12:11 PM, Robert Bradbury wrote: For the last week or so, there have been packages in the world distribution list which previously installed fine which currently do not, these include ruby-gdkpixbuf2, ruby-pango, ruby-gtk2, ruby-gnomecanvas2, ruby-gnome2 and ruby-libglade2 (this is on an x86 system). My reading of the bug reports suggest that this is a problem with the ruby/gentoo config scripts. If so, ok fine, then pull them from the world distribution until such scripts/ebuilds/patches are available. Please do not leave them in the world distribution list when they are known to be defective. It appears that there may be some oversight/direction lacking with respect to what makes up the QA with respect to distributed (e.g. approved) packages which have known problems. You need to understand what the world set means. The world set is the packages in /var/lib/portage/world and the sets from /var/lib/portage/world_sets . From this follows that we can't change the content of the world set as it's a user specific configuration issue. Just make sure nothing in those files pulls in the packages that you have issues with and they are no longer part of your world set. What really should happen is that bug reports are filed on things that don't build and they are package.masked if they can't be fixed in a reasonable time frame. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Non-free software in Gentoo
On 12/29/2009 07:52 PM, Greg KH wrote: No, the readme/copying is correct, it covers all of the code that runs on the processor as one body of work. Firmware blobs are different in that they do not run in the same processor, and can be of a different license. Yes, but they don't cover everything in the tarball. If I want to copy the tarball, then I need to comply with the distribution license of the tarball. That license isn't clearly advertised. It is a mix of a number of licenses from GPL v2 to allowed-to-copy-without-modifications. The processor that the software runs on is fairly irrelevant. In any case, I'm sure the kernel team will update the ebuild license string appropriately - this is more of a debate for the LKML. I just don't think that they've done a good job with it. Others are welcome to hold differing opinions. :)
Re: [gentoo-dev] Why do packages which will not build remain in the distribution list?
On 12/30/2009 05:18 AM, Petteri Räty wrote: You need to understand what the world set means. The world set is the packages in /var/lib/portage/world and the sets from /var/lib/portage/world_sets . From this follows that we can't change the content of the world set as it's a user specific configuration issue. Just to clarify a little (the above is completely accurate, but it might not be obvious how portage works just from reading this): The world set is a list of every package that you've executed an emerge package command on, without a -1 on the command line. So, if you type emerge xterm, then xterm is in your world set. A package is removed from world if you uninstall it, or if you edit that file manually. Packages that are installed because they are needed by packages that you install are not added to world, unless you later manually emerge them without a -1 on the command line. The idea is that anything you explicitly ask for is something that portage will try to keep around for you, and anything you don't explicitly ask for is something that portage will try to get rid of if it isn't needed later. So, those ruby packages ended up in world because you emerged them. Any new version that goes stable/testing on those packages will consequently get pulled in by an emerge -u world. The real issue (as was pointed out) is that packages shouldn't even be marked for testing (let alone stable) if they don't actually build, or if they have serious problems. They should be masked, so that only those interested in developing/debugging the package get hit with it. I don't want to comment on the packages you listed in particular, but sometimes you can run into build issues due to a need to run revdep-rebuild, or lafilefixer, or to rebuild some library. I had an x86 chroot that absolutely refused to build imagemagick until I just reinstalled the whole thing from stage3 - probably some obscure library/compiler problem. So a build error might not reflect a problem with the package you're trying to build. Obviously we still try to avoid these kinds of issues and warn users when they are likely to happen. I'd continue to follow the bug, and if it seems like something like this isn't being resolved expediently feel free to contact the QA team: http://www.gentoo.org/proj/en/qa/ The QA team ensures that Gentoo quality policies are being followed and can poke maintainers or step in as appropriate. Note that I haven't reviewed the packages/bugs that are being discussed here, so none of this is targeted at anybody in particular. I'm just pointing out how things like this are supposed to work in general. Rich
Re: [gentoo-dev] Why do packages which will not build remain in the distribution list?
On Wed, 30 Dec 2009 06:58:48 -0500, Richard Freeman ri...@gentoo.org wrote: [...] So a build error might not reflect a problem with the package you're trying to build. This is the case here. Some packages install broken pkg-config files (missing a Name: field) which will cause pkg-config --list-all to fail when encountering such a package. That in turn also makes the Ruby pkg-config library fail which is used in the configure step. We already have filed some bugs against these broken packages. Now we have to wait until all are fixed, or find a way to make pkg-config more resistant to such errors -- both are outside of the Ruby team's realm. Alex -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
[gentoo-dev] Qt3 deprecation and removal policy
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. The only supported and maintained version of Qt, both by the upstream developers (Nokia) and the Gentoo Qt Project, is now only version 4 (specifically =4.5.3). As a result we have decided on a policy and timeline for the removal of qt:3 and ebuilds depending on it. 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. The deprecated ebuilds for qt:3, and packages using it, will remain available in the community-maintained kde-sunset overlay. # Timeline # 2010-01-01: * mark qt:3 as deprecated with ewarn * mask qt3 useflag in profiles * add ewarn to qt3.eclass with link to removal policy * prepare news item about qt:3 deprecation and future removal 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 2010-03-21: * remove qt:3 and depending ebuilds from the tree * remove masks * clean profiles from qt3 remnants * mark qt3.eclass as deprecated pending later removal # 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, -- Ben de Groot Gentoo Linux developer, Gentoo Qt Project lead __
Re: [gentoo-dev] Election for the Gentoo Council empty seat
On Tue, Dec 15, 2009 at 11:57:41PM -0100, Jorge Manuel B. S. Vicetto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. As announced by Denis (Calchan)[1], we need to have an election for the Gentoo Council's empty seat. We'll be putting up a page with all the information for the Council election, including the election officials, asap. I'll send another email later with the link and the missing information, but for now, let me just share the dates for nomination and voting: 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. If you have any doubts, please contact me in IRC, you can use the elections project channel[2], or email the Elections team[3]. I nominate tanderson. And I (obviously) accept. :) -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council -
Re: [gentoo-dev] Election for the Gentoo Council empty seat
On Tue, Dec 15, 2009 at 11:57:41PM -0100, Jorge Manuel B. S. Vicetto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. As announced by Denis (Calchan)[1], we need to have an election for the Gentoo Council's empty seat. We'll be putting up a page with all the information for the Council election, including the election officials, asap. I'll send another email later with the link and the missing information, but for now, let me just share the dates for nomination and voting: 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. If you have any doubts, please contact me in IRC, you can use the elections project channel[2], or email the Elections team[3]. I nominate Alex Alexander ( wired ) Cheers -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise/Kernel/AMD64/Bug-wrangler] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Election for the Gentoo Council empty seat
On Wed, Dec 30, 2009 at 09:27:12PM +0200, Markos Chandras wrote: On Tue, Dec 15, 2009 at 11:57:41PM -0100, Jorge Manuel B. S. Vicetto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. As announced by Denis (Calchan)[1], we need to have an election for the Gentoo Council's empty seat. We'll be putting up a page with all the information for the Council election, including the election officials, asap. I'll send another email later with the link and the missing information, but for now, let me just share the dates for nomination and voting: 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. If you have any doubts, please contact me in IRC, you can use the elections project channel[2], or email the Elections team[3]. I nominate Alex Alexander ( wired ) I accept the nomination. Thanks Markos :) Cheers -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise/Kernel/AMD64/Bug-wrangler] Web: http://hwoarang.silverarrow.org -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpl8S2IoF270.pgp Description: PGP signature
Re: [gentoo-dev] Qt3 deprecation and removal policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Em 30-12-2009 15:14, Ben de Groot escreveu: 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. The only supported and maintained version of Qt, both by the upstream developers (Nokia) and the Gentoo Qt Project, is now only version 4 (specifically =4.5.3). As a result we have decided on a policy and timeline for the removal of qt:3 and ebuilds depending on it. 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. The deprecated ebuilds for qt:3, and packages using it, will remain available in the community-maintained kde-sunset overlay. # Timeline # 2010-01-01: * mark qt:3 as deprecated with ewarn * mask qt3 useflag in profiles * add ewarn to qt3.eclass with link to removal policy * prepare news item about qt:3 deprecation and future removal 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 2010-03-21: * remove qt:3 and depending ebuilds from the tree * remove masks * clean profiles from qt3 remnants * mark qt3.eclass as deprecated pending later removal # 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, A question: My systems don't use qt3 use flag since six months ago, but using qt3support USE FLAG. It's sane keep this flag set in make.conf? Thanks for now. p.s.: sorry if this is not the place to this question. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks7ui8ACgkQ35zeJy7JhCiAxACgo/ebR4o+/gQa9/1+xjSTV0w8 kLoAoIueeG1xBlqwAR5XqBX1TrkqzRd5 =IquM -END PGP SIGNATURE-
Re: [gentoo-dev] Qt3 deprecation and removal policy
2009/12/30 Zhu Sha Zang zhushaz...@yahoo.com.br: Cheers, A question: My systems don't use qt3 use flag since six months ago, but using qt3support USE FLAG. It's sane keep this flag set in make.conf? If you use KDE or anything else that depends on the qt3support use flag, then it is a requirement. qt3support isn't Qt3, it is just an extra part of the Qt4 api for easing Qt3 - Qt4 porting. HTH Espen
Re: [gentoo-dev] Qt3 deprecation and removal policy
2009/12/30 Zhu Sha Zang zhushaz...@yahoo.com.br: A question: My systems don't use qt3 use flag since six months ago, but using qt3support USE FLAG. It's sane keep this flag set in make.conf? Absolutely. That useflag is also enabled by default in the desktop profile, because KDE4 depends on it. Qt3support is a Qt4 module and does not depend on qt:3. It is used to make it easier for developers to port Qt3 apps to Qt4. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Non-free software in Gentoo
On Tue, Dec 29, 2009 at 09:42:06PM -0500, Vincent Launchbury wrote: Greg KH wrote: The fact that some people claim that the firmware blobs somehow violate the GPLv2 license of the kernel is a claim, not a fact, so please do not state it as such. Hi Greg, Thanks for your reply. I think you misunderstood my point though. I wasn't saying that the firmware violates the GPL, I have no idea whether it does or not. I was saying that some of the firmware is non-free software, and therefore the license should include more than just GPL-2. This especially effects people using ACCEPT_LICENSE to maintain a free system. 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. Hint, these firmware blobs do not run on your processor, so they have nothing to do with the license of your system. Also note that the majority of these firmware blobs are now removed from the kernel, and are in a separate patckage, so this might be totally irrelevant at this point in time. This may be true, but the packages in the main tree still contain non-free firmware. If this is fixed in a later release, then GPL-2 would be fine for those. Again, no, the GPLv2 covers the license of all of the code you run in the kernel package. So please don't state that the Linux kernel is not properly listed as the GPLv2, because it is. In linux-2.6.31 for example, here are some excerpts from firmware/WHENCE: Regarding the keyspan USB driver: This firmware may not be modified and may only be used with Keyspan hardware. and the emi26 driver: This firmware may not be modified and may only be used with the Emagic EMI 2|6 Audio Interface. And again, you do not run those firmware images on your processor, so the point is moot. 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. I'm not sure if this git repo is part of a separate package or not, but it seems the same terms are present: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=WHENCE;h=83d245bee1ec44cbd5c0e1a53a3989c57f675c91;hb=f20b0674534a444ae74239843cac19f72c64912b Which is why I think the license should be amended. If I'm mistaken, please do correct me, but based on my above notes, I believe it should be updated. Please see above why this is all just fine. thanks, greg k-h
Re: [gentoo-dev] Non-free software in Gentoo
On Wed, Dec 30, 2009 at 06:43:47AM -0500, Richard Freeman wrote: On 12/29/2009 07:52 PM, Greg KH wrote: No, the readme/copying is correct, it covers all of the code that runs on the processor as one body of work. Firmware blobs are different in that they do not run in the same processor, and can be of a different license. Yes, but they don't cover everything in the tarball. If I want to copy the tarball, then I need to comply with the distribution license of the tarball. That license isn't clearly advertised. It is a mix of a number of licenses from GPL v2 to allowed-to-copy-without-modifications. No, you can copy that tarball just fine, and when you _distribute_ it, the GPLv2 applies to it. The processor that the software runs on is fairly irrelevant. Not true at all, why would you think that? Since when does a license cross a processor boundry? In any case, I'm sure the kernel team will update the ebuild license string appropriately - this is more of a debate for the LKML. I just don't think that they've done a good job with it. Others are welcome to hold differing opinions. :) You don't think the gentoo kernel team (of which I think I'm the longest-term member), or the Linux kernel developers (of which I am the actual person who put those images in the kernel back in the late 1990's after consulting many lawers, and Linus, on the issue) are doing a good job with this? thanks, greg k-h
Re: [gentoo-dev] Non-free software in Gentoo
On Wed, Dec 30, 2009 at 08:51:18PM -0800, Greg KH wrote: On Wed, Dec 30, 2009 at 06:43:47AM -0500, Richard Freeman wrote: On 12/29/2009 07:52 PM, Greg KH wrote: No, the readme/copying is correct, it covers all of the code that runs on the processor as one body of work. Firmware blobs are different in that they do not run in the same processor, and can be of a different license. Yes, but they don't cover everything in the tarball. If I want to copy the tarball, then I need to comply with the distribution license of the tarball. That license isn't clearly advertised. It is a mix of a number of licenses from GPL v2 to allowed-to-copy-without-modifications. No, you can copy that tarball just fine, and when you _distribute_ it, the GPLv2 applies to it. Then I can distribute modified versions of the tarball, with altered firmware, in direct violation of the license granted for that firmware, just because it's allowed by the GPL? Seriously, you're saying the license of the firmware doesn't matter. The processor that the software runs on is fairly irrelevant. Not true at all, why would you think that? Since when does a license cross a processor boundry? When I copy the Linux kernel sources, all files are copied by a single processor. This isn't about running the kernel. In any case, I'm sure the kernel team will update the ebuild license string appropriately - this is more of a debate for the LKML. I just don't think that they've done a good job with it. Others are welcome to hold differing opinions. :) You don't think the gentoo kernel team (of which I think I'm the longest-term member), or the Linux kernel developers (of which I am the actual person who put those images in the kernel back in the late 1990's after consulting many lawers, and Linus, on the issue) are doing a good job with this? Please stop avoiding the issue. No one is saying the firmware is in conflict with the GPL, or that distribution of the kernel is illegal. The way it's distributed is fine. It's just not reflected properly in Gentoo.
Re: [gentoo-portage-dev] binpkg doesn't pull-in dependency required by USE flag
On 12/29/2009 11:45 PM, Amit Dor-Shifer wrote:
Normally, when jce is on, sun-jdk pulls-in sun-jce-bin:
amit0 myebuilds # USE=${USE} jce emerge -p sun-jdk
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N f ] dev-java/sun-jce-bin-1.6.0
[ebuild R ] dev-java/sun-jdk-1.6.0.16 USE=jce*
However, when I attempt to merge the binpkg-ed sun-jdk, dep isn't pulled:
That's because the dependency is in DEPEND which is built time only
and therefore doesn't apply to binary packages. You can use
--with-bdeps=y if you want it to pull in DEPEND for binary packages.
--
Thanks,
Zac
[gentoo-portage-dev] forcing a USE flag if another is on
Is there some method of specifing if USE flag X is enabled, enable USE flag y as-well? Something like a conditional use.force file in profiles/. Amit
[gentoo-portage-dev] Re: forcing a USE flag if another is on
Amit Dor-Shifer posted on Wed, 30 Dec 2009 16:45:40 +0200 as excerpted: Is there some method of specifing if USE flag X is enabled, enable USE flag y as-well? Something like a conditional use.force file in profiles/. Amit That should be doable globally using /etc/portage/bashrc or the like ( /etc/portage/profile/bashrc). For specific packages, it's doable using /etc/portage/env/cat-egory/pkgname files, altho that's not so well documented. In any of those cases, syntax is standard bash, so you get the full range of bash conditionals and scripting available to setup your environment as complicated as you wish. (However, it is my understanding that the /etc/portage/env files only get sourced for the bash/ebuild.sh side of portage, not for the python side, so stuff like depchecks and features that are dealt with on the python side, won't necessarily work as expected. Test it if in doubt... or put it in one of the bashrcs, with a conditional so it's only applied to the package in question.) -- 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-portage-dev] Re: forcing a USE flag if another is on
On Wed, Dec 30, 2009 at 04:20:45PM +, Duncan wrote: Amit Dor-Shifer posted on Wed, 30 Dec 2009 16:45:40 +0200 as excerpted: Is there some method of specifing if USE flag X is enabled, enable USE flag y as-well? Something like a conditional use.force file in profiles/. Amit That should be doable globally using /etc/portage/bashrc or the like ( /etc/portage/profile/bashrc). It's not doable via bashrc (bashrc runs at build time)- intentionally to block abuses of this sort I might add. Reiterating- playing w/ USE in bash doesn't change the USE state python/package manager side, meaning you'll not get the proper depedencies pulled in... ~harring pgpaFikDS1XEq.pgp Description: PGP signature
