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...
