Re: [gentoo-dev] base.eclass
On Sun, 8 Jul 2012 17:35:08 -0400
Alexis Ballier aball...@gentoo.org wrote:
On Sun, 8 Jul 2012 22:10:02 +0200
Michał Górny mgo...@gentoo.org wrote:
On Sun, 08 Jul 2012 19:49:25 +0200
René Neumann li...@necoro.eu wrote:
Hi all,
I'd like just to receive a short clarification about the 'status'
of base.eclass: Is this eclass expected to be available
everywhere, i.e. should each eclass make sure it imports and
incorporates it. Or is it just an eclass like the others and
ebuilds should make sure they inherit it if needed?
No. It is unmaintained, has serious design flaws and it simply
should not be used anywhere. At least in EAPI != [01].
what is the PATCHES=() replacement in new eapis? (mainly why i use
base.eclass more and more these days)
That's what I used:
[[ ${PATCHES} ]] epatch ${PATCHES[@]}
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] base.eclass
On Sun, 8 Jul 2012 23:40:29 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny: On Sun, 08 Jul 2012 19:49:25 +0200 René Neumann li...@necoro.eu wrote: Hi all, I'd like just to receive a short clarification about the 'status' of base.eclass: Is this eclass expected to be available everywhere, i.e. should each eclass make sure it imports and incorporates it. Or is it just an eclass like the others and ebuilds should make sure they inherit it if needed? No. It is unmaintained, has serious design flaws and it simply should not be used anywhere. At least in EAPI != [01]. Please clarify this. A lot of (inheriting eclasses and) packages depend on features provided by base.eclass (e.g., PATCHES), which are pretty neat and which I would sorely miss. So I would certainly object to deprecating base.eclass, unless its relevant functionality is only moving to a better place. base.eclass is randomly exporting non-requested, non-wanted phase functions colliding with other inherited eclasses. It's just the lexical order of inherits what stops mayhem from happening. In other words, base.eclass is only suitable if you are expecting to export *all* phase functions which simply doesn't happen in eclasses. For example, if distutils used base eclass, every VCS eclass inherited before it would be ignored (due to src_unpack() redefined to default one for no good reason). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] base.eclass
On Sun, 8 Jul 2012 23:40:29 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: A lot of (inheriting eclasses and) packages depend on features provided by base.eclass (e.g., PATCHES), which are pretty neat and which I would sorely miss. So I would certainly object to deprecating base.eclass, unless its relevant functionality is only moving to a better place. Then you should ask for EAPI support for PATCHES, or write the code manually, or put the code in a small eclass that just does that. But note that the Council has voted against having either arguments or global scope variables to enhance default phase functions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] base.eclass
On 07/08/2012 11:10 PM, Michał Górny wrote: On Sun, 08 Jul 2012 19:49:25 +0200 René Neumann li...@necoro.eu wrote: Hi all, I'd like just to receive a short clarification about the 'status' of base.eclass: Is this eclass expected to be available everywhere, i.e. should each eclass make sure it imports and incorporates it. Or is it just an eclass like the others and ebuilds should make sure they inherit it if needed? No. It is unmaintained, has serious design flaws and it simply should not be used anywhere. At least in EAPI != [01]. yet base.eclass supports arguments for base_src_install passed to 'make install' and council voted against moving this to the PM so what ciaranm said is very true, people just refuse to let it become useless
Re: [gentoo-dev] base.eclass
On Mon, 09 Jul 2012 11:21:21 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: yet base.eclass supports arguments for base_src_install passed to 'make install' and council voted against moving this to the PM so what ciaranm said is very true, people just refuse to let it become useless Perhaps you should view the Council's vote as advice that passing arguments that way is unpopular and unlikely to endear you to your fellow developers. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] base.eclass
On Mon, 9 Jul 2012 08:39:38 +0200
Michał Górny mgo...@gentoo.org wrote:
On Sun, 8 Jul 2012 17:35:08 -0400
Alexis Ballier aball...@gentoo.org wrote:
On Sun, 8 Jul 2012 22:10:02 +0200
Michał Górny mgo...@gentoo.org wrote:
On Sun, 08 Jul 2012 19:49:25 +0200
René Neumann li...@necoro.eu wrote:
Hi all,
I'd like just to receive a short clarification about the
'status' of base.eclass: Is this eclass expected to be available
everywhere, i.e. should each eclass make sure it imports and
incorporates it. Or is it just an eclass like the others and
ebuilds should make sure they inherit it if needed?
No. It is unmaintained, has serious design flaws and it simply
should not be used anywhere. At least in EAPI != [01].
what is the PATCHES=() replacement in new eapis? (mainly why i use
base.eclass more and more these days)
That's what I used:
[[ ${PATCHES} ]] epatch ${PATCHES[@]}
and ? thanks, I can read the code :)
are you suggesting people to duplicate the code ? this is in no way a
replacement...
A.
Re: [gentoo-dev] base.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2012 08:45 AM, Michał Górny wrote: On Sun, 8 Jul 2012 23:40:29 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny: On Sun, 08 Jul 2012 19:49:25 +0200 René Neumann li...@necoro.eu wrote: Hi all, I'd like just to receive a short clarification about the 'status' of base.eclass: Is this eclass expected to be available everywhere, i.e. should each eclass make sure it imports and incorporates it. Or is it just an eclass like the others and ebuilds should make sure they inherit it if needed? No. It is unmaintained, has serious design flaws and it simply should not be used anywhere. At least in EAPI != [01]. Please clarify this. A lot of (inheriting eclasses and) packages depend on features provided by base.eclass (e.g., PATCHES), which are pretty neat and which I would sorely miss. So I would certainly object to deprecating base.eclass, unless its relevant functionality is only moving to a better place. base.eclass is randomly exporting non-requested, non-wanted phase functions colliding with other inherited eclasses. It's just the lexical order of inherits what stops mayhem from happening. In other words, base.eclass is only suitable if you are expecting to export *all* phase functions which simply doesn't happen in eclasses. For example, if distutils used base eclass, every VCS eclass inherited before it would be ignored (due to src_unpack() redefined to default one for no good reason). There are tons of eclasses randomly exporting phase functions. That is not the problem. The problem is that other eclasses inherit base.eclass. Only that leads to this mess. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP+tmXAAoJEFpvPKfnPDWz2JMH/AwYoHvD9vIBhSSDCQ6np/L5 NzDHuKcqUKKQ5bs9+gHWSf81lFaazu9mw187d1o016nD6TQ1rPjbulQhU9ZLuCt1 qDGBAH1j1vPOktstxzkAXWRzkmbkGir9hz5Mw8WO+AXvcHa5sP4stiaNQyL6ZKhe hhfLkZC+ToZP8CcW7yeS8nC910bvDV9hVfNxsBOMR/EKY/aSnHcsfOf4c3pCX9xd YrrEvoT9zdx9827sk8+PO4m4kAZsvjem7IiTTa+LRH1wPf5DBpjL19c0pSyHF3Kc kBDL4BFrT4lqoNhO0vDXL45AVRsKz2/G0Tu7XLg2ewwCZByPpPlGR277wLjRo44= =DaE5 -END PGP SIGNATURE-
[gentoo-dev] Portage Output / End User Experience
After a little discussion in bug 425016 [1], I did an experiment. I created a fresh Gentoo install, set the profile to desktop/kde, and tried to emerge chromium and kde-meta. The immediate response was for portage to suggest setting -u and -N due to conflicts. So, I tried emerge -puDNv chromium kde-meta That said I needed to enable minizip for zlib and icu for libxml2. So, I did that via package.use, and tried again. Now I'm told: The following keyword changes are necessary to proceed: #required by dev-libs/libxslt-1.1.26-r3, required by x11-libs/libxcb-1.8.1, required by x11-libs/xcb-util-0.3.9, required by x11-libs/xcb-util-image-0.3.9 =dev-libs/libxml2-2.8.0-r1 ~amd64 The following USE changes are necessary to proceed: #required by net-libs/libsoup-2.36.1-r1, required by media-plugins/gst-plugins-soup-0.10.30, required by media-libs/phonon-gstreamer-4.5.0[network], required by media-libs/phonon-4.5.1-r1[gstreamer], required by kde-base/kdelibs-4.8.3, required by kde-base/libkcompactdisc-4.8.3, required by kde-base/kdemultimedia-meta-4.8.3, required by kde-base/kde-meta-4.8.3, required by kde-meta (argument) =dev-libs/libxml2-2.8.0-r1 -icu emerge: there are no ebuilds built with USE flags to satisfy dev-libs/libxml2:2[!icu?]. !!! One of the following packages is required to complete your request: - dev-libs/libxml2-2.7.8-r5::gentoo (Change USE: -icu) - x11-libs/qt-webkit-4.8.2::gentoo (Change USE: +icu) Now, a few interesting things here: 1. On my regular kde desktop I don't have an unstable version of libxml2 - I'm not sure why I haven't gotten any complaints about that, but I'm being told to unmask it in this case. 2. The first suggestion with libxml2 is to remove the icu flag, which the previous step told me to add. 3. The very last line does get at what needs to be done here - enable +icu on qt-webkit. If I enable icu on qt-webkit only then it looks like it should work - it no longer asks to unmask libxml2 or unset the icu use flag. I realize that figuring out the right thing to do here isn't at all a trivial matter. However, this seems like a fairly convoluted thing for a new user who wants to run KDE and Chromium to go through. Those are both VERY mainstream packages. Is there any way to improve the portage logic to give better suggestions in this case, or some way to otherwise point new users in the right direction? Please note that I don't mean to pick on either qt or chromium maintainers here - they've all done what seems most logical from the standpoint of their own packages. However, it seems like the combination is not going to be nice on new users. It also seems like the current portage output is giving the user some contradictory and counterproductive advice. It seems like there are really only two possible choices 1. The user could choose to not install chromium. 2. The user could enable icu for qt-webkit. Doing anything else is just going to lead to some kind of cycle of errors until the user figures it out. Then they have to clear out who-knows-what from /etc/portage as they blindly followed instructions. Is there any way for portage to figure out that one of those is the eventual outcome, and then direct the user to the minimal changes to accomplish either? Rich 1 - https://bugs.gentoo.org/show_bug.cgi?id=425016
Re: [gentoo-dev] Portage Output / End User Experience
Rich Freeman wrote: It also seems like the current portage output is giving the user some contradictory and counterproductive advice. It seems like there are really only two possible choices 1. The user could choose to not install chromium. 2. The user could enable icu for qt-webkit. Do you get the same suggestions from portage if you attempt emerge kde and chromium one at a time? //Peter
Re: [gentoo-dev] Portage Output / End User Experience
On Mon, Jul 9, 2012 at 10:11 AM, Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: It also seems like the current portage output is giving the user some contradictory and counterproductive advice. It seems like there are really only two possible choices 1. The user could choose to not install chromium. 2. The user could enable icu for qt-webkit. Do you get the same suggestions from portage if you attempt emerge kde and chromium one at a time? I'll test it out on a fresh install, but that will take a number of hours (a total of 694 packages between them, which will take a while even on 4 cores, and warm up the office as well...). If I try to start out with chromium first the initial suggestion is to enable icu on libxml2, and if I try to start out with kde-meta the initial suggestion is to enable minizip on zlib (unrelated to this whole issue). I don't have a copy of the message but when I got the update to qt-webkit the message was fairly cryptic when it added the !icu? dependency on libxml2. If anything I think it was less clear. Let me give that upgrade a try both ways, but it might take a few days to have all the results of that. Rich
Re: [gentoo-dev] Portage Output / End User Experience
On Mon, Jul 9, 2012 at 10:56 AM, Rich Freeman ri...@gentoo.org wrote: On Mon, Jul 9, 2012 at 10:11 AM, Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: It also seems like the current portage output is giving the user some contradictory and counterproductive advice. It seems like there are really only two possible choices 1. The user could choose to not install chromium. 2. The user could enable icu for qt-webkit. Do you get the same suggestions from portage if you attempt emerge kde and chromium one at a time? I'll test it out on a fresh install, but that will take a number of hours (a total of 694 packages between them, which will take a while even on 4 cores, and warm up the office as well...). If I try to start out with chromium first the initial suggestion is to enable icu on libxml2, and if I try to start out with kde-meta the initial suggestion is to enable minizip on zlib (unrelated to this whole issue). I don't have a copy of the message but when I got the update to qt-webkit the message was fairly cryptic when it added the !icu? dependency on libxml2. If anything I think it was less clear. Let me give that upgrade a try both ways, but it might take a few days to have all the results of that. When tracking down why glibc updates were killing my systems, I wrote an install script to accelerate the install-update-fail-retry cycle. You may find it useful: https://github.com/mikemol/gentoo-install It shouldn't require *too* much modification to automate what you're trying to test. I intend to modify it to work in chroot environments, as a prelude to some build-related bug reports I'm sitting on. -- :wq
Re: [gentoo-dev] Portage Output / End User Experience
On Mon, Jul 9, 2012 at 11:04 AM, Michael Mol mike...@gmail.com wrote: It shouldn't require *too* much modification to automate what you're trying to test. I intend to modify it to work in chroot environments, as a prelude to some build-related bug reports I'm sitting on. Thanks - seems useful in general. Not sure I'll use it for this - a chroot should be adequate to test this (I don't intend to actually run KDE), and is much more efficient with CPU/RAM/etc. One thing I did set up for doing VM installs of Gentoo is a PXE enviornment that runs with an NFS root. I can stick stuff like stage3s and portage snapshots and template config files on that NFS root easily, and update it when necessary (though really the install image really only needs to be updated to address hardware, which isn't a big deal with VMs). It isn't anything too exciting, but maybe I should write up a howto - there may already be some Gentoo PXE guides already and any of those should basically work. Rich
Re: [gentoo-dev] Portage Output / End User Experience
On Mon, Jul 9, 2012 at 6:41 PM, Rich Freeman ri...@gentoo.org wrote: Thanks - seems useful in general. Not sure I'll use it for this - a chroot should be adequate to test this (I don't intend to actually run KDE), and is much more efficient with CPU/RAM/etc. Liberté Linux build scripts do a complete build-from-scratch in a chroot: https://github.com/mkdesu/liberte/blob/master/mkroot https://github.com/mkdesu/liberte/blob/master/src/root/setup build is the top-level script, mastering a read-only deployment image, but mkroot+setup suit the purpose of testing / deploying a fresh Gentoo build. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Last rites for net-ftp/netkit-tftp
El dom, 08-07-2012 a las 21:06 -0400, Anthony G. Basile escribió: On 07/08/2012 08:57 PM, Jeroen Roovers wrote: On Sun, 08 Jul 2012 23:29:35 +0200 Pacho Ramospa...@gentoo.org wrote: El dom, 08-07-2012 a las 21:49 +0200, Diego Elio Pettenò escribió: Il 08/07/2012 20:13, Chí-Thanh Christopher Nguyễn ha scritto: Please report a removal bug for this, so any issues concerning users of netkit-tftp can be tracked. Here it is: https://bugs.gentoo.org/show_bug.cgi?id=425362 And actually Robin K. who submitted the overflow bug I fixed, pointed out that there _are_ cases where hpa doesn't work but netkit does, so I've downgraded the removal to a simple masking for bad code. I guess we'll wait a bit more before removing this, in the mean time though I don't really feel happy with leaving it unmasked so it'll stay as it is. If its upstream is completely dead, it has bad code and it has a replacement, I would still go to treeclean it But if it provides the only means to netboot certain hardware, then you might think twice. jer I have several ubiquity routerstations (the hardware in questions) and I've asked Robin Kauffman to report the steps to reproduce in the bug. I'll try to get to the bottom of why tftp-hpa doesn't work. --Tony I thought it has a replacement, if not, ok to keep signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites for net-ftp/netkit-tftp
On Mon, Jul 9, 2012 at 10:34 PM, Pacho Ramos pa...@gentoo.org wrote: I thought it has a replacement, if not, ok to keep It has a replacement for probably 95% of its users; hopefully Robin and Anthony can figure out why those 5% (random number of course) is not able to use tftp-hpa; once we do that it should be safe to remove. I'll keep it monitored till then. And masked of course, as we don't want to risk issues, especially security issues, due to that.
Re: [gentoo-dev] euscan GSoC project - requesting feedback
On Monday 09 July 2012 23:41:06 you wrote: The main question is: what would you like to have on this dashboard? Currently (in the development version) there's the possibility to login and watch/unwatch packages/categories/herds/... and see the watched stuff in the account dashboard. We're planning on implementing a weekly(?) custom newsletter based on the packages you're watching, which features would you like? I talked with Federico on irc. I proposed to have an 'integration' between euscan and pybugz. In this manner everyone can file a version bump request via euscan. What do you think about? -- Agostino Sarubbo / ago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Output / End User Experience
On 07/09/2012 07:02 AM, Rich Freeman wrote: Is there any way for portage to figure out that one of those is the eventual outcome, and then direct the user to the minimal changes to accomplish either? You could try a larger emerge --backtrack setting. If it doesn't settle on a sensible solution, then it would be interesting to look at --debug output, to find out what has gone wrong. -- Thanks, Zac
Re: [gentoo-dev] Portage Output / End User Experience
On Mon, Jul 9, 2012 at 10:56 AM, Rich Freeman ri...@gentoo.org wrote: I'll test it out on a fresh install, but that will take a number of hours If I install chromium first, I get the following messages when I try to install kde-meta: The following USE changes are necessary to proceed: #required by dev-db/virtuoso-server-6.1.4-r1, required by dev-libs/soprano-2.7.6[virtuoso], required by app-office/akonadi-server-1.7.2, required by kde-base/kdepim-runtime-4.8.3-r2, required by kde-base/kdepim-meta-4.8.3, required by kde-base/kde-meta-4.8.3[semantic-desktop], required by kde-meta (argument) =sys-libs/zlib-1.2.5.1-r2 minizip #required by x11-libs/qt-webkit-4.8.2[gstreamer], required by kde-base/kdebase-menu-icons-4.8.3, required by kde-base/kdebase-runtime-meta-4.8.3, required by kde-base/kdebase-startkde-4.8.3, required by kde-base/kdebase-meta-4.8.3, required by kde-base/kde-meta-4.8.3, required by kde-meta (argument) =dev-libs/libxml2-2.8.0_rc1 -icu You'll note that in this case there is nothing to suggest simply enabling icu for qt-webkit. If I emerge kde-meta first then I get the following when I try to emerge chromium: The following USE changes are necessary to proceed: #required by www-client/chromium-20.0.1132.43, required by chromium (argument) =dev-libs/libxml2-2.8.0_rc1 icu Then if I set the icu use flag on libxml2 it works. Apparently it doesn't realize that I'm about to break qt-webkit. Portage doesn't check use dependencies on existing packages when you go to rebuild something? I hope that helps... Rich
Re: [gentoo-dev] Portage Output / End User Experience
On 07/09/2012 05:42 PM, Rich Freeman wrote: On Mon, Jul 9, 2012 at 10:56 AM, Rich Freeman ri...@gentoo.org wrote: I'll test it out on a fresh install, but that will take a number of hours If I install chromium first, I get the following messages when I try to install kde-meta: The following USE changes are necessary to proceed: #required by dev-db/virtuoso-server-6.1.4-r1, required by dev-libs/soprano-2.7.6[virtuoso], required by app-office/akonadi-server-1.7.2, required by kde-base/kdepim-runtime-4.8.3-r2, required by kde-base/kdepim-meta-4.8.3, required by kde-base/kde-meta-4.8.3[semantic-desktop], required by kde-meta (argument) =sys-libs/zlib-1.2.5.1-r2 minizip #required by x11-libs/qt-webkit-4.8.2[gstreamer], required by kde-base/kdebase-menu-icons-4.8.3, required by kde-base/kdebase-runtime-meta-4.8.3, required by kde-base/kdebase-startkde-4.8.3, required by kde-base/kdebase-meta-4.8.3, required by kde-base/kde-meta-4.8.3, required by kde-meta (argument) =dev-libs/libxml2-2.8.0_rc1 -icu You'll note that in this case there is nothing to suggest simply enabling icu for qt-webkit. If I emerge kde-meta first then I get the following when I try to emerge chromium: The following USE changes are necessary to proceed: #required by www-client/chromium-20.0.1132.43, required by chromium (argument) =dev-libs/libxml2-2.8.0_rc1 icu Then if I set the icu use flag on libxml2 it works. Apparently it doesn't realize that I'm about to break qt-webkit. Portage doesn't check use dependencies on existing packages when you go to rebuild something? Not unless the --complete-graph option is enabled. What I'd like to do is to automatically enable --complete-graph mode whenever the USE of an installed package would change. It would be like that --complete-graph-if-new-ver option which is already enabled by default, but it would apply to USE instead of versions. -- Thanks, Zac
Re: [gentoo-dev] Portage Output / End User Experience
On 07/09/2012 05:58 PM, Zac Medico wrote: On 07/09/2012 05:42 PM, Rich Freeman wrote: On Mon, Jul 9, 2012 at 10:56 AM, Rich Freeman ri...@gentoo.org wrote: I'll test it out on a fresh install, but that will take a number of hours If I install chromium first, I get the following messages when I try to install kde-meta: The following USE changes are necessary to proceed: #required by dev-db/virtuoso-server-6.1.4-r1, required by dev-libs/soprano-2.7.6[virtuoso], required by app-office/akonadi-server-1.7.2, required by kde-base/kdepim-runtime-4.8.3-r2, required by kde-base/kdepim-meta-4.8.3, required by kde-base/kde-meta-4.8.3[semantic-desktop], required by kde-meta (argument) =sys-libs/zlib-1.2.5.1-r2 minizip #required by x11-libs/qt-webkit-4.8.2[gstreamer], required by kde-base/kdebase-menu-icons-4.8.3, required by kde-base/kdebase-runtime-meta-4.8.3, required by kde-base/kdebase-startkde-4.8.3, required by kde-base/kdebase-meta-4.8.3, required by kde-base/kde-meta-4.8.3, required by kde-meta (argument) =dev-libs/libxml2-2.8.0_rc1 -icu You'll note that in this case there is nothing to suggest simply enabling icu for qt-webkit. If I emerge kde-meta first then I get the following when I try to emerge chromium: The following USE changes are necessary to proceed: #required by www-client/chromium-20.0.1132.43, required by chromium (argument) =dev-libs/libxml2-2.8.0_rc1 icu Then if I set the icu use flag on libxml2 it works. Apparently it doesn't realize that I'm about to break qt-webkit. Portage doesn't check use dependencies on existing packages when you go to rebuild something? Not unless the --complete-graph option is enabled. What I'd like to do is to automatically enable --complete-graph mode whenever the USE of an installed package would change. It would be like that --complete-graph-if-new-ver option which is already enabled by default, but it would apply to USE instead of versions. Bug filed: https://bugs.gentoo.org/show_bug.cgi?id=425558 -- Thanks, Zac
Re: [gentoo-dev] Portage Output / End User Experience
On Mon, Jul 9, 2012 at 8:58 PM, Zac Medico zmed...@gentoo.org wrote: Not unless the --complete-graph option is enabled. What I'd like to do is to automatically enable --complete-graph mode whenever the USE of an installed package would change. It would be like that --complete-graph-if-new-ver option which is already enabled by default, but it would apply to USE instead of versions. Ok, with this additional option, if I start with chromium and try to install kde-meta it still suggests unsetting icu, which is going to lead to future errors (or breaking chromium). If I start with kde-meta and try to install chromium the conflict is detected, but it does not suggest setting icu on qt-webkit: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-libs/libxml2:2 (dev-libs/libxml2-2.8.0_rc1::gentoo, installed) pulled in by dev-libs/libxml2:2[!icu?] required by (x11-libs/qt-webkit-4.8.2::gentoo, installed) (dev-libs/libxml2-2.8.0_rc1::gentoo, ebuild scheduled for merge) pulled in by dev-libs/libxml2[icu] required by (www-client/chromium-20.0.1132.43::gentoo, ebuild scheduled for merge) So, seems like there is still room for improvement... Rich
Re: [gentoo-dev] euscan GSoC project - requesting feedback
On Tue, 10 Jul 2012 00:04:15 +0200 Agostino Sarubbo a...@gentoo.org wrote: I proposed to have an 'integration' between euscan and pybugz. Sounds superficially like a giant security hole / spam gateway. What kind of integration are we talking about? In this manner everyone can file a version bump request via euscan. What do you think about? If the false positives go down significantly, we wouldn't need interested users to report version bumps - you could automate that all the way, and publish links to the bugs already reported. But couldn't we more simply and securely implement publishing a hyperlink from euscan's pages to the bugs.g.o form that fills out some of the required information in advance? That way it's everybody's personal bugzilla accounts that are responsible for the spam, and we might more easily find duplicates. Speaking of duplicates, the way subsequent version bump requests for subsequent versions (in different SLOTs, mind you) are usually treated now is that the later bugs are marked as duplicates of the former and that the former bug's Summary is updated to show the currently best version(s). If we're going to stick to that, we *definitely* need a way to catch out duplicates. jer
Re: [gentoo-dev] euscan GSoC project - requesting feedback
On 10 July 2012 13:28, Jeroen Roovers j...@gentoo.org wrote: On Tue, 10 Jul 2012 00:04:15 +0200 Agostino Sarubbo a...@gentoo.org wrote: I proposed to have an 'integration' between euscan and pybugz. Sounds superficially like a giant security hole / spam gateway. What kind of integration are we talking about? In this manner everyone can file a version bump request via euscan. What do you think about? If the false positives go down significantly, we wouldn't need interested users to report version bumps - you could automate that all the way, and publish links to the bugs already reported. But couldn't we more simply and securely implement publishing a hyperlink from euscan's pages to the bugs.g.o form that fills out some of the required information in advance? That way it's everybody's personal bugzilla accounts that are responsible for the spam, and we might more easily find duplicates. Speaking of duplicates, the way subsequent version bump requests for subsequent versions (in different SLOTs, mind you) are usually treated now is that the later bugs are marked as duplicates of the former and that the former bug's Summary is updated to show the currently best version(s). If we're going to stick to that, we *definitely* need a way to catch out duplicates. This is verging on that oft requested thing that Gentoo could do with, a sort of task queue for regular and repeated tasks that can be described in one line and aren't worthy of a full bug. ie: Version Bumps, stabilisation requests, generic repeated transformations ( ie: make the metadata better, etc ) Things that if they really needed a full blown bug could be cross-linked with bugzilla, but wouldn't need be the default option. Though, thats really an entirely different discussion, I'm just teasing the subject so ideas brew and the discussion eventually turns up. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Output / End User Experience
On 07/09/2012 06:11 PM, Rich Freeman wrote: On Mon, Jul 9, 2012 at 8:58 PM, Zac Medico zmed...@gentoo.org wrote: Not unless the --complete-graph option is enabled. What I'd like to do is to automatically enable --complete-graph mode whenever the USE of an installed package would change. It would be like that --complete-graph-if-new-ver option which is already enabled by default, but it would apply to USE instead of versions. Ok, with this additional option, if I start with chromium and try to install kde-meta it still suggests unsetting icu, which is going to lead to future errors (or breaking chromium). If I start with kde-meta and try to install chromium the conflict is detected, but it does not suggest setting icu on qt-webkit: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-libs/libxml2:2 (dev-libs/libxml2-2.8.0_rc1::gentoo, installed) pulled in by dev-libs/libxml2:2[!icu?] required by (x11-libs/qt-webkit-4.8.2::gentoo, installed) (dev-libs/libxml2-2.8.0_rc1::gentoo, ebuild scheduled for merge) pulled in by dev-libs/libxml2[icu] required by (www-client/chromium-20.0.1132.43::gentoo, ebuild scheduled for merge) So, seems like there is still room for improvement... Aside from the obvious need to improve the portage behavior, we might also want to consider enabling USE=icu by default in the profile. -- Thanks, Zac
Re: [gentoo-dev] Portage Output / End User Experience
On Mon, 2012-07-09 at 10:56 -0400, Rich Freeman wrote: On Mon, Jul 9, 2012 at 10:11 AM, Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: I don't have a copy of the message but when I got the update to qt-webkit the message was fairly cryptic when it added the !icu? dependency on libxml2. If anything I think it was less clear. Rich There have already been users on the forums with that very confusion of what to do with the cryptic [!icu?]. And there are currently many forum threads involving the icu use flag, qt-webkit,... -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Portage Output / End User Experience
On Mon, Jul 9, 2012 at 10:22 PM, Brian Dolbec dol...@gentoo.org wrote: There have already been users on the forums with that very confusion of what to do with the cryptic [!icu?]. And there are currently many forum threads involving the icu use flag, qt-webkit,... Yup, this issue hit anybody who has qt-webkit and chromium installed. I wouldn't be surprised if that is half of the entire userbase. We ran into another confusing icu-related issue with qt-core a few weeks ago (bug 413541). I can understand that the qt maintainers want to get away from enabling icu for this reason, but chromium is a VERY popular package so it is really only disabled in the sense that it annoys a bazillion people who have to un-disable it and then still run into the problems. Better portage logic might help here, but I think we need to consider whether a non-optimal decision from a single package perspective is going to lead to a better overall experience for our userbase. Zac suggested adding icu to the profile, which would work, though really just adding it as the default for these two packages would really address the issue until portage can catch up. Those who REALLY don't want icu support in qt-webkit can always disable it manually now that the flag is there. If there is a fear that this default will lead to more bugs, those bugs will happen anyway, since anybody running chromium has to enable that flag. Rich
