info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Use cases for official generic “Linux” builds vs. ABI-unstable system libraries
248 views
Skip to first unread message
Henri Sivonen
Sep 26, 2012, 3:41:04 AM9/26/12
to mozilla.dev.planning group
(Taking discussion from Bugzilla to groups; see
https://bugzilla.mozilla.org/show_bug.cgi?id=794282 )
(In reply to Mike Hommey [:glandium] from comment #6)
> I doubt this is possible to do for official builds. Distro builds could do
> it, but official will likely have a hard time maintaining binary
> compatibility with different versions of the system libraries. Look at the
> ABI changes between 0.10 and 1.0.
> http://upstream-tracker.org/versions/gstreamer.html
(In reply to Mike Hommey [:glandium] from comment #7)
> and no, embedding gstreamer like we embed other third party libraries won't
> help. The only way it would work would be to also embed the mp4 decoder, and
> that's opening a legal can of worms.
First of all, I am in no way suggesting that we demote Linux in terms
of the tier-1 status as it applies to backing out breaking patches or
automated test builds.
With that out of the way:
What are the use cases for Mozilla-supplied generic Linux Firefox
tarball binary releases? Who uses them and why?
At least in the case of Ubuntu, even if you want to test a non-release
channel, you can get distro builds that integrate nicely with the
package management of the system. You can even get daily builds:
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
And on the other hand, Ubuntu-supplied builds work better on Ubuntu,
because they integrate with the global menu. (Consider how silly it
would be if we shipped on Mac without support for the system-style of
menu bar!)
If the ABI-instability of GStreamer or Unity’s global menu make it
unpractical to support generic “desktop Linux” with binary releases,
shouldn't we have a different way of releasing for “desktop Linux”
until “desktop Linux” gets its binary compatibility act together?
Instead of considering “Linux” a Mozilla-supported platform should we
consider “Ubuntu”, “Fedora” and “openSUSE” Mozilla-supported platforms
and let binary-incompatible x86/x86_64 Linux distros take care of
compiling their own binaries like they are already doing anyway at
least for the release channel? After all, the way we do automated
testing has been that the tests run on one popular distro, so de facto
“Linux” isn't a tier-1 platform for automation and backup purposes but
one of the distros is.
And if our supported platforms were “Ubuntu”, “Fedora” and “openSUSE”,
could Mozilla then work out a deal with them so that the builds they
make use at Mozilla-blessed compiler tool chain configuration so that
performance work done by Mozilla on e.g. the linker level would be
applicable to the builds and users actually get? And then Mozilla
would point to the distro packeges instead of generic tarballs. And
Mozilla would then accept bug reports for the distro-specific builds
for the “supported” distros. (My recollection is that when
Mozilla-supplied .deb or .rpm packages have been suggested, there have
been worries about stepping on the distros’ toes.) (I left “Debian”
out of the list, since clearly [and sadly], Mozilla and Debian still
don’t have the trademark stuff sorted out and Debian ships very old
libs anyway.)
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
https://bugzilla.mozilla.org/show_bug.cgi?id=794282 )
(In reply to Mike Hommey [:glandium] from comment #6)
> I doubt this is possible to do for official builds. Distro builds could do
> it, but official will likely have a hard time maintaining binary
> compatibility with different versions of the system libraries. Look at the
> ABI changes between 0.10 and 1.0.
> http://upstream-tracker.org/versions/gstreamer.html
(In reply to Mike Hommey [:glandium] from comment #7)
> and no, embedding gstreamer like we embed other third party libraries won't
> help. The only way it would work would be to also embed the mp4 decoder, and
> that's opening a legal can of worms.
First of all, I am in no way suggesting that we demote Linux in terms
of the tier-1 status as it applies to backing out breaking patches or
automated test builds.
With that out of the way:
What are the use cases for Mozilla-supplied generic Linux Firefox
tarball binary releases? Who uses them and why?
At least in the case of Ubuntu, even if you want to test a non-release
channel, you can get distro builds that integrate nicely with the
package management of the system. You can even get daily builds:
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
And on the other hand, Ubuntu-supplied builds work better on Ubuntu,
because they integrate with the global menu. (Consider how silly it
would be if we shipped on Mac without support for the system-style of
menu bar!)
If the ABI-instability of GStreamer or Unity’s global menu make it
unpractical to support generic “desktop Linux” with binary releases,
shouldn't we have a different way of releasing for “desktop Linux”
until “desktop Linux” gets its binary compatibility act together?
Instead of considering “Linux” a Mozilla-supported platform should we
consider “Ubuntu”, “Fedora” and “openSUSE” Mozilla-supported platforms
and let binary-incompatible x86/x86_64 Linux distros take care of
compiling their own binaries like they are already doing anyway at
least for the release channel? After all, the way we do automated
testing has been that the tests run on one popular distro, so de facto
“Linux” isn't a tier-1 platform for automation and backup purposes but
one of the distros is.
And if our supported platforms were “Ubuntu”, “Fedora” and “openSUSE”,
could Mozilla then work out a deal with them so that the builds they
make use at Mozilla-blessed compiler tool chain configuration so that
performance work done by Mozilla on e.g. the linker level would be
applicable to the builds and users actually get? And then Mozilla
would point to the distro packeges instead of generic tarballs. And
Mozilla would then accept bug reports for the distro-specific builds
for the “supported” distros. (My recollection is that when
Mozilla-supplied .deb or .rpm packages have been suggested, there have
been worries about stepping on the distros’ toes.) (I left “Debian”
out of the list, since clearly [and sadly], Mozilla and Debian still
don’t have the trademark stuff sorted out and Debian ships very old
libs anyway.)
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Mike Hommey
Sep 26, 2012, 6:58:30 AM9/26/12
to Henri Sivonen, mozilla.dev.planning group
On Wed, Sep 26, 2012 at 10:41:04AM +0300, Henri Sivonen wrote:
> (Taking discussion from Bugzilla to groups; see
> https://bugzilla.mozilla.org/show_bug.cgi?id=794282 )
> (In reply to Mike Hommey [:glandium] from comment #6)
> > I doubt this is possible to do for official builds. Distro builds could do
> > it, but official will likely have a hard time maintaining binary
> > compatibility with different versions of the system libraries. Look at the
> > ABI changes between 0.10 and 1.0.
> > http://upstream-tracker.org/versions/gstreamer.html
>
> (In reply to Mike Hommey [:glandium] from comment #7)
> > and no, embedding gstreamer like we embed other third party libraries won't
> > help. The only way it would work would be to also embed the mp4 decoder, and
> > that's opening a legal can of worms.
>
> First of all, I am in no way suggesting that we demote Linux in terms
> of the tier-1 status as it applies to backing out breaking patches or
> automated test builds.
>
> With that out of the way:
>
> What are the use cases for Mozilla-supplied generic Linux Firefox
> tarball binary releases? Who uses them and why?
And what proportion of Linux users do use them? I've seen the question
> (Taking discussion from Bugzilla to groups; see
> https://bugzilla.mozilla.org/show_bug.cgi?id=794282 )
> (In reply to Mike Hommey [:glandium] from comment #6)
> > I doubt this is possible to do for official builds. Distro builds could do
> > it, but official will likely have a hard time maintaining binary
> > compatibility with different versions of the system libraries. Look at the
> > ABI changes between 0.10 and 1.0.
> > http://upstream-tracker.org/versions/gstreamer.html
>
> (In reply to Mike Hommey [:glandium] from comment #7)
> > and no, embedding gstreamer like we embed other third party libraries won't
> > help. The only way it would work would be to also embed the mp4 decoder, and
> > that's opening a legal can of worms.
>
> First of all, I am in no way suggesting that we demote Linux in terms
> of the tier-1 status as it applies to backing out breaking patches or
> automated test builds.
>
> With that out of the way:
>
> What are the use cases for Mozilla-supplied generic Linux Firefox
> tarball binary releases? Who uses them and why?
asked many times, but I don't recall seeing any answer to that question.
I do know some Debian users use the Mozilla builds because they don't
like iceweasel for some reason, or because they want the latest release
instead of what is in stable, backports or unstable, not knowing that,
in fact, Debian packages for releases, beta and aurora builds are
available.
I /think/ some users of other distros use the Mozilla builds because
they don't want the integration bits and/or because they have issues
with their distro builds.
Mike
Zack Weinberg
Sep 26, 2012, 12:20:29 PM9/26/12
to
On 2012-09-26 6:58 AM, Mike Hommey wrote:
>>
>> What are the use cases for Mozilla-supplied generic Linux Firefox
>> tarball binary releases? Who uses them and why?
>
> And what proportion of Linux users do use them? I've seen the question
> asked many times, but I don't recall seeing any answer to that question.
I generally think scrapping binary "generic Linux" tarball distribution
>>
>> What are the use cases for Mozilla-supplied generic Linux Firefox
>> tarball binary releases? Who uses them and why?
>
> And what proportion of Linux users do use them? I've seen the question
> asked many times, but I don't recall seeing any answer to that question.
would be a good move on Mozilla's part, especially if it went along with
a move away from "the only supported configuration is embedded rather
than system libraries".
That said, I have *once* found the binary tarball useful, when I was
stuck with a corporate Linux desktop based on an ancient version of
Ubuntu, whose stock browser was Firefox 4 (when Mozilla was on 13,
iirc). I did not have the ability to upgrade it, and I did not have
enough disk quota (or dependencies) to compile from source, but I was
able to unpack the tarball in my home directory and use that. This is a
pretty marginal use case; if the tarball hadn't been available I would
probably have been able to persuade corporate IT to install a newer
browser from somebody's PPA, or something like that.
zw
Mike Hommey
Sep 26, 2012, 12:37:35 PM9/26/12
to Zack Weinberg, dev-pl...@lists.mozilla.org
harder to do with distro packages, if at all possible.
Mike
Pascal Chevrel
Sep 26, 2012, 12:43:54 PM9/26/12
to
Le 26/09/2012 09:41, Henri Sivonen a écrit :
> (Taking discussion from Bugzilla to groups; see
> https://bugzilla.mozilla.org/show_bug.cgi?id=794282 )
> (In reply to Mike Hommey [:glandium] from comment #6)
>> I doubt this is possible to do for official builds. Distro builds could do
>> it, but official will likely have a hard time maintaining binary
>> compatibility with different versions of the system libraries. Look at the
>> ABI changes between 0.10 and 1.0.
>> http://upstream-tracker.org/versions/gstreamer.html
>
> (In reply to Mike Hommey [:glandium] from comment #7)
>> and no, embedding gstreamer like we embed other third party libraries won't
>> help. The only way it would work would be to also embed the mp4 decoder, and
>> that's opening a legal can of worms.
>
> First of all, I am in no way suggesting that we demote Linux in terms
> of the tier-1 status as it applies to backing out breaking patches or
> automated test builds.
>
> With that out of the way:
>
> What are the use cases for Mozilla-supplied generic Linux Firefox
> tarball binary releases? Who uses them and why?
Hi,
> (Taking discussion from Bugzilla to groups; see
> https://bugzilla.mozilla.org/show_bug.cgi?id=794282 )
> (In reply to Mike Hommey [:glandium] from comment #6)
>> I doubt this is possible to do for official builds. Distro builds could do
>> it, but official will likely have a hard time maintaining binary
>> compatibility with different versions of the system libraries. Look at the
>> ABI changes between 0.10 and 1.0.
>> http://upstream-tracker.org/versions/gstreamer.html
>
> (In reply to Mike Hommey [:glandium] from comment #7)
>> and no, embedding gstreamer like we embed other third party libraries won't
>> help. The only way it would work would be to also embed the mp4 decoder, and
>> that's opening a legal can of worms.
>
> First of all, I am in no way suggesting that we demote Linux in terms
> of the tier-1 status as it applies to backing out breaking patches or
> automated test builds.
>
> With that out of the way:
>
> What are the use cases for Mozilla-supplied generic Linux Firefox
> tarball binary releases? Who uses them and why?
Most of our core localizers are Linux users, they follow mozilla-central
and use our localized nightly builds to see their strings and QA their
builds.
They are not users as in 'people that add to our marketshare', but I
think that building firefox for them is important if we want products of
quality.
There are also problems with distro-provided packages related to l10n,
for example they don't release localized builds but en en-US build with
a language pack, that means for example that the search engines are not
local, that the default protocol providers (mail, news, rss) are the
default en-US ones and that the provided dictionnary is the OS
dictionnary, usually a myspell one that doesn't work correctly, while
the official Mozilla build comes with our own dictionnary based on hunspell.
Cheers
Pascal
PS: also, not all Ubuntu users keep unity as their environment, Ubuntu
user here and happy Gnome 3 user to ;)
Karl Tomlinson
Sep 26, 2012, 6:23:19 PM9/26/12
to
Our nightly users, at least the ones that report bugs, are very
valuable for product quality.
I doubt we would get a similarly smooth daily upgrade from each of
the distributions, and I haven't heard of distribution packaging
systems that provide for installation and differential upgrades
without root privileges.
valuable for product quality.
I doubt we would get a similarly smooth daily upgrade from each of
the distributions, and I haven't heard of distribution packaging
systems that provide for installation and differential upgrades
without root privileges.
Nicolas B. Pierron
Sep 26, 2012, 8:57:27 PM9/26/12
to
On 09/26/2012 03:23 PM, Karl Tomlinson wrote:
> I doubt we would get a similarly smooth daily upgrade from each of
> the distributions, and I haven't heard of distribution packaging
> systems that provide for installation and differential upgrades
> without root privileges.
You can use an external package manager such as Nix which handles both of
> I doubt we would get a similarly smooth daily upgrade from each of
> the distributions, and I haven't heard of distribution packaging
> systems that provide for installation and differential upgrades
> without root privileges.
your concerns, see sections “Multi-user support” and “Binary patching” at
http://nixos.org/nix/ .
--
Nicolas B. Pierron
Henri Sivonen
Nov 7, 2012, 7:35:07 AM11/7/12
to mozilla.dev.planning group
So to summarize use cases for Mozilla-supplied tarball builds for Linux:
Use cases for Mozilla-supplied tarball releases for Linux:
1) People who don't like to look at Iceweasel branding get to look at
Firefox branding instead.
2) People who are unaware that up-to-date versions Iceweasel are
available get to run up-to-date software nonetheless.
3) Resolving unspecified issues with distro builds.
4) Installing the latest version without root access when whoever has
root access does not keep Firefox up-to-date.
5) Getting locale-specific search engine and
registerProtocolHandler() defaults.
6) Getting better spellchecking in some non-English cases.
Use cases for Mozilla-supplied tarball nightlies for Linux:
7) Being able to test nightlies at all on distros that don't provide
a nightly channel.
8) Being able to bisect for regressions more easily than with
packages from a distro-provided nightly channel.
9) Being able to test nightlies without root access.
10) Using localized nightlies to track the localization status.
The first three points don't seem particularly strong to me. While I
would prefer users of the code base being able to look at Firefox
branding rather than Iceweasel branding, it seems a lot less important
to me to allow Debian users work around the consequences of the
collision of Debian and Mozilla policies around trademarks than to
support functionality like system GStreamer or Unity global menu.
Also, it seems like a bad idea for Mozilla to allocate resources to
address Debian user unawareness of how to deal with Debian policies
that require shipping out-of-date software by default (i.e.
unawareness of the repo chooser at http://mozilla.debian.net/). As for
unspecified issues with distro builds, I think the point isn't
particularly strong without concrete data about what the issues are
and why they aren't being fixed by the relevant distributions.
>From my own experience, I recognize points 4 and 9 being real issue
for some users, but to me the non-root case seems such a minority case
that I doubt it's being important enough for Mozilla to address when
balanced against supporting system GStreamer, Unity global menu and
integration with the package manager in the common case.
Point #5 makes me wonder why locale-specific search engine and
registerProtocolHandler() defaults cannot be bundled in a language
pack. It seems to me that that would be a much better solution than
having users fight their distro.
In the case of points #6 and #10, I don't understand well enough why
things are the way they are. Why do distros downgrade spellchecking
capability? Is it a licensing thing? (For Finnish, the proper
spellchecker is Finnish-specific [i.e. not a hunspell dict anyway] and
is provided as an add-on, so I'm not familiar with the case of
downgrading capability when a hunspell dict would work.) Is there a
reason why it's more convenient to provide localized nightly builds as
opposed to making a language pack installed in a nightly auto-update
together with a nightly build?
As for point #7, do we know how our nightly testers are spread across
Linux distributions? Which distributions would need to have nightly
coverage to avoid shrinking the tester population significantly if
nightlies were produced on a per-distro basis? Is Ubuntu currently the
only distro with a distro-specific daily/nightly channel?
To me, point #8 looks the strongest. Is it feasible to automatically
rearrange the contents of a .deb or an .rpm into tarball whose
contents run on the same distro that the .deb or .rpm package would
run on? That is, if .deb and .rpm nightlies were the solution for
getting builds that auto-update and reflect the configuration of the
builds that most of our Linux users end up using when they obtain
release builds from their distro, would it be feasible to produce
tarballs for regression bisection by munging the .deb and .rpm
packages into tarballs without having to spend infrastructure
resources to recompile?
Use cases for Mozilla-supplied tarball releases for Linux:
1) People who don't like to look at Iceweasel branding get to look at
Firefox branding instead.
2) People who are unaware that up-to-date versions Iceweasel are
available get to run up-to-date software nonetheless.
3) Resolving unspecified issues with distro builds.
4) Installing the latest version without root access when whoever has
root access does not keep Firefox up-to-date.
5) Getting locale-specific search engine and
registerProtocolHandler() defaults.
6) Getting better spellchecking in some non-English cases.
Use cases for Mozilla-supplied tarball nightlies for Linux:
7) Being able to test nightlies at all on distros that don't provide
a nightly channel.
8) Being able to bisect for regressions more easily than with
packages from a distro-provided nightly channel.
9) Being able to test nightlies without root access.
10) Using localized nightlies to track the localization status.
The first three points don't seem particularly strong to me. While I
would prefer users of the code base being able to look at Firefox
branding rather than Iceweasel branding, it seems a lot less important
to me to allow Debian users work around the consequences of the
collision of Debian and Mozilla policies around trademarks than to
support functionality like system GStreamer or Unity global menu.
Also, it seems like a bad idea for Mozilla to allocate resources to
address Debian user unawareness of how to deal with Debian policies
that require shipping out-of-date software by default (i.e.
unawareness of the repo chooser at http://mozilla.debian.net/). As for
unspecified issues with distro builds, I think the point isn't
particularly strong without concrete data about what the issues are
and why they aren't being fixed by the relevant distributions.
>From my own experience, I recognize points 4 and 9 being real issue
for some users, but to me the non-root case seems such a minority case
that I doubt it's being important enough for Mozilla to address when
balanced against supporting system GStreamer, Unity global menu and
integration with the package manager in the common case.
Point #5 makes me wonder why locale-specific search engine and
registerProtocolHandler() defaults cannot be bundled in a language
pack. It seems to me that that would be a much better solution than
having users fight their distro.
In the case of points #6 and #10, I don't understand well enough why
things are the way they are. Why do distros downgrade spellchecking
capability? Is it a licensing thing? (For Finnish, the proper
spellchecker is Finnish-specific [i.e. not a hunspell dict anyway] and
is provided as an add-on, so I'm not familiar with the case of
downgrading capability when a hunspell dict would work.) Is there a
reason why it's more convenient to provide localized nightly builds as
opposed to making a language pack installed in a nightly auto-update
together with a nightly build?
As for point #7, do we know how our nightly testers are spread across
Linux distributions? Which distributions would need to have nightly
coverage to avoid shrinking the tester population significantly if
nightlies were produced on a per-distro basis? Is Ubuntu currently the
only distro with a distro-specific daily/nightly channel?
To me, point #8 looks the strongest. Is it feasible to automatically
rearrange the contents of a .deb or an .rpm into tarball whose
contents run on the same distro that the .deb or .rpm package would
run on? That is, if .deb and .rpm nightlies were the solution for
getting builds that auto-update and reflect the configuration of the
builds that most of our Linux users end up using when they obtain
release builds from their distro, would it be feasible to produce
tarballs for regression bisection by munging the .deb and .rpm
packages into tarballs without having to spend infrastructure
resources to recompile?
Chris Double
Nov 7, 2012, 8:48:30 AM11/7/12
to Henri Sivonen, mozilla.dev.planning group
On Thu, Nov 8, 2012 at 1:35 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
> 3) Resolving unspecified issues with distro builds.
I don't think Gentoo provides nightly builds. The version of Firefox
> 3) Resolving unspecified issues with distro builds.
they have seems to be 10.0.9 ESR. I'd rather use a nightly build from
Mozilla without GStreamer than 10.0.9 ESR.
Chris.
--
http://www.bluishcoder.co.nz
Alexander L. Slovesnik
Nov 7, 2012, 8:53:32 AM11/7/12
to dev-pl...@lists.mozilla.org
В письме от Срд, 07 Ноя 2012, 16:35 Henri Sivonen пишет:
> In the case of points #6 and #10, I don't understand well enough why
> things are the way they are. Why do distros downgrade spellchecking
> capability? Is it a licensing thing? (For Finnish, the proper
> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway] and
> is provided as an add-on, so I'm not familiar with the case of
> downgrading capability when a hunspell dict would work.) Is there a
> reason why it's more convenient to provide localized nightly builds as
> opposed to making a language pack installed in a nightly auto-update
> together with a nightly build?
Language packs, installed from ftp.mozilla.org, don't autoupdate (Bug
> things are the way they are. Why do distros downgrade spellchecking
> capability? Is it a licensing thing? (For Finnish, the proper
> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway] and
> is provided as an add-on, so I'm not familiar with the case of
> downgrading capability when a hunspell dict would work.) Is there a
> reason why it's more convenient to provide localized nightly builds as
> opposed to making a language pack installed in a nightly auto-update
> together with a nightly build?
451824).
--
Sincerely yours,
Alexander L. Slovesnik a.k.a. Unghost
==>Web-page: http://www.unghost.ru/
==>Jabber ID: ung...@mozilla-russia.org
==>Gmail Talk ID: ung...@gmail.com
==>ICQ: 205497659
==>IRC: irc://irc.mozilla.org/mozilla-ru
Robert Kaiser
Nov 7, 2012, 9:25:16 AM11/7/12
to
Henri Sivonen schrieb:
archives of of packages (which are needed for that regression tracking).
Also, the easy scriptable "installing" of those builds is essential in
being able to run our automated test suites right on our own Mozilla
systems.
Robert Kaiser
> 8) Being able to bisect for regressions more easily than with
> packages from a distro-provided nightly channel.
I see that as really major - esp. as usually the distros do not keep
> packages from a distro-provided nightly channel.
archives of of packages (which are needed for that regression tracking).
Also, the easy scriptable "installing" of those builds is essential in
being able to run our automated test suites right on our own Mozilla
systems.
Robert Kaiser
Henri Sivonen
Nov 8, 2012, 3:49:18 AM11/8/12
to mozilla.dev.planning group
On Wed, Nov 7, 2012 at 3:48 PM, Chris Double <chris....@double.co.nz> wrote:
> On Thu, Nov 8, 2012 at 1:35 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
>> 3) Resolving unspecified issues with distro builds.
>
> I don't think Gentoo provides nightly builds. The version of Firefox
> they have seems to be 10.0.9 ESR. I'd rather use a nightly build from
> Mozilla without GStreamer than 10.0.9 ESR.
Isn’t it against the spirit of Gentoo to use binaries compiled by
> On Thu, Nov 8, 2012 at 1:35 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
>> 3) Resolving unspecified issues with distro builds.
>
> I don't think Gentoo provides nightly builds. The version of Firefox
> they have seems to be 10.0.9 ESR. I'd rather use a nightly build from
> Mozilla without GStreamer than 10.0.9 ESR.
someone else? :-)
More seriously, though, if the choice is between giving tested system
GStreamer support to Ubuntu and Fedora users versus enabling Gentoo
users work around the Firefox versioning policy of their distro, I'd
much rather give system GStreamer support to Ubuntu and Fedora users.
tarballs available. It doesn't follow that the tarballs should be
generic. In particular, if most of our users use distro-provided
release builds, I think it would be better for our nightly tester
population to test the same build configuration even if for bisecting
those bits are provided as tarballs rather than a .deb or .rpm. Right
now, the Linux nightly tester population tests a different
configuration than the configurations most of the release version
users end up using.
It could be a problem if the mix of distributions used by the nightly
tester population differs significantly from the mix of distributions
used by release channel users. For example, if we determined that
release channel users use Ubuntu and Fedora, targeting nightly builds
to Ubuntu and Fedora would be a problem if our nightly tester
population was instead predominantly using Debian and Gentoo.
Do we have data about the mix of distributions used by the natural
tester population and the mix of distributions used by the release
population (including people who obtain their Firefox binary from
their distribution).
Mounir Lamouri
Nov 9, 2012, 7:45:36 AM11/9/12
to dev-pl...@lists.mozilla.org
On 07/11/12 13:48, Chris Double wrote:
> On Thu, Nov 8, 2012 at 1:35 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
>> 3) Resolving unspecified issues with distro builds.
>
> I don't think Gentoo provides nightly builds. The version of Firefox
> they have seems to be 10.0.9 ESR. I'd rather use a nightly build from
> Mozilla without GStreamer than 10.0.9 ESR.
That is incorrect. Gentoo provides 16.0.2, 15.0.1, 10.0.{10, 9, 7, 6} as
> On Thu, Nov 8, 2012 at 1:35 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
>> 3) Resolving unspecified issues with distro builds.
>
> I don't think Gentoo provides nightly builds. The version of Firefox
> they have seems to be 10.0.9 ESR. I'd rather use a nightly build from
> Mozilla without GStreamer than 10.0.9 ESR.
binary builds [1] and 16.0.2, 10.0.{10, 9, 7, 6, 5, 4} as source-based
builds.
ESR builds are the only ones marked as "stable". This explains why there
are so many versions of it: depending on your architecture, 10.0.x or
10.0.y might be marked as stable (given that the process imply manual
testing).
[1] http://packages.gentoo.org/package/www-client/firefox-bin
[2] http://packages.gentoo.org/package/www-client/firefox
Cheers,
--
Mounir
Robert Kaiser
Nov 9, 2012, 7:46:35 AM11/9/12
to
Henri Sivonen schrieb:
packages for multiple distros (say, the 3-5 major Linux ones plus
ubuntu, which seems to recently not label themselves as Linux any more),
then the generic ones that *should* work independent of distros should
be the best choice. Also, it's really nice for regression testing if you
don't have to replace your "stable" browser with the one you're testing
- but distro-format packages usually are not flexible in where to be
installed, while our generic tarballs are.
> It could be a problem if the mix of distributions used by the nightly
> tester population differs significantly from the mix of distributions
> used by release channel users. For example, if we determined that
> release channel users use Ubuntu and Fedora, targeting nightly builds
> to Ubuntu and Fedora would be a problem if our nightly tester
> population was instead predominantly using Debian and Gentoo.
Or openSUSE, or Arch, or ScientificLinux, or... (you get the picture)
Robert Kaiser
> Being able to bisect is a good reason to keep archived nightly
> tarballs available. It doesn't follow that the tarballs should be
> generic.
If we don't want to heighten the storage requirements by providing
> tarballs available. It doesn't follow that the tarballs should be
> generic.
packages for multiple distros (say, the 3-5 major Linux ones plus
ubuntu, which seems to recently not label themselves as Linux any more),
then the generic ones that *should* work independent of distros should
be the best choice. Also, it's really nice for regression testing if you
don't have to replace your "stable" browser with the one you're testing
- but distro-format packages usually are not flexible in where to be
installed, while our generic tarballs are.
> It could be a problem if the mix of distributions used by the nightly
> tester population differs significantly from the mix of distributions
> used by release channel users. For example, if we determined that
> release channel users use Ubuntu and Fedora, targeting nightly builds
> to Ubuntu and Fedora would be a problem if our nightly tester
> population was instead predominantly using Debian and Gentoo.
Robert Kaiser
Brian Smith
Nov 10, 2012, 5:54:51 PM11/10/12
to Henri Sivonen, mozilla.dev.planning group
Henri Sivonen wrote:
> In the case of points #6 and #10, I don't understand well enough why
> things are the way they are. Why do distros downgrade spellchecking
> capability? Is it a licensing thing? (For Finnish, the proper
> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway]
> and is provided as an add-on, so I'm not familiar with the case of
> downgrading capability when a hunspell dict would work.) Is there a
> reason why it's more convenient to provide localized nightly builds
> as opposed to making a language pack installed in a nightly
> auto-update together with a nightly build?
IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox. Why not just put explicit requirements for spellchecking and other functionality that tends to be degraded (including ECC support) into the Firefox trademark policy?
> In the case of points #6 and #10, I don't understand well enough why
> things are the way they are. Why do distros downgrade spellchecking
> capability? Is it a licensing thing? (For Finnish, the proper
> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway]
> and is provided as an add-on, so I'm not familiar with the case of
> downgrading capability when a hunspell dict would work.) Is there a
> reason why it's more convenient to provide localized nightly builds
> as opposed to making a language pack installed in a nightly
> auto-update together with a nightly build?
Similarly, I am not sure why we can't just say that the GStreamer v.Whatever+ system library is a requirement for Firefox the same way glibc v.Whatever+ is.
> To me, point #8 looks the strongest. Is it feasible to automatically
> rearrange the contents of a .deb or an .rpm into tarball whose
> contents run on the same distro that the .deb or .rpm package would
> run on? That is, if .deb and .rpm nightlies were the solution for
> getting builds that auto-update and reflect the configuration of the
> builds that most of our Linux users end up using when they obtain
> release builds from their distro, would it be feasible to produce
> tarballs for regression bisection by munging the .deb and .rpm
> packages into tarballs without having to spend infrastructure
> resources to recompile?
It might be nice for marketing reasons if we could create a .deb too, if it is not a lot of work. (I suspect that if we standardize on RPM, somebody will contribute the equivalent/better .deb packaging just to show us how silly it is to only ship RPMs.)
Cheers,
Brian
Ben Hearsum
Nov 11, 2012, 4:13:48 PM11/11/12
to Brian Smith, Henri Sivonen, mozilla.dev.planning group
On 11/10/12 05:54 PM, Brian Smith wrote:
> Henri Sivonen wrote:
>> In the case of points #6 and #10, I don't understand well enough why
>> things are the way they are. Why do distros downgrade spellchecking
>> capability? Is it a licensing thing? (For Finnish, the proper
>> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway]
>> and is provided as an add-on, so I'm not familiar with the case of
>> downgrading capability when a hunspell dict would work.) Is there a
>> reason why it's more convenient to provide localized nightly builds
>> as opposed to making a language pack installed in a nightly
>> auto-update together with a nightly build?
>
> IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox.
"as good" is not just defined by features. It's defined by performance
> Henri Sivonen wrote:
>> In the case of points #6 and #10, I don't understand well enough why
>> things are the way they are. Why do distros downgrade spellchecking
>> capability? Is it a licensing thing? (For Finnish, the proper
>> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway]
>> and is provided as an add-on, so I'm not familiar with the case of
>> downgrading capability when a hunspell dict would work.) Is there a
>> reason why it's more convenient to provide localized nightly builds
>> as opposed to making a language pack installed in a nightly
>> auto-update together with a nightly build?
>
> IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox.
(which is affected by things like which versions of libraries you link
to, how you compile it, etc.) as well as crashiness.
What kind of tests do distros run on their builds of Firefox? Do they
run unit tests? Perf tests?
Ben Hearsum
Nov 11, 2012, 4:13:48 PM11/11/12
to Brian Smith, Henri Sivonen, mozilla.dev.planning group
On 11/10/12 05:54 PM, Brian Smith wrote:
> Henri Sivonen wrote:
>> In the case of points #6 and #10, I don't understand well enough why
>> things are the way they are. Why do distros downgrade spellchecking
>> capability? Is it a licensing thing? (For Finnish, the proper
>> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway]
>> and is provided as an add-on, so I'm not familiar with the case of
>> downgrading capability when a hunspell dict would work.) Is there a
>> reason why it's more convenient to provide localized nightly builds
>> as opposed to making a language pack installed in a nightly
>> auto-update together with a nightly build?
>
> IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox.
>> In the case of points #6 and #10, I don't understand well enough why
>> things are the way they are. Why do distros downgrade spellchecking
>> capability? Is it a licensing thing? (For Finnish, the proper
>> spellchecker is Finnish-specific [i.e. not a hunspell dict anyway]
>> and is provided as an add-on, so I'm not familiar with the case of
>> downgrading capability when a hunspell dict would work.) Is there a
>> reason why it's more convenient to provide localized nightly builds
>> as opposed to making a language pack installed in a nightly
>> auto-update together with a nightly build?
>
> IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox.
Henri Sivonen
Nov 13, 2012, 5:27:34 AM11/13/12
to mozilla.dev.planning group
On Sun, Nov 11, 2012 at 12:54 AM, Brian Smith <bsm...@mozilla.com> wrote:
> IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox. Why not just put explicit requirements for spellchecking and other functionality that tends to be degraded (including ECC support) into the Firefox trademark policy?
It’s worth keeping in mind that the next option that distros are
> IMO, we should only let a distro call their build of Firefox "Firefox" if it is as good as our builds of Firefox. Why not just put explicit requirements for spellchecking and other functionality that tends to be degraded (including ECC support) into the Firefox trademark policy?
likely to consider if Mozilla becomes too annoying with trademarks is
no longer unbranded Firefox but Chromium.
I think it would be more fruitful to have two-way communication with
distros in order to move to a situation where Mozilla tests what
distros will ship and not only by the means of Mozilla dictating to
distros what to ship but listening to distros what sort of config
needs testing.
> Similarly, I am not sure why we can't just say that the GStreamer v.Whatever+ system library is a requirement for Firefox the same way glibc v.Whatever+ is.
that works with programs compiled against a past glibc. The
observation that started this thread was that GStreamer’s ABI does not
have that compatibility characteristic. Neither has the ABI of the
library for interfacing with Unity’s global menu.
This thread is about two things:
1) From the perspective of an ISV seeking to ship binaries, “Desktop
Linux” is full of fail and facepalm, because ABIs may not be
forward-compatible within a given distro and may not be
sideways-compatible between distros. As such an ISV, Mozilla is shy to
use APIs that it should use in order to properly integrate with the
platform.
2) As a consequence of #1, many open-source apps born in the Linux
world don’t even try to ship Linux binaries, only ship Windows and Mac
binaries (again, full of fail and facepalm) and tell users to get
their binaries from the distro. In accordance with this pattern, most
Firefox users on “Desktop Linux” get their Firefox from their distro
(in the case of e.g. Ubuntu with Ubuntu-specific platform integration
features). Yet, Mozilla pretends that it's shipping a “Desktop Linux”
product as a binary the way it is shipping Windows and Mac products.
This leads to Mozilla testing a different “Desktop Linux” product than
what most “Desktop Linux” users end up using.
(The situation with binary compatibility is quite twisted. For
example, when a new release of GIMP comes out, you can download
binaries for Windows and Mac by following links from the official site
but for various Linux distributions you either need to wait for a new
release of the distribution or use some random build from somewhere
and hope that it is legitimate. See http://www.gimp.org/downloads/
The major open source projects that still ship binaries seem to be the
ones that have their own GUI toolkit that uses Gtk mainly for theming:
Firefox, Eclipse and LibreOffice.
If you want ABI compatibility across Linux distributions and versions,
the best bet is probably writing to Win32 and using Wine!)
>> To me, point #8 looks the strongest. Is it feasible to automatically
>> rearrange the contents of a .deb or an .rpm into tarball whose
>> contents run on the same distro that the .deb or .rpm package would
>> run on? That is, if .deb and .rpm nightlies were the solution for
>> getting builds that auto-update and reflect the configuration of the
>> builds that most of our Linux users end up using when they obtain
>> release builds from their distro, would it be feasible to produce
>> tarballs for regression bisection by munging the .deb and .rpm
>> packages into tarballs without having to spend infrastructure
>> resources to recompile?
>
> I thought that RPM was the standard, as far as the Linux Standard Base is a standard for Linux.
What matters is what systems our end-users use are like. (Where “our”
includes users of distro-provided Firefox builds.)
> My understanding is that Debian and Ubuntu can install RPMs without too much hassle using alien.
actually works? For starters, alien is not installed by default on
Ubuntu and there does not seem to be any GUI facilities for installing
downloaded .rpm packages.
I managed to locate Maxima as an example of a non-trivial app that is
distributed as a set of supposedly distro-independent .rpm files and
not distributed as a .deb, but the .rpm files were only available as
32-bit and alien on 64-bit Ubuntu can't deal with 32-bit .rpm files,
so I couldn’t test further.
> I also understand that it is possible to create RPMs that are relocatable so that users can install them in their home directories, or wherever, without being root; see rpm --relocate. It seems alien also understands relocatable packages. So, it seems to me like we should be able to build a single RPM that has a dependency on the GStreamer package and whatever, and call it a day. Would that solve the problems you're trying to solve?
ABI discontinuity. Also, having a single RPM build would not solve the
problem of Mozilla testing a different config than what Linux users
end up using.
> It might be nice for marketing reasons if we could create a .deb too, if it is not a lot of work.
.deb at the same time.
0 new messages