Repoman seems to have problems detecting ebuilds that should satisfy ia64 (and possibly other) dependencies. An example is running repoman in app-admin/conserver. When I run repoman there on either x86 stable, sparc testing or sparc64 testing it complains that ia64 does not have a valid stable sys-libs/pam ebuild. However, after talking to agriffis and having him run repoman on an ia64, that does not show up. pam-0.75-r9 has a stable keyword, and app-admin/conserver's dependency on sys-libs/pam is not version dependent. ia64's profile also has a declaration for pam that should allow this version (packages:*>=sys-libs/pam-0.75-r9).
It works for me in my x86 box. Did you update profile dir in your cvs direcotry? If you did and the error happens now, can you show us the repoman error message?
Yeah, profiles dir is up to date. On the sparc64 box, I'm using a cvs co'd portage tree, whereas on the sparc and x86 boxes, I'm using a regularly emerge sync'd tree that is current as of 0700 GMT. The error repoman gives is like a normal broken dependency; excelsior conserver # repoman RepoMan scours the neighborhood... DEPEND.bad 1 app-admin/conserver/conserver-8.0.9.ebuild: ia64 ['sys-libs/pam'] RDEPEND.bad 1 app-admin/conserver/conserver-8.0.9.ebuild: ia64 ['sys-libs/pam']
Actually, it's not happening on x86, but it definitely happens on sparc. I jumped the gun there on x86 :-P
OK. I understand the problem. I'm fixing it.
Cool, what was it?
Fixed in CVS. Jason, repoman ignored some profile files on other arch.
Would be nice to see this fix go out asap. can you rev-bump portage to just push this repoman fix to stable portage please?
i'm using portage 2.0.51_pre13 and this bug still hits me... only in my case, i get dep errors for almost every arch other than my own. DEPEND.bad 1 sys-libs/libstdc++-v3/libstdc++-v3-3.3.3-r1.ebuild: ~mips ['>=sys-devel/binutils-2.14.90.0.6-r1'] sys-devel/binutils/binutils-2.14.90.0.6-r7.ebuild:KEYWORDS="amd64 ~x86 ~ppc ~alpha ~sparc ~mips ~hppa ~ia64" so the keyword is definately there... when i make /etc/make.profile point to a mips profile i get: RepoMan sez: "If everyone were like you, I'd be out of business!" the problem seems to be that it's looking at -my- current profile... gcc34-amd64-2004.1 masks versions of binutils under sys-devel/binutils-2.15.90.0.1.1-r1.
i cant use repoman without --ignore-other-arches, and as mr_bones will tell you this is a bad thing (tm).
I'm not sure if this is the cause. But can you remove the comment out around line 744 in /usr/lib/portage/bin/repoman and try repoman again? From: #portage.portdb=portage.portdbapi(portdir, dep_settings) To: portage.portdb=portage.portdbapi(portdir, dep_settings) genone: may i ask why you commented it out? If there is a bug about it, please tell me.
nakano: because with that line it requires several GB of RAM for a full scan (bug 56170) and I didn't see where it was supposed to be used.
It's used in the next line.
The line is needed to create profiles for each arches. I've also fixed bug 56170. The cause is that the profile caches are cleared in each packages.
yes and no. You assign it to arch_caches and get it back in the if statement, but it's not used anywhere as far as I can see. The only other reference to portage.portdb is way outside of that loop.
portage.portdb is used in many places in portage.py as global variable.
without editing repoman, i get: DEPEND.bad 1 sys-libs/libstdc++-v3/libstdc++-v3-3.3.3-r1.ebuild: ~mips ['>=sys-devel/binutils-2.14.90.0.6-r1'] with that line uncommented: DEPEND.bad 1 sys-libs/libstdc++-v3/libstdc++-v3-3.3.3-r1.ebuild: amd64 ['>=sys-devel/gcc-3.4*'] which makes more sense, because gcc 3.4 is masked in the default amd64 profile. different bug entirely... i wouldnt even be able to --ignore-other-arches to commit this, as it seems to ignore that i'm on amd64 and using an amd64 profile that doesnt mask gcc 3.4.... ok, lets try with gcc. with the line commented out: DEPEND.bad 3 sys-devel/gcc/gcc-3.4.1.ebuild: ~mips ['>=sys-devel/binutils-2.14.90.0.8-r1'] sys-devel/gcc/gcc-3.4.1.ebuild: ~hppa ['sys-libs/glibc'] sys-devel/gcc/gcc-3.4.0-r6.ebuild: ~mips ['>=sys-devel/binutils-2.14.90.0.8-r1'] RDEPEND.bad 1 sys-devel/gcc/gcc-3.4.1.ebuild: ~hppa ['sys-libs/glibc'] with the line uncommented: DEPEND.bad 2 sys-devel/gcc/gcc-3.3.3-r4.ebuild: arm ['>=sys-libs/glibc-2.3.3_pre20040207'] sys-devel/gcc/gcc-3.3.3-r3.ebuild: arm ['>=sys-libs/glibc-2.3.3_pre20040207'] RDEPEND.bad 2 sys-devel/gcc/gcc-3.3.3-r4.ebuild: arm ['>=sys-libs/glibc-2.3.3_pre20040207'] sys-devel/gcc/gcc-3.3.3-r3.ebuild: arm ['>=sys-libs/glibc-2.3.3_pre20040207'] DEPEND.badindev 8 sys-devel/gcc/gcc-3.3.3_pre20040130.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.3_pre20040408-r1.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.2-r5.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.3_pre20040215.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.2-r7.ebuild: ~ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.3.ebuild: ~ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.3-r3.ebuild: ~ppc64 ['sys-libs/glibc', '>=sys-libs/glibc-2.3.3_pre20040207'] sys-devel/gcc/gcc-3.3.3-r3.ebuild: s390 ['>=sys-libs/glibc-2.3.3_pre20040207'] RDEPEND.badindev 8 sys-devel/gcc/gcc-3.3.3_pre20040130.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.3_pre20040408-r1.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.2-r5.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.3_pre20040215.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.2-r7.ebuild: ~ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.3.ebuild: ~ppc64 ['sys-libs/glibc'] sys-devel/gcc/gcc-3.3.3-r3.ebuild: ~ppc64 ['sys-libs/glibc', '>=sys-libs/glibc-2.3.3_pre20040207'] sys-devel/gcc/gcc-3.3.3-r3.ebuild: s390 ['>=sys-libs/glibc-2.3.3_pre20040207' erm.... ok, something still doesnt seem quite right here. lets try binutils. with the line commented: DEPEND.bad 4 sys-devel/binutils/binutils-2.15.90.0.3-r3.ebuild: arm ['sys-libs/glibc'] sys-devel/binutils/binutils-2.15.90.0.3-r3.ebuild: ~ppc ['sys-libs/glibc'] sys-devel/binutils/binutils-2.15.90.0.1.1-r1.ebuild: ~hppa ['sys-libs/glibc'] sys-devel/binutils/binutils-2.15.90.0.1.1-r3.ebuild: ~ppc ['sys-libs/glibc'] RDEPEND.bad 4 sys-devel/binutils/binutils-2.15.90.0.3-r3.ebuild: arm ['sys-libs/glibc'] sys-devel/binutils/binutils-2.15.90.0.3-r3.ebuild: ~ppc ['sys-libs/glibc'] sys-devel/binutils/binutils-2.15.90.0.1.1-r1.ebuild: ~hppa ['sys-libs/glibc'] sys-devel/binutils/binutils-2.15.90.0.1.1-r3.ebuild: ~ppc ['sys-libs/glibc'] ebuild.allmasked 1 sys-devel/binutils uncommented: DEPEND.badindev 3 sys-devel/binutils/binutils-2.14.90.0.8-r1.ebuild: ~ppc64 ['sys-libs/glibc'] sys-devel/binutils/binutils-2.14.90.0.7-r4.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/binutils/binutils-2.14.90.0.8.ebuild: ~ppc64 ['sys-libs/glibc'] RDEPEND.badindev 3 sys-devel/binutils/binutils-2.14.90.0.8-r1.ebuild: ~ppc64 ['sys-libs/glibc'] sys-devel/binutils/binutils-2.14.90.0.7-r4.ebuild: ppc64 ['sys-libs/glibc'] sys-devel/binutils/binutils-2.14.90.0.8.ebuild: ~ppc64 ['sys-libs/glibc'] erm... ok, i seems to work as it 'should' with the line uncommented, but it also seems that this is wrong too...
oh yeah, it also didnt require large amounts of memory to do.
alright, with this line uncommented and profiles/profiles.desc updated, this bug can be closed. let me know when it's in a release so i can update to it. :)
OK. The code has been in cvs. It means it will be included in the next .51(pre).
strike that... just tried to do a repoman scan on the full cvs tree: ayanami portcvs # repoman scan > ../repo QA Notice: USE Flag 'python' not in IUSE for sys-apps/file-4.09 Traceback (most recent call last): File "/usr/bin/repoman", line 657, in ? myaux=portage.db["/"]["porttree"].dbapi.aux_get(catdir+"/"+y,allvars,strict=1) File "/usr/lib/portage/pym/portage.py", line 5159, in aux_get myret=doebuild(myebuild,"depend","/",self.mysettings,dbkey=mydbkey) File "/usr/lib/portage/pym/portage.py", line 2537, in doebuild retval = spawn(EBUILD_SH_BINARY+" depend",mysettings) File "/usr/lib/portage/pym/portage.py", line 1884, in spawn mypid=os.fork() OSError: [Errno 12] Cannot allocate memory
did you apply this patch? http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/bin/repoman?r1=1.69&r2=1.70&root=gentoo-src
all i did was uncomment that one line, i didnt apply a patch or move "arch_caches={}" around. i guess i should wait until the next portage release to test further, since i'm not using the cvs version of portage and i modified my repoman to not run xmllint since it causes repoman to hang 9 times out of 10. ignore me, i'll file another bug after the next release if this persists :) thankyou very much for the fix
This was released in pre15 iirc. Either way, it's in pre17.
