Re: RFS nuitka
On Tue, 03 Jan 2012, Kay Hayen wrote: > >* custom get-orig-source rule in debian/rules -- most popular way to > > automate things of this kind ;) > That's just where to put it, not what to put there? yeap... "what" could indeed be either a call to dh_wraporig or just a tandem of two tar commands (one to extract, another one to compress again with a set of --exclude options). N.B. I am somewhat surprised that tar itself doesn't have an option to filter a tar archive applying --exclude to a stream from STDIO > Yeah yeah. :-) > I had installed the "pbuilder" stuff and things, but honestly, > normally I don't see much point, once it will be working again. > Mostly because the binary package contains no binaries and the tame > dependencies. ;-) you would be surprised ... there is dozen of reasons not to mention that some (e.g. me) make it a requirement for sponsored uploads... here is few: - since upload happens to debian sid (AKA unstable) it might have newer versions that what you have on your system, thus building in an up-to-date sid chroot would be beneficial to spot fresh incompatibilities/problems earlier than later - building in a clean environment also provides better assurance that package would build for anyone trying to build it later on > And I even predicted it, but couldn't fix it anymore. I knew it was > flawed, but "mentors.debian.net" won't let me upload any "-2" ever, > presumably due to the changed "orig" source. yeap -- .orig for a given "upstream" version, once uploaded must not change ;-), thus shouldn't even be uploaded in general for -2, -3, ... debian revisions. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102235824.gs16...@onerussian.com
Re: RFS nuitka
Hello Yaroslav,
you wrote:
* once I had wrote a little helper for myself
http://anonscm.debian.org/viewvc/pkg-exppsy/tools/dh_wraporig?view=markup
which I had used for many cases like this, it was also autogenerating
README.Debian-source
which summarized the changes
That looks interesting, I will try it if the outcome is that a repacking
still is what I should do.
* custom get-orig-source rule in debian/rules -- most popular way to
automate things of this kind ;)
That's just where to put it, not what to put there?
since you are using git, you might also like simply to tune up
.gitattributes to exclude undesired pieces from the generated by git
archive tarball
I am using "distutils" to provide the "sdist" and not git. That has the
advantage to provide other targets as well. I think that idea is also
from a tutorial of the team somehow, as dh_python2 uses it too.
I think so too... meanwhile, here
http://www.onerussian.com/tmp/nuitka-logs.tgz
fetch build logs for your most recent package (fails everywhere
now -- thanks to tests ;) )
it would be great if for every upload you verify that package builds
fine in a clean chroot ;-)
Yeah yeah. :-)
I had installed the "pbuilder" stuff and things, but honestly, normally
I don't see much point, once it will be working again. Mostly because
the binary package contains no binaries and the tame dependencies.
And I even predicted it, but couldn't fix it anymore. I knew it was
flawed, but "mentors.debian.net" won't let me upload any "-2" ever,
presumably due to the changed "orig" source.
I might make a new "pre4" minor release later today with it included,
once I understood what to do with the "+dfsg" suffix. Changing that
suffix may also be enough I figured.
AFAIK (would be great if someone corrects me) -- besides some
somewhat over-engineered ways to generate debian/control from
debian/control.in or smth like that, there is no good way, so specifying
them both in depends and build-depends is what I have been doing.
OK, I just didn't want to miss it if there was an easy way. I saw things
like "${misc:Depends}" and thought there could be a way to express it.
But it's totally not worth it with only 2 of them.
Yours,
Kay
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f023f23.6050...@gmx.de
Re: RFS nuitka
On Mon, 02 Jan 2012, Kay Hayen wrote:
> >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...
well, AFAIK there is no standard tool but there is plenty of crafty ways
* git-import-orig (from git-buildpackage) has options to specify which
ones to prune while importing a new upstream tarball (so it is not
preferable way for you since you are upstream ;-) )
* once I had wrote a little helper for myself
http://anonscm.debian.org/viewvc/pkg-exppsy/tools/dh_wraporig?view=markup
which I had used for many cases like this, it was also autogenerating
README.Debian-source
which summarized the changes
* custom get-orig-source rule in debian/rules -- most popular way to
automate things of this kind ;)
since you are using git, you might also like simply to tune up
.gitattributes to exclude undesired pieces from the generated by git
archive tarball
> 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.
the structure of it wasn't standardized before so it was nearly
impossible... now with DEP-5 something like that could be done and I
believe there were some recent discussions
> >across releases (and architectures if anyone rebuilds it there ;) )
> I have added it. They are now run at build time.
> >>...<
> 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.
I think so too... meanwhile, here
http://www.onerussian.com/tmp/nuitka-logs.tgz
fetch build logs for your most recent package (fails everywhere
now -- thanks to tests ;) )
it would be great if for every upload you verify that package builds
fine in a clean chroot ;-)
> 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.
AFAIK (would be great if someone corrects me) -- besides some
somewhat over-engineered ways to generate debian/control from
debian/control.in or smth like that, there is no good way, so specifying
them both in depends and build-depends is what I have been doing.
--
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120102213417.gr16...@onerussian.com
Re: RFS nuitka
* Yaroslav Halchenko , 2012-01-02, 15:49: to bloat .orig.tar.gz if there is an easy way to avoid it, while also making 100%-proof that contained copy of 3rd party code is used instead of system-wide one. You can "rm -rf" it early in the build process to assure that. E.g., if you use dh, override_dh_auto_configure is a convenient place. :) an evil act ;) iirc that would also trigger a lengthy list of warnings from dpkg-source if it happens to run 2nd time within the source tree, or am I mixing it up? That's right. Fortunately, you can make dpkg-source shut up by adding appropriate extend-diff-ignore to debian/source/options. what is ds standa for btw? debian source? Yes. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102212633.ga9...@jwilk.net
Re: RFS nuitka
On Mon, 02 Jan 2012, Jakub Wilk wrote: > >to bloat .orig.tar.gz if there is an easy way to avoid it, while > >also making 100%-proof that contained copy of 3rd party code is > >used instead of system-wide one. > You can "rm -rf" it early in the build process to assure that. E.g., > if you use dh, override_dh_auto_configure is a convenient place. :) an evil act ;) iirc that would also trigger a lengthy list of warnings from dpkg-source if it happens to run 2nd time within the source tree, or am I mixing it up? > >another aspect, as I hinted, if 3rd party pieces are shipped, > >their license/copyright must be listed in debian/copyright -- that > >might extend it considerably for no good reason... > I didn't look at nuitka (recently), but d/copyright for scons in the > archive is very simple, so I don't expect the cost to be high. atm may be yes... but then it would be needed for nuitka maintainer to monitor also scons current state regardless copyrights/licenses to assure debian/copyright being up-to-date. so imho it might be somewhat of a burden for no good reason > >myself. Well, ok -- for some I did stopped carrying +dfsg -- eh, > >inconsistent me ;) > >do we have another commonly used suffix for such cases? > I believe that +ds suffix is quite popular. See also bug #499167 not surprising that I have missed it -- only a few packages installed on my laptop have +ds or +debian (especially in contrast to +dsfg)... here is a quick look at winners of '+SUFFIX': 4 bzr 4 doc 5 l 5 repack 7 debian 8 cvs 9 ds 17 nmu 28 git 39 svn 129 dfsg 340 b what is ds standa for btw? debian source? > >or should no suffix being added at all and just > >debian/README.Debian (or debian/README.Debian-source) mention > >repackaging? > Repacking should be documented somewhere regardless of whether a > special suffix is used or not. Unfortunately, Policy and Developer's > Reference disagree on which file should be used for this purpose > (d/README.source or d/copyright). See bug #561494. thanks for the pointer... I usually used debian/README.Debian-source -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102204944.gq16...@onerussian.com
Re: RFS nuitka
* Yaroslav Halchenko , 2012-01-02, 15:15: 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 ii (somewhat preferable). remove scons from within .orig.tar.gz I disagree that (ii) is preferable. You should not repack upstream source unless you have to. (Please see ftp-master's reject FAQ.) (somewhat) agree -- in general there should be no repackaging, unless the trade-off with archive size/clarity kicks in. i.e. why to bloat .orig.tar.gz if there is an easy way to avoid it, while also making 100%-proof that contained copy of 3rd party code is used instead of system-wide one. You can "rm -rf" it early in the build process to assure that. E.g., if you use dh, override_dh_auto_configure is a convenient place. :) another aspect, as I hinted, if 3rd party pieces are shipped, their license/copyright must be listed in debian/copyright -- that might extend it considerably for no good reason... I didn't look at nuitka (recently), but d/copyright for scons in the archive is very simple, so I don't expect the cost to be high. not sure if just a referral to copyright file of the corresponding package would be appropriate. I don't think it would be appropriate. (optionally add +dfsg or .dfsg suffix to the version making it 0.3.17~pre2+dfsg-1) Since the software would be repackaged for reasons that are unrelated to DFSG compliance, the "dfsg" suffix would be incorrect/confusing. yeah -- agreed... shame on me though that I did use it this way many times just to hint on having upstream tarball repacked -- I did feel that it is inappropriate but just didn't listen to myself. Well, ok -- for some I did stopped carrying +dfsg -- eh, inconsistent me ;) do we have another commonly used suffix for such cases? I believe that +ds suffix is quite popular. See also bug #499167 or should no suffix being added at all and just debian/README.Debian (or debian/README.Debian-source) mention repackaging? Repacking should be documented somewhere regardless of whether a special suffix is used or not. Unfortunately, Policy and Developer's Reference disagree on which file should be used for this purpose (d/README.source or d/copyright). See bug #561494. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102203358.ga6...@jwilk.net
Re: RFS nuitka
Hello Jakub, you wrote: ii (somewhat preferable). remove scons from within .orig.tar.gz I disagree that (ii) is preferable. You should not repack upstream source unless you have to. (Please see ftp-master's reject FAQ.) Thanks for the pointer, I looked at it. (optionally add +dfsg or .dfsg suffix to the version making it 0.3.17~pre2+dfsg-1) Since the software would be repackaged for reasons that are unrelated to DFSG compliance, the "dfsg" suffix would be incorrect/confusing. I have added the removal of "tests/benchmarks" as well, for which I as an upstream, would accept non-DFSG material as well. There is none of it in there at this time though. So yes, Nuitka as upstream is 100% clear to DFSG. Should I change things back to patches then? These removals may get huge. Imagine e.g. that I include Shedskin tests or even dare include the whole CPython tests (once Nuitka is itself PSF too). Or, probably another way, can I, as an upstream, provide 2 forms of tarballs, one for packaging and one for everybody else with more stuff like the scons inline copy and benchmarks and extended tests from 3rd parties already contained? I saw the issue being rated as: Minor issues, sometimes also named "Good packaging behavior". Not a single one is enough to get you a REJECT, but if you collect multiple ones the probability rises So, please advise. Like I said, I try to be a "good upstream" :-) Thanks, Kay -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f02142e.9040...@gmx.de
Re: RFS nuitka
On Mon, 02 Jan 2012, Jakub Wilk wrote: > >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 > >ii (somewhat preferable). remove scons from within .orig.tar.gz > I disagree that (ii) is preferable. You should not repack upstream > source unless you have to. (Please see ftp-master's reject FAQ.) (somewhat) agree -- in general there should be no repackaging, unless the trade-off with archive size/clarity kicks in. i.e. why to bloat .orig.tar.gz if there is an easy way to avoid it, while also making 100%-proof that contained copy of 3rd party code is used instead of system-wide one. another aspect, as I hinted, if 3rd party pieces are shipped, their license/copyright must be listed in debian/copyright -- that might extend it considerably for no good reason... not sure if just a referral to copyright file of the corresponding package would be appropriate. > >(optionally add +dfsg or .dfsg suffix to the version making it > >0.3.17~pre2+dfsg-1) > Since the software would be repackaged for reasons that are > unrelated to DFSG compliance, the "dfsg" suffix would be > incorrect/confusing. yeah -- agreed... shame on me though that I did use it this way many times just to hint on having upstream tarball repacked -- I did feel that it is inappropriate but just didn't listen to myself. Well, ok -- for some I did stopped carrying +dfsg -- eh, inconsistent me ;) do we have another commonly used suffix for such cases? or should no suffix being added at all and just debian/README.Debian (or debian/README.Debian-source) mention repackaging? -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102201501.gp16...@onerussian.com
Re: RFS nuitka
* Yaroslav Halchenko , 2012-01-01, 18:33: 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 ii (somewhat preferable). remove scons from within .orig.tar.gz I disagree that (ii) is preferable. You should not repack upstream source unless you have to. (Please see ftp-master's reject FAQ.) (optionally add +dfsg or .dfsg suffix to the version making it 0.3.17~pre2+dfsg-1) Since the software would be repackaged for reasons that are unrelated to DFSG compliance, the "dfsg" suffix would be incorrect/confusing. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102200325.ga4...@jwilk.net
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 (i...@egenix.com) / ,
1997-2006, Marc-Andre Lemburg (m...@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.buildOK 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
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f020acc.2010...@gmx.de
Re: RFS nuitka
Happy New Year! so let's begin ;) 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) 2. debian/copyright a. separate main copyright statement into separate paragraph (separated with empty line) with Files: * 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 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 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) 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 (i...@egenix.com) / , 1997-2006, Marc-Andre Lemburg (m...@lemburg.com) / assignment to the code, or in the] 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 ;) ) sorry -- now family time otherwise FWIW package seems to build nicely across most of recent debian/ubuntu releases: nuitka_0.3.17pre2-1_amd64.build OK 0:39.27 real, 23.32 user, 11.13 sys, 337464 out 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.buildOK 0:40.20 real, 24.28 user, 10.22 sys, 325848 out nuitka_0.3.17pre2-1~nd08.04+1_amd64.build FAILED 0:13.14 real, 4.48 user, 3.13 sys, 63792 out nuitka_0.3.17pre2-1~nd09.10+1_amd64.build FAILED 0:13.52 real, 3.88 user, 3.03 sys, 69544 out nuitka_0.3.17pre2-1~nd10.04+1_amd64.build FAILED 0:19.92 real, 5.42 user, 4.86 sys, 83824 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 On Sat, 31 Dec 2011, Kay Hayen wrote: > Dear Debian Python Team, > I am out of review comments for the package of mine: > * Package name: nuitka >Version : 0.3.17pre2-1 >Upstream Author : Kay Hayen > * URL : http://nuitka.net > * License : GPLv3 >Section : python > It builds those binary packages: > nuitka - Python compiler with full language support and CPython > compatible > To access further information about this package, please visit the > following URL: > http://mentors.debian.net/package/nuitka > Alternatively, one can download the package with dget using this command: > dget -x > http://mentors.debian.net/debian/pool/main/n/nuitka/nuitka_0.3.17pre2-1.dsc > I would be glad if someone uploaded this package for me. I believe > it relatively is simple package. No real compile time dependencies. > Pure Python. Lintian clean. Closes an ITP bug, etc. > At Python compile time, it uses g++ and Scons, but without the user > noticing. Esp. Nuitka is not itself build with Scons, nor needs the > user use it, etc. There is a inline copy of Scons in Nuitka, which > is removed for Debian of course, and not in the binary build. > I am willing to be a "good" upstream, and have so far made all known > modifications to fit better into Debian. My intention is to become a > "Debian Maintainer" for this package. > Thanks in advance, > Kay Hayen -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012010125.gh16...@onerussian.com
RFS nuitka
Dear Debian Python Team, I am out of review comments for the package of mine: * Package name: nuitka Version : 0.3.17pre2-1 Upstream Author : Kay Hayen * URL : http://nuitka.net * License : GPLv3 Section : python It builds those binary packages: nuitka - Python compiler with full language support and CPython compatible To access further information about this package, please visit the following URL: http://mentors.debian.net/package/nuitka Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/nuitka/nuitka_0.3.17pre2-1.dsc I would be glad if someone uploaded this package for me. I believe it relatively is simple package. No real compile time dependencies. Pure Python. Lintian clean. Closes an ITP bug, etc. At Python compile time, it uses g++ and Scons, but without the user noticing. Esp. Nuitka is not itself build with Scons, nor needs the user use it, etc. There is a inline copy of Scons in Nuitka, which is removed for Debian of course, and not in the binary build. I am willing to be a "good" upstream, and have so far made all known modifications to fit better into Debian. My intention is to become a "Debian Maintainer" for this package. Thanks in advance, Kay Hayen -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4efedcdd.20...@gmx.de
