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.
