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. 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
