16. jan. 2012 05.11 skrev letters.random13 <[email protected]>: > thanks to everyone for the valuable answers, > > rather than embed responses in the long email, or start a new thread, here's > a summary w/ a couple follow-up questions: > > i added some info to MER#98 for python2.7, i'll try to update that to see if > spectacle will work, make it the primary instead of altinstall python, use > updated libffi, etc., etc. i think on meego there was an informal 'intent > to package' wiki page where one could find if anyone else was working on a > package, & maybe put some archival info. for mer would bugzilla comments be > the place to look? > I think for Mer the bugs open with severity=task would be the way to do it, as to be sure not to conflict with existing work. When working on something, mark yourself as assignee + ASSIGNED
I guess I could technically note the "ASSIGNED" task bugs in my weekly summary of tasks, to aid this awareness. > didn't quite understand the discussion regarding ifarch / > https://bugs.merproject.org/show_bug.cgi?id=86 > are you trying to avoid ifarch completely? maybe maintain completely > separate src pkgs for diff archs? So, the challenge is that we currently use %ifarch in order to disable running tests on certain architecture, because of the fact we build those architectures utilizing QEMU binary emulation. The other issue is that each time we add a new cross compiled architecture, we have to go around in each package and add another architecture in the ifarch wrapping "make check" However, to do proper QA, we should run the test cases on actual hardware as well, and currently they won't be done in a native build because of the ifarch issue. > > for python, the upstream pkg configure/make is pretty well maintained for > diff arches. i think that ix86 is probably much better tested than arm, so > the success of %check is definitely arch-dependent. for a first cut would > you rather have no %check so no %ifarch is required? If it fails under qemu builds we disable %check for those architectures but as said above, we'd like to move to a different method than ifarch > also, i was under the impression that ifarch would also work under obs > cross-compile building (subject to whatever bugs there are in the emulation > & obs & host). is this not the case? Your impression is right. > > > thanks again, > > dean > BR Carsten Munk
