[gentoo-dev] Re: About src_test() in perl-modules

[Torsten Veller]

* Mikle Kolyada :
> Lately, i saw many bugs like =dev-perl/${packagename}: fails test.

Strange, I didn't.

> Me just interested proper way to fix those bugs?

I think it depends on the bug.

So let's have a look at all "dev-perl" bugs in the last month:
https://bugs.gentoo.org/buglist.cgi?short_desc=dev-perl&chfieldto=Now&chfield=%5BBug%20creation%5D&chfieldfrom=-1M&short_desc_type=allwordssubstr

I see four bugs with test failures in the summary. The last three
are probably caused by not running perl-cleaner and invalid as the
dependencies are already correct. The libintl-perl tests depend on the
locale setting. An upstream bug was filed a long time ago and we tried
to skip the tests if they will fail but probably missed some case.

-- 
Thanks
Torsten

[gentoo-dev] Drop the Perl Modules Guideline?

[Torsten Veller]

Let's discuss the "specific guideline" for Perl modules. It's as follows:

,- http://devrel.gentoo.org/handbook/handbook.xml?part=2&chap=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

[Torsten Veller]

* "Fabian Groffen (grobian)" :
> 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

[Torsten Veller]

* Ian Stakenvicius :
> 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

[Torsten Veller]

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

[Torsten Veller]

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] Last rites dev-perl/Cflow, dev-lang/eleven and net-im/silc-client

[Torsten Veller]

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] remote-id cpan-module

[Torsten Veller]

* Corentin Chary :
> On Thu, May 17, 2012 at 2:02 AM, Kent Fredric  wrote:
> > On 13 May 2012 07:43, Torsten Veller  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] Re: License groups in ebuilds

[Torsten Veller]

* Ciaran McCreesh :
> On Sat, 12 May 2012 21:05:06 +0200
> Torsten Veller  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: RFC: Add new remote-id types in metadata.dtd

[Torsten Veller]

* Corentin Chary :
> 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 @@
>  
>perl
>
> +Class::MOP
> + type="cpan-module">Moose::Meta::Attribute::Native::Trait::Counter
> + type="cpan-module">Moose::Meta::Attribute::Native::Trait::String
> +Moose::Meta::Method::Delegation
> + type="cpan-module">Moose::Meta::TypeConstraint::Role
> + type="cpan-module">Moose::Meta::Attribute::Custom::Moose
> +Moose::Meta::Attribute
> +Moose::Meta::Method
> +Moose::Error::Croak
> +Moose::Util::MetaRole
> +Moose::Role
>  Moose
>
>  

[gentoo-dev] Re: License groups in ebuilds

[Torsten Veller]

* Kent Fredric :
> 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: making the stable tree more up-to-date

[Torsten Veller]

* "Paweł Hajdan, Jr." :
> 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] Re: Bugzilla proxy-maintainer template

[Torsten Veller]

* Markos Chandras :
> 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] Bugzilla proxy-maintainer template

[Torsten Veller]

* "Markos Chandras (hwoarang)" :
>   Log:
>   add note about default comment in bugs. Add template

> +Bugs assigned to maintainer-nee...@gentoo.org
> +
> +Developers who participate in this project should encourage users to 
> participate in this project when they notice a open bug for an orphaned 
> package. This 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] write to filesystem in pkg_pretend

[Torsten Veller]

* justin :
> 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

[Torsten Veller]

* Mike Frysinger :
> 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

[Torsten Veller]

* Jeremy Olexa :
> 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

[Torsten Veller]

* Samuli Suominen :
> 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

[Torsten Veller]

* Theo Chatzimichos :
> 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=2&chap=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

[Torsten Veller]

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?

[Torsten Veller]

* Alex Legler :
> 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: bugzilla cleanup: remove SECURITY keyword?

[Torsten Veller]

* "\"Paweł Hajdan, Jr.\"" :
> 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: Ebuild- and CPAN-versions compatibility

[Torsten Veller]

* Torsten Veller :
> 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...@]}"

[gentoo-dev] Ebuild- and CPAN-versions compatibility

[Torsten Veller]

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

[Torsten Veller]

* Ciaran McCreesh :
> 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

[Torsten Veller]

* Sebastian Pipping :
> +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

[Torsten Veller]

* Markus Duft :
> >>>  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]

# Torsten Veller  (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

[Torsten Veller]

* Michał Górny :
> Torsten Veller  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

[Torsten Veller]

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

[Torsten Veller]

