Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Chromium bundled code

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


vapier at gentoo

Apr 30, 2012, 9:11 AM

Post #1 of 44 (1815 views)
Permalink
Chromium bundled code

On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
> doing it wrong. I don't like how Google develops Android in the dark,
> or that they bundle 1GB of third-party stuff in their Chromium source
> and distribute a favored binary-only derivative.

err, they distribute a Chromium source tarball, and their build system
includes flags to use the system versions of those bundled libs if you so
choose. i think this is a perfectly fine compromise.
-mike
Attachments: signature.asc (0.82 KB)


rich0 at gentoo

Apr 30, 2012, 9:28 AM

Post #2 of 44 (1792 views)
Permalink
Re: Chromium bundled code [In reply to]

On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier [at] gentoo> wrote:
> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> doing it wrong. I don't like how Google develops Android in the dark,
>> or that they bundle 1GB of third-party stuff in their Chromium source
>> and distribute a favored binary-only derivative.
>
> err, they distribute a Chromium source tarball, and their build system
> includes flags to use the system versions of those bundled libs if you so
> choose. i think this is a perfectly fine compromise.

Must be a fairly new compromise - but glad to hear that they've come
along a bit.

Maybe their future Google Earth install package for Linux won't bundle wine. :)

In any case, I think this really just gets to my point - people who
develop FOSS aren't doing it with the express goal of making your life
difficult - they just don't always have the same itches. If you help
them out or ask NICELY sometimes they'll even help scratch yours.

Rich


mattst88 at gentoo

Apr 30, 2012, 9:32 AM

Post #3 of 44 (1792 views)
Permalink
Re: Chromium bundled code [In reply to]

On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier [at] gentoo> wrote:
> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> doing it wrong. I don't like how Google develops Android in the dark,
>> or that they bundle 1GB of third-party stuff in their Chromium source
>> and distribute a favored binary-only derivative.
>
> err, they distribute a Chromium source tarball, and their build system
> includes flags to use the system versions of those bundled libs if you so
> choose. i think this is a perfectly fine compromise.
> -mike

It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
libraries, and still has TODOs in place to use the system's ffmpeg,
hunspell, (Open?)SSL, SQLite, and libvpx.


vapier at gentoo

Apr 30, 2012, 10:30 AM

Post #4 of 44 (1793 views)
Permalink
Re: Chromium bundled code [In reply to]

On Monday 30 April 2012 12:32:35 Matt Turner wrote:
> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
> >> doing it wrong. I don't like how Google develops Android in the dark,
> >> or that they bundle 1GB of third-party stuff in their Chromium source
> >> and distribute a favored binary-only derivative.
> >
> > err, they distribute a Chromium source tarball, and their build system
> > includes flags to use the system versions of those bundled libs if you so
> > choose. i think this is a perfectly fine compromise.
>
> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
> libraries

to be sure the system ones get used

> and still has TODOs in place to use the system's ffmpeg,
> hunspell, (Open?)SSL, SQLite, and libvpx.

it's on going work :). ffmpeg/libvpx are a bit harder as Chromium syncs faster
than they make releases i believe.
-mike
Attachments: signature.asc (0.82 KB)


floppym at gentoo

Apr 30, 2012, 10:42 AM

Post #5 of 44 (1794 views)
Permalink
Re: Chromium bundled code [In reply to]

On Mon, Apr 30, 2012 at 1:30 PM, Mike Frysinger <vapier [at] gentoo> wrote:
> On Monday 30 April 2012 12:32:35 Matt Turner wrote:
>> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
>> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> >> doing it wrong.  I don't like how Google develops Android in the dark,
>> >> or that they bundle 1GB of third-party stuff in their Chromium source
>> >> and distribute a favored binary-only derivative.
>> >
>> > err, they distribute a Chromium source tarball, and their build system
>> > includes flags to use the system versions of those bundled libs if you so
>> > choose.  i think this is a perfectly fine compromise.
>>
>> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
>> libraries
>
> to be sure the system ones get used
>
>> and still has TODOs in place to use the system's ffmpeg,
>> hunspell, (Open?)SSL, SQLite, and libvpx.
>
> it's on going work :).  ffmpeg/libvpx are a bit harder as Chromium syncs faster
> than they make releases i believe.
> -mike

Right. Generally, the bundled ffmpeg does not correspond to an
official upstream release.

ffmpeg upstream is not afraid of making API changes, so it has proven
quite difficult to make chromium work with all versions on ffmpeg in
portage, plus the bundled snapshot. When we were using the system lib,
it would break nearly every time a new major version of chromium was
forked.


