[gentoo-dev] default desktop profile
Hello developers, today I posted a bug (187475) about a minor issue about the useflag libnotify not beeing in the default desktop profile. Me was told that this sould be discussed on gentoo-dev. I can't really understand why such a minor issue have to be discussed among all developers as there are certainly much more importand things to do. Beeing a user I have the feeling that bugs concerning such minor issues aren't welcome among the gentoo developers. I consider it important for gentoo to regard such details too achieve a more polished gnome desktop experience by default as we have now. To come to the bug, I'll comment Jakub Moc's last comment: As said above - bloating default profiles even more goes to gentoo-dev mailing list, so that people could comment. I for one am already annoyed enough by the nonsense being added there, such as USE=kerberos or USE=ldap. I agree that there is too much enabled by default, but other things are missing. I personally need kerberos and ldap but that shouldn't be the default for most singel-user desktop installations. So, these are my proposed changes for the default desktop profile: +bash-completion +bluetooth +ffmpeg(totem isn't much without it) +libnotify (gives very nice popup notifications in many programs instead of an annoying, workflow interrupting dialog box with an OK button) +ppds (everyone has a printer, and this is needed to configure it without further investigations. cups is already in) +startup-notification -fortran (not 1% of the desktop users need fortran and it speeds up the compile) -kerberos -ldap I'm curious about your comments, -- Martin Schwier Gentoo user ;) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: default desktop profile
Martin Schwier wrote: +bash-completion Well I for one can't stand bash-completion, but I guess I could always disable it if others think it useful. +bluetooth +ffmpeg(totem isn't much without it) If it's just for a specific package, there is a default package.use iirc. +libnotify (gives very nice popup notifications in many programs instead of an annoying, workflow interrupting dialog box with an OK button) +ppds (everyone has a printer, and this is needed to configure it without further investigations. cups is already in) +startup-notification -fortran (not 1% of the desktop users need fortran and it speeds up the compile) I'd have to agree on that one. We've always installed without fortran, and it was easy enough to switch it back in for the user who needed koctave. -kerberos -ldap Well I think those two are there so that samba works well as an Active Directory server, or is integrated better into a Windoze setup. Kerberos was only added recently for that reason, iirc. So I'd vote against losing them for a default install, since integration with heterogeneous networks is so important. Dunno if that can be managed better with package.use. (If I haven't commented on one it means I don't have a preference either way.) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
Sven == Sven Köhler [EMAIL PROTECTED] writes: Sven Oh! So USE=hal forces pciutils not to use zlib? There are many more ebuilds than just hal which fail with a compressed pci.ids file. And many of them are non-obvious. It took me more than I little bit of effort after the zlib USE flag was first added to the pciutils ebuild to figure out why so many packages where failing... (On an old enough install, with enough disparate packages installed, a naïve emerge world will always fail. *Something* is guaranteed to be unhappy.) The lunacy is that compressing pci.ids and usb.ids helps no-one. On a system running from a spinning disk the size difference is lost in the noise. On embedded systems one knows in advance what devices exist on the motherboard and can edit the ids file down to just those. Most embedded systems don't even need the ids files on the production load. No developer worth his salt would waste space on names where the numbers work just as well. They'd use the names on the development platform, of course, but those would be complied to just the ints on the final load. So, simply put, compressing pci.ids benefits no-one, and harms many. A cool hack perhaps, but misguided and useless. The pciutils ebuild should be re-engineered to use separate USE flags for linking to libz and compressing the database. Or the database should be an ebuild of its own, using a custom flag (compressed?) to request compression of the ids file, and not the zlib flag. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
James Cloos wrote: The pciutils ebuild should be re-engineered to use separate USE flags for linking to libz and compressing the database. ++ It may be what upstream (pciutils) do by default, but no other distro ships with compressed ids for the reasons you outline (and you can't mmap the file). It breaks a default desktop installation (aiui) so it really shouldn't use a default system-wide USE flag, but a local one. Anyone who really wants it can set it, and everyone else's machines will still work. As Mr Gianelloni spelt out on bugzilla[1]: when you install from stage3, then immediately type emerge [blah], I would expect it to work. If it does not, then it is a failure in the ebuild and a bug... it is your responsility to ensure that your package is not broken with a default installation. I don't know if that's policy or not, but imo it should be. On a wider note, it seemed to me from the bug to be more of a dispute between HAL upstream and pciutils upstream. I wonder how many such disputes are actually resolved within Gentoo, since it seems the kind of thing that would show up most in a source distro. (And as such shows another reason why Gentoo is so important to the wider community. Certainly devs from other projects i've met on IRC who use Gentoo seem a lot less stressed than those on other distros.. ;) [1] http://bugs.gentoo.org/show_bug.cgi?id=120088#c3 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Martin Schwier wrote: To come to the bug, I'll comment Jakub Moc's last comment: As said above - bloating default profiles even more goes to gentoo-dev mailing list, so that people could comment. I for one am already annoyed enough by the nonsense being added there, such as USE=kerberos or USE=ldap. As Donnie recently talked/blogged about philosophy ... One of the core Gentoo philosophies is that it's a meta distribution. As such, the idea of opt in rather than opt out has been the motto for quite a while. It's one defining trait of Gentoo. I'll go with Jakub on this one. Adding more stuff is only a disservice to everyone, including our users. Some use flags can do a lot of harm if you try to take them out : directfb and xcb are 2 painful examples. My 2 euro cents. :) Rémi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
On 8/2/07, Martin Schwier [EMAIL PROTECTED] wrote:
Hello developers,
today I posted a bug (187475) about a minor issue about the useflag
libnotify not beeing in the default desktop profile. Me was told that
this sould be discussed on gentoo-dev. I can't really understand why
such a minor issue have to be discussed among all developers as there
are certainly much more importand things to do.
Beeing a user I have the feeling that bugs concerning such minor issues
aren't welcome among the gentoo developers. I consider it important for
gentoo to regard such details too achieve a more polished gnome desktop
experience by default as we have now.
To come to the bug, I'll comment Jakub Moc's last comment:
As said above - bloating default profiles even more goes to gentoo-dev
mailing
list, so that people could comment. I for one am already annoyed enough by
the
nonsense being added there, such as USE=kerberos or USE=ldap.
I agree that there is too much enabled by default, but other things are
missing. I personally need kerberos and ldap but that shouldn't be the
default for most singel-user desktop installations.
So, these are my proposed changes for the default desktop profile:
+bash-completion
+bluetooth
Most Probably dont have/want bluetooth. I know at most 1 linux users
who would use it.
+ffmpeg(totem isn't much without it)
+libnotify (gives very nice popup notifications in many programs instead
of an annoying, workflow interrupting dialog box with an OK button)
+ppds (everyone has a printer, and this is needed to configure it
without further investigations. cups is already in)
No, not everyone has a printer :P
+startup-notification
-fortran (not 1% of the desktop users need fortran and it speeds up
the compile)
-kerberos
-ldap
I just turned these off myself. Why?,, i like compiling for hours with
emerge --newuse ;)
The millions of lines of text make me feel geeky ;) ( lol )
I'm curious about your comments,
--
Martin Schwier
Gentoo user ;)
--
[EMAIL PROTECTED] mailing list
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print enNOSPicAMreil [EMAIL PROTECTED][(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: default desktop profile
Rémi Cardona wrote: One of the core Gentoo philosophies is that it's a meta distribution. As such, the idea of opt in rather than opt out has been the motto for quite a while. It's one defining trait of Gentoo. I second that. But gentoo isn't following this philosophies strictly. The profiles are there for giving the user sensible defaults because it isn't always clear which effect a particular useflag has. In the libnotify case I don't expect a new user to know what he gets from this flag and so he won't set it and his desktop experience suffers. I'll go with Jakub on this one. Adding more stuff is only a disservice to everyone, including our users. Sure you have to balance the pros and cons of the stuff you add, but there are numerous example in packages where this is not the case. Let me give one: The gnome meta ebuild pulls in way too much stuff. I always have to copy it in my local overlay and have to remove epiphany, evolution, vino, ekiga and more. There are no use flags to control this and I expect many gnome users to use Firefox and Thunderbird instead of epiphany and evolution. (many, not all). If I use the official gnome ebuild instead of my edited one then 35 new packages will be pulled in. Well I think *that* is bloat! The libnotify useflag pulls in one 60k library that don't harm anyone. It is worth to think very good about where to give the user the choice to control his packages and which default to give him. In the libnotify case I would vote to make it a static dependency and not useflag controllable or at least set the useflag by default. Kent Fredric wrote: No, not everyone has a printer :P Okay, cups is in by default, but the drivers aren't... :-/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
On Thursday 02 August 2007, Martin Schwier wrote: today I posted a bug (187475) about a minor issue about the useflag libnotify not beeing in the default desktop profile. Me was told that this sould be discussed on gentoo-dev. I can't really understand why such a minor issue have to be discussed among all developers as there are certainly much more importand things to do. Beeing a user I have the feeling that bugs concerning such minor issues aren't welcome among the gentoo developers. I consider it important for gentoo to regard such details too achieve a more polished gnome desktop experience by default as we have now. the profiles are made up of input from many developers, so having the decision made by a single one in bugzilla is incorrect. the topic is also subject to debate and bugzilla is not the forum for wide debating in Gentoo. -fortran (not 1% of the desktop users need fortran and it speeds up the compile) fortran is an expected default in the Linux world, so you get it by default. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
There are many more ebuilds than just hal which fail with a compressed pci.ids file. And many of them are non-obvious. It took me more than I little bit of effort after the zlib USE flag was first added to the pciutils ebuild to figure out why so many packages where failing... Oh! Really? Which ones? So it seems, there are many many handwritten parsers out there? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Release managment
On Thursday, 2. August 2007 19:35, Christian Faulhammer wrote: Martin Michlmayr, Debian Project Leader from 2003 to 2005, has finished his Phd thesis about Quality improvement in volunteer software projects [1] .. he gave a short introduction on the whole topic on Google Tech Talks: http://video.google.com/videoplay?docid=-5503858974016723264 (for those who rather spend an hour listening than reading :-) P.S.: Is -dev the correct list? I guess that depends on what we can/want to learn from his research. -R. pgpnoplZEkiKc.pgp Description: PGP signature
[gentoo-dev] Release managment
Hi, Martin Michlmayr, Debian Project Leader from 2003 to 2005, has finished his Phd thesis about Quality improvement in volunteer software projects [1] V-Li P.S.: Is -dev the correct list? [1] URL:http://www.cyrius.com/publications/michlmayr-phd.pdf -- http://www.gentoo.org/ http://www.faulhammer.org/ http://www.gnupg.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] 2.6.22 stable plans
William L. Thomson Jr. ha scritto: This is for the very short term. I don't want to maintain a driver for hardware I don't own and never intend on purchasing. Well seems most AMD machines are likely to ship with ATI chipsets these days. For sure most lappies :) Interesting side note. Beryl/Xgl works on my laptop, ATI Xpress200m. cool... would you like to write a pair of lines describing the process, software (ebuilds) versions used, tips and quirks? cause I tried many time but always failes someway, so that I started to think ati-drivers for X200M are bork :S -- 0xff -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: default desktop profile
Martin Schwier wrote: snip The gnome meta ebuild pulls in way too much stuff. I always have to copy it in my local overlay and have to remove epiphany, evolution, vino, ekiga and more. There are no use flags to control this and I expect many gnome users to use Firefox and Thunderbird instead of epiphany and evolution. (many, not all). If I use the official gnome ebuild instead of my edited one then 35 new packages will be pulled in. Well I think *that* is bloat! The libnotify useflag pulls in one 60k library that don't harm anyone. more snip The official Gnome meta ebuild pulls in what upstream considers to be the Gnome Desktop - thats why it is there, the Gnome herd will *not* change that. As a convenience, they have provided the gnome-light meta ebuild. If Gnome pulls in too much, then take a look at gnome-light. If that pulls in too little, then continue to work on it in your overlay, the Gnome herd does not have time to create multiple ebuilds of the official upstream Gnome desktop just because some users don't want this or that, they provide it as a convenience, and that is all. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] archfs - filesystem for rdiff-backup archives
= Status report = Project description = Archfs is a filesystem that displays rdiff-backup archives in a user-friendly fashion. It is built using FUSE library, that makes possible creating filesystems in userspace. This particular filesystem analyzes given single or multiple rdiff-backup archives and allows to browse its contents. Project status == All planned features are operational. Autotools are used to configure, build and install filesystem. I am learning how ebuilds are made and gathering feedback from users in order to work on code's quality and robustness. Timeline == 1 VIII - 10 VIII - making it possible to add software to gentoo distribution; presenting software to possible large number of users to gather feedback 11 VIII - 20 VIII - excessive testing; using feedback gathered from users for fixing bugs/adding smaller features; -- Filip Gruszczyński
Re: [gentoo-dev] Re: default desktop profile
Martin Schwier wrote: In the libnotify case I would vote to make it a static dependency and not useflag controllable or at least set the useflag by default. I see this so: If upstream thinks, this is an option, the ebuild should reflect this. If upstream thinks, this is vital, the ebuild should also reflect this. The decision, if some feature should always be included, when a package is compiled, should be made by upstream, not by gentoo. There may be cases, where it is wise to not follow this rule for various reason, but this should be made by the package maintainer per package and not be a general rule. This is what makes gentoo a distribution of choices. I don't like feature A, upstream doesn't it's vital and gentoo give me the ability to disable/enable the feature A via USE-flags. As a conclusion, even a lot of peoples likes libnotify, it is not a reason to make it a static dependency and not USE-flag controllable. There may be users, like me, who don't like libnotify. If this is seen as a major profit for most users, doesn't make a lot of problems, its USE-flag could be enabled by default. Myself, who would not prefer to have it enabled by default, can easily reverse that in make.conf. This is only an opinion from a user and reflects a part, on how I see gentoo and what it makes it for me the best distribution out there. Greetings, Jean-Marc Hengen -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
On Thu, 2007-08-02 at 20:09 +0200, federico ferri wrote: William L. Thomson Jr. ha scritto: This is for the very short term. I don't want to maintain a driver for hardware I don't own and never intend on purchasing. Well seems most AMD machines are likely to ship with ATI chipsets these days. For sure most lappies :) Interesting side note. Beryl/Xgl works on my laptop, ATI Xpress200m. cool... would you like to write a pair of lines describing the process, software (ebuilds) versions used, tips and quirks? Yeah I might see about documenting it at some point, but I basically just followed the wiki. Although it's still a little quirky wrt to starting beryl-xgl, and beryl-manager during log in. But that kinda gives me a choice when I log in to start metacity or beryl :) cause I tried many time but always failes someway, so that I started to think ati-drivers for X200M are bork :S Nah, it's all about your config. If that sucker is not dialed in it will blow. It took me forever to get mine to where it's at. Still some stuff left like dialing in dual monitors and etc. Here is my current xorg.conf. It's still kinda a mess, but should help out. http://dev.gentoo.org/~wltjr/misc/xpress200m_xorg.conf -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
Sven Köhler wrote:
There are many more ebuilds than just hal which fail with a compressed
pci.ids file. And many of them are non-obvious. It took me more than
I little bit of effort after the zlib USE flag was first added to the
pciutils ebuild to figure out why so many packages where failing...
Oh! Really? Which ones?
app-laptop/smcinit
app-misc/ddccontrol
sys-apps/hwsetup
sys-apps/{lib,}kudzu
sys-apps/vbetool
sys-boot/efibootmgr
sys-power/athcool
are some we have on file so far.
--
dirtyepicyou'd be tossed up or wash up, the narrator relates
gentoo org in a spartan antarctican walk for many days
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
On Wednesday 01 August 2007, William L. Thomson Jr. wrote: On Wed, 2007-08-01 at 09:54 -0700, Chris Gianelloni wrote: This is for the very short term. I don't want to maintain a driver for hardware I don't own and never intend on purchasing. Well seems most AMD machines are likely to ship with ATI chipsets these days. For sure most lappies :) maybe, but irrelevant i think if the driver blows dead goats and the vendor isnt willing to help and no Gentoo dev wants to touch it, what other solution is there ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
On Thu, Aug 02, 2007 at 05:19:02PM -0600, Ryan Hill wrote:
Oh! Really? Which ones?
app-laptop/smcinit
app-misc/ddccontrol
sys-apps/hwsetup
sys-apps/{lib,}kudzu
sys-apps/vbetool
sys-boot/efibootmgr
sys-power/athcool
are some we have on file so far.
So it seems, there are many many handwritten parsers out there?
From the bugs I've fixed because of pciutils zlib support, it's not much
in the way of custom parsers, it's rather just a lot of getting zlib
included in the linker call.
--
Robin Hugh Johnson
Gentoo Linux Developer Council Member
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpW1K9zvCPGs.pgp
Description: PGP signature
Re: [gentoo-dev] 2.6.22 stable plans
On Thu, 2 Aug 2007 19:31:09 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: if the driver blows dead goats and the vendor isnt willing to help and no Gentoo dev wants to touch it, what other solution is there ? There's an open-source driver for the r5xx stuff called the avivo driver [1]. It's still pretty rough, so I haven't packaged it yet. For anyone interested, it should be pretty easy to make an ebuild for it based on the xf86-video-ati ebuild and the git eclass. For the present, je_fro's picked up ati-drivers and anarchy's been sending changes for some of the newest stuff. Thanks, Donnie 1. http://gitweb.freedesktop.org/?p=avivo/xf86-video-avivo.git;a=summary signature.asc Description: PGP signature
[gentoo-dev] Re: Release managment
Christian Faulhammer wrote: Hi, Martin Michlmayr, Debian Project Leader from 2003 to 2005, has finished his Phd thesis about Quality improvement in volunteer software projects [1] V-Li P.S.: Is -dev the correct list? I would say this is perfect for -project. It's a thesis on software projects, right? Rather than something that's about the technical development of our tree. [1] URL:http://www.cyrius.com/publications/michlmayr-phd.pdf -- dirtyepicyou'd be tossed up or wash up, the narrator relates gentoo org in a spartan antarctican walk for many days 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: archfs - filesystem for rdiff-backup archives
Er it's been pointed out to me that this is a Google SoC project, so apologies for the beginners info. (I'd forgotten your earlier post.) http://code.google.com/p/archfs/ for anyone else who's interested. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
Robin H. Johnson wrote:
On Thu, Aug 02, 2007 at 05:19:02PM -0600, Ryan Hill wrote:
Oh! Really? Which ones?
app-laptop/smcinit
app-misc/ddccontrol
sys-apps/hwsetup
sys-apps/{lib,}kudzu
sys-apps/vbetool
sys-boot/efibootmgr
sys-power/athcool
are some we have on file so far.
So it seems, there are many many handwritten parsers out there?
From the bugs I've fixed because of pciutils zlib support, it's not much
in the way of custom parsers, it's rather just a lot of getting zlib
included in the linker call.
Right. In all fairness I should have mentioned that the above packages
have already been fixed.
--
dirtyepicyou'd be tossed up or wash up, the narrator relates
gentoo org in a spartan antarctican walk for many days
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
On Thursday 02 August 2007, Donnie Berkholz wrote: Mike Frysinger [EMAIL PROTECTED] wrote: if the driver blows dead goats and the vendor isnt willing to help and no Gentoo dev wants to touch it, what other solution is there ? There's an open-source driver for the r5xx stuff called the avivo driver [1]. It's still pretty rough, so I haven't packaged it yet. For anyone interested, it should be pretty easy to make an ebuild for it based on the xf86-video-ati ebuild and the git eclass. For the present, je_fro's picked up ati-drivers and anarchy's been sending changes for some of the newest stuff. sounds good to me ... so to tie back to the source of the thread, crappy closed source vendor drivers are not a valid reason to hold up stabilization of a kernel if the issue affects you: (1) complain to the vendor (2) help make the package work with the new kernel (3) dont buy the hardware (4) stop bugging the kernel developers (5) give me a hug (6) goto 5 -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Pending death of mail-filter/spamassassin-ruledujour
Heya, The upstream rules_du_jour folk have had issues over the last few months with DDoS and other attacks. Additionally, the nature of their original update mechanism causes a lot of traffic. Everybody that is using rules_du_jour is strongly encouraged to move to using the sa-update mechanism that is included with recent versions of SpamAssassin. Here is a guide to using SARE rulesets with sa-update: http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt mail-filter/spamassassin-ruledujour will be p.masked on August 4th, and removed one month thereafter. -- Robin Hugh Johnson Gentoo Linux Developer Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpqHZMu6upm8.pgp Description: PGP signature
[gentoo-dev] Re: archfs - filesystem for rdiff-backup archives
emerge: there are no ebuilds to satisfy archfs. Perhaps a link to the homepage/ overlay might be handy? ;) This is not something that's about the technical development of our tree so it might be considered off-topic (interesting though it might be.) As a general rule, the Unsupported Software forum is a good place to get feedback from users til something is releasable. (Apologies if you've already gone thru that process, just mention it and give the url in that case.) At that point getting feedback from devs as to it's suitability for inclusion is acceptable, aiui, although even then you're probably just going to get told to get on #gentoo-sunrise (irc.freenode.org) and work on getting it into the main overlay before it makes the portage tree. (Unless ofc a dev wants to pick it up out of interest.) BTW I don't recommend autotools (there's a reason they're called autohell ;) especially if you're not writing from scratch. (That's why you get all those redundant configure checks..) A simple system.mk which gets included in the makefile is a lot easier for everyone. ion3 (which is now in mabi's overlay iirc) does this, and it's a doddle to configure. (I think it was one or two sed calls.) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
On Thu, 2007-08-02 at 11:27 +0200, Martin Schwier wrote: So, these are my proposed changes for the default desktop profile: +bash-completion +bluetooth +ffmpeg(totem isn't much without it) +libnotify (gives very nice popup notifications in many programs instead of an annoying, workflow interrupting dialog box with an OK button) +ppds (everyone has a printer, and this is needed to configure it without further investigations. cups is already in) +startup-notification Well, we don't add local USE flags to the default profiles unless there is a *very* good reason. I really don't have a problem with any of these being added, but I'd rather hear the opinions of my peers. Also, if these *were* to get added, they wouldn't be added to the 2007.0 profiles and would wait for 2007.1's profiles, which we should be starting up some time soon. I usually ask for these sorts of suggestions over on the gentoo-releng mailing list near the beginning of our release cycle. -fortran (not 1% of the desktop users need fortran and it speeds up the compile) ... (I have no comments on this one) -kerberos -ldap These aren't going anywhere so long as they're needed for proper Active Directory connectivity. I added them for a reason and don't really intend on removing them. As I said, I consider the ability to intercommunicate with Active Directory to be a *vital* capability for a desktop... any desktop. -- 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] Pending death of mail-filter/spamassassin-ruledujour
Robin H. Johnson wrote: Heya, The upstream rules_du_jour folk have had issues over the last few months with DDoS and other attacks. Additionally, the nature of their original update mechanism causes a lot of traffic. Everybody that is using rules_du_jour is strongly encouraged to move to using the sa-update mechanism that is included with recent versions of SpamAssassin. Here is a guide to using SARE rulesets with sa-update: http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt mail-filter/spamassassin-ruledujour will be p.masked on August 4th, and removed one month thereafter. I updated the one reference to this package in our docs, in mailfilter-guide.xml. Yanked out dujour in favor of the link you gave. Should be good to go. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
On Thu, 2007-08-02 at 14:15 +0100, Steve Long wrote: James Cloos wrote: The pciutils ebuild should be re-engineered to use separate USE flags for linking to libz and compressing the database. ++ It may be what upstream (pciutils) do by default, but no other distro ships with compressed ids for the reasons you outline (and you can't mmap the file). It breaks a default desktop installation (aiui) so it really shouldn't use a default system-wide USE flag, but a local one. Anyone who really wants it can set it, and everyone else's machines will still work. As Mr Gianelloni spelt out on bugzilla[1]: when you install from stage3, then immediately type emerge [blah], I would expect it to work. If it does not, then it is a failure in the ebuild and a bug... it is your responsility to ensure that your package is not broken with a default installation. That isn't policy, as much as I would like it to be. Also, both hal and zlib are in USE in the default profiles, so it does work out of the box right now. -- 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] Re: why? pciutils with zlib use-flag went stable on x86
On Thu, 2007-08-02 at 08:23 -0400, James Cloos wrote: There are many more ebuilds than just hal which fail with a compressed pci.ids file. And many of them are non-obvious. It took me more than I little bit of effort after the zlib USE flag was first added to the pciutils ebuild to figure out why so many packages where failing... This might have been the case way back then, but we've been cleaning up any ebuilds since. I know that there is nothing that we've been made aware of anymore that *doesn't* work with a compressed pci.ids file, since most use the library and simply required linking with zlib to build/link. -- 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] default desktop profile
Chris Gianelloni wrote: On Thu, 2007-08-02 at 11:27 +0200, Martin Schwier wrote: +ppds (everyone has a printer, and this is needed to configure it without further investigations. cups is already in) +startup-notification Well, we don't add local USE flags to the default profiles unless there is a *very* good reason. I really don't have a problem with any of these being added, but I'd rather hear the opinions of my peers. I am very strongly in support of ppds, as I consider it critical for us to make printers easier to set up. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] 2.6.22 stable plans
On Thu, 2007-08-02 at 16:55 -0700, Donnie Berkholz wrote: On Thu, 2 Aug 2007 19:31:09 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: if the driver blows dead goats and the vendor isnt willing to help and no Gentoo dev wants to touch it, what other solution is there ? There's an open-source driver for the r5xx stuff called the avivo driver [1]. 1. http://gitweb.freedesktop.org/?p=avivo/xf86-video-avivo.git;a=summary Still leaves a gap, since the open source radeon driver is not fully supporting R3xx to my knowledge much less r4xx. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2.6.22 stable plans
On Thu, 2007-08-02 at 20:05 -0400, Mike Frysinger wrote: sounds good to me ... so to tie back to the source of the thread, crappy closed source vendor drivers are not a valid reason to hold up stabilization of a kernel Who ever said they were crappy? Maybe the documentation on usage is crappy, but drivers have consistently gotten much better. These days pretty solid IMHO for my uses. They just did not compile against 2.6.22 due to some files being moved around or etc. I happen to like the drivers, and they are the only thing I can use to get DRI from my hardware. Last I checked there was a version of ati-drivers available for stable systems. So by stabilizing 2.6.22 you will effectively break those systems. Not breakage in portage's eyes, but people upgrading their systems won't be able to run the latest stable kernel with the latest stable ati-drivers. FYI, the patches in bug #183480 [1] allow one to use the most current ati-drivers with a 2.6.22 kernel. As I am now while I am composing this message. Having applied said patches and bumped ebuild locally. Just needs to happen in tree :) 1. http://bugs.gentoo.org/show_bug.cgi?id=183480 -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2.6.22 stable plans
William L. Thomson Jr. wrote: On Thu, 2007-08-02 at 16:55 -0700, Donnie Berkholz wrote: On Thu, 2 Aug 2007 19:31:09 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: if the driver blows dead goats and the vendor isnt willing to help and no Gentoo dev wants to touch it, what other solution is there ? There's an open-source driver for the r5xx stuff called the avivo driver [1]. 1. http://gitweb.freedesktop.org/?p=avivo/xf86-video-avivo.git;a=summary Still leaves a gap, since the open source radeon driver is not fully supporting R3xx to my knowledge much less r4xx. Update your knowledge, the normal radeon driver works nice for both. =) Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] 2.6.22 stable plans
William L. Thomson Jr. wrote: FYI, the patches in bug #183480 [1] allow one to use the most current ati-drivers with a 2.6.22 kernel. As I am now while I am composing this message. Having applied said patches and bumped ebuild locally. Just needs to happen in tree :) 01 Aug 2007; Jeff Gardner [EMAIL PROTECTED] +files/8.37.6/fix-ioctl-for-2.6.22.patch, ati-drivers-8.37.6-r1.ebuild: Add patch to allow compilation with 2.6.22 kernels. See bug #182597. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: 2.6.22 stable plans
William L. Thomson Jr. [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 02 Aug 2007 23:19:08 -0400: On Thu, 2007-08-02 at 16:55 -0700, Donnie Berkholz wrote: On Thu, 2 Aug 2007 19:31:09 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: if the driver blows dead goats and the vendor isnt willing to help and no Gentoo dev wants to touch it, what other solution is there ? There's an open-source driver for the r5xx stuff called the avivo driver [1]. 1. http://gitweb.freedesktop.org/?p=avivo/xf86-video-avivo.git;a=summary Still leaves a gap, since the open source radeon driver is not fully supporting R3xx to my knowledge much less r4xx. To the best of my knowledge... it's not stable upstream yet, but the radeon driver now includes (reverse engineered) R3xx and I believe R4xx support, including 3D. R5xx is right out, since even VESA has issues due to the no 2D hardware engine at all. -- 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
On Thursday 02 August 2007, William L. Thomson Jr. wrote: On Thu, 2007-08-02 at 20:05 -0400, Mike Frysinger wrote: sounds good to me ... so to tie back to the source of the thread, crappy closed source vendor drivers are not a valid reason to hold up stabilization of a kernel Who ever said they were crappy? Maybe the documentation on usage is crappy, but drivers have consistently gotten much better. These days pretty solid IMHO for my uses. last time i used the drivers they sucked hard ... maybe it's gotten better; i dont know -- i tossed all my ati in favor of nvidia my point though wasnt to knock ati (although it was fun), the point was that i do not believe any closed source driver in our tree should ever be grounds for preventing stabilization of a kernel ebuild so next time dsd (or whoever the ninja kernel maintainer happens to be at the time) says hey i plan on stabilizing Linux x.y.z and someone goes wait, you cant until we get closed source driver package foo working, the reply is of course blow it out your arse^H^H^H^Htalk to the package maintainer, this will not hold up stabilization efforts -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 2.6.22 stable plans
Mike Frysinger wrote: my point though wasnt to knock ati (although it was fun), the point was that i do not believe any closed source driver in our tree should ever be grounds for preventing stabilization of a kernel ebuild so next time dsd (or whoever the ninja kernel maintainer happens to be at the time) says hey i plan on stabilizing Linux x.y.z and someone goes wait, you cant until we get closed source driver package foo working, the reply is of course blow it out your arse^H^H^H^Htalk to the package maintainer, this will not hold up stabilization efforts If we're gonna go with this policy here, I'm also going to adopt it for X so we don't get stuck in limbo as happened fairly recently. Thanks, Donnie signature.asc Description: OpenPGP digital signature
