Re: [gentoo-dev] Re: udev and /usr
On Sun, Sep 25, 2011 at 12:05 PM, Mike Frysinger wrote: > On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote: >> I'm a bit concerned that the future of linux on the desktop is going to be >> one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS, >> or a "KDE OS." Each one would have its own package managers, repositories, >> distros, APIs, etc. Clearly there is some benefit from the vertical >> integration (Android and ChromeOS have a very high level of polish, and >> Ubuntu is approaching this often by just writing their own stuff). Instead >> of working to influence other projects (which can be frustrating), big >> distros are looking to just eliminate dependencies outside of themselves. >> This will be a big challenge for a smaller distro like Gentoo. Obviously we >> can't just go write our own Wayland replacement, even if we did essentially >> make our own "systemd" of sorts. > > you're aware the ChromeOS is built on top of / with Gentoo right ? "Gentoo" is defined by portage and the portage tree. If we remove that, the end result is no different than compiling stuff manually in Slackware or by hand. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: udev and /usr
On Sun, Sep 25, 2011 at 2:35 AM, Mike Frysinger wrote: > On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote: >> This will be a big challenge for a smaller distro like Gentoo. Obviously we >> can't just go write our own Wayland replacement, even if we did essentially >> make our own "systemd" of sorts. > > you're aware the ChromeOS is built on top of / with Gentoo right ? Sure - I'm typing this on my CR-48. :) However, I can't seem to find a chromeos-meta package in portage, and the fact that my chromeos laptop has some feature does me little good in getting my Gentoo desktop to do the same. At best ChromeOS is a fork of Gentoo, and the work that is done to highly integrate it doesn't really trickle back upstream. To be honest, I'm not sure it would be easy for them to do so. I think that the issue is that big companies are moving away from The-Unix-Way(TM), to some extent. Rather than having a bunch of modular components that you can mix and match, everybody is looking to vertically integrate. That often starts with existing components but then leads to various changes such that the components are no longer replaceable. Suppose you're a big integrator like Canonical. You employ 1000 linux devs, all paid to work 40 hours per week and who regularly meet and are competently managed/etc (let's assume for the sake of argument that this makes them more productive). You want to add feature X to your product. However, to accomplish this you need to get module A and module B to talk to each other in some way not allowed by their APIs. Module A is maintained by 3 volunteers, and module B is maintained by 100 people but they have a huge NIH chip on their shoulder and half of them work for competitors and they don't take module A seriously. You can spend hundreds of hours getting them to try them to play nicely with each other, or you can just fork A and B and patch them to do what you want them to do. Sure, that is a long-term maintenance burden, but your 1000 devs can surely handle that. Repeat this 100 times and you end up with a chromium tarball that consists of 90% redistributed 3rd-party libraries with subtle tweaks. However, can you really argue with Google's success with this approach. The FOSS world tends to be messy - lots of strong personalities and nobody really has a financial interest in doing much of anything that doesn't scratch a personal itch. There are alliances of convenience. Big companies are finding it less expensive to just do an end-run around the whole thing. I think there will be a balance, since fundamentally there are advantages to compatibility. However, I fear that the future will look more and more like a world where you pick one ecosystem and end up with first-rate apps that work nicely and 3rd-rate apps that don't. If you pick KDE, then you had better like amarok or whatever else comes with it, or be prepared to quit and restart the app anytime your laptop switches from your car's bluetooth stereo to internal speakers. Rich
[gentoo-dev] Re: GCC 4.6 unmasking
Il giorno ven, 23/09/2011 alle 20.38 -0600, Ryan Hill ha scritto: > If you have any issues with 4.6 itself or patches you need applied, > now is > the time to speak up. There should be already a bug open about valgrind: even when _not_ using DWARF-4 (which breaks binutils, btw) the new gcc uses new DWARF instructions that are not supported even by the ~arch version. We need either to get upstream to release a new version or we should patch it/snapshot it. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] last-rite app-misc/ktsuss
Hi, upstream looks dead and there's a security bug open https://bugs.gentoo.org/show_bug.cgi?id=381115 This package can be repaced by gksu or kdesu. Two rdeps are net-misc/wicd, which I'm maintining and app-portage/portato which I bugged. # Thomas Kahle (25 Sep 2011) # Masked for removal in 30 days. Unfixed security # issues (Bug 381115), dead upstream. x11-misc/ktsuss Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: Digital signature
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
>> Open a bug, attach your ebuilds ( are there any releases besides the >> git code? ) and I will take it from there > > Here it is: https://bugs.gentoo.org/show_bug.cgi?id=383937 > There are no "released" version, and the project have no homepage > (except http://euscan.iksaif.net). euscan ebuild is now in portage, Thanks Markos ! -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] Re: udev and /usr
On 9/25/11 5:53 AM, Rich Freeman wrote: > Repeat this 100 times and you end up with a chromium tarball > that consists of 90% redistributed 3rd-party libraries with subtle > tweaks. However, can you really argue with Google's success with this > approach. At least in Gentoo we remove _most_ of the bundled libraries. Currently the biggest culprits are probably ffmpeg (Chromium upstream breaks it so often that I gave up trying to use the system version) and mesa (yeah, Chromium bundles it and it seems it's patched). I'm slowly convincing the upstream to have a more distro-friendly bundling strategy (i.e. staying close to upstream and making it possible to use system versions). This takes time, and I often need to do the unbundling work myself. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2011-09-25 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2011-09-25 23h59 UTC. Removals: dev-php5/pecl-id3 2011-09-25 19:13:48 olemarkus Additions: app-vim/threesome 2011-09-19 06:45:50 radhermit app-portage/install-mask2011-09-19 08:26:53 mgorny dev-perl/XML-SAX-Base 2011-09-19 13:50:03 tove app-laptop/prey 2011-09-19 16:25:04 hwoarang dev-ruby/simple_oauth 2011-09-19 19:38:32 graaff dev-vcs/git-bz 2011-09-20 14:15:19 mgorny media-sound/split2flac 2011-09-22 18:10:41 maksbotan app-office/unoconv 2011-09-23 13:24:55 scarabeus media-libs/sampleicc2011-09-24 14:09:46 scarabeus media-sound/flacon 2011-09-24 18:15:13 maksbotan app-crypt/kencfs2011-09-25 15:17:26 dilfridge app-portage/euscan 2011-09-25 17:41:38 hwoarang sci-biology/goby-cpp2011-09-25 21:45:36 weaver sci-biology/goby2011-09-25 21:50:28 weaver sci-biology/clustal-omega 2011-09-25 22:35:59 weaver -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-php5/pecl-id3,removed,olemarkus,2011-09-25 19:13:48 Added Packages: app-vim/threesome,added,radhermit,2011-09-19 06:45:50 app-portage/install-mask,added,mgorny,2011-09-19 08:26:53 dev-perl/XML-SAX-Base,added,tove,2011-09-19 13:50:03 app-laptop/prey,added,hwoarang,2011-09-19 16:25:04 dev-ruby/simple_oauth,added,graaff,2011-09-19 19:38:32 dev-vcs/git-bz,added,mgorny,2011-09-20 14:15:19 media-sound/split2flac,added,maksbotan,2011-09-22 18:10:41 app-office/unoconv,added,scarabeus,2011-09-23 13:24:55 media-libs/sampleicc,added,scarabeus,2011-09-24 14:09:46 media-sound/flacon,added,maksbotan,2011-09-24 18:15:13 app-crypt/kencfs,added,dilfridge,2011-09-25 15:17:26 app-portage/euscan,added,hwoarang,2011-09-25 17:41:38 sci-biology/goby-cpp,added,weaver,2011-09-25 21:45:36 sci-biology/goby,added,weaver,2011-09-25 21:50:28 sci-biology/clustal-omega,added,weaver,2011-09-25 22:35:59 Done.
Re: [gentoo-dev] Re: udev and /usr
On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote: > On Sun, Sep 25, 2011 at 12:05 PM, Mike Frysinger wrote: > > On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote: > >> I'm a bit concerned that the future of linux on the desktop is going to > >> be one where your choices are things like Android, ChromeOS, Ubuntu, > >> Gnome OS, or a "KDE OS." Each one would have its own package managers, > >> repositories, distros, APIs, etc. Clearly there is some benefit from > >> the vertical integration (Android and ChromeOS have a very high level > >> of polish, and Ubuntu is approaching this often by just writing their > >> own stuff). Instead of working to influence other projects (which can > >> be frustrating), big distros are looking to just eliminate dependencies > >> outside of themselves. This will be a big challenge for a smaller > >> distro like Gentoo. Obviously we can't just go write our own Wayland > >> replacement, even if we did essentially make our own "systemd" of > >> sorts. > > > > you're aware the ChromeOS is built on top of / with Gentoo right ? > > "Gentoo" is defined by portage and the portage tree. If we remove > that, the end result is no different than compiling stuff manually in > Slackware or by hand. which is how Chrome OS is built. ROOT=/some/place emerge -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: udev and /usr
On Sunday, September 25, 2011 08:53:08 Rich Freeman wrote: > However, I can't seem to find a chromeos-meta package in portage, and > the fact that my chromeos laptop has some feature does me little good > in getting my Gentoo desktop to do the same. At best ChromeOS is a > fork of Gentoo, and the work that is done to highly integrate it > doesn't really trickle back upstream. To be honest, I'm not sure it > would be easy for them to do so. Chrome OS uses the Gentoo tree of ebuilds and an overlay of custom packages. there are also a number of patches to packages that are in our tree, but those are in the process of merging back into Gentoo mainline. i wouldn't really clasify this as a fork ... it's more a derivative. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: udev and /usr
On Mon, Sep 26, 2011 at 7:02 AM, Mike Frysinger wrote: > On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote: >> "Gentoo" is defined by portage and the portage tree. If we remove >> that, the end result is no different than compiling stuff manually in >> Slackware or by hand. > > which is how Chrome OS is built. > ROOT=/some/place emerge > Yes, I'm well aware of how ChromeOS is built. :) But neither portage, nor the portage tree, nor any of our branding are shipped with ChromeOS. Hence it's as much a Gentoo install as $company that uses portage to build $image for their embedded device, but doesn't leave any trace of Gentoo behind. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: GCC 4.6 unmasking
On Sun, 25 Sep 2011 15:10:13 +0200 Diego Elio Pettenò wrote: > Il giorno ven, 23/09/2011 alle 20.38 -0600, Ryan Hill ha scritto: > > If you have any issues with 4.6 itself or patches you need applied, > > now is > > the time to speak up. > > There should be already a bug open about valgrind: even when _not_ using > DWARF-4 (which breaks binutils, btw) the new gcc uses new DWARF > instructions that are not supported even by the ~arch version. We need > either to get upstream to release a new version or we should patch > it/snapshot it. Hmm, I don't see any bugs open that cover that. The support is upstream already? I think we should also consider bumping the minimum glibc version to 2.12 now that it's stable. I know it's a pain in the ass but anything older than that just plain doesn't work anymore. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: udev and /usr
On 09/25/2011 06:57 PM, Nirbheek Chauhan wrote: > On Mon, Sep 26, 2011 at 7:02 AM, Mike Frysinger wrote: >> On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote: >>> "Gentoo" is defined by portage and the portage tree. If we remove >>> that, the end result is no different than compiling stuff manually in >>> Slackware or by hand. Sure, the average Chrome OS end user may not know the difference. However, it makes a difference to the Gentoo community to have our tools and tree used by Chrome OS developers, and have them contribute back fixes and enhancements. >> which is how Chrome OS is built. >> ROOT=/some/place emerge >> > > Yes, I'm well aware of how ChromeOS is built. :) > > But neither portage, nor the portage tree, nor any of our branding are > shipped with ChromeOS. Hence it's as much a Gentoo install as $company > that uses portage to build $image for their embedded device, but > doesn't leave any trace of Gentoo behind. So what? I work on Gentoo for the benefit of myself and others (including Chrome OS devs), not because I want people to see Gentoo branding, or have more people identify themselves as "Gentoo users." -- Thanks, Zac
Re: [gentoo-dev] Re: udev and /usr
On Sunday, September 25, 2011 21:57:27 Nirbheek Chauhan wrote: > But neither portage, nor the portage tree, nor any of our branding are > shipped with ChromeOS. Hence it's as much a Gentoo install as $company > that uses portage to build $image for their embedded device, but > doesn't leave any trace of Gentoo behind. you don't need a portage tree. binpkgs work just fine. all the metadata is pulled down as you go. i'm not saying it is Gentoo, but it is clearly a derivative that relies on quite a bit of the tree to build. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: udev and /usr
On Mon, Sep 26, 2011 at 7:57 AM, Zac Medico wrote: > On 09/25/2011 06:57 PM, Nirbheek Chauhan wrote: >> But neither portage, nor the portage tree, nor any of our branding are >> shipped with ChromeOS. Hence it's as much a Gentoo install as $company >> that uses portage to build $image for their embedded device, but >> doesn't leave any trace of Gentoo behind. > > So what? I work on Gentoo for the benefit of myself and others > (including Chrome OS devs), not because I want people to see Gentoo > branding, or have more people identify themselves as "Gentoo users." > I never meant to say that it's NOT beneficial to Gentoo. I've stated publicly, numerous times since the very beginning in emails, on IRC, twitter, etc. that the fact that ChromeOS uses Portage is and will be quite beneficial to us in many ways. If you recall my recent email to gentoo-core, I specifically talked about this. Please don't take my pedantic definition-wrangling as anything but pedantry. All I've been saying is that it's *misleading* to users for us to say that Google uses Gentoo on its Chrome Books. Google uses Gentoo's portage tools to build ChromeOS, which is hence arguably a *derivative* of Gentoo, but not really Gentoo. This is precisely what Mike said in his last email, and resolved his initial statement for me, which was ambiguous from my PoV. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
