[gentoo-dev] Re: Banning modification of pkg-config files (was: [gentoo-project] Re: Call For Agenda Items - 13 May 2014)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/09/2014 04:07 PM, hasufell wrote: I ask the council to vote on banning pkg-config files that would be added or renamed downstream (at least this will prevent new violations). I want to repeat my stance from the linked bug that making this a policy or calling on council to add more weight to existing devmanual bits is adding red tape that from my point of view decreases the quality of Gentoo. Asking me to remove the pkg-config file for lua-5.2 or removing the modifications to 5.1 will kill support for packages depending on these files existing. As long as there's stuff expecting the file to be around, I have a hard time committing a fix that will increase the breakage in the tree. Let me be clear: once packagers of lua using apps tell me they no longer need the .pc file for their stuff to work, I'll remove it promptly or switch to the reduced version you get from calling make pc for lua-5.2. However, all the linked bugs and commits seem to address the point that debian *renames* the lua .pc files. You seam to take particular issue with slotting lua (which requires us to rename them as well). I'm on the record saying that I don't like this solution. However, I've made it clear (and the eselect-lua module implements this) that there's always a lua.pc, liblua.so, etc of the user's chosing. It's also the only thing we got to resolve the stalemate of lua users lagging behind releases. If you have better ideas, please let me know. Since this is a technical matter, please direct further discussion to the gentoo-dev ML. Cheers, Matti -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTbRyhXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNzE1M0M4QzQxMzM4REREMjMzQjg4NUZE REY5NzFGMTE4RUVBNUU2AAoJEN35cfEY7qXmEGsP/39WprTJ9T4FmBiNO+xnPDS5 H3FbNmdN/YjyOy5OSBMbS2j9fxQXEJ5AdAeE5gWyEiNEji0wmecWqP2FNAEtoZ5c H4IJ92eSyw99zz424GU2eS0uNCkujn/xOIxWHmrvWiCiUYzF150KHl9nrRRdRrwB dKjyz7nXiEyZDS1dQ4gyTMeA6mUIrr0bFl0G8Kfy0dPWB0elpe837no/S/fRcKtM syb9+QL3TvYlCVbONkcFxtOQyij+9OTcMffITVysiHjy5+CNKoVjw3zKUPoYQN1f CSdob9x/W+vUrZt1gjEbxukqyBMlBokapvN1nwwi7T6IczHCPpDtnvN6TncX/0VW AkwB5wAgtxjsf6bu8vvx6D6gRYDoYFgXHe81m+SHfmbkDaIAUk67QdN3WHg4R0o7 fgJ5KVx5KowemNdM3SybJlTTOkt6ROaqkzMRsXDC+vDwQEZ4881zLpttGFfEJPjR tfej+FrhoMv5yir8joUIePwXLXluF1D0DO8RlrUpGTAFkwY1QqdA0ho3rwRpDZDT 70iWKepz6Xgj7mKlVjSF6C5iPxyKYMbgVgH+4IK4MCWYvam/tLwtbuegDmF/txUM 5P4a4fQUzvmGFmDOkRsnJBj5Gnez8J5DxzB3hmRJgT+TVKxlfRCQ4Ajh31VHQXun nw5cxcrYETn9jQtdmbqJ =JnYK -END PGP SIGNATURE-
[gentoo-dev] Last-rites: dev-php/PEAR-File_PDF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Matti Bickel m...@gentoo.org (21 Nov 2013) # Outdated, beta and abandoned upstream, removal on 20131220 dev-php/PEAR-File_PDF -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlKOcstfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM4NjQwRkYxM0E5ODM3Q0Q4MEE1MDJDMDdD RDMxQ0ExNDg0OUVDNkMACgkQfNMcoUhJ7GyKKwCcCNYw7l9XdeMipMZIVRhsnEnE 2mcAnRalL+mdPdkA4EouzJ4yDDe3oCz3 =Xc3l -END PGP SIGNATURE-
[gentoo-dev] Last-rites: dev-php/DBUnit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Matti Bickel m...@gentoo.org (13 Nov 2013) # Now included in dev-php/phpunit, removal on 20131213 dev-php/DBUnit -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlKEB3tfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM4NjQwRkYxM0E5ODM3Q0Q4MEE1MDJDMDdD RDMxQ0ExNDg0OUVDNkMACgkQfNMcoUhJ7GzCFACgijb0WfgzGFBJ10zGSkCHhTey OoUAn2hraL8ZDx7T1W6OtUciOaPxbebC =wP3I -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/2013 11:17 AM, Amadeusz Żołnowski wrote: Quoting Pacho Ramos (2013-01-17 20:21:30) # Pacho Ramos pa...@gentoo.org # Still uses depend.php (#449820), upstream dead for ages and # newer versions don't work. Removal in a month. www-apps/online-bookmarks Is there any goog alternative? Maybe one of these? http://lifehacker.com/5540019/five-best-bookmark-management-tools -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEOQ1YACgkQfNMcoUhJ7GzIXQCeMTohwB5Wv0UO5RfCAcqs+iC6 qSEAn0z9RKYR1kCmR1lEdbKdkVfGQyI0 =HQI6 -END PGP SIGNATURE-
[gentoo-dev] Last rites: www-apps/phpwiki
# Matti Bickel m...@gentoo.org (26 Jun 2012) # Dead upstream. Use any other wiki software like ikiwiki. # Removal on 26th Jul 2012 www-apps/phpwiki
[gentoo-dev] Last-rite for dev-php/PEAR-DB_DataObject_FormBuilder
# Matti Bickel m...@gentoo.org (18 Mar 2012) # masked for removal in 30 days, ~15 Apr 2012 # unmaintained upstream (bug #396963) dev-php/PEAR-DB_DataObject_FormBuilder
[gentoo-dev] [FYI] php-lib-r1.eclass going to die
Hi folks,
I thought I'd throw this out, so nobody is suprised when I start to put
qawarns in the eclass: I don't think php-lib-r1.eclass has any value now
that we have EAPI4. The only thing it basically does is
a) setting RDEPEND=dev-lang/php
and
b) provide a php_lib_r1_src_install that accepts as its parameters the
destination directory and the files to add. It then stores them
/usr/share/php/${PN}/$1.
Everything the eclass does can be done more cleanly and explictly inside
the ebuild. So if you planned to inherit php-lib-r1, please don't. Just
add the RDEPEND and use
src_install() {
insinto /usr/share/php/${PN}
doins -r your src/* (or wherever you stored your files)
dodoc README
}
as an example. I've also converted most of the ebuilds in our tree to do
this.
If your ebuild relied on php-lib-r1 to provide depend.php - shame on you
:p - depend.php will share the fate of php-lib-r1. But that's another mail.
Cheers, Matti
[gentoo-dev] Lastrite: dev-php/PEAR-I18N
# Matti Bickel m...@gentoo.org (16 Jan 2012) # Now part of dev-lang/php; merge it with USE=intl # Removal in 30 days, bug #396975 dev-php/PEAR-I18N
[gentoo-dev] Relinking fun with libtool
Hi folks, coming back from an extended vacation I found bug #351266[1] still open. The root cause of this install failure seems to be libtool trying to relink php's apache module. I'm not entirely sure what causes this (as my system doesn't relink the library), but more importantly I failed to find information on what's the best way to deal with this situation. So far, every google hit I've found suggested that just going ahead w/o relinking worked fine, which also seems to be the case in the referenced bug. So that leaves me with either: a) remove the relink_command from libphp5.la before calling emake install-sapi b) modifying the libdir in libphp5.la before calling emake install-sapi to point to $D/usr/lib/... c) finding out why libtool decides it needs to relink at all. Clearly, requiring users to edit the la file by hand is no solution. I've not found other ebuilds dealing with relinking, so is this me just misunderstanding how libtool works or an issue with php's build system? I'm quite at a loss here. I'd be glad if somebody with more libtool knowledge can shed some light (or point me to some docs) on why relinking is necessary here at all and how to fix this breakage. [1]https://bugs.gentoo.org/show_bug.cgi?id=351266 signature.asc Description: OpenPGP digital signature
[gentoo-dev] FYI: Moving packages from dev-php5 to dev-php
Hi all, this is a quick note that the php team (well, Ole and me) has decided to kill of the dev-php5 category. We think it's confusing and the distinction of which packages go where isn't as clear as it should be. I find myself regularly looking in dev-php instead of dev-php5. As php extensions (which should be in dev-php5 now) may now break on minor versions changes of php, the dev-php5 name is not as appropiate as it was with php4 still around. So we're going to remove it. This will not be an overnight change. We intend to move packages from dev-php5 to dev-php starting this weekend (29./30.1.) and be finished sometime next month. Packages pending a revision or version bump will go first. You can post all issues (if any) to our tracker bug #324665. Any advice and feedback welcome. EOM signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions
On 01/27/2011 05:30 PM, Ciaran McCreesh wrote: No, since there's no such thing as an app that's guaranteed to be portable. What about app-doc/php-doc? Yeah, single use case. But I feel stupid requesting keywords for it. It's all text. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions
On 01/27/2011 06:59 PM, Tomáš Chvátal wrote: Adding ebuilds with noarch keyword must be preceded with: All ebuilds seeking to have this feature implemented must be discussed on #gentoo-dev mailing list and proven not having portability issues. So instead of opening a bug for all arches, I post each new version of php-doc to -dev? While I'm all for ~allarches, I see that the overhead of *proving* to another party that my ebuild won't break is both neccessary and absurd. Creating ~allarch packages should make things easier, not harder. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions
On 01/27/2011 07:42 PM, Tomáš Chvátal wrote: Only to gain the ~allarch. When it gains it gets tested by arch member of any team and stabled. Verstanden? :) Yep, I think I did. But what if introduce, say, a non-portable find command into a new revision that breaks on some arches. I'll carry over ~allarch for this revision, I even test it on my amd64 machine. Only to find prefix/bsd users screwed and wanting my head ;) So to continue having my stuff ~allarch, I'd need to post my modified ebuild to -dev again, right? Writing portable (shell) code is a lot harder than normal ebuild writing, as most of the issues won't come up on my machine and I'm simply not experienced enough with portability issues. So I'd find myself posting every change to -dev, just in case. So while the idea is intriguing, I think it won't help. Arch teams will have to recheck new revisions for conformance. The time taken to do this could be already spent on marking it arch. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] On hosting self-produced distfiles
On 01/20/2011 01:50 AM, Diego Elio Pettenò wrote: I just wanted to write here a clarification regarding self-produced distfiles, such as patchset tarballs, SCM snapshots and the like. Some people seem under the impression that the correct way to host these is to use mirror://gentoo/ and copy them on /space/distfiles-local on dev.g.o. Please don't do this. As one of those under the impression that mirror://gentoo was the right choice: why is it bad? From Fauli's post I gather the emacs team wanted to support ancient versions and have all files necessary to install an ebuild whatsoever it's age. In my case, that would mean installing php-4.0, for example. Why on earth should I support something like that? If I'm PHP upstream, okay, maybe allow others to see the evolution of the language. But the evolution of the php patchset? Sounds not that necessary to me. So, I'm not opposed to your idea. If ya want to archive your stuff forever, by all means do it. I just see no point in forcing this on all devs. So, care to explain or give me pointer on why this is necessary? Thanks, Matti signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: On hosting self-produced distfiles
First, thanks for pointing this out. On 01/20/2011 07:51 PM, Diego Elio Pettenò wrote: License compliance when distributing binaries; Not sure what you mean: if someone quickpkg's php and needs all the source? Well, they already downloaded them. Better keep them around, since it's *your* binary, not mine. distributions built upon Gentoo that might use old and set-in-stone Portage trees; Same thing, as already pointed out in another message. I see the point in making it easier for them. That's okay. So what you're saying is we're upstream too and upstream's should provide their historical stuff. security issues that might be reported and needs to be investigated, ... If you're reporting a security issue in a ebuild that's no longer in tree (in php's case, chances are it got removed b/c of security :p), the bug wouldn't be investigated, right? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: On hosting self-produced distfiles
On 01/20/2011 08:42 PM, Diego Elio Pettenò wrote: We do distribute part of our packages as binaries already so we have to be compliant with their licenses to begin with. Better doing it with a single sweep than trying to come up with abstruse case-by-case points, no? No. Licenses are not a valid argument to me. I'd accept that if we're Debian and pushing 100% of *our* stuff as binary. What we do 90% of the time is distributing text - ebuilds. Arguing against this is just getting to the point of arguing because somebody is doing what nobody did for a long time: taking decisions. Yes, and I'm not going to stop you. Frankly, I don't care enough where my tarballs end up. I just was curious about the reasons, as I see no compelling point in *forcing* this. If you're reporting a security issue in a ebuild that's no longer in tree (in php's case, chances are it got removed b/c of security :p), the bug wouldn't be investigated, right? There are cases and cases there; in the case of _custom_ tarballs, I'd expect us to investigate if the security issues was found on our version and not in the upstream-provided one for instance. Take php-5.3.2: I don't care if you found a security issue in my tarball or in php's tarball. I'll have a look to determine if the bug's still in the newest version. If it is, I'll rename the bug. If it is not, it doesn't matter to me. Once again, please tell me: what does it change to you? If anybody should complain about this request is Infra. What it changes for me? The target argument of my scp command. Which is so small that I don't care (see above for why I still replied). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Sandbox violation?
On 01/12/2011 02:53 AM, Ajai Khattri wrote: C: /usr/bin/php-cgi -v -d session.save_path=/tmp OK, this is a masked ebuild but what does this actually mean and how can we fix it? Which version of php is this? All php versions we (the php team) maintain should have been fixed so this doesn't occur. We specifically check for this path and poke a hole in the sandbox for it. If this occurs with php-5.2.17 and/or php-5.3.5, please file a bug at bugs.gentoo.org about it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What are || ( ) dependencies?
On 12/18/2010 08:35 PM, Ryan Hill wrote: On Fri, 17 Dec 2010 15:25:04 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? I already thought that was the case, so +1 from me. Me too, but can't tell where I picked that up. +1 anyway. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Extending EAPI=4
On 10/25/2010 06:23 PM, Petteri Räty wrote: On 10/25/2010 04:24 PM, Arfrever Frehtes Taifersar Arahesis wrote: I would like to request that 2 additional features are added to EAPI=4. These features will be needed for further development of python.eclass. 1. Support for . characters in names of USE flags Ideally we should have consistency across languages so if we go down this road then for example ruby should eventually support it too. Ruby people: can you provide your input. PHP could potentially benefit from this, we currently (see php-ext-source-r2.eclass) have to use - instead of the dot. But to my eyes the ugliness is acceptable. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/php/files/eblits: src_configure-v1.eblit src_configure-v2.eblit
On 10/24/2010 02:07 PM, Samuli Suominen wrote: On 10/24/2010 02:48 PM, Matti Bickel (mabi) wrote: -phpconfutils_extension_with pdo-sqlite sqlite 1 /usr +phpconfutils_extension_with pdo-sqlite sqlite3 1 /usr That's a regression (because USE=sqlite3 is deprecated). Thanks, didn't know that. Here's why I still think this is the best choice at least for the time being (until the next php upstream release): PHP upstream enables both sqlite and sqlite3 by default. We decided to stick with upstream as much as possible, because it makes reporting bugs so much easier and is nice to our users. Additionally, I dare say that they're probably still some people using sqlite2 with PHP (maybe as session storage - that's only available with sqlite2). I don't want to take a perfectly fine option (for now) from them. That said, sqlite2 is deprecated upstream and will show as such in whatever their next release will be. I'll gladly drop the sqlite2 extension as soon as upstream does. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On 09/19/2010 10:49 PM, Andreas K. Huettel wrote: Wouldn't it also make sense to have per-category eclasses? This seems much more useful for me. Yes, probably. But it'll be enough getting per-package eclasses in, right now. I'll revisit this when we finally merge dev-php5 and dev-php. If other teams want to spin this - just go for it :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On 09/26/2010 03:22 PM, Ciaran McCreesh wrote: Isn't the amount of work to get per-package eclasses basically the same as the amount of work to get per-(package and category) eclasses? Actually, I don't know. Tell me. I've no clue how much PM implementation effort this will be, yet. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: per package eclass GLEP
On 09/20/2010 12:00 AM, Duncan wrote: Given that no set eapi is taken to be eapi=0, and this is proposed as part of a new eapi, eapi MUST be set before pkg-inherit, if pkg-inherit and thus per-pkg eclasses are to be used at all. The last sentence of the top paragraph (of the two) should therefore be rewritten to reflect that requirement and avoid any confusion. You're right. I'll remove the if it is set part. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On 09/20/2010 07:30 PM, Alec Warner wrote: Under the new system I can put the code: 1) In a global eclass, any ebuild can likely use it 2) In a per-package eclass, only one package can use it 3) In a pkg eblit, only one package can use it Per package eclasses are pretty much eblits with some PM support thrown in. Wouldn't taking code from a global eclass and moving it to a per-package eclass limit code re-use? No, code reuse will stay the same. What I like about the idea is moving more of the code closer to the ebuild files, tightening it's scope. No more wondering (as an ebuild author) if and how I could use php5_2-sapi.eclass - it just wouldn't be there. I'll answer more points tomorrow, but thanks for your ideas! signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: per package eclass GLEP
I'm a couple weeks late with this, but here goes: from my failed attempts at reviving GLEP33 grow a discussion with ferringb on IRC about how to get what I wanted anyway :) We agreed that having eclasses specific to a package located someplace near the actual ebuilds was beneficial and should be supported by PMs somehow. Someplace and somehow are specified along some other details in the attached proposed GLEP. I'm posting this for review by the wider community, at the same time asking the GLEP editors (antarus? pva?) for guidance on the formalities. I gather the GLEP should get a number and be uploaded in CVS somewhere, as well as appear on the GLEP project page. So, yeah, what do you think? Is it worth it? Can the draft be improved? I'm specifically interested in the amount of work involved in supporting something like the thing laid out in the GLEP in our current PMs. GLEP: 62 Title: Per package eclasses Version: Last-Modified: Author: Matti Bickel m...@gentoo.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: Post-History: Abstract This document proposes a new kind of eclasses, which are specific to a certain package (hence per-package eclasses). It explains the current need for package specific eclasses, the proposed solution and a possible migration path. What is proposed is, in short, creation of eclasses in package directories for use by the ebuilds of the package in the same directory. Per-package eclasses can be thought of (broadly speaking) as normal eclasses used only by one package. Motivation and Rationale Gentoo currently provides 211 eclasses as of 14-08-2010, 36 of which are marked @DEAD and are scheduled for removal. At least three non-dead eclasses are specific to one package (mysql, php5_2-sapi and nvidia-drivers). The sheer number of eclasses makes it hard for old and new developers to quickly find the eclass they are looking for. Providing overlays and working on a single package also is not as easy as it should be. Last but not least, eclasses provided in the package directory could be part of the package's Manifest file, providing part of the eclass signing the Gentoo tree still lacks. Placing the package specific eclasses into the package directories themselves solves all of the problems mentioned (at least partly). It will reduce the clutter in the current eclass directory, provide a single directory to understand an ebuild and provides security benefits by including the eclasses in the Manifest file. Specification = The per-package eclasses are specified to be placed directly under the package directory (as described in [1]_). The eclass may have any name permissible for other eclasses (specifically, must end with .eclass). A per-package eclass is included in an ebuild by a new function ``pkg-inherit`` called in the global scope of the ebuild. The ``pkg-inherit`` function must be given zero or more arguments. If no argument is given, the function shall behave like it was called with the argument ``default``. It is specified to search the package directory of the calling ebuild (but no other directories) for eclasses with the names of the arguments and the suffix .eclass. If such files exist, they must be sourced by the function. If not specified otherwise below, the package manager shall treat the per-package eclass as a normal eclass in any other respect. It is made a requirement that per-package eclasses can not modify the ``EAPI`` variable. It is assumed ``EAPI``, if it set, is set before calling pkg-inherit. Backwards Compatibility === The current Package Manager Specification requires package managers to ignore anything in the top-level package directory that does not have a filename ending in .ebuild ([1]_). Thus package manager which do not implement the per-package eclass feature can ignore them. They, however, will fail to execute ebuilds making use of the new ``pkg-inherit`` function. It is therefore required this feature be made part of a new EAPI. Additionally, tools that regenerate the Manifest file should be aware of per-package eclasses. However, this is only of concern to developers regenerating Manifests in a specific package directory. It is assumed that whoever changes functionality in a package also uses tools capable of supporting features used in the package's ebuilds. Copyright = This document has been placed in the public domain. .. [1] http://distfiles.gentoo.org/distfiles/pms-3.pdf, Section 4.3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: fox.eclass update
Hi folks, The fox eclass accumulated a lot of cruft over the years. Specifically, it includes quite a bit of code to support versions loong gone from our tree. The only officially supported versions now are 1.6 and 1.7. Thus, I've edited it a bit. Main points are EAPI2 phase support and a lot of variable quoting. Posting this for review as the diff is rather largish and I'm known to have the usual typo in it ;) Comments welcome. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: fox.eclass update
On 09/16/2010 04:41 PM, Jeremy Olexa wrote:
Hey Matti, few quick things.
Thanks, all done. FOXCONF is now documented (though not set by default).
Updated diff and eclass attached.
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: fox.eclass
# @MAINTAINER:
# m...@gentoo.org
# @BLURB: Functionality required the FOX Toolkit and it's applications
# @DESCRIPTION:
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
# parallel-installable, while installing only one version of the utils
# (dev-util/reswrap) and apps (app-editors/adie, sci-calculators/calculator,
# x11-misc/pathfinder, and x11-misc/shutterbug).
#
# Version numbering follows the kernel-style odd-even minor version
# designation. Even-number minor versions are API stable, which patch
# releases aimed mostly at the library; apps generally won't need to be
# bumped for a patch release.
#
# Odd-number versions are development branches with their own SLOT and
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
# Here are sample [R]DEPENDs for the fox apps
# 1.6: 'x11-libs/fox:1.6'
# 1.7: '~x11-libs/fox-${PV}'
#
# EAPI phase trickery borrowed from enlightenment.eclass
inherit autotools versionator
FOX_EXPF=src_unpack src_compile src_install pkg_postinst
case ${EAPI:-0} in
2|3|4) FOX_EXPF+= src_prepare src_configure ;;
*) ;;
esac
EXPORT_FUNCTIONS ${FOX_EXPF}
# @ECLASS-VARIABLE: FOX_PV
# @DESCRIPTION:
# The version of the FOX Toolkit provided or required by the package
FOX_PV=${FOX_PV:-${PV}}
# @ECLASS-VARIABLE: FOXVER
# @INTERNAL
# @DESCRIPTION:
# The major.minor version of FOX_PV, usually acts as $SLOT and is used in
# building the applications
FOXVER=`get_version_component_range 1-2 ${FOX_PV}`
# @ECLASS-VARIABLE: FOX_APPS
# @INTERNAL
# @DESCRIPTION:
# The applications originally packaged in the FOX Toolkit
FOX_APPS=adie calculator pathfinder shutterbug
FOX_CHART=chart
# @ECLASS-VARIABLE: FOXCONF
# @DEFAULT_UNSET
# @DESCRIPTION:
# Set this to add additional configuration options during src_configure
DESCRIPTION=C++ based Toolkit for developing Graphical User Interfaces easily
and effectively
HOMEPAGE=http://www.fox-toolkit.org/;
SRC_URI=http://www.fox-toolkit.org/ftp/fox-${FOX_PV}.tar.gz;
IUSE=debug doc profile
if [ ${PN} != fox ] ; then
FOX_COMPONENT=${FOX_COMPONENT:-${PN}}
fi
if [ -z ${FOX_COMPONENT} ] ; then
DOXYGEN_DEP=doc? ( app-doc/doxygen )
fi
if [ ${PN} != reswrap ] ; then
RESWRAP_DEP=dev-util/reswrap
fi
DEPEND=${DOXYGEN_DEP}
${RESWRAP_DEP}
=sys-devel/automake-1.4*
=sys-apps/sed-4
S=${WORKDIR}/fox-${FOX_PV}
fox_src_unpack() {
unpack ${A}
cd ${S}
hasq src_prepare ${FOX_EXPF} || fox_src_prepare
}
fox_src_prepare() {
# fox changed from configure.in to configure.am in 1.6.38
local confFile=configure.ac
[[ -r configure.in ]] confFile=configure.in
# Respect system CXXFLAGS
sed -i -e 's:CXXFLAGS=::' $confFile || die sed ${confFile} error
# don't build apps from top-level (i.e. x11-libs/fox)
# utils == reswrap
for d in ${FOX_APPS} utils windows ; do
sed -i -e s:${d}:: Makefile.am || die sed Makefile.am error
done
# use the installed reswrap for everything else
for d in ${FOX_APPS} ${FOX_CHART} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die sed ${d}/Makefile.am error
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
sed -i \
-e s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox-${FOXVER}: \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
-e 's:\.la::' \
${d}/Makefile.am || die sed ${d}/Makefile.am error
done
eautoreconf
}
fox_src_configure() {
use debug FOXCONF+= --enable-debug \
|| FOXCONF+= --enable-release
econf ${FOXCONF} \
$(use_with profile profiling)
}
fox_src_compile() {
hasq src_configure ${FOX_EXPF} || fox_src_configure
cd ${S}/${FOX_COMPONENT}
emake || die compile error
# build class reference docs (FOXVER = 1.2)
if use doc [ -z ${FOX_COMPONENT} ] ; then
cd ${S}/doc
make docs || die doxygen error
fi
}
fox_src_install() {
cd ${S}/${FOX_COMPONENT}
emake install \
DESTDIR=${D} \
htmldir=/usr/share/doc/${PF}/html \
artdir=/usr/share/doc/${PF}/html/art \
screenshotsdir=/usr/share/doc/${PF}/html/screenshots \
Re: [gentoo-dev] RFC: fox.eclass update
On 09/16/2010 08:32 PM, Peter Volkov wrote:
В Чтв, 16/09/2010 в 16:24 +0200, Matti Bickel пишет:
+FOXVER=`get_version_component_range 1-2 ${FOX_PV}`
It's better to prefer $() style over ``:
http://mywiki.wooledge.org/BashFAQ/082
Hmm, I prefer Backticks personally, as I like to conserve space whenever
possible. But for consistency with the rest of the tree, I changed that
to $() in the diff.
- elibtoolize
+ eautoreconf
Hm, is this change necessary?
I might be missing something here, but the change in recent fox versions
to configure.ac instead of configure.in forces a run of autoconf, afaik.
Thanks for the comments, updated eclass attached.
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: fox.eclass
# @MAINTAINER:
# m...@gentoo.org
# @BLURB: Functionality required the FOX Toolkit and it's applications
# @DESCRIPTION:
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
# parallel-installable, while installing only one version of the utils
# (dev-util/reswrap) and apps (app-editors/adie, sci-calculators/calculator,
# x11-misc/pathfinder, and x11-misc/shutterbug).
#
# Version numbering follows the kernel-style odd-even minor version
# designation. Even-number minor versions are API stable, which patch
# releases aimed mostly at the library; apps generally won't need to be
# bumped for a patch release.
#
# Odd-number versions are development branches with their own SLOT and
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
# Here are sample [R]DEPENDs for the fox apps
# 1.6: 'x11-libs/fox:1.6'
# 1.7: '~x11-libs/fox-${PV}'
#
# EAPI phase trickery borrowed from enlightenment.eclass
inherit autotools versionator
FOX_EXPF=src_unpack src_compile src_install pkg_postinst
case ${EAPI:-0} in
2|3|4) FOX_EXPF+= src_prepare src_configure ;;
*) ;;
esac
EXPORT_FUNCTIONS ${FOX_EXPF}
# @ECLASS-VARIABLE: FOX_PV
# @DESCRIPTION:
# The version of the FOX Toolkit provided or required by the package
FOX_PV=${FOX_PV:-${PV}}
# @ECLASS-VARIABLE: FOXVER
# @INTERNAL
# @DESCRIPTION:
# The major.minor version of FOX_PV, usually acts as $SLOT and is used in
# building the applications
FOXVER=$(get_version_component_range 1-2 ${FOX_PV})
# @ECLASS-VARIABLE: FOX_APPS
# @INTERNAL
# @DESCRIPTION:
# The applications originally packaged in the FOX Toolkit
FOX_APPS=adie calculator pathfinder shutterbug
FOX_CHART=chart
# @ECLASS-VARIABLE: FOXCONF
# @DEFAULT_UNSET
# @DESCRIPTION:
# Set this to add additional configuration options during src_configure
DESCRIPTION=C++ based Toolkit for developing Graphical User Interfaces easily
and effectively
HOMEPAGE=http://www.fox-toolkit.org/;
SRC_URI=http://www.fox-toolkit.org/ftp/fox-${FOX_PV}.tar.gz;
IUSE=debug doc profile
if [[ ${PN} != fox ]] ; then
FOX_COMPONENT=${FOX_COMPONENT:-${PN}}
fi
if [[ -z ${FOX_COMPONENT} ]] ; then
DOXYGEN_DEP=doc? ( app-doc/doxygen )
fi
if [[ ${PN} != reswrap ]] ; then
RESWRAP_DEP=dev-util/reswrap
fi
DEPEND=${DOXYGEN_DEP}
${RESWRAP_DEP}
=sys-devel/automake-1.4*
=sys-apps/sed-4
S=${WORKDIR}/fox-${FOX_PV}
fox_src_unpack() {
unpack ${A}
cd ${S}
hasq src_prepare ${FOX_EXPF} || fox_src_prepare
}
fox_src_prepare() {
# fox changed from configure.in to configure.am in 1.6.38
local confFile=configure.ac
[[ -r configure.in ]] confFile=configure.in
# Respect system CXXFLAGS
sed -i -e 's:CXXFLAGS=::' $confFile || die sed ${confFile} error
# don't build apps from top-level (i.e. x11-libs/fox)
# utils == reswrap
for d in ${FOX_APPS} utils windows ; do
sed -i -e s:${d}:: Makefile.am || die sed Makefile.am error
done
# use the installed reswrap for everything else
for d in ${FOX_APPS} ${FOX_CHART} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die sed ${d}/Makefile.am error
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
sed -i \
-e s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox-${FOXVER}: \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
-e 's:\.la::' \
${d}/Makefile.am || die sed ${d}/Makefile.am error
done
eautoreconf
}
fox_src_configure() {
use debug FOXCONF+= --enable-debug \
|| FOXCONF+= --enable-release
econf ${FOXCONF} \
$(use_with profile profiling)
}
fox_src_compile() {
hasq src_configure ${FOX_EXPF} || fox_src_configure
cd ${S}/${FOX_COMPONENT}
emake || die
Re: [gentoo-dev] RFC: fox.eclass update
On 09/16/2010 09:29 PM, Mike Frysinger wrote:
+if [[ -f ${D}/usr/bin/fox-config ]] ; then
+mv ${D}/usr/bin/fox-config ${D}/usr/bin/fox-${FOXVER}-config
fi
seems like you would want || die here
Why? I can't imagine how that could fail.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On 08/05/2010 05:27 AM, Brian Harring wrote: If a PM encounters an EAPI it doesn't understand/support, by definition the metadata it tried generating is not usable- the PM doesn't support that new EAPI thus it has zero clue how to generate/store metadata appropriately for that EAPI. I guess the point here is that we need a stable version of PMs for a reasonable time before we switch tree ebuilds to it. People will hate me if I use EAPI4 functionality in php ebuilds as soon as councils approves EAPI4. Security might want a word with me if it's a fast-stable security release. But this is orthogonal to GLEP55, afaik. Bad. So I guess it's back to ferring's use a new directory not readable by old PMs idea. GLEP55++, but having to wait several months for that and GLEP33 *on top* is not very motivation for me. The reason for a new directory was to enforce a new structuring that was more friendly to changelogs and manifests- due to ECLASSDIR being documented in PMS (and annoyingly eclass-manpagers being the sole consumer of it) adding a new eclasses directory should require a EAPI bump. I'm not going to argue that PMS doesn't seem to say anything about the content of ECLASSDIR other than that eclasses are stored inside it. A new dir is fine with me. Can we have that in EAPI4 or is that already being finalized? As for per package eclasses, I'd personally require accessing the package eclass being done via a new inherit function- this avoids some annoying gotchas. That said, I don't see a reason right now that it couldn't be added into an EAPI, per the reasons I laid out earlier in this email. Okay, so how can I, as somebody not familiar with PM dev process and roadmaps, help in getting this done? signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: Reviving GLEP33
Hi folks, I've been told that my use of eblits in dev-lang/php is something I should get rid of as soon as possible. Suggested alternative by ferring: use elibs. So here goes: I want to see GLEP33[1] implemented in portage, so I can shift the eblits core and currently global functions into elibs and probably push the eblits I use for php into the same structure. Basic question: what needs to be done to get this GLEP accepted and implemented (it's current status is moribound)? I extracted a list of things we (or rather the portage and all other PM teams) need to do: (1) create elibs() function to enable importing elibs (2) extend repoman to handle new style elibs and eclass signing/checking (3) profit ;) Also, there're some question I have: (1) The GLEP (under The reduced role of Eclasses,[...]) speaks of Cases where the constant [metadata] requirement is violated are known - who exactly are the current offenders? (2) What's the dev community feeling on The end of backwards compatibility... section in the GLEP? Personal opinion: when the council reached consensus that old eclasses can be removed with due last-rites, this section became obsolete. Just putting new-style eclasses in their own dirs in eclass/ might again be an option. Please discuss. (3) Continuing with (2) do you feel we still need to provide a eclass compat build (tarball) to users *still* not using a sane portage version? If no, section The start of a different phase of backwards compatibility can probably be stripped from the GLEP. I silently assumed that our infra servers are running =portage-2.1.4.4 here. Instead of all the backwards-compatibility issues the GLEP deals with, we could just sneak the implementation into EAPI4 and be done with it. [1] http://www.gentoo.org/proj/en/glep/glep-0033.html signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On 08/02/2010 08:16 PM, David Leverton wrote: On 2 August 2010 12:11, Brian Harring ferri...@gmail.com wrote: On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: Hi folks, I've been told that my use of eblits in dev-lang/php is something I should get rid of as soon as possible. Suggested alternative by ferring: use elibs. There's a couple of hundred lines of repeated metadata between php-5.3.2 and php-5.3.3 - not identical, but similar enough that there would be gains from factoring it out, and elibs won't help with that. Sure. I was thinking of providing php.eclass with the common metadata for php-5*, including patchset code, core DEPEND and the like. With the php team rather stretched nowadays, it will take a few days before that'll happen. I'm still trying to cope with the complexity of the whole php eco-system. Am I understanding correctly in that you didn't use an eclass to avoid cluttering up the main eclass directory with something specific to this one package? Yes. Actually, that was hoffie's goal, when he decided to use eblits. I continued this and actually made php5_2-sapi.eclass obsolete by using eblits in php-5.2.14. Interesting sidenote: I only needed one more eblit for this - the amount of code shared went through the ceiling. If so, it sounds like what you really want is per-package eclasses (maybe with elibs as well to hold the non-metadata code), which aren't covered by GLEP33 but ought to be easy enough to add. It's actually covered by GLEP33: http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring And yes, it's one of it's most obvious advantages. I hate the clutter of php-* eclasses with passion (I'm aware most of them serve a good purpose). My suggestion? Split this into two, elibs, and eclass refactoring. Per-package eclasses would be beneficial IMHO regardless of the other eclass stuff from 33, might be worth thinking about those as another item (consistent with the existing design plans of course) if the rest isn't going to happen soon. If we can get that going asap without waiting, I'm all for it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On 08/02/2010 09:51 PM, Mike Frysinger wrote: On Monday, August 02, 2010 05:56:08 Matti Bickel wrote: I've been told that my use of eblits in dev-lang/php is something I should get rid of as soon as possible. current eblits support isnt going anywhere. so dont waste time trying to change code if there is no real alternative. see Bug 327999. Yes, from my reading GLEP33 wouldn't solve bug #327999. But that's a different issue, isn't it? I don't see how elibs are not an alternative for eblits. What can you do with eblits you can't do with elibs? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On 08/03/2010 12:17 AM, David Leverton wrote:
On 2 August 2010 22:40, Matti Bickel m...@gentoo.org wrote:
On 08/02/2010 08:16 PM, David Leverton wrote:
If so, it sounds like what you really want is per-package eclasses
(maybe with elibs as well to hold the non-metadata code), which
aren't covered by GLEP33 but ought to be easy enough to add.
It's actually covered by GLEP33:
http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring
I interpreted that more as a way to organise the global eclasses
Yes, I thought you were talking about them. Introducing eclasses into
the rest of the tree - is that possible from the implementation side?
That is, how can PMs support that w/o much hassle? Are there any speed
considerations that need to be taken into account?
I like the idea. Having dev-lang/php/php-common.eclass makes a lot more
sense then putting it into ${PORTDIR}/include/eclass.
PHP will still need global eclasses for PEAR and pecl stuff, so I like
them moving forward, too. And hiding them into
${PORTDIR}/include/eclass/php/ might be a good first step.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
On 07/17/2010 07:02 PM, Petteri Räty wrote: Do stabilisations on the security bug so arch team members can skim through their stabilisation list by just looking for secur...@g.o to find the vulnerable packages. V-Li If you want things to happen this way then it should be at least documented in the devmanual. It's in the security project's policy: once an ebuild is committed, evaluate what keywords are needed for the fix ebuild and get arch-specific teams to test and mark the ebuild stable on their architectures (arch-teams should be cc'd on the bug, as well as releng during release preparation) and set status whiteboard to stable http://www.gentoo.org/security/en/vulnerability-policy.xml, Chapter 4 As the CC'ing should be done by the security folks/the maintainer when a new ebuild is ready, I don't think it needs to be in devmanual. The relevant people should be aware of the process. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
On 07/17/2010 07:58 PM, Petteri Räty wrote: As the CC'ing should be done by the security folks/the maintainer when a new ebuild is ready, I don't think it needs to be in devmanual. The relevant people should be aware of the process. If relevant people already know the policy and act accordingly then why do we have this thread in the first place? Dunno, I take it as a friendly reminder. People can slip up. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: eclass/php5_1.eclass
Hi, 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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: eclass/php5_1.eclass
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. signature.asc Description: OpenPGP digital signature
Re: Allow eclasses to have fluid APIs (was: [gentoo-dev] RFC: remove php4 from depend.php and others)
On 07/10/2010 10:34 AM, Brian Harring wrote: If people want to allow eclasses to have fluid APIs (specifically removal of functionality), that's a discussion that needs to start on the dev level. Anyone got strong opinions on this one? The argument was presented a long time before: we can't care about things not in our tree, there might be thousands of twisted ways our eclasses are used we can't control. If nothing is broken in gentoo-x86, we as developers should be allowed to make the change. To ensure the change is indeed not breaking stuff, RFCs to -dev are a requirement. Everybody who copied and re-used our eclasses should be reading -dev (or at least -dev-announce), anyway. Not our fault if they run an open system (as in, I've not nailed all my versions down and use a static tree) and do not keep up with it. Now, I'm aware that RFC and implementation periods should depend on the impact of the change - if I'm proposing to alter eutils, I better wait some time AFTER a conclusion has been reached, so everybody can adapt. That 'should' above is intentional - prescribing a fixed time period for every possible change does not give devs enough flexibility and implementation time may be a subject during RFC anyway. To continue the eutils example: if I keep a custom overlay which depends on the removed functionality, I will speak up and ask you defer the change 14 days so I can fix my overlay. Similarly, if somebody still uses the php4 bits in depend.php eclass, please speak up and allow me to convince you of the php5 ways :-) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-php5/znf
Late to the party, but anyway: # Matti Bickel m...@gentoo.org (04 Jul 2010) # Dead upstream (bug #324825) # Masked for removal in 30 days dev-php5/znf signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: removal of virtual/php from depend.php
Hi,
in concert with bug 319623 the php team would like to remove virtual/php
from the depend.php eclass. This will change DEPEND and RDEPEND strings
for quite some packages.
The basic idea is:
virtual/php is only provided by dev-lang/php and has been for quite some
time now. There are no plans to split php again. So all ebuilds that
need a PHP installation should just depend on dev-lang/php.
For convenience we still provide virtual/httpd-php, which will give you
php and a webserver able to display your php sites.
So we're replacing virtual/php with dev-lang/php in depend.php.
Question is: do we need depend.php-r1 for this? Did I miss some
important point about the change?
Yes, this eclass requires EAPI=2 and I will not commit the change to
this eclass until every ebuild using it has migrated. If that's not
feasible, I'll use depend.php-r1.
Patch attached. Thanks to Ole Markus With, it's actually his work and
I'm just helping fleshing out ideas and directions here.
diff --git a/eclass/depend.php.eclass b/eclass/depend.php.eclass
index 003ac46..681e6dd 100644
--- a/eclass/depend.php.eclass
+++ b/eclass/depend.php.eclass
@@ -25,8 +25,8 @@ inherit eutils phpconfutils
# Set this after setting DEPEND/RDEPEND in your ebuild if the ebuild requires PHP4
# with cli SAPI.
need_php4_cli() {
- DEPEND=${DEPEND} =virtual/php-4*
- RDEPEND=${RDEPEND} =virtual/php-4*
+ DEPEND=${DEPEND} =dev-lang/php-4*[cli]
+ RDEPEND=${RDEPEND} =dev-lang//php-4*[cli]
PHP_VERSION=4
}
@@ -76,8 +76,8 @@ uses_php4() {
# Set this after setting DEPEND/RDEPEND in your ebuild if the ebuild requires PHP5
# with cli SAPI.
need_php5_cli() {
- DEPEND=${DEPEND} =virtual/php-5*
- RDEPEND=${RDEPEND} =virtual/php-5*
+ DEPEND=${DEPEND} =dev-lang/php-5*[cli]
+ RDEPEND=${RDEPEND} =dev-lang/php-5*[cli]
PHP_VERSION=5
}
@@ -127,8 +127,8 @@ uses_php5() {
# Set this after setting DEPEND/RDEPEND in your ebuild if the ebuild requires PHP
# (any version) with cli SAPI.
need_php_cli() {
- DEPEND=${DEPEND} virtual/php
- RDEPEND=${RDEPEND} virtual/php
+ DEPEND=${DEPEND} dev-lang/php[cli]
+ RDEPEND=${RDEPEND} dev-lang/php[cli]
}
# @FUNCTION: need_php_httpd
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] RFC: remove php4 from depend.php and others
Hi,
yet another patch from Ole in a bid to rid the php eclasses from some
long forgotten code. The patches should be self-explanatory - just rip
out everything related to dev-php4 :)
Comments welcome.
All the work will go into our overlay (slotting branch:
http://git.overlays.gentoo.org/gitweb/?p=proj/php.git;a=tree;h=refs/heads/slotting;hb=slotting)
before migration to the tree.
diff --git a/eclass/depend.php.eclass b/eclass/depend.php.eclass
index 681e6dd..c194449 100644
--- a/eclass/depend.php.eclass
+++ b/eclass/depend.php.eclass
@@ -18,57 +18,6 @@
inherit eutils phpconfutils
-# PHP4-only depend functions
-
-# @FUNCTION: need_php4_cli
-# @DESCRIPTION:
-# Set this after setting DEPEND/RDEPEND in your ebuild if the ebuild requires PHP4
-# with cli SAPI.
-need_php4_cli() {
- DEPEND=${DEPEND} =dev-lang/php-4*[cli]
- RDEPEND=${RDEPEND} =dev-lang//php-4*[cli]
- PHP_VERSION=4
-}
-
-# @FUNCTION: need_php4_httpd
-# @DESCRIPTION:
-# Set this after setting DEPEND/RDEPEND in your ebuild if the ebuild requires PHP4
-# with either cgi or apache2 SAPI.
-need_php4_httpd() {
- DEPEND=${DEPEND} =virtual/httpd-php-4*
- RDEPEND=${RDEPEND} =virtual/httpd-php-4*
- PHP_VERSION=4
-}
-
-# @FUNCTION: need_php4
-# @DESCRIPTION:
-# Set this after setting DEPEND/RDEPEND in your ebuild if the ebuild requires PHP4
-# (with any SAPI).
-need_php4() {
- DEPEND=${DEPEND} =dev-lang/php-4*
- RDEPEND=${RDEPEND} =dev-lang/php-4*
- PHP_VERSION=4
- PHP_SHARED_CAT=php4
-}
-
-# common settings go in here
-uses_php4() {
- # cache this
- libdir=$(get_libdir)
-
- PHPIZE=/usr/${libdir}/php4/bin/phpize
- PHPCONFIG=/usr/${libdir}/php4/bin/php-config
- PHPCLI=/usr/${libdir}/php4/bin/php
- PHPCGI=/usr/${libdir}/php4/bin/php-cgi
- PHP_PKG=$(best_version =dev-lang/php-4*)
- PHPPREFIX=/usr/${libdir}/php4
- EXT_DIR=$(${PHPCONFIG} --extension-dir 2/dev/null)
-
- einfo
- einfo Using ${PHP_PKG}
- einfo
-}
-
# PHP5-only depend functions
# @FUNCTION: need_php5_cli
@@ -158,7 +107,6 @@ need_php() {
need_php_by_category() {
case ${CATEGORY} in
dev-php) need_php ;;
- dev-php4) need_php4 ;;
dev-php5) need_php5 ;;
*) die Version of PHP required by packages in category ${CATEGORY} unknown
esac
@@ -174,8 +122,6 @@ has_php() {
# Detect which PHP version we have installed
if has_version '=dev-lang/php-5*' ; then
PHP_VERSION=5
- elif has_version '=dev-lang/php-4*' ; then
- PHP_VERSION=4
else
die Unable to find an installed dev-lang/php package
fi
@@ -396,17 +342,6 @@ has_concurrentmodphp() {
require_pdo() {
has_php
- # Do we have PHP5 installed?
- if [[ ${PHP_VERSION} == 4 ]] ; then
- eerror
- eerror This package requires PDO.
- eerror PDO is only available for PHP 5.
- eerror You must install =dev-lang/php-5.1 with USE=\pdo\.
- eerror pdo USE flags turned on.
- eerror
- die PHP 5 not installed
- fi
-
# Was PHP5 compiled with internal PDO support?
if built_with_use =${PHP_PKG} pdo || phpconfutils_built_with_use =${PHP_PKG} pdo ; then
return
@@ -436,15 +371,6 @@ require_php_cli() {
local PHP_PACKAGE_FOUND=
- # Detect which PHP version we have installed
- if has_version '=dev-lang/php-4*' ; then
- PHP_PACKAGE_FOUND=1
- pkg=$(best_version '=dev-lang/php-4*')
- if built_with_use =${pkg} cli || phpconfutils_built_with_use =${pkg} cli ; then
- PHP_VERSION=4
- fi
- fi
-
if has_version '=dev-lang/php-5*' ; then
PHP_PACKAGE_FOUND=1
pkg=$(best_version '=dev-lang/php-5*')
@@ -480,15 +406,6 @@ require_php_cgi() {
local PHP_PACKAGE_FOUND=
- # Detect which PHP version we have installed
- if has_version '=dev-lang/php-4*' ; then
- PHP_PACKAGE_FOUND=1
- pkg=$(best_version '=dev-lang/php-4*')
- if built_with_use =${pkg} cgi || phpconfutils_built_with_use =${pkg} cgi ; then
- PHP_VERSION=4
- fi
- fi
-
if has_version '=dev-lang/php-5*' ; then
PHP_PACKAGE_FOUND=1
pkg=$(best_version '=dev-lang/php-5*')
@@ -522,13 +439,6 @@ require_sqlite() {
return
fi
- # Do we have pecl-sqlite installed for PHP4?
- if [[ ${PHP_VERSION} == 4 ]] ; then
- if has_version 'dev-php4/pecl-sqlite' ; then
- return
- fi
- fi
-
# If we get here, then we don't have any SQLite support for PHP installed
eerror
eerror No SQLite extension for PHP found.
diff --git a/eclass/php-pear-lib-r1.eclass b/eclass/php-pear-lib-r1.eclass
index 5c58dce..f5fdd7f 100644
--- a/eclass/php-pear-lib-r1.eclass
+++ b/eclass/php-pear-lib-r1.eclass
@@ -33,17 +33,7 @@ php-pear-lib-r1_src_install() {
addpredict /var/lib/net-snmp/
addpredict /session_mm_cli0.sem
- case ${CATEGORY} in
- dev-php)
- if has_version '=dev-lang/php-5*' ; then
-PHP_BIN=/usr/$(get_libdir)/php5/bin/php
- else
-PHP_BIN=/usr/$(get_libdir)/php4/bin/php
- fi ;;
- dev-php4) PHP_BIN=/usr/$(get_libdir)/php4/bin/php ;;
- dev-php5) PHP_BIN=/usr/$(get_libdir)/php5/bin/php ;;
- *) die Version of PHP required by packages in category ${CATEGORY} unknown
- esac
+ PHP_BIN=/usr/$(get_libdir)/php5/bin/php
cd ${S}
diff --git
[gentoo-dev] FYI: dropping support for php4
Yeah, we have dropped support for PHP-4 in the tree for ages, but in the php4 overlay it still lives on. This is just a reminder that php4 will be even more broken when the recent patches will get applied. The php team does and will not support installations running on the php4 overlay and will consider removing it (likely end of july) so as to not encourage usage of php4. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Tone in Gentoo
On 06/19/2010 09:10 AM, Paweł Hajdan, Jr. wrote: I think that is the point. Is just not being actively hostile a success? Given our past, yes. Given the size of our project, yes. The sheer size of the project guarantees that not everybody will like everyone. They merely get along and no thread will change that fact. Maybe a developer get-together like they happen here in the German conspiracy and elsewhere will, but that's not something you can force-feed others. Moreover, we don't just want to get along with ourselves. We want to encourage other people to join our community. I want and will train people who want to scratch their personal (technical) itches in gentoo to become a developer. Joining the community, otoh, takes as much as a /join #gentoo or logging into the forums. Yes, you can do that just for fun and that's totally fine. If something prevents users from joining the community in this way, UserRel should have a look at it. Nothing new here. But all examples of tone I've seen in this lengthy thread revolve around developer (particularly infra/devrel) communications. As has been said before, the two should not be confused, as they are different problems and have different solutions. As for the latter problem, Jorge and Patrick have said all there is to say about the issue. What we should improve, are the human communication skills (including mine, eh). This is nothing we can improve. I can't magically improve anyone's communication skill (and hell, I wish someone could fix mine!). Everyone decides if that's something he or she wants or needs to work on and how. Personally, I've observed that leading by example works best here. So please join me in killing some bugs (gently) today, kthx? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving unmaintained packages to Sunrise
On 06/13/2010 10:41 AM, Michał Górny wrote: Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? In this case by 'unmaintained' I mean those which have open bugs assigned to 'maintainer-needed' for a long time, and are potentially a candidates for the treecleaning (not necessarily being in the removal queue yet). What's stopping you or any of the sunrise guys to pick up packages when treecleaners send the last rites? You have 30 days minimum, to get a new ebuild rolling before it gets the axe. Sounds like plenty of time to me. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-php5/{creole,jargon}
# Matti Bickel m...@gentoo.org (13 Jun 2010) # Dead upstream (bug #321685) # Removal on 2010-07-13 dev-php5/jargon dev-php5/creole signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On 06/06/2010 12:40 PM, Thomas Sachau wrote: My base proposal for this is something like this: Every package defines the language(s), where it could be installed for multiple slots, e.g.: MULTI_SLOT=python or MULTI_SLOT=python ruby Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Don't get me wrong, but isn't that what the python developers guide[1] says? (python.eclass supports PYTHON_DEPEND helper variable, which allows to specify minimal and maximal version of Python.) I thought the whole point of this debate was that nobody cared enough to convert all those ebuilds to use PYTHON_DEPEND properly. The proper fix is to convert ebuilds to the new syntax. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bug wrangler queue is large...
On 05/26/2010 11:01 AM, Duncan wrote: [Reopening on RESO FIXED bugs as non-reporter] That's what clone bug is for... or at least what /I/ use it for. Resulting in extra work for wranglers. At least for the packages I maintain, I actually read my bugmail and will respond to comments even in RESO FIXED bugs. Plus, you're still screwed if users help out with the wrangling. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 08:24 PM, Mike Frysinger wrote: they are supposed to be doing basic triage, user feedback Can you be more specific? I wrangle bugs when there's a need and I'd like to hear what maintainers want to see on a bug assigned to them. If info is missing I usually ask for it and assign the bug anyway. If that's not wanted, let me know. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 09:33 PM, Mike Frysinger wrote: i posted some specific examples already ... Sure enough. Just wanted to know if there's more to it than build.log and emerge --info. I'll try to extract something more than that next time. Goes w/o saying that bug cleanup should be done prior to assignments. so wranglers ask for it, leave it assigned to bug-wranglers, and close as NEEDINFO. when (if) things become available, it can then be re-opened and moved to the maintainer. -mike Good enough for me. The intention behind the immediate assignments was the hope that maintainers could figure out the error from the already provided info (does not work won't get assigned), netting quicker reaction times. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 10:08 PM, Harald van Dijk wrote: http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml Cool, I clearly not up to date here, I've never thought this to be a project. Thanks for the link. Wrt mentioning metadata.xml for herd lookup in there: I've found willikins' meta -v (in a query, mind you) saves me a few keystrokes. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 10:08 PM, Harald van Dijk wrote: NEEDINFO bugs cannot be reopened by other users, even if they provide the requested information. I utterly fail at finding documentation on that. I've recently hit a problem where a user couldn't reopen a RESO FIXED bug, too. Are bugzi permissions documented somewhere? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Does anyone use the VERIFIED status in bugzilla?
On 05/14/2010 03:34 PM, Samuli Suominen wrote: I'd like to see the whole thing go away. It's this one user I've pretty much ever seen using it. And he's using it to change RESOLVED status to VERIFIED on e.g. removal bugs, stabilization bugs, keywording bugs... cleanup++ [1] - http://www.bugzilla.org/docs/3.4/en/html/lifecycle.html Looks nice on paper if you put it like that, but not really how it's working for us in reality. From my work on b.g.o: I use a simplified version of this, shown at: http://dev.gentoo.org/~mabi/gentooBzLifecycle.png Basically three states less and a NEEDINFO resolution added. That's all I ever touched in the years.
Re: [gentoo-dev] RFC: bugzilla flags for arch-testing
On 04/26/2010 11:40 AM, Paweł Hajdan, Jr. wrote: To make it easier to find stabilization bugs with arch-testers' comments, I'd like to add new flags to Gentoo bugzilla. Can you explain how the TESTED Keyword is not sufficient for your goal? It explicitly states: Ebuilds that have been marked as tested by arch testers. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Nirbheek Chauhan wrote: On Tue, Apr 13, 2010 at 10:03 PM, Matti Bickel m...@gentoo.org wrote: I rather like the changelogs auto-generated. A method to link my git commit to bugzie would be awesome. I *do* envy debian and others for the auto bughandling they have. Previewing more than a raw number would also reduce (not eliminate) the errors committed, i guess. I think you will *really* like `git bz`[1][2][3]. Actually, I do :) Someone posted a link in a thread I can't remember now and it looks very promising. Though i don't know if there's anything barring us from using it. But I image it would make my life easier a lot. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Nirbheek Chauhan wrote: From my PoV, editing ChangeLog is like editing history. Complete no-no. It is possible in all major SCMs for a reason. And I (as a user) would laugh at Changelog entries saying um, I got that bug number wrong, it is really #1234. If I (as a developer) log such edits, I'm wasting my users time. So I'll continue to edit and commit Changelogs without additional notice. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Alec Warner wrote: On Tue, Apr 13, 2010 at 9:12 AM, Matti Bickel m...@gentoo.org wrote: Nirbheek Chauhan wrote: From my PoV, editing ChangeLog is like editing history. Complete no-no. It is possible in all major SCMs for a reason. And I (as a user) would laugh at Changelog entries saying um, I got that bug number wrong, it is really #1234. If I (as a developer) log such edits, I'm wasting my users time. Its not possible in perforce once your change has been submitted. Oh, missed that one. Maybe that makes perforce more auditble or whatnot. I rather like the changelogs auto-generated. A method to link my git commit to bugzie would be awesome. I *do* envy debian and others for the auto bughandling they have. Previewing more than a raw number would also reduce (not eliminate) the errors committed, i guess. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Policy regarding the inactive members
/me puts on his asbestos underwear Markos Chandras wrote: So the attendance to council meetings is enough to prove that a member is active? 0_o Yes. Anything else is just too hard to measure, imo. If you notice a council member acting w/o knowing what the heck is going on, then vote him down next election. place on the mailing list. Because I really doubt that *all* council members are reading the mailing list in daily basis so they get to know everything that is going on to Gentoo. This is impossible. Council should follow -council and debate points pushed onto their agenda via -dev. At least that's my understanding. The only council members who look active to me are Petteri and Denis. While I applaud Denis and Petteri for taking a stand on the pit that -dev is, I doubt council members should be required to participate here. They can vote on an issue without discussing their opinion first, based on their technical/social experience (which is what I voted them in for, in the first place) A council member is inactive when: 1) He is inactive in critical discussions ( such as the whole Phoenix discussion ) for a certain period of time Please, no. Or we start to get -council/-dev threads about why a certain thread here is not considered critical by half of the council when they don't reply. If you can't put a number on it, please don't make it a hard requirement. 2) Fails to accomplish his role by supervising the Gentoo projects. This isn't even in their domain. I would complain *loud* about any council member interfering with projects unless it's an inter-project issue. The council is meant for arbitration and vision, not for commanding devs. Remember we have plenty of Gentoo projects nearly dead and there is no way for us to participate since contacting the project leaders is a no-go. Huh? That's what I did with php. Chtekk was most helpful, and because he's no longer active (wish him all the best!), nobody stopped me from updating the projects pages to reflect that (after speaking to the team, of course!) Rather than relying on the council for whatever leadership you want, please just DO something that scratches YOUR itch. I'm aware our current technical/social infrastructure is not up to par on handling large scale contributions by hundreds of users/non-devs. I realize there's this impression that every time you have an idea there's a mob of people stoning your idea to death. I have however observed that the more mature (read: the more implemented code) your idea is, the smaller the stones. And if your idea is good enough, others might use their stones for building instead of mud-slinging. Just my 2cent. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Policy regarding the inactive members
Zeerak Mustafa Waseem wrote: But isn't it the councils purpose to lead gentoo? It's my understanding that council gets elected to lead gentoo as a whole. But in the end the one doing the work gets to decide what's going on (as long as it's intra-project; the only thing i remember where council got to vote on a project outcome is PMS/EAPI) Don't get me wrong: several times i hoped for somebody with authority to magically end discussions on an issue, handing out the right direction and be done with it (you already mentioned python-3). But in a consensus community like gentoo we will instantly have discussions about our definition of right direction. Only a select few still have that authority required to end a sub-thread with their right direction. And this is mostly because they post hard facts you are buying because they've done so for years and otherwise kept their mouth shut. But i disgress.. By leading they have to either delegate to someone to supervise Gentoo projects or do it themselves. No. It just doesn't work that way. GLEP39 says projects may have a leader, who will hopefully be responsible to the projects members. That's the person you want to turn to. Older projects may still have a operation lead and a strategic lead. In that case, you want the strategic lead :) The whole wording and history of the GLEP gives projects most of the power. They can't be blocked by the community, they can conflict, they can go defunct at any time. All these are explicitly spelled out in the GLEP. I do agree that doing something yourself will always be the first step, but there is no way every developer can keep track of everything that's going on. They are not required to. I'm not required to know of the wiki project or the huge issue that python3 going stable seems to be. My responsibility as a dev is to keep up with things I work on, like EAPI changes. If I *want* others to notice, I'll contact council (if I need a decision) or PR (if I have an announcement). You are proposing a centralized solution. This hasn't worked since Daniel left and I personally think gentoo's too large to successfully try it again. I utterly fail to see why there should be any rock throwing. Me too. But it happens. Despite a dozen folks calling for calm again and again. I don't want to offer explanations for it, this mail has gotten long enough as it is ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: eblits.eclass
Hi folks,
this is my first eclass proposal, so rip it apart gently ;)
Disclaimer: the work proposed is NOT my own, but rather contributed by
vapier (see [1] or sys-libs/glibc) and kumba (see [2] or
sys-kernel/mips-sources).
I propose to add eblits.eclass[2] (attached to this message) with the
purpose and author comments from [1].
A quick grep showed that glibc and mips-sources currently use functions
defined in global scope in each ebuild to do the job. The referenced
overlays also use eblits to install php-5.3 and this is currently
blocking php-5.3 from entering the tree.
sys-kernel/mips-sources also has comment:
# They'll likely be superseded someday by better ideas, possibly elibs.
That's why I titled this email RFC - I realize this eclass might be
obsolete in a not to distant future and possibly cause funny behaviour
in ebuilds that I'm not aware of.
So please enlighten me of any problems you can think of that adding
eblits.eclass as proposed above would cause. I'd be more than happy if
we can get an update on elibs progress, too.
As the need for such an eclass is very real (we really, really want
php-5.3 in the tree!), I want to limit discussion to one week, ending
April 18th. If there are no objections, I'll add the eclass after that date.
TIA, Matti
[1]
http://hg.hoffie.info/gentoo-php-rewrite/file/66effb7b56a0/eclass/eblits.eclass
[2]
http://github.com/GiDiS/gentoo-php-rewrite/blob/master/eclass/eblits.eclass
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# eblit-core
# Usage: function [version] [eval]
# Main eblit engine
eblit-core() {
[[ -z $FILESDIR ]] FILESDIR=$(dirname $EBUILD)/files
local e v func=$1 ver=$2 eval_=$3
for v in ${ver:+-}${ver} -${PVR} -${PV} ; do
e=${FILESDIR}/eblits/${func}${v}.eblit
if [[ -e ${e} ]] ; then
. ${e}
[[ ${eval_} == 1 ]] eval ${func}() { eblit-run
${func} ${ver} ; }
return 0
fi
done
return 1
}
# eblit-include
# Usage: [--skip] function [version]
# Includes an eblit -- a chunk of common code among ebuilds in a given
# package so that its functions can be sourced and utilized within the
# ebuild.
eblit-include() {
local skipable=false r=0
[[ $1 == --skip ]] skipable=true shift
[[ $1 == pkg_* ]] skipable=true
[[ -z $1 ]] die Usage: eblit-include function [version]
eblit-core $1 $2
r=$?
${skipable} return 0
[[ $r -gt 0 ]] die Could not locate requested eblit '$1' in
${FILESDIR}/eblits/
}
# eblit-run-maybe
# Usage: function
# Runs a function if it is defined in an eblit
eblit-run-maybe() {
[[ $(type -t $@) == function ]] $@
}
# eblit-run
# Usage: function [version]
# Runs a function defined in an eblit
eblit-run() {
eblit-include --skip common ${*:2}
eblit-include $@
eblit-run-maybe eblit-$1-pre
eblit-${PN}-$1
eblit-run-maybe eblit-$1-post
}
# eblit-pkg
# Usage: phase [version]
# Includes the given functions AND evals them so they're included in the binpkgs
eblit-pkg() {
[[ -z $1 ]] die Usage: eblit-pkg phase [version]
eblit-core $1 $2 1
}
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Alistair Bush wrote: I'm not overly concerned about what wiki we use. But may I suggest we approach gentoo-wiki to see whether they would like to be involved. +1, especially the overly concerned part. Seriously folks. Just start it. Take whatever you as a person feel comfortable with. Talk to infra, if there are concerns about security. Then get moving. Maybe even set up multiple implementations and start evaluating, if you can trick infra into doing the setup. If not, you'd have to live with what they give you. You can theorize all you want about the best possible solution. That will just clog up the pipes and piss users off no end. It certainly did so for me. I'm now at the point where i'm willing to bet money on the wiki request never actually reaching infra. Can we please go back to happy days where guys and gals worked on an implementation FIRST, posted to lists SECOND and ironed out errors via peer review THIRD? It'll make us all more productive. What project should we create this under. Please don't make it another project. This will just create a new territory and spread resources even thinner. Take one of the user-facing projects like forums or userrel. But don't let this be a blocker to get things done. You can always change ownership of the stuff once you actually get some property to talk about. An important lesson i've learned during the last days as i've taken up php stuff: people, users and devs alike, will step up to help you, do things for you, work with you and be generally amazing if you (1) ask specific, detailed questions and (2) provide some of the work yourself. Usually you have to do (2) before you can do (1). Applying this the wiki debate, you (1) ask specific, *technical* questions, you ideally answer with yes/no (1.1) Do we have an ebuild for it? If no, can i maintain one? (1.2) Will infra emerge the ebuild for me? If not, why not? (1.3) Who do i pester about my administrator access data? (1.4) Who can i use as lab-monk^W^W^Wa test group? How to reach them? (2) set up some fscking wiki and let people play with it. (3) profit ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Is Gentoo dying?
Alec Warner wrote: The above are all pretty easy to do with the data in the tree. Some other useful ideas might be: - compare open bugs for the package, when was the last bug for a package closed (bugs data kinda sucks for this) An additional search: last touched by assignee between never and now-30 days. I also just discovered that awesome query interface our bugzilla has. Can we publish a data set query where new bugs are plotted against closed bugs (maybe add already open bugs) for each herd? I'll try to come up with a query if no one else is faster with this. If the difference between new and closed bugs in a 30 days time period is over a given threshold (say 15% of the current open bugs), this might be a herd that needs help. Maybe we can come up with more insightful bugzie searches. And maybe something like that exists already and i've failed finding it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Handling of keywording bugs with only one arch
Alec Warner wrote: Could we generate a bugzilla search for arch teams? Do arch teams already use existing bugzilla functionality? At least when i was with the ppc team, we had a bugzie search. And bugzie already sorts your query for you. I guess it could be made to only show keyword=STABLEREQ, bug changed = -1month since bug creation, assigned OR cc contains ppc@ or something like that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Qt3 mask breaks significant science packages
Samuli Suominen wrote: if a package is broken, and been in treecleaners queue for too long, and it would be a semi-trivial fix, it simply doesn't get done without manpower Because i can't find this info on the treecleaner project page: is there a bugzilla query for the treecleaners queue, so others can take a look/help out? I have found 4 bugs assigned to treeclea...@gentoo.org, but i'm sure i missed something. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
Angelo Arrifano wrote: What do you people think on a new pkg_changelog function that would instruct the ebuild how to retrieve this kind of information from the package? No, please don't. I'm okay with it if your mean at the end of emerge -u atom, but wouldn't it be pointless to see what changed *after* you just installed the thing? The reason i'm against it is the complexity involved. You need to pull down the source (up to hunderts of megabytes for openoffice), run src_unpack and eventually src_configure phases. Then you need to know where to look and what to show. But i agree it's cool to know what i will gain from my daily emerge run. As an alternative, let the ebuild provide a variable that points to upstreams online Changelog or something, so you as a human can go parse it yourself. But then you could also just take the HOMEPAGE variable that's already there. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
Jeremy Olexa wrote: There is an optional changelog tag in metadata.xml. Good. Seems i'm not the first who thought about that ;) Yeah, maybe we can get the package managers to display the URLs corresponding to the atoms to be installed/updated when given a flag. But maybe that already exists, i haven't had a look in a while. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Handling of keywording bugs with only one arch
Ryan Hill wrote: I can't find it any more, but that's probably where this idea came from. It never really made sense to me but I've done it on several occasions. me too. I guess it's been handed down for ages. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
Zeerak Mustafa Waseem wrote: On Sun, Mar 07, 2010 at 09:08:14PM -0600, Ryan Hill wrote: A stable user who doesn't want python 3 installed shouldn't have it forced on them. If something is pulling in python-3 then that package needs to have its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was before (unless you use @installed) so it shouldn't be pulled in by anything that doesn't require it. +1 on that. If your program is only tested with python-2 or has regressions with python-3 (e.g. performance loss), a maintainer can and should mark that package as python-2 only. For new systems, the only must have python user i can think of is portage. And that has an explicit USE=python3 and as Zac outlined takes DEPEND-pains to ensure python-2.* is pulled in if available. So you're starting with python-2.* and every program not explicitly pulling in python-3.* should be happy with that. I think that is being said is, due to python 3 being unnecessary for majority of users, due to a small number of applications actually using it, it should be in ~arch. You're actually damning most of the tree to be ~arch, if that's the criterion for stable. Of course an application that depends on python 3, but is entirely stable should not be marked testing (to my reckoning at least). I think the best way to go about it is to set python-3 in ~arch. These are contradicting statements. Repoman will and should kill anyone attempting to do that. All [R,]DEPENDS of an ebuild must be stable, if that ebuild is to be marked stable, too. So b/c i still can't understand what's so horrible about python-3 going into stable (even if p.mask'ed, if that's the consensus), my vote goes to mark it stable already. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Thilo Bangert bang...@gentoo.org wrote: 'guess'. Like how you have to guess what use flags are really being used for the package in question, because it doesn't tell you? i'd like to ask the developers of package managers to standardize this. having packagmanager --info be the same no matter who you like best is incredibly usefull. ++ Please, do it. Even an educated guess is better than nothing, raising the probability bug-wranglers can handle the bug even before it hits other devs' inboxes. -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpEH0FPACq8x.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
Peter Alfredsen loki_...@gentoo.org wrote: I think we should start deprecating EAPI=0 usage *now* with a repoman warning whenever a new ebuild is committed that does not use EAPI=1 or EAPI=2. This warning should encourage use of the newest EAPI, EAPI=2. A general question, that just popped into my head when i was reading this: if i touch a ebuild which has EAPI=0, should i bump it to EAPI=2? Since the introduction of EAPI i have been bumping EAPI of my ebuilds based on need. So if i needed slot-deps, i've made the ebuild EAPI=1, not EAPI=2 by choice. If i needed use-deps, then well, i went for EAPI=2. How are other ebuild developers doing this? What's the package manager ppls take on this? -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpr5TMoF3mbY.pgp Description: PGP signature
Re: [gentoo-dev] prepalldocs implementation in eutils.eclass (was: prepalldocs is now banned)
Tiziano Müller dev-z...@gentoo.org wrote:
The only problem I see here is that either OLDLOCATION or ${T}/doc
contains subdirs. So my proposal for the next EAPI is to allow dodoc and
newdoc to operate on dirs. Which also gives the benefit to reduce this
idiom:
insinto /usr/share/doc/${PF}
doins -r examples
to:
dodoc examples
Your comments?
Yes, please. It will simplify dozens of ebuilds and feels 'natural' to
me. Keeping with doins, etc. i would propose to make it
dodoc -r $something
And thanks for your analysis.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
pgphJ60gwGZyv.pgp
Description: PGP signature
Re: [gentoo-dev] RFC: fox.eclass update
Peter Volkov p...@gentoo.org wrote:
В Вск, 08/02/2009 в 23:06 +0100, Matti Bickel пишет:
+# could probably be lower
+WANT_AUTOCONF=latest
+WANT_AUTOMAKE=latest
These are defaults. You don't need to specify them.
+ eautomake || die automake error
eautomake dies on its own. You don't need || die here.
Thanks for the comments, WANT_AUTO* was specified to make some previous
commenter happy, but removed now ;)
Where was that 'which functions || die on their own' table, anyway?
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
--- /usr/portage/eclass/fox.eclass 2008-10-12 14:36:35.0 +0200
+++ fox-proposed.eclass 2009-02-09 19:21:03.0 +0100
@@ -1,8 +1,12 @@
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.8 2008/10/12 12:31:36
mabi Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.7 2007/01/15 20:27:06
mabi Exp $
-# fox eclass
+# @ECLASS: fox.eclass
+# @MAINTAINER: m...@gentoo.org
+# @BLURB: Common build and install functions for fox-related apps and library
+# @DESCRIPTION: Used by the x11-libs/fox library and all applications that come
+# with the upstream source tarball.
#
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
@@ -19,26 +23,18 @@
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
-# Here are sample [R]DEPENDs for the fox apps
-# fox versions that do not use this eclass are blocked in INCOMPAT_DEP below
-# 1.0: '=x11-libs/fox-1.0*'
-# 1.2: '=x11-libs/fox-1.2*'
+# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
+#
+# @EXAMPLE: Here are sample [R]DEPENDs for the fox apps
# 1.4: '=x11-libs/fox-1.4*'
# 1.5: '~x11-libs/fox-${PV}'
# 1.6: '=x11-libs/fox-${FOXVER}*'
-#
-# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
-
-inherit eutils libtool versionator
+inherit autotools eutils libtool versionator
FOX_PV=${FOX_PV:-${PV}}
-PVP=(${FOX_PV//[-\._]/ })
-FOXVER=${PVP[0]}.${PVP[1]}
-
-if [ ${FOXVER} != 1.0 ] ; then
- FOXVER_SUFFIX=-${FOXVER}
-fi
+FOXVER=$(get_version_component_range 1-2)
+FOXVER_SUFFIX=-${FOXVER}
DESCRIPTION=C++ based Toolkit for developing Graphical User Interfaces easily
and effectively
HOMEPAGE=http://www.fox-toolkit.org/;
@@ -46,44 +42,28 @@
IUSE=debug doc profile
-# from fox-1.0
-FOX_APPS=adie calculator pathfinder
-# from fox-1.2+
-if [ ${FOXVER} != 1.0 ] ; then
- FOX_APPS=${FOX_APPS} shutterbug
- FOX_CHART=chart
-fi
+# @ECLASS-VARIABLE: FOX_APPS
+# @DESCRIPTION: all applications that come with the fox toolkit source
+FOX_APPS=adie calculator pathfinder shutterbug chart
if [ ${PN} != fox ] ; then
FOX_COMPONENT=${FOX_COMPONENT:-${PN}}
fi
-if [ ${FOXVER} != 1.0 ] [ -z ${FOX_COMPONENT} ] ; then
- DOXYGEN_DEP=doc? ( app-doc/doxygen )
-fi
-
if [ ${PN} != reswrap ] ; then
RESWRAP_DEP=dev-util/reswrap
fi
-# These versions are not compatible with new fox layout
-# and will cause collissions - we need to block them
-INCOMPAT_DEP=!x11-libs/fox-1.0.53
- !=x11-libs/fox-1.2.4
- !~x11-libs/fox-1.2.6
- !=x11-libs/fox-1.4.11
-
-DEPEND=${INCOMPAT_DEP}
- ${DOXYGEN_DEP}
- ${RESWRAP_DEP}
- =sys-devel/automake-1.4*
+DEPEND=${RESWRAP_DEP}
+ doc? ( app-doc/doxygen )
+ =sys-devel/automake-1.4
=sys-apps/sed-4
S=${WORKDIR}/fox-${FOX_PV}
fox_src_unpack() {
unpack ${A}
- cd ${S}
+ cd ${S}
ebegin Fixing configure
@@ -103,14 +83,14 @@
done
# use the installed reswrap for everything else
- for d in ${FOX_APPS} ${FOX_CHART} tests ; do
+ for d in ${FOX_APPS} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die sed ${d}/Makefile.am error
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
- if version_is_at_least 1.6.34 ${PV} ; then
+ if version_is_at_least 1.6.34 ${PV}; then
sed -i \
-e s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox${FOXVER_SUFFIX}: \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
@@ -124,19 +104,13 @@
${d}/Makefile.am || die sed ${d}/Makefile.am
error
fi
done
-
- # Upstream often has trouble with version number transitions
- if [ ${FOXVER} == 1.5 ] ; then
- sed -i -e 's:1.4:1.5:g' chart/Makefile.am
- fi
-
eend
ebegin Running automake
- automake-1.4 -a -c || die automake error
+ eautomake
eend
Re: [gentoo-dev] RFC: fox.eclass update
Hi,
shame on me, here i'm wondering why noone replies...
Sorry, i failed to send the updated patch o.O
Here's the patch again w/ your suggestions included.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
--- /usr/portage/eclass/fox.eclass 2008-10-12 14:36:35.0 +0200
+++ fox-proposed.eclass 2009-02-08 19:35:49.0 +0100
@@ -1,8 +1,12 @@
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.8 2008/10/12 12:31:36
mabi Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.7 2007/01/15 20:27:06
mabi Exp $
-# fox eclass
+# @ECLASS: fox.eclass
+# @MAINTAINER: m...@gentoo.org
+# @BLURB: Common build and install functions for fox-related apps and library
+# @DESCRIPTION: Used by the x11-libs/fox library and all applications that come
+# with the upstream source tarball.
#
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
@@ -19,26 +23,22 @@
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
-# Here are sample [R]DEPENDs for the fox apps
-# fox versions that do not use this eclass are blocked in INCOMPAT_DEP below
-# 1.0: '=x11-libs/fox-1.0*'
-# 1.2: '=x11-libs/fox-1.2*'
+# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
+#
+# @EXAMPLE: Here are sample [R]DEPENDs for the fox apps
# 1.4: '=x11-libs/fox-1.4*'
# 1.5: '~x11-libs/fox-${PV}'
# 1.6: '=x11-libs/fox-${FOXVER}*'
-#
-# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
-inherit eutils libtool versionator
+# could probably be lower
+WANT_AUTOCONF=latest
+WANT_AUTOMAKE=latest
+inherit autotools eutils libtool versionator
FOX_PV=${FOX_PV:-${PV}}
-PVP=(${FOX_PV//[-\._]/ })
-FOXVER=${PVP[0]}.${PVP[1]}
-
-if [ ${FOXVER} != 1.0 ] ; then
- FOXVER_SUFFIX=-${FOXVER}
-fi
+FOXVER=$(get_version_component_range 1-2)
+FOXVER_SUFFIX=-${FOXVER}
DESCRIPTION=C++ based Toolkit for developing Graphical User Interfaces easily
and effectively
HOMEPAGE=http://www.fox-toolkit.org/;
@@ -46,44 +46,28 @@
IUSE=debug doc profile
-# from fox-1.0
-FOX_APPS=adie calculator pathfinder
-# from fox-1.2+
-if [ ${FOXVER} != 1.0 ] ; then
- FOX_APPS=${FOX_APPS} shutterbug
- FOX_CHART=chart
-fi
+# @ECLASS-VARIABLE: FOX_APPS
+# @DESCRIPTION: all applications that come with the fox toolkit source
+FOX_APPS=adie calculator pathfinder shutterbug chart
if [ ${PN} != fox ] ; then
FOX_COMPONENT=${FOX_COMPONENT:-${PN}}
fi
-if [ ${FOXVER} != 1.0 ] [ -z ${FOX_COMPONENT} ] ; then
- DOXYGEN_DEP=doc? ( app-doc/doxygen )
-fi
-
if [ ${PN} != reswrap ] ; then
RESWRAP_DEP=dev-util/reswrap
fi
-# These versions are not compatible with new fox layout
-# and will cause collissions - we need to block them
-INCOMPAT_DEP=!x11-libs/fox-1.0.53
- !=x11-libs/fox-1.2.4
- !~x11-libs/fox-1.2.6
- !=x11-libs/fox-1.4.11
-
-DEPEND=${INCOMPAT_DEP}
- ${DOXYGEN_DEP}
- ${RESWRAP_DEP}
- =sys-devel/automake-1.4*
+DEPEND=${RESWRAP_DEP}
+ doc? ( app-doc/doxygen )
+ =sys-devel/automake-1.4
=sys-apps/sed-4
S=${WORKDIR}/fox-${FOX_PV}
fox_src_unpack() {
unpack ${A}
- cd ${S}
+ cd ${S}
ebegin Fixing configure
@@ -103,14 +87,14 @@
done
# use the installed reswrap for everything else
- for d in ${FOX_APPS} ${FOX_CHART} tests ; do
+ for d in ${FOX_APPS} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die sed ${d}/Makefile.am error
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
- if version_is_at_least 1.6.34 ${PV} ; then
+ if version_is_at_least 1.6.34 ${PV}; then
sed -i \
-e s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox${FOXVER_SUFFIX}: \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
@@ -124,19 +108,13 @@
${d}/Makefile.am || die sed ${d}/Makefile.am
error
fi
done
-
- # Upstream often has trouble with version number transitions
- if [ ${FOXVER} == 1.5 ] ; then
- sed -i -e 's:1.4:1.5:g' chart/Makefile.am
- fi
-
eend
ebegin Running automake
- automake-1.4 -a -c || die automake error
+ eautomake || die automake error
eend
- elibtoolize
+ #elibtoolize
}
fox_src_compile() {
@@ -150,21 +128,21 @@
$(use_with profile profiling) \
|| die configure error
- cd ${S}/${FOX_COMPONENT}
+ cd ${S}/${FOX_COMPONENT
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
Tomáš Chvátal [EMAIL PROTECTED] wrote: On Sunday 30 November 2008 14:23:48 Diego 'Flameeyes' Pettenò wrote: I have a very quick proposal: why don't we move the packages' homepage in metadata.xml (since it's usually unique for all the versions) and we get rid of the variable for the next EAPI version? I would rather see something like: packagename/metadata.xml packagename/package-base.ebuild packagename/packagename-version.ebuild packagename/Manifest packagename/Changelog Correct me if i'm wrong, but this doesn't address the problem with multiple versions having multiple homepages. I'm with Diego here that this should be *very* rare. Can somebody verify this? I mean just throw a little shell script on the portage tree showing which ebuilds differ in HOMEPAGE but still have the same path.. my poor ibook would take too long for such a thing, so sorry, no data here. And while your proposal sounds more compliant to the DRY principle, i would object it on the basis that it makes a single ebuild actually harder to understand as you have to read (1) eclasses, (2) -base.ebuild and (3) -version.ebuild. -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpLZ47VAfi0Y.pgp Description: PGP signature
Re: [gentoo-dev] Time to say goodbye
I normally don't do that. But i have to echo dertobi123 here. Sad to see you go, Marius. I wish you all the best in your future endavours. May the force be with you. You've been inspiring in your rational arguments and analysis as well as in the quality and quantity of your contributions. Thank you. And i'll see to fulfill my promise to get gentoo-stats going. See you on the other side (or some other event around here). -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpl5mKjPyzyw.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Tobias Scherbaum [EMAIL PROTECTED] wrote: Mark Loeser wrote: Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. What if this would break deps or it's a very common package for example belonging to the set of system packages? Then the maintainer moans and does nothing. I guess that's where the MAY part from above comes in. Policy should not be an excuse to stop thinking. And if i break a user system when i drop my stable keywords, IMHO i'm violating the 'work as pleasently and efficiently as possible' bit of our philosophy. It isn't that we have arch teams denying ebuilds their blessing because they're evil. Maybe they're overworked, maybe they even have a real life. Or maybe they have stated that your ebuild has QA issues (as Ferris did), which should be noted and fixed by the maintainer. So bottom-line: i'm very much in favour of your solution to question #1. And i'd like to stress the automatic bit. Yes, we can get access to tinderboxes. But last i looked, this involved tracking down the person responsible for it, asking for access and doing everything you need to get your package to compile. Well, i'm lazy, so i didn't do it. Automatic tinderbox testing would very much help in the process. Maybe someone can write a script so that once a maintainer opens/gives his OK to a stable bug, automatic testing could be started and the results posted back to the bug? After the timeframe (30 days? 60? I don't know, and it's not important at this point) maintainers could move to stable their package themself IF the automatic tests indicate success AND no arch member has spoken up. just my $0.02 -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpaOntcepuKy.pgp Description: PGP signature
Re: [gentoo-dev] RFC: fox.eclass update
Donnie Berkholz [EMAIL PROTECTED] wrote:
On 13:56 Mon 13 Oct , Petteri Räty wrote:
Could you also send a diff next time.
Or this time, even. +1 on that.
Here you are. It's attached.
One easy thing to do is move what comments exist to the eclass-manpages
format.
I also included some eclass-manpage foo now, thanks for the hint.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
--- gentoo-x86/eclass/fox.eclass2008-10-12 14:31:36.0 +0200
+++ fox-proposed.eclass 2008-10-13 20:27:05.0 +0200
@@ -1,8 +1,12 @@
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.8 2008/10/12 12:31:36
mabi Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.7 2007/01/15 20:27:06
mabi Exp $
-# fox eclass
+# @ECLASS: fox.eclass
+# @MAINTAINER: [EMAIL PROTECTED]
+# @BLURB: Common build and install functions for fox-related apps and library
+# @DESCRIPTION: Used by the x11-libs/fox library and all applications that come
+# with the upstream source tarball.
#
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
@@ -19,26 +23,18 @@
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
-# Here are sample [R]DEPENDs for the fox apps
-# fox versions that do not use this eclass are blocked in INCOMPAT_DEP below
-# 1.0: '=x11-libs/fox-1.0*'
-# 1.2: '=x11-libs/fox-1.2*'
+# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
+#
+# @EXAMPLE: Here are sample [R]DEPENDs for the fox apps
# 1.4: '=x11-libs/fox-1.4*'
# 1.5: '~x11-libs/fox-${PV}'
# 1.6: '=x11-libs/fox-${FOXVER}*'
-#
-# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
-
-inherit eutils libtool versionator
+inherit autotools eutils libtool versionator
FOX_PV=${FOX_PV:-${PV}}
-PVP=(${FOX_PV//[-\._]/ })
-FOXVER=${PVP[0]}.${PVP[1]}
-
-if [ ${FOXVER} != 1.0 ] ; then
- FOXVER_SUFFIX=-${FOXVER}
-fi
+FOXVER=$(get_version_component_range 1-2)
+FOXVER_SUFFIX=-${FOXVER}
DESCRIPTION=C++ based Toolkit for developing Graphical User Interfaces easily
and effectively
HOMEPAGE=http://www.fox-toolkit.org/;
@@ -46,44 +42,28 @@
IUSE=debug doc profile
-# from fox-1.0
-FOX_APPS=adie calculator pathfinder
-# from fox-1.2+
-if [ ${FOXVER} != 1.0 ] ; then
- FOX_APPS=${FOX_APPS} shutterbug
- FOX_CHART=chart
-fi
+# @ECLASS-VARIABLE: FOX_APPS
+# @DESCRIPTION: all applications that come with the fox toolkit source
+FOX_APPS=adie calculator pathfinder shutterbug chart
if [ ${PN} != fox ] ; then
FOX_COMPONENT=${FOX_COMPONENT:-${PN}}
fi
-if [ ${FOXVER} != 1.0 ] [ -z ${FOX_COMPONENT} ] ; then
- DOXYGEN_DEP=doc? ( app-doc/doxygen )
-fi
-
if [ ${PN} != reswrap ] ; then
RESWRAP_DEP=dev-util/reswrap
fi
-# These versions are not compatible with new fox layout
-# and will cause collissions - we need to block them
-INCOMPAT_DEP=!x11-libs/fox-1.0.53
- !=x11-libs/fox-1.2.4
- !~x11-libs/fox-1.2.6
- !=x11-libs/fox-1.4.11
-
-DEPEND=${INCOMPAT_DEP}
- ${DOXYGEN_DEP}
- ${RESWRAP_DEP}
- =sys-devel/automake-1.4*
+DEPEND=${RESWRAP_DEP}
+ doc? ( app-doc/doxygen )
+ =sys-devel/automake-1.4
=sys-apps/sed-4
S=${WORKDIR}/fox-${FOX_PV}
fox_src_unpack() {
unpack ${A}
- cd ${S}
+ cd ${S}
ebegin Fixing configure
@@ -103,14 +83,14 @@
done
# use the installed reswrap for everything else
- for d in ${FOX_APPS} ${FOX_CHART} tests ; do
+ for d in ${FOX_APPS} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die sed ${d}/Makefile.am error
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
- if version_is_at_least 1.6.34 ${PV} ; then
+ if version_is_at_least 1.6.34 ${PV}; then
sed -i \
-e s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox${FOXVER_SUFFIX}: \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
@@ -124,19 +104,13 @@
${d}/Makefile.am || die sed ${d}/Makefile.am
error
fi
done
-
- # Upstream often has trouble with version number transitions
- if [ ${FOXVER} == 1.5 ] ; then
- sed -i -e 's:1.4:1.5:g' chart/Makefile.am
- fi
-
eend
ebegin Running automake
- automake-1.4 -a -c || die automake error
+ eautomake || die automake error
eend
- elibtoolize
+ #elibtoolize
}
fox_src_compile() {
@@ -150,21 +124,21 @@
$(use_with profile profiling
[gentoo-dev] RFC: fox.eclass update
Hi folks,
While fixing bug #240060 I touched fox.eclass.
In the process, I updated the eclass to
* use versionator
* cut support for fox-1.0 (loong outdated)
* cut support for fox-1.5
* use eautomake instead of =automake-1.4*
* use emake instead of make
* use elog instead of einfo
* apply more variable quoting
I'm sure, I missed one or the other issue. That's why I'm posting it
here for public review. If you have requests or comments to make, please
reply to this thread.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.7 2007/01/15 20:27:06
mabi Exp $
# fox eclass
#
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
# parallel-installable, while installing only one version of the utils
# (dev-util/reswrap) and apps (app-editors/adie, sci-calculators/calculator,
# x11-misc/pathfinder, and x11-misc/shutterbug).
#
# Version numbering follows the kernel-style odd-even minor version
# designation. Even-number minor versions are API stable, which patch
# releases aimed mostly at the library; apps generally won't need to be
# bumped for a patch release.
#
# Odd-number versions are development branches with their own SLOT and
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
# Here are sample [R]DEPENDs for the fox apps
# 1.4: '=x11-libs/fox-1.4*'
# 1.5: '~x11-libs/fox-${PV}'
# 1.6: '=x11-libs/fox-${FOXVER}*'
#
# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
inherit autotools eutils libtool versionator
FOX_PV=${FOX_PV:-${PV}}
FOXVER=$(get_version_component_range 1-2)
FOXVER_SUFFIX=-${FOXVER}
DESCRIPTION=C++ based Toolkit for developing Graphical User Interfaces easily
and effectively
HOMEPAGE=http://www.fox-toolkit.org/;
SRC_URI=http://www.fox-toolkit.org/ftp/fox-${FOX_PV}.tar.gz;
IUSE=debug doc profile
FOX_APPS=adie calculator pathfinder shutterbug chart
if [ ${PN} != fox ] ; then
FOX_COMPONENT=${FOX_COMPONENT:-${PN}}
fi
if [ ${PN} != reswrap ] ; then
RESWRAP_DEP=dev-util/reswrap
fi
DEPEND=${RESWRAP_DEP}
doc? ( app-doc/doxygen )
=sys-devel/automake-1.4
=sys-apps/sed-4
S=${WORKDIR}/fox-${FOX_PV}
fox_src_unpack() {
unpack ${A}
cd ${S}
ebegin Fixing configure
# Respect system CXXFLAGS
sed -i -e 's:CXXFLAGS=::' configure.in || die sed configure.in error
touch aclocal.m4
sed -i -e 's:CXXFLAGS=::' configure || die sed configure error
eend
ebegin Fixing Makefiles
# don't build apps from top-level (i.e. x11-libs/fox)
# utils == reswrap
for d in ${FOX_APPS} utils windows ; do
sed -i -e s:${d}:: Makefile.am || die sed Makefile.am error
done
# use the installed reswrap for everything else
for d in ${FOX_APPS} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die sed ${d}/Makefile.am error
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
if version_is_at_least 1.6.34 ${PV}; then
sed -i \
-e s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox${FOXVER_SUFFIX}: \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
-e 's:\.la::' \
${d}/Makefile.am || die sed ${d}/Makefile.am
error
else
sed -i \
-e s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox${FOXVER_SUFFIX}: \
-e 's:../src/libFOX:-lFOX:' \
-e 's:\.la::' \
${d}/Makefile.am || die sed ${d}/Makefile.am
error
fi
done
eend
ebegin Running automake
eautomake || die automake error
eend
#elibtoolize
}
fox_src_compile() {
local myconf
use debug myconf=${myconf} --enable-debug \
|| myconf=${myconf} --enable-release
econf \
${FOXCONF} \
${myconf} \
$(use_with profile profiling) \
|| die configure error
cd ${S}/${FOX_COMPONENT}
emake || die compile error
# build class reference docs (FOXVER = 1.2)
if use doc [ -z ${FOX_COMPONENT} ] ; then
cd ${S}/doc
emake docs || die doxygen error
fi
}
fox_src_install () {
cd ${S}/${FOX_COMPONENT
Re: [gentoo-dev] RFC: 0-day bump requests
Hans de Graaff [EMAIL PROTECTED] wrote: On Fri, 2008-07-04 at 02:31 +0200, Marius Mauch wrote: On Fri, 4 Jul 2008 01:16:09 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: Disclaimer: I'm not really a package maintainer anymore. I am, and Marius said all the things that I would have said. :-) AOL here. For the few packages i maintain, i'm on all relevant channels to be notified of updates in time. But i appreciate user feedback on bumps, for most of the time they come with patches or complete ebuilds. (thanks guys, you're fantastic) I certainly want to stress the wording part of marius' mail. The bump request i dealt with are patch attached kind of stuff. That's not annoying, that shows the user's caring and i appreciate that very much. Especially if the bump is critical i like timely feedback on it, in a hey, this has been out for some days, fixes issue X, which is kind of important to me, could we have a bump in the tree? kind of way. I DO get annoyed by package X has a bugfix release out 5 hours now, why isn't it in the tree yet!!? - but i don't get those bump requests... -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpQTUflDLLsB.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council 2008/2009 - RESULTS
Donnie Berkholz [EMAIL PROTECTED] wrote: On 23:00 Sat 05 Jul , Łukasz Damentko wrote: Gentoo Council for term 2008/2009 will be: Donnie Berkholz (dberkholz) Mark Loeser (Halcy0n) Diego Petteno (Flameeyes) Petteri Raty (Betelgeuse) Luca Barbato (lu_zero) Markus Ullmann (Jokey) Tobias Scherbaum (dertobi123) Looks like a mandate for the preexisting council. Thanks to everyone for your confidence in us! Thanks to you guys for working on the council. I really appreciate the work you, and especially donnie with the planning, put into this. -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgp7xuStDxCE4.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/pvfs2: ChangeLog pvfs2-2.6.3-r1.ebuild
Steve Long [EMAIL PROTECTED] wrote: Mixing 'gt' and 'ge' is a bad idea. Just outa curiosity, why? Because it's inconsistent and one generally assumes that people will be consistent with the way they test numbers. That way you only need to read the number rather than continually checking every single line to see how exactly it's tested for. I don't see how this is inconsistent either: two tests are needed, so that both patches are only applied for =2.6.22 and first only if 2.6.20. The point is that if you stick to ge OR gt, everyone could just skip reading the comparison and focus on the numbers. Will be fixed in the next release, along with kernel-2.4 support... -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpGNkr8MFQEL.pgp Description: PGP signature
Re: [gentoo-dev] Trivial commit reviews
Mike Doty [EMAIL PROTECTED] wrote: Donnie Berkholz wrote: Over time, the number of these simple reviews should go dramatically down so it no longer bothers anyone to see them. If it doesn't, that means some of our developers aren't learning or paying attention, and we should take a closer look at whether they should remain developers. My concern is that if we flood -dev with trivial commit problems then more people will stop watching -dev and/or resort to killfiles or other filtering. While I do agree with Donnies assessment, my concern is that over a longer time period, it might have a negative effect. I totally agree with Donnie here. Please keep up the work, everybody should be encouraged to fix these (trivial) problems. I sincerly hope that these message will not have to continue for long. But as long as they do, they serve as a big reminder in your inbox of what is wrong. Just my 0.02$ -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpSepMsMY6j8.pgp Description: PGP signature
[gentoo-dev] Last rites: net-irc/xdcc-fetch
# Matti Bickel [EMAIL PROTECTED] (18 Sep 2007) # Masked for removal in 30 days # Last release 2005, only works with # unsupported FXRuby-1.0 or -1.2. (bug #177785) net-irc/xdcc-fetch Jokey agreed to let it go. This will greatly simplify FXRuby stuff :-) -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpsUzdRa91Gh.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: x11-wm/ion2
Mike Doty [EMAIL PROTECTED] wrote: Matti Bickel wrote: Hi, as previously mentioned, ion2 is currently broken (bug #167468) and going away in favour of the soon to be stable x11-wm/ion3. It will be p.masked and removed in 30 days unless someone speaks up and solves the issues surrounding slotted lua among others (see the bug for details). didn't we yank ion from the tree because of upstream license problems? We did. That was an oversight on my part, as i still serve ion3 from my dev-overlay over at overlays.gentoo.org. Bad habits telling everyone to use that one instead, sorry. The license still hasn't changed, so this situation will remain. However, ion2 is definitly broken, as the bug explains. -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpdmTMPi7g9c.pgp Description: PGP signature
[gentoo-dev] Last rites: x11-wm/ion2
Hi, as previously mentioned, ion2 is currently broken (bug #167468) and going away in favour of the soon to be stable x11-wm/ion3. It will be p.masked and removed in 30 days unless someone speaks up and solves the issues surrounding slotted lua among others (see the bug for details). -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpcllsOLLfLh.pgp Description: PGP signature
Re: [gentoo-dev] Packages of for grabs
Christian Heim [EMAIL PROTECTED] wrote: On Wednesday 29 August 2007 21:41:07 Christian Heim wrote: maintainer-needed: - x11-wm/ion2 (twp) Will have last-rites this week. With the advent of ion3 stable in my overlay there's no use to keep it. -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpW4nOUe1M6d.pgp Description: PGP signature
Re: [gentoo-dev] Re: How to help an ebuild move along
Christian Faulhammer [EMAIL PROTECTED] wrote: Olivier Galibert [EMAIL PROTECTED]: So my question is, what could I do to help having it end up in the official package database? Become a developer. From the looks of it, there's already a gentoo developer on it. Please help Flammie with that :) -- Regards, Matti Bickel Encrypted/Signed Email preferred pgpdWg7s5MB62.pgp Description: PGP signature
Re: [gentoo-dev] [PMS] Version Naming Clarification
Carsten Lohrke [EMAIL PROTECTED] wrote: On Donnerstag, 7. Juni 2007, Doug Goldstein wrote: That's exactly what I'm saying. CPV (Category/Package/Version) requires =, =, , = to begin it. So you'd like to change every foo/bar occurrence (and that's the common case) to =foo/bar-0 !? Completely out of line, imho. I don't understand what the fuzz is about. sys-fs/ntfs3g is absolutely fine. Fighting for the little - is nonsense. Um no. IF one specifies sys-foo/bar-3g you expect it to be a atom, else you have to prefix it with = to be a CPV. If i choose to specify sys-utils/bar then i get any version of bar, which is fine. If i choose to specify sys-utils/bar-3 and bar-3 is not a valid atom, repoman cries at me. Thus, you can continue using the tree just fine :) HTH, -- Regards, Matti Bickel Encrypted/Signed Email preferred pgpKkjqgEdTea.pgp Description: PGP signature
Re: [gentoo-dev] What's it about, anyway?
Tobias Klausmann [EMAIL PROTECTED] wrote: [lots of good stuff] You rock. It's that simple. Your analysis of the problem hits the nail on the head and i call on all participating devs and users alike to step the hell back and take a deep breath before posting again. It's helps your bloodpressure, your fellow devs and our users. So please stop this nonsense and name-calling. -- Regards, Matti Bickel Encrypted/Signed Email preferred pgprTlgdsqp6P.pgp Description: PGP signature
Re: [gentoo-dev] RFC: ion license
Ciaran McCreesh [EMAIL PROTECTED] wrote: Supporting this would be a huge policy violation, and not so merely as a technicality. How's that? I agree that this timely response clause will mean ion-3 will never go stable. That's the only thing i could envision to be a policy violation. I suggest simply removing ion support from the main tree, and sticking it in an overlay that comes with a big warning telling users that they cannot expect any level of QA for those packages. Care to expand on no QA? Tuomo fixed several QA warnings upstream (missing strlen, etc. includes) when i told him (there will be patches on our side until the next _rc). Additionally i'd like to point out the bit where he says he don't want this license to hinder distributions who just stick with upstream, which our policy explicitly recommends. That's why i'm trying to reach a compromise on those USE patches we apply. That's why the next build will tell ppl to bug me first. In general: i don't think forking is an option. I won't be maintaining a fork myself to begin with. If the general feeling is that ion is unacceptable in the tree, i'll mask it pending removal. -- Regards, Matti Bickel Encrypted/Signed Email preferred pgpq2TuFCjjfL.pgp Description: PGP signature
Re: [gentoo-dev] RFC: ion license
Ciaran McCreesh [EMAIL PROTECTED] wrote: Matti Bickel [EMAIL PROTECTED] wrote: How's that? I agree that this timely response clause will mean ion-3 will never go stable. That's the only thing i could envision to be a policy violation. Right, and packages that aren't aiming for stable eventually shouldn't really be in the tree at all. Point taken. Tbh, i don't think allowing ion to remain in ~arch would be a big deal though. A larger issue, though... It requires some way of pushing updates to a user who hasn't synced for 28 days. The license explicitly makes a exception for a user who hasn't updated or is without net connection, demanding the new version to be shown at next install/upgrade cycle after the sync. If upstream release a new version that has a serious bug, Gentoo would be required to include it as the most visible package within 28 days, even if it is completely unusable. In that case, i will provide a patch or pull the package, if upstream disagrees. However, if it's a critical fix (security), i trust upstream to release a new version asap. On that note: the QA warnings have a patch with gentoo and will be included in the next upstream release. I intend to handle any other fix the same way, and upstream has not spoken out against this. If he doesn't want to hinder distributions, get him to fix his licence. The way it is now makes it impossible for distributions to do their job. We all agree it's retarded. However, i can't change the way it is. In general: i don't think forking is an option. I won't be maintaining a fork myself to begin with. Probably true, from a Gentoo perspective. If there's a significant ion userbase, someone else will do the work. There's already someone doing the work for gentoo. Look at bug #136077, which is, tbh, one of my main motivators to work on that package. I just feel that letting (contributing) users down would be kind of a shame. -- Regards, Matti Bickel Encrypted/Signed Email preferred pgp0YNlgl9W6K.pgp Description: PGP signature
Re: [gentoo-dev] RFC: ion license
Wulf C. Krueger [EMAIL PROTECTED] wrote: In the conversation with you, Matti, he argues that elog is not prominent enough, users don't read USE flag descriptions, etc. So those issues seem unresolved. Well, this arguments are nothing new, just read this ml.. However, i don't think think his reasoning is justified here. We do inform the user, everything else is not within our reach. And imho the license doesn't require more. If i get a cease and desist over *that*, well, screw it. -- Regards, Matti Bickel Encrypted/Signed Email preferred pgp4MSlQKyGCY.pgp Description: PGP signature
[gentoo-dev] RFC: ion license
Hi, recently, there's been some worries about the changes and new requirements the ion upstream, tuomov, put forth in a new LICENSE for ion-3. It's main additions are a timely response clause, which requires us to get the same keywords for a newly released version as the previous had within 28 days. Another point is the no patches clause, which prohibits distributions from carrying a significantly modified ion-3 release under the ion name. As this changes are not properly reflected in any existing license in our tree, i'd like to add the attached original license. I'm still undecided about a name for it. The new release candidate will be up in the tree once a new name is decided. For reference, all the flames, announcements and discussion are in this links: https://lists.berlios.de/pipermail/ion-general/2007-May/002013.html https://lists.berlios.de/pipermail/ion-general/2007-April/001959.html http://archlinux.org/pipermail/tur-users/2007-April/004634.html -- Regards, Matti Bickel Encrypted/Signed Email preferred Copyright (c) Tuomo Valkonen 1999-2007. The code of this project is essentially licensed under the LGPL, version 2.1, unless otherwise indicated in components taken from elsewhere. It is reproduced below. Additionally, the following terms apply to the use of the names Ion, Ion3, and other derived names: Derived works and altered versions that significantly differ from the original copyright holder's versions, must either a) be given names that can not be associated with the Ion project, or b) be qualified as Ion soup, and still be considerable as customised versions of this software. In both cases, executables must also be given names that do not conflict with the original copyright holder's version, and the copyright holder may not be referred to for support. Modules and other (standalone) extensions to Ion must also be named so that they can not be confused to be supported by the copyright holder. If Ion occurs in the name, it must be in the form Foo for Ion instead of Ion Foo, etc. If the name of the project (Ion), resp. names of particular branches (Ion1, Ion2, Ion3, etc.), are used without further prominent version qualifiers and notices of possible out-datedness to distribute this software, then the following conditions must hold: a) The version distributed online may not significantly differ from the copyright holder's latest release marked stable, resp. latest release on a branch, within a reasonable delay (normally 28 days) from the release. b) The holders of physical distribution media are provided ways to upgrade to the latest release within this same delay. This name policy notice may not be altered, and must be included in any altered versions and binary redistributions. It may only be removed when using small portions of the code in unrelated projects. The copyright holder and the Ion project retain the same rights to your modifications that it would have under the LGPL or GPL without these or similar additional terms. Explanations: Significant change: Bug fixes are a priori insignificant as additions. Basic changes that are needed to install or run the software on a target platform are a priori insignificant. Additionally, basic configuration changes to better integrate the software with the target platform, without obstructing the standard behaviour, are a priori insignificant. The copyright holder, however, reserves the right to refine the definition of significant changes on a per-case basis. Please consult when in doubt. Distributions: For example, suppose an aggregate distribution of software provides a `installpkg` command for installing packages. Then the action `installpkg ion3` (resp. `installpkg ion`) should always install the latest release of Ion3 (resp. the latest stable release), online connectivity provided. The action `installpkg ion-3ds-20070318` may at any date install this particular mentioned release. Likewise `installpkg ion-soup` may install any non-conflicting customised version. --- GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser
Re: [gentoo-dev] new herd: theology
Jeroen Roovers [EMAIL PROTECTED] wrote: I shall contemplate fiercely on building my own herd of nightly bloodsuckers, zombies and cannibals. I don't know whether to call it 'postnuclear-vampirism' or just plain 'satanism' yet. I'm interested. Will you bring back xmms? Will your program include last-rites for packages you convert over from maintainer-needed? Oh, and about that theology herd - i do find 'theology' a kinda narrow naming, but that's just me. -- Regards, Matti Bickel Encrypted/Signed Email preferred pgpTVOJsY2bso.pgp Description: PGP signature
Re: [gentoo-dev] Planning for automatic assignment of bugs
Robin H. Johnson [EMAIL PROTECTED] wrote: Taking into account the other reasonable input, how about the name of attribute 'automatic-bug' ? I would like assign somewhere in the name, but i'd be fine with your proposal as well. -- Regards, Matti Bickel Encrypted/Signed Email preferred pgpqjgvmTCCXj.pgp Description: PGP signature
Re: [gentoo-dev] New Developer: Aggelos Orfanakos (agorf)
Welcome Aggy! Mart Raudsepp [EMAIL PROTECTED] wrote: Once Aggy isn't around computers, he finds time to enjoy swimming (/me winks at dad eryof), table tennis, photography, astronomy and listening to music. I challenge you to a match of table tennis. Now come over here and beat me! No, not far at all, just the other side of Europe, so no excuses :p I'll be umpire of this. And after that, i'll beat you two :p We need one more for a double.. -- Regards, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred pgpfusH8wCtzB.pgp Description: PGP signature
Re: [gentoo-dev] Re: Fw: [gentoo-core] [POLICY] Keywording/Stabilizing Bug Assignment Policy
Stefan Schweizer [EMAIL PROTECTED] wrote: They generate irrelevant information for me because I cannot help with stabling. So I would love to have the possibility to -CC me there after siging the stabling off. You are responsible for any failures discovered by arch teams while testing. Nothing sucks more than us discovering ups, $maintainer hasn't tested this code to be endian aware and it goes nuts on my machine and the maintainer not responding to it (yes, i'll prod $maintainer seperatly on IRC, but bugs is just way easier). -- Regards, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred pgp72QDrGy6lJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: New Developer: Tobias Heinlein (keytoaster)
Alec Warner [EMAIL PROTECTED] wrote: Dude masterdriverz is like 29, he just masquerades as a young person to pick up all the 16 year old hotties on irc. There's such a thing? I mean for real, and not 40 year old fatties posing as 16 year old hotties to masterdriverz.. -- Regards, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred pgpYst4I4Bzqv.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Ciaran McCreesh [EMAIL PROTECTED] wrote: If they want to have sekrit meetings with sekrit handshakes, let them. If enough people think this is not acceptable, they'll be gone on the next election. Which is all very well, but it's kind of hard to evaluate the effectiveness of Council members and the Council as a whole if they're doing things behind everyone's backs and making horrible threats to try to prevent people from publishing logs of their goings on... Please evaluate the council's effectivness based on their achievements. And no, secret meetings don't count towards that. Seriously, i understand that the council should be as transparent as possible, but there are issues that need some confidential handling. threatening to pull each others' access if anyone goes public with whatever it was that was discussed, *something* has to be done... Um, that's hard to say without the thing in the open. I just trust the involved parties to have enough insight to bring anything that would harm gentoo to public scrunity (and following outcry). The details can remain private if necessary, but publishing a brief summary along the lines of we discussed x and y and decided z *has* Um, wait. Council *decisions*, as long as they're affecting gentoo's ways, must be out in the open. We won't end up with National Security Letters to infra or something (and i trust there'll be an uproar, if it ever reaches that point). Say, if the council decides to ice a project, how can that be kept secret? -- Regards, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred pgpSbg74jRcs0.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Grant Goodyear [EMAIL PROTECTED] wrote: For what it's worth, I deliberately wrote the GLEP that way. The truth of the matter is that the Council has only whatever power the devs permit, so adding additional restrictions seems like a really bad idea to me. grant++ Seriously, if enough devs can agree that the council's wrong, the council can say all they like, in the end it's the community that has to implement changes. If there's uproar about councils decisions, i'm sure we'd find a way to let them know in a way they can't ignore :) In general, please give the guys some credit, please give the community some credit. We're not powerless, we'll never be. -- Regards, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred pgpoJ5TYtw83W.pgp Description: PGP signature
