[gentoo-dev] Drop the Perl Modules Guideline?
Let's discuss the specific guideline for Perl modules. It's as follows: ,- http://devrel.gentoo.org/handbook/handbook.xml?part=2chap=1#doc_chap2_sect2 | Perl | | New Perl modules are to be added to portage only when one of the following | conditions is met: | | a) The module(s) fulfill a dependency | b) The module(s) cannot be handled by g-cpan | c) The module(s) add functionality to existing ebuilds | d) The module(s) provide tools, applications or other features (i.e. more |than what their .PM offers) | | Please make sure that at least one member of the perl herders approves | your addition. `- Recently the proxy-maintainer project is repeatedly adding packages which aren't following these guideline AFAIK. So maybe we should change it. 444974 a) dev-perl/Text-Format - Various subroutines to format text 2012-12-07 444976 a) dev-perl/Roman - Perl module for conversion between Roman and Arabic numerals.2012-12-03 446710 ?) dev-perl/FLV-AudioExtractor - Extract audio from Flash Videos 2012-12-12 447724 ?) dev-perl/Email-Send-Gmail - Send Messages using Gmail Mon 10:12 Ad a): This requirement is a little problematic: Sometimes perl modules are needed for maintainer-wanted packages. Sometimes the perl modules are added to the tree while the maintainer-wanted package never are or will be. Sometimes the maintainer are waiting for the perl team to do their work. Ad b): (Judging from bugreports) g-cpan doesn't seem to be really reliable these days. I always wanted to test/verify it. But ... (random excuse: time, motivation,...) I guess I don't have no problem with modifying or dropping the requirements. The perl overlay contains hundreds of packages which should be added to the main tree. The dev-perl category currently already contains the most packages (1140 per packages.g.o). -- Best regards Torsten
[gentoo-dev] Re: gentoo-x86 commit in dev-perl/XML-Parser: XML-Parser-2.410.0-r1.ebuild ChangeLog
* Fabian Groffen (grobian) grob...@gentoo.org:
grobian 12/08/07 15:21:54
Modified: ChangeLog
Added:XML-Parser-2.410.0-r1.ebuild
Log:
Fix expat detection for FreeBSD that silently went unnoticed.
The following single quotes were dropped:
-myconf=EXPATLIBPATH='${EPREFIX}/usr/$(get_libdir)'
EXPATINCPATH='${EPREFIX}/usr/include'
+myconf=EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir)
EXPATINCPATH=${EPREFIX}/usr/include
Sorry, I don't understand the problem. Is it a general problem with
the single quote or a special FreeBSD problem?
I think we should convert all myconf strings to arrays:
myconf=( EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir)
EXPATINCPATH=${EPREFIX}/usr/include )
--
Thanks
[gentoo-dev] About forcing rebuilds of perl modules
* Ian Stakenvicius a...@gentoo.org: FYI, all the work subslotting the perl stuff doesn't work yet, so it's probably best to wait a few days before trying it out. Perl modules have to be rebuilt if dev-lang/perl's useflags are changed. That would make dev-lang/perl's SLOT depend on users USE flags settings which is forbidden. Or will it work for sub-slot part? SLOT=0/5.16(?ithreads:-ithreads)(?debug:-debug) -- Thanks Torsten
[gentoo-dev] Last rites: dev-perl/Tie-RegexpHash, net-proxy/vulture
The following packages will be removed from the tree: # Mask for removal (#421461) # Test suite fails since perl 5.13.6 dev-perl/Tie-RegexpHash # Mask for removal (#310711) # vulture is the only consumer of =dev-perl/DBD-SQLite-0.31* net-proxy/vulture
[gentoo-dev] Last rites: dev-perl/CPAN-Mini-Phalanx, dev-perl/gimp-perl, dev-perl/XML-Sablot, dev-perl/Devel-Profiler
The following packages will be removed from the tree: # Masked for removal (#420075) # The Phalanx Project is finished and no longer active dev-perl/CPAN-Mini-Phalanx # Masked for removal (#249786,#331675,#420211) # No release since 2005, not needed. dev-perl/gimp-perl # Masked for removal (#420179) # Fails with perl-5.16, probably 5.14 too. # No release since 2005, not needed in the tree and # upstream bug not fixed for one year dev-perl/XML-Sablot # Masked for removal (#420109) # Depends on Devel-DProf, removed from perl-5.16. # Use dev-perl/Devel-NYTProf instead dev-perl/Devel-Profiler
[gentoo-dev] remote-id cpan-module
* Corentin Chary iks...@gentoo.org:
On Thu, May 17, 2012 at 2:02 AM, Kent Fredric kentfred...@gmail.com wrote:
On 13 May 2012 07:43, Torsten Veller t...@gentoo.org wrote:
It doesn't even list Moose for Moose?
Its probably falling outside the initial 10 results, I forgot it did that,
02packages.details.txt.gz lists 72 package names for Moose-2.0602.
Need to bolt on a { size: 100 } to the query to expand how may
results it will return.
Updated remotesid.py to use that, correctly add Moose in the diff now !
metadata.dtd was updated per bug #406287 and it contains the cpan-module
remote-id.
The current patch for dev-perl/* is roughly 800k big:
http://dev.gentoo.org/~tove/files/devperlremoteids.patch
I am going to update the files in the next days.
Now it would be a good time to voice your concerns.
--
Thanks
Torsten
[gentoo-dev] Last rites dev-perl/Cflow, dev-lang/eleven and net-im/silc-client
Masked until fixed or removed: # Install perl modules in the site branch (#280728) # - dev-perl/Cflow (#391391) # - dev-lang/eleven (#295118) # - net-im/silc-client (#294854) dev-perl/Cflow dev-lang/eleven net-im/silc-client
[gentoo-dev] Re: License groups in ebuilds
* Kent Fredric kentfred...@gmail.com:
I'd welcome groups so we can have a Perl_5 group. The lions share of
modules published on CPAN are licensed Under the same license as Perl
5 Itself, which implies || ( GPL-2 Artistic-1 )
Perl is licensed as
| This program is free software; you can redistribute it and/or modify
| it under the terms of either:
|
| a) the GNU General Public License as published by the Free
| Software Foundation; either version 1, or (at your option) any
| later version, or
|
| b) the Artistic License which comes with this Kit.
The perl-module.eclass offers a default LICENSE as
LICENSE=${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}
So if a distribution uses the same license as Perl 5 itself you can
just drop the LICENSE from the ebuild (as long no former eclass sets its
own LICENSE).
I've further added comments to the LICENSE in the ebuilds if it does not
use the same terms as the Perl 5 programming language system itself
but or-later group of licenses (like GPL-2+ or Artistic+...).
--
Regards
[gentoo-dev] Re: RFC: Add new remote-id types in metadata.dtd
* Corentin Chary corentin.ch...@gmail.com:
On Sat, Apr 21, 2012 at 03:33:18PM +1200, Kent Fredric wrote:
{ term: { status:latest} },
{ term: { module.authorized:true}}
What does this mean?
- latest? this term looks like maintenance work.
- what is authorized?
It doesn't even list Moose for Moose?
02packages.details.txt.gz lists 72 package names for Moose-2.0602.
--- a/dev-perl/Moose/metadata.xml
+++ b/dev-perl/Moose/metadata.xml
@@ -3,6 +3,17 @@
pkgmetadata
herdperl/herd
upstream
+remote-id type=cpan-moduleClass::MOP/remote-id
+remote-id
type=cpan-moduleMoose::Meta::Attribute::Native::Trait::Counter/remote-id
+remote-id
type=cpan-moduleMoose::Meta::Attribute::Native::Trait::String/remote-id
+remote-id type=cpan-moduleMoose::Meta::Method::Delegation/remote-id
+remote-id
type=cpan-moduleMoose::Meta::TypeConstraint::Role/remote-id
+remote-id
type=cpan-moduleMoose::Meta::Attribute::Custom::Moose/remote-id
+remote-id type=cpan-moduleMoose::Meta::Attribute/remote-id
+remote-id type=cpan-moduleMoose::Meta::Method/remote-id
+remote-id type=cpan-moduleMoose::Error::Croak/remote-id
+remote-id type=cpan-moduleMoose::Util::MetaRole/remote-id
+remote-id type=cpan-moduleMoose::Role/remote-id
remote-id type=cpanMoose/remote-id
/upstream
/pkgmetadata
[gentoo-dev] Re: License groups in ebuilds
* Ciaran McCreesh ciaran.mccre...@googlemail.com:
On Sat, 12 May 2012 21:05:06 +0200
Torsten Veller t...@gentoo.org wrote:
The perl-module.eclass offers a default LICENSE as
LICENSE=${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}
So if a distribution uses the same license as Perl 5 itself you can
just drop the LICENSE from the ebuild (as long no former eclass sets
its own LICENSE).
That's definitely not going to work if the 'inherit' comes at the top
of the ebuild, and is severely dodgy if it doesn't...
What doesn't work?
--
Regards
[gentoo-dev] Re: making the stable tree more up-to-date
* Paweł Hajdan, Jr. phajdan...@gentoo.org: Please review the list, it's 800+ packages so I thought about asking for feedback before filing stabilization bugs (I plan to do that in stages of course). What do you expect to happen with bugs assigned to maintainer-needed? I don't know if any of the packages is really good to be stabilized. Maybe they are better than the current stable version, maybe not. -- Regards Torsten
[gentoo-dev] Bugzilla proxy-maintainer template
* Markos Chandras (hwoarang) hwoar...@gentoo.org: Log: add note about default comment in bugs. Add template +titleBugs assigned to maintainer-nee...@gentoo.org/title +body +pDevelopers who participate in this project should encourage users to participate in this project when they notice a open bug for an orphaned package. uri link=default-comment.txtThis/uri template (or a similar one) can be used to inform users about this project. Template: This package has no maintainer so this bug may go unnoticed for a long time. Gentoo has a dedicated team[1] for assisting users in maintaining orphaned packages. If you are interested in maintaining this package, please contact proxy-ma...@gentoo.org. Did you consider to ask the bugzilla maintainers to add a Note like the one for security bugs? Maybe it can also be shown early in the bug-filing process. I am asking because the number of sunrise mails via maintainer-wanted and now the expected proxy-maint info mails via maintainer-needed are boring. -- Thanks
[gentoo-dev] Re: Bugzilla proxy-maintainer template
* Markos Chandras hwoar...@gentoo.org: However, a comment draws more attention than a bugzilla note. That's exactly the problem for watchers of maintainer-needed or -wanted. Every mail draws some attention. Anyway I can /dev/null those mails. Just need to create another rule. -- Regards
[gentoo-dev] write to filesystem in pkg_pretend
* justin j...@gentoo.org: Now using the new pkg_pretend for EAPI=4 While T is defined in all phases, PMS also says that pkg_pretend must not write to the filesystem. Is it allowed to write to T or not? Can the specs be clearer if it's allowed? -- Thanks
[gentoo-dev] Re: rejecting unsigned commits
* Mike Frysinger vap...@gentoo.org: On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote: [Manifest signing] Does that get us any closer to GLEPs 57, 58, 59 (or generally approaching the tree-signing/verifying group of problems)? yes I think, it's a no. The MetaManifest GLEP relies on a signed top-level MetaManifest which hashes all sub Manifests, whether they are signed or not doesn't matter. I don't see a major advantage to signed portage snapshots we already offer today. Do you want to reject signed commits if - keys are not publicly available [1] - signatures are from expired keys [2] - keys are revoked [3] - keys are not listed in userinfo.xml (current or former devs) [4] [1] https://bugs.gentoo.org/205405 [2] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/signatures_by_expired_keys.txt [3] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/signatures_by_revoked_keys.txt [4] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/keys_in_use.txt
[gentoo-dev] Re: Adding app-arch/xz-utils to the system set
* Jeremy Olexa darks...@gentoo.org: Well, the interesting bit of info is that the wider developer community maybe already assumes it to be in the system set. *OR* can't be bothered to remember that it is NOT in the system set. The data to back up this statement is in https://bugs.gentoo.org/349315 in which ~20 packages are discovered to be missing the build time dep. The same argument can be used to add app-arch/unzip to the system set. ~106 packages do not DEPEND on app-arch/unzip while using a zip file. I think the missing dependency problem should be fixed by a repoman patch. The two bugs in the OP weren't PM-can-not-unpack-the-sources problems. -- Regards Torsten
[gentoo-dev] Re: Status of sparc-fbsd
* Samuli Suominen ssuomi...@gentoo.org: So I think your own chance is to contact aballier, ask if he still has access (or ask for renewed opinion for the killing) That was the intention. I cc'ed the bsd team and am still expecting a reply. I will move the sparc-bsd and amd-bsd profiles to exp in one week. I suggest to remove amd-bsd completely. --- profiles.desc 14 Dec 2010 20:44:09 - 1.166 +++ profiles.desc 11 Feb 2011 06:49:12 - @@ -147,8 +147,8 @@ # Gentoo/FreeBSD Profiles -amd64-fbsd default/bsd/fbsd/amd64/7.2 dev -amd64-fbsd default/bsd/fbsd/amd64/8.0 dev -sparc-fbsd default/bsd/fbsd/sparc/7.2 dev -sparc-fbsd default/bsd/fbsd/sparc/8.0 dev +amd64-fbsd default/bsd/fbsd/amd64/7.2 exp +amd64-fbsd default/bsd/fbsd/amd64/8.0 exp +sparc-fbsd default/bsd/fbsd/sparc/7.2 exp +sparc-fbsd default/bsd/fbsd/sparc/8.0 exp x86-fbsd default/bsd/fbsd/x86/7.2dev x86-fbsd default/bsd/fbsd/x86/8.0dev
[gentoo-dev] Touching profiles
* Theo Chatzimichos tampak...@gentoo.org: For the record, Kacper told me today that every developer is allowed to touch ppc/ppc64 profiles. Archies that don't want others to touch their profiles should mention it in the devmanual. I was not aware of that, I thought that !arch member is not allowed to touch arch-specific profiles. The situation is complicated: - The devmanual[1] reference is wrong. I wonder where it comes from. The devmanual wasn't considered policy (mainly because it was started by ca connection devmanual - policy creeps in. *shrug* - Some arch teams don't want other devs to touch their profiles: DON'T TOUCH THIS FILE. Instead, file a bug and assign it to... But this arch is neiter mentioned in the handbook nor in the manual: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=5#doc_chap4 http://devmanual.gentoo.org/archs/index.html - The devhandbook[2] is also kind of unmaintained. Devmanual and -handbook are waiting for a merge AFAIR. - And there is already a stalled bug[3] about Developer Handbook should document how/when to touch arch profiles' files Summary: You do it wrong either way. [1] http://devmanual.gentoo.org [2] http://devrel.gentoo.org/handbook [3] https://bugs.gentoo.org/304435 -- Thanks
[gentoo-dev] Status of sparc-fbsd, amd64-fbsd
Arch teams handle KEYWORDREQ bugs too. I have masked the only dev-lang/perl version keyworded for sparc-fbsd 3 weeks ago. No user, no dev complained by now (#288028). So I think this arch (as much as amd64-fbsd) is unsupported/dead but repoman's dependencies check reports a lot of warnings due to the dev status of their profiles. Do we want to: - remove amd64-fbsd completely (affects app-doc/pms, sys-apps/grep)? - move sparc-fbsd-profiles to exp or kill it? -- Regards Torsten
[gentoo-dev] Re: bugzilla cleanup: remove SECURITY keyword?
* \Paweł Hajdan, Jr.\ phajdan...@gentoo.org: I've noticed we have a SECURITY keyword on bugs.gentoo.org, but only 79 bugs have it, and doesn't seem to be actively used, so it seems to only add confusion. What do you think about removing it? What sort of confusion does SECURITY add? Do other keywords[1] like Bug add confusion too? Is it worthwhile to remove the SECURITY keyword from 79 bugs... ...if you consider that (if everyone gets keyword-changes bugzilla mails, it's an Email Preference[2] configurable in bugzilla) 79 mails are sent to 11 + 63 + other CC'ed recipients? ...if the keyword modification mails weren't sent but one of our infra members had to spend time on this? [1] https://bugs.gentoo.org/describekeywords.cgi [2] https://bugs.gentoo.org/userprefs.cgi?tab=email
[gentoo-dev] Re: bugzilla cleanup: remove SECURITY keyword?
* Alex Legler a...@gentoo.org: On 1/18/11 3:31 PM, Paweł Hajdan, Jr. wrote: Is it worthwhile to remove the SECURITY keyword from 79 bugs... It is not, we would have told you before if you had actually asked us. (hoping you get the hint) Paweł actually asked: What do you think about removing it? Why can't we (whoever it is) answer here? -- Piece Torsten
[gentoo-dev] Re: Ebuild- and CPAN-versions compatibility
* Torsten Veller t...@gentoo.org:
CPAN and ebuild versions are ordered in different ways. The idea here is
to change the ebuild versions to be predictable and CPAN compatible.
I've committed dev-perl/Gentoo-PerlMod-Version which contains a perl module and
a scipt to convert the versions. gentoo-perlmod-version.pl maps given
perlish versions to ebuild versions (perl = ebuild):
$ gentoo-perlmod-version.pl 0.9 0.98 0.987 v0.{900,980,987} 0.{900,980,987}.0
0.9 = 0.900
0.98 = 0.980
0.987 = 0.987
v0.900 = 0.900
v0.980 = 0.980
v0.987 = 0.987
0.900.0 = 0.900
0.980.0 = 0.980
0.987.0 = 0.987
gentoo-perlmod-version.pl 0.9 0.08 0.007 0.0006 0.5 0.04 0.003
0.9 = 0.900
0.08 = 0.80
0.007 = 0.7
0.0006 = 0.0.600
0.5 = 0.0.50
0.04 = 0.0.4
0.003 = 0.0.0.300
Using version.pm the ebuild and perl versions can be compared:
The ebuild version just needs to be prefixed with a 'v'.
$ perl -wE 'while(@ARGV){say version-parse(shift) = version-parse(shift)}'
v1.1 1.001 v1.190 1.19
The given perl distribution version will be recorded as MODULE_VERSION in
the ebuild. (For ease of use s/^MODULE_VERSION=([']?)(.+)\1/$2/ should
return the version if not PV.)
Diff of the perl-module.eclass is attached.
The change of versioning will result in ~22 downgrades:
$ find dev-perl -name *.ebuild | egrep '\.[1-9][0-9]{3}'
dev-perl/POE-Component-IKC/POE-Component-IKC-0.2200.ebuild
dev-perl/Class-Accessor-Grouped/Class-Accessor-Grouped-0.1.ebuild
dev-perl/IO-Moose/IO-Moose-0.1004.ebuild
dev-perl/DBD-mysql/DBD-mysql-2.9007.ebuild
dev-perl/text-autoformat/text-autoformat-1.669002.ebuild
dev-perl/text-autoformat/text-autoformat-1.669001.ebuild
dev-perl/CPAN-Mini/CPAN-Mini-1.100630.ebuild
dev-perl/Tie-Cache-LRU/Tie-Cache-LRU-20081023.2116.ebuild
dev-perl/DateTime-Format-Strptime/DateTime-Format-Strptime-1.5000.ebuild
dev-perl/DateTime-Format-Strptime/DateTime-Format-Strptime-1.4000.ebuild
dev-perl/Net-Twitter/Net-Twitter-3.14001.ebuild
dev-perl/Net-Twitter/Net-Twitter-3.13009.ebuild
dev-perl/XML-RAI/XML-RAI-1.3031.ebuild
dev-perl/XML-RAI/XML-RAI-1.3022.ebuild
dev-perl/Algorithm-Diff/Algorithm-Diff-1.1902.ebuild
dev-perl/Throwable/Throwable-0.102080.ebuild
dev-perl/Email-Sender/Email-Sender-0.102370.ebuild
dev-perl/Email-Sender/Email-Sender-0.101760.ebuild
dev-perl/Convert-BER/Convert-BER-1.3200.ebuild
dev-perl/Convert-BER/Convert-BER-1.3101.ebuild
dev-perl/Scalar-Properties/Scalar-Properties-1.100860.ebuild
dev-perl/DateTime-Format-Mail/DateTime-Format-Mail-0.3001.ebuild
dev-perl/File-chdir/File-chdir-0.1002.ebuild
dev-perl/File-chdir/File-chdir-0.1003.ebuild
dev-perl/Net-Netmask/Net-Netmask-1.9015.ebuild
dev-perl/PlRPC/PlRPC-0.2020-r1.ebuild
dev-perl/SQL-Translator/SQL-Translator-0.11006.ebuild
dev-perl/SQL-Translator/SQL-Translator-0.11007.ebuild
dev-perl/Perl6-Junction/Perl6-Junction-1.4.ebuild
dev-perl/MP3-Tag/MP3-Tag-0.9709.ebuild
- Die on unsupported EAPI
- Die if PERL_EXPORT_PHASE_FUNCTIONS not yes or no
- Add support for MY_PN, MY_PV, MODULE_VERSION
- Allow use of myconf, mymake, myinst as arrays
- Use Module::Build even if Module::Build is not prefered but no Makefile.PL is
found
--- a/eclass/perl-module.eclass
+++ b/eclass/perl-module.eclass
@@ -34,7 +34,7 @@
esac
;;
*)
- DEPEND=EAPI-UNSUPPORTED
+ die EAPI=${EAPI} is not supported by perl-module.eclass
;;
esac
@@ -46,7 +46,7 @@
debug-print PERL_EXPORT_PHASE_FUNCTIONS=no
;;
*)
- DEPEND+= PERL_EXPORT_PHASE_FUNCTIONS-UNSUPPORTED
+ die PERL_EXPORT_PHASE_FUNCTIONS=${PERL_EXPORT_PHASE_FUNCTIONS}
is not supported by perl-module.eclass
;;
esac
@@ -54,6 +54,10 @@
LICENSE=${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}
+if [[ -n ${MY_PN} || -n ${MY_PV} || -n ${MODULE_VERSION} ]] ; then
+ : ${MY_P:=${MY_PN:-${PN}}-${MY_PV:-${MODULE_VERSION:-${PV
+ S=${MY_S:-${WORKDIR}/${MY_P}}
+fi
[[ -z ${SRC_URI} -z ${MODULE_A} ]] MODULE_A=${MY_P:-${P}}.tar.gz
[[ -z ${SRC_URI} -n ${MODULE_AUTHOR} ]] \
SRC_URI=mirror://cpan/authors/id/${MODULE_AUTHOR:0:1}/${MODULE_AUTHOR:0:2}/${MODULE_AUTHOR}/${MODULE_SECTION:+${MODULE_SECTION}/}${MODULE_A}
@@ -97,21 +101,31 @@
# Disable ExtUtils::AutoInstall from prompting
export PERL_EXTUTILS_AUTOINSTALL=--skipdeps
- if [[ ${PREFER_BUILDPL} == yes -f Build.PL ]] ; then
+ if [[ $(declare -p myconf 2-) != declare -a myconf=* ]]; then
+ local myconf_local=(${myconf})
+ else
+ local myconf_local=(${myco...@]})
+ fi
+
+ if [[ ( ${PREFER_BUILDPL} == yes || ! -f Makefile.PL ) -f Build.PL
]] ; then
einfo Using Module::Build
if [[ ${DEPEND} != *virtual/perl-Module-Build* ${PN} !=
Module-Build ]] ; then
eqawarn QA Notice: The ebuild uses Module::Build but
doesn't depend on it.
eqawarn
[gentoo-dev] Ebuild- and CPAN-versions compatibility
CPAN and ebuild versions are ordered in different ways. The idea here is
to change the ebuild versions to be predictable and CPAN compatible.
CPAN versions exist as decimal and dotted-integer versions.
| # Decimal versions #
| \d+(\.d+)?
|
| Any version which looks like a number[...]. This
| also includes versions with a single decimal point[...]
1.19 1.191 1.2
| # Dotted-Integer Versions #
| v\d+(\.\d{1,3}){2,}
|
| These contain more than one decimal point[...]
| This is what is commonly used in most open source software as the
| external version[...] A leading 'v' character is now required
v1.9.0 v1.10.0 v1.10.0.1
These version objects can be compared by grouping three digits of the
decimal number to one integer part of the dotted-integer version...
1.19 = 1.190 = 1.19 ~ v1.190.0
1.191 = 1.191 = 1.191000 ~ v1.191.0
1.2 = 1.20 ~ v1.200.0
1.009 = 1.009000 ~ v1.9.0
1.01 = 1.01 ~ v1.10.0
1.01001 ~ v1.10.0.1
perl -wE'use version;@v=map{version-parse($_)}...@argv;print map{$_-numify,
,$_-normal,\n}...@v' \
1.19 1.191 1.2 1.9.0 1.10.0 1.10.0.1
Many CPAN distributions are released in decimal version format. Most of
the time it's no problem to use the same version as PV. Sometimes it is...[2]
I solved it by adding additional dots.
1.191 becomes 1.19.1, 5.251 becomes 5.2.5.1, depending on former
releases. By removing the additional dots from PV it's easy to get the
upstream decimal version. But it differs from perlish versions meaning.
The current list of outdated cpan packages[1] contains at least four
packages that need attention:
| App-CLI 0.080.313
| IO-AIO 3.653.7
| MARC-Charset1.3 1.31
| Sphinx-Search 0.220.2401
Vincent Pit currently maintains a number of special version mappings[6] for
CPANPLUS-Dist-Gentoo[4][5] (creates ebuilds from the CPAN like g-cpan
does) and suggested to move to a predictable and CPAN-compatible
versioning scheme:
| if the version starts by 'v' or has at least two dots, then it's used
| as-is (thus 'v1.2' becames '1.2' and '1.2.3' stays the same) ; otherwise
| the version number is a float 1.xxxyyyzzz... which is mapped to
| 1.xxx.yyy.zzz with padding zeros if needed ('1.1' would become '1.100',
| and '1.0701' would be '1.070.100')
(whether 1.0701 becomes 1.070.100 or 1.70.100 has to be decided but
doesn't really matter.)
I like this but it also means:
- set the CPAN version inside the ebuilds
- touch a lot of ebuilds
- have some downgrades[3]
- some upstreams force 0.21 0.21.1 (which isn't true for cpan
versioning!). hopefully these are only historical issues.
- versions look different but mean the same
- fix tools like up2date-ng, g-cpan,...
Maybe we should start by fixing only the packages where the CPAN versions
weren't compatible with PMS? Instead of having mappings for many cases
we only need a list of packages with transformed versions?
Comments?
[0] https://github.com/gentoo-perl/wiki/wiki/version
[1] http://www.gentoo.org/proj/en/perl/outdated-cpan-packages.xml
[2] grep ^inherit.*versionator dev-perl/**/*.ebuild | wc -l # 86
[3] find dev-perl -name *.ebuild | egrep \.[0-9]{4,} | wc -l # ~68
downgrades
[4] http://search.cpan.org/dist/CPANPLUS-Dist-Gentoo/
[5]
https://github.com/gentoo-perl/perl-experimental/tree/master/dev-perl/CPANPLUS-Dist-Gentoo
[6]
http://cpansearch.perl.org/src/VPIT/CPANPLUS-Dist-Gentoo-0.11/lib/CPANPLUS/Dist/Gentoo/Maps.pm
[gentoo-dev] Old-style virtuals blocking feature needed for virtual/mta
* Ciaran McCreesh ciaran.mccre...@googlemail.com: Is there anything in particular holding back replacing most or all of the remaining old-style virtuals with new 'package' virtuals? There's still that stupid !virtual/blah thing to deal with. Old style virtual providers are allowed to block their own virtual to mean there must not be any other provider of this installed (although it's not clear what that means if anything other than a simple !virtual/pkg is used). Anything doing that would now have to explicitly list its own blocks. Arguably, this is a good thing, since you'd have to say exactly what you do and don't work with. This is a problem for virtual/mta. As long as we have to block all other mailers with the sendmail compatibility interface to avoid collisions, adding explicit blockers for mailers in all repositories is unlikely to work well. The former mailwrapper/mailer-config tools solved this problem but they were too slow. Once we have a better alternatives system (#348843) the problem might be sorted out (as you probably know). -- Regards Torsten
[gentoo-dev] Re: Stable Python stage repair thread
* Sebastian Pipping sp...@gentoo.org:
+repair_python_integration() {
+ case $1 in
+ pkg_postinst)
You could also use EBUILD_PHASE.
http://dev.gentoo.org/~tanderson/pms/eapi-2-approved/pms.html#TBL-11-41-2
[gentoo-dev] Re: FOSDEM 2011
* Markus Duft markus.d...@salomon.at: markus.d...@salomon.at wrote: booth registration is not yet open, i will have an eye on this too... right now i'm _very_ busy with work (and life ;)), thus i cannot manage all this anymore (booth application, flyers, posters, cds, etc. Also a The Call for Stands is open until 2010-12-06. -- Regards Torsten
[gentoo-dev] Last rites: app-portage/flagedit app-portage/profuse dev-util/libconf app-admin/config_confd
# Torsten Veller t...@gentoo.org (11 Nov 2010) # Masked for removal. Unmaintained with bugs # (#162753,#196552,#225071,#297650,#300104,#326099) app-admin/config_confd app-portage/flagedit app-portage/profuse dev-util/libconf
[gentoo-dev] Re: Maintainer needed for app-portage/flagedit app-portage/profuse dev-util/libconf
* Michał Górny mgo...@gentoo.org: Torsten Veller t...@gentoo.org wrote: If nobody is interested, I'll mask them for removal in one week. If nobody is interested indeed, I'd appreciate a longer removal period Longer than the typical 30 days? Alternatively I can move the packages from the perl herd to maintainer-needed and we wait until the replacement is finished... -- Regards Torsten
[gentoo-dev] Maintainer needed for app-portage/flagedit app-portage/profuse dev-util/libconf
Moin, is anybody interested to maintain the following packages? | app-admin/config_confd | app-portage/flagedit | app-portage/profuse | dev-util/libconf If nobody is interested, I'll mask them for removal in one week. https://bugs.gentoo.org/buglist.cgi?quicksearch=app-admin/config_confd,app-portage/flagedit,app-portage/profuse,dev-util/libconf -- Regards
[gentoo-dev] Re: QA last rites: media-video/elltube
* Markos Chandras hwoar...@gentoo.org: On Sat, Oct 23, 2010 at 08:39:22PM +0300, Petteri Räty wrote: On 10/23/2010 04:16 PM, Markos Chandras wrote: # Markos Chandras hwoar...@gentoo.org (23 Oct 2010) # on behalf of QA team # # Does not work with recent versions of ffmpeg. # Does not work with youtube anymore due to API changes. # Dead upstream. # Removal in 15 days. # Alternatives: # media-video/minitube # media-video/xvideoservicethief media-video/elltube I think whenever faster than the standard 30 days is used then there should be a reason in the mask entry. You need more reasons that those I already mentioned? The package is broken, can't be fixed in any way, since there is no upstream anymore and plus there are more featureful programs to view youtube videos than this one. Imho, the 30 days does not make sense here. If I am not completely out of date, portage doesn't warn you if you have a package installed that is no longer available, meaning the ebuild was removed from your repositories. If you don't sync while the package is masked, you might not realise that you have removed software installed. That might be one reason to keep the package.mask entry longer than 15 days. Or I and the premise are completely wrong, then why don't you remove the package in one week? -- Regards
[gentoo-dev] perl-5.12 news item
Remind users to run perl-cleaner after installing a new perl version. This will be committed before the arch teams stabilize dev-lang/perl-5.12.2-r1. , 2010-10-16-perl-5.12-upgrade-procedure.en.txt Title: Perl 5.12 upgrade procedure Author: perl-team p...@gentoo.org Content-Type: text/plain Posted: 2010-10-16 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-lang/perl-5.12 Run `perl-cleaner --all` after upgrading to a new Perl version! Perl 5.12 is not binary compatible with prior releases of Perl. If you have built extensions (i.e. modules that include C code) using an earlier version of Perl, you will need to rebuild and reinstall those extensions. [1] In fact, in Gentoo you currently have to rebuild all Perl modules and all binaries linking libperl to get into a consistent state again. perl-cleaner generates a list of broken packages and passes it to your package manager to reinstall them. After reinstalling the packages, perl-cleaner outputs a list of files the script could not deal with (like modules installed not via the package manager). See `man perl-cleaner` for its options. [1] http://search.cpan.org/dist/perl-5.12.2/INSTALL#Changes_and_Incompatibilities `
[gentoo-dev] Re: gentoo-x86 commit in perl-core/IO-Compress:
* Mike Frysinger (vapier) vap...@gentoo.org:
vapier 10/08/23 20:01:12
Modified: IO-Compress-2.027.ebuild IO-Compress-2.024.ebuild
IO-Compress-2.026.ebuild ChangeLog
IO-Compress-2.025.ebuild IO-Compress-2.030.ebuild
IO-Compress-2.021.ebuild
Log:
Add proper blockers to old split packages #274443.
RDEPEND=virtual/perl-Scalar-List-Utils
=virtual/perl-Compress-Raw-Zlib-${PV}
- =virtual/perl-Compress-Raw-Bzip2-${PV}
+ =virtual/perl-Compress-Raw-Bzip2-${PV}
+ !perl-core/Compress-Zlib
+ !perl-core/IO-Compress-Zlib
+ !perl-core/IO-Compress-Bzip2
+ !perl-core/IO-Compress-Base
DEPEND=${RDEPEND}
#test? ( dev-perl/Test-Pod )
How long do you think the blockers should exist?
12 months ago they were removed from perl-core.
16 months ago they were moved from dev-perl to perl-core. Do you want to
block them too?
Why didn't anybody reply to
mid.gmane.org/20100803082816.tac2b81f...@veller.net
It's the same problem.
--
Regards
[gentoo-dev] Re: gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20100809-summary.txt
* Tomas Chvatal (scarabeus) scarab...@gentoo.org: 4) Bugs assigned to council@ in bugzilla and their progress https://bugs.gentoo.org/buglist.cgi?query_format=advancedshort_desc_type= allwordssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type =allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstr status_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMED bug_status=NEWbug_status=ASSIGNEDemailassigned_to1=1emailcc1=1emailtype1= substringemail1=council%40gentoo.orgemailassigned_to2=1emailreporter2=1 emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes= chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+ last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= Look up bugzilla's quicksearch help. The following quicksearch lists all unresolved bugs: http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:coun...@gentoo.org
[gentoo-dev] Re: gentoo-x86 commit in mail-filter/mailfilter: ChangeLog mailfilter-0.8.2.ebuild
EAPI=2
-
inherit eutils
DESCRIPTION=Mailfilter is a utility to get rid of unwanted spam mails
@@ -19,16 +18,16 @@
RDEPEND=
src_prepare() {
- epatch ${FILESDIR}/0.8.2-gcc44.patch
+ epatch ${FILESDIR}/0.8.2-gcc44.patch \
+ ${FILESDIR}/0.8.2-openssl-1.patch
}
src_compile() {
- # bug #281069
- emake -j1 || die emake failed
+ emake -j1 || die #281069
}
src_install() {
- emake DESTDIR=${D} install || die make install failed
+ emake DESTDIR=${D} install || die
dodoc INSTALL doc/FAQ ${FILESDIR}/rcfile.example{1,2} \
- README THANKS ChangeLog AUTHORS NEWS || die doc failed
+ README THANKS ChangeLog AUTHORS NEWS || die
}
Etiquette policy
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=2:
| Respect developers' coding preferences. Unnecessarily changing the
| syntax of an ebuild increases the load on the CVS server and can cause
| complications for others. Syntax changes should only be done if there is
| a real benefit, such as faster compilation, improved information for the
| end user, or compliance to Gentoo policies.
If you are not the maintainer, don't quote any policy compliance in
ChangeLog, I think this is a breach of the etiquette policy.
Thanks
[gentoo-dev] Re: Council Election Results
The good old ruby grapher with: ScaleSize= 11 HeightScale = 3 BarHeight= 11 ferringb (1) halcy0n (2) jmbsvicetto | | | | |#| |#|#|# |#|#|# |#|#|# |#|#|# |## |# # |### |### #|### # | |### #|### # | |## #| # | |## |### ## | # |## |### |## +--- +--- +--- chainsaw (4) betelgeuse (5)scarabeus (6 | | | | | | | | | | | | | |#| |# # |#|# |# # |## |# |# ###|## #|# # # |## |## # #|### ## |### |## ## |## |### # |## ### |## |### |### |### +--- +--- +--- wired (7) patrick (8) phajdan.jr ( | | | | | | | | | | | | | # | | # | # |#| # | # |#| # | ### |#| # # |# ## | # ## | # # |# ## # | # |### ## |# |### |## |### |### |### +--- +--- +--- sping (10)_reopen_nomi | | | | | | | # | |## |# |## | ## |## | |# ## | |# ### | # |# ## | # ## |### ### | |### |# +--- +---
[gentoo-dev] Re: devmanual change notification
* Jeroen Roovers j...@gentoo.org: Devmanual gets patched? No seriously - I guess mail to dev-announce@ would be nice in case of changes to devmanual. Useful for all developers who don't like getting spammed by the commits mailing list. Since moving from subversion to git we don't get any notification at all. Not even the commits list gets the changes. Before the move the commits were also sent to the devmanual-commits alias. The best we currently have are the feeds from gitweb[1] but they only show the log. For a patch we have to click another link. [1] http://sources.gentoo.org/gitweb/?p=devmanual.git
[gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open
Hello fellow developers and users. Nominations for the Gentoo Council 2010/2011 are now open for the next two weeks (until 23:59 UTC, 18/06/2010). All nominations must be sent to the gentoo-dev mailing list. If you were nominated and want to run, you have to accept your nomination on the same mailing list. Here are the rules: * Council elections generally happen once a year * The council is composed of seven elected members * Nominations are allowed from June 5th 00H00 UTC to June 18th 23H59 UTC * Only Gentoo developers may be nominated * Anyone can nominate (nominating yourself is OK) * Nominees must accept their nomination before voting begins * Voting is opened from June 20th 00H00 UTC to July 03rd 23H59 UTC (there is a one day break between nominations and voting so the infra team has time to set up everything) * Only Gentoo developers that have joined the project before nomination starts may vote * Gentoo uses the Condorcet method of voting The page listing all nominations is here: http://www.gentoo.org/proj/en/elections/council/2010/council-201006-nominees.xml If you don't know what the Gentoo Council is, you can read about it here: http://www.gentoo.org/proj/en/council/ If you want to ask a question or share your thoughts, contact any of the election officials: Roy Bamford (neddyseagoon) Ulrich Müller (ulm) Torsten Veller (tove) Robin H. Johnson (robbat2) will be doing infra magic. You can send us an e-mail (elections at gentoo dot org) or find us on Freenode (#gentoo-elections, #gentoo-dev, so on). For the elections team, Torsten
[gentoo-dev] Re: [Gentoo Phoenix] an official Gentoo wiki
* Tobias Scherbaum dertobi...@gentoo.org: Accidentally I noticed an initial project meeting which was announced via planet.g.o - but I wasn't able to attend that meeting, as i noticed it just a day or two before. The meeting was also announced on the wiki alias. Five days before the meeting you should have got a mail. I think this is sufficient. -- Regards Torsten
[gentoo-dev] Re: Council 201006 elections
* Mike Frysinger vap...@gentoo.org: On Monday, May 31, 2010 22:46:50 Jorge Manuel B. S. Vicetto wrote: Here are the details for the Council 201006 elections: * nominations: June 5th to 18th * voting: June 20th to July 3rd funny, this isnt what the council page says at all | Nominations are allowed from July 1st UTC to July 31st 2359 UTC | Voting is opened from August 1st UTC to August 31st 2359 UTC | (from http://council.gentoo.org) The dates shifted because a former council didn't made its full term due to the 50% attendance clause. The 'one year' is then reset from that point. [0] The current council's term started in July 2009. So the next Council should start in July 2010. The length of the periods were shortened in 2008 [1] when we had the early election and last year's election was run within 2+2 weeks too. I think the council page should be fixed. Do you agree? [0] http://www.gentoo.org/proj/en/glep/glep-0039.html [1] http://mid.gmane.org/4845954c.6070...@gentoo.org -- Regards Torsten
[gentoo-dev] Links to compressed files (was: gentoo-x86 commit in app-misc/mmv: ChangeLog mmv-1.01b_p15.ebuild)
src_install() {
doman mmv.1 || die
dosym mmv.1.gz /usr/share/man/man1/mcp.1.gz || die
dosym mmv.1.gz /usr/share/man/man1/mln.1.gz || die
dosym mmv.1.gz /usr/share/man/man1/mad.1.gz || die
How does this work with various package managers?
Portage works fine with different PORTAGE_COMPRESS settings.
I guess paludis creates uncompressed man-pages and has three broken links?
And pkgcore?
Is there a reliable/predictable way to create such links?
[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
* Torsten Veller ml...@veller.net:
The perl-module.eclass must be updated to support EAPI=3 [1] and
a new eclass will be added which does contain some (more or less) useful
stand-alone functions split from the old perl-module.eclass without
exporting phase functions.
Somehow I was sleeping: It's more useful to set EXPORT_FUNCTIONS
conditionally and have all functions in perl-module.eclass.
I think this justifies the elimination of the perl-helper.eclass.
Sorry for the confusion. Hopefully wide awake now.
New perl-helper.eclass:
| # Copyright 1999-2010 Gentoo Foundation
| # Distributed under the terms of the GNU General Public License v2
| # $Header: $
|
| # @DEAD
|
| PERL_EXPORT_PHASE_FUNCTIONS=no
| inherit perl-module
Head of new perl-module.eclass:
http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=tree;f=eclass;hb=HEAD
| @@ -12,19 +12,19 @@
| # The perl-module eclass is designed to allow easier installation of perl
| # modules, and their incorporation into the Gentoo Linux system.
|
| -inherit perl-helper eutils base
| +inherit eutils base
| [[ ${CATEGORY} == perl-core ]] inherit alternatives
|
| PERL_EXPF=src_unpack src_compile src_test src_install
|
| case ${EAPI:-0} in
| 0|1)
| - PERL_EXPF=${PERL_EXPF} pkg_setup pkg_preinst pkg_postinst
pkg_prerm pkg_postrm
| + PERL_EXPF+= pkg_setup pkg_preinst pkg_postinst pkg_prerm
pkg_postrm
| ;;
| 2|3)
| - PERL_EXPF=${PERL_EXPF} src_prepare src_configure
| + PERL_EXPF+= src_prepare src_configure
| [[ ${CATEGORY} == perl-core ]] \
| - PERL_EXPF=${PERL_EXPF} pkg_postinst pkg_postrm
| + PERL_EXPF+= pkg_postinst pkg_postrm
|
| case ${GENTOO_DEPEND_ON_PERL:-yes} in
| yes)
| @@ -38,7 +38,17 @@ case ${EAPI:-0} in
| ;;
| esac
|
| -EXPORT_FUNCTIONS ${PERL_EXPF}
| +case ${PERL_EXPORT_PHASE_FUNCTIONS:-yes} in
| + yes)
| + EXPORT_FUNCTIONS ${PERL_EXPF}
| + ;;
| + no)
| + debug-print PERL_EXPORT_PHASE_FUNCTIONS=no
| + ;;
| + *)
| + DEPEND+= PERL_EXPORT_PHASE_FUNCTIONS-UNSUPPORTED
| + ;;
| +esac
|
| DESCRIPTION=Based on the $ECLASS eclass
...
[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
* James Cloos cl...@jhcloos.com: TV == Torsten Veller ml...@veller.net writes: TV There was a reason why the man-pages were removed: I think it was TV collisions protection and perl people use `perldoc` anyway. Perl people -- I'm one -- use man(1); given the differences in usefulness, I cannot imagine why anyone would prefer perldoc(1) over man(1). Please file a bug if you want man pages for all the modules. Thanks
[gentoo-dev] Re: [Gentoo Pheonix] Heartbeat team force
* Sebastian Pipping sp...@gentoo.org: i was refering to the members of the embedded herd. the rendered page lists dagger, kumba, pebenito, solar to be working for that herd. the link you gave does not contain the word dagger. how does it get in there? From herds.xml. Really.
[gentoo-dev] Re: [Gentoo Pheonix] Heartbeat team force
* Sebastian Pipping sp...@gentoo.org: - Package tree history (VCS logs, ..) - get real numbers on how much active manpower we have I am generating monthly stats for gentoo-x86 for a year or so: http://dev.gentoo.org/~tove/stats/gentoo-x86/ It lists the number of commits per month (cvs-log-20...) for all active devs. Monthly commits per dev over time (dev/commits-$dev...). cvs-log-sum.txt total number of commits per dev. slacker.txt combines the last two month and adds further information for devs without commits (date of last commit, date of last bugzilla interaction, dev bug information, away status). Since 2010 I also add cvs-log-all-.. which adds all not-retired devs with gentoo-x86 access. grep for Sum, Mean,...: http://dev.gentoo.org/~tove/files/activedevs.txt http://dev.gentoo.org/~tove/files/sum.txt http://dev.gentoo.org/~tove/files/mean.txt http://dev.gentoo.org/~tove/files/median.txt
[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
* Alec Warner anta...@gentoo.org: It is obvious what many of the functions do (I can read shell, yay!) but it is not obvious to me why they exist or why I would want to call them. Why do I want to delete AppleDouble files? What are dual-life scripts and why do I want to symlink them? Why would I want to delete packfiles? Some documentation would be nice h ere. Absolutely. The perl-team already has a bug for it (#259815). Perl eclass changes are tracked in bug #239510. But I don't think missing documentation is a stopper here. Most of it is copied from perl-modules.eclass. - AppleDouble (name reported by `file`) 268497 [p...@gentoo.org] - Remove ._* files in perl-module_src_prepare 273104 [dev-port...@gentoo.org] - New QA check: installed OSX fork files (if I got the name right) - dual-life scripts scripts installed by dual-life packages (part of dev-lang/perl and also stand-alone in perl-core/). Only relevant for perl-core/ packages. - .packlist something like CONTENTS. [---=| TOFU protection by t-prot: 143 lines snipped |=---]
[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
* James Cloos cl...@jhcloos.com: One change the perl eclasses require is elimination of the code which deletes the man pages. Deleting the man pages is /extremely/ rude and should not occur. There was a reason why the man-pages were removed: I think it was collisions protection and perl people use `perldoc` anyway. Do we need a patch to avoid collisions? Do you have it ready and tested?
[gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
The perl-module.eclass must be updated to support EAPI=3 [1] and
a new eclass will be added which does contain some (more or less) useful
stand-alone functions split from the old perl-module.eclass without
exporting phase functions.
Functions used in ebuilds that don't need the exported default phases
are perlinfo() and fixlocalpod().
Below is the new eclass, working title is perl-helper.eclass.
A diff between the the current and the new perl-module.eclass can be
found at [2]. Both are in use in the perl-experimental overlay [3].
Please review! If someone can come up with better names, either the
perl-helper.eclass or the functions named perl_*, please tell me.
I tried to make the perl-helper functions more unique but the
meaningfulness is open to question.
Thanks
[1] https://bugs.gentoo.org/310453
[2] http://dev.gentoo.org/~tove/files/perl-module.diff
[3]
http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=tree;f=eclass;hb=HEAD
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
[[ ${CATEGORY} == perl-core ]] inherit alternatives
perlinfo() {
debug-print-function $FUNCNAME $@
perl_set_version
}
perl_set_version() {
debug-print-function $FUNCNAME $@
debug-print $FUNCNAME: perlinfo_done=${perlinfo_done}
${perlinfo_done} return 0
perlinfo_done=true
local f version install{{site,vendor}{arch,lib},archlib}
eval $(perl -V:{version,install{{site,vendor}{arch,lib},archlib}} )
PERL_VERSION=${version}
SITE_ARCH=${installsitearch}
SITE_LIB=${installsitelib}
ARCH_LIB=${installarchlib}
VENDOR_LIB=${installvendorlib}
VENDOR_ARCH=${installvendorarch}
}
fixlocalpod() {
debug-print-function $FUNCNAME $@
perl_delete_localpod
}
perl_delete_localpod() {
debug-print-function $FUNCNAME $@
find ${D} -type f -name perllocal.pod -delete
find ${D} -depth -mindepth 1 -type d -empty -delete
}
perl_fix_osx_extra() {
debug-print-function $FUNCNAME $@
# Remove AppleDouble encoded Macintosh file
local f
find ${S} -type f -name ._* -print0 | while read -rd '' f ; do
einfo Removing AppleDouble encoded Macintosh file: ${f#${S}/}
rm -f ${f}
f=${f#${S}/}
# f=${f//\//\/}
# f=${f//\./\.}
# sed -i /${f}/d ${S}/MANIFEST || die
grep -q ${f} ${S}/MANIFEST \
elog AppleDouble encoded Macintosh file in MANIFEST:
${f#${S}/}
done
}
perl_delete_module_manpages() {
debug-print-function $FUNCNAME $@
perl_set_eprefix
if [[ -d ${ED}/usr/share/man ]] ; then
# einfo Cleaning out stray man files
find ${ED}/usr/share/man -type f -name *.3pm -delete
find ${ED}/usr/share/man -depth -type d -empty -delete
fi
}
perl_delete_packlist() {
debug-print-function $FUNCNAME $@
perl_set_version
if [[ -d ${D}/${VENDOR_LIB} ]] ; then
find ${D}/${VENDOR_LIB} -type f -a \( -name .packlist \
-o \( -name '*.bs' -a -empty \) \) -delete
find ${D}/${VENDOR_LIB} -depth -mindepth 1 -type d -empty
-delete
fi
}
perl_remove_temppath() {
debug-print-function $FUNCNAME $@
find ${D} -type f -not -name '*.so' -print0 | while read -rd '' f ; do
if file ${f} | grep -q -i text ; then
grep -q ${D} ${f} ewarn QA: File contains a
temporary path ${f}
sed -i -e s:${D}:/:g ${f}
fi
done
}
perl_link_duallife_scripts() {
debug-print-function $FUNCNAME $@
if [[ ${CATEGORY} != perl-core ]] || ! has_version
=dev-lang/perl-5.8.8-r8 ; then
return 0
fi
perl_set_eprefix
local i ff
if has ${EBUILD_PHASE:-none} postinst postrm ; then
for i in ${duallifescrip...@]} ; do
alternatives_auto_makesym /usr/bin/${i}
/usr/bin/${i}-[0-9]*
ff=`echo
${EROOT}/usr/share/man/man1/${i}-${PV}-${P}.1*`
ff=${ff##*.1}
alternatives_auto_makesym
/usr/share/man/man1/${i}.1${ff} /usr/share/man/man1/${i}-[0-9]*
done
else
pushd ${ED} /dev/null
for i in $(find usr/bin -maxdepth 1 -type f 2/dev/null) ; do
mv ${i}{,-${PV}-${P}} || die
DUALLIFESCRIPTS[${#DUALLIFESCRIPTS[*]}]=${i##*/}
if [[ -f usr/share/man/man1/${i##*/}.1 ]] ; then
mv
usr/share/man/man1/${i##*/}{.1,-${PV}-${P}.1} || die
fi
done
popd /dev/null
fi
}
perl_set_eprefix() {
[gentoo-dev] Re: Handling of keywording bugs with only one arch
* Petteri Räty betelge...@gentoo.org: So let's summarize for assigning to the single arch: In support (and my comments in support): - Can be used as a gentle reminder for slacker arches And if not only one arch or single arch is slacking? I guess you would find another gentle way to remind them. How about a tool generating mails to arch teams, which lists all STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month? (Or probably easier or possible at all: which weren't changed for 30 days.)
[gentoo-dev] Re: gentoo-x86 commit in media-gfx/graphicsmagick: ChangeLog graphicsmagick-1.3.12.ebuild
* Fabian Groffen (grobian) grob...@gentoo.org: grobian 10/03/21 09:24:54 Modified: ChangeLog graphicsmagick-1.3.12.ebuild Log: Add EPREFIX to configure arguments, bump to EAPI=3 (Portage version: 2.2.00.15838-prefix/cvs/Darwin powerpc) file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-gfx/graphicsmagick/graphicsmagick-1.3.12.ebuild?rev=1.2view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-gfx/graphicsmagick/graphicsmagick-1.3.12.ebuild?rev=1.2content-type=text/plain diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-gfx/graphicsmagick/graphicsmagick-1.3.12.ebuild?r1=1.1r2=1.2 -EAPI=2 +EAPI=3 inherit eutils toolchain-funcs flag-o-matic perl-module perl-module.eclass currently does not support EAPI=3.
[gentoo-dev] Re: Remove dev-status of mips profiles
* Ryan Hill dirtye...@gentoo.org: Torsten Veller ml...@veller.net wrote: * Torsten Veller t...@gentoo.org: Can we please move the mips profiles from dev to exp in profiles/profiles.desc? Based on the current feedback I'll change it not earlier than friday next week if nobody objects. Did you get feedback from anyone on m...@? No, I don't think so. Nonetheless mips was CC'ed on the last mail. I also got no reply to the keywording bugs waiting for mips. -- Thanks
[gentoo-dev] Re: eutils changes wrt EAPI-3 - ebeep and epause no longer available
* Jeremy Olexa darks...@gentoo.org:
Maciej Mrozowski wrote:
A as result of discussion http://www.mail-archive.com/gentoo-
d...@lists.gentoo.org/msg37300.html
ebeep and epause functions defined in eutils are not available in EAPI = 3.
For interactive installs, PROPERTIES=interactive should be used instead.
Maybe ebeep and epause should be defined in EAPI=3 but a qa warning
so things actually get fixed?
Something like this (not tested):
%% cvs di eutils.eclass
Index: eutils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
retrieving revision 1.330
diff -u -r1.330 eutils.eclass
If you'd update your tree you can see that something like this was
committed.
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/eutils.eclass?r1=1.330r2=1.332
--- eutils.eclass 15 Feb 2010 02:10:39 - 1.330
+++ eutils.eclass 17 Feb 2010 14:13:16 -
@@ -50,6 +50,15 @@
done
fi
}
+else
+ ebeep() {
+ eqawarn ebeep is not defined in EAPI=3, please file
The problem here is that eqawarn isn't defined in EAPI 3.
[gentoo-dev] Remove dev-status of mips profiles
Can we please move the mips profiles from dev to exp in profiles/profiles.desc? The ~150 mips development profiles increase the time for a `repoman -d full` run in dev-perl/ from three to five minutes. That is an increase of roughly 66 percent. repoman further prints more than 2000 lines of output for two keywording problems. I can't remember any serious mips keywording activity in the last years. I don't see why I should spend any more time on checking their profiles and filing bugs for an unactive team. Open KEYWORDREQ bugs: https://bugs.gentoo.org/buglist.cgi?quicksearch=kw%3AKEYWORDREQ+owner%2Ccc%3Amips%40gentoo.org
[gentoo-dev] Re: [RFC] Font eclass EAPI update and design
* Tomáš Chvátal scarab...@gentoo.org:
# @FUNCTION: font_pkg_setup
# @DESCRIPTION:
# The font pkg_setup function.
# Collision portection and Prefix compat for eapi 3.
font_pkg_setup() {
# make sure we get no collisions
# setup is not the nicest place, but preinst doesn't cut it
[[ -e ${FONTDIR}/fonts.cache-1 ]] rm -f ${FONTDIR}/fonts.cache-1
(E)ROOT is missing.
# Prefix compat
case ${EAPI:-0} in
0|1|2)
if ! use prefix; then
EPREFIX=
ED=${D}
EROOT=${ROOT}
[[ ${EROOT} = */ ]] || EROOT+=/
fi
;;
esac
Don't we need this for every eclass using EPREFIX, ED and EROOT
independent of EAPI?
Can't we move this to prefix.eclass and inherit it? Or is the EPREFIX
setting in prefix.eclass already enough?
[gentoo-dev] Re: Usage of vecho in the tree
* Torsten Veller ml...@veller.net:
./dev-scheme/bigloo/bigloo-3.2b_p2.ebuild: vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-scheme/elk/elk-3.99.7.ebuild: vecho Tests already run
during compile
./mail-mta/courier/courier-0.61.2.ebuild:vecho Test phase
[check]: ${CATEGORY}/${PF}
./mail-mta/courier/courier-0.59.0.ebuild:vecho Test phase
[check]: ${CATEGORY}/${PF}
./mail-mta/courier/courier-0.60.0.ebuild:vecho Test phase
[check]: ${CATEGORY}/${PF}
./mail-mta/courier/courier-0.61.1.ebuild:vecho Test phase
[check]: ${CATEGORY}/${PF}
./dev-libs/libmemcached/libmemcached-0.30.ebuild:vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-libs/libmemcached/libmemcached-0.30.ebuild:vecho Test phase
[none]: ${CATEGORY}/${PF}
./dev-libs/libmemcached/libmemcached-0.28.ebuild:vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-libs/libmemcached/libmemcached-0.28.ebuild:vecho Test phase
[none]: ${CATEGORY}/${PF}
./dev-lang/php/php-5.2.10.ebuild:vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-lang/php/php-5.2.9-r2.ebuild: vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-lang/php/php-5.2.10-r2.ebuild: vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-lang/php/php-5.2.12.ebuild:vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-lang/php/php-5.2.10-r1.ebuild: vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-lang/php/php-5.2.11-r1.ebuild: vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-lang/php/php-5.2.11.ebuild:vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-lang/mono/mono-2.4..ebuild:vecho Test phase
[check]: ${CATEGORY}/${PF}
./dev-lang/mono/mono-1.2.5.1-r1.ebuild: vecho Test phase
[check]: ${CATEGORY}/${PF}
./dev-lang/mono/mono-1.2.6-r3.ebuild:vecho Test phase
[check]: ${CATEGORY}/${PF}
./dev-lang/mono/mono-2.4.2.3.ebuild: vecho Test phase
[check]: ${CATEGORY}/${PF}
./dev-lang/mono/mono-2.0..ebuild:vecho Test phase
[check]: ${CATEGORY}/${PF}
./dev-lang/mono/mono-.ebuild:vecho Test phase
[check]: ${CATEGORY}/${PF}
./dev-lang/mono/mono-2.0.1-r1.ebuild:vecho Test phase
[check]: ${CATEGORY}/${PF}
./sys-devel/clang/clang-2.6-r1.ebuild: vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-python/pysvn/pysvn-1.7.0.ebuild: vecho Test phase
[test]: ${CATEGORY}/${PF}
./dev-python/pysvn/pysvn-1.7.0.ebuild: vecho Test phase
[none]: ${CATEGORY}/${PF}
I am going to change `vecho` to `echo` this weekend unless there are
objections.
--
Regards Torsten
[gentoo-dev] EAPI-3 times and dates
EAPI-3 was approved by the council during their last meeting (2010-01-18). Which portage versions do support it? (I wasn't able to find it in the docs.) When can we stabilize EAPI-3 ebuilds? (I guess this is again a council decision?) How long do we have to provide ebuilds for older EAPIs? (We can drop them as long as users are able to upgrade to an EAPI-3 capable package-manager for at least one year from now/after stabilisation?) Is this worth to be documented if it isn't?
[gentoo-dev] Usage of vecho in the tree
A number of ebuilds use vecho from portage.
But vecho is not defined in general. It's a portage internal command.
Do we want to fix the ebuilds? Add a repoman check so we don't have to clean
them regularly?
Or do we want to provide it via profiles/base/profile.bashrc like elog?
BTW: Do we want to remove the elog check from the profiles now?
./dev-scheme/bigloo/bigloo-3.2b_p2.ebuild: vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-scheme/elk/elk-3.99.7.ebuild: vecho Tests already run
during compile
./mail-mta/courier/courier-0.61.2.ebuild:vecho Test phase [check]:
${CATEGORY}/${PF}
./mail-mta/courier/courier-0.59.0.ebuild:vecho Test phase [check]:
${CATEGORY}/${PF}
./mail-mta/courier/courier-0.60.0.ebuild:vecho Test phase [check]:
${CATEGORY}/${PF}
./mail-mta/courier/courier-0.61.1.ebuild:vecho Test phase [check]:
${CATEGORY}/${PF}
./dev-libs/libmemcached/libmemcached-0.30.ebuild:vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-libs/libmemcached/libmemcached-0.30.ebuild:vecho Test phase [none]:
${CATEGORY}/${PF}
./dev-libs/libmemcached/libmemcached-0.28.ebuild:vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-libs/libmemcached/libmemcached-0.28.ebuild:vecho Test phase [none]:
${CATEGORY}/${PF}
./dev-lang/php/php-5.2.10.ebuild:vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-lang/php/php-5.2.9-r2.ebuild: vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-lang/php/php-5.2.10-r2.ebuild: vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-lang/php/php-5.2.12.ebuild:vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-lang/php/php-5.2.10-r1.ebuild: vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-lang/php/php-5.2.11-r1.ebuild: vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-lang/php/php-5.2.11.ebuild:vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-lang/mono/mono-2.4..ebuild:vecho Test phase [check]:
${CATEGORY}/${PF}
./dev-lang/mono/mono-1.2.5.1-r1.ebuild: vecho Test phase [check]:
${CATEGORY}/${PF}
./dev-lang/mono/mono-1.2.6-r3.ebuild:vecho Test phase [check]:
${CATEGORY}/${PF}
./dev-lang/mono/mono-2.4.2.3.ebuild: vecho Test phase [check]:
${CATEGORY}/${PF}
./dev-lang/mono/mono-2.0..ebuild:vecho Test phase [check]:
${CATEGORY}/${PF}
./dev-lang/mono/mono-.ebuild:vecho Test phase [check]:
${CATEGORY}/${PF}
./dev-lang/mono/mono-2.0.1-r1.ebuild:vecho Test phase [check]:
${CATEGORY}/${PF}
./sys-devel/clang/clang-2.6-r1.ebuild: vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-python/pysvn/pysvn-1.7.0.ebuild: vecho Test phase [test]:
${CATEGORY}/${PF}
./dev-python/pysvn/pysvn-1.7.0.ebuild: vecho Test phase [none]:
${CATEGORY}/${PF}
[gentoo-dev] Re: Usage of vecho in the tree
* Torsten Veller ml...@veller.net: Or do we want to provide it via profiles/base/profile.bashrc like elog? That wouldn't work as other package managers don't source profile.bashrc.
[gentoo-dev] Re: RFC: don't define ebeep and epause in eutils in EAPI 3
* Mike Frysinger vap...@gentoo.org: On Sunday 17 January 2010 16:12:29 David Leverton wrote: On Sunday 17 January 2010 20:38:48 Petteri Räty wrote: With GLEP 42 and proper logging of e* messages I think we shouldn't annoy users any more with ebeep or epause so attached is a patch only defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to keep these around for EAPI 3? If not I will apply the attached patch. The patch only defines these functions for EAPI=0 and EAPI=1. The eclass-manpages comments should be updated too. you mean you should re-emerge it on your system I think he means that the patch should modify @DESCRIPTION too.
[gentoo-dev] Re: Election for the Gentoo Council empty seat
* David Abbott dabb...@gentoo.org: I nominate (in no particular order): tove Thanks, but I decline. pgpnd8aNUxHU5.pgp Description: PGP signature
[gentoo-dev] Re: gentoo-x86 commit in perl-core/Compress-Raw-Zlib
* Jonathan Callen (abcd) a...@gentoo.org:
EAPI=2
IUSE=test
src_prepare() {
+ use prefix || EPREFIX=
Why is prefix not in IUSE?
IUSE lists the USE flags used by the ebuild.
Historically, USE_EXPAND values and ARCH were not included...
prefix is not an ARCH.
BTW: don't we bump EAPI to not add this `use prefix ||...` test?
[gentoo-dev] Implicit IUSE
* Jonathan Callen a...@gentoo.org:
Torsten Veller wrote:
Why is prefix not in IUSE?
IUSE lists the USE flags used by the ebuild.
Historically, USE_EXPAND values and ARCH were not included...
prefix is not an ARCH.
While prefix is not an ARCH or a in USE_EXPANDed variable, it is
included in the list of implicit USE flags, which do not need to be
included in IUSE.
I found the list of implicit USE flags:
def _get_implicit_iuse(self):
Some flags are considered to
be implicit members of IUSE:
* Flags derived from ARCH
* Flags derived from USE_EXPAND_HIDDEN variables
* Masked flags, such as those from {,package}use.mask
* Forced flags, such as those from {,package}use.force
* build and bootstrap flags used by bootstrap.sh
For 'prefix' we rely on the fact that it will either be in use.mask
or use.force.
So why do we still add 'selinux' to IUSE?
[gentoo-dev] Re: Individual developer signing
* Robin H. Johnson robb...@gentoo.org: BTW: About a third of the Manifests are signed [1]. We didn't improve [1] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/Manifest.png [2] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/ratio_2005.png [3] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/Manifest2.png Nice graphs. Can you show them over a larger timespan? Yes, I recreated them from cvs and the keys available now. [1] and [3] show the progress for the last year and [4] the history since May 2004. - In Jan 2008 the transition to Manifest2 was finished and all signatures were dropped. - I guess [2] didn't require-cross-certification while gnupg now defaults to require-cross-certification. So the number of valid signatures in [4] is lower than in [2]. After the Manifest2-break the level is lower. [4] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/Manifest-all.png
[gentoo-dev] Individual developer signing
* Robin H. Johnson robb...@gentoo.org: The GLEP on Individual developer signing has not made it into a Draft yet. But you can view the very brief version here: http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/02-developer-process-security?view=markup [...] 2. Every developer signs everything 100% of the time (make it a QA check). +1 on this. In the GLEPs i missed the point where the signatures of Manifests are verified. Only the MetaManifest gets verified. So what's the advantage of individually signed Manifests? The only thing we can check: Is the key used for signing listed in ldap (and thus in the keyring of automated Gentoo keys)? Are the keys in ldap really mine? Do I miss anything? BTW: About a third of the Manifests are signed [1]. We didn't improve since 2005/2006 [2]. The two parties are working hard against each other [3]. 55 Manifests are signed by revoked keys [4]. [1] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/Manifest.png [2] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/ratio_2005.png [3] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/Manifest2.png [4] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/signatures_by_revoked_keys.txt
[gentoo-dev] Re: gentoo-x86 commit in media-sound/squeezeboxserver: ChangeLog squeezeboxserver-7.4.1.ebuild metadata.xml
* Joe Peterson (lavajoe) lava...@gentoo.org:
1.1
media-sound/squeezeboxserver/squeezeboxserver-7.4.1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-sound/squeezeboxserver/squeezeboxserver-7.4.1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-sound/squeezeboxserver/squeezeboxserver-7.4.1.ebuild?rev=1.1content-type=text/plain
Index: squeezeboxserver-7.4.1.ebuild
===
RDEPEND=
=dev-perl/Class-XSAccessor-1.03
=dev-perl/Class-XSAccessor-Array-1.04
Class-XSAccessor-Array was merge in dev-perl/Class-XSAccessor-1.05 (#275520)
Please depend on =dev-perl/Class-XSAccessor-1.05 and drop -Array.
# Selected contents of SqueezeCenter's local CPAN collection that we include
# in the installation. This removes duplication of CPAN modules. (See Gentoo
# bug #251494).
Hm, I've added a bunch of these modules as requested in
https://bugs.gentoo.org/showdependencytree.cgi?id=251494
Why don't you use them now?
CPANKEEP=
Class/XSAccessor/Array.pm
JSON/XS/VersionOneAndTwo.pm
Class/Accessor/
Class/Accessor.pm
MRO/Compat.pm
Algorithm/C3.pm
Data/
DBIx/
File/BOM.pm
Net/UPnP/
Net/UPnP.pm
Proc/Background/
Proc/Background.pm
Text/Unidecode/
Text/Unidecode.pm
Tie/Cache/LRU/
Tie/Cache/LRU.pm
Tie/LLHash.pm
Tie/RegexpHash.pm
UUID/Tiny.pm
URI/Find.pm
PAR/
PAR.pm
enum.pm
LIBDIR=/usr/lib/squeezeboxserver
get_libdir ?
pkg_setup() {
# Sox has optional OGG and FLAC support, so make sure it has that
included
# if required
if use ogg; then
if ! built_with_use media-sound/sox ogg; then
eerror media-sound/sox not built with USE=ogg
die Squeezebox Server needs media-sound/sox to be
built with USE=ogg
fi
fi
if use flac; then
if ! built_with_use media-sound/sox flac; then
eerror media-sound/sox not built with USE=flac
die Squeezebox Server needs media-sound/sox to be
built with USE=flac
fi
fi
Use EAPI=2 and USE Dependencies
http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
src_install() {
# The main Perl executables
exeinto /usr/sbin
newexe slimserver.pl squeezeboxserver
newexe scanner.pl squeezeboxserver-scanner
newexe cleanup.pl squeezeboxserver-cleanup
|| die
# Get the Perl package name and version
eval `perl '-V:package'`
eval `perl '-V:version'`
# The custom OS module for Gentoo - provides OS-specific path details
cp ${FILESDIR}/gentoo-filepaths.pm Slim/Utils/OS/Custom.pm || die
Unable to install Gentoo custom OS module
# The server Perl modules
dodir /usr/lib/${package}/vendor_perl/${version}
cp -r Slim ${D}/usr/lib/${package}/vendor_perl/${version} || die
Unable to install server Perl modules
You can make use of:
perl -V:installvendorlib
# Compiled CPAN module go under lib as they are arch-specific
dodir /usr/lib/squeezeboxserver/CPAN
cp -r CPAN/arch ${D}/usr/lib/squeezeboxserver/CPAN || die Unable to
install compiled CPAN modules
# Preseve some of the Squeezebox Server-packaged CPAN modules that
Gentoo
# doesn't provide ebuilds for.
for ITEM in ${CPANKEEP}; do
dodir /usr/share/squeezeboxserver/CPAN/$(dirname ${ITEM})
cp -r CPAN/${ITEM}
${D}/usr/share/squeezeboxserver/CPAN/${ITEM} || die Unable to preserve
CPAN item ${ITEM}
done
For CPANKEEP, see above.
# Install preferences
insinto ${PREFSDIR}
if [ ! -f ${PREFSDIR}/squeezeboxserver.prefs ]; then
This test in src_test is wrong.
newins ${FILESDIR}/squeezeboxserver.prefs
squeezeboxserver.prefs
fi
fowners squeezeboxserver:squeezeboxserver ${PREFSDIR}
fperms 770 ${PREFSDIR}
pkg_postinst() {
# Album art requires PNG and JPEG support from GD, so if it's not there
# then warn the user. It's not mandatory as the user may not be using
# album art.
if ! built_with_use dev-perl/GD jpeg || \
! built_with_use dev-perl/GD png || \
! built_with_use media-libs/gd jpeg || \
! built_with_use media-libs/gd png; then
EAPI=2 and if ! has_version dev-perl/GD[jpeg] || \ ... is prefered.
Regards
[gentoo-dev] Re: QA: package.mask policies
Tomáš Chvátal scarab...@gentoo.org wrote: But if we look on tag of screen-4.0.3 or its release: screen-4.0.3.tar.gz07-Aug-2008 06:30 821K screen-4.0.3.tar.gz.sig07-Aug-2008 06:30 65 *screen-4.0.3 (25 Oct 2006) Part of the famous Software from the future series. Proudly presented by your Gentoo time travel agency.
[gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
* Sebastian Pipping webmas...@hartwork.org: What's next === What's the status of the stats project? What's missing? What help is needed? I'd really like to see a system that can answer: How often is cpv x installed on arch y (testing/stable flavour)?
[gentoo-dev] Re: perl-5.10.1 status update
* Torsten Vellert...@gentoo.org: After that I'll minimize my perl work if no more people join to help. Plan revised: I stop doing perl work right now. Thanks
[gentoo-dev] make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )
* Robin H. Johnson (robbat2) robb...@gentoo.org:
1.1 app-arch/hardlink/hardlink-0.1.1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1content-type=text/plain
src_install() {
emake DESTDIR=${D} install
^ || die
}
1.1 app-arch/duff/duff-0.4.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1content-type=text/plain
src_install() {
emake DESTDIR=${D} install
^ || die
dodoc AUTHORS ChangeLog HACKING NEWS README* TODO
}
An imprecise search (/make .*install$/) revealed another 200 packages:
http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt
Let it die before replacing a working package with a broken one.
Thanks
[gentoo-dev] Re: gentoo-x86 commit in net-mail/getmail: ChangeLog getmail-4.9.2.ebuild
* Fabian Groffen (grobian) grob...@gentoo.org:
grobian 09/10/11 15:04:33
Modified: ChangeLog getmail-4.9.2.ebuild
Log:
Use ED for Prefix compatability, marked ~ppc-macos and ~x64-solaris
(Portage version: 2.2.00.14552-prefix/cvs/Darwin powerpc, RepoMan options:
--force)
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild?rev=1.2view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild?rev=1.2content-type=text/plain
diff :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild?r1=1.1r2=1.2
Index: getmail-4.9.2.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- getmail-4.9.2.ebuild 23 Jul 2009 19:27:29 - 1.1
+++ getmail-4.9.2.ebuild 11 Oct 2009 15:04:33 - 1.2
@@ -1,6 +1,6 @@
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild,v
1.1 2009/07/23 19:27:29 tove Exp $
+# $Header: /var/cvsroot/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild,v
1.2 2009/10/11 15:04:33 grobian Exp $
inherit distutils
@@ -10,7 +10,7 @@
LICENSE=GPL-2
SLOT=4
-KEYWORDS=~alpha ~amd64 ~ppc ~sparc ~x86
+KEYWORDS=~alpha ~amd64 ~ppc ~sparc ~x86 ~ppc-macos ~x64-solaris
IUSE=
DEPEND==dev-lang/python-2.3.3
@@ -19,14 +19,15 @@
PYTHON_MODNAME=getmailcore
src_install() {
+ [[ -z ${ED} ]] local ED=${D}
distutils_src_install
# handle docs the gentoo way
- rm ${D}/usr/share/doc/${P}/COPYING || die
+ rm ${ED}/usr/share/doc/${P}/COPYING || die
if [[ ${P} != ${PF} ]] ; then
- mv ${D}/usr/share/doc/${P} ${D}/usr/share/doc/${PF} || die
+ mv ${ED}/usr/share/doc/${P} ${ED}/usr/share/doc/${PF} || die
fi
dodir /usr/share/doc/${PF}/html
- mv ${D}/usr/share/doc/${PF}/*.{html,css}
${D}/usr/share/doc/${PF}/html || die
+ mv ${ED}/usr/share/doc/${PF}/*.{html,css}
${ED}/usr/share/doc/${PF}/html || die
}
Can you please explain these changes? What is ED? Why does it need
changes in the ebuild at all?
Where is the documentation?
[gentoo-dev] Re: perl-module.class review
* Ciaran McCreesh ciaran.mccre...@googlemail.com:
Torsten Veller t...@gentoo.org wrote:
+EXPORTED_FUNCTIONS=src_unpack src_compile src_test src_install
You're probably not the only one using this trick, so it might be wise
to use PERL_EXPORTED_FUNCTIONS or somesuch to avoid name collisions
with other eclasses.
git and x-modular use EXPORTED_FUNCTIONS and
cmake and xfconf use EXPF.
| eclass/git.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
| eclass/x-modular.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
|
| eclass/cmake-utils.eclass:EXPORT_FUNCTIONS ${EXPF}
| eclass/xfconf.eclass:EXPORT_FUNCTIONS ${EXPF}
I'll use PERL_EXPORTED_FUNCTIONS in the perl eclass.
Thanks :)
[gentoo-dev] Re: perl-module.class review
* Tomáš Chvátal scarab...@gentoo.org:
I think it is not required
EXPF=src_compile src_test src_install - definition, also nulls anything
what was in it before :]
case ${EAPI:-0} in
2) EXPF=${EXPF} src_configure ;;
1|0) ;;
*) die Unknown EAPI, Bug eclass maintainers. ;;
esac
EXPORT_FUNCTIONS ${EXPF} - export
And later in cmake-utils_src_compile you use:
| has src_configure ${EXPF} || cmake-utils_src_configure
What will happen if an EAPI=2 ebuild inherits cmake-utils and another eclass
also using EXPF that does not EXPORT_FUNCTIONS src_configure and the
ebuild uses cmake-utils_src_compile?
It will call cmake-utils_src_configure during src_configure and later in
cmake-utils_src_compile it will run cmake-utils_src_configure again,
won't it?
[gentoo-dev] Re: perl-module.class review
* Tomáš Chvátal scarab...@gentoo.org:
Dne pondělí 21 Září 2009 18:03:56 Torsten Veller napsal(a):
* Tomáš Chvátal scarab...@gentoo.org:
I think it is not required
EXPF=src_compile src_test src_install - definition, also nulls
anything what was in it before :]
case ${EAPI:-0} in
2) EXPF=${EXPF} src_configure ;;
1|0) ;;
*) die Unknown EAPI, Bug eclass maintainers. ;;
esac
EXPORT_FUNCTIONS ${EXPF} - export
And later in cmake-utils_src_compile you use:
| has src_configure ${EXPF} || cmake-utils_src_configure
What will happen if an EAPI=2 ebuild inherits cmake-utils and another
eclass also using EXPF that does not EXPORT_FUNCTIONS src_configure and
the ebuild uses cmake-utils_src_compile?
It will call cmake-utils_src_configure during src_configure and later in
cmake-utils_src_compile it will run cmake-utils_src_configure again,
won't it?
You dont do this magic before inherits, so you are safe, if you inherit in
middle of your eclass code, then you probably deserve the breakage for
writting such horrible thing ;]
I'am trying to give an example:
,- test.eclass
EXPF=pkg_postinst
EXPORT_FUNCTIONS ${EXPF}
test_pkg_postinst() {
einfo test_pkg_postinst
}
'- test.eclass
,- another_test.eclass
EXPF=src_configure src_compile
EXPORT_FUNCTIONS ${EXPF}
another_test_src_configure() {
einfo another_test_src_configure
}
another_test_src_compile() {
einfo another_test_src_compile
has src_configure ${EXPF} || another_test_src_configure
}
'- another_test.eclass
,- test.ebuild
EAPI=2
inherit another_test test
DESCRIPTION=
HOMEPAGE=
SRC_URI=
LICENSE=
SLOT=0
KEYWORDS=~amd64
IUSE=
'- test.ebuild
It outputs:
* another_test_src_configure
* another_test_src_compile
* another_test_src_configure
* test_pkg_postinst
if s/EXPF/TEST_EXPF/ in test.eclass, it does:
* another_test_src_configure
* another_test_src_compile
* test_pkg_postinst
[gentoo-dev] Re: perl-module.class review
* Maciej Mrozowski reave...@poczta.fm:
How about unsetting variables after use in first place so that they no longer
pollute global env.
It's probably too late as it is used in functions like
cmake-utils_src_compile:
| has src_configure ${EXPF} || cmake-utils_src_configure
[gentoo-dev] perl-module.class review
Attached is a diff of the current and the prospective perl-module.class.
Please review.
Thanks.
--- perl-module.eclass
+++ perl-module.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2004 Gentoo Foundation
+# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/perl-module.eclass,v 1.116
2009/03/29 17:32:31 tove Exp $
#
@@ -13,13 +13,18 @@
# modules, and their incorporation into the Gentoo Linux system.
inherit eutils base
+[[ ${CATEGORY} == perl-core ]] inherit alternatives
+
+EXPORTED_FUNCTIONS=src_unpack src_compile src_test src_install
case ${EAPI:-0} in
0|1)
- EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm
pkg_postrm src_compile src_install src_test src_unpack
+ EXPORTED_FUNCTIONS=${EXPORTED_FUNCTIONS} pkg_setup pkg_preinst
pkg_postinst pkg_prerm pkg_postrm
;;
2)
- EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_test src_install
+ EXPORTED_FUNCTIONS=${EXPORTED_FUNCTIONS} src_prepare
src_configure
+ [[ ${CATEGORY} == perl-core ]] \
+ EXPORTED_FUNCTIONS=${EXPORTED_FUNCTIONS} pkg_postinst
pkg_postrm
case ${GENTOO_DEPEND_ON_PERL:-yes} in
yes)
@@ -30,6 +35,8 @@
;;
esac
+EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
+
DESCRIPTION=Based on the $ECLASS eclass
LICENSE=${LICENSE:-|| ( Artistic GPL-2 )}
@@ -56,7 +63,7 @@
perl-module_src_unpack() {
base_src_unpack unpack
- has ${EAPI:-0} 0 1 perl-module_src_prepare
+ has src_prepare ${EXPORTED_FUNCTIONS} || perl-module_src_prepare
}
perl-module_src_prepare() {
@@ -110,7 +117,7 @@
perl-module_src_compile() {
${perlinfo_done} || perlinfo
- has ${EAPI:-0} 0 1 perl-module_src_prep
+ has src_configure ${EXPORTED_FUNCTIONS} || perl-module_src_prep
if [[ -f Build ]] ; then
./Build build \
@@ -124,13 +131,38 @@
fi
}
+# For testers:
+# This code attempts to work out your threadingness from MAKEOPTS
+# and apply them to Test::Harness.
+#
+# If you want more verbose testing, set TEST_VERBOSE=1
+# in your bashrc | /etc/make.conf | ENV
+#
+# For ebuild writers:
+# If you wish to enable default tests w/ 'make test' ,
+#
+# SRC_TEST=do
+#
+# If you wish to have threads run in parallel ( using the users makeopts )
+# all of the following have been tested to work.
+#
+# SRC_TEST=do parallel
+# SRC_TEST=parallel
+# SRC_TEST=parallel do
+# SRC_TEST=parallel
+#
+
perl-module_src_test() {
- if [[ ${SRC_TEST} == do ]] ; then
+ if has 'do' ${SRC_TEST} || has 'parallel' ${SRC_TEST} ; then
+ if has ${TEST_VERBOSE:-0} 0 has 'parallel' ${SRC_TEST} ;
then
+ export HARNESS_OPTIONS=j$(echo -j1 ${MAKEOPTS} | sed -r
s/.*(-j\s*|--jobs=)([0-9]+).*/\2/ )
+ einfo Test::Harness Jobs=${HARNESS_OPTIONS}
+ fi
${perlinfo_done} || perlinfo
if [[ -f Build ]] ; then
- ./Build test || die test failed
+ ./Build test verbose=${TEST_VERBOSE:-0} || die test
failed
elif [[ -f Makefile ]] ; then
- emake test || die test failed
+ emake test TEST_VERBOSE=${TEST_VERBOSE:-0} || die test
failed
fi
fi
}
@@ -162,7 +194,7 @@
fixlocalpod
- for f in Change* CHANGES README* ${mydoc}; do
+ for f in Change* CHANGES README* TODO ${mydoc}; do
[[ -s ${f} ]] dodoc ${f}
done
@@ -174,10 +206,12 @@
find ${D} -type f -not -name '*.so' -print0 | while read -rd '' f ; do
if file ${f} | grep -q -i text ; then
-if grep -q ${D} ${f} ; then ewarn QA: File contains a temporary path
${f} ;fi
+ grep -q ${D} ${f} ewarn QA: File contains a
temporary path ${f}
sed -i -e s:${D}:/:g ${f}
fi
done
+
+ linkduallifescripts
}
perl-module_pkg_setup() {
@@ -188,20 +222,21 @@
${perlinfo_done} || perlinfo
}
-perl-module_pkg_postinst() { : ; }
-# einfo Man pages are not installed for most modules now.
-# einfo Please use perldoc instead.
-#}
+perl-module_pkg_postinst() {
+ linkduallifescripts
+}
-perl-module_pkg_prerm() { : ; }
+perl-module_pkg_postrm() {
+ linkduallifescripts
+}
-perl-module_pkg_postrm() { : ; }
+perl-module_pkg_prerm() { : ; }
perlinfo() {
perlinfo_done=true
- local f version install{site{arch,lib},archlib,vendor{arch,lib}}
- for f in version install{site{arch,lib},archlib,vendor{arch,lib}} ; do
+ local f version install{{site,vendor}{arch,lib},archlib}
+ for f in version install{{site,vendor}{arch,lib},archlib} ; do
[gentoo-dev] perl-5.10.1 status update
Many want it - very few help. That's perl-5.10 in Gentoo. I am trying to outline the changes in the perl-experimental overlay. And if there are no objections / better ideas, that will go into the tree. After that I'll minimize my perl work if no more people join to help. So these are the changes: - sys-devel/libperl is obsolete The shared libperl.so will be installed by dev-lang/perl and perl will link it. No libperl.a will be installed. - The PDEPEND modules will be removed... As some dual-life modules (the packages in perl-core/ are also installed by perl) install scripts which would collide, currently the scripts are removed from dev-lang/perl and the package is added to PDEPEND. In 5.8.8 we have two such PDEPENDS, with 5.10 it might be ten. The problem today is, we are not able to add perl-core/Encode (#235904) without bumping dev-lang/perl. - ...and the colliding scripts will be symlinked by alternatives.eclass - perl modules must be reinstalled if any of the useflags 'ithreads' or 'debug' are changed. perl-cleaner-2 should do this correctly. For minor version bumps of perl, the script probably needs further tweaking to minimize the number of reinstalled packages. That's what i remember. http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git
[gentoo-dev] Major problems in the tree in the last month
* Andrew D Kirch trel...@trelane.net: This should really be a non-issue. I just spent 2 days dealing with being 3.5 weeks out of date. To help us improve the user experience, what were the problems that cost you two days?
[gentoo-dev] Re: perl-5.10 inclusion
* Lars Wendler polynomia...@gentoo.org: perl-5.10 is out since end of 2007 [1] and we still don't have it in our main This is the problem. To add 5.10.0 now you have to review 1.5 years of patches. http://git.debian.org/?p=perl/perl.git;a=heads http://cvs.fedoraproject.org/viewvc/devel/perl/ ... I am sure there is at least one security related patch missing in the perl-experimental package. OTOH: 5.10.1 is expected soon. A first release candidate was scheduled for this weekend. Well, once the ...plan was to have 5.10.1 out by the end of the year That was last year and the point where i stopped spending time on packaging 5.10.0. Looking back after 9 month, this was probably not the best decision. I don't expect to find many problems within other packages. What needs to be done: - Find maintainers. - Fix our patchset: http://git.overlays.gentoo.org/gitweb/?p=proj/perl5-packaging.git;a=summary - Fix perl-cleaner and test the upgrade path: http://github.com/tove/perl-cleaner/tree
[gentoo-dev] Re: Manifesto archive
* Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org: Please archive the manifestos somewhere under the project space like it was done the last years. Yes, that is another thing I was planning to do. The only reason I haven't done it yet, is that older manifestos were stored as txt files and this year the candidates mostly opted for html/xml files. I'll probably just go ahead, ignore the looks and copy their manifestos to txt files. If any of the nominees would be kind enough to do it for us and send us the file, it would be greatly appreciated. I converted the files from html to rst (except for calchan and dertobi123). gentoofan23's manifesto is taken from cache. They are now in proj/en/elections/council/2009/manifesto/ [1]. I did not update the links in the list of nominees [2]. Please verify your manifesto and/or replace it with your original version. 1 http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/elections/council/2009/manifesto/ 2 http://www.gentoo.org/proj/en/elections/council/2009/council-200906-nominees.xml Have fun.
[gentoo-dev] Manifesto archive
* Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org: http://www.gentoo.org/proj/en/elections/council/2009/council-200906-nominees.xml Please archive the manifestos somewhere under the project space like it was done the last years. Looking back at the 2005 list of nominees, all external links are dead. Only the archived parts are still available. I can help if needed. Thanks
[gentoo-dev] Re: Gentoo Council Elections Results for term 2009/2010
* Roy Bamford neddyseag...@gentoo.org: The full ranked list of candidates, in order, is:- solar betelgeuse calchan dertobi123 ulm leio lu_zero patrick dev-zero ssuominen scarabeus gentoofan23 peper _reopen_nominations Can you please publish the full ranking output?
[gentoo-dev] Exim and Sendmail need a maintainer
The net-mail team is looking for maintainers for | mail-mta/sendmail | mail-mta/exim. If you are a dev, just start maintaining them. For users wanting to help, send a mail to net-m...@g.o Beside these two MTAs there is a number of packages in the net-mail herd that could benefit from a active maintainer too. If you want to help us or take over a package from the net-mail herd, don't hesitate to contact us. Thanks
[gentoo-dev] Re: Gentoo Council 2009/2010 - Nominations are now open
* Patrick Lauer patr...@gentoo.org: People I nominate: * tove, because he has done an awesome job keeping perl alive and has shown consistent sane opinions in technical discussions Thanks, but I have to decline. pgpCDmFKgCMJ9.pgp Description: PGP signature
[gentoo-dev] Last rites: net-mail/gotmail
# Torsten Veller t...@gentoo.org (15 Apr 2009) # Mask net-mail/gotmail for removal (#266204) net-mail/gotmail Use pop3 instead. pgpULRM4EMbKq.pgp Description: PGP signature
[gentoo-dev] Re: Last rites: dev-lang/pugs
* Marijn Schouten (hkBst) hk...@gentoo.org: Torsten Veller wrote: # Masked for removal (#151986,#171649,#239222) (23 Mar 2009) # 151986 - dev-lang/pugs-6.2.13 installs stuff in /lib instead of /usr/lib # 171649 - dev-lang/pugs-6.2.13 fails to build with ghc-6.6 # 239222 - Remove dependencies in pugs on dev-lang/ghc-bin dev-lang/pugs I don't see how any of the above is fatal. Can you explain a bit better why you want to remove this? Isn't pugs still the most complete implementation of Perl6? It fails to build. No release in the last years. Do you want to maintain it? http://search.cpan.org/dist/Perl6-Pugs/ http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=Perl6-Pugs+6.2.13 http://www.cpantesters.org/show/Perl6-Pugs.html#Perl6-Pugs-6.2.13
[gentoo-dev] Re: perl-module.eclass -- review - 3
* Robin H. Johnson robb...@gentoo.org:
On Mon, Mar 02, 2009 at 09:51:07AM -0800, Donnie Berkholz wrote:
conditional variable (GENTOO_PERL=no?) that defaults to yes.
Yes, this would be needed in any case, similar to how it's done for
stuff that had optional X dependencies.
Next version. I want to commit it tomorrow.
For EAPI=2 it checks GENTOO_DEPEND_ON_PERL and depends on
dev-lang/perl[-build] unless GENTOO_DEPEND_ON_PERL is set and not yes.
Thanks
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/perl-module.eclass,v 1.112 2008/09/30
08:28:44 robbat2 Exp $
#
# Author: Seemant Kulleen seem...@gentoo.org
# @ECLASS: perl-module.eclass
# @MAINTAINER:
# p...@gentoo.org
# @BLURB: eclass for perl modules
# @DESCRIPTION:
# The perl-module eclass is designed to allow easier installation of perl
# modules, and their incorporation into the Gentoo Linux system.
inherit eutils base
case ${EAPI:-0} in
0|1)
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm
pkg_postrm src_compile src_install src_test src_unpack
;;
2)
EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_test src_install
case ${GENTOO_DEPEND_ON_PERL:-yes} in
yes)
DEPEND=dev-lang/perl[-build]
RDEPEND=${DEPEND}
;;
esac
;;
esac
DESCRIPTION=Based on the $ECLASS eclass
LICENSE=${LICENSE:-|| ( Artistic GPL-2 )}
[[ -z ${SRC_URI} -z ${MODULE_A} ]] MODULE_A=${MY_P:-${P}}.tar.gz
[[ -z ${SRC_URI} -n ${MODULE_AUTHOR} ]] \
SRC_URI=mirror://cpan/authors/id/${MODULE_AUTHOR:0:1}/${MODULE_AUTHOR:0:2}/${MODULE_AUTHOR}/${MODULE_SECTION}/${MODULE_A}
[[ -z ${HOMEPAGE} ]] \
HOMEPAGE=http://search.cpan.org/dist/${MY_PN:-${PN}};
SRC_PREP=no
SRC_TEST=skip
PREFER_BUILDPL=yes
PERL_VERSION=
SITE_ARCH=
SITE_LIB=
ARCH_LIB=
VENDOR_ARCH=
VENDOR_LIB=
pm_echovar=
perlinfo_done=false
perl-module_src_unpack() {
base_src_unpack unpack
has ${EAPI:-0} 0 1 perl-module_src_prepare
}
perl-module_src_prepare() {
if [[ -n ${PATCHES} ]] ; then
base_src_unpack autopatch
fi
esvn_clean
}
perl-module_src_configure() {
perl-module_src_prep
}
perl-module_src_prep() {
[[ ${SRC_PREP} = yes ]] return 0
SRC_PREP=yes
${perlinfo_done} || perlinfo
export PERL_MM_USE_DEFAULT=1
# Disable ExtUtils::AutoInstall from prompting
export PERL_EXTUTILS_AUTOINSTALL=--skipdeps
if [[ ${PREFER_BUILDPL} == yes -f Build.PL ]] ; then
einfo Using Module::Build
perl Build.PL \
--installdirs=vendor \
--libdoc= \
--destdir=${D} \
--create_packlist=0 \
--extra_linker_flags=${LDFLAGS} \
${myconf} \
${pm_echovar} \
|| die Unable to build! (are you using
USE=\build\?)
elif [[ -f Makefile.PL ]] ; then
einfo Using ExtUtils::MakeMaker
perl Makefile.PL \
PREFIX=/usr \
INSTALLDIRS=vendor \
INSTALLMAN3DIR='none' \
DESTDIR=${D} \
${myconf} \
${pm_echovar} \
|| die Unable to build! (are you using
USE=\build\?)
fi
if [[ ! -f Build.PL ! -f Makefile.PL ]] ; then
einfo No Make or Build file detected...
return
fi
}
perl-module_src_compile() {
${perlinfo_done} || perlinfo
has ${EAPI:-0} 0 1 perl-module_src_prep
if [[ -f Build ]] ; then
./Build build \
|| die compilation failed
elif [[ -f Makefile ]] ; then
emake \
OTHERLDFLAGS=${LDFLAGS} \
${mymake} \
|| die compilation failed
# OPTIMIZE=${CFLAGS} \
fi
}
perl-module_src_test() {
if [[ ${SRC_TEST} == do ]] ; then
${perlinfo_done} || perlinfo
if [[ -f Build ]] ; then
./Build test || die test failed
elif [[ -f Makefile ]] ; then
emake test || die test failed
fi
fi
}
perl-module_src_install() {
local f
${perlinfo_done} || perlinfo
[[ -z ${mytargets} ]] mytargets=pure_install
if [[ -f Build ]] ; then
./Build ${mytargets} \
|| die ./Build ${mytargets} failed
elif [[ -f Makefile
[gentoo-dev] perl-app.eclass -- review
Not much to say about it: It's a useless eclass anyway.
Now it has EAPI=2 support too.
The new eclass and
a diff of the relevant parts of current perl-module.eclass and perl-apps.eclass
are attached.
I want to commit it soon too.
Thanks
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/perl-app.eclass,v 1.10 2006/12/09
14:34:01 mcummings Exp $
# Author: Michael Cummings mcummi...@gentoo.org
# Maintained by the Perl herd p...@gentoo.org
inherit perl-module
case ${EAPI:-0} in
0|1) EXPORT_FUNCTIONS src_compile ;;
2) EXPORT_FUNCTIONS src_configure src_compile ;;
esac
perl-app_src_prep() {
perl-app_src_configure
}
perl-app_src_configure() {
perl-module_src_configure
}
perl-app_src_compile() {
has ${EAPI:-0} 0 1 perl-app_src_prep
perl-module_src_compile
}
--- perl-module.eclass.orig_minimal 2009-03-05 15:39:47.0 +0100
+++ perl-app.eclass.orig_minimal2009-03-05 15:40:13.0 +0100
@@ -1,9 +1,13 @@
-inherit base
+# The perl-app eclass is designed to allow easier installation of perl
+# apps, ineheriting the full structure of the perl-module eclass but allowing
+# man3 pages to be built. This is to work around a collision-protect bug in the
+# default perl-module eclass
-EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm pkg_postrm
src_compile src_install src_test src_unpack
+inherit perl-module
-perl-module_src_prep() {
+EXPORT_FUNCTIONS src_compile
+perl-app_src_prep() {
perlinfo
export PERL_MM_USE_DEFAULT=1
@@ -12,10 +16,10 @@
SRC_PREP=yes
- find ${S} -type d -name \.svn -exec /bin/rm -rf {} \; 2/dev/null
+ pwd
if [ ${PREFER_BUILDPL} == yes ] ( [ -f Build.PL ] || [ ${PN} ==
module-build ] ); then
einfo Using Module::Build
- echo $pm_echovar | perl Build.PL ${myconf}
--installdirs=vendor --destdir=${D} --libdoc= || die Unable to build! (are you
using USE=\build\?)
+ echo $pm_echovar | perl Build.PL --installdirs=vendor
--destdir=${D} --libdoc= || die Unable to build! (are you using
USE=\build\?)
elif [ -f Makefile.PL ] [ ! ${PN} == module-build ]; then
einfo Using ExtUtils::MakeMaker
echo $pm_echovar | perl Makefile.PL ${myconf}
INSTALLMAN3DIR='none'\
@@ -27,10 +31,10 @@
fi
}
-perl-module_src_compile() {
+perl-app_src_compile() {
perlinfo
- [ ${SRC_PREP} != yes ] perl-module_src_prep
+ [ ${SRC_PREP} != yes ] perl-app_src_prep
if [ -f Makefile ]; then
make ${mymake} || die compilation failed
elif [ -f Build ]; then
[gentoo-dev] Re: perl-module.eclass -- review
* Robin H. Johnson robb...@gentoo.org: On Fri, Feb 27, 2009 at 03:08:52PM +0100, Torsten Veller wrote: Please review the attached perl-module.eclass. Patch linked below. Are you going to include the changes from Bug 254980 so that s390 can build their stages properly? Specifically, going to EAPI2 and adding DEPEND=dev-lang/perl[!build] to the eclass. Currently the eclass doesn't set any dependencies. If it is used the ebuild has to depend on perl if needed. I see the following options: 1) Don't add DEPEND to the eclass. So if a package is used for stage-building we have to raise EAPI and depend on dev-lang/perl[-build] in the ebuild. The part I don't understand in the bug above is: Does adding dev-lang/perl[-build] automagically reinstall perl during stage-building (here portage stops and complains). 2) Add DEPEND conditionally to the eclass. To give ebuilds the chance to inherit perl-module.eclass (and currently also perl-app.eclass) and support perl conditionally, we have to add another global variable to check it. (Checking CATEGORY and perl? probably could be added additonally) 3) Add DEPEND. Always depend on dev-lang/perl and if EAPI=2 then depend on dev-lang/perl[-build] Comments?
[gentoo-dev] Re: perl-module.eclass -- review - 2
* Donnie Berkholz dberkh...@gentoo.org:
Thanks for your comments.
On 12:28 Sat 28 Feb , Torsten Veller wrote:
case ${EAPI:-0} in
0|1)
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm
pkg_postrm src_compile src_install src_test src_unpack
;;
*)
EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_test src_install
;;
esac
Maybe this is just me, but I prefer to reserve '*' cases for the
fallback when I don't understand what I'm given.
As this is a general problem we should move it out of this thread.
I also think this should have been discussed months ago.
find ${D}/${VENDOR_LIB} -type f -a \( -name .packlist \
-o \( -name '*.bs' -a -empty \) \) -delete
find ${D}/${VENDOR_LIB} -depth -mindepth 1 -type d -empty -delete
I'm curious how portable the find () construct is. Do you know?
http://www.opengroup.org/onlinepubs/95399/utilities/find.html
The brackets are no problem.
But -mindepth and -delete are not in the specs:
| The -mindepth and -maxdepth options are GNU extensions that should be
| avoided if possible. (from devmanual.g.o)
Well, even the portage ebuild uses -mindepth. So should I replace it?
| The `-delete' action was introduced by the BSD family of operating
| systems (from `info find`)
and is also used several times in the tree.
find ${D} -type f -not -name '*.so' | while read f ; do
if file ${f} | grep -q -i text ; then
if grep -q ${D} ${f} ; then ewarn QA: File contains a temporary path
${f} ; fi
sed -i -e s:${D}:/:g ${f} || die
Could you just use dosed here?
I guess you mean the default expression?
dosed defaults to s:${D}::g
$D is supposed to end with a trailing slash.
- is the path still absolute?
Strange at least.
BTW: After I looked up the devmanual part about find above, I wonder:
| find ${S} -type f | while read f ; do
| [...]
| for f in $(find ${S} -type f) ; do
| [...]
| Warning
| In both cases, files with weird characters or spaces in their names may
| cause serious problems.
Is there still a problem in the snippet above and is the following better
(if we assume that packages contain files with sane names)?
pushd ${D} /dev/null
for f in $(find . -type f -not -name '*.so' ) ; do
if file ${f} | grep -q -i text ; then
sed -i -e s:${D}:/:g ${f} || die
fi
done
popd /dev/null
Maybe i need some coffee.
[gentoo-dev] Re: perl-module.eclass -- review - 2
* Torsten Veller ml...@veller.net:
Please review the attached perl-module.eclass.
Patch linked below.
Thanks Bo Ørsted Andresen for feedback
Changes
~~~
- use emake
- more quoting
- call perlinfo only once
As I've not seen any ebuild doing the replacement in line 156,
I've added a temporary ewarn. If you hits you, tell me.
git://github.com/tove/perl-eclass.git
http://people.gentoo.org/tove/files/perl-module.eclass.diff
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/perl-module.eclass,v 1.112 2008/09/30
08:28:44 robbat2 Exp $
#
# Author: Seemant Kulleen seem...@gentoo.org
# @ECLASS: perl-module.eclass
# @MAINTAINER:
# p...@gentoo.org
# @BLURB: eclass for perl modules
# @DESCRIPTION:
# The perl-module eclass is designed to allow easier installation of perl
# modules, and their incorporation into the Gentoo Linux system.
inherit eutils base
case ${EAPI:-0} in
0|1)
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm
pkg_postrm src_compile src_install src_test src_unpack
;;
*)
EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_test src_install
;;
esac
DESCRIPTION=Based on the $ECLASS eclass
LICENSE=${LICENSE:-|| ( Artistic GPL-2 )}
[ -z ${SRC_URI} -a -z ${MODULE_A} ] MODULE_A=${MY_P:-${P}}.tar.gz
[ -z ${SRC_URI} -a -n ${MODULE_AUTHOR} ] \
SRC_URI=mirror://cpan/authors/id/${MODULE_AUTHOR:0:1}/${MODULE_AUTHOR:0:2}/${MODULE_AUTHOR}/${MODULE_SECTION}/${MODULE_A}
[ -z ${HOMEPAGE} ] \
HOMEPAGE=http://search.cpan.org/dist/${MY_PN:-${PN}};
SRC_PREP=no
SRC_TEST=skip
PREFER_BUILDPL=yes
PERL_VERSION=
SITE_ARCH=
SITE_LIB=
VENDOR_LIB=
VENDOR_ARCH=
ARCH_LIB=
pm_echovar=
perlinfo_done=false
perl-module_src_unpack() {
base_src_unpack unpack
has ${EAPI:-0} 0 1 perl-module_src_prepare
}
perl-module_src_prepare() {
if [[ -n ${PATCHES} ]] ; then
base_src_unpack autopatch
fi
esvn_clean
}
perl-module_src_configure() {
perl-module_src_prep
}
perl-module_src_prep() {
[[ ${SRC_PREP} = yes ]] return 0
SRC_PREP=yes
${perlinfo_done} || perlinfo
export PERL_MM_USE_DEFAULT=1
# Disable ExtUtils::AutoInstall from prompting
export PERL_EXTUTILS_AUTOINSTALL=--skipdeps
if [[ ${PREFER_BUILDPL} == yes -f Build.PL ]] ; then
einfo Using Module::Build
perl Build.PL \
--installdirs=vendor \
--libdoc= \
--destdir=${D} \
--create_packlist=0 \
--extra_linker_flags=${LDFLAGS} \
${myconf} \
${pm_echovar} \
|| die Unable to build! (are you using
USE=\build\?)
elif [[ -f Makefile.PL ]] ; then
einfo Using ExtUtils::MakeMaker
perl Makefile.PL \
PREFIX=/usr \
INSTALLDIRS=vendor \
INSTALLMAN3DIR='none' \
DESTDIR=${D} \
${myconf} \
${pm_echovar} \
|| die Unable to build! (are you using
USE=\build\?)
fi
if [[ ! -f Build.PL ! -f Makefile.PL ]] ; then
einfo No Make or Build file detected...
return
fi
}
perl-module_src_compile() {
${perlinfo_done} || perlinfo
has ${EAPI:-0} 0 1 perl-module_src_prep
if [[ -f Build ]] ; then
./Build build || die compilation failed
elif [[ -f Makefile ]] ; then
#emake ${mymake} OPTIMIZE=${CFLAGS} OTHERLDFLAGS=${LDFLAGS}
|| die compilation failed
emake ${mymake} OTHERLDFLAGS=${LDFLAGS} || die compilation
failed
fi
}
perl-module_src_test() {
if [[ ${SRC_TEST} == do ]] ; then
${perlinfo_done} || perlinfo
if [[ -f Build ]] ; then
./Build test || die test failed
elif [[ -f Makefile ]] ; then
emake test || die test failed
fi
fi
}
perl-module_src_install() {
local f
${perlinfo_done} || perlinfo
[[ -z ${mytargets} ]] mytargets=pure_install
if [[ -f Build ]] ; then
./Build ${mytargets} || die
elif [[ -f Makefile ]] ; then
emake ${myinst} ${mytargets} || die
fi
# einfo Cleaning out stray man files
find ${D} -type f -name *.3pm -delete
find ${D}/usr/share/man -depth -type d -empty -delete 2/dev/null
fixlocalpod
for f in Change* CHANGES README* ${mydoc}; do
[[ -s ${f} ]] dodoc ${f}
done
[gentoo-dev] perl-module.eclass -- review
Please review the attached perl-module.eclass.
Patch linked below.
Changes (#239510):
~~~
- EAPI 2 support
- default license
- reduced EXPORT_FUNCTIONS for EAPI=2
- HOMEPAGE changed
- LDFLAGS support
- quoting
- removes updatepod()
- removes .packlist files
- removes empty *.bs files
- removed BUILDER_VER stuff
IDEAS
~
- remove esvn_clean
- cache perlinfo calls
TODO (no showstopper)
- still no documentation
- perl-app.eclass not done
After that perl-module_src_prep calls in ebuilds should be updated
(perl-module_src_configure) or removed:
|app-pda/pilot-link
|dev-perl/GDTextUtil
|dev-tex/html2latex
|kde-base/dcopperl
|mail-filter/spamassassin
|sci-libs/gdal
|sci-libs/udunit
Ebuilds with a local perl-module_src_prep function should be fixed too
|dev-perl/Alien-wxWidgets
|dev-perl/HTML-Mason
|www-apps/Embperl/Embperl
git://github.com/tove/perl-eclass.git
http://people.gentoo.org/tove/files/perl-module.eclass.diff
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/perl-module.eclass,v 1.112 2008/09/30
08:28:44 robbat2 Exp $
#
# Author: Seemant Kulleen seem...@gentoo.org
# @ECLASS: perl-module.eclass
# @MAINTAINER:
# p...@gentoo.org
# @BLURB: eclass for perl modules
# @DESCRIPTION:
# The perl-module eclass is designed to allow easier installation of perl
# modules, and their incorporation into the Gentoo Linux system.
inherit eutils base
case ${EAPI:-0} in
0|1)
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm
pkg_postrm src_compile src_install src_test src_unpack
;;
*)
EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_test src_install
;;
esac
DESCRIPTION=Based on the $ECLASS eclass
LICENSE=${LICENSE:-|| ( Artistic GPL-2 )}
[ -z ${SRC_URI} -a -z ${MODULE_A} ] MODULE_A=${MY_P:-${P}}.tar.gz
[ -z ${SRC_URI} -a -n ${MODULE_AUTHOR} ] \
SRC_URI=mirror://cpan/authors/id/${MODULE_AUTHOR:0:1}/${MODULE_AUTHOR:0:2}/${MODULE_AUTHOR}/${MODULE_SECTION}/${MODULE_A}
[ -z ${HOMEPAGE} ] \
HOMEPAGE=http://search.cpan.org/dist/${MY_PN:-${PN}};
SRC_PREP=no
SRC_TEST=skip
PREFER_BUILDPL=yes
PERL_VERSION=
SITE_ARCH=
SITE_LIB=
VENDOR_LIB=
VENDOR_ARCH=
ARCH_LIB=
pm_echovar=
perl-module_src_unpack() {
base_src_unpack unpack
has ${EAPI:-0} 0 1 perl-module_src_prepare
}
perl-module_src_prepare() {
if [[ -n ${PATCHES} ]] ; then
base_src_unpack autopatch
fi
esvn_clean
}
perl-module_src_configure() {
perl-module_src_prep
}
perl-module_src_prep() {
[[ ${SRC_PREP} = yes ]] return 0
SRC_PREP=yes
perlinfo
export PERL_MM_USE_DEFAULT=1
# Disable ExtUtils::AutoInstall from prompting
export PERL_EXTUTILS_AUTOINSTALL=--skipdeps
if [[ ${PREFER_BUILDPL} == yes -f Build.PL ]] ; then
einfo Using Module::Build
perl Build.PL \
--installdirs vendor \
--libdoc= \
--config installman3dir= \
--destdir ${D} \
--create_packlist=0 \
--extra_linker_flags=${LDFLAGS} \
${myconf} \
${pm_echovar} \
|| die Unable to build! (are you using
USE=\build\?)
elif [[ -f Makefile.PL ]] ; then
einfo Using ExtUtils::MakeMaker
perl Makefile.PL \
PREFIX=/usr \
INSTALLDIRS=vendor \
INSTALLMAN3DIR='none' \
DESTDIR=${D} \
${myconf} \
${pm_echovar} \
|| die Unable to build! (are you using
USE=\build\?)
fi
if [[ ! -f Build.PL ! -f Makefile.PL ]] ; then
einfo No Make or Build file detected...
return
fi
}
perl-module_src_compile() {
perlinfo
has ${EAPI:-0} 0 1 perl-module_src_prep
if [[ -f Build ]] ; then
./Build build || die compilation failed
elif [[ -f Makefile ]] ; then
#make ${mymake} OPTIMIZE=${CFLAGS} OTHERLDFLAGS=${LDFLAGS}
|| die compilation failed
make ${mymake} OTHERLDFLAGS=${LDFLAGS} || die compilation
failed
fi
}
perl-module_src_test() {
if [[ ${SRC_TEST} == do ]] ; then
perlinfo
if [[ -f Build ]] ; then
./Build test || die test failed
elif [[ -f Makefile ]] ; then
make test || die test failed
fi
fi
}
perl-module_src_install() {
local f stat
perlinfo
[[ -z ${mytargets} ]]
[gentoo-dev] Open council spot
* Petteri Räty betelge...@gentoo.org: Donnie Berkholz wrote: Open council spot - leio is next on the list. He's willing to join the council. A few of us already voted to confirm him on-list, and we're waiting on the others. Goal: Vote to confirm him, if necessary. There already were enough votes (4/6 I think) to confirm him. GLEP 39 doesn't specify what happens when a member leaves. It does only talk about slackers. A former council decided to offer any open position to the next in line and if they accept and the current Council unanimously accepts the new person, they get the position. http://www.gentoo.org/proj/en/council/meeting-logs/20070208-summary.txt 4/6 is not unanimously. But... This all was before _reopen_nominations was introduced. With _reopen_nominations I don't see why the council needs to vote at all. There might be a problem if another member leaves as the next two are ranked equally. Thanks
[gentoo-dev] Re: prepalldocs implementation in eutils.eclass
* Michael Sterrett mr_bon...@gentoo.org:
Patches welcome.
--- eutils.eclass
+++ eutils.eclass
@@ -1823,21 +1823,3 @@
newbin ${tmpwrapper} ${wrapper} || die
fi
}
-
-# @FUNCTION: prepalldocs
-# @USAGE:
-# @DESCRIPTION:
-# Compress files in /usr/share/doc which are not already
-# compressed, excluding /usr/share/doc/${PF}/html.
-# Uses the ecompressdir to do the compression.
-prepalldocs() {
- if [[ -n $1 ]] ; then
- ewarn prepalldocs: invalid usage; takes no arguments
- fi
-
- cd ${D}
- [[ -d usr/share/doc ]] || exit 0
-
- ecompressdir --ignore /usr/share/doc/${PF}/html
- ecompressdir --queue /usr/share/doc
-}
[gentoo-dev] repoman -d or not -d
How do we use the -d config switch of repoman? Do I use it if i bump packages, add new dependencies? Is it mainly for the maintainers of the profile/arch? Sorry, if I've missed the discussion. Thanks, Torsten
[gentoo-dev] Re: gentoo-x86 commit in app-forensics/memdump: memdump-1.0.1.ebuild ChangeLog
* Patrick Lauer (patrick) patr...@gentoo.org:
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/memdump/memdump-1.0.1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/memdump/memdump-1.0.1.ebuild?rev=1.1content-type=text/plain
Index: memdump-1.0.1.ebuild
===
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/app-forensics/memdump/memdump-1.0.1.ebuild,v 1.1
2009/01/04 23:45:43 patrick Exp $
DESCRIPTION=Simple memory dumper for UNIX-Like systems
HOMEPAGE=http://www.porcupine.org/forensics;
SRC_URI=http://www.porcupine.org/forensics/${PN}-1.01.tar.gz;
LICENSE=IBM
SLOT=0
KEYWORDS=~amd64 ~ppc ~x86
DEPEND=sys-apps/sed
sys-apps/grep
RDEPEND=virtual/libc
^^
IUSE=
S=${WORKDIR}/${PN}-1.01
src_compile() {
cd ${S}/memdump-1.01
emake XFLAGS=${CFLAGS} OPT= DEBUG= || die
}
src_test() {
if has userpriv ${FEATURES};
~~~
not in pms afair
then
einfo Cannot test with FEATURES=userpriv
elif [ -x /bin/wc ];
then
einfo testing
if [ `./memdump -s 344 | wc -c` = 344 ];
then
einfo passed test
else
die failed test
fi
fi
}
src_install() {
dosbin memdump
|| die
dodoc README LICENSE
doman memdump.1
}
[gentoo-dev] Re: gentoo-x86 commit in app-forensics/sleuthkit: ChangeLog sleuthkit-3.0.0.ebuild
* Patrick Lauer (patrick) patr...@gentoo.org:
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/sleuthkit/sleuthkit-3.0.0.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/sleuthkit/sleuthkit-3.0.0.ebuild?rev=1.1content-type=text/plain
inherit eutils flag-o-matic autotools
SLOT=0
DESCRIPTION=A collection of file system and media management forensic
analysis tools
HOMEPAGE=http://www.sleuthkit.org/sleuthkit/;
SRC_URI=mirror://sourceforge/sleuthkit/${P}.tar.gz
LICENSE=GPL-2 IBM
KEYWORDS=~amd64 ~arm ~hppa ~ppc ~s390 ~sparc ~x86
no IUSE.
# disabling until imported into portage - patrick
#DEPEND=ewf? ( app-forensics/libewf )
# aff? ( app-forensics/afflib )
RDEPEND=dev-perl/DateManip
src_unpack() {
unpack ${A}
^^ often not wanted
cd ${S}
# AC_FUNC_REALLOC in configure.ac that hasn't been propagated
eautoreconf
}
src_compile() {
use hfs append-flags -DTSK_USE_HFS
^^^
econf || die configure failed
emake || die make failed
}
src_install() {
emake install DESTDIR=${D}
^ || die
dodoc docs/*.txt README.txt CHANGES.txt TODO.txt
}
[gentoo-dev] Need to mask non-visible packages in package.mask?
Some time ago (31 Oct 2008) I renamed perl-core/File-Spec-3.2701 to perl-core/File-Spec-3.27.01 by adding the new file and removing the other. I expected portage to do an downgrade. It didn't. I realised it when i got this bug https://bugs.gentoo.org/248178 and after joining #-portage I add a mask for a non-existing package to package.mask. Today I was CC'ed to https://bugs.gentoo.org/105016 because package.mask contains invalid entries. In the meantime another bug was filed about portage doesn't attempt to downgrade packages on keyword changes... https://bugs.gentoo.org/252167 with a fix. I am confused. Will portage warn about the downgrade now and forever?
[gentoo-dev] Moving packages -- breaking the tree or stop updating mirrors?
It is time to finish the move of some new dual-lifed perl modules from dev-perl to perl-core (plus virtual/). It involves updating of 120 packages all over the tree but mostly in dev-perl. As this takes some time the tree will be inconsistent until it is finished. I don't know how long it'll take. So the question is: Can we stop updating the rsync mirrors during that time easily? Or even better: Can *I* stop it? As there were problems while moving packages before, I remember we were talking about a way to stop updating rsync mirrors from cvs. I guess nothing was implemented? Thanks.
[gentoo-dev] Re: gentoo-x86 commit in app-mobilephone/smstools: ChangeLog smstools-2.2.20.ebuild
* Tony Vroon (chainsaw) [EMAIL PROTECTED]:
diff -u -r1.1 -r1.2
--- smstools-2.2.20.ebuild14 Jan 2008 16:13:37 - 1.1
+++ smstools-2.2.20.ebuild31 Oct 2008 15:49:29 - 1.2
-pkg_setup() {
- enewgroup sms
- enewuser smsd -1 -1 /var/spool/sms sms
-}
-
src_unpack() {
unpack ${A}
cd ${S}
@@ -35,7 +30,12 @@
src_compile() {
cd src
- emake || die emake failed
+ emake CC=$(tc-getCC) || die emake failed
+}
+
+pkg_preinst() {
+ enewgroup sms
+ enewuser smsd -1 -1 /var/spool/sms sms
}
src_install() {
chown -R smsd:sms ${D}/var/spool/sms
chmod g+s ${D}/var/spool/sms/incoming
newinitd ${FILESDIR}/smsd.initd smsd
insopts -o smsd -g sms -m0644
@@ -60,5 +60,6 @@
}
pkg_postinst() {
+ touch /var/log/smsd.log
chown -f smsd:sms /var/log/smsd.log
}
Remember pkg_preinst is called after src_install.
So the user and group probably don't exist during src_install.
BTW: ROOT should be respected in pkg_postinst too.
[gentoo-dev] Re: proj/en/perl/outdated-cpan-packages.xml automatic update
* Robin H. Johnson [EMAIL PROTECTED]: On Fri, Oct 03, 2008 at 07:33:11AM +0200, Torsten Veller wrote: * Robin H. Johnson [EMAIL PROTECTED]: And something is broken with CPAN, just in time for us :-). Manually browsing give me: http://search.cpan.org/~rjbs/Email-MessageID-1.400/ This version was released yesterday. But using CPAN itself gives me: Email::MessageID 1.351 R/RJ/RJBS/Email-MessageID-1.351.tar.gz It's in here: Last-Updated: Fri, 03 Oct 2008 00:26:55 GMT Email::MessageID 1.400 R/RJ/RJBS/Email-MessageID-1.400.tar.gz If you look at the commits that the script made, some of the CPAN mirrors had Email-MessageID-1.400 in the index, but others didn't. http://cpan.org/misc/cpan-faq.html#Which_site_mirror: http://www.cs.uu.nl/stats/mirmon/cpan.html: The mirrors are not all syncing from the master site and sync at different times probably only once a day while the master gets update more often. So a new module can be missing on some servers. Then again some servers are not uptodate at all. archive.cs.uu.nl: Fri, 03 Oct 2008 00:26:55 GMT arwen.cs.dal.ca: Wed, 01 Oct 2008 08:28:05 GMT cpan.biz.net.id: Thu, 02 Oct 2008 14:27:30 GMT cpan.catalyst.net.nz: Fri, 03 Oct 2008 04:27:05 GMT cpan.mirror.ac.za:Thu, 02 Oct 2008 14:27:30 GMT cpan.mirrors.easynet.fr: Fri, 03 Oct 2008 03:26:50 GMT cpan.mirror.choon.net:Fri, 03 Oct 2008 04:27:05 GMT cpan.mirror.clemson.edu: Sat, 27 Sep 2008 22:26:48 GMT cpan.net.pl: Fri, 05 Sep 2008 00:02:47 GMT cpan.triplemind.com: Mon, 14 Jul 2008 03:02:58 GMT cpan.velug.org.ve:Fri, 03 Oct 2008 04:27:05 GMT For the scipt we should use a reliable mirror or the master site. Thanks.
[gentoo-dev] Re: proj/en/perl/outdated-cpan-packages.xml automatic update
* Robin H. Johnson [EMAIL PROTECTED]: On Thu, Oct 02, 2008 at 06:20:57PM -0700, Robin H. Johnson wrote: To help out the perl team, I converted their up2date-ng script running to be purely automatic from cvs.g.o now, it will run daily at 01h52 UTC. Thanks. If you touch up2date_package.altname or up2date_package.mask please give me a shout so I can ensure updated copies on the server. And something is broken with CPAN, just in time for us :-). Manually browsing give me: http://search.cpan.org/~rjbs/Email-MessageID-1.400/ This version was released yesterday. But using CPAN itself gives me: Email::MessageID 1.351 R/RJ/RJBS/Email-MessageID-1.351.tar.gz It's in here: Last-Updated: Fri, 03 Oct 2008 00:26:55 GMT Email::MessageID 1.400 R/RJ/RJBS/Email-MessageID-1.400.tar.gz
