Repoman does not have the capability to check dependencies for arches other than the one repoman is being run from. This results in commits being able to have broken dependencies for stable and/or unstable ebuilds on other arches. Reproducible: Always Steps to Reproduce: 1. 2. 3.
re-assigning to puggy as he is the main repoman guy now.
can this be fixed ASAP. we continually have problems with devs not paying enough attention to the status of keywords in ebuilds that cause borkages, and i'd rather not have to go yell at them all the time.
agree with weeve, that would save us non x86 devs from a lot of headaches
puggy -- we need to pay attention to this bug with some seriousness. rest of portage team --- anything you all can do?
yeah, just told one of my soon-to-be amd64 guys about that caveat today. how ironic. But it's dealable with amd64, I could see it being a PITA if you used an old slow sparc or something though. -Brad
ehh, is this the same as the bug in which Repoman treats packages lacking an arch keyword of the arch repoman is run on as bad depends? That is, I run repo from my sparc box (500MHz Blade 100), and if the package I'm trying to commit has dependencies which have either ~sparc or lack the sparc keyword at all, then repoman flags them as DEPEND.bad, and prohibits me from committing the package.
uhh, is it me, or is what kumba said what it's supposed to do. It's not supposed to let you submit a package if deps have no keywords, or have the ~arch flag and you're marking the current package stable. Err, feature vs bug. -Brad
I mean, in some cases, I'll goto commit a package on my sparc box for mips (say I added a mips keyword or something). But repoman blocks me because there's some binutils version blocking me because that binutils doesn't have sparc? (maybe it has ~sparc instead) What I'm saying is repoman shouldn't care about architechture it's running on. The host arch should not influence how repoman makes a decision on a bad dependency or not, whether I run repo on sparc64 or x86 or mips. I just happened to use my sparc64 box cause it's reasonably quick, and isn't directly exposed to the internet like my x86 (except it does run apache), so repoman should ignore this when comparing dependencies and not block me since a dependency of some package lacks stable sparc keywords.
yes, that's the bug we're talking about. Your first comment didn't seem like you meant from a different arch ;) -Brad
any progress on this ?
Can something please be done about this? Is someone working on this (if so can they comment on status)? If not what's the plan for getting it in there? This is a pain us non-x86 arch people feel on a daily basis, and NOT checking this is really bad QA.
I've implemented this. (I think we need to handle /etc/make.profile correctly in repoman) Can anyone test it, please?
Created attachment 21808 [details, diff] patch against repoman
Traceback (most recent call last): File "/usr/bin/repoman", line 155, in ? repoman_settings = portage.config(clone=portage.settings) TypeError: __init__() got an unexpected keyword argument 'clone'
Created attachment 21811 [details, diff] patch against repoman in portage-2.0.49-r18 the previous patch is against cvs version.
Created attachment 21812 [details, diff] patch against repoman in portage-2.0.49-r18 I forgot regarding -arch.
in cvs.
This is looking good to me. However, there does seem to be at least one behavioral problem, though I think it's on regular repoman's end. I have the patched repoman on an x86 box, and regular repoman from portage-2.0.49-r18 on sparc64. x86 repoman picks up the fact that app-admin/amanda depends on xfsdump, and that xfsdump does not have any sparc keywords. repoman on the sparc64 host does not see this. (Note: sparc64 uses the sparc keyword for ebuilds). xfsdump does not appear to be masked in package.mask or in the default-sparc64-1.4 profile as well as the profile's use.mask. If I do a pretend emerge with the command USE="xfs" emerge -pv amanda, this will show the broken dependency. xfsdump and the xfs use flag should be masked on sparc as it does not have xfs support in any kernels (for the QA conscious). I'll keep looking around and report back if I find anything else.
Created attachment 21954 [details, diff] patch against repoman in -r15/18
Created attachment 21955 [details, diff] patch against portage.py in -r15/18 fixed a problem which couldn't handling !ppc? style in DEPEND/RDEPEND
i'm using this since 2 days. i'm not really able to commit anything into cvs, cause there are a lot of things broken (in every arch) portage works perfect, but the dependencies are mostly bad for one arch. this means there's a lot of QA work to do
One thing I have noticed with this patch is that virtuals don't seem to get properly checked on other arches. Not sure if this is something easily fixable or not.
Also if support for each profile's use.mask could be included that would be great (currently doesn't seem to be doing that).
right, virtuals are not working correct for other archs
Yep, I also noticed the virtual problem. I'm working on it. I'll fix it in next release.
I fixed these problems in cvs. I think they would be in .50_pre3 or .50.
paul please submit your issues here
Currently (50_pre3) repoman does check, but a bit too rigorously. There are packages (like sys-libs/db) that use for example java. As db is a system package allmost all architectures support it. The package also includes java bindings that can optionally be build using the java use flag. However virtual/jdk is not available on all archs. That should not really be a problem as in that case it obviously makes no sense to set the USE flag. When java becomes available (or is hand-compiled, whatever) it should not be necessary to edit all ebuilds to support java. What this means to me is that it someway must be possible for repoman to give the ok without needing to make actual architecture dependend conditions in the ebuilds. (it would be ok to have a condition like: virtual/jdk? ( java? ( virtual/jdk ) ) Where "virtual/jdk?" would check on the availability of that package. Or some masking per architecture is also ok, but something along the lines of: "!ia64? ( !ppc64? ( !mips? ( !arm? ( java? ( virtual/jdk ) ) ) ) )" is both ugly and unportable (if an arch starts to support java, all ebuilds need to be edited)
Thank you for feedback :) I think we can use use.mask in the case. What do you think?
DEPEND.badindev 2 media-libs/freetype/freetype-2.1.5.ebuild: ppc64 ['virtual/glibc'] media-libs/libungif/libungif-4.1.0.1b.ebuild: ppc64 ['virtual/x11'] seems that ppc64 doesn't have virtuals portage version 2.0.50_pre3
Another thing that I think can be added to this bug. Repoman takes /etc/portage/package.mask into account. Obviously this is not wanted, as that is local configuration.
supposed to be fixed in 2.0.50 which is stable now. If this bug is not fixed please reopen.
