Support from Google on issues reported on Chromium

[Raymond Wooninck]

Hi,

One of our users reported an issue with chromium not working as it should on a
Bulgarian bank website. We are currently looking into the issue, but it seems
more that there was something wrong with the 48.0.2564.83 build, as that the
latest chromium-dev build does not show the issue. At this moment I am hoping
that the users issue would be resolved with the 48.0.2565.103 build which was
released last week.

However this is not the point. The point is that the issue was nicely reported
on the chromium issues website (https://code.google.com/p/chromium/issues/
detail?id=585053), but instead of getting help, he got the following messages:

"This is a WontFix on our end then. You'll have to talk to your distributor.
We don't maintain the unbranded Chromium builds and everyone has their own
random patches to it that we certainly can't support."

and

"If you're using something called "Chromium" from a Linux distribution, it's
usually patched by them. You should file a bug with openSUSE Leap. That it
works in Chrome and a trunk build of Chromium but not openSUSE Leap Chromium
suggests it's because of some openSUSE Leap change."

Despite that the user indicated the version of chromium (48.0.2564.83, which
is the previous stable build), the issue was only quickly tested on chromium
trunk and then dismissed as "complain to your distro, they must have patched
it".

Is this really the support we are getting from Google for Chromium issues ?
If that is the case, is there any reason why we actually still want to
maintain and distribute this browser ?? At least for openSUSE (and I am sure
that many other distro's are doing the same), I am trying to build with at
least patches as possible and the patches we have are either just for to fix
building with higher GCC versions, etc.

Raymond
openSUSE Chromium packager

[Michael Moss]

In that particular bug, the user also says:

"In Chrome and Firefox everything works as expected but not in Chromium."

which suggested the issue was something specific to that Chromium build. While the difference was probably just that they tested different versions of Chrome vs. Chromium, and the correct response might have been "this should be fixed when your distro releases version x.x.x.x of Chromium", I wouldn't say it was completely clear in this case.

However, I agree with your general concern that we shouldn't be dismissively "blaming the distro". It's definitely not our desire to have users chasing all over filing bug reports, or to unnecessarily increase the support burden on distros, so please do bring it to our attention if you find bugs where you feel that's happening.

Michael

--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/55964584.xMcxKoO5g8%40hqvmt44011.eur.cchbc.com.

[Paweł Hajdan, Jr.]

+1 to what mmoss@ said. In fact, that was one of the reasons for creating this ML - to create an escalation path for cases like this. Please continue doing so.

On the other hand, in case of https://code.google.com/p/chromium/issues/detail?id=585053 , the reporter refused to provide a net-internal trace even with fake credentials. I consider that a legitimate reason why a developer could have closed that bug.

Did he end up filing OpenSUSE bug? Did the issue eventually get resolved? Please let me know if I can still help somehow.

Paweł

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAKs%2B6oPm8Y7gH9VhwWXDkOMcQSkQD02tPGYnxZ9vNDL4DECrZg%40mail.gmail.com.

[Raymond Wooninck]

Hi Pawel.

On Thursday, 11 February 2016 13:49:15 CET Paweł Hajdan, Jr. wrote:
> On the other hand, in case of
> https://code.google.com/p/chromium/issues/detail?id=585053 , the reporter
> refused to provide a net-internal trace even with fake credentials. I
> consider that a legitimate reason why a developer could have closed that
> bug.

There are limitations to what an average user can provide :) I agreed with
the fact that the bug was closed with the indication to report it first with
the distribution. The only item that I wanted to highlight, which also the
user reported on the openSUSE bug, was the fact that it appeared as if
Chromium build by distributions was not support as that there are too many
patches, etc.

> Did he end up filing OpenSUSE bug? Did the issue eventually get resolved?

He indeed filed an openSUSE bug and that is how I got involved :) The issue got
resolved and the user is happy again :)

> Please let me know if I can still help somehow.

Well, we still actually have the issue of the missing tarballs :) Last night
a new DEV snapshot was publish and again no tarball. Also the latest Stable
tarball is still not there.

Regards

Raymond

[Raymond Wooninck]

On Thursday, 11 February 2016 13:49:15 CET Paweł Hajdan, Jr. wrote:

> +1 to what mmoss@ said. In fact, that was one of the reasons for creating
> this ML - to create an escalation path for cases like this. Please continue
> doing so.

Well, I guess you have now a situation where you can prove your support to
distributions shipping Chromium. Already for more than 2 weeks, the tarballs
for the stable, beta and dev channels have not been published. This has been
reported in this list and I even created an issue https://code.google.com/p/
chromium/issues/detail?id=584647 but without any follow-up nor resolution.

If you really have the intention to support distributions, then this is the
first thing to resolve. Tarballs are required in order to provide the latest
chromium builds to our users. Without tarballs there is nothing that we can
do.

This is getting ridiculous that something that is so fundamental to the
support of chromium is just left unresolved.

If this continues longer, then I would be forced to remove the Chromium builds
from openSUSE for security reasons as that Chromium appears no longer
maintained

REgards

Raymond

[Christoph Moench-Tegeder]

## Raymond Wooninck (titti...@gmail.com):

> Well, I guess you have now a situation where you can prove your support to
> distributions shipping Chromium. Already for more than 2 weeks, the tarballs
> for the stable, beta and dev channels have not been published. This has been
> reported in this list and I even created an issue https://code.google.com/p/
> chromium/issues/detail?id=584647 but without any follow-up nor resolution.

Unfortunately, that issue isn't even visible to the general public.

The unavailability of source tarballs is a huge burden for every
platform not supported by the binary builds (as well as any distribution
which needs to build packages from source) - the latest .109 fixes
several vulnerabilities with severity "high", but without tarballs
the update is rather messy (and not really suitable for e.g. the FreeBSD
packages, with which I'm involved).

Regards,
Christoph

--
Spare Space

[Raymond Wooninck]

On Saturday, 13 February 2016 13:24:30 CET Christoph Moench-Tegeder wrote:
> ## Raymond Wooninck (titti...@gmail.com):
> > Well, I guess you have now a situation where you can prove your support to
> > distributions shipping Chromium. Already for more than 2 weeks, the
> > tarballs for the stable, beta and dev channels have not been published.
> > This has been reported in this list and I even created an issue
> > https://code.google.com/p/ chromium/issues/detail?id=584647 but without
> > any follow-up nor resolution.
> Unfortunately, that issue isn't even visible to the general public.

I raised the issue on Feb 5 in the category infrastructure. I believed this
was the best category as that the rest are more chromium functionality
related. On the 8th the bug was assigned to Pawel Hadjan jr, but that is it.

> The unavailability of source tarballs is a huge burden for every
> platform not supported by the binary builds (as well as any distribution
> which needs to build packages from source) - the latest .109 fixes
> several vulnerabilities with severity "high", but without tarballs

I know and I am in the same position. Yes, I can point out to users that they
should start installing Chrome, but is this really the solution ? If that is
the case then it seems as if Google is cutting off the chromium builds on
distributions and only willing to support the Google Chrome builds.

Raymond

[Dirk Pranke]

I apologize for the troubles.

I do not know at the moment why the tarballs are missing. Unfortunately, I

think the people who know this part of the system best have been out for

one reason or another, and some of the others who could help have been

busy with other fires.

To the best of my knowledge, this is not an intentional change. I also don't

know why that bug was marked as restricted; I've cleared the restriction.

Hopefully we can get someone to look at this soon.

-- Dirk

[Michael Moss]

I'm also not familiar with the tarball generation process, but as an aside, why are they even necessary? Why isn't it preferred to get the sources straight from the git repositories, just like a developer doing a personal build might do? And if you really need a tarball for your particular release workflow, why not still fetch from git and then generate your own tarballs as needed? That would both keep you more up-to-date and, after the initial checkout, require you to fetch much less data on a regular basis.

None of this is to say that we shouldn't or won't fix the current process, but I'm genuinely curious why it's at all desirable.

Michael

--

You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAEoffTCS8H5jrzuy2DZ41jT5d%3DRGeB8JiV-OJtu7r_gQ6LFRtQ%40mail.gmail.com.

[René Ladan]

Op 15 feb. 2016 19:53 schreef "'Michael Moss' via chromium-packagers" <chromium-...@chromium.org>:

>
> I'm also not familiar with the tarball generation process, but as an aside, why are they even necessary? Why isn't it preferred to get the sources straight from the git repositories, just like a developer doing a personal build might do? And if you really need a tarball for your particular release workflow, why not still fetch from git and then generate your own tarballs as needed? That would both keep you more up-to-date and, after the initial checkout, require you to fetch much less data on a regular basis.
>

Fetching straight from git is currently not supported by FreeBSD,  and given the complexity of fetching the source code for Chromium and all of its dependencies I do not see that as a feasible alternative for the average user (or the package building cluster).

Happily test-building the new Stable version now.

René

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAKs%2B6oN64vbLAP9R4Xh5yVnw6HQGpAVg7h0rmLAQQafn9f_9qg%40mail.gmail.com.

[Mike Frysinger]

"git is better than tarballs" is objectively incorrect in a number of scenarios:

https://groups.google.com/a/chromium.org/d/msg/chromium-dev/1cfARm3qzQI/aqCetKzXSIQJ

as for generating your own tarballs, it seems reasonable for Google to host these since multiple distros want this, and their size is not trivial.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAKs%2B6oN64vbLAP9R4Xh5yVnw6HQGpAVg7h0rmLAQQafn9f_9qg%40mail.gmail.com.

[Christoph Moench-Tegeder]

## René Ladan (re...@freebsd.org):

> Fetching straight from git is currently not supported by FreeBSD, and
> given the complexity of fetching the source code for Chromium and all of
> its dependencies I do not see that as a feasible alternative for the
> average user (or the package building cluster).

I'd even believe that most distributions/package builders have an
option for saving the "intermediary" git tree. Further, uploading
tarballs >0.5GB (source+testdata) could be rather slow for a random
user - better let Google generate and host the tarballs.

[Robert Nagy]

Using git in this case would not have been useful either since the DEPS
file was pointing to unavailable commits for libjingle and webrtc,
so I don't see show using git would have been of any help if gclient
sync would fail.

> > > distributions shipping Chromium.A Already for more than 2

> weeks, the
> > > tarballs for the stable, beta and dev channels have not been
> published.
> > > This has been reported in this list and I even created an issue

> > > https://code.google.com/p/ chromium/issues/detail?id=584647A

> https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAAbOSckDBDRpQK1mxKVZEDP5nWroRO98K4iVPQ0EkoPp5Dp-Aw%40mail.gmail.com.

[Michael Moss]

This isn't (I think) about having a tarball to bootstrap a normal checkout. This is about repeatedly downloading tarballs of specific releases as the primary (only?) way of getting the sources. That seems a lot less efficient than having a git-based checkout from which you generate release tarballs as needed.

[Michael Moss]

On Mon, Feb 15, 2016 at 11:40 AM, René Ladan <re...@freebsd.org> wrote:

Op 15 feb. 2016 19:53 schreef "'Michael Moss' via chromium-packagers" <chromium-...@chromium.org>:
>
> I'm also not familiar with the tarball generation process, but as an aside, why are they even necessary? Why isn't it preferred to get the sources straight from the git repositories, just like a developer doing a personal build might do? And if you really need a tarball for your particular release workflow, why not still fetch from git and then generate your own tarballs as needed? That would both keep you more up-to-date and, after the initial checkout, require you to fetch much less data on a regular basis.
>
Fetching straight from git is currently not supported by FreeBSD

Could you elaborate? Is it technically not supported, like, FreeBSD doesn't have the necessary tools or access? Or it's not supported by policy? 

,  and given the complexity of fetching the source code for Chromium and all of its dependencies I do not see that as a feasible alternative for the average user (or the package building cluster) 

Happily test-building the new Stable version now.

[Mike Frysinger]

the issues outlined in that thread apply here ... the use of said tarball is irrelevant.

git sucks for firewalls, bad network connections, and for distributing load.

-mike

[Raphael Kubo da Costa]

'Michael Moss' via chromium-packagers <chromium-...@chromium.org>

writes:

> On Mon, Feb 15, 2016 at 11:40 AM, René Ladan <re...@freebsd.org> wrote:
>
>>
>> Op 15 feb. 2016 19:53 schreef "'Michael Moss' via chromium-packagers" <
>> chromium-...@chromium.org>:
>> >
>> > I'm also not familiar with the tarball generation process, but as an
>> aside, why are they even necessary? Why isn't it preferred to get the
>> sources straight from the git repositories, just like a developer doing a
>> personal build might do? And if you really need a tarball for your
>> particular release workflow, why not still fetch from git and then generate
>> your own tarballs as needed? That would both keep you more up-to-date and,
>> after the initial checkout, require you to fetch much less data on a
>> regular basis.
>> >
>> Fetching straight from git is currently not supported by FreeBSD
>>
> Could you elaborate? Is it technically not supported, like, FreeBSD doesn't
> have the necessary tools or access? Or it's not supported by policy?

I think René misunderstood your suggestion and was saying that setting
up depot_tools and fetching Chromium via gclient sync as part of the
package building process would not fly, not that it is not possible to
do that, create a tarball and then use that as the source to build
package.

[René Ladan]

2016-02-16 11:45 GMT+01:00 Raphael Kubo da Costa
<raphael.ku...@intel.com>:

> 'Michael Moss' via chromium-packagers <chromium-...@chromium.org>
> writes:
>
>> On Mon, Feb 15, 2016 at 11:40 AM, René Ladan <re...@freebsd.org> wrote:
>>
>>>
>>> Op 15 feb. 2016 19:53 schreef "'Michael Moss' via chromium-packagers" <
>>> chromium-...@chromium.org>:
>>> >
>>> > I'm also not familiar with the tarball generation process, but as an
>>> aside, why are they even necessary? Why isn't it preferred to get the
>>> sources straight from the git repositories, just like a developer doing a
>>> personal build might do? And if you really need a tarball for your
>>> particular release workflow, why not still fetch from git and then generate
>>> your own tarballs as needed? That would both keep you more up-to-date and,
>>> after the initial checkout, require you to fetch much less data on a
>>> regular basis.
>>> >
>>> Fetching straight from git is currently not supported by FreeBSD
>>>
>> Could you elaborate? Is it technically not supported, like, FreeBSD doesn't
>> have the necessary tools or access? Or it's not supported by policy?
>
> I think René misunderstood your suggestion and was saying that setting
> up depot_tools and fetching Chromium via gclient sync as part of the
> package building process would not fly, not that it is not possible to
> do that, create a tarball and then use that as the source to build
> package.
>

Indeed, like Raphael says.

Using git/gclient for development works fine on FreeBSD (until it
stumbles upon the first error),
but indeed for package building one wants to have a simple tarball.

Regards,
René

>>> , and given the complexity of fetching the source code for Chromium and
>>> all of its dependencies I do not see that as a feasible alternative for the
>>> average user (or the package building cluster)
>

> --
> You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/87h9h9szlu.fsf%40rkubodac-desk.ger.corp.intel.com.



--
http://www.rene-ladan.nl/