Re: [gentoo-dev] Packages up for grabs
On Thu, Jan 3, 2013 at 12:57 AM, Panagiotis Christopoulos pchr...@gentoo.org wrote: On 22:52 Thu 20 Dec , Pacho Ramos wrote: Due araujo no longer taking care of them: dev-lang/gnu-smalltalk ... I'm taking this one. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) o_O xD -- Alex http://www.linuxized.com
Re: [gentoo-dev] GCC 4.7 unmasking
On 25 Feb 2013 06:53, Ryan Hill dirtye...@gentoo.org wrote: I'm going to be unmasking 4.7.2 later this week. There are still 47 open bugs blocking the 4.7 tracker, so if any are yours now would be a good time to take a look at them. https://bugs.gentoo.org/390247 Can't you just smell all those Gentoo systems gearing up for long emerge -e sessions? xD Thanks for working on this. Alex | wired
Re: [gentoo-dev] Draft news item: preserve-libs default for portage-2.1.12
On Sun, Jun 02, 2013 at 05:41:21PM -0700, Zac Medico wrote: Please review the attached news item which announces the preserve-libs default for portage-2.1.12. Note that our council has discussed this change in their 2013-05-14 meeting [1], and they were in favor of allowing it. [1] http://thread.gmane.org/gmane.linux.gentoo.project/2448/focus=2452 -- Thanks, Zac Title: Portage preserve-libs default Author: Zac Medico zmed...@gentoo.org Content-Type: text/plain Posted: 2012-06-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =sys-apps/portage-2.1.12 Beginning with sys-apps/portage-2.1.12, FEATURES=preserve-libs is enabled by default. This feature will preserve libraries when the sonames change during upgrade or downgrade. Libraries are preserved only if consumers of those libraries are detected. Preserved libraries are automatically removed when there are no remaining consumers. Run `emerge @preserved-rebuild` in order to rebuild all consumers of preserved libraries. If you would like to disable this behavior by default, then set FEATURES=-preserve-libs in make.conf. See the make.conf(5) man page for more information about this feature. Looks good. Perhaps you'd like to add that this replaces revdep-rebuild in case it's not obvious to some users. By the way: Wh h xD I almost believed this would never happen. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com signature.asc Description: Digital signature
[gentoo-dev] revbumping ebuilds after USE dependency changes
Hello, Please revbump an ebuild after changing its USE dependencies. Using net-p2p/transmission as an example, it used to depend on dev-qt/qtgui:4=[dbus] however, qtgui lost the dbus useflag, so the dependency was changed to dev-qt/qtgui:4=[dbus(+)] without revbumping the transmission ebuild. [0] Portage fails to notice this when resolving dependencies if the package was installed prior to the change, resulting in errors like the following: (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts with dev-qt/qtgui:4/4=[dbus] required by (net-p2p/transmission-2.80::gentoo, installed) which, I imagine, could be very frustrating for a user who doesn't mess with the internals of Gentoo often. You might think that such a revbump is overkill, but in reality the user will have to re-emerge the package anyway in order to get rid of the error, so there is no point in avoiding it, unless portage changes the way it handles these changes. [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1r2=1.2 Thanks, -- Alex Alexander | wired@gentoo + www.linuxized.com ++ www.leetworks.com signature.asc Description: Digital signature
Re: [gentoo-dev] revbumping ebuilds after USE dependency changes
On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote: On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander wi...@gentoo.org wrote: Hello, Please revbump an ebuild after changing its USE dependencies. Using net-p2p/transmission as an example, it used to depend on dev-qt/qtgui:4=[dbus] however, qtgui lost the dbus useflag, so the dependency was changed to dev-qt/qtgui:4=[dbus(+)] without revbumping the transmission ebuild. [0] Portage fails to notice this when resolving dependencies if the package was installed prior to the change, resulting in errors like the following: (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts with dev-qt/qtgui:4/4=[dbus] required by (net-p2p/transmission-2.80::gentoo, installed) which, I imagine, could be very frustrating for a user who doesn't mess with the internals of Gentoo often. You might think that such a revbump is overkill, but in reality the user will have to re-emerge the package anyway in order to get rid of the error, so there is no point in avoiding it, unless portage changes the way it handles these changes. [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1r2=1.2 Actually, Portage normally handles this situation gracefully by using the dependencies from the portage tree instead of vdb. However, in the case of a slot-operator dep, it always uses vdb. See bug 477544. https://bugs.gentoo.org/show_bug.cgi?id=477544 Aha, thanks for the bug, missed it. Well, my recommendation is still valid until portage gets fixed. Glad to know someone's looking into it though. -- Alex Alexander | wired@gentoo + www.linuxized.com ++ www.leetworks.com signature.asc Description: Digital signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer patr...@gentoo.org wrote: On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote: On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: Greetings, Gnome Herd decided to target stablilization of 3.8 [1] which requires systemd. What are the reasons to stable 3.8 and not 3.6, a version w/o this restriction, enabling all non systemd users to profit from this eye-candy as well. I raise the freedom of choice card here. And deliberately choosing an uncooperative version doesn't shine a good light. Facts, pls! Michael [1] https://bugs.gentoo.org/show_bug.cgi?id=478252 To stabilize gnome-3.6, we would need 1. one or (preferably) two *active* gentoo developers; 2. who are familiar with gnome's internals and are able to backport bugfixes from 3.8/3.10 without support from upstream developers; and 3. who volunteer to run openrc+gnome-3.6 for a long time on their main machines so that they can give a stable 3.6 the support that the word 'stable' implies. We do not have such people on the gnome team. Seeing the noise in #gentoo from people getting whacked in the kidney by the systemd sidegrade ... that's a very optimistic decision. It'll cause lots of pain for users that suddenly can't start lvm properly and other nasty landmines hidden in the upgrade path. By stabilizing this early you're causing lots of extra work for others. I hope you understand that some of us will be very rude and just suggest to unmerge gnome on all support requests as it now moves outside our support range ... Have a nice day, Patrick Although I understand your frustration, I don't see any other options for the Gentoo gnome team. People who don't like this should take their complaints upstream. -- Alex Alexander + wired + www.linuxized.com + www.leetworks.com
[gentoo-dev] gentoo KVM images now available :)
Hello :) I've created some KVM images to aid Gentoo Developers and the KDE herd in ebuild development and maintainance. Two images are currently available: [1] an X-less ~x86 with various tools preinstalled [like layman] and a copy of the first ~x86 with kdebase-meta[kdeprefix] and a few other packages installed on top of it The portage tree is in a separate image, along with binary packages of most stuff installed in the two images. (a bz2 of the tree is in /usr just in case) The images are available at dev.gentooexperimental.org [1]. Please read the README [2] for instructions and more information :) An image with -kdeprefix kde is also en route. I would really appreciate feedback on the images: * things you liked * things missing * things you'd do differently either through these mailing lists or in freenode/#gentoo-kde so I can make future revisions better and more useful! Regards, Alex Alexander (wired) Gentoo KDE Team Herd Tester [1] http://dev.gentooexperimental.org/~wired/kvm/ [2] http://dev.gentooexperimental.org/~wired/kvm/README.txt signature.asc Description: OpenPGP digital signature
[gentoo-dev] blocking mixed versions of split QT libraries
QT doesn't work well when mixed versions of its core libraries are
installed. Usually an emerge -avDu world solves the problem, but some
users tend to avoid this.
For example, lets say you have parts of QT 4.4.2 on your system. QT
4.5.1 is available and a user decides to manually update qt-core, or
to install KDE which has a QT dependency on a QT library not
installed. In these cases, portage will update only a part of the
installed QT libraries, leaving the system in a mixed state.
QT based apps don't like that. Others will refuse to build, others
will fail to run.
We've managed to experimentally block partial QT upgrades by adding an
RDEPEND to all QT libraries [1] in qting-edge overlay. Portage
understands this and throws out B blocks if you try to change versions
only in parts of QT, but upgrades/downgrades fine if you do them all
at once (or use -Du world).
This fix also catches stale QT libraries that nothing depends on
anymore because the user has removed whatever required them (and never
ran --depclean).
Unfortunately we've got reports from paludis users stating that they
can't update QT from qting-edge anymore.
What I'd like to discuss is the following:
1) Is there a saner way to achieve our goal of doing whatever is
possible to avoid mixed QT versions?
2) Is our implementation considered correct and acceptable by the PMS guys?
3) Whats the general Gentoo Policy on mixed versions? Do we care, or
is our policy please -Du world?
We've also managed to achieve the same thing by adding PDEPENDs to
each QT library for any other QT libraries that depend on it:
i.e. if qt-xmlpatterns depends on qt-gui, we add the following to qt-gui:
PDEPEND=
|| ( !x11-libs/qt-xmlpatterns ~x11-libs/qt-xmlpatterns-${PV} )
the above (expanded for all libraries) has the same effect as the [1]
RDEPEND but looks a bit more hackish.
thanks
[1] lines 30-59
http://github.com/gentoo-qt/qting-edge/blob/master/eclass/qt4-build-edge.eclass
--
Alex Alexander || wired
Gentoo QT KDE Herd Tester
http://www.linuxized.com
Re: [gentoo-dev] blocking mixed versions of split QT libraries
From what I understand you are utilizing portages ability to
automagically resolve blockers when all blockers will be resolved within
the current command. Agree?? or is it the fact that you are doing
!x11-libs/qt-assistant-${PV}-r that is causing the paludis problem?
Yes, portage's auto-resolving ability thats exactly what we're using
to make this happen.
I would suggest that you just tell paludis users to use --dl-blocks
discard when updating qt. After looking at the eclass im not sure
whether it will work or not. im assuming that discarding blocks will
just ignore everything, but I haven't tested it so can't be sure.
Well since there's no other obvious way to achieve the whole thing,
this seems like the only option for paludis users for now. If it
works.
1) Is there a saner way to achieve our goal of doing whatever is
possible to avoid mixed QT versions?
I don't believe so, not within current ways of declaring dependencies.
maybe the PMS guys could implement something... :D
2) Is our implementation considered correct and acceptable by the PMS guys?
3) Whats the general Gentoo Policy on mixed versions? Do we care, or
is our policy please -Du world?
I say we should be stopping them from happening.
Good work btw.
Thank you for your thoughts
--
Alex Alexander || wired
Gentoo QT KDE Herd Tester
http://www.linuxized.com
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, May 18, 2009 at 17:21, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
Not really. There's no particularly good mechanism for ensuring equal
versions of things where not everything has to be installed. The best
option I can think of is to have a meta package called, say, split-qt,
and to do all your external (not inter-qt-library) dependencies as:
x11-libs/split-qt[gui][xmlpatterns]
and then have x11-libs/split-qt's deps be like:
gui? ( ~x11-libs/qt-gui-${PV} )
how would that solve a user's emerge -av1 qt-core when a new Qt
version becomes available?
--
Alex Alexander || wired
Gentoo QT KDE Herd Tester
http://www.linuxized.com
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, May 18, 2009 at 19:51, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: It wouldn't, although it would be fixed as soon as someone tried to install a package with a Qt dep. Dependencies the way they are now aren't really expressive enough to handle what you're after -- split packages are considered unrelated. so the RDEPEND in qting-edge seems to be the only working solution for now... is paludis expected to behave like portage in the near future regarding these blocks? are there any plans to add support for these kinds of cases in the PMS? other sets of packages could probably benefit from such a feature as well. thanks -- Alex Alexander || wired Gentoo QT KDE Herd Tester http://www.linuxized.com
Re: [gentoo-dev] New 10.0 profiles are in repository
On Thu, Aug 6, 2009 at 22:17, Zac Medicozmed...@gentoo.org wrote: It would be pretty trivial to use a PORTAGE_PROFILES variable in make.conf, to replace /etc/make.profile. You could do something like this: PORTAGE_PROFILES=/usr/portage/profiles/desktop /usr/portage/profiles/gnome You could use this approach to pull in profiles from overlays too if desired. This looks pretty neat. Many (new) users who ignore or are ignorant of profiles could benefit by it, since they'll (have to) look at it when they first open the default /etc/make.conf -- Thanks, Zac -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] Re: Devaway for me, for a whole year period(military service)
On Tue, Aug 11, 2009 at 20:32, Markos Chandrashwoar...@gentoo.org wrote: Now, it is my time to say goodbye ( but not forever ) . I am *forced* to join the greek army from 16/8/2009 until May 2010. So I wont be active during this period. When I come back, I expect a more shiny Gentoo which will provide great experiences to our users. So long people. It was a pleasure to work with you so far. See you in May :) -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] Web: http://hwoarang.silverarrow.org 9+ months of pure slacking eh :p Try to hang in there and come back in one piece! Καλό κουράγιο μεγάλε ;) -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] 2009.0 profiles
On Sat, Aug 29, 2009 at 00:23, Mike Frysingervap...@gentoo.org wrote: On Friday 28 August 2009 16:27:18 Sebastian Pipping wrote: Mike Frysinger wrote: 10.0 is retarded How would you like the problem to be addressed? we already have a simple logical version system. 2009.0 is the next step. -mike Years do not make a good versioning scheme, if one release gets out late you're automatically considered outdated by users. I think 10.0 is cool :) -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] Stabilization of Python 3.1
*On Sat, Sep 19, 2009 at 23:21, Robert Bridge rob...@robbieab.com wrote: So the question isn't SHOULD python-3 be stabilised, it's what will break if it is surely? There seems to be a misunderstanding on what will happen if/when python 3 gets stabilized. The short answer is... *drum roll*... nothing :) I'm guessing that the idea of getting python 3 stable is to allow people interested in using it to do so easily. We're talking about the stabilization of python 3, NOT switching portage or your system to it. Python 2.6 will continue to be the user's default python even after he installs version 3. In fact, if you're using ~testing you should have it already and your system is probably still working OK :) Now.. if a user decides to switch his system *manually* to python 3 without thinking... he's asking for it :) -- Alex || wired Gentoo Dev www.linuxized.com
[gentoo-dev] rfc: Qt version 4.5.2 news item
We're planning on stablereq'ing Qt 4.5.2 (really) soon, so I've written this news item to cover default USE flag changes that could confuse users :) Please review, thanks: Title: Qt 4.5.2 default USE flag changes Author: Alex Alexander wi...@gentoo.org Content-Type: text/plain Posted: 2009-09-23 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: x11-libs/qt-core-4.5.2 Qt version 4.5.2 has significant changes in the USE flags enabled by default. When upgrading, make sure you check and re-enable any USE flags you need. Depending on your system and installed packages, you might hit an issue where portage is getting confused by this USE flag change, trying to mix old 4.5.1 ebuilds with new 4.5.2 ones, resulting in blocks. If this happens to you, please add the offending USE flags (usually 'qt3support' and 'dbus') in your USE= or switch to a desktop profile (eselect profile list). Check this post [0] for more details on this issue. [0] http://www.linuxized.com/p192 -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] rfc: Qt version 4.5.2 news item
On Wed, Sep 23, 2009 at 10:16, Ulrich Mueller u...@gentoo.org wrote: GLEP 42 says that you should wrap lines at 72 columns. Ulrich Correct, I was sure I'd miss something. Thanks :) Title: Qt 4.5.2 default USE flag changes Author: Alex Alexander wi...@gentoo.org Content-Type: text/plain Posted: 2009-09-23 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: x11-libs/qt-core-4.5.2 Qt version 4.5.2 has significant changes in the USE flags enabled by default. When upgrading, make sure you check and re-enable any USE flags you need. Depending on your system and installed packages, you might hit an issue where Portage is getting confused by this USE flag change, trying to mix old 4.5.1 ebuilds with new 4.5.2 ones, resulting in blocks. If this happens to you, please add the offending USE flags (usually 'qt3support' and 'dbus') in your USE= or switch to a desktop profile (eselect profile list). Check this post [0] for more details on this issue. [0] http://www.linuxized.com/p192 -- Alex || wired Gentoo Dev www.linuxized.com
[gentoo-dev] 2nd KDE (mini) Meeting - September 2009
Hey, The KDE Team will have a supplemental September meeting tomorrow to discuss the state of KDE 4.3.1 and Qt 4.5 / gcc 4.4, as agreed in the previous meeting. Date: Thursday, 2009/09/24 Time: 1900 UTC Channel: #gentoo-meetings Topics: - KDE 4.3.1 state: bugs, stabilization - Qt 4.5.x and gcc 4.4 see ya there :) -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] rfc: Qt version 4.5.2 news item
On Wed, Sep 23, 2009 at 10:35, Alex Alexander wi...@gentoo.org wrote: Title: Qt 4.5.2 default USE flag changes Author: Alex Alexander wi...@gentoo.org committed, thanks :) -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] Anyone intrested in maintaining Midnight Commander?
On Fri, Oct 2, 2009 at 21:57, Samuli Suominen ssuomi...@gentoo.org wrote: The latest version is now patch free, 4.7.0_pre3, and there's only 1 bug open. So I'm basically done with it. If any of you actually use it, feel free to substitute me from the metadata.xml, I just picked it up because nobody else did. Thanks, Samuli /me uses it I'll take it off your hands, thanks for taking care of it for so long. -- Alex || wired
Re: [gentoo-dev] Updated handbooks for autobuilds
On Sun, Oct 4, 2009 at 21:42, Joshua Saddler nightmo...@gentoo.org wrote: There. I did the x86 and amd64 handbooks (networked, anyway; who cares about networkless). They're now ready for the 10th anniversary. I'm pretty sure. I also did the x86 quickinstall handbooks. Thanks Joshua! -- Alex || wired
Re: [gentoo-dev] gentoo-news repository
On Thu, Oct 8, 2009 at 12:08, Ulrich Mueller u...@gentoo.org wrote: Opinions? Sounds good, although it could get a bit crowded if we remove /, unless we remove really old items (like = 2 years old). -- Alex || wired
Re: [gentoo-dev] gentoo-news repository
On Thu, Oct 8, 2009 at 14:07, Markos Chandras hwoar...@gentoo.org wrote: Crowded? I don't think so :) The number of news items is quite small, so I think we can afford having them all in the same folder I'm assuming devs will eventually pick this feature up and use it more often :) But yeah, as long as someone cleans up *really* old items, it shouldn't be a problem. -- Alex || wired
[gentoo-dev] KDE Team Meeting - October 2009
Greetings, The KDE Team will have its usual monthly meeting this Thursday. Date: Thursday, 2009/10/22 Time: 1900 UTC Channel: #gentoo-meetings Late announcement, I know, but I guess better late than never :) Reply to this email with anything you'd like to have discussed at the meeting. Everyone should be there so we can celebrate having KDE 4 stable! Thanks, -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Mon, Oct 26, 2009 at 21:42, Zeerak Waseem zeera...@gmail.com wrote: having to choose a profile, gives less time for the wavering user Why all the fuss? No-one said we're removing the plain desktop profile, we're simply adding *more* options. If you want generic DE options pre-enabled, choose the desktop profile. If you *know* you only need KDE as your DE, choose KDE, If you *know* you only need GNOME as your DE, choose GNOME, If you need both or can't decide, either choose Desktop and add the USE flags yourself or use both profiles together. Beats enabling default USE flags without asking you :) -- Alex || wired Gentoo Dev www.linuxized.com
[gentoo-dev] Re: KDE Team meeting November 2009
On Sun, Nov 15, 2009 at 03:26:24PM +0100, Tomáš Chvátal wrote: Hi, This months meeting will be held as usual so i am anouncing it in advance so we discuss and prepare on the topics. As a sidenote: since Qt team is leaving us kde to their own project space this meetings from now on will be focused only on kde relevant matters. Just wanted to add that although Qt has its own project now, we don't want to break up the fine meetings we've been having so far. So we'd like to continue having common meetings for the time being :) Things we have on Qt agenda for now: * Proposition to return to monolithic Qt ebuilds In last meeting we decided to continue this discussion in ML. We should revisit the subject in this meeting, especially now that one of the major issues is gone with the removal of old Qt versions. * Status of new qt-tng.eclass * #gentoo-qt - its there, do we want to use it? Thanks, -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpIsxqWkw99o.pgp Description: PGP signature
Re: [gentoo-dev] metdata.dtd should require herd/
On Tue, Dec 15, 2009 at 06:19:00PM +0300, Peter Volkov wrote: So what we will do with this? It'll be great to fix dtd to follow our requirements, but there is a problem: if we change dtd like this: !ELEMENT pkgmetadata ( herd+, (maintainer|longdescription|use|upstream)* ) we will force all metadata.xml files have strict order of tags: first herd/ then other tags. Currently there are about 200 ebuilds with different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 . Forced ordering looks fine to me... we could announce the change, let devs fix their metadata during a short period of time (say, 2 weeks), then force-fix the ones left (200 is a small number) and apply the dtd fix. -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpa6qfA2bTVF.pgp Description: PGP signature
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] Re: [rfc] layman storage location (again)
On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote: I sometimes think the main problem is the tree itself. Portage really should had a directory of its own, but maybe with anoher structure, like /var/portage, /var/portage/tree (the current PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree itself), /var/portage/overlays/layman or /var/portage/layman. I of course realize that change the structure of the whole portdir would had inresting complications, so take this comment just as serious as you like. But overlays really was an afterthought? I like this suggestion, it certainly makes the whole folder structure cleaner. If we're going to fix stuff, lets do it properly once and for all. Some compatibility code that checks and uses the old default locations while printing out warnings would help existing users with the transition without breaking current systems. Users with custom PORTDIR and friends could be notified through a news item. /var/portage/ /var/portage/tree /var/portage/layman /var/portage/overlays (non-layman managed, layman could also be in here) /var/portage/distfiles /var/portage/packages or %s/var/usr/ -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpC37DfrQPPw.pgp Description: PGP signature
[gentoo-dev] an update script for the gentoo developer
Hello fellow devs,
I've created a script to help me keep my tree/overlays up-to-date,
automatically regenerate metadata, update eix, etc.
It's not anything too sophisticated, but it works for me, so I thought
I'd share it with you guys.
An updated version of the script is available at my gentoo devspace:
http://dev.gentoo.org/~wired/scripts/update
./update -h gives you all available options
edit the script to set the defaults to your liking.
the script expects the following directory structure:
${DATA_DIR}/
main/
gentoo-x86/
gentoo/ (optional)
gentoo-news/ (optional)
overlays/
{various overlays}
overlays_disabled/
{overlays not used}
make.conf
autogenerated, holds active overlay list
imported in /etc/make.conf
${SCRIPT_OUTPUT}
if called with -c, all output goes here
the make.conf is sourced in /etc/make.conf and is generated each time
the overlays/ folder gets updated.
the script is constantly improved and I keep the online version
up-to-date. there are some options that diff/fetch the latest version
for you automatically.
I'll probably add a --sync option soon to make it useful on
systems without a CVS checkout.
hopefully some of you will find it useful.
patches and feedback always welcome :)
--
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com
pgp4UPO4oVOmv.pgp
Description: PGP signature
Re: [gentoo-dev] New category for version control
On Thu, Mar 04, 2010 at 10:32:47AM +0100, Ulrich Mueller wrote: On Thu, 4 Mar 2010, Christian Faulhammer wrote: My proposal would be to call it dev-scm and put all version controls, direct frontends, plugins and the like into that. Better call it dev-vcs to avoid confusion with both the Scheme language and with software configuration management. Nice idea, +1. I too prefer dev-vcs as the category name. -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgphqAM5dBleT.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events
On Wed, Mar 10, 2010 at 07:45:21AM -0500, Mike Frysinger wrote: the front page of http://gentoo.org/ now links to a Google Calendar (see side bar). this has been around for a while, but it seems it's been more of an underground thing, so it's time to raise its awareness. like other aspects of Gentoo, all Gentoo developers have access to it to add their own events. anything Gentoo related may be added of course ! meetings, events, scheduled package events, etc... the access step requires a bit of help though -- simply e-mail me off list your gmail account and we can get you set up. once you have access, you may easily pass it on to other Gentoo peeps. -mike excellent idea! thanks for taking the time to do this :) i've added my gentoo email to my personal google account so you should be able to add me using that, could you try? thanks, -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgp0zEFpLLvJM.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events
On Wed, Mar 10, 2010 at 08:18:11AM -0500, Mike Frysinger wrote: On Wednesday 10 March 2010 07:56:42 Alex Alexander wrote: On Wed, Mar 10, 2010 at 07:45:21AM -0500, Mike Frysinger wrote: the front page of http://gentoo.org/ now links to a Google Calendar (see side bar). this has been around for a while, but it seems it's been more of an underground thing, so it's time to raise its awareness. like other aspects of Gentoo, all Gentoo developers have access to it to add their own events. anything Gentoo related may be added of course ! meetings, events, scheduled package events, etc... the access step requires a bit of help though -- simply e-mail me off list your gmail account and we can get you set up. once you have access, you may easily pass it on to other Gentoo peeps. excellent idea! thanks for taking the time to do this :) sorry, i didnt mean to make it sound like this was my idea ... Diego put it together originally and it's slowly grown since i've added my gentoo email to my personal google account so you should be able to add me using that, could you try? google didnt warn when i added, so presumably it worked -mike it did, thanks -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpXOawPoPzEV.pgp Description: PGP signature
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On Thu, Mar 18, 2010 at 06:29:56PM +0200, Markos Chandras wrote: Dear fellow developers, A new project is about to start so I am requesting your feedback The primary goal of the Proxy Maintainers[1] project is to create and maintain relationships between developers and users in order to ensure packages in the Gentoo tree stay up to date. This involves a few main tasks: [...] 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in Gentoo bugzilla?I think the latter is the best IMO, the best route would be to start with-in Gentoo Bugs, then slowly move each contributor to a proxy-maintainer overlay. This overlay would not have a review process for ebuilds, meaning that every contributor that has passed the first stage (by submitting a few ebuilds in bugzilla) will be granted access. that way users will: * get experience on actually committing stuff to a tree * learn how to use tools like repoman and git (think of the future ;)) it will also be better for us. moving packages from the overlay to tree will be simpler, also tracking versions and package status will be easier. 2) I think an email alias is not needed We can monitor maintainer-wanted/- needed alias if needed. What do you think? If we go with the new overlay, I think we'll need an alias where the users can ask for help and talk about their packages. 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that the specific bug is already taking by another developer and that somebody is working on it. So marking a bug with a keyword e.g. PROXY might be useful. Thats not a bad idea. Another solution would be to assign the bugs to proxy-maintain...@g.o. -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpSloZtxpV78.pgp Description: PGP signature
Re: [gentoo-dev] Empty herd: sgml
On Mon, Mar 22, 2010 at 02:25:43AM -0100, Jorge Manuel B. S. Vicetto wrote: Here is a list of the packages that would be moved to maintainer-wanted: app-doc/halibut app-office/passepartout app-text/asciidoc app-text/build-docbook-catalog app-text/docbook2X app-text/docbook-dsssl-stylesheets app-text/docbook-sgml-dtd app-text/docbook-sgml app-text/docbook-sgml-utils app-text/docbook-xml-dtd app-text/docbook-xml-simple-dtd app-text/docbook-xsl-stylesheets app-text/gentoo-guide-xml-dtd app-text/grutatxt app-text/html2text app-text/html401 app-text/htmlrecode app-text/htmltidy app-text/html-xml-utils app-text/linuxdoc-tools app-text/openjade app-text/opensp app-text/robodoc app-text/sablotron app-text/sgml-common app-text/sgmltools-lite app-text/sgrep app-text/txt2tags app-text/xhtml1 app-text/xml2doc app-text/xml2 app-text/xmlformat app-text/xmlstarlet app-text/xmlto www-client/htmlview The following packages would be dropped to the remaining maintainers: app-emacs/nxml-mode (emacs) app-emacs/psgml (emacs) app-text/gnome-doc-utils (gnome) app-text/highlight (tex) app-text/scrollkeeper-dtd (gnome) app-text/scrollkeeper (gnome) app-text/webgen (ruby) dev-ruby/xml-simple (ruby) A lot of useful stuff here. I've added myself and tampakrap to the sgml herd, we'll try to keep it in good shape :) -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpug5W71Iomd.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- humpback, genstef, wrobel
On Tue, May 25, 2010 at 11:39:10AM +0200, Torsten Veller wrote: Here's a bunch of packages up for grabs, due to maintainers retiring.. maintainer-needed - sys-apps/ivman grabbed this one ;) -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpwhTJeyfRfC.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild
On Thu, Jun 10, 2010 at 11:45:14PM +0200, Rémi Cardona wrote: Le 10/06/2010 22:45, Arfrever Frehtes Taifersar Arahesis a écrit : 2010-06-10 22:20:44 Nirbheek Chauhan napisał(a): On Fri, Jun 11, 2010 at 1:30 AM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-06-10 21:27:40 Jeremy Olexa napisał(a): I see no reason to *not* add a ChangeLog entry here. ChangeLog entries are not required for trivial changes. A trivial change is fixing a typo, or a manifest problem, a missing quotation mark, etc. Anything else is not trivial. Anything that changes how an ebuild functions, what it does, or the installed files (and/or their contents) is NOT a trivial change. This commit only removed some compiler warnings. Why argue about this? Just always add a ChangeLog entry, like everyone else. This is in everyone's interest, including yours. +1 besides, fixing dependencies or messing with cflags doesn't seem trivial to me =] -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpPR8plFTSTJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
On Fri, Jun 11, 2010 at 11:50:38PM +0200, Ben de Groot wrote: I guess I should have done a proper grep on the tree before my first message. I missed a few more that are now up for grabs: app-misc/vifm media-sound/ncmpcpp net-misc/wput ^^ I'll take these media-video/smplayer ^^ The Qt team will take care of this. I might add myself as a maintainter to give it some extra attention, we'll see. -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpENsvSXuXxa.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open
On Tue, Jun 15, 2010 at 01:17:20PM +0300, Markos Chandras wrote: I nominate the following developers ... *wired thanks, I accept. you may read my manifesto here: http://dev.gentoo.org/~wired/manifesto_2010-06.txt -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpvYQN1MCTYR.pgp Description: PGP signature
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, Jun 28, 2010 at 06:39:44AM +0530, Nirbheek Chauhan wrote: Hello everyone, ... What needs to be done now is for someone with lots of CPU power to grab the list of packages[1], and build them one-by-one (all versions), adding to a new list all the ebuilds that fail. How to test: LDFLAGS=-Wl,--as-needed emerge -v1 $atom Once we have the list that fails with normal as-needed, we can fix them, get the fix upstreamed (if possible), and switch the flag on. This action should probably be accompanied by a news item informing users about the change, and encouraging them to report the (rare) bug which might hit them. Let's try to make Gentoo less frustrating for our users. I'll help ;) Testing from the bottom up to avoid overlapping with hwoarang. 1. http://dev.gentoo.org/~nirbheek/files/as-needed-failures.list -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpiDYoSbYHWA.pgp Description: PGP signature
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Tue, Jun 29, 2010 at 08:23:40AM +0100, Ciaran McCreesh wrote: On Tue, 29 Jun 2010 05:30:24 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 28 Jun 2010 15:05:19 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: You appear to be assuming that those pushing the --as-needed solution have it finished. This is far from the case. There's still a lot of work that would need to be done, and that work will have to be carried on by every developer indefinitely as new versions of packages come out. It's a case of the wrong thing requires quite a lot more work before it's ready, and once it's ready everyone will have to carry on working on it forever. Why do you care? Everybody intimately involved in Exherbo and caring about it tells me you forked. I use Gentoo, as you well know from every other time the anyone who ever touches any other distribution is a traitor and should go away and never do anything with Gentoo again line has been tried. I care because it's a huge waste of everyone's time that's all happened because one developer refused to admit that he was in effect advocating the use of a flag in the same category as -ffast-math, even when shown how it would break correct code. This community has shown many times that it doesn't follow your logic. You've made your point, we listened, we rejected it. Please _try_ to understand that you *can't* force your opinion no matter how many times you repeat it. There are times when the majority will reach a decision you think is wrong. If the community feels their choice, albeit not perfect, will help the project, you have to respect that. That is, if you want to be part of the community :) If you didn't and are still leeching off our ebuild tree, then please file --as-needed bugs like everyone else, or shut up. Exherbo doesn't and never has used Gentoo ebuilds. Again, as you know fine well. -- Ciaran McCreesh Please try to restrain yourself from commenting on topics where the community has already reached a decision in the future. Even if you don't like it ;) -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpbRsle55BGJ.pgp Description: PGP signature
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Tue, Jun 29, 2010 at 06:25:50PM +0100, David Leverton wrote: On Tuesday 29 June 2010 09:46:52 Alex Alexander wrote: If the community feels their choice, albeit not perfect, will help the project, you have to respect that. That is, if you want to be part of the community :) I see your point to some extent, but the concern is that such decisions might sometimes get made according to who's best at ignoring technical objections rather than what's the best thing to do. It has happened before, although in that case the change was made first, and then when the issue was brought up it got basically ignored for so long that it would be pointless to fix. It would be worrying if things like that started to happen more often. I understand your concern. But this is no such case. We went through the discussion phase already. We're trying to avoid an endless loop. In any case, as mentioned in my other mail, if this particular change is done in a way that's optional for the user, I personally won't be /too/ upset if the rest of you want to do unspeakable things to your systems ;-). This thread is about LDFLAGS+=--as-needed in make.defaults, which can be overridden, so I don't see any issues there either. You're free to change the defaults if you don't like them :) -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpt1wNQUPCc1.pgp Description: PGP signature
Re: [gentoo-dev] Minor changes in python.eclass and distutils.eclass
On Mon, Jul 05, 2010 at 05:23:58PM +0200, Arfrever Frehtes Taifersar Arahesis wrote: These minor changes in python.eclass and distutils.eclass have been already reviewed on alias of Gentoo Python Project. It's recommended to be familiar with internals of current code before trying to understand these minor changes. Suggestions about indentation and quoting will be rejected. I don't understand. eclass patches are supposed to be sent to -dev as RFCs, not as hey, I did this, but if you want to comment, don't, I don't care. You should welcome critisism, your fellow devs want whats best for Gentoo, they are not after you :) Truth is, all that weird coloring is messing up the eclass. At the very least you could have defined your own epinfo function or something to cover it up. Or pushed for Peterri's eqawarn solution. -- Arfrever Frehtes Taifersar Arahesis -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpnlC6WnX40e.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, Jan 05, 2012 at 08:08:44PM +, Ciaran McCreesh wrote: On Thu, 5 Jan 2012 13:30:24 -0600 William Hubbs willi...@gentoo.org wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. Although this is a bit frightening to think about, because people are crazy enough to actually implement it, this is one of the funniest things I've read lately, thanks for the laugh xD On a serious note though, it seems to me that the /bin | /usr/bin line is too blurry, creating confusion. Migrating everything to a single folder is the simplest solution of all. Combine that with redhat's update approach and it is easy to see why they've taken this route. If people are really interested in keeping a tight, self contained root, we need to: - establish a [tight] list of software we consider critical for / - fix/patch software in that list so it can run without /usr there - create /bin = /usr/bin/ symlinks for above software (simplifies things if packages start hardcoding /usr/bin here and there) - move everything else in /usr/bin/ Do this and I'm sure other people/distros will follow/help and upstreams will accept our patches. I'm sure there are other people who don't like this one bin folder to rule them all logic. If no one is really interested in doing all this... well, whoever actually implements something in open source usually wins the race - it's the same in Gentoo too, no? ;) Only difference here is, one team has the advantage of being paid to do it. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, Jan 06, 2012 at 08:35:32AM -0500, Rich Freeman wrote: On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander wi...@gentoo.org wrote: If people are really interested in keeping a tight, self contained root, we need to: - establish a [tight] list of software we consider critical for / - fix/patch software in that list so it can run without /usr there - create /bin = /usr/bin/ symlinks for above software (simplifies things if packages start hardcoding /usr/bin here and there) - move everything else in /usr/bin/ You're missing one thing: - establish a list of all the configurations that will actually work with this self-contained root I think this is why there is so much disagreement over whether this is a good move. If you have a really simple configuration, then the self-contained root concept works reasonably well (though apparently we'll have to heavily patch newer versions of udev or abandon it to sustain this). However, if you have a very complex configuration the current self-contained root is already broken and you need an initramfs anyway. For in-between cases things might work now but that is likely to change as upstream moves on. The binary distros don't have users tweaking their kernels and init scripts, so they basically have to design for worst-case. Gentoo can get away with designing for more of an average case since we just tell anybody with a complex case to go read a howto and configure what is necessary (and we like to do that stuff anyway). We can choose not to like it, but it sounds like maintaining a self-contained root for even the typical case will become untenable. Those who argue that having /usr on a separate partition simply shouldn't be supported are basically just saying that our self-contained root should include everything in /usr which seems to defeat the whole point of a self-contained root anyway. It seems to me that the most reasonable approach is to not force the issue, but not deviate greatly from upstream either. That means accepting that over time the rootfs will become less and less capable of working on its own, and immediately improving tools like dracut to overcome these limitations. Users who can get away with it can avoid using an initramfs, at least for a time. Sure, it is all open source, and Gentoo can swim upstream if we REALLY want to. However, this only works if developers are willing to spend the time constantly fixing upstream's tools. It sounds to me like the maintainers of packages like udev/systemd/etc want to actually move in the same direction as upstream so in practice I don't see that happening. Now, Gentoo is about choice, so one thing we should try to do as much as possible is understand the limitations of the various configurations and make it clear to users when they do and don't need an initramfs. To be honest, tight coupling worries me more than the /usr move, since that has a lot more potential to constrain the choices we can offer our users (which is a great deal of the value that Gentoo offers). I understand its advantages, but it seems somewhat contrary to the unix way. That's why I wrote tight list. I do not expect the self-contained root to be able to handle everything /usr (or a complete initramfs) would. What it could and couldn't do is something that needs to be decided, but some work is already done there - it's just a bit messy and incomplete and because most people don't care it keeps getting worse. The important thing here is to make a clear definition of where we draw the line and make sure things work the way we want them to. I agree with you in that at some point patching may become too time consuming, but I still believe that if we do this properly, with a well-defined plan and list of packages we want to keep in / (with symlinks to be compatible with whatever others are trying to do), we won't be alone in this. Gentoo may be one of the most hardcore power-user distros out there, but we're certainly not the only one. Now, if only we had people interested enough in doing this... :) -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com signature.asc Description: Digital signature
Re: [gentoo-dev] github g.o.g.o
On Sat, Feb 25, 2012 at 01:55:37PM +0100, Justin wrote: Hi all, is there a way to do a way or two way sync between a repo on github and on g.o.g.o? I have the felling that I heard of an official overlay which is operated like this. Could someone please point me to this overlay and the technique? For every secondary repo you want to keep synced, add a pushurl entry pushurl = git-repo-url below your main url = line in the repo's .git/config file. Git will automatically push to all pushurl entries automatically when you git push. We do this in the Qt overlay (with gitorious atm): [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = git://git.overlays.gentoo.org/proj/qt.git pushurl = g...@gitorious.org:gentoo-qt/qt.git Regards, -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com signature.asc Description: Digital signature
Re: [gentoo-dev] Packages up for grabs due www-server herd removal
On Wed, Mar 21, 2012 at 12:26:12PM +0100, Pacho Ramos wrote: As discussed in [gentoo-dev] www-servers herd is empty thread, we agreed with dropping this herd and let people get what they want to maintain. This is the list of orphan packages: ... www-servers/lighttpd This is not an orphan :) -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com
Re: [gentoo-dev] rfc: location of portage tree
On Tue, Mar 27, 2012 at 02:05:54PM -0500, William Hubbs wrote:
All,
I know this has come up before, but I don't really recall what the
specific objections were.
IMO the portage directory doesn't belong under /usr at all.
I was chatting with another developer who uses
/var/cache/portage/{tree,distfiles}, and I'm thinking about switching my
default setup to do this.
I realize that historically the portage tree has been installed under
/usr, but Can we consider changing this default for new installations
and providing instructions for users for how to get the portage tree out
of /usr?
William
If/when this happens, we should also consider improving the internal
structure of the portage folder. At the moment we just throw everything
in it, which is not very user friendly. I recommend creating a subfolder
for the actual tree, keeping distfiles and packages out.
For example, my /usr/portage/ on this system looks like this:
portage/
tree/
profiles/ - tree/profiles/
distfiles/
packages/
layman/
it is a big improvement over the current
distfiles-and-packages-mixed-with-tree-while-layman-wanders state :)
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
signature.asc
Description: Digital signature
Re: [gentoo-dev] Happy 10th birthday (in advance)
On Mar 31, 2012 12:57 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 31 Mar 2012 12:44:03 +0300 Alex Alexander alex.alexan...@gmail.com wrote: @preserved-libs works very well and is awesome. hack or not. IMO it should be in stable already. I've been using it on stable production boxes for years without any issues :) ...and here we see the problem. You think that I haven't noticed it break means it works. The problem with preserved-libs (and emerge --jobs, for that matter) is that the design is I can think of a few ways where it might break, so I'll hard-code in special cases to handle those, but in general I can't think of what other problems there are so it's fine. That's a bad way of doing things. -- Ciaran McCreesh No. I didn't say I think it works, I said I have proof it works. You can argue about the implementation details all you want and it'll still work. If you can make it better then, by all means, send a patch. Otherwise stop spreading false FUD, please. Thanks :) Alex | wired
Re: [gentoo-dev] Happy 10th birthday (in advance)
On Mar 31, 2012 5:57 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 31 Mar 2012 15:08:29 +0300 Alex Alexander alex.alexan...@gmail.com wrote: No. I didn't say I think it works, I said I have proof it works. Well that's interesting, because there are plenty of examples where it doesn't work, and all that it takes to disprove a theory is a single counterexample. So I think you're misunderstanding what constitutes proof here -- some evidence certainly isn't it. -- Ciaran McCreesh Boring. You conveniently ignored the other part of my message. I'll repeat it: no matter how much you argue, it'll still work fine for me. That said, I think we can end this conversation now :) Gentoo \o/ Alex | wired
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 9:22 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 23 Jun 2012 20:23:13 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 23 Jun 2012 19:06:38 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 23 Jun 2012 20:09:03 +0200 Michał Górny mgo...@gentoo.org wrote: That's just it, though -- this no longer holds. -r300 is now being used for something that is exactly the same version as -r200. Did you look at SONAME? Look at SONAME before deciding what package to install? Kindly explain how that works. I'm just saying that these are two different versions of the package. If you want GTK+3, you take the newer one. If you want GTK+2 compat, you take the older slot. What's wrong with that? The package mangler does not know that 1.1-r300 is not a better version than 1.1-r200, or that 1.2-r200 is not a better version than 1.1-r300. Indicating packages where this kind of strangeness happens allows manglers to know that things that are usually true about the relationship between slots and versions no longer hold, and that in these specific cases it should consider slots to be heavily independent. You already have this info, it's called a slot dependency. -- Alex
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 9:37 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 23 Jun 2012 21:35:47 +0300 Alex Alexander wi...@gentoo.org wrote: The package mangler does not know that 1.1-r300 is not a better version than 1.1-r200, or that 1.2-r200 is not a better version than 1.1-r300. Indicating packages where this kind of strangeness happens allows manglers to know that things that are usually true about the relationship between slots and versions no longer hold, and that in these specific cases it should consider slots to be heavily independent. You already have this info, it's called a slot dependency. It's not a property of individual packages that happen to depend upon the problematic package. The property holds or not for a package regardless of whether anything depends upon it. They are part of the deal. If your package has reverse deps, you don't want to update it before figuring out it's reverse dependencies anyway, you never know what slot/version restrictions you're going to get. If it is a package without reverse dependencies, updating to the most recent slot and/or version should be expected unless the user has the slot defined in the world file. -- Alex
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 10:16 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 23 Jun 2012 22:14:32 +0300 Alex Alexander wi...@gentoo.org wrote: If it is a package without reverse dependencies, updating to the most recent slot and/or version should be expected unless the user has the slot defined in the world file. That's the part that no longer holds. The package mangler now needs a way of knowing that for a certain few packages, bringing in new slots when not explicitly required is undesirable. Or the PM can notify the user that a new slot has come up and instruct them to specify their desired slot in their world file. -- Alex
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sep 16, 2012 4:55 PM, Brian Harring ferri...@gmail.com wrote:
Folks-
Keeping it short and quick, a basic glep has been written for what I'm
proposing for DEPENDENCIES enhancement.
The live version of the doc is available at
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html
Am I the only one who thinks that this dep:{build,...} thing looks really
ugly and is hard to read?
IMO simply removing the dep part would greatly improve things:
DEPENDENCIES=
:build,run? ( ... )
:run? ( ... )
s/:/@/ would also be interesting
DEPENDENCIES=
@build,run? ( ... )
@run? ( ... )
Alex | wired
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sep 17, 2012 6:13 AM, Brian Harring ferri...@gmail.com wrote:
On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:
On Sep 16, 2012 4:55 PM, Brian Harring [1]ferri...@gmail.com
wrote:
Folks-
Keeping it short and quick, a basic glep has been written for what
I'm
proposing for DEPENDENCIES enhancement.
The live version of the doc is available at
[2]
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe
ndencies.html
Am I the only one who thinks that this dep:{build,...} thing looks
really ugly and is hard to read?
IMO simply removing the dep part would greatly improve things:
That 'dep' part isn't great, but it's added for a reason; to unify
with USE_EXPAND/use group intended syntax. There's a reference in
there to
http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which
I'll formalize soon enough.
DEPENDENCIES=
:build,run? ( ... )
:run? ( ... )
For your suggestion, consider it if we *do* fxi USE expand- via using
the same namespace:setting form.
Using app-admin/mcollective ad an example, it's deps are thus:
DEPEND=ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
RDEPEND=dev-ruby/stomp
ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
Which, if USE_EXPAND targets were groupped, would go from this
ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
dep:run? ( dev-ruby/stomp )
to this:
ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
:run? ( dev-ruby/stomp )
Ok, now I get it. I've read the other threads as well, but failed to put it
all together. Happens when you barely sleep every night :-)
I don't like this mix of dependency types and use flag deps. It smells
trouble. Dependency types should be easy to separate and read, but the
above example is a mess, dep: or no dep:.
Why? Because you have to scan the whole thing to sort out which lines are
dependency types and which lines are use deps and even then it would be
easy to misread something.
If we want to stay away from labels (which aren't that bad IMO), I'd
recommend the following instead:
Force explicit setting of the dependency type and disallow the mix of
dependency types and use flag deps at the same level / block.
DEPENDENCIES=
:build,run? ( lib/foo )
:run? (
lib/bar
someuseflag? ( random/app )
)
:*? (
thing? (
:build? ( lib/thing )
:run? ( lib/thingrunner )
)
Or, using your example:
:build,run? (
ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
)
:run? ( dev-ruby/stomp )
Alex | wired
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
On Sep 22, 2012 10:58 AM, Michał Górny mgo...@gentoo.org wrote: Hello, The current dependency syntax: [VERSION-OP] PACKAGE-NAME [- PACKAGE-VERSION] suffers a few problems: The syntax you are describing is used all over portage, not just dependencies. Some examples are the /etc/portage/package.* files, has_version or exact version matching when emerging. Changing it just for dependencies would most certainly confuse people and tbh I like the current syntax :-) Alex | wired
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
On Sep 22, 2012 7:38 PM, Michał Górny mgo...@gentoo.org wrote: emerge 'foo = 1.1' 'bar 1.0'? emerge foo '=' 1.1 bar '' 1.0? How is the above easier to read than emerge =foo-1.1 bar-1.0 ? I think your example is working against you*.* The current syntax is much easier to read than the quote-and-whitespace-tracking horror of your example :-P Alex | wired
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
On Sep 22, 2012 8:25 PM, Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 20:11:48 +0300 Alex Alexander wi...@gentoo.org wrote: On Sep 22, 2012 7:38 PM, Michał Górny mgo...@gentoo.org wrote: emerge 'foo = 1.1' 'bar 1.0'? emerge foo '=' 1.1 bar '' 1.0? How is the above easier to read than emerge =foo-1.1 bar-1.0 Did you even test it? That would create '=foo-1.1' and then fail trying to read 'bar-1.0'. It's rather: emerge '=foo-1.1' 'bar-1.0' Yes, you are right, still much easier to read than your example tho. Testing things is limited to very important stuff atm, I only have an android phone and intermittent 3g available and ssh without a real kb is a pain :-) I think your example is working against you*.* The current syntax is much easier to read than the quote-and-whitespace-tracking horror of your example :-P It's no less quoting than in the current case. And it could be simply extended to supporting quoting-less syntax, e.g.: emerge foo -gt 1.1 bar -lt 1.0 I still find whitespace inappropriate for this kind of things. You are trying to replace a single atom that instantly gives you all required information with a format that does not clearly separate atoms, IMHO anyway :-) Alex | wired
Re: [gentoo-dev] Re: Last rites: eclass/php5_1.eclass
On Sun, Jul 18, 2010 at 03:05:18PM -0500, Doug Goldstein wrote: On Sat, Jul 17, 2010 at 6:28 PM, Ryan Hill dirtye...@gentoo.org wrote: On Sat, 17 Jul 2010 22:23:03 +0200 Matti Bickel m...@gentoo.org wrote: On 07/17/2010 09:58 PM, Matti Bickel wrote: since there's no dev-lang/php-5.1* version in the tree anymore, this eclass is useless. It will be removed on 17th August 2010. I've just been told by scarabeus that eclass removal is a two years minimum process. So it'll be removed 17th August 2012 and marked #...@dead (deprived of functionality) in the next days. /me shakes his fist once again at the inanity of this policy. Just remove it! If the council can not be bothered to help developers develop but instead hinder developers from developing, then they are no longer relevant and should be treated as such. Other course of action could always be that they should all be kicked out and replaced with a suitable organization to ensure Gentoo's technical and developmental success. Thats a bit harsh :) We are already planning to re-visit this issue: http://archives.gentoo.org/gentoo-dev/msg_fcd62364eb57125a651397a5328a7af9.xml -- Doug Goldstein -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpErqcdnbJYK.pgp Description: PGP signature
Re: [gentoo-dev] Re: bug wrangler queue is large...
On Mon, Jul 19, 2010 at 08:01:38PM +0200, Jeroen Roovers wrote: On Fri, 16 Jul 2010 01:50:00 +0300 Markos Chandras hwoar...@gentoo.org wrote: The queue is almost 100 bugs long again. We could really use some help here. Thanks Down to 7 now. wow. nice work! -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpeYSEiaBoqj.pgp Description: PGP signature
[gentoo-dev] Council Agenda proposal for upcoming 2010-07-26 meeting
Hi, following is the Council Agenda proposal for the upcoming meeting on Monday, July 26th. * allow all members to show up (5 min) ** vote ** add --as-needed to default profile's LDFLAGS ** discuss / vote ** - required-use: http://dev.gentoo.org/~ferringb/required-use.html - review eclass removal policy should it be 2 years since portage 2.1.4.4 went stable? - should there a policy about eclass API changes? - use of invalid DEPEND atom EAPI_TOO_OLD instead of calling die in global scope on eclasses http://archives.gentoo.org/gentoo-dev/msg_dee3aab5e8c840ed3fa4add9c7d74b97.xml and replies - mailing lists should we post council agenda to -council? -dev? -project? some devs suggest we should cross-post to -dev and -council but not everyone likes cross-posting as it can lead to fragmentation Petteri suggested punting -council and using -project instead * go through bugs assigned to coun...@g.o * open floor: listen to developers --- If you have something urgent not included above, please reply to this thread. --- Note that I haven't added a duration to anything but the rollcall. Instead, I recommend we follow a 10 minutes per topic rule. If a topic's discussion passes the 10 minute mark without reaching a decision, we move further discussion to the mailing lists. If we need to vote for that topic, we move it to the next agenda with a *vote* flag. Items with a *vote* flag cannot be moved a second time (unless there's new data to consider), so they must be settled at that agenda's meeting, in an attempt to avoid endless discussions. What do you think? -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpOt4l86b35Q.pgp Description: PGP signature
Re: [gentoo-dev] News item announcing as-needed (glep 42 stuff)
On Mon, Jul 26, 2010 at 10:29:06PM +0200, Tomáš Chvátal wrote: Hi guys, See the attachment for the draft. Please improve it to be an actual English :P How about: -Wl,--as-needed has been added to the default profile's LDFLAGS. This option optimizes the linking process, only linking binaries to libraries that are trully needed. This way, fewer libraries are loaded at runtime and fewer packages need to be rebuilt on library updates. Setting LDFLAGS in your make.conf will override the default. In that case, if you want the new setting you have to either remove LDFLAGS, or append -Wl,--as-needed to it (sans the quotes) yourself. To take advantage of the new default you can either rebuild world or allow the system to migrate slowly through updates. To disable the new default (not recommended) you can define your own LDFLAGS in make.conf. LDFLAGS=-Wl,-O1 will suffice. For more information on --as-needed, read [1]. [1] http://www.gentoo.org/proj/en/qa/asneeded.xml -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com pgphbA3oTx1sX.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote: - If you are not in cc of the gentoo bug nor in the herd alias, please cc yourself on the bug. - Please close the bugs, even the dupes (and apply previous point to the dupes too). - That way you'll be able to quickly fix (apparently, I didn't check) obvious mistakes [1]. - You'll have to do a rev. bump for *FLAGS respect, please also check if you can avoid it by doing a version bump instead. Well not always. If something is on ~testing then I don't think I should spam the tree with revbumps. Stable users are my first priority so Stable may be more critical, but we support ~testing as well. How do you expect your changes to be tested before landing on stable if you don't revbump the packages, allowing them to reach our users? Please, don't skip revbumps to avoid tree spamming, thats why we have revbumps in the first place ;) unless something is on stable branch, I fix it as it is. I don't want to version bump anything because I don't want to mess with anyones packages. I only do QA fixing. If you have problem touching your packages just say it A. [1] https://bugs.gentoo.org/show_bug.cgi?id=332523 -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com pgpmeRTNX8JRb.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 04:47:39PM +0300, Markos Chandras wrote: On Sat, Aug 14, 2010 at 04:10:13PM +0300, Alex Alexander wrote: On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote: - If you are not in cc of the gentoo bug nor in the herd alias, please cc yourself on the bug. - Please close the bugs, even the dupes (and apply previous point to the dupes too). - That way you'll be able to quickly fix (apparently, I didn't check) obvious mistakes [1]. - You'll have to do a rev. bump for *FLAGS respect, please also check if you can avoid it by doing a version bump instead. Well not always. If something is on ~testing then I don't think I should spam the tree with revbumps. Stable users are my first priority so Stable may be more critical, but we support ~testing as well. How do you expect your changes to be tested before landing on stable if you don't revbump the packages, allowing them to reach our users? I expect arch testers to do a pretty good testing before they mark them stable. Seems like I am the only one who fixes such issues without revbump. Strange, cvs log must be lying... Now lets see http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html Ebuilds should have their -rX incremented whenever a change is made which will make a **substantial** difference to what gets installed by the package — by substantial, we generally mean something for which many users would want to upgrade. This is usually for bugfixes. Seems like it is up to maintainer's discretion to decide what it is substantial change and what it is not. Many users wont be directly affected from my changes. It is not like not respect CXX, CXXFLAGS after all. Simple compile fixes do not warrant a revision bump; this is because they do not affect the installed package for users who already managed to compile it. Small documentation fixes are also usually not grounds for a new revision. So you want me to force everyone to update the package just to respect the LDFLAGS. Why, since until recently, nobody gave a crap about this kind of QA issues? Please provide a patch for devmanual to make it more clear. If it is already clear maybe I am that stupid after all. In any case, I will keep doing what I do because you didn't convince me so far that my changes need a revbump. If arch testers fail to do proper testing thats really *REALLY* not my fault. Testing is testing and I can't do a revbump for every little piece of shit I fix everytime. Does respecting LDFLAGS change the installed files in any way? yes. Will users benefit from your change if you don't revbump? No. I think that chain of logic is enough to warrant a revbump and it is covered by the devmanual since the change affects the installed package. It's merely a cp, why are you making such a fuss about it? You're doing a good job already, we're just pointing out ways to make it even better :) BTW, archs do the final testing, but much testing is done by the users themselves, who report the bugs that get fixed before the packages get a STABLEREQ bug ;) Please, don't skip revbumps to avoid tree spamming, thats why we have revbumps in the first place ;) unless something is on stable branch, I fix it as it is. I don't want to version bump anything because I don't want to mess with anyones packages. I only do QA fixing. If you have problem touching your packages just say it A. [1] https://bugs.gentoo.org/show_bug.cgi?id=332523 -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com pgpeRtWlpAORz.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 08:00:40PM +0300, Markos Chandras wrote:
On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
Does respecting LDFLAGS change the installed files in any way? yes.
Will users benefit from your change if you don't revbump? No.
I think that chain of logic is enough to warrant a revbump and it is
covered by the devmanual since the change affects the installed package.
No it doesn't. If it was that clear we wouldn't debated over this over and
over. The cvs logs and you will see that other devs are fixing the package
without revbump.
The fact that others do what you do doesn't automatically make it right.
It's merely a cp, why are you making such a fuss about it? You're doing
a good job already, we're just pointing out ways to make it even better
Cause I don't like users to compile the same damn package over and over. -r1
for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a good
reason or not? It is not like I introduce huge patches with bugfixes etc. My
fixes are QA fixes not *serious* bugfixes anyway.
Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
there isn't much for users to test anyway. Either you respect the bloody flags
or not. I don't do blindly commits. I try to test the packages in multiple
chroots anyway.
All your fixes are important else you wouldn't be doing them.
I still don't understand why you don't want to revbump.
Your changes may not affect program features but they do fix hidden
issues. Issues that might help users later (for example, rebuilding a
package with --as-needed may reduce revdep-rebuilds in the future).
You can always try to reduce revbumps by doing all the things you
mentioned together, if possible.
In any case, unless we're talking about openoffice or kdelibs, revbumps
don't really cost so much anymore.
:)
BTW, archs do the final testing, but much testing is done by the users
themselves, who report the bugs that get fixed before the packages get a
STABLEREQ bug ;)
Most of these bugs don't come from users but from Diego. Why? Because users
don't bother reading the build.log and see if all their flags are respected or
not. I wouldn't do it either. This
I never said users report these specific bugs. But they will test *your*
revbumps and may report other problems you didn't hit.
Please, don't skip revbumps to avoid tree spamming, thats why we have
revbumps in the first place ;)
I am not convinced yet that this kind of QA fixes require a revbump. As I
said, commit an actual patch, assigned to QA and if the rest of the members
agree on that I am willing to change my policy.
Now you're just being stubborn. I'm pretty sure your mentor told you any
change to installed files warrants a revbump ;)
Do we really need bureaucracy to enforce a commonly followed but not
documented policy?
unless something is on stable branch, I fix it as it is. I don't want
to
version bump anything because I don't want to mess with anyones
packages. I only do QA fixing. If you have problem touching your
packages just say it
A.
[1] https://bugs.gentoo.org/show_bug.cgi?id=332523
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
pgpjSxqLycMhR.pgp
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 08:34:13PM +0300, Markos Chandras wrote: said, commit an actual patch, assigned to QA and if the rest of the members agree on that I am willing to change my policy. Now you're just being stubborn. I'm pretty sure your mentor told you any change to installed files warrants a revbump ;) Pretty sure this rule is not that strict. Do we really need bureaucracy to enforce a commonly followed but not documented policy? So document this policy to point stubborn maintainers to it Apparently I pissed a lot people off so I will siege my QA fixes for now. Apparently I need a break I'm pretty sure you didn't piss off anyone. We're having a conversation about something, we're not fighting :) -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com pgpyYRRiLy0N8.pgp Description: PGP signature
Re: [gentoo-dev] New eclass: scons.eclass
On Sun, Aug 22, 2010 at 12:04:52PM +0200, Michał Górny wrote:
Hello,
As per bug #333911, I'm working on a new eclass, providing some basic
functions common to most of the ebuilds using the SCons build system.
[...]
I'm attaching the eclass draft (the same which is attached to bug
#333911), and inlining a simple use example below:
#v+
inherit scons
# ...
pkg_setup() {
scons-clean-makeopts
}
src_compile() {
scons \
$(scons-use unicode) \
$(scons-use gnutls ssl gnutls openssl) \
${MAKEOPTS} || die
# expands into:
# scons unicode={1|0} ssl={gnutls|openssl} -jN || die
}
#v-
Looks nice :)
You could avoid having to define pkg_setup in every ebuild by defining a
default one in your eclass:
--- scons.eclass.old2010-08-22 13:11:57.0 +0300
+++ scons.eclass2010-08-22 13:15:57.0 +0300
@@ -39,6 +39,15 @@
DEPEND=dev-util/scons
fi
+# -- phase functions --
+
+# @FUNCTION: scons_pkg_setup
+# @DESCRIPTION:
+# default pkg_setup, runs scons-clean-makeopts
+scons_pkg_setup() {
+ scons-clean-makeopts
+}
+
# -- public functions --
# @FUNCTION: scons-clean-makeopts
@@ -185,3 +194,5 @@
_scons-clean-makeopts-perform-test '-j2 HOME=/tmp' '-j2'
_scons-clean-makeopts-perform-test '--jobs funnystuff -k' --jobs=${jc}
-k
}
+
+EXPORT_FUNCTIONS pkg_setup
--
Best regards,
Michał Górny
http://mgorny.alt.pl
xmpp:mgo...@jabber.ru
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / Chromium / KDE / more
www.linuxized.com
pgp0A6fSdvEeq.pgp
Description: PGP signature
Re: [gentoo-dev] What the hell is going on here?
On Fri, Sep 17, 2010 at 03:52:03PM +0100, Markos Chandras wrote: On Fri, Sep 17, 2010 at 12:51:52PM +0200, Maciej Mrozowski wrote: On Friday 17 of September 2010 12:41:51 Angelo Arrifano wrote: Every single QA commit review coming into my Inbox during the past week was directed to arfrever. I *know* he is on probation, I *know* he made mistakes - in fact every one makes mistakes. But you guys are hammering all over him for picky stuff. Remind you that while it is a pleasure to be member of Gentoo, we are not your slaves; we chose to spend our free time contributing to Gentoo for several reasons - fun, knowledge and team work. Satisfying somebody else's flavors and wishes is certainly *not* one of them. I never had the chance to talk with arfrever, nor I ever looked to his work at Gentoo. But there is one thing I definitely got right, he has a lot of motivation to continue in Gentoo and *offer* his time and knowledge, otherwise he would just raise the middle finger and go away after all of this bashing. The other important thing is such lecturing should probably take place in private, like gentoo-core. -- regards MM Well, Angelo is quite right for posting in this ML because QA members wants anything to be publicly visible. Angelo, I do agree with you. It seems like everyone is forcing himself to find mistakes on Arfrevers commits even the slightest one. Whilst I do agree that pointing the mistakes is a good thing, however I am totally against targeting one person just to satisfy our ego. So I you spot a commit mistake and report it via the ML make sure you do it again when someone != Arfrever do it in the future. Bye -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 I don't think ego has anything to do with this. Arfrever brought this on himself. His [multiple] past mistakes and lack of cooperation are forcing the other devs to screen all his commits now, to make sure history doesn't repeat itself. Angelo, while I agree with your general thoughts on why everyone is contributing, I believe you should have gathered more intel before sending an email like this. We do respect Arfrever's motivation, we just need to make sure it translates to good, trustworthy work. If we didn't, his request to return to Gentoo would have been denied. Regards, -- Alex Alexander | wired Gentoo Linux Developer | Council / Qt / Chromium / more www.linuxized.com pgp6PWiLHdmMh.pgp Description: PGP signature
Re: [gentoo-dev] What the hell is going on here?
On Fri, Sep 17, 2010 at 06:38:48PM +0300, Theo Chatzimichos wrote: On Friday 17 September 2010 18:33:01 Alex Alexander wrote: I don't think ego has anything to do with this. Arfrever brought this on himself. His [multiple] past mistakes and lack of cooperation are forcing the other devs to screen all his commits now, to make sure history doesn't repeat itself. I object here, I asked Arfrever's help (either with python or python ebuilds) and every time I got some great feedback. Thats great! I never claimed he wasn't *helpful*. Accepting critisism and suggestions from fellow devs is something completely different. Angelo, while I agree with your general thoughts on why everyone is contributing, I believe you should have gathered more intel before sending an email like this. We do respect Arfrever's motivation, we just need to make sure it translates to good, trustworthy work. If we didn't, his request to return to Gentoo would have been denied. and I don't agree with this part, no need to say anything more than the previous guys said. Why? Do you feel we don't respect his motivation? Do you believe his commits don't require screening after the recent events? I'm sure no-one really wants to see Arfrever, or any other dev, go. Then again, no-one wants a broken tree either, so checking everything down to the smallest detail for a while won't hurt that much. Regards, -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt, Planet, Overlays -- Alex Alexander | wired Gentoo Linux Developer | Council / Qt / Chromium / more www.linuxized.com pgp5ecJVM1TkW.pgp Description: PGP signature
Re: [gentoo-dev] What the hell is going on here?
On Fri, Sep 17, 2010 at 06:04:31PM +0200, Angelo Arrifano wrote: «forcing other devs to screen all his commits now» - like torture and pay-back? That's exactly what I feel it is entirely wrong. It just makes Gentoo look bad. Anyway, I think QA should keep their commit acceptability threshold in the same level for everyone. Of course this is easier to say than to do, we are humans after all, and feelings are always involved. Usually, personal interference is avoided by making the review process blind. That is, the person that commits would remain anonymous during the QA review process, but this is hard to apply in practice. Regards, - Angelo This is a matter of perspective. To you it might look like torture and pay-back, but for the guys doing it it could be making sure he follows all the guidelines. I can understand how easy it is to confuse those two if you aren't fully informed, though. To avoid communicating the wrong message to people outside Gentoo, following Maciej's proposal to lecture Arfrever in -core would be a good idea. Regards, -- Alex Alexander | wired Gentoo Linux Developer | Council / Qt / Chromium / more www.linuxized.com pgpFWwlGodl7b.pgp Description: PGP signature
Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree
On Thu, Sep 30, 2010 at 09:36:44AM +0200, Andreas K. Huettel wrote: Hi, as I've only recently graduated to developer, I've got a question about this. Diego, your request makes perfect sense to me. But, so far I always thought Python, portage, and gcc are the things that I really need to rely on, so whatever I do, I'll keep those stable. (My development machine(s) are also my real-life work machines.) What is the general opinion on this? Do you (developers) all use ~arch portage? How big is the risk? I use portage-2.2 on all my systems, including production boxes. Best, Andreas -- Alex Alexander | wired Gentoo Linux Developer | Council / Qt / Chromium / more www.linuxized.com pgp47eUOJ1QiL.pgp Description: PGP signature
Re: [gentoo-dev] Changes in server profiles
On Sun, Oct 31, 2010 at 11:50:02AM +, Markos Chandras wrote: On Sat, Oct 30, 2010 at 10:59:08PM -0400, Richard Freeman wrote: On 10/30/2010 08:10 AM, Thomas Sachau wrote: If i remember it right, the server profile was created for those people, who only want a minimum amount of default profile enabled USE flags (so no desktop profile because of that), but on the other side dont want to do the additional work/checks/reading for hardened profiles (which have much less profile enabled USE flags, but also have the special gcc, glibc and Kernel), basicly a profile, which does the same as hardened profile without the specific hardened bits. Isn't this essentially what the default profile is? Basically server is just default + USE=apache2 ldap mysql snmp truetype xml. Well it shouldn't be like that. And if the default profile is pretty much the same as the server one, then please consider removing the server profile as it makes no sense then Please don't. The fact that there are only a few changes doesn't make it useless. Also, you'd be forcing all users currently using the profile to migrate without any real reason. -- Alex Alexander | wired Gentoo Linux Developer | Council / Qt / Chromium / more www.linuxized.com pgp22L3Od8mYh.pgp Description: PGP signature
Re: [gentoo-dev] Hardened is planning on restructuring its profiles
On 6 Nov 2010, at 16:37, Anthony G. Basile bluen...@gentoo.org wrote: Hi everyone, The hardened team is planning to restructure its profiles so that there is no version. Thus on a amd64 system, [8] hardened/linux/amd64/10.0 [9] hardened/linux/amd64/10.0/no-multilib would appear as [8] hardened/linux/amd64 [9] hardened/linux/amd64/no-multilib We're planning on starting with the minor arches and then moving onto x86 and amd64. Since this has the potential to impact all profiles (given the complex inheritance structure), we'd like any feedback or caveats before we proceed. Anthony G. Basile (blueness) and the hardened team -- Anthony G. Basile, Ph.D. Gentoo Developer I'd like to know why you made this decision :) also, what will you do in the future if the need to make a change that breaks stuff shows up? Alex | wired | sent from my i4
Re: [gentoo-dev] Re: 150 bugs at bug-wranglers@
On Wed, Nov 10, 2010 at 07:05:44PM +0100, Jeroen Roovers wrote: On Wed, 10 Nov 2010 18:40:02 +0100 Diego Elio Pettenò flamee...@gmail.com wrote: Il giorno mer, 10/11/2010 alle 16.40 +0100, Jeroen Roovers ha scritto: On the other hand, whenever someone sends mail in this thread, the matter is usually resolved within a day. :) What if we automate sending of Bug wranglers queue full messages once a day when the queue is over a given number? Should be easier and therefore quicker to implement than all the other planned enhancements, like automated assignment. jer this is actually one line using pybugz, a few more including the mail code. I can run that once a day and send an email when a threshold is met. what do you think is best? 100 bugs? 150 bugs? -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpZ2OfKEfJtX.pgp Description: PGP signature
[gentoo-dev] [warning] the bug queue has 117 bugs
Our bug queue has 117 bugs! If you have some spare time, please help assign/sort a few bugs. Thanks!
Re: [gentoo-dev] [warning] the bug queue has 117 bugs
On Thu, Nov 11, 2010 at 01:28:46AM +0200, Alex Alexander wrote: Our bug queue has 117 bugs! If you have some spare time, please help assign/sort a few bugs. Thanks! How's this? I'll run it daily at 1200 UTC with a threshold of 130 for starters. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpKseJdFcvwB.pgp Description: PGP signature
Re: [gentoo-dev] Re: 150 bugs at bug-wranglers@
On Fri, Nov 12, 2010 at 05:52:10PM +0100, Jeroen Roovers wrote: On Thu, 11 Nov 2010 00:00:18 +0200 Alex Alexander wi...@gentoo.org wrote: 100 bugs? 150 bugs? 100 is better: that usually equates to a few days of backlog, whereas 150 bugs might very well denote an entire week's work. Alright, adjusted to 100 bugs for now :) -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpeoLuDjVCjk.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt-gui: ChangeLog qt-gui-4.7.1-r1.ebuild qt-gui-4.6.3-r1.ebuild
On Sat, Nov 13, 2010 at 23:40, Alexis Ballier aball...@gentoo.org wrote: Hi, + 10 Nov 2010; Alex Alexander wi...@gentoo.org +qt-gui-4.6.3-r1.ebuild, + +qt-gui-4.7.1-r1.ebuild: + moved Qt's GTK style to x11-themes/qgtkstyle - this fixes the nasty + qt-gui/cairo bug #336801 what to do with packages depending on qt-gui[gtk] ? media-sound/qtractor fails to build now, even if I install qgtkstyle failure is the same as in bug #340581 A. Interesting. Why would an app depend on Qt's GTK style? Let me have a deeper look. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com
Re: [gentoo-dev] [warning] the bug queue has 111 bugs
On Sun, Nov 14, 2010 at 03:20:05PM -0300, Alexis Ballier wrote: On Sunday 14 November 2010 09:45:04 Alex Alexander wrote: On Sun, Nov 14, 2010 at 01:10:26PM +0100, Paweł Hajdan, Jr. wrote: On 11/14/10 1:00 PM, Alex Alexander wrote: If you have some spare time, please help assign/sort a few bugs. I have another great idea for you. People are lazy, so could you make the warning message include a direct link to the Bug Wranglers queue? OK, link added http://bit.ly/bsHeJt could you please include a link pointing to https:// ? A. sure, https link added as well http://bit.ly/8Z4xUU :) -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpf81oufmdZ7.pgp Description: PGP signature
Re: [gentoo-dev] EAPI versioning of files in profiles
On Mon, Nov 15, 2010 at 07:40:44PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
Some updates to my suggestion:
- Files would optionally end with -${EAPI} suffix.
- The following files would be affected:
package.mask
package.unmask
package.keywords
package.accept_keywords
package.use
package.provided
use.force
use.mask
use.unsatisfiable
package.use.force
package.use.mask
package.use.unsatisfiable
packages
virtuals
(Some of these files aren't documented in PMS.)
I would like to suggest that this feature be included in EAPI=4.
I have a patch, which implements this feature in Portage.
The council has already decided that a filename suffix is not a
desirable way to fix issues like this.
We really need another solution..
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgpYqazF9Ucai.pgp
Description: PGP signature
[gentoo-dev] [warning] the bug queue has 109 bugs
Our bug queue has 109 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On Sun, Nov 21, 2010 at 01:47:57AM -0600, Ryan Hill wrote: On Sun, 21 Nov 2010 17:35:18 +1300 Alistair Bush ali_b...@gentoo.org wrote: We don't do revbumps on masked toolchain packages. Why not? Yeah why not? do you inform users of this? Users unmasking toolchain packages need to be paying close attention to what's going on behind the scenes. They're in the tree for people who know what they're doing to test. Even unmasked, toolchain revbumps are expensive and we do them only when absolutely necessary. If you pushed important fixes to gcc, you should revbump it before unmasking it. If you skip the revbump, I'm sure most users will miss this. There's virtually no expense to a revbump in this case. You just asked every user currently using gcc-4.5.1 to rebuild it, isn't a revbump the best, safest way to do that? -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgppwbotqb0dQ.pgp Description: PGP signature
Re: [gentoo-dev] Change policy about live ebuilds
On Sun, Nov 21, 2010 at 01:11:53PM +, Markos Chandras wrote:
Hi there,
The official policy for live ebuilds is the following one:
http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html
I don't quite agree with this policy and I guess most of you don't agree
either looking at the number of live ebuilds/package.mask entries.
My proposal is to keep empty keywords on live ebuilds without masking
them via package.mask
Users interpret this as a 'double masking' which in fact it is since
they need to touch two files before they are able to use the package.
I agree. Forcing the users to add ${P} ** in their keywords is enough,
it states that they're on their own.
I also know that we can use overlays for that, but distribute the
ebuilds among dev/proj overlays is not always a solution.
+1
for big projects like KDE, overlays are a better place, but for small
packages, they are overkill.
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgprpo8XtIFmz.pgp
Description: PGP signature
Re: [gentoo-dev] PYTHON_DEPEND in EAPI =4, PYTHON_BDEPEND
On 28 Nov 2010, at 22:20, Michał Górny mgo...@gentoo.org wrote:
On Sun, 28 Nov 2010 20:32:16 +0100
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
PYTHON_DEPEND will be required. Otherwise each ${range_of_versions}
should be included between and markers.
Do we really need to introduce those ugly markers? AFAICS in all places
they're used you could simply either use version numbers themselves or
'*' (instead of '', and '*[...]' instead of '[...]').
--
Best regards,
Michał Górny
I agree, reading these markers hurts my eyes :p
Alex | wired
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 04:47:36PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
2010-11-29 12:43 Sebastian Pipping sp...@gentoo.org napisał(a):
On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote:
Sebastian Pipping recently removed automatic upgrade of active version of
Python, so
python-2.7.1.ebuild does not upgrade active version of Python.
The ebuilds you just added for 2.7.1 and 3.1.3 do contain
eselect_python_update() and calls to it.
I suppose that happened by mistake and removed eselect_python_update()
on these ebuilds, too. They are in CVS now, mirrors take extra time.
It wasn't any mistake. Please actually read that code:
eselect_python_update() {
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
}
${PV%%.*} == 2
'eselect python update --python2' would be called only if output of
'eselect python show --python2' was empty, which would occur when
there was no active version of Python 2 set (no /usr/bin/python2
symlink).
--
Arfrever Frehtes Taifersar Arahesis
I updated two systems and they both switched to 2.7.1 automatically.
They were working fine with 2.6 before the update.
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgpiaF7y7PtID.pgp
Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 07:36:45PM +0100, Ulrich Mueller wrote:
On Mon, 29 Nov 2010, Graham Murray wrote:
I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which
until two days ago unconditionally called the following eselect
action:
But python-2.7 is installed in a new slot and python-2.6.x is not
removed. So. surely python-2.6.6-r1's pkg_postrm() should not be
called during the installation of python-2.7.1.
You are right, this cannot be the reason then.
But could pkg_postrm() of python-3.1.2-r4 have caused the update?
It essentially executed the following code:
[[ $(eselect python show) == python2.* ]]
eselect_python_options=--python2
eselect python update --python3 /dev/null
eselect python update ${eselect_python_options}
Ebuilds for 2.7.1 and 3.1.3 were committed together, and 3.1.2-r4 and
3.1.3 are in the same slot.
That's it. I ran those commands manually and the third one,
which evaluates to
eselect python update --python2
switched my python to 2.7.
On Mon, Nov 29, 2010 at 05:31:29PM +0100, Ulrich Mueller wrote:
On Mon, 29 Nov 2010, Alex Alexander wrote:
They were working fine with 2.6 before the update.
If it ain't broke, don't fix it? ;-)
I lol'd hard with this, thanks! :p
So, no updates at all? :D
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgpittushruqq.pgp
Description: PGP signature
[gentoo-dev] [warning] the bug queue has 102 bugs
Our bug queue has 102 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
[gentoo-dev] [warning] the bug queue has 114 bugs
Our bug queue has 114 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
[gentoo-dev] [warning] the bug queue has 114 bugs
Our bug queue has 114 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
[gentoo-dev] Lastrite: dev-java/qtjambi
# Alex Alexander wi...@gentoo.org (09 Dec 2010) # Requires Qt 4.5 which is old and not available in our tree anymore. # Upstream dropped official support after that Qt version. # Newer versions are available by a community port, but # there has been no interest for new ebuilds. # Masked for removal in 30 days. dev-java/qtjambi -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpgJy9UHG40Q.pgp Description: PGP signature
[gentoo-dev] [warning] the bug queue has 118 bugs
Our bug queue has 118 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On Mon, Jan 03, 2011 at 04:40:57PM +0200, Samuli Suominen wrote:
Quoting PMS, Chapter 8:
All ebuild-defined variables discussed in this chapter must be defined
independently of any system, profile or tree dependent data, and must
not vary depending upon the ebuild phase.
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob_plain;f=ebuild-vars.tex;hb=HEAD
This is very inconvinent rule for example, github tarballs where the
directory changes with every release. I've used this:
src_unpack() {
unpack ${A}
cd *-${PN}-*
S=`pwd`
}
In $PORTDIR/sys-fs/udisks-glue/udisks-glue-1.2.0.ebuild to get S=
defined as:
fernandotcl-udisks-glue-f9b4839
Where f9b4839 changes...
Far as I know, S= isn't used to generate metadata cache, so it's PMS
that need fixing for it's wording:
All ebuild-defined variables used to generate metadata cache, discussed
in this chapter...
Yes, please :)
I've used that method to work around some github-tarballed packages
as well, seems to work pretty well.
Thanks,
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgpGzstSRPxR3.pgp
Description: PGP signature
[gentoo-dev] [warning] the bug queue has 88 bugs
Our bug queue has 88 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
[gentoo-dev] Re: EAPI usage in main tree
On Tue, Jan 25, 2011 at 12:20:30PM +0100, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to upgrade tree-wide policy for EAPI usage in main tree. Currently we say that developers can use any named version they wish or find sufficient. I would on other hand like to have all ebuilds to use Latest EAPI version possible (given the eclasses support it [hint hint maintainers of eclasses should always try to support latest :P]) with expection for base-system or more specialy depgraph for portage that needs to be EAPI0. [[ And here we need to find out some upgrade proccess that would work for everyone so we could somehow migrate them too :)]] With this usually new developers should be aware only of latest EAPI and wont need to memorize what which EAPI support. Heck even I sometimes forget what i can do with some version and whatnot. Winner for being PITA in this race is python.eclass that HAS completely different behavior based on EAPI version used... I agree with the idea, however, just creating the policy won't be enough. We should make repoman print a warning if an older EAPI is used, maybe even refuse to commit (without -f), at least on version bumps, to get the devs' attention. base-system excluded for now, obviously. Cheers Tomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+sf4ACgkQHB6c3gNBRYeR6wCeNKsc8LnLw3ltkc1KKllzMP3u bXMAnRlbWZjGpQ7Zc2abdxtoJFKRVszS =lkXl -END PGP SIGNATURE- -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpyPp4InK8Yn.pgp Description: PGP signature
[gentoo-dev] EAPI 4 available, allowed in the main tree, ~testing ebuilds
Hello fellow devs, We're pleased to announce that EAPI 4 is now available and allowed in the main tree, in ~testing ebuilds :) New features in EAPI 4 include REQUIRED_USE, pkg_pretend, REPLACING_VERSIONS and REPLACED_BY_VERSION and various other interesting changes and fixes. To find out more about EAPI 4, you can read the latest version of the Package Manager Specification [0][1]. A shortlist of all the changes is also available there [2]. Please note that at this moment only ~testing Portage supports EAPI 4. This means that you'll have to avoid any stabilization of EAPI 4 ebuilds until a newer version of Portage is stabilized. Many thanks to all the people who worked to make EAPI 4 possible! [0] =app-doc/pms-4_p20110118 [1] http://dev.gentoo.org/~ulm/pms/4/pms.html [2] http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-172000E On behalf of the Gentoo Council, -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpF2dxzK0sgj.pgp Description: PGP signature
[gentoo-dev] [warning] the bug queue has 81 bugs
Our bug queue has 81 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
[gentoo-dev] [warning] the bug queue has 94 bugs
Our bug queue has 94 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
[gentoo-dev] [warning] the bug queue has 83 bugs
Our bug queue has 83 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On Sat, Mar 05, 2011 at 12:32:15AM +0100, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 4.3.2011 10:35, Paweł Hajdan, Jr. napsal(a): # Pawel Hajdan jr phajdan...@gentoo.org (04 Mar 2011) # Masked for removal in 90 days. # Multiple hard to fix and time consuming maintenance problems: # - history of bugs (bug #304527, bug #335101, bug #347175, #bug #349249, bug #356609) # - upstream's binary builds cannot be used on Gentoo #as easily as other -bin packages (ubuntu-specific #library names that require compatibility symlinks, #bundling libraries, mirror/redistribution policy, and so on) # - dependencies for the -bin package are harder to manage; #often we have source compatibility, but not binary compatibility www-client/chromium-bin Well I can't afford to compile it for 3 hours. Could you at least make it compile against system webkit? That would save so much time i would not complain :) What system webkit? Chromium has its own version of webkit :) Anyway, compilation on a modern system shouldn't take more than an hour. ~15-20 minutes on a quad i5. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgppKwus8FBgQ.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On Sat, Mar 05, 2011 at 12:51:23AM +0100, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 5.3.2011 00:46, Alex Alexander napsal(a): What system webkit? Chromium has its own version of webkit :) For this lovely thing it should be webkit-gtk Anyway, compilation on a modern system shouldn't take more than an hour. ~15-20 minutes on a quad i5. Do I look like I *censored* money? How am I supposed to build such system :D heh. then you should stick to stable releases and compile less frequently, the binary package is too painful to maintain [also known as a demotivator]. I can also give you a binpkg from one of my chroots :P -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpxsj09Qg3Cl.pgp Description: PGP signature
