At some point around Feb. 2010, an update (portage?, bash?) introduced problems into the package query tool, epm. For recently emerged packages, the information displayed by 'epm -qi' is mostly missing, while for packages installed some time ago, the fields of information are all present. Reproducible: Always Steps to Reproduce: 1. emerge a new or update a package 'foo' 2. epm -qi foo Actual Results: epm -qi portage Use of uninitialized value in printf at /usr/bin/epm line 248. Use of uninitialized value in printf at /usr/bin/epm line 248. Use of uninitialized value in printf at /usr/bin/epm line 248. Use of uninitialized value in printf at /usr/bin/epm line 248. Use of uninitialized value in printf at /usr/bin/epm line 248. Use of uninitialized value in printf at /usr/bin/epm line 248. Use of uninitialized value in printf at /usr/bin/epm line 248. Use of uninitialized value in printf at /usr/bin/epm line 248. Name : Version : Release : Slot: Install date: Sat Mar 20 16:34:23 2010 Build Host: Group : sys-apps License: Size : 2053094 Packager : ranger URL : Summary : Expected Results: epm -qi portage Name : portage Version : 2.1.7.17 Release : r0 Slot: 0 Install date: Sat Mar 20 16:34:23 2010 Build Host: BoeCore2 Group : sys-apps License: GPL-2 Size : 2053094 Packager : ranger URL : http://www.gentoo.org/proj/en/portage/index.xml Summary : Portage is the package management and distribution system for Gento /usr/bin/epm line 208 has a regexp while (<F>) { next unless (/^(CATEGORY|HOSTNAME|DESCRIPTION|HOMEPAGE|LICENSE|PN|PR|PV|SLOT)=(.*)/); ($key, $value) = ($1, $2); The file <F> that it is stepping through is environment.bz2 file (in /var/db/pkg/sys-apps/portage-2.1.7.17 for the example above). That file used to have assignments such as HOMEPAGE="http://www.gentoo.org/proj/en/portage/index.xml" which are now of the form declare HOMEPAGE="http://www.gentoo.org/proj/en/portage/index.xml" or declare -x HOMEPAGE="http://www.gentoo.org/proj/en/portage/index.xml" I would think a simple change to the regexp line would fix this bug.
Created attachment 225777 [details, diff] epm patches for newer portage system Rework so epm doesn't fail on envariables declared with '(declare( -x)? )?' which balks with 'unintialized value'
I was just going to file a bug on this with an included patch... Give it a try and let me know if this fixes it for you... One more thing, it appears that 'HOSTNAME' is not preserved in the build environment which is what epm keys off of to ascertain 'Build Host:' Here are my notes regarding that: #TT:Sun 21 Mar 2010 08:21:40 PM EDT Cannot fix the "Build Host" entry, as epm will look in: /var/db/**/environment.bz2 for the HOSTNAME envariable The HOSTNAME envariable is no longer available, and this changed between: 2.6.13 => 2.7.16 HOSTNAME is filtered out by: ebuild.sh::filter_readonly_variables() regardless if 'allow-extra-variables' is defined or not, as HOSTNAME is in bash_misc_vars
(In reply to comment #2) Thanks. That patch worked better than my attempted hacks. I don't miss HOSTNAME. I have not tested extensively, but the patch produces expected output for the cases I use the most: epm -qa |grep foo # search among installed packages epm -Gqi foo # what group, URL, maintainer, install date for foo epm -ql foo # show all installed files for package foo Odd to have such perl code bridging rpm and emerge, two python arenas.
Created attachment 226685 [details, diff] smaller patch to fix environment.bz2 handling I have created a smaller patch (just a 3 line change) to fix the issue. I've attached it even when I'm a bit late.
Created attachment 226687 [details, diff] smaller patch to fix environment.bz2 handling patch fixed (extra HOMEPAGE/URL removed)
I can confirm that with it epm -qi finally does something useful again. It would be great if this patch would finally make it into Gentoo.
The attached patches will fix this issue... bump issue so it gets another look over...
Thanks for the patches. Fixed in epm-1.33-r1