phajdan.jr at gentoo

May 3, 2012, 2:34 AM

Post #6 of 44 (1794 views)
Permalink
Re: Chromium bundled code [In reply to]

On 4/30/12 6:32 PM, Matt Turner wrote:
> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier [at] gentoo> wrote:
>> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>>> doing it wrong. I don't like how Google develops Android in the dark,
>>> or that they bundle 1GB of third-party stuff in their Chromium source
>>> and distribute a favored binary-only derivative.
>>
>> err, they distribute a Chromium source tarball, and their build system
>> includes flags to use the system versions of those bundled libs if you so
>> choose. i think this is a perfectly fine compromise.

Right, and the source tarball is ~175 MB. It's not perfect, but it's
also far from 1 GB. The bundled libraries are included in the tarball.

> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
> libraries.

Note that the list in the ebuild is about _excluding_ bundled libraries,
i.e. the directories listed are removed and everything else is removed.

I'm generally co-operating with upstream (also as part of that upstream,
but with limited resources at least for now) so that there are options
to use system libraries, and what's left is non-trivial to unbundle
(e.g. mesa) but it should be unbundled at some point.

> and still has TODOs in place to use the system's ffmpeg,
> hunspell, (Open?)SSL, SQLite, and libvpx.

Yes, the TODOs can definitely tell you what's left there. The list is
not comprehensive though.

Ah, and help is always welcome - with unbundling libraries, gcc-4.7
porting, and other things. Feel free to send your thoughts/questions to
chromium [at] g

Paweł
Attachments: signature.asc (0.20 KB)


phajdan.jr at gentoo

May 3, 2012, 2:37 AM

Post #7 of 44 (1782 views)
Permalink
Re: Chromium bundled code [In reply to]

On 4/30/12 7:42 PM, Mike Gilbert wrote:
> ffmpeg upstream is not afraid of making API changes, so it has proven
> quite difficult to make chromium work with all versions on ffmpeg in
> portage, plus the bundled snapshot. When we were using the system lib,
> it would break nearly every time a new major version of chromium was
> forked.

Right. Eventually I'd like to create an ffmpeg compatibility layer in
Chromium, so that all Chromium-specific code would talk to it, and the
layer would know how to handle (at compile time) different versions of
ffmpeg.

Also, the browser binary should really just link directly to ffmpeg
libraries instead of using dlopen. I also plan to change that.
Attachments: signature.asc (0.20 KB)


rich0 at gentoo

May 3, 2012, 8:28 AM

Post #8 of 44 (1788 views)
Permalink
Re: Chromium bundled code [In reply to]

On Thu, May 3, 2012 at 5:34 AM, "Paweł Hajdan, Jr."
<phajdan.jr [at] gentoo> wrote:
>
> Right, and the source tarball is ~175 MB. It's not perfect, but it's
> also far from 1 GB. The bundled libraries are included in the tarball.

I was thinking about the unpacked size - which is 1001M according to
du for chromium-18.0.1025.168.tar.bz2. That's a lot of source code...

However, my whole point wasn't to throw stones at the chromium team -
I think that they've been doing a great job of fixing this problem,
and will continue to do so. I just was pointing out that Google's
practice of bundling dependencies wasn't to my liking, but that I
wasn't going to give them too much of a hard time precisely because
I'm not being part of the solution.

Rich


waltdnes at waltdnes

May 3, 2012, 2:39 PM

Post #9 of 44 (1780 views)
Permalink
Re: Chromium bundled code [In reply to]

On Thu, May 03, 2012 at 11:28:49AM -0400, Rich Freeman wrote

> However, my whole point wasn't to throw stones at the chromium team -
> I think that they've been doing a great job of fixing this problem,
> and will continue to do so. I just was pointing out that Google's
> practice of bundling dependencies wasn't to my liking, but that I
> wasn't going to give them too much of a hard time precisely because
> I'm not being part of the solution.

I think Chromium's problem is that it's based on Chrome. And Google
is "pulling an AOL" by trying to turn Chrome into an OS for its
Chromebooks. To paraphrase the old emacs joke... Chrom(e/ium) is a
mediocre OS that lacks a lightweight web browser. I just did a
"pretend" build for Chromium. I fail to understand why a *WEB BROWSER*
needs elfutils and dbus and udev as hard-coded dependancies. The udev
dependancy is a show stopper for me, as I've migrated over to mdev. See
https://wiki.gentoo.org/wiki/Mdev That page is now mostly other
people's contributions. I was the rabble-rouser who started it.

--
Walter Dnes <waltdnes [at] waltdnes>


vapier at gentoo

May 3, 2012, 4:18 PM

