<div dir="ltr"><div class="gmail_quote">On Mon, 9 Mar 2015 at 00:50 Luca Bruno <<a href="mailto:lucab@debian.org">lucab@debian.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Speaking of which, have you ever tried the nodocs build-profile you committed?<br>
I think it doesn't work, as building a single binary package changes the<br>
DESTDIR so things are not anymore under debian/tmp.<br>
If that's the case, please refrain from committing untested stuff, or which<br>
doesn't match what the docs say, or which doesn't update existing docs where<br>
needed.<br></blockquote><div><br></div><div>I think I'm a little offended by this :/  Yes, I tested nodocs and it worked fine at the time I added this support.  And to repeat an earlier apology, the docs you're referring to <span style="font-size:13.1999998092651px">were written at a time when I was working on my own packaging without co-maintainers, and </span><span style="font-size:13.1999998092651px">were intended for a consumer of the package as it would appear in Debian repositories.</span></div><div><br></div><div>I think I always had the luxury of extra packages back when I was testing this however (split out editor configs, rust-{gdb,lldb}, runtime library experiments, etc) which would explain why I'd never seen the issue you're hitting.</div><div><br></div><div>I think we should add `DESTDIR := $(CURDIR)/debian/tmp` to the top of debian/rules to get consistent behaviour - or i<span style="font-size:13.1999998092651px">f we're going to accept the rust-gdb split then that will also workaround the issue "for free".  I'll commit the former right now in fact.</span></div><div><span style="font-size:13.1999998092651px"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Fwiw, my local branch has these changes:<br>
> - Move .so libs to standard /usr/lib<br>
<br>
Let's keep this on hold for the moment.<br></blockquote><div><br></div><div>Ack.  It's in alioth gus/libdir if you want to take a look.  I'll continue using it for my cargo packaging for now (when I get back to that), since it fixes the `-C prefer-dynamic` issue without needing explicit changes in cargo or elsewhere. <span style="font-size:13.1999998092651px">Obviously we'll need to work out what we want to do here before the cargo packaging can get uploaded.</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> - Split rust-gdb into separate package<br>
<br>
Are you taking care of installing pretty-printers under PYTHONPATH and the<br>
loader in auto-load directory? We may want to add some versioning here to<br>
avoid future clashes, and propose something upstream which doesn't need<br>
`rustc --sysroot`.<br></blockquote><div><br></div><div>Yes it's in PYTHONPATH, `info auto-load python-scripts` shows the right directory, and `info pretty-printer` shows the pretty printer.  I also patch it to avoid `rustc --sysroot` since we know where we've installed the support files - again the patch is in alioth gus/libdir if you want to take a look.</div><div><br></div><div>I think adding versioning is overkill given that the pretty printer is quite basic and not overly tied to a particular version of rustc.  <span style="font-size:13.1999998092651px">If it /does/ change radically in the future somehow a) we can move to a versioned scheme then, and b) I think we'd need to merge support into the same version of rust-gdb anyway (sounds like a project that should happen upstream) since you might be debugging a binary with linked code from mixed rustc compilers.</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> - Set buildflags according to policy (fixes relro lintian issue)<br>
<br>
Please thoroughly test this before committing, as I have this feeling that<br>
stuff will possibly break in subtle ways.<br></blockquote><div><br></div><div>Yeah, I agree - i<span style="font-size:13.1999998092651px">f you've got any ideas for additional test cases, I'd be happy to try them out.  </span><span style="font-size:13.1999998092651px">It passes the full "make check" suite, which exercises the compiler quite extensively - including both small executables produced and of course the rustc executable itself (which is built with these additional flags).</span></div><div><br></div><div>I have _not_ tried compiling with the embedded llvm _and_ the additional CFLAGS/CXXFLAGS.  It's conceivable that something in LLVM fails to compile with -Werror, etc - although Sylvestre may be already building his llvm with the recommended buildflags, I haven't looked.</div><div><br></div><div>Also: As I mention in the change, my current RUSTFLAGS setting assumes rustc is linking using GNU ld.  This is currently the case for all linux+openbsd rustc targets (search for linker_is_gnu) but is something to keep in mind with ports to the more exotic Debian architectures.</div><div><br></div><div> - Gus</div></div></div>