[gentoo-dev] Re: Last Rites on slots (was: Re: Last Rites - August 27th - September 2nd 2007)
Lars Weiler wrote: > Think about apache1, php4, KDE-3, gcc-2.95, etc. > > IMHO they are worth being announced in the last rites > section, probably along with a nice upgrade-guide. > ++ A slot definitely is equivalent to a package from user/code perspective; eg if gtk-1 were removed. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Gentoo Graphical User Interfaces Project
On 04:53 Mon 03 Sep , Luis Francisco Araujo wrote: > Our main idea is to develop and collect all the necessary applications > to offer GUI's (keeping Gentoo flexibility) for most of our system > tasks, offering an alternative for those users who like these kind of > interfaces. Please keep in mind all the GUI apps I added in app-admin/system-config-* some time ago, so you don't need to duplicate them. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [RFC] udev rules cleanup / merging rules files with other distros
Hi there! As you all know up to now we have our very own rules file 50-udev.rules This is good for getting our specials - but bad from maintainance view. So here we are: In udev git-gtree suse and redhat rules are already merged. But they use a different permission / group system than we have, they have less groups and assign some desktop permissions via pam_console. I also got all of our rules files (except 50-udev.rules) merged with what the other distros use (already in git). Slackware has already started merging the rules with this "upstream" common rules, and they also are more near to our approach by using groups for audio/tape/cdrom/... But I have not yet seen their rules yet. So for now we are on our own. So before doing to much work we should get a sane concept. And for that concept we need: * A (maybe formal) definition what each group should be used for * what devices it contains (if not obvious) * if permissions should be read/read-write for the group * and nothing/read for world. The question arises as we use MODE=660 for most groups but upstream does 640 most of the time. This are the groups. 1. audio All alsa and oss devices. Rules are not contained in upstream rules - they will in future be installed by media-libs/alsa-lib And upstream split of file for also also does not contain this group but sure it should keep MODE=660 / group audio (Or should we still support oss without having alsa installed) 2. cdrom Used for all cdrom/cdwriter devices and for scsi also the associated sg device. MODE=660 Upstream has no such group - member of disk for them. 3. cdrw Only used for pktcdvd with MODE=660 Should this be merged into group cdrom? 4. disk Contains every device with SUBSYSTEM==block, with MODE=660 the raw-devices (still needed?) + some devices needed for ata-over-ethernet (with modes 220 or 440) Upstream uses MODE=640 (Like old unix group for backup usage). 5. floppy The fd* devices, MODE=660 Upstream uses MODE=640 6. lp Used for all *lp* and parport devices with MODE=660 Upstream uses it same way. 7. tape Contains all tape devices with MODE=660. Upstream has no such group - member of disk group. 8. tty Same usage as upstream (maybe only very slight changes) 9. usb Devices for libusb (/dev/bus/usb/...) with MODE=664. + legousbtower device Upstream has no such group but has libusb stuff root:root with MODE=644 If default world permission is reading then every package changing permissions here (like gphoto, iscan, sane) should also keep world-read I think! 10. uucp serial devices, isdn and more for dialout usage MODE=660 Upstream uses it same way. 11. video A lot of misc stuff: dri/card*, nvidia, 3dfx, framebuffer, ieee1394, v4l, dvb with MODE=660 Upstream has no such group - they keep group at root and grant access via pam. Groups we do not use yet: 12. kmem Upstream uses it for /dev/mem /dev/kmem /dev/port with MODE=640 Should be ok to use - we have group=root, MODE=640 for now Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Gentoo Graphical User Interfaces Project
Luis Francisco Araujo wrote: > himerge is not really new ; it's been around for a good while now. > > Its name stands for 'Haskell Interface for Emerge' ; plus i think some > of those GUI's you are mentioning didn't exist when i started himerge or > they don't offer all that himerge does. > http://www.haskell.org/himerge/himerge-screens/lasthimerge.png Wow! Looks loverley.. /me logs onto #gentoo-haskell to bug araujo. ;P -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Samstag, 1. September 2007, Matthias Schwarzott wrote: > On Samstag, 1. September 2007, Daniel Drake wrote: > > I like the idea of adding this to CONFIG_PROTECT_MASK. > > Ok seems we should do this! Next udev ebuild will add rules directory to CONFIG_PROTECT_MASK. I also tested now what happens to rule changes that get installed in the same turn as the MASK is added. etc-update and dispatch-conf both handle this case fine. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Gentoo Graphical User Interfaces Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: > On 04:53 Mon 03 Sep , Luis Francisco Araujo wrote: >> Our main idea is to develop and collect all the necessary applications >> to offer GUI's (keeping Gentoo flexibility) for most of our system >> tasks, offering an alternative for those users who like these kind of >> interfaces. > > Please keep in mind all the GUI apps I added in > app-admin/system-config-* some time ago, so you don't need to duplicate > them. > > Thanks, > Donnie Of course, Thanks - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG3SQSBCmRZan6aegRAoHWAJ9RHlqGheCyCjcoYbL7ORaaOC0xNQCgkyDD 3R635k5n6bxDBx6ZUr3f5lE= =aO4C -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last Rites on slots (was: Re: Last Rites - August 27th - September 2nd 2007)
On Mon, 2007-09-03 at 07:49 +0200, Lars Weiler wrote: > * Andrew Gaffney <[EMAIL PROTECTED]> [07/09/02 19:11 -0500]: > > I'm not so sure. The last rites have historically always been for complete > > removals of a package from the tree. Is there any reason to change it? Just > > removing an older version of a package from the tree is something that > > happens all the time. Do we want to clutter up the GWN (as much as it needs > > content sometimes) with this unimportant information? > > Think about apache1, php4, KDE-3, gcc-2.95, etc. > > IMHO they are worth being announced in the last rites > section, probably along with a nice upgrade-guide. No. Things like these should be listed in "Gentoo News" with a nice, full article. The Last Rites section is supposed to be nothing more than a list of upcoming package removals. All "important" news should still be done separately. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] udev rules cleanup / merging rules files with other distros
Maybe some of those groups could be merged (cdrom, cdrw) or dropped (tape maybe?) Having usb devices as root:root 644 is going to be a PITA if we don't have something like a sane pam_console (one that doesn't change all /dev nodes whenever someone logs in over ssh, like the one we used to have did) or like ConsoleKit. Cheers, Rémi -- [EMAIL PROTECTED] mailing list