Post #10 of 44 (2103 views)
Permalink
Re: Chromium bundled code [In reply to]

On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
> I think Chromium's problem is that it's based on Chrome.

you've got that wrong. Chrome is based on Chromium.

> And Google is "pulling an AOL" by trying to turn Chrome into an OS for its
> Chromebooks.

ChromeOS and Chrome are run as semi-separate projects. the former uses Gentoo
to provide a slim/secure Linux base in which you run Chrome.

> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and udev as
> hard-coded dependancies.

you need to think bigger. Chromium supports joystick inputs (which come and
go) for playing games in the browser, so udev makes sense. it also supports
looking up your location, detecting when the network comes up/down, and
kde/gnome password stores, all of which require dbus. and with nacl, you're
loading ELF objects, so libelf makes sense.

really though, if you don't like Chrome, then don't use it. many people do.
-mike
Attachments: signature.asc (0.82 KB)


lu_zero at gentoo

May 3, 2012, 5:49 PM

Post #11 of 44 (1807 views)
Permalink
Re: Chromium bundled code [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/12 16:18, Mike Frysinger wrote:
> On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
>> I think Chromium's problem is that it's based on Chrome.
>
> you've got that wrong. Chrome is based on Chromium.
>
>> And Google is "pulling an AOL" by trying to turn Chrome into an OS for its
>> Chromebooks.
>
> ChromeOS and Chrome are run as semi-separate projects. the former uses Gentoo
> to provide a slim/secure Linux base in which you run Chrome.
>
>> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and udev as
>> hard-coded dependancies.
>
> you need to think bigger. Chromium supports joystick inputs (which come and
> go) for playing games in the browser, so udev makes sense.

So is it using libudev to get that information? I guess would be
possible to patch it out, probably dbus would cover that base as well.

(As soon I have some time I might dabble with a dbus integration for mdev)

lu

- --

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+jJ5UACgkQ6Ex4woTpDjQOtQCZAYnPNGSZ/qlukltSyLL+zACm
vuYAoJp6uvjatUzQrJRK53Hl9kQD9IiN
=onw7
-----END PGP SIGNATURE-----


vapier at gentoo

May 3, 2012, 6:22 PM

Post #12 of 44 (1799 views)
Permalink
Re: Chromium bundled code [In reply to]

On Thursday 03 May 2012 20:49:25 Luca Barbato wrote:
> On 03/05/12 16:18, Mike Frysinger wrote:
> > On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
> >> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and
> >> udev as hard-coded dependancies.
> >
> > you need to think bigger. Chromium supports joystick inputs (which come
> > and go) for playing games in the browser, so udev makes sense.
>
> So is it using libudev to get that information? I guess would be
> possible to patch it out, probably dbus would cover that base as well.

i'm not sure that info is broadcasted over dbus. at any rate, if it is, i'm
not sure that would gain traction upstream unless it was an improvement. and
if it's not going upstream, i don't Paweł is keen on maintaining it locally.

> (As soon I have some time I might dabble with a dbus integration for mdev)

we would have to make mdev available as a sep package then ... don't want
busybox itself linking against anything beyond the C library.
-mike
Attachments: signature.asc (0.82 KB)


antarus at gentoo

May 4, 2012, 1:37 AM

Post #13 of 44 (1773 views)
Permalink
Re: Chromium bundled code [In reply to]

On Thu, May 3, 2012 at 11:39 PM, Walter Dnes <waltdnes [at] waltdnes> wrote:
> On Thu, May 03, 2012 at 11:28:49AM -0400, Rich Freeman wrote
>
>> However, my whole point wasn't to throw stones at the chromium team -
>> I think that they've been doing a great job of fixing this problem,
>> and will continue to do so.  I just was pointing out that Google's
>> practice of bundling dependencies wasn't to my liking, but that I
>> wasn't going to give them too much of a hard time precisely because
>> I'm not being part of the solution.
>
>  I think Chromium's problem is that it's based on Chrome.  And Google
> is "pulling an AOL" by trying to turn Chrome into an OS for its
> Chromebooks.  To paraphrase the old emacs joke... Chrom(e/ium) is a
> mediocre OS that lacks a lightweight web browser.  I just did a
> "pretend" build for Chromium.  I fail to understand why a *WEB BROWSER*

I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
totally OK and you are free to use whatever software you prefer. I
somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
dbus / etc requirements.

Disclaimer, I work at Google (but not on any Chrom{e,ium}(OS) related projects.)

-A

> needs elfutils and dbus and udev as hard-coded dependancies.  The udev
> dependancy is a show stopper for me, as I've migrated over to mdev.  See
> https://wiki.gentoo.org/wiki/Mdev  That page is now mostly other
> people's contributions.  I was the rabble-rouser who started it.
>
> --
> Walter Dnes <waltdnes [at] waltdnes>
>


lu_zero at gentoo

May 4, 2012, 11:02 AM

Post #14 of 44 (1783 views)
Permalink
Re: Chromium bundled code [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/12 18:22, Mike Frysinger wrote:
>> (As soon I have some time I might dabble with a dbus integration for mdev)
>
> we would have to make mdev available as a sep package then ... don't want
> busybox itself linking against anything beyond the C library.

The integration would be mdev -> shell -> dbus or mdev -> socket ->
dbus. I consider dbus still not reliable for core services.

> -mike


- --

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+kGZkACgkQ6Ex4woTpDjSAhgCeLCi65aZru86eamoOEVQzqXrH
mwgAoOX538fSV09WkUYApNL33+3uf4RX
=nnLz
-----END PGP SIGNATURE-----


lu_zero at gentoo

May 4, 2012, 11:03 AM

Post #15 of 44 (1767 views)
Permalink
Re: Chromium bundled code [In reply to]

On 04/05/12 01:37, Alec Warner wrote:
> I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
> and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
> totally OK and you are free to use whatever software you prefer. I
> somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
> dbus / etc requirements.

If dbus and libudev are just for fringe features might be nice disable
them. I wonder if there isn't already a setting for it. chrome for
android won't use them anyway.



--

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero


floppym at gentoo

May 4, 2012, 11:21 AM

Post #16 of 44 (1770 views)
Permalink
Re: Chromium bundled code [In reply to]

On Fri, May 4, 2012 at 2:03 PM, Luca Barbato <lu_zero [at] gentoo> wrote:
> On 04/05/12 01:37, Alec Warner wrote:
>> I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
>> and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
>> totally OK and you are free to use whatever software you prefer. I
>> somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
>> dbus / etc requirements.
>
> If dbus and libudev are just for fringe features might be nice disable
> them. I wonder if there isn't already a setting for it. chrome for
> android won't use them anyway.
>

I don't see a user-controllable setting for dbus or udev. Rather, it
checks for OS == "Linux".

My 2 cents: The Chromium project really doesn't have any motivation to
make it optional since their end product is Google Chrome and they
target a given version of Ubuntu. I think a patch to make them
optional might be accepted, but it probably isn't going to happen
otherwise.


phajdan.jr at gentoo

May 4, 2012, 11:35 AM

Post #17 of 44 (1770 views)
Permalink
Re: Chromium bundled code [In reply to]

On 5/4/12 8:02 PM, Luca Barbato wrote:
> I consider dbus still not reliable for core services.

Just curious - why? I just have no idea about how dbus works or what are
possible problems with it.
Attachments: signature.asc (0.20 KB)


phajdan.jr at gentoo

May 4, 2012, 11:37 AM

Post #18 of 44 (1762 views)
Permalink
Re: Chromium bundled code [In reply to]

On 5/4/12 8:21 PM, Mike Gilbert wrote:
> My 2 cents: The Chromium project really doesn't have any motivation to
> make it optional since their end product is Google Chrome and they
> target a given version of Ubuntu. I think a patch to make them
> optional might be accepted, but it probably isn't going to happen
> otherwise.

Another point is that too many USE flags for such a big and complex
package as www-client/chromium would make testing much much harder, and
create many configurations upstream would not support.
Attachments: signature.asc (0.20 KB)


lu_zero at gentoo

May 4, 2012, 12:18 PM

Post #19 of 44 (1785 views)
Permalink
Re: Chromium bundled code [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/12 11:35, "Paweł Hajdan, Jr." wrote:
> On 5/4/12 8:02 PM, Luca Barbato wrote:
>> I consider dbus still not reliable for core services.
>
> Just curious - why? I just have no idea about how dbus works or what are
> possible problems with it.

About all the integrations I know of crash if the daemon crashes and the
daemon itself tended to be frail. I hadn't checked lately if it improved
since all my usage for it is limited.

Anyway for core services I'm sold to the principle of the least
complexity and maximum separation, so that replacing/updating dbus won't
force me to reboot my system.

lu


- --

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+kK4MACgkQ6Ex4woTpDjQKkACfWepG+ppIl/uapi9JjMlsF0fh
8IAAoIvzZ1kq0dJNo8q+kyXVayEZRTNM
=LST6
-----END PGP SIGNATURE-----


levertond at googlemail

May 4, 2012, 12:25 PM

Post #20 of 44 (1769 views)
Permalink
Re: Chromium bundled code [In reply to]

Luca Barbato wrote:
> On 03/05/12 16:18, Mike Frysinger wrote:
>> you need to think bigger. Chromium supports joystick inputs (which come and
>> go) for playing games in the browser, so udev makes sense.
>
> So is it using libudev to get that information? I guess would be
> possible to patch it out, probably dbus would cover that base as well.
>
> (As soon I have some time I might dabble with a dbus integration for mdev)

If it really is just for joysticks etc it might be worth seeing if it
can be made to use XInput instead. Maybe upstream had a specific reason
not do it that way in the first place, but in general, X apps really
shouldn't be touching the input devices directly.


lu_zero at gentoo

May 4, 2012, 12:39 PM

Post #21 of 44 (1768 views)
Permalink
Re: Chromium bundled code [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/12 11:37, "Paweł Hajdan, Jr." wrote:
> On 5/4/12 8:21 PM, Mike Gilbert wrote:
>> My 2 cents: The Chromium project really doesn't have any motivation to
>> make it optional since their end product is Google Chrome and they
>> target a given version of Ubuntu. I think a patch to make them
>> optional might be accepted, but it probably isn't going to happen
>> otherwise.
>
> Another point is that too many USE flags for such a big and complex
> package as www-client/chromium would make testing much much harder, and
> create many configurations upstream would not support.

I'll check with upstream if that would be a huge problem for them, we
have 6 useflags and we'd bump them to 8. Firefox has twice of them.

If nobody else wants to I could have a look and see how hard is to make
that nicer for our non-udev/non-dbus users on linux.

lu

- --

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+kMHwACgkQ6Ex4woTpDjTTAgCfXtMJFJjB5ZH08u0Nb7yKmkqv
/GwAoNejWgUcHaMWnD6e8Bgr/+V/cYDA
=CCQe
-----END PGP SIGNATURE-----


vapier at gentoo

May 4, 2012, 12:41 PM

Post #22 of 44 (1768 views)
Permalink
Re: Chromium bundled code [In reply to]

On Friday 04 May 2012 15:25:58 David Leverton wrote:
> Luca Barbato wrote:
> > On 03/05/12 16:18, Mike Frysinger wrote:
> >> you need to think bigger. Chromium supports joystick inputs (which come
> >> and go) for playing games in the browser, so udev makes sense.
> >
> > So is it using libudev to get that information? I guess would be
> > possible to patch it out, probably dbus would cover that base as well.
> >
> > (As soon I have some time I might dabble with a dbus integration for
> > mdev)
>
> If it really is just for joysticks etc it might be worth seeing if it
> can be made to use XInput instead. Maybe upstream had a specific reason
> not do it that way in the first place, but in general, X apps really
> shouldn't be touching the input devices directly.

why require X ? :)
-mike
Attachments: signature.asc (0.82 KB)


levertond at googlemail

May 4, 2012, 12:48 PM

Post #23 of 44 (1771 views)
Permalink
Re: Chromium bundled code [In reply to]

Mike Frysinger wrote:
> On Friday 04 May 2012 15:25:58 David Leverton wrote:
>> If it really is just for joysticks etc it might be worth seeing if it
>> can be made to use XInput instead. Maybe upstream had a specific reason
>> not do it that way in the first place, but in general, X apps really
>> shouldn't be touching the input devices directly.
>
> why require X ? :)
> -mike

I wasn't aware that Chromium on Linux supported anything else (and at
least the current ebuild has hard deps on X libraries), but when it is
running on X it ought to follow X conventions, even if it does something
else in other circumstances.


waltdnes at waltdnes

May 4, 2012, 2:35 PM

Post #24 of 44 (1773 views)
Permalink
Re: Chromium bundled code [In reply to]

On Thu, May 03, 2012 at 09:22:11PM -0400, Mike Frysinger wrote

> we would have to make mdev available as a sep package then ... don't
> want busybox itself linking against anything beyond the C library.

Busybox, including its mdev functionality, is targetted at small and
embedded systems. I don't think that'll change, at least I hope it
doesn't. What could work is a shim or compatability layer that gets
called, and pre-processes requests and forwards them to mdev.

--
Walter Dnes <waltdnes [at] waltdnes>


lu_zero at gentoo

May 4, 2012, 2:52 PM

Post #25 of 44 (1768 views)
Permalink
Re: Chromium bundled code [In reply to]

On 04/05/12 14:35, Walter Dnes wrote:
> What could work is a shim or compatability layer that gets
> called, and pre-processes requests and forwards them to mdev.

That's my idea =)

lu

--

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.