Hi, 11. jan. 2012 23.07 skrev letters.random13 <[email protected]>: > 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) We haven't yet paid for "official" SSL certificates, it's in our plans but it is a significant cost to have. For now it's just a bit of an annoyance, but better than plaintext passwords flying over the wire.
> > (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? So, we try to have a tradition of that if you see something that needs to be done and you can't do it right away, you make a bugzilla severity='task' bug for it, in order to have something for new or other contributors to do. It's a good way of letting people get involved. We have a bug related to making this a bit more automated, https://bugs.merproject.org/show_bug.cgi?id=97 > > some upgrade-able packages aren't listed in bugs. If you can't find a package in bugs.* components, you place it in Other and we catch it in our weekly triage meetings and put it in the right spot :) We'll try to catch missing components as well, if you see some that's missing, file a bug against the infrastructure/bugzilla. > > e.g., libffi is presently 3.0.9, but: > This update to libffi 3.0.10 includes a critical bug fix for ARM targets.(!) That sounds like something we should upgrade, yes :) > > 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). Agreed, we need to have up to date packages for these essential tools and we've tried to catch these issues in the release management meetings. Personally I just git clone it and python setup.py install. There's some talk of providing these along with a platform SDK of sorts. > > 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. Okay, so, spectacle is in fact valuable and I'd encourage you to start learning and using it. Many were initially upset about it in MeeGo as well (Fedora packagers, typically) but they learnt to love it after a while as it really makes life as a packager and distribution maintainer a lot easier. I think the problem is the lack of documentation and explanations. A typical workflow for many is to edit the yaml and then run the 'specify' tool which updates the spec file. It makes upgrades trivially easy, or adding a patch. For me, making a new package takes a lot less time with spectacle. Because most software is very similar in what it needs for packaging. It also means that when someone comes back to the package half a year later, they can easily get into the packaging and do upgrades, etc, without having to figure out your specific way or style of packaging. For the customizations that are outside the yaml-generated spec template, there's handy 'template holes' (like << macros and >> macros) that you can add customizations in. Generally, if you have a yaml file in a package, submissions that remove it will be declined as you're making it difficult for anyone else coming after you to work with the package. YAML for new packages is not mandatory since it doesn't fit all scenarios for software, but it is recommended to do for simple packages. > > (4) other valuable packages are also drifting toward obsolescence (or were > nearly that way when meego branched them). We've been spending a lot of time to catch these, try to see http://review.merproject.org/ , All -> Merged. For the tools, we're doing an effort now to help package tools in a sane state - help much welcome as well. Spectacle, 'mic' comes to mind. > > in Mer:Trunk:Base, Don't use Mer:Trunk:Base, it's a leftover on COBS from a old copy of the Mer core. The correct reference is http://gitweb.merproject.org/gitweb and the Mer git repositories. If you need to branch from Mer latest release, the remote OBS project Mer:fake:Core:i586 can be used, as an example. > 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? We don't really do multiple versions of the same thing (Qt4.8 vs Qt5 may be an exception though), so if we do a Python2.7 upgrade, we replace the old one. > (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. Generally - yes, we should run test suites - they're a good, early way to catch issues. (To some extent, we don't want to run the full gcc test suite at each rebuild of gcc, as this would slow down full rebuilds a lot, but we should have a %if that allows us to enable it eventually) Now, the problem is that we do cross compilation for anything non-X86 and hence tests run under QEMU binary emulation. In truth, those are currently %ifnarch %{arm} for example, but instead, we want to move to doing something like described in https://bugs.merproject.org/show_bug.cgi?id=86 that determines it based on if we're running with QEMU binary emulation or not. The reason for this is that it's quite tedious to add another QEMU based architecture, like MIPS, to packages. And because we'd eventually like to run test cases on actual ARM/MIPS hardware. > > thanks in advance for any clarification. Great questions, if you have more, I'd be happy to answer :) BR Carsten Munk
