[arch-dev-public] Packaging Chromium for [extra]
Hi devs, I did have a closer look at chromium recently and it did improve a lot. Even though it's called "beta" it is really usable and feature complete. There is quite a high demand for it (the binary version in AUR has neraly 800 votes). I would like to make a peoper package for it and provide that in our repo. The AUR packages are either svn trunk builds or repackaged ubuntu debs with ugly symlinks to libs with other so names. My idea is to build a tar out of their svn tag and build a clean package with that. What do you think? (it's about chromium btw. and not Chrome which is Google's build with some "extras") -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 12/09/2009 02:47 PM, Pierre Schmitz wrote:
Hi devs,
I did have a closer look at chromium recently and it did improve a lot. Even though it's called "beta" it is really usable and feature complete.
There is quite a high demand for it (the binary version in AUR has neraly 800 votes). I would like to make a peoper package for it and provide that in our repo.
The AUR packages are either svn trunk builds or repackaged ubuntu debs with ugly symlinks to libs with other so names.
My idea is to build a tar out of their svn tag and build a clean package with that.
What do you think? (it's about chromium btw. and not Chrome which is Google's build with some "extras")
i don't have any objections about having a chromium package in our repos.
I've already thought about this a few times though I haven't used it mayself so far. I have a big problem with google's way violating users privacy. That's the reason I'd rather like to see us packaging Iron: http://www.srware.net/en/software_srware_iron.php Another major issue I see is the included 3rd branch of webkit. Right we package webkit-gtk and Qt ships it's own webkit. It would be stupid to build another browser inclusing its own static webkit branch. And there's one more major issue: Google calls their software open source. But the development process is happing behind closed doors. For now: -1 from me for any Google applications in our official repos. But I can imagine to provide Iron packaged in the community repo. -Andy
Am Mittwoch 09 Dezember 2009 14:15:44 schrieb Andreas Radke:
I've already thought about this a few times though I haven't used it mayself so far.
I have a big problem with google's way violating users privacy. That's the reason I'd rather like to see us packaging Iron: http://www.srware.net/en/software_srware_iron.php
Another major issue I see is the included 3rd branch of webkit. Right we package webkit-gtk and Qt ships it's own webkit. It would be stupid to build another browser inclusing its own static webkit branch.
And there's one more major issue: Google calls their software open source. But the development process is happing behind closed doors.
For now: -1 from me for any Google applications in our official repos. But I can imagine to provide Iron packaged in the community repo.
-Andy
I have more objections against Iron. There is no vcs, bug tracker, mailinglist etc. and the soruces are hosted on rapidshre (wtf?). The privacy thing can be disabl by GUI; of course users should know wht they are doing. Btw: firefox has similiar issues. They indeed provide some of their modified 3rdpart libs (like webkit, ffmpeg...). But they are trying to get those thing upstream. But there are things that require chagnes to that 3rd party code. Lot's of projects are doing this: Qt, php etc. The have mailinglist, irc and a public bug tracker etc.. So I don't really get your problem. I am not that happy with some/most of their services either and would never use e.g. gmail. But there work at chromium is not that bad compared to other open source projects. I think we should stay objective and fair. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Dec 9, 2009 at 6:47 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Hi devs,
I did have a closer look at chromium recently and it did improve a lot. Even though it's called "beta" it is really usable and feature complete.
There is quite a high demand for it (the binary version in AUR has neraly 800 votes). I would like to make a peoper package for it and provide that in our repo.
The AUR packages are either svn trunk builds or repackaged ubuntu debs with ugly symlinks to libs with other so names.
My idea is to build a tar out of their svn tag and build a clean package with that.
What do you think? (it's about chromium btw. and not Chrome which is Google's build with some "extras")
Sounds good to me
Am Mittwoch 09 Dezember 2009 13:47:20 schrieb Pierre Schmitz:
My idea is to build a tar out of their svn tag and build a clean package with that.
As there were some objections about this I have put chromium into [testing] and not straight to [extra]. So we can have a look at it and remove it later if we conclude that it just sucks. :-) I kept the package as clean and close to upstream as possible. There is only one small patch for the build system to disable SSE2 because its not part of the i686 construction set. For now there are just svn tags and no released source packages. So the biggest challenge was to create one myself using their funky build system. As they include lots of third party stuff the source tar is really big; about 110MB. If you want to create a new one, adjust the pkgrel to some of http://src.chromium.org/svn/releases/ source the PKGBUILD and run _source. (downloads lots of stuff; takes about 30min) I initially wanted to follow their beta branch (e.g. 4.0.249.34) but I couldn't get it building. So for now we have a development snapshot. (suggestions are welcome) For some unknown reason the current package crashes with flash sometimes. Any ideas? Or maybe it's just me? Pierre PS: I think I got the sandbox feature working. So don't be afraid of the suid binary. That is needed to chroot each browser tab. (otherwise you'll need selinux or seccomp; the latter didn't really work for me) -- Pierre Schmitz, https://users.archlinux.de/~pierre
2009/12/10, Pierre Schmitz <pierre@archlinux.de>:
For some unknown reason the current package crashes with flash sometimes. Any ideas? Or maybe it's just me?
I'm using it with many flash site and it works fine. No crash here. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Am Freitag 11 Dezember 2009 00:51:56 schrieb Giovanni Scafora:
2009/12/10, Pierre Schmitz <pierre@archlinux.de>:
For some unknown reason the current package crashes with flash sometimes. Any ideas? Or maybe it's just me?
I'm using it with many flash site and it works fine. No crash here.
Maybe you were just lucky. It was confirmed by others in the meantime. I tried compiling with no_strict_aliasing and it seems to solve the issue so far. But I need more testing to make sure it's really related. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Freitag 11 Dezember 2009 03:40:04 schrieb Pierre Schmitz:
Am Freitag 11 Dezember 2009 00:51:56 schrieb Giovanni Scafora:
2009/12/10, Pierre Schmitz <pierre@archlinux.de>:
For some unknown reason the current package crashes with flash sometimes. Any ideas? Or maybe it's just me?
I'm using it with many flash site and it works fine. No crash here.
Maybe you were just lucky. It was confirmed by others in the meantime. I tried compiling with no_strict_aliasing and it seems to solve the issue so far. But I need more testing to make sure it's really related.
OK, just uploaded -2 to testing; let me know, if it does work or not. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Pierre Schmitz schrieb:
PS: I think I got the sandbox feature working. So don't be afraid of the suid binary. That is needed to chroot each browser tab. (otherwise you'll need selinux or seccomp; the latter didn't really work for me)
If you just want chroot, "setcap cap_sys_chroot +ep /usr/bin/whatever" is sufficient. Setuid on a browser is the worst idea I ever heard - especially for a feature that is supposed to provide extra security.
Am Freitag 11 Dezember 2009 01:02:34 schrieb Thomas Bächler:
If you just want chroot, "setcap cap_sys_chroot +ep /usr/bin/whatever" is sufficient.
The point is that it does not work. See http://src.chromium.org/svn/releases/4.0.267.0/src/chrome/browser/zygote_hos... At least I didn't get it working; but it might be possible. A good starting point is http://code.google.com/p/chromium/wiki/LinuxSandboxing -- Pierre Schmitz, https://users.archlinux.de/~pierre
Pierre Schmitz schrieb:
Am Freitag 11 Dezember 2009 01:02:34 schrieb Thomas Bächler:
If you just want chroot, "setcap cap_sys_chroot +ep /usr/bin/whatever" is sufficient.
The point is that it does not work. See http://src.chromium.org/svn/releases/4.0.267.0/src/chrome/browser/zygote_hos...
At least I didn't get it working; but it might be possible. A good starting point is http://code.google.com/p/chromium/wiki/LinuxSandboxing
It checks explicitly whether the "sandbox binary" is setuid, which is as stupid as using a setuid binary in the first place. What does the "sandbox binary" even do exactly? If you really need setuid for it, it's certainly a stupid design.
On Fri, 11 Dec 2009 09:21:39 +0100, Thomas Bächler <thomas@archlinux.org> wrote:
Pierre Schmitz schrieb:
Am Freitag 11 Dezember 2009 01:02:34 schrieb Thomas Bächler:
If you just want chroot, "setcap cap_sys_chroot +ep /usr/bin/whatever"
is sufficient.
The point is that it does not work. See
http://src.chromium.org/svn/releases/4.0.267.0/src/chrome/browser/zygote_hos...
At least I didn't get it working; but it might be possible. A good starting point is http://code.google.com/p/chromium/wiki/LinuxSandboxing
It checks explicitly whether the "sandbox binary" is setuid, which is as
stupid as using a setuid binary in the first place. What does the "sandbox binary" even do exactly? If you really need setuid for it, it's
certainly a stupid design.
Using a suid helper binary is just used as a fallback on systems where you don't have apparmor, selinux and such. They are working on a seccomp implementation though and if I read our kernel config correctly we have supprot for that. So hacking up a sandbox implementation which uses capabilities to chroot wont be worth the effort as the suid sansbox is a temporary solution anyway. Fun fact: due to its design netscape plugins cannot be sandboxed; so you could simply compromise chromium by a flashplugin exploit I guess. Another reason why we should get rid of flash soon. -- Pierre Schmitz, https://users.archlinux.de/~pierre
So, the package is getting better. As you might have noticed I downgraded from 4.0.267.0 to 4.0.249.30. This is the same version as the official Chrome beta for Linux. The previous one was just a trunk snapshot. The plan is to follow the beta branch until a stable version is released. I also know why the beta did never build for me (that's why I choosed a snapshot). There was a src branch within the http://src.chromium.org/svn/releases/4.0.249.30/ dir which confused the gclient tool. Long story short: it pulled the wrong webkit and other revsions which did not match the chromium version. It was just luck that the previous package wirked at all. I also fixed setting the default browser from within chromium and enabled h264 codecs etc.. This package should now be ready to be moved to extra. For those who are unsure about their privacy: See http://en.wikipedia.org/wiki/Google_Chrome#Usage_tracking RLZ, the clientID and bugtracker thing isn't included in chromium anyway and everything else can be easily disabled/changed in the optinos menu. Btw: Firefox uses the exact same services by default. To underline this: there are no secret call home functions in this package and you still have full controll over your data. Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
After enough testing I'll move chromium to [extra] now. Thanks for the feedback. Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (6)
-
Aaron Griffin
-
Andreas Radke
-
Giovanni Scafora
-
Ionut Biru
-
Pierre Schmitz
-
Thomas Bächler