Bugzilla Bug 129571

the summary says that all ... just another "non-interactivity broken on default
config" issue ...

if setarch replaces linux32 and it is impossible to have them both, all the
packages dependant on linux32 should be fixed to depend on setarch BEFORE
setarch was added into profiles/default-linux/amd64/packages

btw, what is the reason of adding setarch to system, does it break without it?
- I guess no, so IMHO it should remain as a dependency for the apps that
actually use it (what if I have pure 64bit system, then why I would need to
"change reported architecture"?)

I have found two affected packages: dev-util/catalyst and www-client/opera

guys, I do not want to be too much critical (since as a professional tester I
know that it is hard to catch it all) but sometimes I have a feeling that the
QA team has fallen asleep ... please do not take me bad, I appreciate the
developers' work, but I feel that there are some problems - on the other hand,
I do not think that they are so serious that they would require more care (from
my side) than just this note

setarch replaces sys-apps/linux32, calm down a bit...

is there really a good reason to block linux32 from setarch? can't they just
co-exist at least for now.

alright, I'm an idiot, forget that

The two packages (catalyst and opera) should be fixed to depend on setarch
instead of linux32 (if possible).

Please CC the appropriate team(s) when doing this sort of thing.  This
defintely would have gotten reverted on the next catalyst bump had I not just
*happened* to notice blubb making this change to catalyst.

all the relevant teams were covered in Bug 123526

catalyst/opera slipped through the cracks, not a big deal

> btw, what is the reason of adding setarch to system, does it break without it?
> - I guess no, so IMHO it should remain as a dependency for the apps that
> actually use it (what if I have pure 64bit system, then why I would need to
> "change reported architecture"?)

it wasn't really added, it just replaced linux32. question remains though.

> I have found two affected packages: dev-util/catalyst and www-client/opera

I checked the tree, they are the only two who explicitly depend on linux32.
they are fixed now. checked the tree for the rest of the deprecated packages,
only one affected seems to be sparc-utils which deps on sparc32

> guys, I do not want to be too much critical (since as a professional tester I
> know that it is hard to catch it all) but sometimes I have a feeling that the
> QA team has fallen asleep ... please do not take me bad, I appreciate the
> developers' work, but I feel that there are some problems - on the other hand,
> I do not think that they are so serious that they would require more care (from
> my side) than just this note

I would understand this complaint if the tree was broken for days or weeks
already, but you filed the bug a few hours after it popped up and it was fixed
a fter a bit more than 12 hours. Sure, it shouldn't have happened at all, but
errors do happen.

(In reply to comment #7)
> > btw, what is the reason of adding setarch to system, does it break without it?
> > - I guess no, so IMHO it should remain as a dependency for the apps that
> > actually use it (what if I have pure 64bit system, then why I would need to
> > "change reported architecture"?)
> 
> it wasn't really added, it just replaced linux32. question remains though.
> 
> > I have found two affected packages: dev-util/catalyst and www-client/opera
> 
> I checked the tree, they are the only two who explicitly depend on linux32.
> they are fixed now. checked the tree for the rest of the deprecated packages,
> only one affected seems to be sparc-utils which deps on sparc32
> 
> > guys, I do not want to be too much critical (since as a professional tester I
> > know that it is hard to catch it all) but sometimes I have a feeling that the
> > QA team has fallen asleep ... please do not take me bad, I appreciate the
> > developers' work, but I feel that there are some problems - on the other hand,
> > I do not think that they are so serious that they would require more care (from
> > my side) than just this note
> 
> I would understand this complaint if the tree was broken for days or weeks
> already, but you filed the bug a few hours after it popped up and it was fixed
> a fter a bit more than 12 hours. Sure, it shouldn't have happened at all, but
> errors do happen.
> 

Hi,

You mentioned "sparc-utils which deps on sparc32" <G>  Yes, I am having this
issue on my Sparc boxes.  My I choose to ignore the dependency issues for a
short period of time?  Are they working on the "sparc-utils which deps on
sparc32" also?

Thanks for your time.

It's already fixed:

*sparc-utils-1.9-r3 (11 Apr 2006)

  11 Apr 2006; Gustavo Zacarias <gustavoz@gentoo.org>
  -sparc-utils-1.9-r2.ebuild, +sparc-utils-1.9-r3.ebuild:
  Don't force CFLAGS and switch to setarch, thanks to spanky for noticing

so just resyncing will fix it

(In reply to comment #9)
> It's already fixed:
> 
> *sparc-utils-1.9-r3 (11 Apr 2006)
> 
>   11 Apr 2006; Gustavo Zacarias <gustavoz@gentoo.org>
>   -sparc-utils-1.9-r2.ebuild, +sparc-utils-1.9-r3.ebuild:
>   Don't force CFLAGS and switch to setarch, thanks to spanky for noticing
> 
> so just resyncing will fix it
> 

Thank you (again).  You guys are GREAT...