Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=588941 --- Comment #32 from Dave Malcolm <dmalcolm@xxxxxxxxxx> 2010-12-16 20:45:39 EST --- (In reply to comment #11) ... > 1) License tag is better. dmalcolm: I found the list of licenses that had > been included in the spec file present in the LICENSE file. If that's where > you got the original list from then the license tag should now be correct. I > was able to remove LGPL and Distributable because those were coming from > bundled jar files. I removed the bundled jars (see below) so that should now > be fine. The LICENSE file is indeed where I got that list from. I haven't yet gone through the full tarball payload. > 4) The build isn't make driven but I didn't look at parallelizing it. The compilation phase invokes a Makefile; on my machine it used "-j 4", and in one of the Koji scratch builds it used "-j 10" It appears to come from this code in pypy-1.4/pypy/translator/c/genc.py:compile: > if self.config.translation.make_jobs != 1: > extra_opts += ['-j', str(self.config.translation.make_jobs)] which in turn is intialized in this code in pypy-1.4/pypy/config/translationoption.py: cmdline="--make-jobs", default=detect_number_of_processors()), Hopefully that's good enough for our build system. It's actually visible in the built binary, FWIW: > $ ./pypy --info|grep make_jobs > translation.make_jobs: 4 Unfortunately that parallelizable phase is only a small fraction of the build time (see "compile_c" below); from the x86_64 scratch build's log: [Timer] Timings: [Timer] annotate --- 780.8 s [Timer] rtype_lltype --- 491.7 s [Timer] pyjitpl_lltype --- 712.2 s [Timer] backendopt_lltype --- 202.3 s [Timer] stackcheckinsertion_lltype --- 21.6 s [Timer] database_c --- 243.8 s [Timer] source_c --- 477.3 s [Timer] compile_c --- 148.4 s [Timer] =========================================== [Timer] Total: --- 3078.2 s real 52m21.339s user 49m43.905s sys 0m3.552s so roughly 15% of that build time benefited from the 10 cores on that machine (presumably, would have been ~1480 seconds otherwise, so that at least is a significant saving). As I understand it, parallelizing the rest of the build would involve major rewrites (it's all in one big cpython process) > 5) rpmlint c): Yeah, it's because it's named -libs. Another possible name is > -stdlib since it is the python stdlib(for pypy). Did moving to versioned requirements fix this? > 5e) I was waiting for the koji build to complete to see if this is still an > issue with 1.4. Seems to have been fixed, either in 1.4, or in Toshio's work on the specfile. > 5f) dmalcolm, what did we decide to do with this on the python and python3 > packages? I've copied a fixer-upper from the python3 specfile in my 1.4-4 pypy.spec > Other: > * Removed bundled jar files. Pre-built files are not allowed. It looks like > these were present in case we were building a pypy that targets the jvm (rather > than POSIX-C). Simple removal should be fine until/unless we want to enable > that backend. If we do enable that, one of the jar files is packaged for BTW, I considered building that one. The impression I get is that the JVM backend isn't as mature as the .c backend, so it seems simplest to omit it for now. (fijal: do you have any advice/guidance on this?) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review