Hi, I raised https://bugs.merproject.org/show_bug.cgi?id=98 while looking at some build issues we are having in OBS ( https://bugs.merproject.org/show_bug.cgi?id=34) so we would welcome the work you have done on 2.7 as I think the issue has been fixed upstream. Could you link to your Python 2.7 OBS project?
I'll let Carsten answer your other points as I know there has been discussion on how to track upstream and also on Mer a tool repo which is free from legacy MeeGo. I hope we can answer your concerns and get you on the road to contributing fully BR vgrade On Wed, Jan 11, 2012 at 10:07 PM, letters.random13 < [email protected]> wrote: > hello, > > thanks for your work on mer/nemo. > > as a new potential contributor i have a several questions that would > probably be better in the wiki ( > http://wiki.merproject.org/wiki/Contribution_in_detail), but of course i > don't have the answers: > > (1) any chance of valid ssl certs for mer/nemo websites? > i use https-everywhere, so from (https)://bugs.nemomobile.org i receive: > This Connection is Untrusted > > bugs.nemomobile.org uses an invalid security certificate. > > The certificate is not trusted because no issuer chain was provided. > > (Error code: sec_error_unknown_issuer) > > (2) is there a standard regarding tracking the latest version of upstream > projects versus retaining meego(?) versions / compatibility?? > > example: > bugs.merproject.org/show_bug.cgi?id=70 > "e2fsprogs should be upgraded to 1.42" > > is this based purely on contributor/maintainer interest or is there some > other (automated?) procedure? > > some upgrade-able packages aren't listed in bugs. > > e.g., libffi is presently 3.0.9, but: > This update to libffi 3.0.10 includes a critical bug fix for ARM > targets.(!) > > this upgrade is trivial (i've packaged it on obs), subject to the > following mer repo issues... > > (3) packaging: how to handle the redundancy of maintaining a package with > spectacle (yaml file, etc.) versus rpm (spec) file? > > mer:tools:testing includes spectacle, but the repositories are drifting > toward obsolescence (Fedora_14, Ubuntu_10.10) (on my desktop machines, at > least). > > i would rather just manually update the libffi rpm spec file, and never > deal with spectacle. should i just delete the redundant yaml file (& any > other related files) from the package? otherwise the unmodified yaml file & > thus the new package will be broken. > > (4) other valuable packages are also drifting toward obsolescence (or were > nearly that way when meego branched them). > > in Mer:Trunk:Base, > python 2.6.4 saw minimal cherry-picked security-related patches from the > time meego branched it (from Fedora 14, i think), and the maintainer > certainly didn't attempt to track important fedora patches (see e.g., > https://bugs.meego.com/show_bug.cgi?id=22784) > > the current fedora version 2.7.2 package has quite a bit of cruft; i > wouldn't even think about rebasing on it. > an alternative is to just grab the upstream python.org source & package > it (which i have done on obs). > > does py2.6 need to be retained, thus making py2.7 an alternate python? > in meego it would have been placed in an alternate location like: > %global _prefix /opt/org.python.python%{pybasever} > > (this likely requires a few tedious patches). > > or, should the new py2.7 just replace the unmaintained py2.6? > > (5) the python source comes with a large, but not perfect, test package. > this was ignored in the meego rpmbuild. does mer have a standard > (required? optional?) regarding running the test suite (and/or requiring it > to succeed) during rpmbuild packaging? if so, test pass/fail (and thus > rpmbuild success) will likely depend on the build arch. is there some > standard procedure for this in mer? > > an example of the current, tedious spec file hack is: > > %ifarch %{ix86} > > EXCLUDED_TESTS=" \ > test_file \ > test_file2k \ > test_ioctl \ > %{nil}" > > %endif > > where the list is generated manually, via repeated build attempts in obs. > > thanks in advance for any clarification. > >
