Re: RFS nuitka
Hello Yaroslav,
thanks for the review, really helpful. I tried to address all the
problems and have uploaded another package.
You wrote:
1. version
0.3.17pre2-1
if 'pre' means prior 0.3.17, then make it 0.3.17~pre2-1 otherwise
it would sort after (use dpkg --compare-versions in cmdline if you want
to check for sure how versions get sorted)
Changed in last upload "0.3.17~pre3+dfsg-1".
2. debian/copyright
a. separate main copyright statement into separate paragraph (separated
with empty line) with
Files: *
Done.
b. nuitka/build/static_src/arm_ucontext_src/getcontext.asm
you should copy that MIT style license verbatim into debian/copyright
and also that file contains 1 more copyright/license for some snippets
in the code of that file
Done.
3. debian/patches/remove-inline-scons
removing scons with patch like this is not quite the right way... two
possibilities
i. don't remove scons but just (minimalistic patch) make system wide
used
then you would need still to add its copyright/license into
debian/copyright, just add a comment that those are not used
The system wide is used by default as upstream, but I don't like the
idea of having dead code floating around, and a potentially hard test,
if it's really dead. So I went with:
ii (somewhat preferable). remove scons from within .orig.tar.gz
(optionally add +dfsg or .dfsg suffix to the version making it
0.3.17~pre2+dfsg-1)
Done that. Although it was kind of hurtful to integrate. :-) Is there
really nobody who has a tool to take upstream tars and remove files from
it? For starters "tar --delete" hates to work on compressed archives...
4. go through the output of licensecheck -r --copyright .
and fill entries for them in debian/copyright: e.g. I find things like
./tests/benchmarks/pybench/pybench.py: UNKNOWN
[Copyright: , 2000-2006, eGenix.com Software GmbH (info@egenix.com) / , 1997-2006, Marc-Andre Lemburg (mal@lemburg.com) / assignment to the code, or in the]
I removed the benchmarks, as they are not useful at all, and people need
not get them via Nuitka too. I am making now sure that no "UNKNOWN"
licenses occur, and added more entries to "debian/copyright" as well as
adding missing copyright notices.
That was a lot of work, but I believe it's now good. It's a pity that
the tool seems to not integrate with "debian/copyright" file.
5. you do have unittests, why don't excercize them during build time
(override_dh_auto_test)? that would assure that it functions correctly
across releases (and architectures if anyone rebuilds it there ;) )
I have added it. They are now run at build time.
sorry -- now family time
otherwise FWIW package seems to build nicely across most of recent
debian/ubuntu releases:
nuitka_0.3.17pre2-1~nd50+1_amd64.build FAILED 0:10.87 real, 3.24 user, 2.25 sys, 55704 out
nuitka_0.3.17pre2-1~nd60+1_amd64.build OK 0:35.42 real, 19.53 user, 9.62 sys, 220960 out
nuitka_0.3.17pre2-1~nd70+1_amd64.build OK 0:40.50 real, 24.46 user, 10.47 sys, 326920 out
nuitka_0.3.17pre2-1~nd+1_amd64.build OK 0:40.20 real, 24.28 user, 10.22 sys, 325848 out
nuitka_0.3.17pre2-1~nd10.10+1_amd64.build FAILED 0:14.55 real, 5.64 user, 3.40 sys, 94560 out
nuitka_0.3.17pre2-1~nd11.04+1_amd64.build OK 0:59.51 real, 35.69 user, 16.09 sys, 211232 out
nuitka_0.3.17pre2-1~nd11.10+1_amd64.build OK 0:50.39 real, 30.28 user, 14.37 sys, 369608 out
Actually I believe that Squeeze (6.x) is not supposed to work. And also
Ubuntu 11.04 isn't, although with lesser certainty. They won't work due
to missing dependencies I b lieve.
Maybe it is because Nuitka was not run as part of the build process yet.
The control file is having:
Build-Depends: debhelper (>= 7.4.3), python (>= 2.6.6-3)
Depends: g++-4.6 (>= 4.6.1), scons (>=2.0.1), ${misc:Depends},
${python:Depends}
I was thinking that the run time dependency would also be checked at
build time. And now I believe, that the new package will fail for you
due to that, so I added them for the next upload.
Is there a generic way to achieve that? I mean other than to copy them
to both? For now I copied them over (it's only 2), but I am curious if
there is a better way.
Thanks again,
Kay Hayen
Reply to: