On Sunday, March 20, 2016 at 3:05:25 AM UTC-7, Henri Sivonen wrote: > On Fri, Mar 18, 2016 at 6:45 PM, Mike Hommey <m...@glandium.org> wrote: > > On Fri, Mar 18, 2016 at 05:23:21PM +0200, Henri Sivonen wrote: > >> You say you don't see #5 happening. Do you see #4 happening? If not, > >> what do you see happening? > > > > At this point, I'm wondering if the best outcome wouldn't be 6) Distros > > die. I'm almost not joking. > > Non-jokingly, though, what resolution do you see? > > >> Looking at > >> https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security > >> , it seems that Debian users get a more up-to-date Blink than Gecko. > >> If that policy is any indication, if ESR didn't exist, Gecko would get > >> the same deal as Blink... In other words, it looks like Debian > >> penalizes Gecko relative to Blink because ESR exists. :-( > > > > Well, at some point Blink wasn't even in stable. I'm actually surprised > > that it is now. > > The key thing is that it is now and updating it in a way that's an > exception to Debian's general policy is now itself stated policy. So > Debian has explicitly granted our main competitor the sort of policy > exception that would be the best suited to resolving the problem at > hand arising from Debian policy. > > How do we get for rustc (as a build dependency of Firefox) the sort of > policy exception that our main competitor already got? > > > But as a matter of fact, Debian's old stable is not > > receiving Blink/Chromium updates (it's stuck on 37), while it receives > > updates for Iceweasel (it has 38.7 as or writing, will receive 38.8, and > > 45.2 after that) > > It appears that 45 ESR compiles with the GCC version that's in > oldstable. What would have happened if that wasn't the case? What's > the plan if during the support cycle of the current stable the next > ESR doesn't build with the GCC version that shipped in current stable? > > The comments on https://bugzilla.mozilla.org/show_bug.cgi?id=1175546 > suggest that Mozilla deferred relying on GCC bug fixes until after 45 > ESR in order for Debian not to have to backport a compiler for > oldstable. Is that the case? That is, is Debian's policy already > hindering Mozilla's ability to avoid C++ compiler bugs that the > compiler upstream has fixed? > > >> On Fri, Mar 18, 2016 at 1:01 PM, Sylvestre Ledru <sle...@mozilla.com> > >> wrote: > >> > One dirty solution would be to ship rustc+llvm sources into Firefox > >> > sources when targeting stable distros. > >> > But this increases the load on the maintainers by an order of magnitude > >> > (maintainers will have to manage rust & llvm) > >> > and might not work if llvm starts requiring a more recent of gcc to > >> > build. > >> > >> Surely llvm can be built with clang, so you could include not only the > >> source of every rustc release since Debian's freeze but the source > >> code of every llvm and clang release since Debian's freeze... Except > >> then you'd need a policy exception for the anti-bundling policy. If > >> you need *some* policy exception no matter what, surely going for the > >> most sensible exception (letting both the Firefox package and the > >> rustc package update every six weeks within the LTS cycle) would make > >> the most sense. > > > > A 6GB source tarball, for a build taking 200 hours just for one > > architecture (I'm making up numbers, but I'm probably in the right > > ballpark). Times 10 supported architectures. You'd better not have a > > one-liner patch to apply on top of that. > > Right. That would be an absurd outcome caused by Debian's policy. So > how do we go about getting a policy exception to avoid absurdity? > > > Note that this is why Blink/Chromium can get away with very frequent updates > > in stable and not Iceweasel/Firefox: > > > > $ grep-dctrl -sPackage -FDepends chromium --and --not -FSource > > chromium-browser > > /var/lib/apt/lists/ftp.jp.debian.org_debian_dists_jessie_main_binary-amd64_Packages > > | wc -l > > 2 > > > > (one is http://chromium-bsu.sourceforge.net/, the other is mozplugger, > > which... sounds like a mistake... I think it's an NPAPI plugin) > > > > > > $ grep-dctrl -sPackage -FDepends iceweasel --and --not -FSource iceweasel > > /var/lib/apt/lists/ftp.jp.debian.org_debian_dists_jessie_main_binary-amd64_Packages > > | wc -l > > 64 > > Are the dependent packages Firefox extensions? Now that Debian has > already accepted upgrading to the next ESR during the lifecycle of > stable, how are those dependent packages expected to survive that > upgrade without being themselves updated? > > On Fri, Mar 18, 2016 at 9:05 PM, <bander...@mozilla.com> wrote: > > One could similarly make distro packages of rustc specifically for building > > firefox (called 'rustc-fx' for example), and put them on the same ESR > > upgrade schedule as Firefox. > > This is the approach Ubuntu takes with GCC in order rapid-release > (non-ESR) Firefox for Ubuntu LTS. > > > As another idea: Rust could maintain an LTS branch designed to be upgraded > > in conjunction with Firefox, that both keeps the language on a stable > > revision while also exposing backported features that Firefox needs in a > > controlled way. So Firefox would commit to being on e.g. 1.12 for 3 years, > > but could import 'future' features. Then LTS distros would put rustc LTS > > point releases on the same upgrade schedule as Firefox ESR upgrades. > > > > For Firefox this would require a lot of discipline. For Rust it would be a > > massive challenge coming up with a maintainable scheme. I'm actually > > thinking Rust could support multiple language revisions with a single > > compiler in a way that would allow old revisions to receive continual > > bugfixes and integrate 'future' features; and that would be reliable enough > > that LTS distros could make major version bumps to rustc alongside Firefox > > while still deploying the language revision compatible with their LTS. > > Difficult and crazy. > > Indeed difficult and crazy. Moreover, this would mean that Debian > policy would inflict a significant negative externality borne by Gecko > developers and Firefox's competitiveness in the sense of Gecko being > unable to benefit from Rust improvements and improvements to the crate > ecosystem in a timely fashion. In order to be able to allocate > resources into Gecko's competitiveness, I think Gecko developers must > refuse to bear the cost of Debian policy like this. Even Windows XP > doesn't inflict this kind of hindrance on us. > > I think the Mozilla-side discipline should be limited to: > 1) (The Rust parts of) Firefox on the release channel compiling with > the then-current stable channel rustc and Rust standard library. > 2) Stable channel rustc being able to compile its corresponding > standard library. > 3) Stable channel rustc being able to compile itself. > 4) Stable channel rustc being able to be compiled with the previous > stable channel rustc. > > Extra cost arising from distro policies should be internalized by the > distros. Mike already said that internalizing the cost of Debian's > policy in the case of (Rustless) Firefox is intractable. Especially in > the light of the policy exception Debian has for Chromium, the > reasonable conclusion is that Debian should grant such an exception to > Firefox + rustc. > > On Sat, Mar 19, 2016 at 2:27 PM, <cosinusoida...@gmail.com> wrote: > > On Thursday, 17 March 2016 12:23:32 UTC, Henri Sivonen wrote: > >> (rustc originally bootstrapped with OCaml, but > >> building the whole history of Rust from the OCaml days to present > >> every time Fedora builds Firefox seems excessively impractical.) > > > > Out of interest, would that actually involve building every single Linux > > snapshot from > > https://github.com/rust-lang/rust/blob/master/src/snapshots.txt in > > sequence? All 319 of them? > > Presumably, yes, if you want to bootstrap from OCaml. Maybe you could > skip some snapshots, but you don't know which ones in advance. > Fortunately, e.g. the Fedora policy doesn't require bootstrapping all > the way from OCaml. > > On Sun, Mar 20, 2016 at 6:18 AM, Cameron Kaiser <ckai...@floodgap.com> wrote: > > And are those the steps you'd actually have to take to bring Rust up from > > scratch on a new platform? > > That's the definition of "from scratch", isn't it? But ignoring that: > No, unless you want to go full-tinfoil against the Trusting Trust > attack and chances are you didn't do that with GCC, either. > > Realistically, the way to bring up Rust on a new platform is to > cross-compile on an existing platform. I'm guessing that you are > thinking of OS X 10.4 on (32-bit big-endian) PowerPC. OS X 10.7+ on > x86 and x86_64 is a tier-1 Rust platform and Linux on 32-bit > big-endian PowerPC is a tier-3 Rust platform, so the basic ingredients > are roughly there. The main obstacle will probably be the same as with > OS X 10.6: thread-local storage.
I'm surprised to hear that *10.4* is still expected to work. The oldest version I've heard Rust needed to support is 10.6. Any any case, Rust is trying to build more and more binaries, to alleviate cross-compilation bootstrapping burden. We've got netbsd, freebsd, and arm linux compilers coming online soon. If more OS X support is needed from Rust we can build more OS X compilers. > > AFAICT, you need approximately: > 1) A host running OS X 10.7 or later on x86 or x86_64. > 2) The PPC 10.4 SDK loaded onto that host to have the right PPC libc > and pthreads libraries to link with. > 3) A GCC build that runs on x86/x86_64 but can compile and link targeting > PPC. > 4) Figure out how to disable thread-local storage given that > according to https://github.com/rust-lang/rust/issues/32047 the old > configuration option no longer works. > 5) Follow a cross-compilation guide such as > https://github.com/Ogeon/rust-on-raspberry-pi/blob/master/MANUAL.md > but substituting the OS X 10.4 SDK and PPC-targeting GCC stuff in > place of the Linaro stuff and powerpc-apple-darwin as the target > triple. > 6) Fix whatever doesn't work... > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
