hnakamur
diff --git a/‎debian/NEWS
+29 b/‎debian/NEWS
+29
diff --git a/‎debian/README.Debian
+213 b/‎debian/README.Debian
+213
@@ -0,0 +1,29 @@
+rustc (1.20.0+dfsg1-2) unstable; urgency=medium
+
+  Starting from version 1.20.0+dfsg1-1 (i.e. the previous version) the Debian
+  packages of rustc no longer fail their build if any tests fail. In other
+  words, some tests might have failed when building this and future versions of
+  the package. This is due to lack of maintainer time to investigate failures.
+
+  Many previous test failures were reported to upstream and did not receive a
+  timely response, suggesting the failures were not important. I was then
+  forced to patch out the test to make the build proceed, so several tests were
+  being ignored in practise anyway.
+
+  This brings the Debian package in line with the Fedora package which also
+  ignores all test failures. (Many other distributions don't run tests at all.)
+
+  If you think that the Debian rustc package is miscompiling your program in a
+  way that the upstream distributed compiler doesn't, you may check the test
+  failures here:
+
+  https://buildd.debian.org/status/package.php?p=rustc
+
+  If you can identify a relevant test failure as well as the patches needed to
+  fix it (either to rustc or LLVM), this will speed up the processing of any
+  bug reports on the Debian side.
+
+  We will also examine these failures ourselves on a best-effort basis and
+  attempt to fix the more serious-looking ones.
+
+ -- Ximin Luo <[email protected]>  Mon, 16 Oct 2017 18:02:23 +0200
@@ -0,0 +1,213 @@
+Test failures
+=============
+
+Starting from version 1.20.0+dfsg1-1 the Debian packages of rustc no longer
+fail the overall build if > 0 tests fail. Instead, we allow up to around 5
+tests to fail. In other words, if you're reading this in a binary package,
+between 0 and 5 tests might have failed when building this.
+
+This is due to lack of maintainer time to investigate all failures. Many
+previous test failures were reported to upstream and did not receive a timely
+response, suggesting the failures were not important. I was then forced to
+patch out the test to make the build proceed, so several tests were being
+ignored in practise anyway.
+
+This brings the Debian package in line with the Fedora package which also
+ignores all test failures. (Many other distributions don't run tests at all.)
+
+If you think that the Debian rustc package is miscompiling your program in a
+way that the upstream distributed compiler doesn't, you may check the test
+failures here:
+
+https://buildd.debian.org/status/package.php?p=rustc
+
+If you can identify a relevant test failure, as well as the patches needed to
+fix it (either to rustc or LLVM), this will speed up the processing of any bug
+reports on the Debian side.
+
+We will also examine these failures ourselves on a best-effort basis and
+attempt to fix the more serious-looking ones.
+
+Uncommon architectures
+----------------------
+
+Debian release architectures armel and s390x currently have more test failures,
+being tracked by upstream here:
+
+- https://github.com/rust-lang/rust/issues/52493 armel
+- https://github.com/rust-lang/rust/issues/52491 s390x
+
+Ports architectures
+-------------------
+
+The number of allowed test failures on certain Debian ports architectures
+(currently powerpc, powerpcspe, sparc64, x32) is raised greatly to help unblock
+progress for porters. Of course, as a user this means you may run into more
+bugs than usual; as mentioned above bugs reports and patches are welcome.
+
+
+Shared libraries
+================
+
+For now, the shared libraries of Rust are private.
+The rational is the following:
+ * Upstream prefers static linking for now
+   - https://github.com/rust-lang/rust/issues/10209
+ * rust is still under heavy development. As far as we know, there is
+   no commitement from upstream to provide a stable ABI for now.
+   Until we know more, we cannot take the chance to have Rust-built packages
+   failing at each release of the compiler.
+ * Static builds are working out of the box just fine
+ * However, LD_LIBRARY_PATH has to be updated when -C prefer-dynamic is used
+
+ -- Sylvestre Ledru <[email protected]>, Fri, 13 Feb 2015 15:08:43 +0100
+
+
+Architecture-specific notes
+===========================
+
+armhf
+-----
+
+We only ship debuginfo for libstd and not the compiler itself, otherwise builds
+run out of memory on the Debian buildds, with non-obvious and random errors.
+
+See https://github.com/rust-lang/rust/issues/45854 for details.
+
+If all your armhf build machines have ~8GB memory or more, you can experiment
+with disabling this work-around (i.e. revert to normal) in d/rules.
+
+
+Cross-compiling
+===============
+
+Rust uses LLVM, so cross-compiling works a bit differently from the GNU
+toolchain. The most important difference is that there are no "cross"
+compilers, every compiler is already a cross compiler. All you need to do is
+install the standard libraries for each target architecture you want to compile
+to. For rustc, this is libstd-rust-dev, so your debian/control would look
+something like this:
+
+    Build-Depends:
+     [..]
+     rustc:native    (>= $version),
+     libstd-rust-dev (>= $version),
+     [..]
+
+You need both, this is important. When Debian build toolchains satisfy the
+build-depends of a cross-build, (1) a "rustc:native" Build-Depends selects
+rustc for the native architecture, which is possible because it's "Multi-Arch:
+allowed", and this will implicitly pull in libstd-rust-dev also for the native
+architecture; and (2) a "libstd-rust-dev" Build-Depends implies libstd-rust-dev
+for the foreign architecture, since it's "Multi-Arch: same".
+
+You'll probably also want to add
+
+    include /usr/share/rustc/architecture.mk
+
+to your debian/rules. This sets some useful variables like DEB_HOST_RUST_TYPE.
+
+See the cargo package for an example.
+
+Terminology
+-----------
+
+The rust ecosystem generally uses the term "host" for the native architecture
+running the compiler, equivalent to DEB_BUILD_RUST_TYPE or "build" in GNU
+terminology, and "target" for the foreign architecture that the build products
+run on, equivalent to DEB_HOST_RUST_TYPE or "host" in GNU terminology. For
+example, rustc --version --verbose will output something like:
+
+    rustc 1.16.0
+    [..]
+    host: x86_64-unknown-linux-gnu
+
+And both rustc and cargo have --target flags:
+
+    $ rustc --help | grep '\-\-target'
+        --target TARGET     Target triple for which the code is compiled
+    $ cargo build --help | grep '\-\-target'
+        --target TRIPLE              Build for the target triple
+
+One major exception to this naming scheme is in CERTAIN PARTS OF the build
+scripts of cargo and rustc themselves, such as the `./configure` scripts and
+SOME PARTS of the `config.toml` files. Here, "build", "host" and "target" mean
+the same things they do in GNU toolchain terminology. However, IN OTHER PARTS
+OF the build scripts of cargo and rustc, as well as cargo and rustc's own
+output and logging messages, the term "host" and "target" mean as they do in
+the previous paragraph. Yes, it's a total mind fuck. :( Table for clarity:
+
+======================================= =============== ========================
+                                        Rust ecosystem, Some parts of the rustc
+GNU term / Debian envvar                rustc and cargo and cargo build scripts
+======================================= =============== ========================
+build   DEB_BUILD_{ARCH,RUST_TYPE}      host            build
+  the machine running the build
+--------------------------------------- --------------- ------------------------
+host    DEB_HOST_{ARCH,RUST_TYPE}       target          host(s)
+  the machine the build products run on
+--------------------------------------- --------------- ------------------------
+only relevant when building a compiler
+target  DEB_TARGET_{ARCH,RUST_TYPE}     N/A             target(s)
+  the one architecture that the built                     extra architectures
+  cross-compiler itself builds for                        to build "std" for
+--------------------------------------- --------------- ------------------------
+
+
+Porting to new architectures (on the same distro)
+=================================================
+
+As mentioned above, to cross-compile rust packages you need to install the rust
+standard library for each relevant foreign architecture. However, this is not
+needed when cross-compiling rustc itself; its build system will build any
+relevant foreign-architecture standard libraries automatically.
+
+Cross-build, in a schroot using sbuild
+--------------------------------------
+
+0. Set up an schroot for your native architecture, for sbuild:
+
+    sudo apt-get install sbuild
+    sudo sbuild-adduser $LOGNAME
+    newgrp sbuild # or log out and log back in
+    sudo sbuild-createchroot --include=eatmydata,ccache,gnupg unstable \
+      /srv/chroot/unstable-$(dpkg-architecture -qDEB_BUILD_ARCH)-sbuild \
+      http://deb.debian.org/debian
+
+   See https://wiki.debian.org/sbuild for more details.
+
+1. Build it:
+
+    sudo apt-get source --download-only rustc
+    sbuild --host=$new_arch rustc_*.dsc
+
+Cross-build, directly on your own system
+----------------------------------------
+
+0. Install the build-dependencies of rustc (including cargo and itself):
+
+    sudo dpkg --add-architecture $new_arch
+    sudo apt-get --no-install-recommends build-dep --host-architecture=$new_arch rustc
+
+1. Build it:
+
+    apt-get source --compile --host-architecture=$new_arch rustc
+
+Native-build using bundled upstream binary blobs
+------------------------------------------------
+
+Use the same instructions as given in "Bootstrapping" in debian/README.source
+in the source package, making sure to set the relevant architectures.
+
+Responsible distribution of cross-built binaries
+------------------------------------------------
+
+By nature, cross-builds do not run tests. These are important for rustc and
+many tests often fail on newly-supported architectures even if builds and
+cross-builds work fine. You should find some appropriate way to test your
+cross-built packages rather than blindly shipping them to users.
+
+For example, Debian experimental is an appropriate place to upload them, so
+that they can be installed and tested on Debian porter boxes, before being
+uploaded to unstable and distributed to users.
+