perl-cleaner told me to create a bug with the following information (sorry for the bad summary): After I run # emerge --ask --verbose --update --deep --with-bdeps=y --newuse world I run perl-cleaner: Calculating dependencies... done! [ebuild U ] virtual/perl-Archive-Tar-2.40.0::gentoo [1.960.0::gentoo] 0 KiB [ebuild U ] virtual/perl-CPAN-Meta-Requirements-2.132.0::gentoo [2.125.0-r1::gentoo] 0 KiB [ebuild U ] virtual/perl-ExtUtils-Command-1.200.0::gentoo [1.180.0-r2::gentoo] 0 KiB Total: 3 packages (3 upgrades), Size of downloads: 0 KiB >>> Verifying ebuild manifests >>> Emerging (1 of 3) virtual/perl-Archive-Tar-2.40.0::gentoo >>> Emerging (2 of 3) virtual/perl-CPAN-Meta-Requirements-2.132.0::gentoo >>> Emerging (3 of 3) virtual/perl-ExtUtils-Command-1.200.0::gentoo >>> Installing (1 of 3) virtual/perl-Archive-Tar-2.40.0::gentoo >>> Installing (2 of 3) virtual/perl-CPAN-Meta-Requirements-2.132.0::gentoo >>> Installing (3 of 3) virtual/perl-ExtUtils-Command-1.200.0::gentoo >>> Jobs: 3 of 3 complete Load avg: 0.78, 3.89, 3.88 >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. * Beginning a clean up of .ph files * Excluding files for 5.22.0 and 5.22.0/x86_64-linux from cleaning * Locating ph files for removal * Updating ph files. * Ignore all "No such file..." messages! Can't open machine/ansi.h: No such file or directory Can't open sys/_types.h: No such file or directory Can't open gnu/stubs-x32.h: No such file or directory Can't open gnu/stubs-x32.h: No such file or directory Can't open gnu/stubs-x32.h: No such file or directory Can't open gnu/stubs-x32.h: No such file or directory * Locating packages for an update * Locating ebuilds linked against libperl * Adding to list: perl-core/ExtUtils-Manifest:0 * virtual/perl-ExtUtils-Manifest:0 * Adding to list: perl-core/CPAN-Meta:0 * virtual/perl-CPAN-Meta:0 * emerge -v1 --backtrack=200 --usepkg=n perl-core/ExtUtils-Manifest:0 virtual/perl-ExtUtils-Manifest:0 perl-core/CPAN-Meta:0 vi rtual/perl-CPAN-Meta:0 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] perl-core/ExtUtils-Manifest-1.700.0::gentoo 0 KiB [ebuild R ] virtual/perl-ExtUtils-Manifest-1.700.0-r1::gentoo 0 KiB [ebuild R ] perl-core/CPAN-Meta-2.143.240::gentoo USE="{-test}" 0 KiB [ebuild R ] virtual/perl-CPAN-Meta-2.150.1::gentoo 0 KiB Total: 4 packages (4 reinstalls), Size of downloads: 0 KiB >>> Verifying ebuild manifests >>> Emerging (1 of 4) perl-core/ExtUtils-Manifest-1.700.0::gentoo >>> Emerging (2 of 4) virtual/perl-ExtUtils-Manifest-1.700.0-r1::gentoo >>> Emerging (3 of 4) perl-core/CPAN-Meta-2.143.240::gentoo >>> Emerging (4 of 4) virtual/perl-CPAN-Meta-2.150.1::gentoo >>> Installing (2 of 4) virtual/perl-ExtUtils-Manifest-1.700.0-r1::gentoo >>> Installing (1 of 4) perl-core/ExtUtils-Manifest-1.700.0::gentoo >>> Installing (4 of 4) virtual/perl-CPAN-Meta-2.150.1::gentoo >>> Installing (3 of 4) perl-core/CPAN-Meta-2.143.240::gentoo >>> Jobs: 4 of 4 complete Load avg: 1.23, 3.30, 3.67 >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. * * It seems like perl-cleaner had to rebuild some packages. * * If you have just updated your major Perl version (e.g. from 5.20.2 to 5.22.0), * and have run perl-cleaner _after_ that update, then this means most likely * that these packages are buggy. Please file a bug on http://bugs.gentoo.org/ and * report that perl-cleaner needed to reinstall the following list: * perl-core/ExtUtils-Manifest:0 virtual/perl-ExtUtils-Manifest:0 perl-core/CPAN-Meta:0 virtual/perl-CPAN-Meta:0 * * Finding left over modules and header * The following files remain. These were either installed by hand * or edited. This script cannot deal with them. PS: To get a smooth perl upgrade I had to manually remove perl-core/libnet, perl-core/Data-Dumper and perl-core/ExtUtils-MakeMaker. Reproducible: Always
sys-libs/libhugetlbfs:0 is also affected.
Module-Corelist seems also to be affected per my output: * report that perl-cleaner needed to reinstall the following list: * perl-core/CPAN-Meta:0 virtual/perl-CPAN-Meta:0 perl-core/Module-CoreList:0 virtual/perl-Module-CoreList:0 perl-core/ExtUtils-Manifest:0 virtual/perl-ExtUtils-Manifest:0 *
(In reply to Thomas D. from comment #0) [...] > * report that perl-cleaner needed to reinstall the following list: > * perl-core/ExtUtils-Manifest:0 virtual/perl-ExtUtils-Manifest:0 > perl-core/CPAN-Meta:0 virtual/perl-CPAN-Meta:0 > * > > * Finding left over modules and header > > * The following files remain. These were either installed by hand > * or edited. This script cannot deal with them. > > > PS: To get a smooth perl upgrade I had to manually remove perl-core/libnet, > perl-core/Data-Dumper and perl-core/ExtUtils-MakeMaker. > > Reproducible: Always I think that perl modules are using subslots and perl-module.eclass properly and, then, this shouldn't occur. But, *maybe*, the problem was that this packages weren't updated to their eapi5 versions until now (as they were probably buildtime only dependencies) and, then, now that they got merged with updated eapi and subslot information stored in VDB, this shouldn't need any change for the future (In reply to Thomas D. from comment #1) > sys-libs/libhugetlbfs:0 is also affected. I would open a new bug report for that one with all logs because, for that case, I suspect there is an automagic dependency on perl or similar Thanks
(In reply to Thomas D. from comment #1) > sys-libs/libhugetlbfs:0 is also affected. This is the only problematic one (all others are probably due to not running depclean at some point).
* missing dev-lang/perl:= dependency (yes the slot operator is mandatory) * installs Perl modules in incorrect path /usr/lib64/perl5 /usr/lib64/perl5/TLBC /usr/lib64/perl5/TLBC/DataCollect.pm /usr/lib64/perl5/TLBC/OpCollect.pm /usr/lib64/perl5/TLBC/PerfCollect.pm /usr/lib64/perl5/TLBC/Report.pm please consider using PERL_EXPORT_PHASE_FUNCTIONS=no inherit perl-module and then during build perl_set_version to read out the perl install paths; the modules should eg. go into ${VENDOR_LIB}/TLBC/Report.pm
(In reply to Andreas K. Hüttel from comment #5) feel free to make any perl related changes to the ebuild
Hi, I created a pull request which fixes this bug and various other problems in this ebuild: https://github.com/gentoo/gentoo/pull/131 - libhugetlbfs project moved from SF to GitHub (HOMEPAGE, SRC_URI & metadata.xml updated) - Perl modules will be now installed in the correct location (Fixes https://bugs.gentoo.org/show_bug.cgi?id=554688#c5) - Added RDEPEND on dev-lang/perl atom (https://bugs.gentoo.org/show_bug.cgi?id=554688#c5) - Added dev-lang/python:2_7 dependency when using FEATURES=test Required by "run_tests.py", otherwise * Starting tests File "./run_tests.py", line 62 print "Pool state: %s" % str(beforepool) [...] when using dev-lang/python:3*. - "/var/lib" added to sandbox' write list, otherwise mkdir -p /var/lib/hugetlbfs/pagesize-${pagesize} would fail - Removed redundant "addwrite" call for "/var/lib/hugetlbfs/pagesize-${pagesize}" (Already added to white list when we created these folders) For better reviewing I am attaching a diff against the current ebuild in tree: diff -rupN old/sys-libs/libhugetlbfs/libhugetlbfs-2.19.ebuild new/sys-libs/libhugetlbfs/libhugetlbfs-2.19.ebuild --- old/sys-libs/libhugetlbfs/libhugetlbfs-2.19.ebuild 2015-08-09 22:34:55.000000000 +0200 +++ new/sys-libs/libhugetlbfs/libhugetlbfs-2.19.ebuild 2015-09-25 16:37:31.000000000 +0200 @@ -2,30 +2,40 @@ # Distributed under the terms of the GNU General Public License v2 # $Id$ -EAPI="4" +EAPI="5" +PERL_EXPORT_PHASE_FUNCTIONS="no" +GENTOO_DEPEND_ON_PERL="no" +PYTHON_COMPAT=( python2_7 ) -inherit eutils multilib toolchain-funcs +inherit eutils multilib perl-module python-any-r1 toolchain-funcs DESCRIPTION="easy hugepage access" -HOMEPAGE="http://libhugetlbfs.sourceforge.net/" -SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz" +HOMEPAGE="https://github.com/libhugetlbfs/libhugetlbfs" +SRC_URI="https://github.com/libhugetlbfs/libhugetlbfs/archive/${PV}.tar.gz -> ${P}.tar.gz" LICENSE="GPL-2" SLOT="0" -KEYWORDS="~amd64 ~ppc64 ~x86" -IUSE="static-libs" +KEYWORDS="~amd64 ~x86" +IUSE="static-libs test" + +DEPEND="test? ( ${PYTHON_DEPS} )" +RDEPEND="dev-lang/perl:=" src_prepare() { epatch "${FILESDIR}"/${PN}-2.9-build.patch #332517 epatch "${FILESDIR}"/${PN}-2.6-noexec-stack.patch epatch "${FILESDIR}"/${PN}-2.6-fixup-testsuite.patch + + perl_set_version + sed -i \ -e '/^PREFIX/s:/local::' \ -e '1iBUILDTYPE = NATIVEONLY' \ -e '1iV = 1' \ -e "/^LIB\(32\)/s:=.*:= $(get_libdir):" \ -e '/^CC\(32\|64\)/s:=.*:= $(CC):' \ - Makefile + -e "/^PMDIR = .*\/perl5\/TLBC/s::PMDIR = ${VENDOR_LIB}\/TLBC:" \ + Makefile || die "sed failed" if [ "$(get_libdir)" == "lib64" ]; then sed -i \ -e "/^LIB\(32\)/s:=.*:= lib32:" \ @@ -73,10 +83,12 @@ src_test() { einfo "Planning allocation" PAGESIZES="$(${hugeadm} --page-sizes-all)" + addwrite /var/lib/ + # Need to do this before we can create the mountpoints. for pagesize in ${PAGESIZES} ; do # The kernel depends on the location :-( - mkdir -p /var/lib/hugetlbfs/pagesize-${pagesize} + mkdir -p /var/lib/hugetlbfs/pagesize-${pagesize} || die "Failed to create directory" addwrite /var/lib/hugetlbfs/pagesize-${pagesize} done addwrite /proc/sys/vm/ @@ -95,7 +107,6 @@ src_test() { for pagesize in ${PAGESIZES} ; do pagecount=$((${MIN_HUGEPAGE_RAM}/${pagesize})) einfo " ${pagecount} @ ${pagesize}" - addwrite /var/lib/hugetlbfs/pagesize-${pagesize} src_test_alloc_one "$hugeadm" "+" "${pagesize}" "${pagecount}" rc=$? if [[ $rc -eq 0 ]]; then diff -rupN old/sys-libs/libhugetlbfs/metadata.xml new/sys-libs/libhugetlbfs/metadata.xml --- old/sys-libs/libhugetlbfs/metadata.xml 2015-08-24 23:01:04.000000000 +0200 +++ new/sys-libs/libhugetlbfs/metadata.xml 2015-09-25 19:16:46.000000000 +0200 @@ -3,6 +3,6 @@ <pkgmetadata> <herd>base-system</herd> <upstream> - <remote-id type="sourceforge">libhugetlbfs</remote-id> + <remote-id type="github">libhugetlbfs/libhugetlbfs</remote-id> </upstream> </pkgmetadata>
(In reply to Thomas D. from comment #7) never post patches as comments. bugzilla will corrupt them rendering them useless, and most of the time they just add noise. if you want to post a patch, then do so as an attachment.
Created attachment 412940 [details, diff] Changeset PR 131
i've updated the upstream, but not the SRC_URI. github does not have the same tarball as SF which means all the manifests/existing downloads would break. http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c027340b6037cda863580de3d2520b57a9c49dea
(In reply to SpanKY from comment #6) > (In reply to Andreas K. Hüttel from comment #5) > > feel free to make any perl related changes to the ebuild Perl changes (including needed EAPI=5 bump) done in 2.19-r1, leaving this open in case you still want to implement any of the other changes suggested by Thomas D.
I updated the PR at GitHub and incorporated your changes (well, I already fixed the Perl thing but I now switched from per-module eclass to perl-functions eclass like you did).
(In reply to Andreas K. Hüttel from comment #11) thanks, i've made the perl support optional now via USE=perl http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eafb5bff4795e5a83122ebcbfc37b86607119115 (In reply to Thomas D. from comment #12) i've added the python test changes here: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e5ed736019cf2fd7e9db25189d1ac6b070337c4 and then version bumped to 2.20 (needed to build w/gcc-5): http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8f3aa6dadf4c787c54fabb212d7079c9fa5327a8
