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
