Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
On Montag, 9. November 2009, Mart Raudsepp wrote: On Sun, 2009-08-30 at 16:11 +0200, Matthias Schwarzott wrote: Hi there! A late hello, Second point: udev-145 bundles a lot of new extras, but they can only be enabled/disabled all or nothing. These extras are: * udev-acl: Apply consolekit permissions to devices for users (audio, video, joysticks, scanner, cameras, ...) * usb-db: Provide udev-rules with device names of pci and usb devices * hid2hci: Special utility to fix resume of some hid devices * keymap: Auto-configure model specific keys found on many laptops (brightness up, next song, www browser, or suspend) * modem-modeswitch: Switch modems that provide virtual cd-drive with drivers to modem mode I think the thread hasn't seen an answer to the question of when these are actually used or useful, as asked in another subthread as well. * gudev: glib/gobject support for libudev Would it be possible to have this in a separate package? Of course then with a temporary compatibility PDEPEND on it with udev[extras] until packages needing gudev migrate over. The question is: DO we really need to split udev that upstream bundled into one tarball? And what of the above listed other things besides core udev does gudev require or potentially use? To be answered by someone else, I do not need these yet. Matthias
[gentoo-dev] Re: redistribute intel rpms
Sébastien Fabbro posted on Wed, 11 Nov 2009 22:55:20 -0800 as excerpted: To make myself clearer, the tar ball includes a few binary rpms and a installer blob. Both icc and ifc tar ball include the mkl, idb and some common library rpms. If we go for a kde-split with a mirror restrict approach, users would still have to download the big (~800Mb) tar balls. Only users with use of all (icc, idb, ifc, mkl, ipp, tbb) intel software would benefit of downloading them. It is also the fact Intel has a history of changing their packaging system. Not to mention that a rpm split seems to me lot simpler to maintain and quicker to package for me than the kde-split mirror-restricted approach, and the fact my interest for these packages is limited. OK, makes sense... as long as there's legal cover to do it. If there's not, then we're back to doing the split. And asking about the legal cover is what this thread's all about. Fair enough. I was simply wondering if the split had been given due consideration as I didn't get that from the original post, but it appears so. Thanks. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Lastrite: kde-base/kdelibs:3.5, kde-base/arts:3.5 reverse dependencies
These are masked with co-ordination from games@ # Samuli Suominen ssuomi...@gentoo.org (10 Nov 2009) # Has kde-base/arts depend, and it can't be removed. # Masked for removal. games-puzzle/quintalign games-sports/kbilliards games-strategy/kpictorial games-util/krconlinux games-puzzle/easysok These are masked with co-ordination from media-video@, dev-perl/PerlQt media-video/dpencoder media-video/qvamps media-video/asdf These are now orphaned (with co-ordination from Chainsaw, dropped USE amarok from app-misc/g15composer): dev-perl/DCOP dev-perl/DCOP-Amarok dev-perl/DCOP-Amarok-Player This is masked with co-ordination from boinc maintainer (scarabeus) sci-misc/kboincspy These doesn't do anything (only shared libraries (plugins)) for KDE3 components: x11-plugins/khexclock x11-misc/lineak-kdeplugins app-pda/libopensync-plugin-kdepim app-laptop/kthinkbat
[gentoo-dev] Lastrite: media-sound/kstreamripper (KDE3)
$subject, replaced by media-sound/kradioripper (KDE4)
