<div dir="ltr"><div><div>Testing with pbuilder-dist right now. Still fighting with some of the build dependencies, but Lintian also tells me about some broken links in the source repository, so I thought I might just as well report these right away:<br><br>E: pd-l2ork source: source-contains-unsafe-symlink externals/grill/trunk/flext/config.guess<br>E: pd-l2ork source: source-contains-unsafe-symlink externals/grill/trunk/flext/config.sub<br>E: pd-l2ork source: source-contains-unsafe-symlink externals/grill/trunk/flext/depcomp<br>E: pd-l2ork source: source-contains-unsafe-symlink externals/grill/trunk/flext/install-sh<br>E: pd-l2ork source: source-contains-unsafe-symlink externals/grill/trunk/flext/ltmain.sh<br>E: pd-l2ork source: source-contains-unsafe-symlink externals/grill/trunk/flext/missing<br><br></div>I'd remove these from the repository (AFAICT they're generated anyway).<br><br></div><div>Lintian also complains about these binaries in the repository:<br><br>E: pd-l2ork source: source-is-missing externals/postlude/pluginhost~/libpluginhost~.so<br>E: pd-l2ork source: source-is-missing doc/additional/pd-msg/3.pdscript/pdsend<br><br></div><div>These are surely generated as well, in any case they shouldn't be in the repository either.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 4:47 AM, Albert Graef <span dir="ltr"><<a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I just need an option to skip the packaging steps, so I added a -n option for that purpose to tar_em_up.sh now, see attached diff. It would be nice if you can commit this as well.<br><br></div>I already have some extra infrastructure to create the necessary source tarballs and run debuild to create the source and binary deb packages, this all works in an automatic fashion. Will post these later. The package builds fine now, I just need to test with pbuilder and then on Launchpad that it works in a pristine and chrooted build environment. Stay tuned.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">Albert<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 12, 2014 at 2:40 PM, Ivica Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">The final deb building is embedded in the line where we pass it install prefix which invokes one of the makefiles inside the packages sub-folder. This means that you will probably have to export a variable just like I do for the incremental building of the gem library ( building of gem in incremental builds is ignored because it takes so long). So, what I do is in the tar_em_up script I export a variable when incremental option is selected and then check for that variable inside of the Makefile located in the externals folder. We could amend the Makefile that does the building of the Deb package which is located in packages subfolder (either packages or packages/linux_make, can't remember which), and then check for the newly exported variable when using the proposed - L flag for launchpad and skip building of the Deb as well as moving of the file into a different folder. Please note that moving of the final deb file is IIRC performed at the end of tar_em_up script. HTH</p>
<div class="gmail_quote"><div><div>On Nov 12, 2014 8:25 AM, "Albert Graef" <<a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 12, 2014 at 4:04 AM, Ivica Ico Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">Many thanks for this, Albert. Do we also need to disable moving or
move the final deb file that is built into a specific folder? By
default tar_em_up.sh moves it into the one level above the root git
folder (e.g. if your git checkout is in ~/blah, the final deb will
be placed in the ~/ folder).<br>
</div></blockquote></div><br></div><div class="gmail_extra">The binary deb can't be used for a Debian source package anyway. I use tar_em_up.sh with the -F option as a way to build everything and put the install tree into the packages/linux_make/build, from where I can move it into the proper Debian staging directory. So I don't actually use the created tarball either.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">But you're right, moving the tarball one level above the source directory might create issues on Launchpad. It would be nice to have an option to have tar_em_up.sh just populate packages/linux_make/build with everything that goes into the package, without actually building the deb package or tarball. Or at least disable the final step where the package gets moved out of the source directory.<br><br></div><div class="gmail_extra">However, I think that I can figure this out on my own. The relevant part of the tar_em_up.sh script are the lines following the `# finish install` comment, right? So I just need an option which does a full build as usual and then just disables the final steps from there.<br></div><div class="gmail_extra"><br>-- <br><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+AlbertGraef</a></div></div>
</div></div>
<br></div></div><span>_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="http://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">http://disis.music.vt.edu/listinfo/l2ork-dev</a><br></span></blockquote></div>
<br>_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="http://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">http://disis.music.vt.edu/listinfo/l2ork-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+AlbertGraef</a></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+AlbertGraef</a></div></div>
</div>