[Pkg-rust-maintainers] Alpha2 upload [was: build profiles]

[Luca Bruno]

On Monday 09 March 2015 03:51:46 Angus Lees wrote:

> > If that's the case, please refrain from committing untested stuff, or
> > which doesn't match what the docs say, or which doesn't update existing
> > docs where needed.
 
> I think I'm a little offended by this :/ 

I'm sorry for that, it sounded a bit harsh, I apologize. Main point was:
it's team-work, so if you break stuff or document it not clearly enough, it 
has direct negative impact on other people on the team.

> I think we should add `DESTDIR := $(CURDIR)/debian/tmp` to the top of
> debian/rules to get consistent behaviour - or if 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.

I was actually passing --destdir to dh_auto_install as a workaround locally, 
but if nodocs profile builds with your commit that's equally ok.

> I think adding versioning is overkill given that the pretty printer is
> quite basic and not overly tied to a particular version of rustc.  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.

I was thinking more about file-paths collisions with future rustcX; but you 
are right, we'll think about this later.
 
> > - Set buildflags according to policy (fixes relro lintian issue)
> > 
> > Please thoroughly test this before committing, as I have this feeling that
> > stuff will possibly break in subtle ways.
> 
> Yeah, I agree - if you've got any ideas for additional test cases, I'd be
> happy to try them out.  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).

Cool! I am more concerned about cargo and other libs, which may happen to mix 
flags. But at this point, I don't have specific cases in mind, so don't bother 
too much.

I saw your buildflags patch, just two quick notes:
 * CFLAGS and CXXFLAGS seems to be usually included by mk/cfg/*.mk files,
   except for x86_64-unknown-linux-gnu. I don't know the reason behind that,
   but I suspect your platform.mk may results in double flags on other 
   platforms.
 * is there a reason for "Forwarded: no" or is it just a matter of (lack of)
   time? I would be interested in getting upstream review on this and the
   rationale behind the different handling in amd64.

Cheers, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.    | lucab (AT) debian.org
`. `'`                          | GPG Key ID: 0x4F3BBEBF
  `-     http://www.debian.org 	| Debian GNU/Linux Developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150309/2d9c4f6d/attachment.sig>