From mclasen at redhat.com Mon Feb 12 15:56:06 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 10:56:06 -0500 Subject: Using pulseaudio by default Message-ID: <45D08E16.7030601@redhat.com> Ok, we are getting close to test2, and we need to make a decision about this soon. Here is a list of outstanding issues that we need to address for using pulseaudio in F7: - pulseaudio needs to work with suspend/resume (228205, has a patch) - pulseaudio should work with fast user switching (228287) - gstreamer-plugins-pulse needs to be in the default install - gstreamer must be configured to should be configured to use the pulse plugin - alsa-plugins-pulse needs to be in the distribution (222248) - alsa needs to be configured to use the pulse plugin - pulseaudio needs to be started at login, probably via an autostart file Some of these changes affects more than the default desktop. If gstreamer and alsa are configured to use pulseaudio, users won't here anything unless pulseaudio is running, so kde and xfce will have to be prepared for this too. From drago01 at gmail.com Mon Feb 12 16:13:42 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 12 Feb 2007 17:13:42 +0100 Subject: Using pulseaudio by default In-Reply-To: <45D08E16.7030601@redhat.com> References: <45D08E16.7030601@redhat.com> Message-ID: <45D09236.7010901@gmail.com> Matthias Clasen wrote: > - alsa needs to be configured to use the pulse plugin shouldn't this be the other way round? pulseaudio->alsa ? or did I miss something? or is it something like dmix? From mclasen at redhat.com Mon Feb 12 16:21:32 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 11:21:32 -0500 Subject: Using pulseaudio by default In-Reply-To: <45D09236.7010901@gmail.com> References: <45D08E16.7030601@redhat.com> <45D09236.7010901@gmail.com> Message-ID: <45D0940C.6050405@redhat.com> dragoran wrote: > Matthias Clasen wrote: >> - alsa needs to be configured to use the pulse plugin > shouldn't this be the other way round? > pulseaudio->alsa ? > or did I miss something? > or is it something like dmix? pulseaudio is using the alsa devices, every other alsa client needs to be redirected to go through pulse. The alsa libraries have a plugin framework that make this possible. From rdieter at fedoraproject.org Mon Feb 12 16:08:11 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 12 Feb 2007 10:08:11 -0600 Subject: Using pulseaudio by default References: <45D08E16.7030601@redhat.com> Message-ID: Matthias Clasen wrote: > Some of these changes affects more than the default desktop. If gstreamer > and alsa are configured to use pulseaudio, users won't here anything > unless pulseaudio is running, so kde and xfce will have to be prepared > for this too. akode includes playback for pulseaudio, I'll look into enabling that. -- Rex From drago01 at gmail.com Mon Feb 12 16:26:22 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 12 Feb 2007 17:26:22 +0100 Subject: Using pulseaudio by default In-Reply-To: <45D0940C.6050405@redhat.com> References: <45D08E16.7030601@redhat.com> <45D09236.7010901@gmail.com> <45D0940C.6050405@redhat.com> Message-ID: <45D0952E.10205@gmail.com> Matthias Clasen wrote: > dragoran wrote: >> Matthias Clasen wrote: >>> - alsa needs to be configured to use the pulse plugin >> shouldn't this be the other way round? >> pulseaudio->alsa ? >> or did I miss something? >> or is it something like dmix? > pulseaudio is using the alsa devices, every other alsa client needs to > be redirected > to go through pulse. The alsa libraries have a plugin framework that > make this possible. > ok but why redirect apps that uses alsa directly trought pulse? what is the gain when doing this? I don't know much about pulseaudio but in case of esd I always preffered that a app bypassed esd . From rdieter at fedoraproject.org Mon Feb 12 16:29:25 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 12 Feb 2007 10:29:25 -0600 Subject: Using pulseaudio by default References: <45D08E16.7030601@redhat.com> <45D09236.7010901@gmail.com> <45D0940C.6050405@redhat.com> <45D0952E.10205@gmail.com> Message-ID: dragoran wrote: > ok but why redirect apps that uses alsa directly trought pulse? > what is the gain when doing this? Presumably to avoid device contention (in cases where dmix isn't available, of course). -- Rex From naziirr at gmail.com Sat Feb 17 10:56:58 2007 From: naziirr at gmail.com (Ramagudi Naziir) Date: Sat, 17 Feb 2007 12:56:58 +0200 Subject: Desktop problems with 2.6.20 Message-ID: <4f436aae0702170256g68c13767u357094b64b7c1882@mail.gmail.com> Hello, I have been running 2.6.20-rc5 successfully with FC6. Yesterday I have git pulled the latest 2.6.20. I have used make oldconfig and chose all default answers. I have built and run the new kernel successfully. The problems is that now the Desktop don't show up. I see the fedora login screen,but after I login I can only see the mouse icon and two white stripes (one in the upper screen boundary and the second in the lower). besides that the screen is totally black. I can move the mouse. When I press Alt-F2 I can see the "run command" menu, but i cannot type anything into it. pressing the 'x' button does close it. oh, and i can see the popup window of the "security updates waiting", but it is not in the regular place (upper right corner) - it is in the upper left corner. Can anyone help please ? There are no significant error messages in /var/log/message or /var/log/Xorg.0.log. What can I do please ? Thank You naziir. From davidz at redhat.com Sun Feb 18 17:09:46 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 18 Feb 2007 12:09:46 -0500 Subject: Polishing stuff - gnome-filesystem package Message-ID: <1171818586.2708.41.camel@zelda.fubar.dk> Hi, Given the F7 schedule was pushed back one month I thought perhaps we could spend this time on polishing stuff. It looks like gnome-screensaver already drops a directory Pictures in /etc/skel/Pictures [1] to ensure that the user gets the directory ~/Pictures. Personally, I'm a big fan of having pre-made directories in a new users home directory. Mostly because it allows us to patch our applications so they open the file chooser in the right directory. I think we ought to do more of this. I also think we ought to formalize a bit. So someone last week brought forward the idea of a gnome-filesystem package that put files in /etc/skel. This package would provide /etc/skel/Documents Downloads Music Pictures Public plus perhaps a few others. This brings back the good old discussion of whether we should use localized names; e.g. if the users preferred locale is, say, Danish then perhaps the user perhaps would expect ~/Dokumenter Hentede Filer Musik Billeder Delte Filer Well, - fact of the matter is that many programs today already hardcode paths like ~/Pictures (gnome-screensaver, f-spot at least [2]) and ~/Music (banshee at least; possibly Rhythmbox too). - We've already have a precedent with ~/Desktop and, ugh, it shows in Nautilus as "Desktop" in a danish locale, not "Skrivebord" as I would assume. That's a bug we *could* address; see item 3. below. - It's could be considered a bug that gnome-usershare don't make sure that a ~/Public directory is created via e.g. /etc/skel (same thing as Ray fixed for gnome-screensaver). At least I consider this a bug. So, call to action 1. Someone create a gnome-filesystem package that populate /etc/skel. Include some docs with instructions on what this is, why etc. etc. Make sure it's evident how it should be used; e.g. what are the naming conventions for where I should save my files if I'm a Bittorrent client (perhaps in ~/Downloads/MyAppName) etc. etc. Make sure this package is mentioned in the Fedora packaging guide lines. Make it clear that requests for new top-level directories in $HOME can be applied for via the normal bugzilla process. (we could even call it desktop-filesystem if the KDE people agree this is a good idea. But I'm unsure how KDE works (Rex?) and we can always rename the package later.) 2. File bugs against relevant packages to - Require the gnome-filesystem package instead of dropping it's own directories into /etc/skel - Use the appropriate directory (e.g. Pictures instead of Photos or vice versa) in the app - Make sure the app defaults to the correct directory for usage; e.g. Firefox should do all downloads to ~/Downloads if that's what the gnome-filesystem package prescribes (or would that violate "branding"? [4]); make sure f-spot uses ~/Pictures etc. 3. Talk alexl into putting a feature into Nautilus / gnome-vfs so it can read a .localization file (much like it reads a .hidden file, see [3]) such that the gnome-filesystem package can drop a file /etc/skel/.localization that e.g. looks like this (or whatever format, preferable interoperable with other desktops etc. etc. [dir Desktop] Name[da]=Skrivebord Name[de]=Schreibtisch .. [dir Pictures] Name[da]=Billeder Name[de]=Abbildungen .. 4. If it's possible to put emblems on the files in gnome-filesystem we could do that too. Alex? The work for doing this, perhaps except 3. (but I doubt it's much work either), is a no-brainer (unless you insist on name-on-disk-should- be-localized-crack but that should be rebutted above) that will make our desktop look more polished. We should just do this. Or we could just do what we normally do - sit here and wait for upstream to make a decision. I doubt that will happen for the next 2-3 years given the latest exchange of flames on d-d-l. So, in some sense, I'm taking the flamewar here :-) Thanks, David [1] : See http://cvs.fedora.redhat.com/viewcvs/devel/gnome-screensaver/gnome-screensaver.spec?r1=1.134&r2=1.135 [2] : Actually f-spot requires ~/Photos, even in a danish locale, and gives you an ugly modal dialog error message if it doesn't exist. But either gnome-screensaver and/or f-spot is patchable :-) [3] : See http://curtis.hovey.name/2007/02/16/localizing-standard-directories-or-nautilus-hidden-hacks/ [4] : If it violates Firefox branding rules to change the default download directory... then it's probably a sign that we should probably switch the default browser in the GNOME desktop away from Firefox. Of course this is my own opinion.... From davidz at redhat.com Sun Feb 18 17:19:16 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 18 Feb 2007 12:19:16 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171818586.2708.41.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> Message-ID: <1171819156.2708.45.camel@zelda.fubar.dk> On Sun, 2007-02-18 at 12:09 -0500, David Zeuthen wrote: > 4. If it's possible to put emblems on the files in gnome-filesystem > we could do that too. Alex? and, of course, I forgot 5. Make sure the GTK+ file chooser bookmarks and the Nautilus bookmarks (are they the same? I keep forgetting) got the folders as default I also recall that Mandriva is doing something like this already; it's probably worth looking into the specifics. David From rstrode at redhat.com Sun Feb 18 17:19:46 2007 From: rstrode at redhat.com (Ray Strode) Date: Sun, 18 Feb 2007 12:19:46 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171818586.2708.41.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> Message-ID: <45D88AB2.204@redhat.com> Hi, > So someone last week brought forward the idea of a gnome-filesystem > package that put files in /etc/skel. This package would provide > > /etc/skel/Documents > Downloads > Music > Pictures > Public > It should also own common other gnome directories like /usr/share/gnome/help, etc. and include a .gtk-bookmarks file, too, so these premade folders make it into the file chooser. --Ray From mclasen at redhat.com Sun Feb 18 17:27:48 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 18 Feb 2007 12:27:48 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <45D88AB2.204@redhat.com> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> Message-ID: <1171819668.3436.0.camel@localhost.localdomain> On Sun, 2007-02-18 at 12:19 -0500, Ray Strode wrote: > Hi, > > So someone last week brought forward the idea of a gnome-filesystem > > package that put files in /etc/skel. This package would provide > > > > /etc/skel/Documents > > Downloads > > Music > > Pictures > > Public > > > It should also own common other gnome directories like > /usr/share/gnome/help, > etc. and include a .gtk-bookmarks file, too, so these premade folders > make it into the file chooser. Slight problem is that we have no framework for translatable bookmarks. Nautilus and GTK+ just assume that the bookmarks are in the preferred language. From davidz at redhat.com Sun Feb 18 17:34:27 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 18 Feb 2007 12:34:27 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171819668.3436.0.camel@localhost.localdomain> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> Message-ID: <1171820067.2708.50.camel@zelda.fubar.dk> On Sun, 2007-02-18 at 12:27 -0500, Matthias Clasen wrote: > On Sun, 2007-02-18 at 12:19 -0500, Ray Strode wrote: > > Hi, > > > So someone last week brought forward the idea of a gnome-filesystem > > > package that put files in /etc/skel. This package would provide > > > > > > /etc/skel/Documents > > > Downloads > > > Music > > > Pictures > > > Public > > > > > It should also own common other gnome directories like > > /usr/share/gnome/help, > > etc. and include a .gtk-bookmarks file, too, so these premade folders > > make it into the file chooser. > > Slight problem is that we have no framework for translatable bookmarks. > Nautilus and GTK+ just assume that the bookmarks are in the preferred > language. Well, if problem 3. is solved in gnome-vfs, e.g. char *gnome_vfs_get_localized_name_for_folder (const char *path) the I'm not sure it's hard to fix the gnome-vfs back-end of the filechooser. Wouldn't that work? Or are GTK+ bookmarks used elsewhere too? Also, even if we don't solve problem 3. until Fedora 8 I still think we should do this. It's not like apps aren't hardcoding folders today.. David From mclasen at redhat.com Sun Feb 18 17:45:50 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 18 Feb 2007 12:45:50 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171820067.2708.50.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> Message-ID: <1171820750.3436.2.camel@localhost.localdomain> On Sun, 2007-02-18 at 12:34 -0500, David Zeuthen wrote: > Well, if problem 3. is solved in gnome-vfs, e.g. > > char *gnome_vfs_get_localized_name_for_folder (const char *path) > > the I'm not sure it's hard to fix the gnome-vfs back-end of the > filechooser. Wouldn't that work? Or are GTK+ bookmarks used elsewhere > too? They are used by nautilus and the panel. > Also, even if we don't solve problem 3. until Fedora 8 I still think we > should do this. It's not like apps aren't hardcoding folders today... I agree. From davidz at redhat.com Sun Feb 18 17:53:40 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 18 Feb 2007 12:53:40 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171820067.2708.50.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> Message-ID: <1171821220.2708.66.camel@zelda.fubar.dk> On Sun, 2007-02-18 at 12:34 -0500, David Zeuthen wrote: > On Sun, 2007-02-18 at 12:27 -0500, Matthias Clasen wrote: > > On Sun, 2007-02-18 at 12:19 -0500, Ray Strode wrote: > > > Hi, > > > > So someone last week brought forward the idea of a gnome-filesystem > > > > package that put files in /etc/skel. This package would provide > > > > > > > > /etc/skel/Documents > > > > Downloads > > > > Music > > > > Pictures > > > > Public > > > > > > > It should also own common other gnome directories like > > > /usr/share/gnome/help, > > > etc. and include a .gtk-bookmarks file, too, so these premade folders > > > make it into the file chooser. > > > > Slight problem is that we have no framework for translatable bookmarks. > > Nautilus and GTK+ just assume that the bookmarks are in the preferred > > language. > > Well, if problem 3. is solved in gnome-vfs, e.g. > > char *gnome_vfs_get_localized_name_for_folder (const char *path) > > the I'm not sure it's hard to fix the gnome-vfs back-end of the > filechooser. Wouldn't that work? Or are GTK+ bookmarks used elsewhere > too? I mean, you'd just do, just before rendering the localized name, static char * bookmark_get_localized_name (Bookmark *b) { char *ret; if (strcmp (b->name, g_basename (b->path) == 0)) { char *l; l = gnome_vfs_get_localized_name_for_folder (b->path); if (l != NULL) { ret = g_strdup (g_basename (l)); g_free (l); goto out; } g_free (l); } ret = g_stdup (b->name); out: return ret; } but perhaps that's a bit ugly and too magic. The big problem here is that people can edit the name of bookmarks. If they do that, well, all bets are off and people are on their own. (We should be able to handle name editing too though - e.g. if I'm in a Danish locale and change the bookmark name to 'Billeder' then the bookmark editor is smart about things and sets it to 'Pictures' since 'Billeder' is the danish translation for 'Pictures'. I'm not sure it's worth the trouble though; if people wants to change the name of a bookmark we probably should respect it even in other locales.) David From roguexz at gmail.com Sun Feb 18 18:13:24 2007 From: roguexz at gmail.com (Rogue) Date: Sun, 18 Feb 2007 23:43:24 +0530 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171821220.2708.66.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> <1171821220.2708.66.camel@zelda.fubar.dk> Message-ID: <45D89744.8010204@gmail.com> An HTML attachment was scrubbed... URL: From david at lovesunix.net Sun Feb 18 18:25:13 2007 From: david at lovesunix.net (David Nielsen) Date: Sun, 18 Feb 2007 19:25:13 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171820067.2708.50.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> Message-ID: <1171823113.13400.11.camel@dawkins> s?n, 18 02 2007 kl. 12:34 -0500, skrev David Zeuthen: > > Also, even if we don't solve problem 3. until Fedora 8 I still think we > should do this. It's not like apps aren't hardcoding folders today.. Some of them are.. f-spot for one hardcodes ~/Photos much to my annoyance because I have a setup entirely in Danish and it makes kittens cry every time I see that one folder.. please think of the kittens. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From rdieter at math.unl.edu Sun Feb 18 19:43:02 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 18 Feb 2007 13:43:02 -0600 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171818586.2708.41.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> Message-ID: David Zeuthen wrote: > Given the F7 schedule was pushed back one month I thought perhaps we > could spend this time on polishing stuff. ... > So someone last week brought forward the idea of a gnome-filesystem > package that put files in /etc/skel. This package would provide > > /etc/skel/Documents > Downloads > Music > Pictures > Public Good stuff, I was thinking of adding similar/dup items to kde-filesystem. Maybe we can make a generic userdir/skel package for this kind of thing. Reviewers might get picky of 2 pkgs (try to) own the same dirs (though I don't think it necessarily a problem in this case). -- Rex From davidz at redhat.com Sun Feb 18 19:51:18 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 18 Feb 2007 14:51:18 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: References: <1171818586.2708.41.camel@zelda.fubar.dk> Message-ID: <1171828278.2708.72.camel@zelda.fubar.dk> On Sun, 2007-02-18 at 13:43 -0600, Rex Dieter wrote: > David Zeuthen wrote: > > > Given the F7 schedule was pushed back one month I thought perhaps we > > could spend this time on polishing stuff. > ... > > So someone last week brought forward the idea of a gnome-filesystem > > package that put files in /etc/skel. This package would provide > > > > /etc/skel/Documents > > Downloads > > Music > > Pictures > > Public > > Good stuff, I was thinking of adding similar/dup items to > kde-filesystem. Maybe we can make a generic userdir/skel package for > this kind of thing. Reviewers might get picky of 2 pkgs (try to) own > the same dirs (though I don't think it necessarily a problem in this case). What about having a co-maintained desktop-filesystem package with desktop-filesystem-gnome and desktop-filesystem-kde sub packages? (possibly other sub packages for e.g. xfce) That would provide the various desktop maintainers with a natural way of keeping abreast of changes to the user directory layouts. Also the docs for how packages should integrate would live in the main desktop- filesystem package and our packaging guidelines would point to that. David From bnocera at redhat.com Mon Feb 19 00:37:14 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 19 Feb 2007 00:37:14 +0000 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <45D89744.8010204@gmail.com> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> <1171821220.2708.66.camel@zelda.fubar.dk> <45D89744.8010204@gmail.com> Message-ID: <1171845434.16466.4.camel@cookie.hadess.net> On Sun, 2007-02-18 at 23:43 +0530, Rogue wrote: > I am a little naive when it comes to programming in linux, but > couldn't we achieve the same result by symlinking folders? > > Like: > > .Desktop -> Localized desktop name > .Pictures -> Localized pictures folder name > > And add support for these special folder names. Wouldn't this be > something feasible? > > Just my few points. This would mean they would show up as links in the file manager(s). How would you clean them up when switching languages as well? From alexl at redhat.com Mon Feb 19 09:38:32 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Feb 2007 10:38:32 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171818586.2708.41.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> Message-ID: <1171877912.23837.23.camel@greebo> On Sun, 2007-02-18 at 12:09 -0500, David Zeuthen wrote: > This brings back the good old discussion of whether we should use > localized names; e.g. if the users preferred locale is, say, Danish then > perhaps the user perhaps would expect > > ~/Dokumenter > Hentede Filer > Musik > Billeder > Delte Filer Ugh, this old thread... > 3. Talk alexl into putting a feature into Nautilus / gnome-vfs so it > can read a .localization file (much like it reads a .hidden file, > see [3]) such that the gnome-filesystem package can drop a file > /etc/skel/.localization that e.g. looks like this (or whatever > format, preferable interoperable with other desktops etc. etc. > > [dir Desktop] > Name[da]=Skrivebord > Name[de]=Schreibtisch > .. > > [dir Pictures] > Name[da]=Billeder > Name[de]=Abbildungen > .. How do you update this file as new translations are added? How do you support users renaming or moving the directory? How do you explain to people that the folders display differently in some apps (terminal, non-gtk apps, etc)? Even inside gnome things will be strange, filenames will be /home/alex/Pictures/cats, but it will display as [home][alex][Bilder][cats] in the pathbar. I know we try to avoid showing paths as much as possible in gnome, but we're far from succeeding in all places. > 4. If it's possible to put emblems on the files in gnome-filesystem > we could do that too. Alex? Not possible currently. > The work for doing this, perhaps except 3. (but I doubt it's much work > either), is a no-brainer (unless you insist on name-on-disk-should- > be-localized-crack but that should be rebutted above) that will make our > desktop look more polished. I'm currently of the opinion that we should use localized filenames on disk, and instead have a mapping from "well known location" (such as desktop, music dir, photos dir, etc). This means we get consistent naming in *all* apps, including the terminal, and it allows users to move these locations where they want them (including in subdirs or hidden dirs if wanted). Now, I've changed opinion on this during the years, so I might be convinced to change my mind again, but its hardly done by calling other opinions crack. Its far from a clear cut decision. Each side has advantages and disadvantages. I'm on the localized filenames side because its the only one that can produce an internally consistent translated ui (*all* of the ui, not just cherry picking some parts of it) on a localized desktop. > We should just do this. Or we could just do what we normally do - sit > here and wait for upstream to make a decision. I doubt that will happen > for the next 2-3 years given the latest exchange of flames on d-d-l. So, > in some sense, I'm taking the flamewar here :-) I really dislike this handwaving of "upstream" not doing anything. Upstream is not some mythical person. *WE* are upstream (such a change would be in glib/gtk/gnome-vfs/nautilus which is mostly maintained by redhat). If upstream failed to do something it is a failure on *our* part. I've myself spent quite some time on this the last time it came up. But at the end I decided to not solve it, not because upstream can't decide, but because i had a billion other things to do and not enough time to do all of them. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a sword-wielding chivalrous cat burglar on a search for his missing sister. She's a plucky hip-hop archaeologist from out of town. They fight crime! From pmatilai at laiskiainen.org Mon Feb 19 10:55:30 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 19 Feb 2007 12:55:30 +0200 (EET) Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171823113.13400.11.camel@dawkins> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> <1171823113.13400.11.camel@dawkins> Message-ID: On Sun, 18 Feb 2007, David Nielsen wrote: > s?n, 18 02 2007 kl. 12:34 -0500, skrev David Zeuthen: >> >> Also, even if we don't solve problem 3. until Fedora 8 I still think we >> should do this. It's not like apps aren't hardcoding folders today.. > > Some of them are.. f-spot for one hardcodes ~/Photos much to my > annoyance because I have a setup entirely in Danish and it makes kittens > cry every time I see that one folder.. please think of the kittens. Some apps hardcoding folder names doesn't make it a good idea that should be copied everywhere. I don't see anything harmful in prepopulating new users home directories with some clues how you might want to organize your data, it might be helpful to a computer-illiterate. Just as long as you don't *force* those directories to be used (in other words, things don't break if you remove them and use what you want to use) And no, I don't use F-Spot. I'm not going to change my >10 year old home directory structure just because some new application thinks it knows better than me. - Panu - From fedora at leemhuis.info Mon Feb 19 12:40:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Feb 2007 13:40:00 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> <1171823113.13400.11.camel@dawkins> Message-ID: <45D99AA0.8050602@leemhuis.info> On 19.02.2007 11:55, Panu Matilainen wrote: > [...] > I don't see anything harmful in prepopulating new users home directories > with some clues how you might want to organize your data, it might be > helpful to a computer-illiterate. +1 > Just as long as you don't *force* those > directories to be used +infinite > [...] I'm not going to change my >10 year old > home directory structure just because some new application thinks it knows > better than me. +infinite Site note: I like Gnome and that it has less knobs to adjust. And that it sometimes forces a user into the right direction. But it should not force the user to much into a scheme. CU thl P.S.:We should also not forget users on the command-line and with different file manager users. They will get confused if directories have a different name suddenly P.P.S.:Even today Gnome annoys me already with the Desktop and Templates dir they create -- that's why I have alias ls='ls --color=tty -I Desktop -I Templates' in my .bashrc :-/ From rdieter at math.unl.edu Mon Feb 19 12:41:17 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Feb 2007 06:41:17 -0600 Subject: Polishing stuff - gnome-filesystem package References: <1171818586.2708.41.camel@zelda.fubar.dk> <1171828278.2708.72.camel@zelda.fubar.dk> Message-ID: David Zeuthen wrote: > On Sun, 2007-02-18 at 13:43 -0600, Rex Dieter wrote: >> Good stuff, I was thinking of adding similar/dup items to >> kde-filesystem. Maybe we can make a generic userdir/skel package for >> this kind of thing. Reviewers might get picky of 2 pkgs (try to) own >> the same dirs (though I don't think it necessarily a problem in this >> case). > > What about having a co-maintained desktop-filesystem package with > desktop-filesystem-gnome and desktop-filesystem-kde sub packages? > (possibly other sub packages for e.g. xfce) > > That would provide the various desktop maintainers with a natural way of > keeping abreast of changes to the user directory layouts. Also the docs > for how packages should integrate would live in the main desktop- > filesystem package and our packaging guidelines would point to that. That makes a whole lot of sense. -- Rex From nphilipp at redhat.com Mon Feb 19 13:54:12 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 19 Feb 2007 14:54:12 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> <1171823113.13400.11.camel@dawkins> Message-ID: <1171893252.13418.18.camel@gibraltar.stuttgart.redhat.com> On Mon, 2007-02-19 at 12:55 +0200, Panu Matilainen wrote: > On Sun, 18 Feb 2007, David Nielsen wrote: > > s?n, 18 02 2007 kl. 12:34 -0500, skrev David Zeuthen: > >> > >> Also, even if we don't solve problem 3. until Fedora 8 I still think we > >> should do this. It's not like apps aren't hardcoding folders today.. > > > > Some of them are.. f-spot for one hardcodes ~/Photos much to my > > annoyance because I have a setup entirely in Danish and it makes kittens > > cry every time I see that one folder.. please think of the kittens. > > Some apps hardcoding folder names doesn't make it a good idea that should > be copied everywhere. +1 If apps would like to open certain directories for e.g. photos, this could easily be defined as a /desktop/gnome/foldernames/photos gconf key. This would let us we-have-lived-well-with-this-layout-for-years types point these apps to the directories we use. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From ch.nolte at noltec.org Mon Feb 19 14:34:57 2007 From: ch.nolte at noltec.org (Christian Nolte) Date: Mon, 19 Feb 2007 15:34:57 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171893252.13418.18.camel@gibraltar.stuttgart.redhat.com> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> <1171823113.13400.11.camel@dawkins> <1171893252.13418.18.camel@gibraltar.stuttgart.redhat.com> Message-ID: <45D9B591.8080506@noltec.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nils Philippsen schrieb: > On Mon, 2007-02-19 at 12:55 +0200, Panu Matilainen wrote: >> On Sun, 18 Feb 2007, David Nielsen wrote: >>> s?n, 18 02 2007 kl. 12:34 -0500, skrev David Zeuthen: >>>> Also, even if we don't solve problem 3. until Fedora 8 I still think we >>>> should do this. It's not like apps aren't hardcoding folders today.. >>> Some of them are.. f-spot for one hardcodes ~/Photos much to my >>> annoyance because I have a setup entirely in Danish and it makes kittens >>> cry every time I see that one folder.. please think of the kittens. >> Some apps hardcoding folder names doesn't make it a good idea that should >> be copied everywhere. > > +1 > > If apps would like to open certain directories for e.g. photos, this > could easily be defined as a /desktop/gnome/foldernames/photos gconf > key. This would let us we-have-lived-well-with-this-layout-for-years > types point these apps to the directories we use. +1 This IMHO is the best way to map these default folders to already existing folders. If we switch to this scheme we should give the user the possibilty of choosing if he wants the default-folder structure or if he wants to define some of these folders himself. Furthermore: What if a user changes the name of one of his default-folder via a terminal? Perhaps this could be intercepted with inotify? - -- Christian Nolte mailto:ch.nolte at noltec.org key : http://www.noltec.org/christian-nolte.asc or : www.keyserver.net GPG-fingerprint: 1088 6C2D 1496 0A34 D159 1108 08D8 C0D2 77E1 5BBC - ---------------------------------------------------------------------- For more than 4 generations the IT Professionals were the guardians of quality and stability in software. Before the dark times. Before Microsoft... - ---------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF2bWRCNjA0nfhW7wRAk4BAKCUZV9OpxGnLVLUgsqtFWnUS7xjTgCcDqRp sZGoVB9dCA2tPE7d/FM41og= =4Uti -----END PGP SIGNATURE----- From pmatilai at laiskiainen.org Mon Feb 19 14:41:08 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 19 Feb 2007 16:41:08 +0200 (EET) Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171893252.13418.18.camel@gibraltar.stuttgart.redhat.com> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> <1171823113.13400.11.camel@dawkins> <1171893252.13418.18.camel@gibraltar.stuttgart.redhat.com> Message-ID: On Mon, 19 Feb 2007, Nils Philippsen wrote: > On Mon, 2007-02-19 at 12:55 +0200, Panu Matilainen wrote: >> On Sun, 18 Feb 2007, David Nielsen wrote: >>> s?n, 18 02 2007 kl. 12:34 -0500, skrev David Zeuthen: >>>> >>>> Also, even if we don't solve problem 3. until Fedora 8 I still think we >>>> should do this. It's not like apps aren't hardcoding folders today.. >>> >>> Some of them are.. f-spot for one hardcodes ~/Photos much to my >>> annoyance because I have a setup entirely in Danish and it makes kittens >>> cry every time I see that one folder.. please think of the kittens. >> >> Some apps hardcoding folder names doesn't make it a good idea that should >> be copied everywhere. > > +1 > > If apps would like to open certain directories for e.g. photos, this > could easily be defined as a /desktop/gnome/foldernames/photos gconf > key. This would let us we-have-lived-well-with-this-layout-for-years > types point these apps to the directories we use. Amen. Having a central place to tell the system "my photo/music/etc collection is here" and have all the relevant applications honor that would actually be very nice. Assuming there's a way to set them through application preferences or such, having to resort to gconf-editor to tune such things is not ok :) Much like having a central place to configure http proxy would be nice (would be, because major applications like firefox don't honor gnome settings :-/ ) - Panu - From notting at redhat.com Mon Feb 19 15:38:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 10:38:42 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: References: <1171818586.2708.41.camel@zelda.fubar.dk> <1171828278.2708.72.camel@zelda.fubar.dk> Message-ID: <20070219153842.GA27059@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > > That would provide the various desktop maintainers with a natural way of > > keeping abreast of changes to the user directory layouts. Also the docs > > for how packages should integrate would live in the main desktop- > > filesystem package and our packaging guidelines would point to that. > > That makes a whole lot of sense. Actually, if *all* you're talking about is /etc/skel stuff, shouldn't it be user-desktop-filesystem - save desktop-filesystem for /usr/share/applications, /usr/share/gnome/help, etc.? Bill, getting off of his bikeshed... From drago01 at gmail.com Mon Feb 19 16:10:22 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 19 Feb 2007 17:10:22 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171818586.2708.41.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> Message-ID: <45D9CBEE.70402@gmail.com> David Zeuthen wrote: > [dir Desktop] > Name[da]=Skrivebord > Name[de]=Schreibtisch > .. > I disagree on changing the name of "desktop" many users are used to it (even windows users) so changing it will only confuse them. From alexl at redhat.com Mon Feb 19 16:34:04 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Feb 2007 17:34:04 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <45D9CBEE.70402@gmail.com> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D9CBEE.70402@gmail.com> Message-ID: <1171902844.23837.35.camel@greebo> On Mon, 2007-02-19 at 17:10 +0100, dragoran wrote: > David Zeuthen wrote: > > [dir Desktop] > > Name[da]=Skrivebord > > Name[de]=Schreibtisch > > .. > > > I disagree on changing the name of "desktop" many users are used to it > (even windows users) so changing it will only confuse them. How could windows users be used to it? Windows translates it. Unless of course you run an english Windows, but nobody is forcing you to use any locale but english in that case. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a suave one-eyed astronaut searching for his wife's true killer. She's an enchanted psychic pearl diver living on borrowed time. They fight crime! From drago01 at gmail.com Mon Feb 19 16:41:26 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 19 Feb 2007 17:41:26 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171902844.23837.35.camel@greebo> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D9CBEE.70402@gmail.com> <1171902844.23837.35.camel@greebo> Message-ID: <45D9D336.8050700@gmail.com> Alexander Larsson wrote: > On Mon, 2007-02-19 at 17:10 +0100, dragoran wrote: > >> David Zeuthen wrote: >> >>> [dir Desktop] >>> Name[da]=Skrivebord >>> Name[de]=Schreibtisch >>> .. >>> >>> >> I disagree on changing the name of "desktop" many users are used to it >> (even windows users) so changing it will only confuse them. >> > > How could windows users be used to it? Windows translates it. > Unless of course you run an english Windows, but nobody is forcing you > to use any locale but english in that case. > > I am using a german windows on one of my boxes and it uses "Desktop" (maybe other windows versions are translated; I only used english and german where it is Desktop) German: Dokumente und Einstellungen//Desktop From alexl at redhat.com Mon Feb 19 17:01:24 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Feb 2007 18:01:24 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <45D9D336.8050700@gmail.com> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D9CBEE.70402@gmail.com> <1171902844.23837.35.camel@greebo> <45D9D336.8050700@gmail.com> Message-ID: <1171904484.23837.44.camel@greebo> On Mon, 2007-02-19 at 17:41 +0100, dragoran wrote: > Alexander Larsson wrote: > > How could windows users be used to it? Windows translates it. > > Unless of course you run an english Windows, but nobody is forcing you > > to use any locale but english in that case. > > > > > I am using a german windows on one of my boxes and it uses "Desktop" > (maybe other windows versions are translated; I only used english and > german where it is Desktop) > German: > Dokumente und Einstellungen//Desktop Hmmm, in swedish it is translated. A common problem with the translated-names-on-disk approach is that some applications don't use the correct win32 api to locate these directories, but instead just use the english names. Maybe this is what happened to you, or maybe its different in different locales. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an ungodly Amish filmmaker fleeing from a secret government programme. She's a vivacious extravagent mermaid married to the Mob. They fight crime! From drago01 at gmail.com Mon Feb 19 17:11:18 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 19 Feb 2007 18:11:18 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171904484.23837.44.camel@greebo> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D9CBEE.70402@gmail.com> <1171902844.23837.35.camel@greebo> <45D9D336.8050700@gmail.com> <1171904484.23837.44.camel@greebo> Message-ID: <45D9DA36.4060601@gmail.com> Alexander Larsson wrote: > On Mon, 2007-02-19 at 17:41 +0100, dragoran wrote: > >> Alexander Larsson wrote: >> > > >>> How could windows users be used to it? Windows translates it. >>> Unless of course you run an english Windows, but nobody is forcing you >>> to use any locale but english in that case. >>> >>> >>> >> I am using a german windows on one of my boxes and it uses "Desktop" >> (maybe other windows versions are translated; I only used english and >> german where it is Desktop) >> German: >> Dokumente und Einstellungen//Desktop >> > > Hmmm, in swedish it is translated. > > A common problem with the translated-names-on-disk approach is that some > applications don't use the correct win32 api to locate these > directories, but instead just use the english names. Maybe this is what > happened to you, or maybe its different in different locales. > > no in german it always was desktop on all windows installs since 95. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's an ungodly Amish filmmaker fleeing from a secret government programme. > She's a vivacious extravagent mermaid married to the Mob. They fight crime! > > From pmatilai at laiskiainen.org Mon Feb 19 18:33:02 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 19 Feb 2007 20:33:02 +0200 (EET) Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171904484.23837.44.camel@greebo> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D9CBEE.70402@gmail.com> <1171902844.23837.35.camel@greebo> <45D9D336.8050700@gmail.com> <1171904484.23837.44.camel@greebo> Message-ID: On Mon, 19 Feb 2007, Alexander Larsson wrote: > On Mon, 2007-02-19 at 17:41 +0100, dragoran wrote: >> Alexander Larsson wrote: > >>> How could windows users be used to it? Windows translates it. >>> Unless of course you run an english Windows, but nobody is forcing you >>> to use any locale but english in that case. >>> >>> >> I am using a german windows on one of my boxes and it uses "Desktop" >> (maybe other windows versions are translated; I only used english and >> german where it is Desktop) >> German: >> Dokumente und Einstellungen//Desktop > > Hmmm, in swedish it is translated. And in Finnish. > A common problem with the translated-names-on-disk approach is that some > applications don't use the correct win32 api to locate these > directories, but instead just use the english names. Maybe this is what > happened to you, or maybe its different in different locales. That, and some specific things are simply better left untranslated: In Windows, "Administrator" the user account name has been translated to "J?rjestelm?yll?pit?j?" (or something resembling that). Try typing that in a hurry, and with a little bit of luck with a non-finnish keyboard layout :) - Panu - From rtlm10 at gmail.com Mon Feb 19 19:32:42 2007 From: rtlm10 at gmail.com (Russell Harrison) Date: Mon, 19 Feb 2007 14:32:42 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D88AB2.204@redhat.com> <1171819668.3436.0.camel@localhost.localdomain> <1171820067.2708.50.camel@zelda.fubar.dk> <1171823113.13400.11.camel@dawkins> Message-ID: <1ed4a0130702191132q4645fd43pc67c2ff74267ff71@mail.gmail.com> Well I was in the middle of writing a response but since Panu's is almost exactly what I was going to say anyway. (even down to the wording, creepy) On 2/19/07, Panu Matilainen wrote: > Some apps hardcoding folder names doesn't make it a good idea that should > be copied everywhere. +1 I don't see anything harmful in prepopulating new users home directories > with some clues how you might want to organize your data, it might be > helpful to a computer-illiterate. Just as long as you don't *force* those > directories to be used (in other words, things don't break if you remove > them and use what you want to use) +10 And no, I don't use F-Spot. I'm not going to change my >10 year old > home directory structure just because some new application thinks it knows > better than me. +1000 Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From fngdr at yahoo.com.cn Tue Feb 20 07:08:01 2007 From: fngdr at yahoo.com.cn (da feng) Date: Tue, 20 Feb 2007 15:08:01 +0800 (CST) Subject: fedora 5 Message-ID: <948444.74965.qm@web92010.mail.cnb.yahoo.com> hello: NVIDIA video driver seems doesn't support "suspend" under fedora 5. The "hibernate" also doesn't work. The video driver fails restarting. And when I choose openGL/GLX information from the video server setting menu, the server restart, the session terminate. But normally it works fine. --------------------------------- ??????-3.5G???20M?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at redhat.com Tue Feb 20 08:28:33 2007 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 20 Feb 2007 09:28:33 +0100 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D9CBEE.70402@gmail.com> <1171902844.23837.35.camel@greebo> <45D9D336.8050700@gmail.com> <1171904484.23837.44.camel@greebo> Message-ID: <1171960113.22738.35.camel@greebo> On Mon, 2007-02-19 at 20:33 +0200, Panu Matilainen wrote: > > That, and some specific things are simply better left untranslated: In > Windows, "Administrator" the user account name has been translated to > "J?rjestelm?yll?pit?j?" (or something resembling that). Try typing > that in a hurry, and with a little bit of luck with a non-finnish > keyboard layout I feel for you. :) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a sword-wielding soccer-playing ex-con with a winning smile and a way with the ladies. She's a cold-hearted punk fairy princess from a family of eight older brothers. They fight crime! From pmatilai at laiskiainen.org Tue Feb 20 12:03:55 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 20 Feb 2007 14:03:55 +0200 (EET) Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171960113.22738.35.camel@greebo> References: <1171818586.2708.41.camel@zelda.fubar.dk> <45D9CBEE.70402@gmail.com> <1171902844.23837.35.camel@greebo> <45D9D336.8050700@gmail.com> <1171904484.23837.44.camel@greebo> <1171960113.22738.35.camel@greebo> Message-ID: On Tue, 20 Feb 2007, Alexander Larsson wrote: > On Mon, 2007-02-19 at 20:33 +0200, Panu Matilainen wrote: >> >> That, and some specific things are simply better left untranslated: In >> Windows, "Administrator" the user account name has been translated to >> "J?rjestelm?yll?pit?j?" (or something resembling that). Try typing >> that in a hurry, and with a little bit of luck with a non-finnish >> keyboard layout > > I feel for you. :) Thankfully not really my headache, unless somebody suggests we start translating "root" account name :) That's not the first translation-hall-or-horror by MS, even worse was somewhere around Excel 3.0 when somebody had this brilliant idea of translating macro names as well (can't remember if they translated all of the language but at least the macros). Thankfully wasn't my headache either :) - Panu - From alexl at redhat.com Tue Feb 20 16:45:20 2007 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 20 Feb 2007 17:45:20 +0100 Subject: homedir subdirectories, counter-proposal In-Reply-To: <1171818586.2708.41.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> Message-ID: <1171989920.22738.70.camel@greebo> On Sun, 2007-02-18 at 12:09 -0500, David Zeuthen wrote: > Hi, > > Given the F7 schedule was pushed back one month I thought perhaps we > could spend this time on polishing stuff. > > It looks like gnome-screensaver already drops a directory Pictures > in /etc/skel/Pictures [1] to ensure that the user gets the directory > ~/Pictures. Personally, I'm a big fan of having pre-made directories in > a new users home directory. Mostly because it allows us to patch our > applications so they open the file chooser in the right directory. > > I think we ought to do more of this. I also think we ought to formalize > a bit. Ok. Here is a counter-proposal for translations-on-disk: http://www.gnome.org/~alexl/xdg-user-dirs-0.0.1.tar.gz Here is how it works: Somewhere (early) in the login scripts we run xdg-user-dirs-update. It reads a config file in /etc/xdg/user-dirs.conf, and a list of defaults for user dirs in /etc/xdg/user-dirs.defaults (by default, it also respects the xdg basedir spec if you want to tweak it). It also loads the current user dir configuration in ~/.config/user-dirs.dirs, if it exists. For each default specified dir type (DESKTOP, TEMPLATES, etc) that is not already in the user config the directory-name is decided based on the default config and translations in gettext. This directory is created and the user config is updated to point to it. Some old directories (like ~/Desktop) are special cased such that a translated version of them are not created if the old one exists already. This gives some backwards compatibility. If a user-configured directory doesn't exist anymore (the user deleted it) we don't recreate it, instead we change the settings to point it to $HOME. There is also a --force flag that ignores any existing settings and just creates and sets up localized dirs. The user config files for the dirs is in a form that allows shell scripts to do: source ~/.config/user-dirs.dirs echo $XDG_DOWNLOAD_DIR Included in the source is a ANSI-C version of xdg_user_dir_lookup() that is just one function and calls only libc functions. Its easy to cut and paste into any application if we need to patch them. For real desktop integration the idea is that the desktops themselves would add support for this in their platform libraries. Here is how the current default config files look, as an example: /etc/xdg/user-dirs.conf: ----- enabled=True ---- /etc/xdg/user-dirs.defaults: ----- # Default settings for user directories # # The values are relative pathnames from the home directory and # will be translated on a per-path-element basis into the users locale DESKTOP=Desktop DOWNLOAD=Download TEMPLATES=Templates PUBLICSHARE=Public DOCUMENTS=Documents MUSIC=Music PHOTOS=Photos # Another alternative is: #MUSIC=Documents/Music #PHOTOS=Documents/Photos ----- And here is a typical ~/.config/user-dirs.dir ----- # This file is written by xdg-user-dirs-update # If you want to change or add directories, just edit the line your interested in # All local changes will be retained on the next run # Format is XDG_xxx_DIR="$HOME/yyy", where yyy is shell-escaped. No other format supported. # XDG_DESKTOP_DIR="$HOME/Desktop" XDG_DOWNLOAD_DIR="$HOME/Nerladdat" XDG_TEMPLATES_DIR="$HOME/Templates" XDG_PUBLICSHARE_DIR="$HOME/Public" XDG_DOCUMENTS_DIR="$HOME/Dokument" XDG_MUSIC_DIR="$HOME/Musik" XDG_PHOTOS_DIR="$HOME/Foton" ----- Opinons? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an ungodly pirate boxer looking for a cure to the poison coursing through his veins. She's a man-hating hypochondriac barmaid from a family of eight older brothers. They fight crime! From notting at redhat.com Tue Feb 20 22:38:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Feb 2007 17:38:31 -0500 Subject: tweaking the LiveCD Message-ID: <20070220223831.GA32321@nostromo.devel.redhat.com> So, I compared the LiveCD manifest against the Desktop (from Test1) manifest. Here's a list of things we should consider for the live - obviously, most of this won't fit (not sure if *any* of it will), but we should at least think about it and make decisions. Sorted into somewhat random categories: I18N ---- aspell-* m17n-db-* scim-qtimm scim-tables-chinese Games ----- atomix celestia crack-attack enigma foobillard gweled lmarbles monkey-bubble neverball Stupid CLI but useful --------------------- attr bind-utils Potentially broken without -------------------------- crontabs termcap gnome-screensaver pcmciautils Things we want/need to install (even if they aren't running 'live') ------------------------------ logrotate mdadm smolt nfs-utils readahead rhgb A11Y ---- gok Is dialup dead? --------------- ppp rp-pppoe wvdial Desktop things that might be useful ----------------------------------- beagle-evolution beagle-gui bitmap-fonts bug-buddy deskbar-applet glabels gnome-audio gnome-backgrounds gnome-blog gnome-keyring-manager gnome-nettool gnome-pilot-conduits gnome-system-monitor gnome-user-docs gnome-user-share gobby hpijs hplip nautilus-sendto nautilus-sendto-bluetooth samba-client sane-backends sane-frontends transmission We need to decide ----------------- livecd has xchat desktop has xchat-gnome Bill From notting at redhat.com Tue Feb 20 22:50:05 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Feb 2007 17:50:05 -0500 Subject: pruning the liveCD Message-ID: <20070220225005.GB32321@nostromo.devel.redhat.com> Along with looking at things to add, we probably want to look at things to remove. So, some suggestions: - emacs (!) - one of gimp/inkscape? Unfortunately, the best way to clear out space that I can see is switch to latin, indic, and cjk liveCDs. Which... yuk. Bill From david at fubar.dk Tue Feb 20 23:07:05 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 20 Feb 2007 18:07:05 -0500 Subject: tweaking the LiveCD In-Reply-To: <20070220223831.GA32321@nostromo.devel.redhat.com> References: <20070220223831.GA32321@nostromo.devel.redhat.com> Message-ID: <1172012825.21650.15.camel@zelda.fubar.dk> On Tue, 2007-02-20 at 17:38 -0500, Bill Nottingham wrote: > gnome-screensaver At least gnome-screensaver is needed - FC7t1 shipped without... so installs from that never locked the screen. > A11Y > ---- > gok orca too, probably even more important (not sure whether it was removed for FC7t1 cuz it drags in festival which is huge). Another point is that we need to work making a11y easy to enable for live cd. My plan at this point includes making the live cd boot into an accessible gdm with a face browser (we're probably going to enable face browser by default btw - for f-u-s). Then a11y / language / keyboard can be configured / enabled there. So starting the live cd would amount to clicking the fedora-livecd face (potentially we'd do readahead while waiting for the user) Needs some thought and experimentation, but I think this is doable. > livecd has xchat > desktop has xchat-gnome Stick with gaim? Again, a space issue... David From notting at redhat.com Tue Feb 20 23:06:14 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Feb 2007 18:06:14 -0500 Subject: tweaking the LiveCD In-Reply-To: <1172012825.21650.15.camel@zelda.fubar.dk> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <1172012825.21650.15.camel@zelda.fubar.dk> Message-ID: <20070220230614.GC32321@nostromo.devel.redhat.com> David Zeuthen (david at fubar.dk) said: > orca too, probably even more important (not sure whether it was removed > for FC7t1 cuz it drags in festival which is huge). Another point is that > we need to work making a11y easy to enable for live cd. orca's already there. > > livecd has xchat > > desktop has xchat-gnome > > Stick with gaim? Again, a space issue... It's certainly an option. Bill From david at fubar.dk Tue Feb 20 23:12:06 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 20 Feb 2007 18:12:06 -0500 Subject: pruning the liveCD In-Reply-To: <20070220225005.GB32321@nostromo.devel.redhat.com> References: <20070220225005.GB32321@nostromo.devel.redhat.com> Message-ID: <1172013126.21650.21.camel@zelda.fubar.dk> On Tue, 2007-02-20 at 17:50 -0500, Bill Nottingham wrote: > Along with looking at things to add, we probably want to look > at things to remove. So, some suggestions: > > - emacs (!) Yea, sorry about that... > - one of gimp/inkscape? Or neither? Space permitting... > Unfortunately, the best way to clear out space that I can see > is switch to latin, indic, and cjk liveCDs. Which... yuk. Yes, but we're most probably going to do this sooner or later anyway so might as well do it now? The savings are substantial IIRC and as a data point Mandriva is doing this already with Mandriva One. The hard part is deciding what regions to target; you have to take into account - translations - input methods - fonts (though I'm firmly in the camp that even a US english install needs to have good enough font coverage to such that e.g. http://www.yahoo.co.jp/index.html isn't a Pango-block fest) - other things I can't remember right now and do the cut such that the free space is split evenly. It's just a really hard problem. David From katzj at redhat.com Tue Feb 20 23:16:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Feb 2007 18:16:35 -0500 Subject: tweaking the LiveCD In-Reply-To: <1172012825.21650.15.camel@zelda.fubar.dk> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <1172012825.21650.15.camel@zelda.fubar.dk> Message-ID: <1172013395.3834.17.camel@aglarond.local> On Tue, 2007-02-20 at 18:07 -0500, David Zeuthen wrote: > On Tue, 2007-02-20 at 17:38 -0500, Bill Nottingham wrote: > > gnome-screensaver > > At least gnome-screensaver is needed - FC7t1 shipped without... so > installs from that never locked the screen. Yeah, I had to drop the extra xscreensaver screensavers and they were the only thing pulling in gnome-screensaver... this is why I really think that we need/want to move to the same type of manifest format as pungi where we reference things based on comps groups. In my queue for real soon; now that the yum depsolving stuff is out of the way, I'm getting back to livecd with a bit of a vengeance. > > A11Y > > ---- > > gok > > orca too, probably even more important (not sure whether it was removed > for FC7t1 cuz it drags in festival which is huge). Yeah, the space requirement of festival makes it (and the things which depend on it, including gok) a lot less attractive. :-/ Not sure what to do on that front > > livecd has xchat > > desktop has xchat-gnome > > Stick with gaim? Again, a space issue... Seems like a sane enough compromise Jeremy From davidz at redhat.com Tue Feb 20 23:23:29 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 20 Feb 2007 18:23:29 -0500 Subject: tweaking the LiveCD In-Reply-To: <1172013395.3834.17.camel@aglarond.local> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <1172012825.21650.15.camel@zelda.fubar.dk> <1172013395.3834.17.camel@aglarond.local> Message-ID: <1172013809.21650.25.camel@zelda.fubar.dk> On Tue, 2007-02-20 at 18:16 -0500, Jeremy Katz wrote: > > orca too, probably even more important (not sure whether it was removed > > for FC7t1 cuz it drags in festival which is huge). > > Yeah, the space requirement of festival makes it (and the things which > depend on it, including gok) a lot less attractive. :-/ Not sure what > to do on that front Right. It feels like selling out willfully not making the live cd usable for users that needs accessibility. So it's not really an option to leave this out I think... plus section 508 is about to be refreshed etc. David From katzj at redhat.com Tue Feb 20 23:31:49 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Feb 2007 18:31:49 -0500 Subject: tweaking the LiveCD In-Reply-To: <1172013809.21650.25.camel@zelda.fubar.dk> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <1172012825.21650.15.camel@zelda.fubar.dk> <1172013395.3834.17.camel@aglarond.local> <1172013809.21650.25.camel@zelda.fubar.dk> Message-ID: <1172014309.3834.21.camel@aglarond.local> On Tue, 2007-02-20 at 18:23 -0500, David Zeuthen wrote: > On Tue, 2007-02-20 at 18:16 -0500, Jeremy Katz wrote: > > > orca too, probably even more important (not sure whether it was removed > > > for FC7t1 cuz it drags in festival which is huge). > > > > Yeah, the space requirement of festival makes it (and the things which > > depend on it, including gok) a lot less attractive. :-/ Not sure what > > to do on that front > > Right. It feels like selling out willfully not making the live cd usable > for users that needs accessibility. So it's not really an option to > leave this out I think... plus section 508 is about to be refreshed etc. The question is how can we do it while minimizing the space requirements. Are there changes we can make to festival so that it isn't humongous? Can we split the package up so that we only require a base set of stuff? Jeremy From stevelist at silverorange.com Wed Feb 21 00:25:36 2007 From: stevelist at silverorange.com (Steven Garrity) Date: Tue, 20 Feb 2007 20:25:36 -0400 Subject: pruning the liveCD In-Reply-To: <20070220225005.GB32321@nostromo.devel.redhat.com> References: <20070220225005.GB32321@nostromo.devel.redhat.com> Message-ID: <45DB9180.90601@silverorange.com> Bill Nottingham wrote: > Along with looking at things to add, we probably want to look > at things to remove. So, some suggestions: > - one of gimp/inkscape? Gimp and Inkscape are actually quite complimentary, one being a vector illustrating application (Inkscape) and the other a raster/photo-editor (gimp). That said, I think a LiveCD could do without either of them - though I suppose that really depends on what the purpose of the LiveCDs are. For what it's worth, as someone who uses both Gimp and Inkscape everyday, I wouldn't be surprised to see both/either missing from a LiveCD. Cheers, Steven Garrity From davidz at redhat.com Wed Feb 21 00:31:48 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 20 Feb 2007 19:31:48 -0500 Subject: tweaking the LiveCD In-Reply-To: <1172014309.3834.21.camel@aglarond.local> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <1172012825.21650.15.camel@zelda.fubar.dk> <1172013395.3834.17.camel@aglarond.local> <1172013809.21650.25.camel@zelda.fubar.dk> <1172014309.3834.21.camel@aglarond.local> Message-ID: <1172017908.21650.36.camel@zelda.fubar.dk> On Tue, 2007-02-20 at 18:31 -0500, Jeremy Katz wrote: > The question is how can we do it while minimizing the space > requirements. Are there changes we can make to festival so that it > isn't humongous? Can we split the package up so that we only require a > base set of stuff? Well, this is something we ought to do for all of our packages on a continual basis - something, btw, I spent time on when I was working on OLPC (*cough* the X server pulling in perl?!? *cough*). Anyway, I'll look at the a11y stuff but probably won't have time until after T2 is out... David From katzj at redhat.com Wed Feb 21 00:41:37 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Feb 2007 19:41:37 -0500 Subject: pruning the liveCD In-Reply-To: <1172013126.21650.21.camel@zelda.fubar.dk> References: <20070220225005.GB32321@nostromo.devel.redhat.com> <1172013126.21650.21.camel@zelda.fubar.dk> Message-ID: <1172018497.14119.11.camel@aglarond.local> On Tue, 2007-02-20 at 18:12 -0500, David Zeuthen wrote: > On Tue, 2007-02-20 at 17:50 -0500, Bill Nottingham wrote: > > Unfortunately, the best way to clear out space that I can see > > is switch to latin, indic, and cjk liveCDs. Which... yuk. > > Yes, but we're most probably going to do this sooner or later anyway so > might as well do it now? The savings are substantial IIRC and as a data > point Mandriva is doing this already with Mandriva One. The cost is somewaht substantial too, though. Instead of one live CD to spin and test, you now have n. You also have n*700 megs worth of ISOs for mirrors to carry. > The hard part is deciding what regions to target; you have to take into > account > - translations > - input methods > - fonts (though I'm firmly in the camp that even a US english install > needs to have good enough font coverage to such that e.g. > http://www.yahoo.co.jp/index.html isn't a Pango-block fest) > - other things I can't remember right now FWIW, fonts are about 135 megs currently while translations are between 4 and 8 megs a language for a total of 32 megs. The other big kicker space-wise for language support (that we're not currently doing) is dictionaries. Have I mentioned that the space constraints of CDs are bothersome yet? ;-) The questions really just come down to which compromises we want to make. Well, that or we need to come up with magically better compression :) Jeremy From davidz at redhat.com Wed Feb 21 00:59:38 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 20 Feb 2007 19:59:38 -0500 Subject: pruning the liveCD In-Reply-To: <1172018497.14119.11.camel@aglarond.local> References: <20070220225005.GB32321@nostromo.devel.redhat.com> <1172013126.21650.21.camel@zelda.fubar.dk> <1172018497.14119.11.camel@aglarond.local> Message-ID: <1172019578.21650.39.camel@zelda.fubar.dk> On Tue, 2007-02-20 at 19:41 -0500, Jeremy Katz wrote: > FWIW, fonts are about 135 megs currently while translations are between > 4 and 8 megs a language for a total of 32 megs. I believe this is uncompressed size yes? The compression is around a factor of 1 to 3 so a CD can hold around 2GB uncompressed stuff. > The questions really just come down to which compromises we want to > make. Well, that or we need to come up with magically better > compression :) Yeah. David From mattdm at mattdm.org Wed Feb 21 03:10:03 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Feb 2007 22:10:03 -0500 Subject: tweaking the LiveCD In-Reply-To: <20070220223831.GA32321@nostromo.devel.redhat.com> References: <20070220223831.GA32321@nostromo.devel.redhat.com> Message-ID: <20070221031003.GA1421@jadzia.bu.edu> On Tue, Feb 20, 2007 at 05:38:31PM -0500, Bill Nottingham wrote: > Stupid CLI but useful > --------------------- [...] > bind-utils Can we split this out to *just* contain "host"? :) > Is dialup dead? > --------------- > ppp > rp-pppoe > wvdial rp-pppoe is for ADSL, not dialup. But I think the widespread use of cheap gateway router boxes has made this less of an issue. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Feb 21 03:43:47 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Feb 2007 22:43:47 -0500 Subject: tweaking the LiveCD In-Reply-To: <1172013395.3834.17.camel@aglarond.local> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <1172012825.21650.15.camel@zelda.fubar.dk> <1172013395.3834.17.camel@aglarond.local> Message-ID: <20070221034347.GB1421@jadzia.bu.edu> On Tue, Feb 20, 2007 at 06:16:35PM -0500, Jeremy Katz wrote: > > orca too, probably even more important (not sure whether it was removed > > for FC7t1 cuz it drags in festival which is huge). > Yeah, the space requirement of festival makes it (and the things which > depend on it, including gok) a lot less attractive. :-/ Not sure what > to do on that front Festival could by split up so some or all of the voices are in a subpackage. I'm not hugely versed in the technical details, but the CMU ARCTIC HTS voices sound great to me (better than the only free alternatives, the older and much larger kal_diphone and ked_diphone ones). We could probably get away with just including the CMU ARCTIC SLT voice (female US English speaker), which is the smallest at 1756k. That alone would save us half the size of the package. Plus, the speech-tools binaries (in libexec) probably aren't needed by almost everyone. And that's pretty significant. *And*, there's some stuff packaged up under /usr/share/festival/dicts that I think maybe doesn't need to be. For example, there's a 118K *patch* in there, plus the 3.6M file that's getting patched. (cmudict-0.4.diff and cmudict-0.4.scm). I assume that's done to fulfill the "Any modifications must be clearly marked as such" clause in the license for the data files in that directory -- probably that could be done in a somewhat smaller way. Oh, and some stuff in /usr/share/festival/etc which is "etc" in the "misc et cetera crap" sense, not the "config files" sense. So, doing all of that would bring the package down to 16M from 54M (on x86_64). Someone who knew the package better and/or had more than a minimal working knowledge of Lisp could probably pare down and/or subpackage non-core functionality even further -- I bet the minimal-but-useful set is under 10M. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jrb at redhat.com Wed Feb 21 04:01:20 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Tue, 20 Feb 2007 23:01:20 -0500 Subject: pruning the liveCD In-Reply-To: <45DB9180.90601@silverorange.com> References: <20070220225005.GB32321@nostromo.devel.redhat.com> <45DB9180.90601@silverorange.com> Message-ID: <1172030480.3191.57.camel@localhost.localdomain> On Tue, 2007-02-20 at 20:25 -0400, Steven Garrity wrote: > Gimp and Inkscape are actually quite complimentary, one being a vector > illustrating application (Inkscape) and the other a raster/photo-editor > (gimp). That said, I think a LiveCD could do without either of them - > though I suppose that really depends on what the purpose of the LiveCDs are. > > For what it's worth, as someone who uses both Gimp and Inkscape > everyday, I wouldn't be surprised to see both/either missing from a LiveCD. I thought the point of the LiveCDs was to help evangelize Linux in general, and Fedora in particular. Given that, it seems like inkscape and the gimp are pretty good choices to put on the LiveCD. Thanks, -Jonathan From mattdm at mattdm.org Wed Feb 21 04:05:06 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Feb 2007 23:05:06 -0500 Subject: tweaking the LiveCD In-Reply-To: <20070221034347.GB1421@jadzia.bu.edu> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <1172012825.21650.15.camel@zelda.fubar.dk> <1172013395.3834.17.camel@aglarond.local> <20070221034347.GB1421@jadzia.bu.edu> Message-ID: <20070221040506.GA5371@jadzia.bu.edu> On Tue, Feb 20, 2007 at 10:43:47PM -0500, Matthew Miller wrote: > On Tue, Feb 20, 2007 at 06:16:35PM -0500, Jeremy Katz wrote: > > > orca too, probably even more important (not sure whether it was removed > > > for FC7t1 cuz it drags in festival which is huge). > > Yeah, the space requirement of festival makes it (and the things which > > depend on it, including gok) a lot less attractive. :-/ Not sure what > > to do on that front > > Festival could by split up so some or all of the voices are in a subpackage. Filed all this as bug #229442. Because it's a good idea livecd or no. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Wed Feb 21 04:07:08 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Feb 2007 23:07:08 -0500 Subject: pruning the liveCD In-Reply-To: <1172019578.21650.39.camel@zelda.fubar.dk> References: <20070220225005.GB32321@nostromo.devel.redhat.com> <1172013126.21650.21.camel@zelda.fubar.dk> <1172018497.14119.11.camel@aglarond.local> <1172019578.21650.39.camel@zelda.fubar.dk> Message-ID: <20070221040708.GA5031@nostromo.devel.redhat.com> David Zeuthen (davidz at redhat.com) said: > > The questions really just come down to which compromises we want to > > make. Well, that or we need to come up with magically better > > compression :) > > Yeah. This brings up one of my nagging concerns though - one of our main points is that we're trying to do a single usable Live CD. As the guy who used to do the Publishers Edition[1]... this is a losing game. We're always going to get more languages. Code tends to always get bigger. We're always going to get *more* functionality we'd like to include, not less. So, the usefulness of the LiveCD is actually going to *decrease* over time. Considering it's a large part of our F7 (and presumably future) plans, that worries me. Bill [1] In the days before LiveCDs, there was the Red Hat Linux 'Publisher's Edition' - a single installable CD that would contain a desktop, standard apps, and basic servers. Due to a) size constraints b) a lack of useful rel-eng tools, it was a pain in the ass to build From mattdm at mattdm.org Wed Feb 21 04:17:33 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Feb 2007 23:17:33 -0500 Subject: pruning the liveCD In-Reply-To: <20070221040708.GA5031@nostromo.devel.redhat.com> References: <20070220225005.GB32321@nostromo.devel.redhat.com> <1172013126.21650.21.camel@zelda.fubar.dk> <1172018497.14119.11.camel@aglarond.local> <1172019578.21650.39.camel@zelda.fubar.dk> <20070221040708.GA5031@nostromo.devel.redhat.com> Message-ID: <20070221041733.GA6464@jadzia.bu.edu> On Tue, Feb 20, 2007 at 11:07:08PM -0500, Bill Nottingham wrote: > As the guy who used to do the Publishers Edition[1]... this is > a losing game. We're always going to get more languages. Code > tends to always get bigger. We're always going to get *more* > functionality we'd like to include, not less. So, the usefulness > of the LiveCD is actually going to *decrease* over time. One consideration is where in time that decreasing future line intersects with the rising prevalence of DVD drives and the increasing capacity of cheap USB media. > Considering it's a large part of our F7 (and presumably future) > plans, that worries me. Hence, moving away from the one-size-fits-all LiveCD and towards "it's easy to spin a LiveCD containing whatever you want" -- as easy as selecting packages in pirut and hitting "burn". Then, the default live CD could concentrate on one basic use scenario like browsing the web. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davidz at redhat.com Wed Feb 21 05:02:18 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 21 Feb 2007 00:02:18 -0500 Subject: tweaking the LiveCD In-Reply-To: <20070220223831.GA32321@nostromo.devel.redhat.com> References: <20070220223831.GA32321@nostromo.devel.redhat.com> Message-ID: <1172034138.21650.112.camel@zelda.fubar.dk> On Tue, 2007-02-20 at 17:38 -0500, Bill Nottingham wrote: > Potentially broken without > -------------------------- > crontabs > termcap > gnome-screensaver > pcmciautils bug-buddy. Yes, this pulls in gdb ;-( David From jspaleta at gmail.com Wed Feb 21 21:41:30 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Feb 2007 12:41:30 -0900 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <1171828278.2708.72.camel@zelda.fubar.dk> References: <1171818586.2708.41.camel@zelda.fubar.dk> <1171828278.2708.72.camel@zelda.fubar.dk> Message-ID: <604aa7910702211341u1f177f38o65fd452b2edb0b6e@mail.gmail.com> On 2/18/07, David Zeuthen wrote: > What about having a co-maintained desktop-filesystem package with > desktop-filesystem-gnome and desktop-filesystem-kde sub packages? > (possibly other sub packages for e.g. xfce) Do we want to try to make a comprehensive list of potential gnome or kde centric directory locations that fit in such a desktop filesystem packaging scheme? for example, /usr/share/gnome-background-properties could easily fit in a desktop-filesystem-gnome package as well -jef From mclasen at redhat.com Fri Feb 23 13:45:34 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 23 Feb 2007 08:45:34 -0500 Subject: Polishing stuff - gnome-filesystem package In-Reply-To: <604aa7910702211341u1f177f38o65fd452b2edb0b6e@mail.gmail.com> References: <1171818586.2708.41.camel@zelda.fubar.dk> <1171828278.2708.72.camel@zelda.fubar.dk> <604aa7910702211341u1f177f38o65fd452b2edb0b6e@mail.gmail.com> Message-ID: <1172238334.3710.1.camel@localhost.localdomain> On Wed, 2007-02-21 at 12:41 -0900, Jeff Spaleta wrote: > On 2/18/07, David Zeuthen wrote: > > What about having a co-maintained desktop-filesystem package with > > desktop-filesystem-gnome and desktop-filesystem-kde sub packages? > > (possibly other sub packages for e.g. xfce) > > Do we want to try to make a comprehensive list of potential gnome or > kde centric directory locations that fit in such a desktop filesystem > packaging scheme? > > for example, > /usr/share/gnome-background-properties > could easily fit in a desktop-filesystem-gnome package as well > Another example I stumbled over is /usr/share/icons, which is currently owned by multiple packages. Even though /usr/share/pixmaps is already in the filesystem package, it is owned by several packages, too... From nphilipp at redhat.com Fri Feb 23 14:01:38 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 23 Feb 2007 15:01:38 +0100 Subject: homedir subdirectories, counter-proposal In-Reply-To: <1171989920.22738.70.camel@greebo> References: <1171818586.2708.41.camel@zelda.fubar.dk> <1171989920.22738.70.camel@greebo> Message-ID: <1172239298.17211.1.camel@gibraltar.stuttgart.redhat.com> On Tue, 2007-02-20 at 17:45 +0100, Alexander Larsson wrote: > Ok. Here is a counter-proposal for translations-on-disk: > http://www.gnome.org/~alexl/xdg-user-dirs-0.0.1.tar.gz > > Here is how it works: > Somewhere (early) in the login scripts we run xdg-user-dirs-update. It > reads a config file in /etc/xdg/user-dirs.conf, and a list of defaults > for user dirs in /etc/xdg/user-dirs.defaults (by default, it also > respects the xdg basedir spec if you want to tweak it). It also loads > the current user dir configuration in ~/.config/user-dirs.dirs, if it > exists. One thing I've never quite understood is why there is ~/.config AND gconf. Both seem to do the same/similar things to me. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Fri Feb 23 14:06:47 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 23 Feb 2007 15:06:47 +0100 Subject: tweaking the LiveCD In-Reply-To: <20070221031003.GA1421@jadzia.bu.edu> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <20070221031003.GA1421@jadzia.bu.edu> Message-ID: <1172239607.17211.5.camel@gibraltar.stuttgart.redhat.com> On Tue, 2007-02-20 at 22:10 -0500, Matthew Miller wrote: > On Tue, Feb 20, 2007 at 05:38:31PM -0500, Bill Nottingham wrote: > > Stupid CLI but useful > > --------------------- > [...] > > bind-utils > > Can we split this out to *just* contain "host"? :) > > > Is dialup dead? > > --------------- > > ppp > > rp-pppoe > > wvdial > > rp-pppoe is for ADSL, not dialup. But I think the widespread use of cheap gateway > router boxes has made this less of an issue. I guess it's a good thing to think of "dialup" as containing ADSL as well (connecting to the Internet is what matters to users). For me, any OS where I can't go online doesn't cut it. And yes, I have a WLAN router box, but no I don't use it as such ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From alexl at redhat.com Fri Feb 23 16:02:51 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 23 Feb 2007 17:02:51 +0100 Subject: homedir subdirectories, counter-proposal In-Reply-To: <1172239298.17211.1.camel@gibraltar.stuttgart.redhat.com> References: <1171818586.2708.41.camel@zelda.fubar.dk> <1171989920.22738.70.camel@greebo> <1172239298.17211.1.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1172246571.17307.249.camel@greebo> On Fri, 2007-02-23 at 15:01 +0100, Nils Philippsen wrote: > On Tue, 2007-02-20 at 17:45 +0100, Alexander Larsson wrote: > > > Ok. Here is a counter-proposal for translations-on-disk: > > http://www.gnome.org/~alexl/xdg-user-dirs-0.0.1.tar.gz > > > > Here is how it works: > > Somewhere (early) in the login scripts we run xdg-user-dirs-update. It > > reads a config file in /etc/xdg/user-dirs.conf, and a list of defaults > > for user dirs in /etc/xdg/user-dirs.defaults (by default, it also > > respects the xdg basedir spec if you want to tweak it). It also loads > > the current user dir configuration in ~/.config/user-dirs.dirs, if it > > exists. > > One thing I've never quite understood is why there is ~/.config AND > gconf. Both seem to do the same/similar things to me. gconf is a gnome-specific system for storing preferences. ~/.config is a standard (http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html) for avoiding putting a shitload of dot-files directly in $HOME. There are various reasons not to use gconf here. a) its gnome specific b) it requires a daemon to run c) gconf data might be stored on ldap or something like that, we'd like to match the config strongly with the homedir itself =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an otherworldly ninja cyborg gone bad. She's a cosmopolitan blonde mermaid prone to fits of savage, blood-crazed rage. They fight crime! From mattdm at mattdm.org Fri Feb 23 17:35:30 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Feb 2007 12:35:30 -0500 Subject: tweaking the LiveCD In-Reply-To: <1172239607.17211.5.camel@gibraltar.stuttgart.redhat.com> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <20070221031003.GA1421@jadzia.bu.edu> <1172239607.17211.5.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20070223173530.GA7427@jadzia.bu.edu> On Fri, Feb 23, 2007 at 03:06:47PM +0100, Nils Philippsen wrote: > I guess it's a good thing to think of "dialup" as containing ADSL as > well (connecting to the Internet is what matters to users). For me, any > OS where I can't go online doesn't cut it. And yes, I have a WLAN router > box, but no I don't use it as such ;-). Does your ISP require pppoe? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rdieter at math.unl.edu Fri Feb 23 17:39:01 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 23 Feb 2007 11:39:01 -0600 Subject: Polishing stuff - gnome-filesystem package References: <1171818586.2708.41.camel@zelda.fubar.dk> <1171828278.2708.72.camel@zelda.fubar.dk> <604aa7910702211341u1f177f38o65fd452b2edb0b6e@mail.gmail.com> <1172238334.3710.1.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > Another example I stumbled over is /usr/share/icons, which is currently > owned by multiple packages. Even though /usr/share/pixmaps is already > in the filesystem package, it is owned by several packages, too... I've already filed a bug against 'filesystem' to own /usr/share/icons, others shouldn't be touching that one. should be fixed soon. -- Rex From notting at redhat.com Fri Feb 23 18:46:57 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Feb 2007 13:46:57 -0500 Subject: patch, manifest changes Message-ID: <20070223184657.GA23983@nostromo.devel.redhat.com> I've been playing to see how much more we can fit on the live CD for test 2. First, I eliminated docs from the livecd with a patch to livecd-creator (attached). Then, I started adding and removing things. Based on Jeremy's test1 configs at http://people.redhat.com/katzj/f7live/, I made the following changes: Added ----- attr bind-utils gnome-screensaver pcmciautils termcap crontabs ppp rp-pppoe wvdial logrotate mdadm smolt nfs-utils readahead rhgb gok gnome-backgrounds gnome-audio nautilus-sendto nautilus-sendto-bluetooth monkey-bubble gnome-blog Removed ------- emacs xchat-gnome This yields a 678MB Live CD, so we've still got a decent amount of room for changes. (SRPM for fedora-livecd attached) Bill -------------- next part -------------- --- creator/livecd-creator 2007-02-23 11:11:05.002439000 -0500 +++ /usr/bin/livecd-creator 2007-02-23 11:42:10.000000000 -0500 @@ -314,6 +314,7 @@ yumconf.write("retries=20\n") yumconf.write("obsoletes=1\n") yumconf.write("gpgcheck=0\n") + yumconf.write("tsflags=nodocs\n") yumconf.write("\n") yumconf.close() -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-livecd-6.90-1.src.rpm Type: application/x-rpm Size: 5761 bytes Desc: not available URL: From katzj at redhat.com Fri Feb 23 19:43:07 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 23 Feb 2007 14:43:07 -0500 Subject: [Fedora-livecd-list] patch, manifest changes In-Reply-To: <20070223184657.GA23983@nostromo.devel.redhat.com> References: <20070223184657.GA23983@nostromo.devel.redhat.com> Message-ID: <1172259787.3646.22.camel@aglarond.local> On Fri, 2007-02-23 at 13:46 -0500, Bill Nottingham wrote: > I've been playing to see how much more we can fit on the live > CD for test 2. Always the fun part (or not) > First, I eliminated docs from the livecd with a patch to > livecd-creator (attached). Hmm... I'm not sure if we really want to do this unconditionally. And given that we later can install from the live CD, is removing the docs something we really want to do? > Then, I started adding and removing things. Based on Jeremy's > test1 configs at http://people.redhat.com/katzj/f7live/, I > made the following changes: Those bits are now at http://people.redhat.com/katzj/live/f7test1/ but a symlink points there. I've put up what I've used for a proto-test2 live CD at http://people.redhat.com/katzj/live/f7test2pre (and I'll try and keep that current) > Added > ----- > attr > bind-utils > gnome-screensaver > pcmciautils > termcap > crontabs > ppp > rp-pppoe > wvdial > logrotate > mdadm > smolt > nfs-utils > readahead These are all in my list > rhgb Not added because it's incredibly painful for a live CD right now... and I keep hoping that we're going to get to kill rhgb before F7. Although the chances of that seem to be dwindling :( > gok > gnome-backgrounds > gnome-audio > nautilus-sendto > nautilus-sendto-bluetooth > monkey-bubble > gnome-blog Didn't add any of these and I'm at ~ 15 megs to spare. So some could be, but probably not all of them without the --nodocs bits > Removed > ------- > emacs > xchat-gnome I took out xchat-gnome, emacs is still there. It's probably worth killing for some subset of the above too. Jeremy From mclasen at redhat.com Fri Feb 23 19:54:16 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 23 Feb 2007 14:54:16 -0500 Subject: [Fedora-livecd-list] patch, manifest changes In-Reply-To: <1172259787.3646.22.camel@aglarond.local> References: <20070223184657.GA23983@nostromo.devel.redhat.com> <1172259787.3646.22.camel@aglarond.local> Message-ID: <1172260456.3710.13.camel@localhost.localdomain> It would be nicer if we could find somebody to cut down some overgrown packages, e.g. perform voicectomy on festival From notting at redhat.com Fri Feb 23 19:57:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Feb 2007 14:57:07 -0500 Subject: [Fedora-livecd-list] patch, manifest changes In-Reply-To: <1172259787.3646.22.camel@aglarond.local> References: <20070223184657.GA23983@nostromo.devel.redhat.com> <1172259787.3646.22.camel@aglarond.local> Message-ID: <20070223195707.GA3646@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > > First, I eliminated docs from the livecd with a patch to > > livecd-creator (attached). > > Hmm... I'm not sure if we really want to do this unconditionally. And > given that we later can install from the live CD, is removing the docs > something we really want to do? It's stuff in /usr/share/doc and info pages. Are either of those appropriate for a *Desktop* livecd? > Those bits are now at http://people.redhat.com/katzj/live/f7test1/ but a > symlink points there. I've put up what I've used for a proto-test2 live > CD at http://people.redhat.com/katzj/live/f7test2pre (and I'll try and > keep that current) OK, will look at what I have and rediff. > > gok > > gnome-backgrounds > > gnome-audio > > nautilus-sendto > > nautilus-sendto-bluetooth > > monkey-bubble > > gnome-blog > > Didn't add any of these and I'm at ~ 15 megs to spare. So some could > be, but probably not all of them without the --nodocs bits So, somehow this spin is now averaging between 706MB and 714MB on my trials - it *shouldn't* be that big. Will do more investigating. Bill From notting at redhat.com Fri Feb 23 20:47:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Feb 2007 15:47:03 -0500 Subject: [Fedora-livecd-list] patch, manifest changes In-Reply-To: <20070223195707.GA3646@nostromo.devel.redhat.com> References: <20070223184657.GA23983@nostromo.devel.redhat.com> <1172259787.3646.22.camel@aglarond.local> <20070223195707.GA3646@nostromo.devel.redhat.com> Message-ID: <20070223204703.GA4385@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > > Didn't add any of these and I'm at ~ 15 megs to spare. So some could > > be, but probably not all of them without the --nodocs bits > > So, somehow this spin is now averaging between 706MB and 714MB > on my trials - it *shouldn't* be that big. Will do more investigating. This is because of gok -> gnome-speech -> festival. I built with the attached diff, and got 681MB, so we've still got some wiggle room. Bill -------------- next part -------------- diff --git a/10-fedora-livecd-base.conf b/10-fedora-livecd-base.conf diff --git a/20-fedora-livecd-gnome.conf b/20-fedora-livecd-gnome.conf index 71abd58..4d54924 100755 --- a/20-fedora-livecd-gnome.conf +++ b/20-fedora-livecd-gnome.conf @@ -46,7 +46,6 @@ totem-mozplugin gnome-session system-config-display vim-minimal -emacs gnome-applets compiz gucharmap @@ -68,7 +67,10 @@ system-config-printer yum-updatesd alsa-utils gnome-screensaver - +gnome-backgrounds +gnome-audio +nautilus-sendto +nautilus-sendto-bluetooth dejavu-lgc-fonts " ;; diff --git a/30-fedora-livecd-desktop.conf b/30-fedora-livecd-desktop.conf index ee686a8..ed76fd4 100755 --- a/30-fedora-livecd-desktop.conf +++ b/30-fedora-livecd-desktop.conf @@ -21,6 +21,7 @@ case $1 in # inquire what packages to install; prints package list on stdout pkgadd) echo " +bug-buddy evolution evolution-connector evolution-webcal @@ -33,6 +34,8 @@ inkscape rhythmbox abiword gnumeric +monkey-bubble +gnome-blog scim scim-libs From laroche at redhat.com Sat Feb 24 06:37:42 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 24 Feb 2007 07:37:42 +0100 Subject: pruning the liveCD In-Reply-To: <1172018497.14119.11.camel@aglarond.local> References: <20070220225005.GB32321@nostromo.devel.redhat.com> <1172013126.21650.21.camel@zelda.fubar.dk> <1172018497.14119.11.camel@aglarond.local> Message-ID: <20070224063742.GA26655@dudweiler.stuttgart.redhat.com> > Have I mentioned that the space constraints of CDs are bothersome > yet? ;-) Any reason not to start also DVD releases? regards, Florian La Roche From scott.walsh at snet.net Sun Feb 25 11:55:30 2007 From: scott.walsh at snet.net (skwalsh) Date: Sun, 25 Feb 2007 06:55:30 -0500 Subject: Sony Vaio AR320E Message-ID: <1172404530.3415.3.camel@scott.localdomain> Installed FC6 w/ all updates. The laptop has special function buttons S1, S2, Volume, and optical drive eject. Does FC6 support these? How do I set them up. If this is the wrong forum, the question becomes "Can you suggest one?" Scott From roguexz at gmail.com Sun Feb 25 12:07:04 2007 From: roguexz at gmail.com (Rogue) Date: Sun, 25 Feb 2007 17:37:04 +0530 Subject: Sony Vaio AR320E In-Reply-To: <1172404530.3415.3.camel@scott.localdomain> References: <1172404530.3415.3.camel@scott.localdomain> Message-ID: <45E17BE8.7010100@gmail.com> An HTML attachment was scrubbed... URL: From roguexz at gmail.com Sun Feb 25 14:29:46 2007 From: roguexz at gmail.com (Rogue) Date: Sun, 25 Feb 2007 19:59:46 +0530 Subject: Sony Vaio AR320E In-Reply-To: <1172412827.10071.4.camel@scott.localdomain> References: <1172404530.3415.3.camel@scott.localdomain> <45E17BE8.7010100@gmail.com> <1172412827.10071.4.camel@scott.localdomain> Message-ID: <45E19D5A.8090200@gmail.com> An HTML attachment was scrubbed... URL: From bnocera at redhat.com Sun Feb 25 16:13:22 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 25 Feb 2007 16:13:22 +0000 Subject: Sony Vaio AR320E In-Reply-To: <1172404530.3415.3.camel@scott.localdomain> References: <1172404530.3415.3.camel@scott.localdomain> Message-ID: <1172420002.31852.13.camel@cookie.hadess.net> On Sun, 2007-02-25 at 06:55 -0500, skwalsh wrote: > Installed FC6 w/ all updates. The laptop has special function buttons > S1, S2, Volume, and optical drive eject. Does FC6 support these? How do > I set them up. > If this is the wrong forum, the question becomes "Can you suggest one?" Not sure how new this machine is, but if it works with sonypi, sonypi should be loaded automatically on this machine (in the latest udev update). As Rogue mentioned, if sonypi is loaded, you should be able to use those keys under X. Note that on my machine (a 3 year old S1XP), S1 and S2 give the same keycode, so you can't differentiate them. Cheers From nphilipp at redhat.com Sun Feb 25 16:31:35 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Sun, 25 Feb 2007 17:31:35 +0100 Subject: tweaking the LiveCD In-Reply-To: <20070223173530.GA7427@jadzia.bu.edu> References: <20070220223831.GA32321@nostromo.devel.redhat.com> <20070221031003.GA1421@jadzia.bu.edu> <1172239607.17211.5.camel@gibraltar.stuttgart.redhat.com> <20070223173530.GA7427@jadzia.bu.edu> Message-ID: <1172421095.30398.6.camel@wombat.tiptoe.de> On Fri, 2007-02-23 at 12:35 -0500, Matthew Miller wrote: > On Fri, Feb 23, 2007 at 03:06:47PM +0100, Nils Philippsen wrote: > > I guess it's a good thing to think of "dialup" as containing ADSL as > > well (connecting to the Internet is what matters to users). For me, any > > OS where I can't go online doesn't cut it. And yes, I have a WLAN router > > box, but no I don't use it as such ;-). > > Does your ISP require pppoe? Yes. I've yet to see an ISP in Germany not requiring PPPoe if you want to do DSL -- perhaps there are some because I've got an old DSL modem with a connector for ATM besides the Ethernet one. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From dave at dave.org.uk Sun Feb 25 17:22:14 2007 From: dave at dave.org.uk (Dave Cross) Date: Sun, 25 Feb 2007 17:22:14 +0000 Subject: Sony Vaio AR320E In-Reply-To: <1172404530.3415.3.camel@scott.localdomain> References: <1172404530.3415.3.camel@scott.localdomain> Message-ID: <45E1C5C6.3070603@dave.org.uk> skwalsh wrote: > Installed FC6 w/ all updates. The laptop has special function buttons > S1, S2, Volume, and optical drive eject. Does FC6 support these? How do > I set them up. > If this is the wrong forum, the question becomes "Can you suggest one?" You might be able to do something with Lineak[1]. It's available as an rpm from one of the FC repositories (as lineakd). # yum install lineakd Dave... [1] http://lineak.sourceforge.net/ From jrb at redhat.com Sun Feb 25 20:26:07 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Sun, 25 Feb 2007 15:26:07 -0500 Subject: [Fedora-livecd-list] patch, manifest changes In-Reply-To: <1172259787.3646.22.camel@aglarond.local> References: <20070223184657.GA23983@nostromo.devel.redhat.com> <1172259787.3646.22.camel@aglarond.local> Message-ID: <1172435167.4262.3.camel@peach> On Fri, 2007-02-23 at 14:43 -0500, Jeremy Katz wrote: > Not added because it's incredibly painful for a live CD right now... > and I keep hoping that we're going to get to kill rhgb before F7. > Although the chances of that seem to be dwindling :( We looked at doing so, but decided we weren't going to do significantly better until we got modesetting in the kernel. Looks like an F8 task at the earliest. Thanks, -Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mcepl at redhat.com Mon Feb 26 08:25:13 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 26 Feb 2007 08:25:13 +0000 (UTC) Subject: tweaking the LiveCD References: <20070220223831.GA32321@nostromo.devel.redhat.com> <20070221031003.GA1421@jadzia.bu.edu> Message-ID: Matthew Miller scripst: >> Is dialup dead? >> --------------- >> ppp >> rp-pppoe >> wvdial No, it quite certainly isn't -- here in the Czech republic, some cell phone operators provide quite sensibly priced plan for connecting over PCMCIA cards, which are quite often emulating modem, so you have to use ppp/wvdial. Matej -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC How many Bavarian Illuminati does it take to screw in a light bulb? Three: one to screw it in, and one to confuse the issue. From bnocera at redhat.com Tue Feb 27 17:06:46 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 27 Feb 2007 17:06:46 +0000 Subject: PulseAudio Message-ID: <1172596006.13777.30.camel@cookie.hadess.net> Heya, After installing something resembling a Rawhide system and filing plenty of bugs in the course of action, I set myself onto testing PulseAudio today. I was quite scared by the amounts of configuration (some of it non-trivial) and changes to applications to get PulseAudio working as the main sound system (ie. with all applications talking to ALSA-libs talking to PulseAudio, talking to the ALSA backend). I wanted to have an esound replacement first, so that beeps and warnings could go through PulseAudio, and not hinder the other applications using ALSA. I encountered a bunch of dependency problems: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230206 Then a warning (which I don't think is critical to testing): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230209 And finally, the big problem, an assert trying to play back some sound: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230211 I think this is still the best course of action for F7, given some work to 1) make PulseAudio work (as it doesn't right now for the above), 2) some integration with the GNOME sound properties so it spits out the sound events on the right device. Cheers From david at fubar.dk Tue Feb 27 17:23:49 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 27 Feb 2007 12:23:49 -0500 Subject: PulseAudio In-Reply-To: <1172596006.13777.30.camel@cookie.hadess.net> References: <1172596006.13777.30.camel@cookie.hadess.net> Message-ID: <1172597029.5097.10.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote: > I think this is still the best course of action for F7, given some > work to 1) make PulseAudio work (as it doesn't right now for the > above), 2) some integration with the GNOME sound properties so it > spits out the sound events on the right device. This needs to work with fast-user-switching and that is *hard* given that PA hogs the device (or at least used to) and most ALSA playback devices can only have a single opener (no mixing). Also, keep in mind that we're going to enable accessible login (including screen readers) for gdm - I wonder if we need pulse audio running there and how it works with the alsa-pulse plug-in - will pulse-audio be activated on demand? Or will the presence of alsa-pulse just break accessible login because there's no PA instance running? Thanks for looking into this - PA rocks and will make our distro so much better. But it needs to work with f-u-s or we need to decide to do pull either PA or f-u-s. Simple as that. David From david at fubar.dk Tue Feb 27 17:36:28 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 27 Feb 2007 12:36:28 -0500 Subject: PulseAudio In-Reply-To: <45E46AC7.4080202@drzeus.cx> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <45E46AC7.4080202@drzeus.cx> Message-ID: <1172597788.5097.13.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 18:30 +0100, Pierre Ossman wrote: > David Zeuthen wrote: > > > > Thanks for looking into this - PA rocks and will make our distro so much > > better. But it needs to work with f-u-s or we need to decide to do pull > > either PA or f-u-s. Simple as that. > > > > Or keep dmix until everything can go through pulse? I don't think this works with f-u-s. I tried. Thinking about it, wouldn't it would be a security issue if it did work? You really don't want dmix to accepting connections from other users... David From xiphmont at gmail.com Tue Feb 27 18:02:26 2007 From: xiphmont at gmail.com (Christopher "Monty" Montgomery) Date: Tue, 27 Feb 2007 13:02:26 -0500 Subject: PulseAudio In-Reply-To: <1172596006.13777.30.camel@cookie.hadess.net> References: <1172596006.13777.30.camel@cookie.hadess.net> Message-ID: <806dafc20702271002g65dd9532kf04d4affc4af0c20@mail.gmail.com> On 2/27/07, Bastien Nocera wrote: > And finally, the big problem, an assert trying to play back some sound: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230211 I believe this is SELinux refusing to grant sufficient shared memory for Pulse to work. It doesn't happen when run as root. Monty From drzeus-bugzilla at drzeus.cx Tue Feb 27 18:02:33 2007 From: drzeus-bugzilla at drzeus.cx (Pierre Ossman) Date: Tue, 27 Feb 2007 13:02:33 -0500 Subject: PulseAudio In-Reply-To: <1172597029.5097.10.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> Message-ID: <45E46AC7.4080202@drzeus.cx> David Zeuthen wrote: > > Thanks for looking into this - PA rocks and will make our distro so much > better. But it needs to work with f-u-s or we need to decide to do pull > either PA or f-u-s. Simple as that. > Or keep dmix until everything can go through pulse? From drzeus-bugzilla at drzeus.cx Tue Feb 27 18:02:41 2007 From: drzeus-bugzilla at drzeus.cx (Pierre Ossman) Date: Tue, 27 Feb 2007 13:02:41 -0500 Subject: PulseAudio In-Reply-To: <1172597788.5097.13.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <45E46AC7.4080202@drzeus.cx> <1172597788.5097.13.camel@zelda.fubar.dk> Message-ID: <45E46F30.7030808@drzeus.cx> David Zeuthen wrote: > > I don't think this works with f-u-s. I tried. Thinking about it, > wouldn't it would be a security issue if it did work? You really don't > want dmix to accepting connections from other users... > Ah. Quite right. Just ignore me then :) From xiphmont at xiph.org Tue Feb 27 18:04:21 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 13:04:21 -0500 Subject: PulseAudio In-Reply-To: <1172597029.5097.10.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> Message-ID: <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote: > > I think this is still the best course of action for F7, given some > > work to 1) make PulseAudio work (as it doesn't right now for the > > above), 2) some integration with the GNOME sound properties so it > > spits out the sound events on the right device. > > This needs to work with fast-user-switching and that is *hard* given > that PA hogs the device (or at least used to) and most ALSA playback > devices can only have a single opener (no mixing). Actually, it's easy. Set up a system Pulse and everyone can use sound and emulation. What needs to happen next is to implement session partitioning in Pulse, the emulation helpers and emulation daemons. Pulse should always be running (even if it occasionally releases devices to save battery). Monty From xiphmont at xiph.org Tue Feb 27 18:07:58 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 13:07:58 -0500 Subject: PulseAudio In-Reply-To: <1172597788.5097.13.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <45E46AC7.4080202@drzeus.cx> <1172597788.5097.13.camel@zelda.fubar.dk> Message-ID: <806dafc20702271007p4e8665b0sc35617380e8b1779@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > On Tue, 2007-02-27 at 18:30 +0100, Pierre Ossman wrote: > > David Zeuthen wrote: > > > > > > Thanks for looking into this - PA rocks and will make our distro so much > > > better. But it needs to work with f-u-s or we need to decide to do pull > > > either PA or f-u-s. Simple as that. > > > > > > > Or keep dmix until everything can go through pulse? > > I don't think this works with f-u-s. I tried. Thinking about it, > wouldn't it would be a security issue if it did work? You really don't > want dmix to accepting connections from other users... Of course not. But dmix or a system Pulse, there will be no session partitioning until everyone esle can catch up with these changes. Monty From bnocera at redhat.com Tue Feb 27 18:07:42 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 27 Feb 2007 18:07:42 +0000 Subject: PulseAudio In-Reply-To: <806dafc20702271002g65dd9532kf04d4affc4af0c20@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <806dafc20702271002g65dd9532kf04d4affc4af0c20@mail.gmail.com> Message-ID: <1172599663.13777.49.camel@cookie.hadess.net> On Tue, 2007-02-27 at 13:02 -0500, Christopher "Monty" Montgomery wrote: > On 2/27/07, Bastien Nocera wrote: > > > And finally, the big problem, an assert trying to play back some sound: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230211 > > I believe this is SELinux refusing to grant sufficient shared memory > for Pulse to work. It doesn't happen when run as root. I'm using SELinux in permissive mode, and don't see any errors in /var/log/messages relating to SELinux errors (some avc denied). From bnocera at redhat.com Tue Feb 27 18:15:19 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 27 Feb 2007 18:15:19 +0000 Subject: PulseAudio In-Reply-To: <1172597029.5097.10.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> Message-ID: <1172600119.13777.55.camel@cookie.hadess.net> On Tue, 2007-02-27 at 12:23 -0500, David Zeuthen wrote: > On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote: > > I think this is still the best course of action for F7, given some > > work to 1) make PulseAudio work (as it doesn't right now for the > > above), 2) some integration with the GNOME sound properties so it > > spits out the sound events on the right device. > > This needs to work with fast-user-switching and that is *hard* given > that PA hogs the device (or at least used to) and most ALSA playback > devices can only have a single opener (no mixing). > > Also, keep in mind that we're going to enable accessible login > (including screen readers) for gdm - I wonder if we need pulse audio > running there and how it works with the alsa-pulse plug-in - will > pulse-audio be activated on demand? Or will the presence of alsa-pulse > just break accessible login because there's no PA instance running? > > Thanks for looking into this - PA rocks and will make our distro so much > better. But it needs to work with f-u-s or we need to decide to do pull > either PA or f-u-s. Simple as that. Does esound work that way? If it doesn't, then you have the exact same problem when a user switches on the sound bling in the control-center. If it does, then what's stopping us from using PA as a drop-in replacement for esound? It would/should work just as well as esound did before (apart from the fact that I'm told PA hogs the physical device instead of going through dmix, which means nothing works unless you have a PA sink, or use the ALSA plugin for PA). From xiphmont at gmail.com Tue Feb 27 18:20:08 2007 From: xiphmont at gmail.com (Christopher "Monty" Montgomery) Date: Tue, 27 Feb 2007 13:20:08 -0500 Subject: PulseAudio In-Reply-To: <1172599663.13777.49.camel@cookie.hadess.net> References: <1172596006.13777.30.camel@cookie.hadess.net> <806dafc20702271002g65dd9532kf04d4affc4af0c20@mail.gmail.com> <1172599663.13777.49.camel@cookie.hadess.net> Message-ID: <806dafc20702271020n50436e2ax7052d5f9b28f6b73@mail.gmail.com> On 2/27/07, Bastien Nocera wrote: > On Tue, 2007-02-27 at 13:02 -0500, Christopher "Monty" Montgomery wrote: > > On 2/27/07, Bastien Nocera wrote: > > > > > And finally, the big problem, an assert trying to play back some sound: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230211 > > > > I believe this is SELinux refusing to grant sufficient shared memory > > for Pulse to work. It doesn't happen when run as root. > > I'm using SELinux in permissive mode, and don't see any errors > in /var/log/messages relating to SELinux errors (some avc denied). Then it is likely a security policy (PAM?) refusing to grant or limiting memory access. That's not to say that Pulse shouldn't be doing a better job of trapping the error- it should. In any case, I have seen that exact error on my own boxes, and it was due to being refused access to shared mem. Not definitive in your case, just likely. Monty From davidz at redhat.com Tue Feb 27 18:20:17 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 13:20:17 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> Message-ID: <1172600417.5097.36.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 13:04 -0500, xiphmont at xiph.org wrote: > On 2/27/07, David Zeuthen wrote: > > On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote: > > > I think this is still the best course of action for F7, given some > > > work to 1) make PulseAudio work (as it doesn't right now for the > > > above), 2) some integration with the GNOME sound properties so it > > > spits out the sound events on the right device. > > > > This needs to work with fast-user-switching and that is *hard* given > > that PA hogs the device (or at least used to) and most ALSA playback > > devices can only have a single opener (no mixing). > > Actually, it's easy. Set up a system Pulse and everyone can use sound > and emulation. What needs to happen next is to implement session > partitioning in Pulse, the emulation helpers and emulation daemons. > > Pulse should always be running (even if it occasionally releases > devices to save battery). So it's like this. For *modern* Linux desktop we've been moving functionality from system-wide daemons into per-session daemons *simply* because system-wide daemons have a number of problems. One of those is that you want to read user settings and enforce policy depending on users session [1]. Another problem is that if you have system-wide daemons you need to coordinate clients with different identities; e.g. you suddenly need to label your objects and make sure that an object created by uid 500 cannot be manipulated by uid 501. Things like that. Does PA handle that already? For starters, how are all the exiting PA tools going to work with PA running system-wide? How is it going to work with multiple sessions? I don't think there's anything "easy" about this. If it was easy, wouldn't you have RPM's for us already? ;-) I think what you want is some system-wide private PA mixer service that only per-session PA instances can connect to over a private protocol. David [1] : see also Lennarts presentation about "Compiz for audio" plans which further marries that idea http://0pointer.de/blog/projects/freedom-lovers.html David From davidz at redhat.com Tue Feb 27 18:21:56 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 13:21:56 -0500 Subject: PulseAudio In-Reply-To: <1172600119.13777.55.camel@cookie.hadess.net> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <1172600119.13777.55.camel@cookie.hadess.net> Message-ID: <1172600516.5097.39.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 18:15 +0000, Bastien Nocera wrote: > On Tue, 2007-02-27 at 12:23 -0500, David Zeuthen wrote: > > On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote: > > > I think this is still the best course of action for F7, given some > > > work to 1) make PulseAudio work (as it doesn't right now for the > > > above), 2) some integration with the GNOME sound properties so it > > > spits out the sound events on the right device. > > > > This needs to work with fast-user-switching and that is *hard* given > > that PA hogs the device (or at least used to) and most ALSA playback > > devices can only have a single opener (no mixing). > > > > Also, keep in mind that we're going to enable accessible login > > (including screen readers) for gdm - I wonder if we need pulse audio > > running there and how it works with the alsa-pulse plug-in - will > > pulse-audio be activated on demand? Or will the presence of alsa-pulse > > just break accessible login because there's no PA instance running? > > > > Thanks for looking into this - PA rocks and will make our distro so much > > better. But it needs to work with f-u-s or we need to decide to do pull > > either PA or f-u-s. Simple as that. > > Does esound work that way? If it doesn't, then you have the exact same > problem when a user switches on the sound bling in the control-center. > > If it does, then what's stopping us from using PA as a drop-in > replacement for esound? It would/should work just as well as esound did > before (apart from the fact that I'm told PA hogs the physical device > instead of going through dmix, which means nothing works unless you have > a PA sink, or use the ALSA plugin for PA). What is stopping us is that esound is not used by default and haven't for a long time. I'm all for PA but we cannot turn it on by default until it works with f-u-s. Well, we can, but then f-u-s is useless and I don't think we want to ship useless products... David From bnocera at redhat.com Tue Feb 27 18:24:00 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 27 Feb 2007 18:24:00 +0000 Subject: PulseAudio In-Reply-To: <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> Message-ID: <1172600640.13777.61.camel@cookie.hadess.net> On Tue, 2007-02-27 at 13:04 -0500, xiphmont at xiph.org wrote: > On 2/27/07, David Zeuthen wrote: > > On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote: > > > I think this is still the best course of action for F7, given some > > > work to 1) make PulseAudio work (as it doesn't right now for the > > > above), 2) some integration with the GNOME sound properties so it > > > spits out the sound events on the right device. > > > > This needs to work with fast-user-switching and that is *hard* given > > that PA hogs the device (or at least used to) and most ALSA playback > > devices can only have a single opener (no mixing). > > Actually, it's easy. Set up a system Pulse and everyone can use sound > and emulation. What needs to happen next is to implement session > partitioning in Pulse, the emulation helpers and emulation daemons. > > Pulse should always be running (even if it occasionally releases > devices to save battery). I'll wait for your mail about the pros and cons before getting further on this. We'd need to rethink the gnome-sound-properties if PA was to be used as a system daemon, as we wouldn't be able to easily switch outputs. What worries me as well is the amount of work necessary to get speaker systems with more than 2 speakers (ie. stereo) working, and if it even would with PA. I'll hold on for more details, and you can fill in the blanks for me then :) Cheers From bnocera at redhat.com Tue Feb 27 18:25:41 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 27 Feb 2007 18:25:41 +0000 Subject: PulseAudio In-Reply-To: <1172600516.5097.39.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <1172600119.13777.55.camel@cookie.hadess.net> <1172600516.5097.39.camel@zelda.fubar.dk> Message-ID: <1172600741.13777.63.camel@cookie.hadess.net> On Tue, 2007-02-27 at 13:21 -0500, David Zeuthen wrote: > On Tue, 2007-02-27 at 18:15 +0000, Bastien Nocera wrote: > > On Tue, 2007-02-27 at 12:23 -0500, David Zeuthen wrote: > > > On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote: > > > > I think this is still the best course of action for F7, given some > > > > work to 1) make PulseAudio work (as it doesn't right now for the > > > > above), 2) some integration with the GNOME sound properties so it > > > > spits out the sound events on the right device. > > > > > > This needs to work with fast-user-switching and that is *hard* given > > > that PA hogs the device (or at least used to) and most ALSA playback > > > devices can only have a single opener (no mixing). > > > > > > Also, keep in mind that we're going to enable accessible login > > > (including screen readers) for gdm - I wonder if we need pulse audio > > > running there and how it works with the alsa-pulse plug-in - will > > > pulse-audio be activated on demand? Or will the presence of alsa-pulse > > > just break accessible login because there's no PA instance running? > > > > > > Thanks for looking into this - PA rocks and will make our distro so much > > > better. But it needs to work with f-u-s or we need to decide to do pull > > > either PA or f-u-s. Simple as that. > > > > Does esound work that way? If it doesn't, then you have the exact same > > problem when a user switches on the sound bling in the control-center. > > > > If it does, then what's stopping us from using PA as a drop-in > > replacement for esound? It would/should work just as well as esound did > > before (apart from the fact that I'm told PA hogs the physical device > > instead of going through dmix, which means nothing works unless you have > > a PA sink, or use the ALSA plugin for PA). > > What is stopping us is that esound is not used by default and haven't > for a long time. I'm all for PA but we cannot turn it on by default > until it works with f-u-s. Well, we can, but then f-u-s is useless and I > don't think we want to ship useless products... If f-u-s breaks, right now, when the user ticks the "start up esound so I can get desktop bling", then something is broken, and needs fixing, whether or not we want to enable PA. From xiphmont at xiph.org Tue Feb 27 18:28:55 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 13:28:55 -0500 Subject: PulseAudio In-Reply-To: <1172600417.5097.36.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> Message-ID: <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > So it's like this. For *modern* Linux desktop we've been moving > functionality from system-wide daemons into per-session daemons *simply* > because system-wide daemons have a number of problems. Justification by cargo cult. Here's a few reasons per-session Pulse is [relatively] a worse idea: You lose state on switch. Transitions are abrupt and 'poppy'; think of the X mode changes upon switch. Per session is harder, yields inferior results in the long run, and gives us no path to move to immediately. Impossibility of emulation. Emulation is not optional. We do not make forward progress by throwing all the current users under the bus. This is *the* reason esd was a resounding failure. > One of those is that you want to read user settings and enforce policy > depending on users session [1]. Of course. And that's no different if it's done in the session or in the system. > Another problem is that if you have system-wide daemons you need to > coordinate clients with different identities; e.g. you suddenly need to > label your objects and make sure that an object created by uid 500 > cannot be manipulated by uid 501. Things like that. Does PA handle that > already? No, it does not. It will also not currently handle f-u-s as a session daemon either. > For starters, how are all the exiting PA tools going to work with PA > running system-wide? PA has always worked as a system daemon. > How is it going to work with multiple sessions? I > don't think there's anything "easy" about this. If it was easy, wouldn't > you have RPM's for us already? ;-) The code is easy. The politics make me want to walk away and never look back. > I think what you want is some system-wide private PA mixer service that > only per-session PA instances can connect to over a private protocol. That is actually one possibility up for consideration, but I think needlessly complicated. The problem is not making Pulse work well with f-u-s-- the problem is keeping ALSA, ESD and OSS access working with f-u-s. Remember-- that's everybody right now. Monty From xiphmont at xiph.org Tue Feb 27 18:44:04 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 13:44:04 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> Message-ID: <806dafc20702271044y62047c77hf526024cdc23f3e4@mail.gmail.com> On 2/27/07, xiphmont at xiph.org wrote: > > I think what you want is some system-wide private PA mixer service that > > only per-session PA instances can connect to over a private protocol. > > That is actually one possibility up for consideration, but I think > needlessly complicated. Rather, I should say the idea up for consideration is a thin authenticator that is the only trusted connection mechanism for a system pulse. That still doesn't directly help out the emulation case though. We can't ship broken stuff, and regressing sound counts as broken. Monty From davidz at redhat.com Tue Feb 27 18:49:57 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 13:49:57 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> Message-ID: <1172602197.5097.57.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 13:28 -0500, xiphmont at xiph.org wrote: > On 2/27/07, David Zeuthen wrote: > > > So it's like this. For *modern* Linux desktop we've been moving > > functionality from system-wide daemons into per-session daemons *simply* > > because system-wide daemons have a number of problems. > > Justification by cargo cult. Oh please. Keep this discussion technical. > Here's a few reasons per-session Pulse is > [relatively] a worse idea: > > You lose state on switch. > Transitions are abrupt and 'poppy'; think of the X mode changes upon switch. X is getting fixed. See Keith's blog for this http://keithp.com/blog/kernel-mode-drivers.html See also below. > Per session is harder, yields inferior results in the long run, and > gives us no path to move to immediately. Either we do things right or we don't do them at all. No more hacks for benefit in the short run. Please. > Impossibility of emulation. Emulation is not optional. We do not > make forward progress by throwing all the current users under the bus. > This is *the* reason esd was a resounding failure. Users can use LD_PRELOAD for such broken apps that we can't patch to live in this century. We all know that /dev/dsp is fundamentally broken and no-one but people living stuck in the 90's are using it. We're a *free software distribution*, we don't have to support legacy crap the nice way. If you want, use LD_PRELOAD hacks. Or some emulation daemon that can forward the stream from then open(2)'er to the right PA instance (not hard). > > Another problem is that if you have system-wide daemons you need to > > coordinate clients with different identities; e.g. you suddenly need to > > label your objects and make sure that an object created by uid 500 > > cannot be manipulated by uid 501. Things like that. Does PA handle that > > already? > > No, it does not. Heck, so uid 501 can poke the streams created by uid 500? That's a show stopper just because of security implications. Do you disagree? > It will also not currently handle f-u-s as a session > daemon either. That's only because PA decides to open the device directly and haven't been taught to give it up on session inactivity. That's not hard to change and it's the right thing to do *anyway* since we probably want a default policy where audio is muted from inactive sessions just like video is muted. Heck, we're getting revoke() soon (see #230006) so whether the PA instance in a session likes it or not it's going to have access to the sound device revoked. It just needs to cope with that *just like* it needs to cope with devices being hot-removed. > > How is it going to work with multiple sessions? I > > don't think there's anything "easy" about this. If it was easy, wouldn't > > you have RPM's for us already? ;-) > > The code is easy. The politics make me want to walk away and never look back. Well, there's no politics here apart from wishing not to introduce short-term hacks that will haunt us for ever. See X.org mode setting in user space for a brilliant example of how this hack is STILL HAUNTING US in 2007. Ding ding ding, it's 2007 already! > > I think what you want is some system-wide private PA mixer service that > > only per-session PA instances can connect to over a private protocol. > > That is actually one possibility up for consideration, but I think > needlessly complicated. The problem is not making Pulse work well > with f-u-s-- the problem is keeping ALSA, ESD and OSS access working > with f-u-s. Remember-- that's everybody right now. Yes, we need to sort out this audio situation. Right now PA, until it's fixed in a sensible way, makes f-u-s not work so we can only do one of them. That's not my call though. What is the view of all this from PA upstream? I talked a lot to Lennart at LCA about this and he said system-wide pulse was a non-starter exactly for the reasons I listed. David From mclasen at redhat.com Tue Feb 27 18:57:51 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 27 Feb 2007 13:57:51 -0500 Subject: PulseAudio In-Reply-To: <1172600516.5097.39.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <1172600119.13777.55.camel@cookie.hadess.net> <1172600516.5097.39.camel@zelda.fubar.dk> Message-ID: <1172602671.10368.4.camel@localhost.localdomain> On Tue, 2007-02-27 at 13:21 -0500, David Zeuthen wrote: > What is stopping us is that esound is not used by default and haven't > for a long time. I'm all for PA but we cannot turn it on by default > until it works with f-u-s. Well, we can, but then f-u-s is useless and I > don't think we want to ship useless products... There's no need to paint back-and-white here. Fast user switching remains useful even if sound does not work with it. It would certainly be nicer if it all just worked, but the fact that it doesn't is no reason to exaggerate like that. From davidz at redhat.com Tue Feb 27 18:54:31 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 13:54:31 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271044y62047c77hf526024cdc23f3e4@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <806dafc20702271044y62047c77hf526024cdc23f3e4@mail.gmail.com> Message-ID: <1172602471.5097.61.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 13:44 -0500, xiphmont at xiph.org wrote: > On 2/27/07, xiphmont at xiph.org wrote: > > > > I think what you want is some system-wide private PA mixer service that > > > only per-session PA instances can connect to over a private protocol. > > > > That is actually one possibility up for consideration, but I think > > needlessly complicated. > > Rather, I should say the idea up for consideration is a thin > authenticator that is the only trusted connection mechanism for a > system pulse. Yea, that's sort of what I meant. The system-wide bit would just pass a fd over a socket to the per-session pulse. > That still doesn't directly help out the emulation case > though. So, why can't the emulation bits pass the fd from the open(2)'er of /dev/dsp to the right PA instance? These bits could live in the system-wide bit... > We can't ship broken stuff, and regressing sound counts as > broken. There's no regressions if we decide not to use PA by default; things will still just suck as bad as they did for FC6, FC5, FC4 and FC3. David From xiphmont at xiph.org Tue Feb 27 19:04:11 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 14:04:11 -0500 Subject: PulseAudio In-Reply-To: <1172602197.5097.57.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> Message-ID: <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > Oh please. Keep this discussion technical. I meant exactly what I said. It was not intended as a personal attack. > Either we do things right or we don't do them at all. No more hacks for > benefit in the short run. Please. > > > Impossibility of emulation. Emulation is not optional. We do not > > make forward progress by throwing all the current users under the bus. > > This is *the* reason esd was a resounding failure. > > Users can use LD_PRELOAD for such broken apps that we can't patch to > live in this century. We all know that /dev/dsp is fundamentally broken > and no-one but people living stuck in the 90's are using it. LD_PRELOAD is a fragile hack that wasn't enough to save ESD. Either we do things right or we don't do them at all. No more hacks for benefit in the short run. Please. > > No, it does not. > > Heck, so uid 501 can poke the streams created by uid 500? That's a show > stopper just because of security implications. Do you disagree? I agree it's not acceptible in the mid/long term. However, this is already what Ubuntu and Debian do today. > That's only because PA decides to open the device directly and haven't > been taught to give it up on session inactivity. That's not hard to > change and it's the right thing to do *anyway* since we probably want a > default policy where audio is muted from inactive sessions just like > video is muted. And that's no different than if pulse was a system daemon that listened to dbus. > Heck, we're getting revoke() soon (see #230006) so whether the PA > instance in a session likes it or not it's going to have access to the > sound device revoked. It just needs to cope with that *just like* it > needs to cope with devices being hot-removed. revoke is just such a .... stunningly... idiotic idea.... > Well, there's no politics here apart from wishing not to introduce > short-term hacks that will haunt us for ever. I can't take you seriously when you keep saying that, then pushing LD_PRELOAD. > What is the view of all this from PA upstream? I talked a lot to Lennart > at LCA about this and he said system-wide pulse was a non-starter > exactly for the reasons I listed. That's partially because I convinced him so at GUADEC. It took some arguing. Monty From xiphmont at xiph.org Tue Feb 27 19:07:25 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 14:07:25 -0500 Subject: PulseAudio In-Reply-To: <1172602471.5097.61.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <806dafc20702271044y62047c77hf526024cdc23f3e4@mail.gmail.com> <1172602471.5097.61.camel@zelda.fubar.dk> Message-ID: <806dafc20702271107p64ee57c4i1c7e256c88514942@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > > Rather, I should say the idea up for consideration is a thin > > authenticator that is the only trusted connection mechanism for a > > system pulse. > > Yea, that's sort of what I meant. The system-wide bit would just pass a > fd over a socket to the per-session pulse. Backwards. > So, why can't the emulation bits pass the fd from the open(2)'er > of /dev/dsp to the right PA instance? These bits could live in the > system-wide bit... Please, no more talk of LD_PRELOAD. I will resign before I pin the future of Linux Audio on an LD_PRELOAD hack. Dead serious. It is a non-starter. > There's no regressions if we decide not to use PA by default; things > will still just suck as bad as they did for FC6, FC5, FC4 and FC3. Sure, problem solved. Monty From davidz at redhat.com Tue Feb 27 19:09:23 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 14:09:23 -0500 Subject: PulseAudio In-Reply-To: <1172602671.10368.4.camel@localhost.localdomain> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <1172600119.13777.55.camel@cookie.hadess.net> <1172600516.5097.39.camel@zelda.fubar.dk> <1172602671.10368.4.camel@localhost.localdomain> Message-ID: <1172603363.5097.66.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 13:57 -0500, Matthias Clasen wrote: > On Tue, 2007-02-27 at 13:21 -0500, David Zeuthen wrote: > > > What is stopping us is that esound is not used by default and haven't > > for a long time. I'm all for PA but we cannot turn it on by default > > until it works with f-u-s. Well, we can, but then f-u-s is useless and I > > don't think we want to ship useless products... > > There's no need to paint back-and-white here. Fast user switching > remains useful even if sound does not work with it. It would certainly > be nicer if it all just worked, but the fact that it doesn't is no > reason to exaggerate like that. Well, what pisses me off is the fact that "per-session daemon is hard, let's just do a system-wide daemon" without realizing all the implications of this (settings, security). I'm perfectly fine with having PA as a per-session daemon and sound on f-u-s not working if the following is on the PA roadmap - PA giving up sound devices on silence - PA being able to give up sound devices on session switching - emulation daemon can forward fd to per-session PA daemon or - some kind of ultra-light system-wide daemon for arbitrating access to sound hardware for per-session PA instances because then we can clean this up for F8 and/or an F7 update. But deciding on an architecture (system-wide PA) that I consider broken by design is just the wrong thing. Monty, what do you think? David From davidz at redhat.com Tue Feb 27 19:14:53 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 14:14:53 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> Message-ID: <1172603693.5097.72.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 14:04 -0500, xiphmont at xiph.org wrote: > > Heck, so uid 501 can poke the streams created by uid 500? That's a > show > > stopper just because of security implications. Do you disagree? > > I agree it's not acceptible in the mid/long term. However, this is > already what Ubuntu and Debian do today. Ding ding ding. We want to ship a distro that is secure by default. Seriously, this is a stop-ship thing whether you personally like it or not. > revoke is just such a .... stunningly... idiotic idea.... My gods. Do not pass start. Do not collect $200. Hint, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230006 and come back when you understand the implications. Thanks. > > Well, there's no politics here apart from wishing not to introduce > > short-term hacks that will haunt us for ever. > > I can't take you seriously when you keep saying that, then pushing LD_PRELOAD. It's because I live in this century and don't use OSS myself. Either LD_PRELOAD or some emulation daemon that forwards the stream to the right PA instance. Either is ugly because OSS is ugly. Of course, we wouldn't enable such things by default because we don't have OSS apps in the default install. Perhaps enterprise distros that care about old crap would. > > What is the view of all this from PA upstream? I talked a lot to Lennart > > at LCA about this and he said system-wide pulse was a non-starter > > exactly for the reasons I listed. > > That's partially because I convinced him so at GUADEC. It took some arguing. *plonk* Here's a quarter, Monty. Go use it to try a modern Linux desktop. David From davidz at redhat.com Tue Feb 27 19:16:32 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 14:16:32 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271107p64ee57c4i1c7e256c88514942@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <806dafc20702271044y62047c77hf526024cdc23f3e4@mail.gmail.com> <1172602471.5097.61.camel@zelda.fubar.dk> <806dafc20702271107p64ee57c4i1c7e256c88514942@mail.gmail.com> Message-ID: <1172603792.5097.75.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 14:07 -0500, xiphmont at xiph.org wrote: > On 2/27/07, David Zeuthen wrote: > > > Rather, I should say the idea up for consideration is a thin > > > authenticator that is the only trusted connection mechanism for a > > > system pulse. > > > > Yea, that's sort of what I meant. The system-wide bit would just pass a > > fd over a socket to the per-session pulse. > > Backwards. How about posting a more detailed plan or replying to the one I posted just before. And no manifestos in it this time either - we're not terribly interested in why *you* think OSS is important to support since it can be done by at least two mechanisms if you so desire. Thanks. David From nicolas.mailhot at laposte.net Tue Feb 27 19:33:01 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 27 Feb 2007 20:33:01 +0100 Subject: PulseAudio In-Reply-To: <1172600417.5097.36.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> Message-ID: <1172604781.11172.16.camel@rousalka.dyndns.org> Le mardi 27 f?vrier 2007 ? 13:20 -0500, David Zeuthen a ?crit : > So it's like this. For *modern* Linux desktop we've been moving > functionality from system-wide daemons into per-session daemons *simply* > because system-wide daemons have a number of problems. Per-session daemons may be nice for stuff that does not require exclusive access, to manage hardware they're a disaster. I don't want to log in at midnight so my GUI recording software is authorised to access the tuner card, wireless link should not go down at user logout, power management should happen even on a mostly headless system, etc The "modern" Linux desktop seems limited to a single-user laptop in brick mode when one logs out. Per-sessions daemons are not simple they're dumb. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From davidz at redhat.com Tue Feb 27 19:41:01 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 14:41:01 -0500 Subject: PulseAudio In-Reply-To: <1172604781.11172.16.camel@rousalka.dyndns.org> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <1172604781.11172.16.camel@rousalka.dyndns.org> Message-ID: <1172605261.5097.83.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 20:33 +0100, Nicolas Mailhot wrote: > Le mardi 27 f?vrier 2007 ? 13:20 -0500, David Zeuthen a ?crit : > > > So it's like this. For *modern* Linux desktop we've been moving > > functionality from system-wide daemons into per-session daemons *simply* > > because system-wide daemons have a number of problems. > > Per-session daemons may be nice for stuff that does not require > exclusive access, to manage hardware they're a disaster. I don't want to > log in at midnight so my GUI recording software is authorised to access > the tuner card, wireless link should not go down at user logout, power > management should happen even on a mostly headless system, etc I already answered your question re device permissions here https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00713.html > The "modern" Linux desktop seems limited to a single-user laptop in > brick mode when one logs out. Yes, having some kind of policy agent running when no user is logged in is desirable. It has nothing to do with this discussion though. > Per-sessions daemons are not simple > they're dumb. Actually these daemons have lots of features (for example nm-applet has WPA2, VPN, secure access to user secrets) and is by far more advanced that what we had before. We simply just need to run them when no user is logged in. Reason why this hasn't happened is that, if you didn't know, answering the question "is a user logged in?" is damn hard to do in a portable and clever way, hence ConsoleKit. Heck, system level daemons that are pure mechanisms, like HAL, now leverage this CK to do things like this http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=d11a896c7cf1edd2d1d1e46647abdbdc53651224 Again, it has nothing to do with this discussion. David From davidz at redhat.com Tue Feb 27 19:49:46 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 14:49:46 -0500 Subject: PulseAudio In-Reply-To: <1172605261.5097.83.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <1172604781.11172.16.camel@rousalka.dyndns.org> <1172605261.5097.83.camel@zelda.fubar.dk> Message-ID: <1172605786.5097.88.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 14:41 -0500, David Zeuthen wrote: > Actually these daemons have lots of features (for example nm-applet has > WPA2, VPN, secure access to user secrets) and is by far more advanced > that what we had before. > > We simply just need to run them when no user is logged in. And, for the record, the reason this is super desirable is that to configure system-wide policy (e.g. when no one is logged in), we can re-use exactly the same configuration applets, e.g. for the g-p-m preference dialog you'd have a button [ Set these settings as system wide ] that would (possibly after auth) copy these settings to the system-wide preference area. For a single-user laptop probably this would be done by default. All this could (possibly) be useful on servers too; e.g. you could have the policy for g-v-m when no-one is logged in to automount media and share it on the local network via Avahi. Use case would be some system that have a CD with patches he needs 100 different servers to access; just pop in the disc and it's available on the network. But now I'm drifting off-topic.... David From xiphmont at xiph.org Tue Feb 27 20:01:54 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 15:01:54 -0500 Subject: PulseAudio In-Reply-To: <1172603693.5097.72.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> Message-ID: <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > My gods. Do not pass start. Do not collect $200. Hint, see > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230006 > > and come back when you understand the implications. Thanks. You're asking the world to upgrade to benefit your pet project or be left behind. The chances of that working out are not high. > It's because I live in this century and don't use OSS myself. And yet you feel justified to dismiss it. I don't use the desktop much myself, so it must be unimportant. Replace OSS with ALSA; the point still stands and perhaps you can identify more with it. Say 'ESD' in a room full of Linux users five years ago, and the first thing anyone thought was 'Oh, it's that thing I have to kill so all my sounds apps will work again'. If we repeat that mistake with PA, PA will also become reviled. > Of course, we wouldn't enable such things by default because we don't > have OSS apps in the default install. Perhaps enterprise distros that > care about old crap would. Fine. Do we ship any ALSA apps? I think we might. > Here's a quarter, Monty. Go use it to try a modern Linux desktop. If we're going to take the gloves off, I can bitchslap with the best. Monty From davidz at redhat.com Tue Feb 27 20:10:56 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 15:10:56 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> Message-ID: <1172607056.5097.97.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 15:01 -0500, xiphmont at xiph.org wrote: > > My gods. Do not pass start. Do not collect $200. Hint, see > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230006 > > > > and come back when you understand the implications. Thanks. > > You're asking the world to upgrade to benefit your pet project or be ^^^ How nice. > left behind. The chances of that working out are not high. No, we're just fixing past design mistakes to make the Linux desktop be true multi-user (again). In some circles it's called progress; looking forward and doing new exciting things. If such things happen to be useful, hey, more power to the Linux desktop. > > It's because I live in this century and don't use OSS myself. > > And yet you feel justified to dismiss it. I don't use the desktop > much myself, so it must be unimportant. I'm not dismissing OSS; there are, at least two mechanisms to support it; let me repeat - LD_PRELOAD (widely used by LTSP) - emulation devices Let me repeat again: both are ugly as hell because OSS is ugly as hell. Whether we as a distro want to keep compat for these around in the *default* install is a separate issue and up to the Fedora project at large. I don't really care and I'm sure people who have a better idea of our user base does. It could go in a compat-oss package for all I care. For the record we have other compat* packages that you need to use antiquated interfaces. > Replace OSS with ALSA; the point still stands and perhaps you can > identify more with it. No, it's fine, apps use libasound and there's a plug-in for Pulse. > Say 'ESD' in a room full of Linux users five years ago, and the first > thing anyone thought was 'Oh, it's that thing I have to kill so all my > sounds apps will work again'. If we repeat that mistake with PA, PA > will also become reviled. I don't understand this. OSS compat is possible through two mechanisms already. Plus I have a lot of faith in the PA developers not to screw up. > > Of course, we wouldn't enable such things by default because we don't > > have OSS apps in the default install. Perhaps enterprise distros that > > care about old crap would. > > Fine. Do we ship any ALSA apps? I think we might. No, it's fine, apps use libasound and there's a plug-in for Pulse. David From xiphmont at xiph.org Tue Feb 27 20:32:49 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 15:32:49 -0500 Subject: PulseAudio In-Reply-To: <1172607056.5097.97.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> Message-ID: <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > Let me repeat again: both are ugly as hell because OSS is ugly as hell. I'm not arguing with that. We need to support it regardless, or the march of forward progress will fail like it did last time. We're not in a situation where we can force bitter medicine on users 'for their own good', and we shouldn't try. > Whether we as a distro want to keep compat for these around in the > *default* install is a separate issue and up to the Fedora project at > large. No, it is entirely the same issue. If only one application a user has been relying on daily for years breaks due to 'forward progress', that user is going to hate 'forward progress'. I am among the people who regard computers as tools: you use them to get work done. You don't use them because you love staring at glowing objects or because all the tech is just so damned nifty. And very few things piss off a tool user like a tool breaking. Being informed it was for his own good does not make him happier ("just write to the author and tell him to fix his broken crap! We're trying to march toward the sunrise of a glorious tomorrow here!"). This is not to say that's not going to happen occasionally anyway, but to claim it's unimportant or obstructionist is ludicrous. This is not off topic. It is central to the problem of software adoption in a community that is not captive. > > Say 'ESD' in a room full of Linux users five years ago, and the first > > thing anyone thought was 'Oh, it's that thing I have to kill so all my > > sounds apps will work again'. If we repeat that mistake with PA, PA > > will also become reviled. > > I don't understand this. OSS compat is possible through two mechanisms > already. Plus I have a lot of faith in the PA developers not to screw > up. Typing 'padsp {insert wrapped application here}' does not count as 'compatability'. If it did, we'd already be done and the world would be saved. As for an emu daemon, we'd need to implement f-u-s awareness. The emu daemon is also a system daemon, and those are apparently evil these days. Many applications of sound are more appliance-like than application-like. A session daemon is all fine and good until the applicance has its appliance disappear. The session daemon approach does not allow even the possibility of appliance-like sound applications. And there's a simple problem of physics, Unlike X we can't just 'fix' the pop of a sound card when the device is shut off and restarted. If we go the session route, we will live with the pop forever. Think about what a sound card output stage looks like.... An earlier question still stands, and it is central: does UID == console session ID? Monty From mccann at jhu.edu Tue Feb 27 20:41:07 2007 From: mccann at jhu.edu (William Jon McCann) Date: Tue, 27 Feb 2007 15:41:07 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> Message-ID: <939dd5750702271241g7e1c6fbegc5927907720fc4d5@mail.gmail.com> Hi Monty, On 2/27/07, xiphmont at xiph.org wrote: > An earlier question still stands, and it is central: does UID == > console session ID? To me, this is very much like asking "Does UID == $DISPLAY"? And the answer of course is - not in general. Jon From xiphmont at xiph.org Tue Feb 27 20:44:10 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 15:44:10 -0500 Subject: PulseAudio In-Reply-To: <939dd5750702271241g7e1c6fbegc5927907720fc4d5@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <939dd5750702271241g7e1c6fbegc5927907720fc4d5@mail.gmail.com> Message-ID: <806dafc20702271244k22ff58d7u22d25b94616e1c5e@mail.gmail.com> On 2/27/07, William Jon McCann wrote: > Hi Monty, > > On 2/27/07, xiphmont at xiph.org wrote: > > An earlier question still stands, and it is central: does UID == > > console session ID? > > To me, this is very much like asking "Does UID == $DISPLAY"? And the > answer of course is - not in general. I am asking so that the answer is a documented-- and thought about-- instead of being a nebulous assumption. For one, it will be difficult to have true session-unique emulation support because those interfaces used /dev permissions with no concept of session, only uid and gid. Monty From davidz at redhat.com Tue Feb 27 21:01:22 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 16:01:22 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> Message-ID: <1172610082.5097.119.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 15:32 -0500, xiphmont at xiph.org wrote: > [stuff why we should support OSS in the default install] As I said, it's not my call whether the Fedora project should support this in the default install. For the record, if you want to run GTK 1.x apps you need to install compat packages. That's a decision that the Fedora project made after doing cost/benefit analysis etc. Things like 'cost' included - including GTK 1.x meant fewer people ported to GTK 2.x - the apps we include in the distro were all migrated - size/complexity of maintenance - and things like... If supporting OSS out of the box just works and is cheap to maintain, hey, go for it. If there's a huge cost.. then.. back to your cost/ benefit analysis. Personally, I'd like OSS to just work, don't get me wrong it would be *nice* to have but not something that should dictate an architecture and make it *very hard* to do future stuff (running PA system-wide). > Typing 'padsp {insert wrapped application here}' does not count as > 'compatability'. If it did, we'd already be done and the world would > be saved. > > As for an emu daemon, we'd need to implement f-u-s awareness. The emu > daemon is also a system daemon, and those are apparently evil these > days. It's fine being a system daemon if it's a pure mechanism. Tell me, said emu system daemon knows the uid/pid of the opener of the device. Presumably this emu system daemon would pass the file descriptor to the appropriate PA instance. How about that? (I tried to ask a few times but you never really answered) > Many applications of sound are more appliance-like than > application-like. A session daemon is all fine and good until the > applicance has its appliance disappear. The session daemon approach > does not allow even the possibility of appliance-like sound > applications. Either - tell them to startup Pulse themselves; or better - we automatically launch Pulse when needed (through libasound or the system emulation daemon) > And there's a simple problem of physics, Unlike X we can't just 'fix' > the pop of a sound card when the device is shut off and restarted. If > we go the session route, we will live with the pop forever. Think > about what a sound card output stage looks like.... We'll have the pop whenever we want to suspend the audio hardware and we do want to do that in the default install for laptops anyway. Because saving power is very important and may in the future be a requirement to sell to governments. Besides, your assumption that the sound card will be switched off/on during session switch (and cause a pop) is utterly wrong - the kernel driver for the hardware would of course only suspend the sound card after N seconds of no openers. Further, only few sound card drivers do this already, I can only think of the one for OLPC hardware. > An earlier question still stands, and it is central: does UID == > console session ID? Nope. David From davidz at redhat.com Tue Feb 27 21:07:43 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 16:07:43 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271244k22ff58d7u22d25b94616e1c5e@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <939dd5750702271241g7e1c6fbegc5927907720fc4d5@mail.gmail.com> <806dafc20702271244k22ff58d7u22d25b94616e1c5e@mail.gmail.com> Message-ID: <1172610463.5097.126.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 15:44 -0500, xiphmont at xiph.org wrote: > On 2/27/07, William Jon McCann wrote: > > Hi Monty, > > > > On 2/27/07, xiphmont at xiph.org wrote: > > > An earlier question still stands, and it is central: does UID == > > > console session ID? > > > > To me, this is very much like asking "Does UID == $DISPLAY"? And the > > answer of course is - not in general. > > I am asking so that the answer is a documented-- and thought about-- > instead of being a nebulous assumption. For one, it will be difficult > to have true session-unique emulation support because those interfaces > used /dev permissions with no concept of session, only uid and gid. If the emu system daemon runs as root you, then /dev/dsp and friends would only need to be accessible by root assuming the emu system daemon passes the fd to the PA instances. That's what I meant in the other mail with: > It's fine being a system daemon if it's a pure mechanism. Tell me, > said emu system daemon knows the uid/pid of the opener of the device. > Presumably this emu system daemon would pass the file descriptor to > the appropriate PA instance. How about that? (I tried to ask a few > times but you never really answered) In order to identify the correct PA session instance you would look at $XDG_SESSION_COOKIE in the environment (/proc/pid/environ) for the caller. Or, more portable, make a D-Bus call to ConsoleKit to get this given the pid. Of course, this means that PA needs to be changed to name it's sockets using the Session name (not the cookie!) instead of the username. But that change is easy. And for now GNOME (probably not KDE either) support multiple logins by the same user on the same box. But that's something we want to fix eventually. Hope this helps. David From davidz at redhat.com Tue Feb 27 21:09:01 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 16:09:01 -0500 Subject: PulseAudio In-Reply-To: <1172610463.5097.126.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <939dd5750702271241g7e1c6fbegc5927907720fc4d5@mail.gmail.com> <806dafc20702271244k22ff58d7u22d25b94616e1c5e@mail.gmail.com> <1172610463.5097.126.camel@zelda.fubar.dk> Message-ID: <1172610541.5097.128.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 16:07 -0500, David Zeuthen wrote: > On Tue, 2007-02-27 at 15:44 -0500, xiphmont at xiph.org wrote: > > On 2/27/07, William Jon McCann wrote: > > > Hi Monty, > > > > > > On 2/27/07, xiphmont at xiph.org wrote: > > > > An earlier question still stands, and it is central: does UID == > > > > console session ID? > > > > > > To me, this is very much like asking "Does UID == $DISPLAY"? And the > > > answer of course is - not in general. > > > > I am asking so that the answer is a documented-- and thought about-- > > instead of being a nebulous assumption. For one, it will be difficult > > to have true session-unique emulation support because those interfaces > > used /dev permissions with no concept of session, only uid and gid. > > If the emu system daemon runs as root you, then /dev/dsp and friends > would only need to be accessible by root assuming the emu system daemon > passes the fd to the PA instances. Eh, scrap that. We'd need to put ACL's on them anyway. The emu daemon would do additional checking though. David From xiphmont at xiph.org Tue Feb 27 21:13:30 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 16:13:30 -0500 Subject: PulseAudio In-Reply-To: <1172610082.5097.119.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> Message-ID: <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> > It's fine being a system daemon if it's a pure mechanism. Tell me, said > emu system daemon knows the uid/pid of the opener of the device. Yes. > Presumably this emu system daemon would pass the file descriptor to the > appropriate PA instance. How about that? (I tried to ask a few times but > you never really answered) That's orthogonal to the argument of system pulse vs. session pulse-- but yes it could talk to pulse either way. It would not be passing an fd (it's using shared mem), but that's an implementation aside. > > Many applications of sound are more appliance-like than > > application-like. A session daemon is all fine and good until the > > applicance has its appliance disappear. The session daemon approach > > does not allow even the possibility of appliance-like sound > > applications. > > Either > > - tell them to startup Pulse themselves; or better > - we automatically launch Pulse when needed (through libasound or > the system emulation daemon) Either would be incompatable with the desktop arrangement; you've set up a situation where serious audio software would be inherently at least partially incompatable with working on a Gnome desktop. Or we'd have to implement both-- a system Pulse for 'appliance' applications that implements auth, etc, anyway, and a coordinated cloud of session pulses. Of course, since they're not really sharing-- one pulse can have the sound devices at a time-- the appliance pulse would lock out the others. > We'll have the pop whenever we want to suspend the audio hardware and we > do want to do that in the default install for laptops anyway. We can suspend Pulse without suspending the hardware, BTW... the kernel drivers will take care of pushing silence... > Because > saving power is very important and may in the future be a requirement to > sell to governments. Sure and there are cases where we do want the full-blown suspension. Does that mean we mandate the lowest common denominator? Most people will not want the popping. > Besides, your assumption that the sound card will be switched off/on > during session switch (and cause a pop) is utterly wrong - the kernel > driver for the hardware would of course only suspend the sound card > after N seconds of no openers. Demonstrably incorrect. > > An earlier question still stands, and it is central: does UID == > > console session ID? > > Nope. How do you regulate /dev access? A user logged in twice would hand both sessions full access. Monty From davidz at redhat.com Tue Feb 27 21:38:53 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 16:38:53 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> Message-ID: <1172612334.5097.150.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 16:13 -0500, xiphmont at xiph.org wrote: > > Presumably this emu system daemon would pass the file descriptor to the > > appropriate PA instance. How about that? (I tried to ask a few times but > > you never really answered) > > That's orthogonal to the argument of system pulse vs. session pulse-- Not really. We're arguing what's best to do - either a system or session PA and this demonstrates that OSS compat has nothing to do with that. > but yes it could talk to pulse either way. It would not be passing an > fd (it's using shared mem), but that's an implementation aside. Right. > > > Many applications of sound are more appliance-like than > > > application-like. A session daemon is all fine and good until the > > > applicance has its appliance disappear. The session daemon approach > > > does not allow even the possibility of appliance-like sound > > > applications. > > > > Either > > > > - tell them to startup Pulse themselves; or better > > - we automatically launch Pulse when needed (through libasound or > > the system emulation daemon) > > Either would be incompatable with the desktop arrangement; you've set > up a situation where serious audio software would be inherently at > least partially incompatable with working on a Gnome desktop. > > Or we'd have to implement both-- a system Pulse for 'appliance' > applications that implements auth, etc, anyway, and a coordinated > cloud of session pulses. I think if you building an appliance - it's not too much work to start another instance of PA; if this can be done on-demand (as you didn't argue it couldn't) then it's all automatic - your appliance would probably run unprivileged (See: flumotion) > Of course, since they're not really > sharing-- one pulse can have the sound devices at a time-- the > appliance pulse would lock out the others. I think ideally we'd have a system-wide daemon that all per-session PA's connect to which does mixing and handling emulation devices. Perhaps, for you, that is PA (with few modules loaded) and we're talking about the same thing. Such a thing would be ConsoleKit aware, e.g. it would enforce (tweakable) policy such as muting inactive sessions. Still, I _do_ want PA in my session so I can do all the "compiz for sound" things (settings) and, in particular, I don't want other users to be able to tweak my streams (security). > > We'll have the pop whenever we want to suspend the audio hardware and we > > do want to do that in the default install for laptops anyway. > > We can suspend Pulse without suspending the hardware, BTW... the > kernel drivers will take care of pushing silence... Yea, but the chip is powered up and eating battery as long as someone has the device file open - the kernel driver has no chance to know it's silence and it shouldn't. (actually some drivers power down parts of the chip depending on whether capture/playback device files are open.) > > Because > > saving power is very important and may in the future be a requirement to > > sell to governments. > > Sure and there are cases where we do want the full-blown suspension. > Does that mean we mandate the lowest common denominator? Most people > will not want the popping. I think it's a user preference really. We have this thing in g-p-m to tweak this desktop-wide preference http://people.freedesktop.org/~david/g-p-m-prefer-power-savings.png (for some reason this is not in Rawhide - I'll investigate) (actually these are two settings; one for when running on battery that defaults to TRUE; one is for running on AC which defaults to FALSE. Which I think is sane). but perhaps Pulse itself could offer a setting whether to use the desktop-wide setting or the user could specify a timeout. My point being, it's a user setting. If the user says "never turn off sound card when there is silence" (by some setting) then the in-session PA just streams silence to the system-wide daemon or kernel driver. > > Besides, your assumption that the sound card will be switched off/on > > during session switch (and cause a pop) is utterly wrong - the kernel > > driver for the hardware would of course only suspend the sound card > > after N seconds of no openers. > > Demonstrably incorrect. So I take it you can point to a kernel driver that doesn't wait N seconds. Return to dealer :-) - more seriously, you do know that runtime power management isn't really set in stone in the Linux kernel yes? Anyway, the point is that this is the behavior we want, don't you agree? > > > An earlier question still stands, and it is central: does UID == > > > console session ID? > > > > Nope. > > How do you regulate /dev access? Access in Linux is per-user/per-group and that's hard to change. The $XDG_SESSION_COOKIE thing is simply a way for a system-wide process to identify what desktop session a process belongs to. It isn't used to enforce any security whatsoever. > A user logged in twice would hand > both sessions full access. Yup. David From davidz at redhat.com Tue Feb 27 21:42:48 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 16:42:48 -0500 Subject: PulseAudio In-Reply-To: <1172612334.5097.150.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> Message-ID: <1172612568.5097.153.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 16:38 -0500, David Zeuthen wrote: > > A user logged in twice would hand > > both sessions full access. > > Yup. Well actually, the answer here is: it depends. For things like multi-seat you probably assign one sound card soundA to seat1 and another sound card soundB to seat2. So if user is logged in twice at seat1 he still don't have access to soundB. David From xiphmont at xiph.org Tue Feb 27 21:56:12 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 16:56:12 -0500 Subject: PulseAudio In-Reply-To: <1172612334.5097.150.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> Message-ID: <806dafc20702271356s69f070c8ofefe328853a0cbdf@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > On Tue, 2007-02-27 at 16:13 -0500, xiphmont at xiph.org wrote: > > > Presumably this emu system daemon would pass the file descriptor to the > > > appropriate PA instance. How about that? (I tried to ask a few times but > > > you never really answered) > > > > That's orthogonal to the argument of system pulse vs. session pulse-- > > Not really. We're arguing what's best to do - either a system or session > PA and this demonstrates that OSS compat has nothing to do with that. I meant technically orthogonal. It can be done regardless of session vs. system. > I think ideally we'd have a system-wide daemon that all per-session PA's > connect to which does mixing and handling emulation devices. Perhaps, > for you, that is PA (with few modules loaded) and we're talking about > the same thing. Such a thing would be ConsoleKit aware, e.g. it would > enforce (tweakable) policy such as muting inactive sessions. Ah, so it boils down to a semantic argument... yes, that 'system daemon' is what I am calling Pulse Audio, in that it will have most of the actual mechanism in it. > Still, I _do_ want PA in my session so I can do all the "compiz for > sound" things (settings) and, in particular, I don't want other users to > be able to tweak my streams (security). We could do it that way, the worry is the latency/complexity introduced by the sound stream having to touch too many hands/endure extra context switches before making it to the actual hardware. We are talking about, for the most part, the same conceptual abstractions, but I'm talking about them all existing in the same process space. A 'system' pulse must, at a very minimum, exhibit full session personalities/awareness to the apps. We're not arguing at all about the end-functionality in this case. > Yea, but the chip is powered up and eating battery as long as someone > has the device file open - the kernel driver has no chance to know it's > silence and it shouldn't. (actually some drivers power down parts of the > chip depending on whether capture/playback device files are open.) Actually, the driver *does* know it's silence because of the way the transactions are handled by ALSA; if the device is open and no app is feeding data, ALSA can be told to supply silence (or hold last value, or an y number of things). As for 'eating power', if it's a hundred mA, I fully agree with you. If it's 10mA, I'm less sure. If it's a mA or less, I laugh at your requirements unless it's OLPC :-) > I think it's a user preference really. We have this thing in g-p-m to > tweak this desktop-wide preference I know it's fashonable to make this a session preference, but it isn't really. This is a decision it makes more sense to give to root. But I don't care enough to argue. > but perhaps Pulse itself could offer a setting whether to use the > desktop-wide setting or the user could specify a timeout. Well, I argue for it being a system (not desktop) setting as it has to do with a system resource. But enh. > My point being, it's a user setting. If the user says "never turn off > sound card when there is silence" (by some setting) then the in-session > PA just streams silence to the system-wide daemon or kernel driver. ..and what happens during the transition? It depends on the settings of each user combined....? > So I take it you can point to a kernel driver that doesn't wait N > seconds. Return to dealer :-) None of the USB sound cards wait, because USB shuts them down immediately upon last transaction finishing. For other cards, it's by driver and they're not consistent. > more seriously, you do know that runtime > power management isn't really set in stone in the Linux kernel yes? I know, never was. Brand new system every three years.... My thinkpad could suspend properly in 2004 :-( > Anyway, the point is that this is the behavior we want, don't you agree? I'd opt toward 'smoothest behavior in all cases' unless demostrated that a powered sound chip is causing measurable drain. That's not an argument against full options being available regardless. > > A user logged in twice would hand > > both sessions full access. > > Yup. Oh, well if that's an accepted part of the design, my work is easier. Monty From xiphmont at xiph.org Tue Feb 27 21:57:16 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 16:57:16 -0500 Subject: PulseAudio In-Reply-To: <1172612568.5097.153.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> <1172612568.5097.153.camel@zelda.fubar.dk> Message-ID: <806dafc20702271357g482a0e0v3c508190f52adb9a@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > On Tue, 2007-02-27 at 16:38 -0500, David Zeuthen wrote: > > > A user logged in twice would hand > > > both sessions full access. > > > > Yup. > > Well actually, the answer here is: it depends. For things like > multi-seat you probably assign one sound card soundA to seat1 and > another sound card soundB to seat2. So if user is logged in twice at > seat1 he still don't have access to soundB. I know you didn't *say* LTSP.... But seriously, how is that currently done with, say, two webcams? Monty From davidz at redhat.com Tue Feb 27 22:26:42 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 17:26:42 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271356s69f070c8ofefe328853a0cbdf@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> <806dafc20702271356s69f070c8ofefe328853a0cbdf@mail.gmail.com> Message-ID: <1172615202.5097.181.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 16:56 -0500, xiphmont at xiph.org wrote: > > I think it's a user preference really. We have this thing in g-p-m to > > tweak this desktop-wide preference > > I know it's fashonable to make this a session preference, but it isn't > really. This is a decision it makes more sense to give to root. But I > don't care enough to argue. That's the same as saying it's also root's choice what screen resolution you run your monitor at (sadly, that's partly true today - you can't make it larger until we get xrandr 1.2) or when you decide it's ok for the system to suspend. Sure, these are system resources, in a OS architecture sense, but keep in mind there's a user in front of the system. Alice and probably 95% of all users don't care about the pop. Bob (and Bob don't know anything about Linux nor what a configuration file even is) and Monty does so we give them an easy way to fix this. > ..and what happens during the transition? It depends on the settings > of each user combined....? For a single seat machine it depends on the user whose session is active. For multi seat, it's more complicated. > > Anyway, the point is that this is the behavior we want, don't you agree? > > I'd opt toward 'smoothest behavior in all cases' unless demostrated > that a powered sound chip is causing measurable drain. That's not an > argument against full options being available regardless. Every single watt counts. Ever wondered why you get less battery run-time when running Linux? All this talk about a system-wide PulseAudio sounds interesting but from what I've seen in the Fedora repositories this is a bit from what we've got today. In particular I'm concerned about labeling streams etc. from different users and ensuring they can't interfere with each other. It would be really good with a mail going into technical details about this. Thanks. David From xiphmont at xiph.org Tue Feb 27 22:32:00 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Tue, 27 Feb 2007 17:32:00 -0500 Subject: PulseAudio In-Reply-To: <1172615202.5097.181.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> <806dafc20702271356s69f070c8ofefe328853a0cbdf@mail.gmail.com> <1172615202.5097.181.camel@zelda.fubar.dk> Message-ID: <806dafc20702271432x3d7d3768i4f1b4187bda4e4d6@mail.gmail.com> On 2/27/07, David Zeuthen wrote: > Every single watt counts. Ever wondered why you get less battery > run-time when running Linux? If we are talking about a watt. Or a milliwatt. What if we're talking about 100uWatt? Is it worth it then? Again, those USB sound devices are on the touchy side and a notebook is even more likely to be using one... > All this talk about a system-wide PulseAudio sounds interesting but from > what I've seen in the Fedora repositories this is a bit from what we've > got today. In particular I'm concerned about labeling streams etc. from > different users and ensuring they can't interfere with each other. It > would be really good with a mail going into technical details about > this. Thanks. Well, it would be on the Wiki if I actually had any edit permissions, which I don't... Monty From davidz at redhat.com Tue Feb 27 22:33:31 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 27 Feb 2007 17:33:31 -0500 Subject: PulseAudio In-Reply-To: <806dafc20702271357g482a0e0v3c508190f52adb9a@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> <1172612568.5097.153.camel@zelda.fubar.dk> <806dafc20702271357g482a0e0v3c508190f52adb9a@mail.gmail.com> Message-ID: <1172615611.5097.188.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 16:57 -0500, xiphmont at xiph.org wrote: > On 2/27/07, David Zeuthen wrote: > > On Tue, 2007-02-27 at 16:38 -0500, David Zeuthen wrote: > > > > A user logged in twice would hand > > > > both sessions full access. > > > > > > Yup. > > > > Well actually, the answer here is: it depends. For things like > > multi-seat you probably assign one sound card soundA to seat1 and > > another sound card soundB to seat2. So if user is logged in twice at > > seat1 he still don't have access to soundB. > > I know you didn't *say* LTSP.... Some estimates out there put GNOME on LTSP as having double-digits market shares of all GNOME deployments. IIRC about 37%. I don't have any links to back this up right now though. It's kinda funny, you're very defensive about keeping compat etc, but seem to ignore "pet projects" like f-u-s, multi-seat and LTSP... anyway... > But seriously, how is that currently done with, say, two webcams? ConsoleKit knows about Sessions and Seats. HAL will assign ACL's based on this. It needs a bit more work (definition of seats and what devices belongs to what seats etc.) so not going to happen for F7. There's also the X.org and Linux VT subsystem to keep in mind. But it's not really hard. FWIW, it came up last week on GNOME's desktop-devel-list http://mail.gnome.org/archives/desktop-devel-list/2007-February/msg00290.html http://mail.gnome.org/archives/desktop-devel-list/2007-February/msg00291.html David From sundaram at fedoraproject.org Tue Feb 27 22:44:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Feb 2007 04:14:04 +0530 Subject: PulseAudio In-Reply-To: <806dafc20702271432x3d7d3768i4f1b4187bda4e4d6@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> <806dafc20702271356s69f070c8ofefe328853a0cbdf@mail.gmail.com> <1172615202.5097.181.camel@zelda.fubar.dk> <806dafc20702271432x3d7d3768i4f1b4187bda4e4d6@mail.gmail.com> Message-ID: <45E4B434.6040409@fedoraproject.org> xiphmont at xiph.org wrote: > Well, it would be on the Wiki if I actually had any edit permissions, > which I don't... Take a look at http://fedoraproject.org/wiki/WikiEditing for that. Rahul From nicolas.mailhot at laposte.net Wed Feb 28 06:28:30 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Feb 2007 07:28:30 +0100 Subject: PulseAudio In-Reply-To: <1172605261.5097.83.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <1172604781.11172.16.camel@rousalka.dyndns.org> <1172605261.5097.83.camel@zelda.fubar.dk> Message-ID: <1172644110.27148.23.camel@rousalka.dyndns.org> Le mardi 27 f?vrier 2007 ? 14:41 -0500, David Zeuthen a ?crit : > On Tue, 2007-02-27 at 20:33 +0100, Nicolas Mailhot wrote: > > Le mardi 27 f?vrier 2007 ? 13:20 -0500, David Zeuthen a ?crit : > > > > > So it's like this. For *modern* Linux desktop we've been moving > > > functionality from system-wide daemons into per-session daemons *simply* > > > because system-wide daemons have a number of problems. > > > > Per-session daemons may be nice for stuff that does not require > > exclusive access, to manage hardware they're a disaster. I don't want to > > log in at midnight so my GUI recording software is authorised to access > > the tuner card, wireless link should not go down at user logout, power > > management should happen even on a mostly headless system, etc > > I already answered your question re device permissions here > > https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00713.html Oh, seems this one was eaten by a spam filter It's a bit more complex than that, a tuner won't record more than one channel at a time, so you need something between the hardware and the GUI frontends to warn some other user already booked a timespan. You know, like cups managing one system access to its printers (shock! system-wide-daemon for desktop use) Also with DVI and friends the video part may depend on a dedicated card but the audio just use one audio input of the motherboard/audio card. I suspect if ever the "drop hardware access to non-active sessions" stuff is implemented people will find lots of other examples where hardware access lifetime and gui session lifetime do not map (even for desktop-related tasks). Linux desktop needs are far bigger than sunray needs. And even without taking hardware into account, mail processing (spam filtering, etc) should happen in the background without needing to keep a GUI session with a MUA running. People hate the "log in the morning, watch evo struggle with mail received in the night" syndrome. Home/SOHO desktop should be like a VCR : you schedule evenemential/periodic tasks, they just happen even when you're doing non-computer stuff, and the results are ready when you log in. You don't ever switch off the computer it goes in low-power modes as needed without manual intervention. The only system for which it's not true is on-battery roaming laptop, which is not the general case (the laptops sales may have skyrocketed, but the bulk of home users don't roam and let their laptop always-on on the computer table of the house) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mcepl at redhat.com Wed Feb 28 09:37:26 2007 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 28 Feb 2007 09:37:26 +0000 (UTC) Subject: PulseAudio References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> Message-ID: David Zeuthen scripst: >> Replace OSS with ALSA; the point still stands and perhaps you can >> identify more with it. > > No, it's fine, apps use libasound and there's a plug-in for Pulse. OK, make Ekiga work together with Rhythmbox playing in the background (both from FC6) and then tell me how fine it is. Mat?j -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Only two of my personalities are schizophrenic, but one of them is paranoid and the other one is out to get him. From davidz at redhat.com Wed Feb 28 16:38:57 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 28 Feb 2007 11:38:57 -0500 Subject: PulseAudio In-Reply-To: <1172644110.27148.23.camel@rousalka.dyndns.org> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <1172604781.11172.16.camel@rousalka.dyndns.org> <1172605261.5097.83.camel@zelda.fubar.dk> <1172644110.27148.23.camel@rousalka.dyndns.org> Message-ID: <1172680737.2604.22.camel@zelda.fubar.dk> On Wed, 2007-02-28 at 07:28 +0100, Nicolas Mailhot wrote: > It's a bit more complex than that, a tuner won't record more than one > channel at a time, so you need something between the hardware and the > GUI frontends to warn some other user already booked a timespan. You > know, like cups managing one system access to its printers (shock! > system-wide-daemon for desktop use) First I was going to say that 1) v4l devices are exclusive-openers; and 2) use O_EXCL for other kinds of devices. But then I realized you're talking about a PVR getting ready to capture a recording in the future. So, sure, you could have some system-wide mechanism for obtaining exclusive access to the hardware that, in the process, would use revoke() to kick out other openers already hogging the device. That's something I've been wanting to put in HAL anyway (since HAL is just a mechanism); it's probably the right place since ACL is managing your permissions. Then your conceived[1] example of a PVR appliance would just work; it would - You're capturing video in your login session (uid=500) - you're tuned into channel 825 - Time passes - PVR appliance decides it wants to record BSG for you. Bummer, that's on channel 62 and, rats, someone is hogging the device files - PVR user (uid=501) calls into system-wide mechanism to get exclusive access on /dev/video0 and /dev/dsp - System-wide mechanism removes ACL's on /dev/video0, /dev/dsp for uid 500 (it keeps ACL's for uid 501 because that's what the caller of of GetExclusiveAccess() has) - System-wide mechanism revoke()'s access to /dev/foo, /dev/bar for uid 500. Your TV capture app in the session hopefully doesn't crash because access is revoked. Today it probably would :-) - System-wide mechanism returns to PVR user in response to the GetExclusiveAccess() call. - PVR appliance now have exclusive access, opens the devices and records your show - Time passes. Disks are spinning. - PVR appliance is done recording. It calls into ReleaseExclusiveAccess() and the system-wide mechanism reconfigures the ACL's. uid 500 can now access the devices again. - Perhaps the video capture thing in the session for uid=500 starts showing something again. Perhaps the kernel should have an option to open(2), say, heh, O_EXCL_AND_KICK_OTHER_OPENERES that does this but all this involves a policy decision (is uid 501 really privileged to do such a powerful operation? The kernel just don't know...) and ACL management. I'll think a bit more about this; we need to get the interface right.. anyway, thanks for bringing this to my attention. [1] : actually I bet the example is not so conceived > Also with DVI and friends the video part may depend on a dedicated card > but the audio just use one audio input of the motherboard/audio card. That's just device access again - I hope with Keith's and others work on that the kernel will, in the future, finally export device files (for GPU's, CRTC's and monitors [2]) so we can manage permissions on them like any other device. Then, you know, we can also run the X server as an unprivileged process. Wouldn't that be something? :-) Lesson here is that multi-user is *hard*. Doesn't mean it's not fixable. It does require that apps adapt and use new infrastructure to learn about the environment in which they're running. That's not different from Windows or Mac OS X - many apps there don't work properly with multi-user simply because the app developer didn't write his app with this in mind. David [2] : Hope I got that right From xiphmont at xiph.org Wed Feb 28 17:43:27 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Wed, 28 Feb 2007 12:43:27 -0500 Subject: PulseAudio In-Reply-To: References: <1172596006.13777.30.camel@cookie.hadess.net> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <806dafc20702271104x539d8ef7x6fb98394ab9a44cb@mail.gmail.com> <1172603693.5097.72.camel@zelda.fubar.dk> <806dafc20702271201y19146f9aq8a6e017025e96cba@mail.gmail.com> <1172607056.5097.97.camel@zelda.fubar.dk> Message-ID: <806dafc20702280943wb345b30yec7b648a8fde568@mail.gmail.com> On 2/28/07, Matej Cepl wrote: > David Zeuthen scripst: > >> Replace OSS with ALSA; the point still stands and perhaps you can > >> identify more with it. > > > > No, it's fine, apps use libasound and there's a plug-in for Pulse. > > OK, make Ekiga work together with Rhythmbox playing in the background > (both from FC6) and then tell me how fine it is. That's exactly the point, it does work (at least, it's supposed to. if it doesn't work, then I will *make* it work). Monty From abo at kth.se Wed Feb 28 18:41:56 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 28 Feb 2007 19:41:56 +0100 Subject: PulseAudio In-Reply-To: <1172602197.5097.57.camel@zelda.fubar.dk> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> Message-ID: <1172688116.30113.45.camel@home.alexander.bostrom.net> tis 2007-02-27 klockan 13:49 -0500 skrev David Zeuthen: > That's only because PA decides to open the device directly and haven't > been taught to give it up on session inactivity. That's not hard to > change and it's the right thing to do *anyway* since we probably want a > default policy where audio is muted from inactive sessions just like > video is muted. Ok, so what are the problems with a really naive solution like this: When a session is swapped out from a console, some system daemon revokes the ACL:s and signals the user PulseAudio daemon to give up the device. If it doesn't comply, more force will probably have to be used. (Timeouts in user interfaces suck though.) It could be as simple as sending SIGHUP/SIGUSR1, SIGTERM and SIGKILL to whatever process is currently hogging the device. Or use D-Bus instead of SIGHUP, since that would allow for specifying exactly what devices needs to be released. /abo From xiphmont at xiph.org Wed Feb 28 18:55:11 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Wed, 28 Feb 2007 13:55:11 -0500 Subject: PulseAudio In-Reply-To: <1172688116.30113.45.camel@home.alexander.bostrom.net> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <1172688116.30113.45.camel@home.alexander.bostrom.net> Message-ID: <806dafc20702281055k60ebec9fy9abf22da789d4402@mail.gmail.com> On 2/28/07, Alexander Bostr?m wrote: > tis 2007-02-27 klockan 13:49 -0500 skrev David Zeuthen: > > > That's only because PA decides to open the device directly and haven't > > been taught to give it up on session inactivity. That's not hard to > > change and it's the right thing to do *anyway* since we probably want a > > default policy where audio is muted from inactive sessions just like > > video is muted. > > Ok, so what are the problems with a really naive solution like this: > > When a session is swapped out from a console, some system daemon revokes > the ACL:s and signals the user PulseAudio daemon to give up the device. > If it doesn't comply, more force will probably have to be used. > (Timeouts in user interfaces suck though.) > > It could be as simple as sending SIGHUP/SIGUSR1, SIGTERM and SIGKILL to > whatever process is currently hogging the device. Or use D-Bus instead > of SIGHUP, since that would allow for specifying exactly what devices > needs to be released. This viloates the tenent of 'fast user switching does not lose state'. Switching to the other login should not cause, eg, Audacity which is holding an hour of unsaved editing work to crash or get killed. Monty From abo at kth.se Wed Feb 28 19:00:47 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 28 Feb 2007 20:00:47 +0100 Subject: PulseAudio In-Reply-To: <806dafc20702281055k60ebec9fy9abf22da789d4402@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <1172688116.30113.45.camel@home.alexander.bostrom.net> <806dafc20702281055k60ebec9fy9abf22da789d4402@mail.gmail.com> Message-ID: <1172689247.30113.49.camel@home.alexander.bostrom.net> ons 2007-02-28 klockan 13:55 -0500 skrev xiphmont at xiph.org: > This viloates the tenent of 'fast user switching does not lose state'. > Switching to the other login should not cause, eg, Audacity which is > holding an hour of unsaved editing work to crash or get killed. It does, yes. Then how about just sending a signal through D-Bus and hoping it isn't ignored? We'll be ridiculed for having a cooperatively multisessioning desktop though. :) /abo From davidz at redhat.com Wed Feb 28 19:02:23 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 28 Feb 2007 14:02:23 -0500 Subject: PulseAudio In-Reply-To: <1172688116.30113.45.camel@home.alexander.bostrom.net> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <1172688116.30113.45.camel@home.alexander.bostrom.net> Message-ID: <1172689343.2604.72.camel@zelda.fubar.dk> On Wed, 2007-02-28 at 19:41 +0100, Alexander Bostr?m wrote: > tis 2007-02-27 klockan 13:49 -0500 skrev David Zeuthen: > > > That's only because PA decides to open the device directly and haven't > > been taught to give it up on session inactivity. That's not hard to > > change and it's the right thing to do *anyway* since we probably want a > > default policy where audio is muted from inactive sessions just like > > video is muted. > > Ok, so what are the problems with a really naive solution like this: > > When a session is swapped out from a console, some system daemon revokes > the ACL:s HAL can do this (it's a one-line change) and probably will depending on a few things. To do this, HAL listens to ConsoleKit on the system message bus. > and signals the user PulseAudio daemon to give up the device. > If it doesn't comply, more force will probably have to be used. > (Timeouts in user interfaces suck though.) If PA is running in the session, it could listen to ConsoleKit on the system message bus. That's actually what I proposed. David From xiphmont at xiph.org Wed Feb 28 19:03:44 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Wed, 28 Feb 2007 14:03:44 -0500 Subject: PulseAudio In-Reply-To: <1172689247.30113.49.camel@home.alexander.bostrom.net> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172597029.5097.10.camel@zelda.fubar.dk> <806dafc20702271004i451bc6a9x8aac6c53d7913fa2@mail.gmail.com> <1172600417.5097.36.camel@zelda.fubar.dk> <806dafc20702271028m6d626d58s7d3e36111e945100@mail.gmail.com> <1172602197.5097.57.camel@zelda.fubar.dk> <1172688116.30113.45.camel@home.alexander.bostrom.net> <806dafc20702281055k60ebec9fy9abf22da789d4402@mail.gmail.com> <1172689247.30113.49.camel@home.alexander.bostrom.net> Message-ID: <806dafc20702281103w4c6fb944obc0688ddd5d4264c@mail.gmail.com> On 2/28/07, Alexander Bostr?m wrote: > ons 2007-02-28 klockan 13:55 -0500 skrev xiphmont at xiph.org: > > > This viloates the tenent of 'fast user switching does not lose state'. > > Switching to the other login should not cause, eg, Audacity which is > > holding an hour of unsaved editing work to crash or get killed. > > It does, yes. > > Then how about just sending a signal through D-Bus and hoping it isn't > ignored? We'll be ridiculed for having a cooperatively multisessioning > desktop though. :) Well, the idea is that the Pulse (be it session or system) doesn't die or get killed and applications running on the desktop are generally unaware anything changed w.r.t sound-- the Pulse mutes their streams, sample and playback get zeroed. The Pulse server, of course, will be 'cooperating', but trusted system software is allowed to be cooperative without being mocked. Monty From xiphmont at xiph.org Wed Feb 28 20:11:09 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Wed, 28 Feb 2007 15:11:09 -0500 Subject: PulseAudio In-Reply-To: <45E4B434.6040409@fedoraproject.org> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> <806dafc20702271356s69f070c8ofefe328853a0cbdf@mail.gmail.com> <1172615202.5097.181.camel@zelda.fubar.dk> <806dafc20702271432x3d7d3768i4f1b4187bda4e4d6@mail.gmail.com> <45E4B434.6040409@fedoraproject.org> Message-ID: <806dafc20702281211v347e43e5yd089e5e5a7c5bad9@mail.gmail.com> On 2/27/07, Rahul Sundaram wrote: > xiphmont at xiph.org wrote: > > > Well, it would be on the Wiki if I actually had any edit permissions, > > which I don't... > > Take a look at http://fedoraproject.org/wiki/WikiEditing for that. I mean, I *should* have editing access, I've supposedly been given edit access, but I don't have edit access. Monty From sundaram at fedoraproject.org Wed Feb 28 20:21:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 01 Mar 2007 01:51:32 +0530 Subject: PulseAudio In-Reply-To: <806dafc20702281211v347e43e5yd089e5e5a7c5bad9@mail.gmail.com> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172607056.5097.97.camel@zelda.fubar.dk> <806dafc20702271232v5acec30cob694461fbb32037a@mail.gmail.com> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> <806dafc20702271356s69f070c8ofefe328853a0cbdf@mail.gmail.com> <1172615202.5097.181.camel@zelda.fubar.dk> <806dafc20702271432x3d7d3768i4f1b4187bda4e4d6@mail.gmail.com> <45E4B434.6040409@fedoraproject.org> <806dafc20702281211v347e43e5yd089e5e5a7c5bad9@mail.gmail.com> Message-ID: <45E5E44C.6080907@fedoraproject.org> xiphmont at xiph.org wrote: > On 2/27/07, Rahul Sundaram wrote: >> xiphmont at xiph.org wrote: >> >> > Well, it would be on the Wiki if I actually had any edit permissions, >> > which I don't... >> >> Take a look at http://fedoraproject.org/wiki/WikiEditing for that. > > I mean, I *should* have editing access, I've supposedly been given > edit access, but I don't have edit access. I see the user name Christopher Montgomery has been added to the edit group recently by Ray Strode. Your profile page is http://fedoraproject.org/wiki/ChristopherMontgomery. Can you please login with this user name and check if you are still not able to edit wiki pages? Rahul From xiphmont at xiph.org Wed Feb 28 20:31:15 2007 From: xiphmont at xiph.org (xiphmont at xiph.org) Date: Wed, 28 Feb 2007 15:31:15 -0500 Subject: PulseAudio In-Reply-To: <45E5E44C.6080907@fedoraproject.org> References: <1172596006.13777.30.camel@cookie.hadess.net> <1172610082.5097.119.camel@zelda.fubar.dk> <806dafc20702271313h3b56049drc12950057c9a5088@mail.gmail.com> <1172612334.5097.150.camel@zelda.fubar.dk> <806dafc20702271356s69f070c8ofefe328853a0cbdf@mail.gmail.com> <1172615202.5097.181.camel@zelda.fubar.dk> <806dafc20702271432x3d7d3768i4f1b4187bda4e4d6@mail.gmail.com> <45E4B434.6040409@fedoraproject.org> <806dafc20702281211v347e43e5yd089e5e5a7c5bad9@mail.gmail.com> <45E5E44C.6080907@fedoraproject.org> Message-ID: <806dafc20702281231q74d6f969oa190d952c2a1a91c@mail.gmail.com> On 2/28/07, Rahul Sundaram wrote: > I see the user name Christopher Montgomery has been added to the edit > group recently by Ray Strode. Your profile page is > http://fedoraproject.org/wiki/ChristopherMontgomery. Can you please > login with this user name and check if you are still not able to edit > wiki pages? I can't. When I attempt to recover a lost password for 'ChristopherMontgomery', the wiki sends me a mail for 'XiphMont' instead. I had assumed the system somehow internally had aliased the two. Monty