* Markos Chandras :
> 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  (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

[Torsten Veller]

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 
Content-Type: text/plain
Posted: 2010-10-16
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: http://search.cpan.org/dist/perl-5.12.2/INSTALL#Changes_and_Incompatibilities
`

[gentoo-dev] Re: gentoo-x86 commit in perl-core/IO-Compress:

[Torsten Veller]

* "Mike Frysinger (vapier)" :
> 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

[Torsten Veller]

* "Tomas Chvatal (scarabeus)" :
>  4) Bugs assigned to council@ in bugzilla and their progress
> 
> https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=
> allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type
> =allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&
> status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&
> bug_status=NEW&bug_status=ASSIGNED&emailassigned_to1=1&emailcc1=1&emailtype1=
> substring&email1=council%40gentoo.org&emailassigned_to2=1&emailreporter2=1&
> emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&
> chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+
> last+time&field0-0-0=noop&type0-0-0=noop&value0-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

[Torsten Veller]

>  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 
:
| 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

[Torsten Veller]

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

[Torsten Veller]

* Jeroen Roovers :
> 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

[Torsten Veller]

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

[Torsten Veller]

* Tobias Scherbaum :
> 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

[Torsten Veller]

* Mike Frysinger :
> 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 )

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)

[Torsten Veller]

> 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]

* Torsten Veller :
> 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

[Torsten Veller]

* James Cloos :
> >>>>> "TV" == Torsten Veller  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

[Torsten Veller]

* Sebastian Pipping :
> 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

[Torsten Veller]

* Sebastian Pipping :
> - 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

[Torsten Veller]

* James Cloos :
> 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] Re: perl eclass review - EAPI=3 + new helper eclass

[Torsten Veller]

* Alec Warner :
> 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] perl eclass review - EAPI=3 + new helper eclass

[Torsten Veller]

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
 

[gentoo-dev] Re: Handling of keywording bugs with only one arch

[Torsten Veller]

* Petteri Räty :
> 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

[Torsten Veller]

* "Fabian Groffen (grobian)" :
> 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.2&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-gfx/graphicsmagick/graphicsmagick-1.3.12.ebuild?rev=1.2&content-type=text/plain
> diff : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-gfx/graphicsmagick/graphicsmagick-1.3.12.ebuild?r1=1.1&r2=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

[Torsten Veller]

* Ryan Hill :
> Torsten Veller  wrote:
> > * Torsten Veller :
> > > 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: Remove "dev"-status of mips profiles

[Torsten Veller]

* Torsten Veller :
> 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.

-- 
Thanks

[gentoo-dev] Re: eutils changes wrt EAPI-3 - ebeep and epause no longer available

[Torsten Veller]

* Jeremy Olexa :
> 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.330&r2=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

[Torsten Veller]

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

[Torsten Veller]

* Tomáš Chvátal :
> # @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]

* Torsten Veller :
> ./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] Re: Usage of vecho in the tree

[Torsten Veller]

* Torsten Veller :
> 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] Usage of vecho in the tree

[Torsten Veller]

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] EAPI-3 times and dates

[Torsten Veller]

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] Re: RFC: don't define ebeep and epause in eutils in EAPI 3

[Torsten Veller]

* Mike Frysinger :
> 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

[Torsten Veller]

* David Abbott :
> I nominate (in no particular order):
> tove

Thanks, but I decline.


pgpnd8aNUxHU5.pgp
Description: PGP signature

[gentoo-dev] Implicit IUSE

[Torsten Veller]

* Jonathan Callen :
> 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: gentoo-x86 commit in perl-core/Compress-Raw-Zlib

[Torsten Veller]

* "Jonathan Callen (abcd)" :
>  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] Re: Individual developer signing

[Torsten Veller]

* "Robin H. Johnson" :
> > 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

[Torsten Veller]

* "Robin H. Johnson" :
> 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

[Torsten Veller]

* "Joe Peterson (lavajoe)" :
> 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.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-sound/squeezeboxserver/squeezeboxserver-7.4.1.ebuild?rev=1.1&content-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"



> 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

[Torsten Veller]

> Tomáš Chvátal  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

[Torsten Veller]

* Sebastian Pipping :
> 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 Veller]

* Torsten Veller:
> 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 )

[Torsten Veller]

* "Robin H. Johnson (robbat2)" :
> 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.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1&content-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.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1&content-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

[Torsten Veller]

* "Fabian Groffen (grobian)" :
> 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.2&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild?rev=1.2&content-type=text/plain
> diff : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild?r1=1.1&r2=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

[Torsten Veller]

* Maciej Mrozowski :
> 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] Re: perl-module.class review

[Torsten Veller]

* Tomáš Chvátal :
> Dne pondělí 21 Září 2009 18:03:56 Torsten Veller napsal(a):
> > * Tomáš Chvátal :
> > > 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

[Torsten Veller]

* Tomáš Chvátal :
> 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

[Torsten Veller]

* Ciaran McCreesh :
> Torsten Veller  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] perl-5.10.1 status update

[Torsten Veller]

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] perl-module.class review

[Torsten Veller]

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}

[gentoo-dev] Major problems in the tree in the last month

[Torsten Veller]

* Andrew D Kirch :
> 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: Diff between Funtoo and Gentoo as an overlay

[Torsten Veller]

* Sebastian Pipping :
>   - perl-experimental

| * Catalyst-Plugin-Authentication - 0.100091 (Infrastructure plugin for the 
Catalyst authentication framework)

Old version. Was replaced by up-to-date stuff.

| * Date-Manip - 5.54 (Date manipulation routines)

_Date-Manip_ is in the tree as DateManip and was removed in June.

| * Image-ExifTool - 7.60 (Read and write meta information)

_Image-ExifTool_ is in the tree as media-libs/exiftool.

| * Netscape-Bookmarks - 1.95 (Netscape bookmarks)
| * Netscape-Bookmarks-Sourceforge - 2.2.02 (Netscape Bookmarks)

Those two aren't available in Gentoo.

| * Wx-Perl-Dialog - 0.04 (Abstract dialog class for simple dialog creation)

_Wx-Perl-Dialog_ was removed in March.

| * catalystframework - 5.7015 (Meta package for Catalyst - The Elegant MVC Web 
Applicatio)

_catalystframework_ was removed in Feb.



So Funtoo should sync more often.

[gentoo-dev] Re: perl-5.10 inclusion

[Torsten Veller]

* Lars Wendler :
> 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

[Torsten Veller]

* "Jorge Manuel B. S. Vicetto" :
> > 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 

2 


Have fun.

[gentoo-dev] Manifesto archive

[Torsten Veller]

* "Jorge Manuel B. S. Vicetto" :
> 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

[Torsten Veller]

* Roy Bamford :
> 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

[Torsten Veller]

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

[Torsten Veller]

* Patrick Lauer :
> 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]

# Torsten Veller  (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

[Torsten Veller]

* "Marijn Schouten (hkBst)" :
> 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] perl-app.eclass -- review

[Torsten Veller]

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 
# Maintained by the Perl herd 

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 - 3

[Torsten Veller]

* "Robin H. Johnson" :
> 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 

# @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
./B

[gentoo-dev] Re: perl-module.eclass -- review

[Torsten Veller]

* "Robin H. Johnson" :
> 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

[Torsten Veller]

* Donnie Berkholz :

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]

* Torsten Veller :
> 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 

# @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
   

[gentoo-dev] perl-module.eclass -- review

[Torsten Veller]

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 

# @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-m

[gentoo-dev] Open council spot

[Torsten Veller]

* Petteri Räty :
> 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".


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

[Torsten Veller]

* Michael Sterrett :
> 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] prepalldocs implementation in eutils.eclass (was: prepalldocs is now banned)

[Torsten Veller]

* Michael Sterrett :
> I added a prepalldocs function to eutils.eclass to provide the
> functionality.  It implements the
> behavior of the current stable sys-apps/portage-2.1.6.4.

ecompressdir is more portage internal than prepalldocs ever was.
This must be fixed.

[gentoo-dev] repoman -d or not -d

[Torsten Veller]

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/sleuthkit: ChangeLog sleuthkit-3.0.0.ebuild

[Torsten Veller]

* "Patrick Lauer (patrick)" :
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/sleuthkit/sleuthkit-3.0.0.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/sleuthkit/sleuthkit-3.0.0.ebuild?rev=1.1&content-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] Re: gentoo-x86 commit in app-forensics/memdump: memdump-1.0.1.ebuild ChangeLog

[Torsten Veller]

* "Patrick Lauer (patrick)" :
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/memdump/memdump-1.0.1.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/memdump/memdump-1.0.1.ebuild?rev=1.1&content-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] Need to mask non-visible packages in package.mask?

[Torsten Veller]

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 
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..." 
with a fix.


I am confused. Will portage warn about the downgrade now and forever?