Created attachment 354164 [details] dev-perl/PortageXS/PortageXS-0.2.12.ebuild Proxy-Maintainer advising availability of PortageXS 0.2.12, which aims to solve 2 present tree bugs ( one partially, but is still an improvement on the current scenario ). Requires bug #477772 Before it can be added.
Created attachment 354166 [details, diff] dev-perl/PortageXS/files/0.2.12/prefix.patch
Created attachment 354168 [details, diff] dev-perl/PortageXS/metadata.xml patch
which bug was fixed completely? (i mean number on b.g.o, if exist).
#264680 should be "mostly" fixed, at least, for average end users at least. #395337 should be fixed also, though, this is mostly conjecture because I don't know what scenario caused it to happen exactly, just my tests show what is seen there shouldn't still be happening. #437414 is now patched in the source, with additional edge cases I found from personal experience, namely, the patch there added a new different bug for me, because the code mixes "old" and "new" portage metafile locations, which aren't always there on systems. So instead of just picking one path and bailing if its not there, it instead checks for expected paths in a priority list, and returns the item found, for instance: the /etc/make.conf -> /etc/portage/make.conf transition is not complete on many targets, and both locations are still supported by portage, however, the existing code only tolerated one of those 2 paths.
Created attachment 354304 [details, diff] dev-perl/PortageXS/files/0.2.12/prefix.patch # attempt 2 Confound it, more testing reveals I somehow managed to miss a bunch of paths for EPREFIX patch, and a bunch of the paths aren't right yet for make.conf and friends -_-. I *swear* I had code in this release to switch between the 2 possible locations of make.profile, but nope, seems that somehow got lost and won't be in till a future release. No panic, 2 more releases already cut, slowly improving
Created attachment 354306 [details] dev-perl/PortageXS/PortageXS-0.2.12.ebuild Reuploading the ebuild, because it needed additonal eprefix parameters to patch a test.
Any update here? Can we add it to the tree?
In CVS.
Re-openining, because the files and changes indicated here to be applied simply didn't get applied. a. Many lines changed upstream b. many lines needed to be changed in the patch c. many lines needed to be changed in the ebuild d. b and c didn't happen. bug #514490 was thus inevitable.
Indeed. I was wrong. I'll mask this version for proper testing by me. Re-assign bug to me as reminder.
- New patch applyed - New dependency on virtual/perl-Module-Build Added
- Metadata done
I Will keep this bug open until unmasking.
Sigh. Now I'm looking into this again, it seems the continued failure to work is due to more failing to use the ebuild I provided: Your ebuild: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-perl/PortageXS/PortageXS-0.02.12.ebuild?view=markup lib/PortageXS/Core.pm \ lib/PortageXS.pm \ usr/bin/portagexs_client \ usr/sbin/portagexsd Mine: lib/PortageXS/Core.pm \ lib/PortageXS.pm \ usr/bin/portagexs_client \ usr/sbin/portagexsd \ t/01_Core.t So of course the tests are going to fail. But In further digging I discovered the patch adds one I didn't add to the eprefixify list, so the eprefixify list should be: lib/PortageXS/examples/getParamFromFile.pl \ lib/PortageXS/Core.pm \ lib/PortageXS.pm \ usr/bin/portagexs_client \ usr/sbin/portagexsd \ t/01_Core.t Having made that change, it again passes its own tests. Other changes I wanted but weren't made: 1. Properly normalising the version 2. Deleting the now outdated HOMEPAGE value ( homepage is now CPAN ) 3. A whole bunch of EAPI5 migration :/
eprefixify options fixed.
HOMEPAGE fixed. Changes to make this ebuild EAPI5-compliant seem to have been already performed as well as version normalisation. I believe we can close this bug now.