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
Reply to: