[arch-dev-public] Potential removal of Chromium in ~2 months
Just a quick heads up that I am considering dropping Chromium from [extra] a week or two before the Chromium 82 stable release (~April 28). The reason for this is that our API keys no longer work for geolocation requests and there is no clear upstream guidance on how to resolve this issue. [1] When I created these API keys back in 2013, there was a semi-official effort by the Chrome Team to support distro builds of Chromium in regard to accessing Google APIs; a few minor hiccups along the way were quickly resolved. I feel this arrangement is starting to fall apart (in spite of some upstream Chrome developers' best efforts). To make a long story short, I consider broken geolocation sufficient reason for removal. I don't mind it being broken for my own use, but shipping a package with broken functionality due to lack of upstream support does not sit well with me. To protect against systems with outdated Chromium (following the stable release of version 82), at the beginning of April I intend to post a news item about the need to switch to another browser. That is assuming no solution is found and nobody objects to the removal or wishes to continue maintenance of the package with reduced functionality. [1] https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/Zy...
On Sat, Feb 22, 2020 at 07:50:58AM +0200, Evangelos Foutras via arch-dev-public wrote:
Just a quick heads up that I am considering dropping Chromium from [extra] a week or two before the Chromium 82 stable release (~April 28). The reason for this is that our API keys no longer work for geolocation requests and there is no clear upstream guidance on how to resolve this issue. [1]
We've talked about this. You're well aware that this isn't an accurate portrayal of the situation. I'm happy to guide you (or anyone else) through the remedy. What you're looking for is continuation of the preferential treatment that distros have historically received and unfortunately, that avenue has changed shape. Your gripe seems to be focused on the requirement of having a billing account now, regardless of the fact that the end goal is the same -- for distros (non-profits) to have free access.
When I created these API keys back in 2013, there was a semi-official effort by the Chrome Team to support distro builds of Chromium in regard to accessing Google APIs; a few minor hiccups along the way were quickly resolved. I feel this arrangement is starting to fall apart (in spite of some upstream Chrome developers' best efforts).
To make a long story short, I consider broken geolocation sufficient reason for removal. I don't mind it being broken for my own use, but shipping a package with broken functionality due to lack of upstream support does not sit well with me.
The short story doesn't accurately reflect reality. There's still upstream support, you've just not been willing to conform to the new officially supported process.
To protect against systems with outdated Chromium (following the stable release of version 82), at the beginning of April I intend to post a news item about the need to switch to another browser. That is assuming no solution is found and nobody objects to the removal or wishes to continue maintenance of the package with reduced functionality.
If anyone wants help in getting Geolocation working again, please let me know. dR
To make a long story short, I consider broken geolocation sufficient reason for removal. I don't mind it being broken for my own use, but shipping a package with broken functionality due to lack of upstream support does not sit well with me.
The short story doesn't accurately reflect reality. There's still upstream support, you've just not been willing to conform to the new officially supported process.
To protect against systems with outdated Chromium (following the stable release of version 82), at the beginning of April I intend to post a news item about the need to switch to another browser. That is assuming no solution is found and nobody objects to the removal or wishes to continue maintenance of the package with reduced functionality.
If anyone wants help in getting Geolocation working again, please let me know.
I'm curious, do you have a reference on how the process has changed? I think it'd be easier for people to gauge interest if they know what the new process entails. I'm also wondering if the billing requirement could be handled by SPI or some other organization-level approach.... Thanks! -Santiago
On Sat, Feb 22, 2020 at 09:59:00AM -0500, Santiago Torres-Arias via arch-dev-public wrote:
To make a long story short, I consider broken geolocation sufficient reason for removal. I don't mind it being broken for my own use, but shipping a package with broken functionality due to lack of upstream support does not sit well with me.
The short story doesn't accurately reflect reality. There's still upstream support, you've just not been willing to conform to the new officially supported process.
To protect against systems with outdated Chromium (following the stable release of version 82), at the beginning of April I intend to post a news item about the need to switch to another browser. That is assuming no solution is found and nobody objects to the removal or wishes to continue maintenance of the package with reduced functionality.
If anyone wants help in getting Geolocation working again, please let me know.
I'm curious, do you have a reference on how the process has changed? I think it'd be easier for people to gauge interest if they know what the new process entails. I'm also wondering if the billing requirement could be handled by SPI or some other organization-level approach....
The old process was essentially "know someone on the inside". Billing and access for Maps-based APIs has a loooooooong history. It existed before Google was really in the business of selling other APIs. Thus, it's gone through multiple iterations and a somewhat independent evolution. Lately, that's changed and it's now using standard internal infrastructure. As a side effect, the backdoor that Chrome developers used to be able to provide to distros is no longer available The new process is well-described here: https://support.google.com/nonprofits/answer/3367237?hl=en dR
I'm curious, do you have a reference on how the process has changed? I think it'd be easier for people to gauge interest if they know what the new process entails. I'm also wondering if the billing requirement could be handled by SPI or some other organization-level approach....
The old process was essentially "know someone on the inside". Billing and access for Maps-based APIs has a loooooooong history. It existed before Google was really in the business of selling other APIs. Thus, it's gone through multiple iterations and a somewhat independent evolution. Lately, that's changed and it's now using standard internal infrastructure. As a side effect, the backdoor that Chrome developers used to be able to provide to distros is no longer available
The new process is well-described here:
Thank you! it appears to me that this would probably require for the distro step in to get the NGO account, which I also think would make it easier to transfer responsibilities between team members on different G-controlled products. -Santiago
On 22/02/2020 14:31, Dave Reisner wrote:
We've talked about this. You're well aware that this isn't an accurate portrayal of the situation. I'm happy to guide you (or anyone else) through the remedy. What you're looking for is continuation of the preferential treatment that distros have historically received and unfortunately, that avenue has changed shape. Your gripe seems to be focused on the requirement of having a billing account now, regardless of the fact that the end goal is the same -- for distros (non-profits) to have free access.
If the remedy consists of creating a billing account, applying as a non-profit, or opening support tickets, I am still going to give it a pass.
The short story doesn't accurately reflect reality. There's still upstream support, you've just not been willing to conform to the new officially supported process.
But it does reflect reality; it has been broken for a month and my post on chromium-packagers has proved to be a dead end. On the mailing list dedicated to Chromium packagers, there has been zero official guidance on the issue.
If anyone wants help in getting Geolocation working again, please let me know.
If anyone wants to give a go, feel free to ping me on IRC for access to the project in the API Console.
participants (3)
-
Dave Reisner
-
Evangelos Foutras
-
Santiago Torres-Arias