From p.vandenberg at personainternet.com Wed Sep 8 17:11:36 2004 From: p.vandenberg at personainternet.com (Paul Vandenberg) Date: Wed, 8 Sep 2004 13:11:36 -0400 (EDT) Subject: GNOME Menu Editing Message-ID: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> Hi, Can anyone tell me if GNOME menu editing will be enabled in FC3? I am really getting tired of editing .desktop files. Thanks...Paul From mknepher at bluethingy.com Wed Sep 8 21:52:58 2004 From: mknepher at bluethingy.com (Michael Knepher) Date: Wed, 08 Sep 2004 14:52:58 -0700 Subject: GNOME Menu Editing In-Reply-To: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> References: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> Message-ID: <1094680378.18708.7.camel@lionel-hutz.darnell.group> On Wed, 2004-09-08 at 13:11 -0400, Paul Vandenberg wrote: > Hi, > > Can anyone tell me if GNOME menu editing will be enabled in FC3? I am > really getting tired of editing .desktop files. It doesn't look like it, and it seems to be a low priority for the GNOME folks. I'm surprised some enterprising hacker hasn't put together a front-end for manipulating the xml menu files. It shouldn't take much more than spit and baling wire ... From p.vandenberg at personainternet.com Thu Sep 9 00:20:06 2004 From: p.vandenberg at personainternet.com (Paul Vandenberg) Date: Wed, 8 Sep 2004 20:20:06 -0400 (EDT) Subject: GNOME Menu Editing In-Reply-To: <1094680378.18708.7.camel@lionel-hutz.darnell.group> References: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> <1094680378.18708.7.camel@lionel-hutz.darnell.group> Message-ID: <1789.66.206.236.217.1094689206.squirrel@webmail.personainternet.com> > On Wed, 2004-09-08 at 13:11 -0400, Paul Vandenberg wrote: >> Hi, >> >> Can anyone tell me if GNOME menu editing will be enabled in FC3? I >> am >> really getting tired of editing .desktop files. > > It doesn't look like it, and it seems to be a low priority for the > GNOME > folks. I'm surprised some enterprising hacker hasn't put together a > front-end for manipulating the xml menu files. It shouldn't take much > more than spit and baling wire ... > > > > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-desktop-list > As far as I know, it was Red Hat that disabled it, not GNOME. In fact, I read that the menu editing was improved in the upcoming GNOME 2.8. I was hoping that this would make Red Hat (Fedora) turn it back on again. It is frustrating that repeated calls for menu editing are falling on deaf ears! If Mandrake wasn't a GNOME release behind, I would consider switching. Paul From veguilla at hpcf.upr.edu Thu Sep 9 01:40:39 2004 From: veguilla at hpcf.upr.edu (Ricardo Veguilla) Date: Wed, 08 Sep 2004 21:40:39 -0400 Subject: GNOME Menu Editing In-Reply-To: <1789.66.206.236.217.1094689206.squirrel@webmail.personainternet.com> References: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> <1094680378.18708.7.camel@lionel-hutz.darnell.group> <1789.66.206.236.217.1094689206.squirrel@webmail.personainternet.com> Message-ID: <1094694040.3654.15.camel@ricardo.veguilla.net> On Wed, 2004-09-08 at 20:20 -0400, Paul Vandenberg wrote: > > As far as I know, it was Red Hat that disabled it, not GNOME. In fact, > I read that the menu editing was improved in the upcoming GNOME 2.8. I > was hoping that this would make Red Hat (Fedora) turn it back on > again. It is frustrating that repeated calls for menu editing are > falling on deaf ears! If Mandrake wasn't a GNOME release behind, I > would consider switching. > > Paul > Well, I don't know whats Fedora (Red Hat... whatever) position regarding menu editing, but if you check the GNOME mailing list archive (http://mail.gnome.org) you will find its true that menu editing isn't a high priority problem for the GNOME team for many valid reasons. Besides, I don't know if the GNOME team was planning to improve menu editing in for the Gnome 2.8, but as far as I can tell (and I'm currently running Gnome 2.7) there is no visible improvement whatsoever. I'm not speaking for the GNOME Developers in any way, this is only my understanding of the situation as a mailing list lurker. -- Ricardo Veguilla From alexl at redhat.com Thu Sep 9 07:20:45 2004 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 09 Sep 2004 09:20:45 +0200 Subject: GNOME Menu Editing In-Reply-To: <1789.66.206.236.217.1094689206.squirrel@webmail.personainternet.com> References: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> <1094680378.18708.7.camel@lionel-hutz.darnell.group> <1789.66.206.236.217.1094689206.squirrel@webmail.personainternet.com> Message-ID: <1094714445.25251.116.camel@greebo.homeip.net> On Wed, 2004-09-08 at 20:20 -0400, Paul Vandenberg wrote: > As far as I know, it was Red Hat that disabled it, not GNOME. In fact, > I read that the menu editing was improved in the upcoming GNOME 2.8. I > was hoping that this would make Red Hat (Fedora) turn it back on > again. It is frustrating that repeated calls for menu editing are > falling on deaf ears! If Mandrake wasn't a GNOME release behind, I > would consider switching. Some time during the Gnome 2.8 cycle was spent on the menu system backend itself, making it use a shared freedesktop.org specification, but as yet there is no menu editor. The reason the upstream vfolder "menu editing" is disabled is that its very unstable and crashes a lot. There will be some changes to the way the panel handles menus in Gnome 2.10, and hopefully we'll get a sane menu editor by then. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an otherworldly drug-addicted inventor plagued by the memory of his family's brutal murder. She's a brilliant green-skinned pearl diver who hides her beauty behind a pair of thick-framed spectacles. They fight crime! From dcbw at redhat.com Thu Sep 9 11:55:43 2004 From: dcbw at redhat.com (Dan Williams) Date: Thu, 9 Sep 2004 07:55:43 -0400 (EDT) Subject: GNOME Menu Editing In-Reply-To: <1094680378.18708.7.camel@lionel-hutz.darnell.group> References: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> <1094680378.18708.7.camel@lionel-hutz.darnell.group> Message-ID: Hi, Actual menu editing through the GNOME VFS menu method is not going to be turned on since there are still lots of problems with it. If there is going to be menu editing, then it will be with, as Michael suggests here, an app to edit the XML files directly. Dan On Wed, 8 Sep 2004, Michael Knepher wrote: > On Wed, 2004-09-08 at 13:11 -0400, Paul Vandenberg wrote: > > Hi, > > > > Can anyone tell me if GNOME menu editing will be enabled in FC3? I am > > really getting tired of editing .desktop files. > > It doesn't look like it, and it seems to be a low priority for the GNOME > folks. I'm surprised some enterprising hacker hasn't put together a > front-end for manipulating the xml menu files. It shouldn't take much > more than spit and baling wire ... > > > > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-desktop-list > From p.vandenberg at personainternet.com Thu Sep 9 13:09:11 2004 From: p.vandenberg at personainternet.com (Paul Vandenberg) Date: Thu, 9 Sep 2004 09:09:11 -0400 (EDT) Subject: GNOME Menu Editing In-Reply-To: References: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com><1094680378.18708.7.camel@lionel-hutz.darnell.group> Message-ID: <27984.192.26.212.72.1094735351.squirrel@webmail.personainternet.com> > Hi, > > Actual menu editing through the GNOME VFS menu method is not going to > be > turned on since there are still lots of problems with it. If there is > going to be menu editing, then it will be with, as Michael suggests > here, > an app to edit the XML files directly. > > Dan > > On Wed, 8 Sep 2004, Michael Knepher wrote: > >> On Wed, 2004-09-08 at 13:11 -0400, Paul Vandenberg wrote: >> > Hi, >> > >> > Can anyone tell me if GNOME menu editing will be enabled in FC3? I >> am >> > really getting tired of editing .desktop files. >> >> It doesn't look like it, and it seems to be a low priority for the >> GNOME >> folks. I'm surprised some enterprising hacker hasn't put together a >> front-end for manipulating the xml menu files. It shouldn't take >> much >> more than spit and baling wire ... >> >> >> >> >> >> -- >> Fedora-desktop-list mailing list >> Fedora-desktop-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-desktop-list >> > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-desktop-list > Well...I've never really done GUI programming. I earn my bread and butter doing mainframe programming. Perhaps, it is time to get my hands dirty and take a stab at it. How hard would it be to create a, "system-config-menu"? Could I use one of the other system-config tools as a model? Paul Thanks...Paul From alexl at redhat.com Thu Sep 9 13:51:44 2004 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 09 Sep 2004 15:51:44 +0200 Subject: User space filesharing Message-ID: <1094737904.25251.195.camel@greebo.homeip.net> In between bugfixes I managed to hack up a pretty cool feature. A program that allows you to easily share files on a network without having to configure anything. Its not production quality yet, and it lacks some UI, but it seems to work. You can get rpms to try it at: http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.i386.rpm http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.src.rpm Just install them and start gnome-user-share, then toggle the /desktop/gnome/file_sharing/enabled key using gconf-editor or gconftool-2. You should get a $HOME/Public directory which is exported via webdav, and it should immediately be visible in the "Network" location in Nautilus 2.7/2.8 on all machines on the local network. Please test it out. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an old-fashioned coffee-fuelled househusband possessed of the uncanny powers of an insect. She's a hard-bitten gypsy widow from a different time and place. They fight crime! From dcbw at redhat.com Thu Sep 9 13:52:47 2004 From: dcbw at redhat.com (Dan Williams) Date: Thu, 09 Sep 2004 09:52:47 -0400 Subject: GNOME Menu Editing In-Reply-To: <27984.192.26.212.72.1094735351.squirrel@webmail.personainternet.com> References: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> <1094680378.18708.7.camel@lionel-hutz.darnell.group> <27984.192.26.212.72.1094735351.squirrel@webmail.personainternet.com> Message-ID: <1094737967.3459.4.camel@dcbw.boston.redhat.com> On Thu, 2004-09-09 at 09:09 -0400, Paul Vandenberg wrote: > Well...I've never really done GUI programming. I earn my bread and > butter doing mainframe programming. Perhaps, it is time to get my > hands dirty and take a stab at it. How hard would it be to create a, > "system-config-menu"? Could I use one of the other system-config tools > as a model? Paul, Such an application would have wider acceptance/use than just Fedora Core, since the menu code that Fedora Core uses will be upstream in GNOME 2.8 (already in KDE). Therefore, whatever application gets written should be targetted at GNOME and not specifically Fedora Core. In any case, it would have to be C/C++ to be accepted into upstream GNOME (as Python, which all the other system-config-* tools are written in, is not an accepted gnome language yet). It wouldn't be a particularly hard application, but there would of course be a lot of XML manipulation involved. Take a look at: http://freedesktop.org/Standards/menu-spec/0.8/ http://www.gnome.org/~calum/usability/specs/menu-edit/ Even if, for the moment, the editor just edited the system menu files and didn't touch the user-specific ones, it would be a win over what we have now. Dan From alexl at redhat.com Thu Sep 9 14:31:06 2004 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 09 Sep 2004 16:31:06 +0200 Subject: User space filesharing In-Reply-To: <1094737904.25251.195.camel@greebo.homeip.net> References: <1094737904.25251.195.camel@greebo.homeip.net> Message-ID: <1094740266.25251.211.camel@greebo.homeip.net> On Thu, 2004-09-09 at 15:51 +0200, Alexander Larsson wrote: > In between bugfixes I managed to hack up a pretty cool feature. A > program that allows you to easily share files on a network without > having to configure anything. Its not production quality yet, and it > lacks some UI, but it seems to work. > > You can get rpms to try it at: > http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.i386.rpm > http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.src.rpm > > Just install them and start gnome-user-share, then toggle > the /desktop/gnome/file_sharing/enabled key using gconf-editor or > gconftool-2. You should get a $HOME/Public directory which is exported > via webdav, and it should immediately be visible in the "Network" > location in Nautilus 2.7/2.8 on all machines on the local network. > > Please test it out. For interesed parties, here is a screenshot of it running as the "gnome" user on my test machine, showing the setting, the Public dir and a share from the "alex" user on my other machine: http://people.redhat.com/alexl/files/user_sharing.png =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an ungodly arachnophobic paramedic in a wheelchair. She's an enchanted thirtysomething queen of the dead living on borrowed time. They fight crime! From tjb at unh.edu Thu Sep 9 14:43:11 2004 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 09 Sep 2004 10:43:11 -0400 Subject: User space filesharing In-Reply-To: <1094737904.25251.195.camel@greebo.homeip.net> References: <1094737904.25251.195.camel@greebo.homeip.net> Message-ID: <1094740991.14698.17.camel@wintermute.sr.unh.edu> On Thu, 2004-09-09 at 15:51 +0200, Alexander Larsson wrote: > In between bugfixes I managed to hack up a pretty cool feature. A > program that allows you to easily share files on a network without > having to configure anything. Its not production quality yet, and it > lacks some UI, but it seems to work. > > You can get rpms to try it at: > http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.i386.rpm > http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.src.rpm > > Just install them and start gnome-user-share, then toggle > the /desktop/gnome/file_sharing/enabled key using gconf-editor or > gconftool-2. You should get a $HOME/Public directory which is exported > via webdav, and it should immediately be visible in the "Network" > location in Nautilus 2.7/2.8 on all machines on the local network. > > Please test it out. The gconf key didn't exist without a log out and log back in. Setting it with gconftool-2 worked though. I can use nautilus to browse it locally (navigating from computer->network->tjb's public files on the same machine that is doing the sharing) but from another machine, the public folder doesn't appear as an entity on the network. I have tcp wrappers locked down so could this be the problem? It works great locally though. tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From alexl at redhat.com Thu Sep 9 15:01:16 2004 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 09 Sep 2004 17:01:16 +0200 Subject: User space filesharing In-Reply-To: <1094740991.14698.17.camel@wintermute.sr.unh.edu> References: <1094737904.25251.195.camel@greebo.homeip.net> <1094740991.14698.17.camel@wintermute.sr.unh.edu> Message-ID: <1094742076.25251.218.camel@greebo.homeip.net> On Thu, 2004-09-09 at 10:43 -0400, Thomas J. Baker wrote: > On Thu, 2004-09-09 at 15:51 +0200, Alexander Larsson wrote: > > In between bugfixes I managed to hack up a pretty cool feature. A > > program that allows you to easily share files on a network without > > having to configure anything. Its not production quality yet, and it > > lacks some UI, but it seems to work. > > > > You can get rpms to try it at: > > http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.i386.rpm > > http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.src.rpm > > > > Just install them and start gnome-user-share, then toggle > > the /desktop/gnome/file_sharing/enabled key using gconf-editor or > > gconftool-2. You should get a $HOME/Public directory which is exported > > via webdav, and it should immediately be visible in the "Network" > > location in Nautilus 2.7/2.8 on all machines on the local network. > > > > Please test it out. > > > The gconf key didn't exist without a log out and log back in. Setting it > with gconftool-2 worked though. I can use nautilus to browse it locally > (navigating from computer->network->tjb's public files on the same > machine that is doing the sharing) but from another machine, the public > folder doesn't appear as an entity on the network. I have tcp wrappers > locked down so could this be the problem? It works great locally though. I'm not sure why it didn't work on the other machine. Did it have nautilus 2.7, and howl installed and mDNSResponder running? Seems to be a problem with rendezvous. Maybe a firewall issue? I'm not sure why installing schemas doesn't trigger reloading them in an already running gconfd. I've seen it happen for other packages, so its a general problem. But it matters little in this case, just set the key to true. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a deeply religious Jewish vampire hunter from a doomed world. She's an artistic gold-digging femme fatale with a birthmark shaped like Liberty's torch. They fight crime! From tjb at unh.edu Thu Sep 9 15:31:36 2004 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 09 Sep 2004 11:31:36 -0400 Subject: User space filesharing In-Reply-To: <1094742076.25251.218.camel@greebo.homeip.net> References: <1094737904.25251.195.camel@greebo.homeip.net> <1094740991.14698.17.camel@wintermute.sr.unh.edu> <1094742076.25251.218.camel@greebo.homeip.net> Message-ID: <1094743896.14698.23.camel@wintermute.sr.unh.edu> On Thu, 2004-09-09 at 17:01 +0200, Alexander Larsson wrote: > > I'm not sure why it didn't work on the other machine. Did it have > nautilus 2.7, and howl installed and mDNSResponder running? Seems to be > a problem with rendezvous. Maybe a firewall issue? > > I'm not sure why installing schemas doesn't trigger reloading them in an > already running gconfd. I've seen it happen for other packages, so its a > general problem. But it matters little in this case, just set the key to > true. I set it up on two systems. They each can see themselves but not each other. Both are up to date rawhide systems. Both can see other rendezvous broadcasting network services (the same two ftp servers). There is no firewall between them (same subnet) and no local firewalls running. tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From alexl at redhat.com Thu Sep 9 15:38:12 2004 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 09 Sep 2004 17:38:12 +0200 Subject: User space filesharing In-Reply-To: <1094743896.14698.23.camel@wintermute.sr.unh.edu> References: <1094737904.25251.195.camel@greebo.homeip.net> <1094740991.14698.17.camel@wintermute.sr.unh.edu> <1094742076.25251.218.camel@greebo.homeip.net> <1094743896.14698.23.camel@wintermute.sr.unh.edu> Message-ID: <1094744292.25251.223.camel@greebo.homeip.net> On Thu, 2004-09-09 at 11:31 -0400, Thomas J. Baker wrote: > On Thu, 2004-09-09 at 17:01 +0200, Alexander Larsson wrote: > > > > I'm not sure why it didn't work on the other machine. Did it have > > nautilus 2.7, and howl installed and mDNSResponder running? Seems to be > > a problem with rendezvous. Maybe a firewall issue? > > > > I'm not sure why installing schemas doesn't trigger reloading them in an > > already running gconfd. I've seen it happen for other packages, so its a > > general problem. But it matters little in this case, just set the key to > > true. > > I set it up on two systems. They each can see themselves but not each > other. Both are up to date rawhide systems. Both can see other > rendezvous broadcasting network services (the same two ftp servers). > There is no firewall between them (same subnet) and no local firewalls > running. Bizzare. I have no idea why this is happening. It seems like publishing from the rawhide machine on non-loopback isn't working. It smells like a firewall or something blocking the outgoing mDNS publishing traffic. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scarfaced crooked cop with a mysterious suitcase handcuffed to his arm. She's a strong-willed wisecracking advertising executive from a different time and place. They fight crime! From justin.creasy at gmail.com Thu Sep 9 18:07:19 2004 From: justin.creasy at gmail.com (Justin Creasy) Date: Thu, 9 Sep 2004 14:07:19 -0400 Subject: desktop mouse icon Message-ID: <6b2ae6df0409091107742a994d@mail.gmail.com> Hello. I am a senior CS major at James Madison University. I am working on a research project that uses 73 flat screen monitors in one large, wrap-around visualization wall. Each CPU is running Fedora Core 1. The visualization is great, but on every computer you can still see the mouse icon. We were able to hack together a solution to hide the mouse icon when we were using redhat 8. We were just hoping that someone knew how to remove/hide the mouse icon in Fedora Core 1. Any help is appreciated, thanks for your time ~ Justin Creasy From hp at redhat.com Thu Sep 9 21:51:13 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 09 Sep 2004 17:51:13 -0400 Subject: GNOME Menu Editing In-Reply-To: <1789.66.206.236.217.1094689206.squirrel@webmail.personainternet.com> References: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> <1094680378.18708.7.camel@lionel-hutz.darnell.group> <1789.66.206.236.217.1094689206.squirrel@webmail.personainternet.com> Message-ID: <1094766673.13661.36.camel@localhost.localdomain> On Wed, 2004-09-08 at 20:20 -0400, Paul Vandenberg wrote: > As far as I know, it was Red Hat that disabled it, not GNOME. In fact, > I read that the menu editing was improved in the upcoming GNOME 2.8. I > was hoping that this would make Red Hat (Fedora) turn it back on > again. It is frustrating that repeated calls for menu editing are > falling on deaf ears! If Mandrake wasn't a GNOME release behind, I > would consider switching. Pretty sure the upstream GNOME improvement was Mark and Dan's work to go to the new menu format. We prioritized that ahead of writing the editor, since we'd have to go back and write the editor again otherwise. Plus, the new format is a fair bit more human-editable. Or at least, a fair bit more documented. But yeah, menu editor is on our list but not the highest priority. Our largest focuses for desktop are 1) to get rid of any need to use the command line, specifically for hardware, e.g. NetworkManager and 2) enterprise management and security stuff like kerberos and remote desktop sharing and so forth. Havoc From hp at redhat.com Thu Sep 9 22:10:17 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 09 Sep 2004 18:10:17 -0400 Subject: desktop mouse icon In-Reply-To: <6b2ae6df0409091107742a994d@mail.gmail.com> References: <6b2ae6df0409091107742a994d@mail.gmail.com> Message-ID: <1094767817.13661.41.camel@localhost.localdomain> On Thu, 2004-09-09 at 14:07 -0400, Justin Creasy wrote: > Hello. I am a senior CS major at James Madison University. I am > working on a research project that uses 73 flat screen monitors in one > large, wrap-around visualization wall. Each CPU is running Fedora Core > 1. The visualization is great, but on every computer you can still see > the mouse icon. We were able to hack together a solution to hide the > mouse icon when we were using redhat 8. We were just hoping that > someone knew how to remove/hide the mouse icon in Fedora Core 1. Any > help is appreciated, thanks for your time ~ Justin Creasy > You can use "unclutter" or make a simple window manager hack that sets the mouse pointer to an all-transparent pixmap and rebuild the window manager. Seems like google could turn up some other possibilities, though I'm sure you've tried that. Havoc From markmc at redhat.com Fri Sep 10 06:31:04 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 10 Sep 2004 07:31:04 +0100 Subject: GNOME Menu Editing In-Reply-To: <1094766673.13661.36.camel@localhost.localdomain> References: <40870.192.26.212.72.1094663496.squirrel@webmail.personainternet.com> <1094680378.18708.7.camel@lionel-hutz.darnell.group> <1789.66.206.236.217.1094689206.squirrel@webmail.personainternet.com> <1094766673.13661.36.camel@localhost.localdomain> Message-ID: <1094797863.3844.2.camel@localhost.localdomain> On Thu, 2004-09-09 at 22:51, Havoc Pennington wrote: > On Wed, 2004-09-08 at 20:20 -0400, Paul Vandenberg wrote: > > As far as I know, it was Red Hat that disabled it, not GNOME. In fact, > > I read that the menu editing was improved in the upcoming GNOME 2.8. I > > was hoping that this would make Red Hat (Fedora) turn it back on > > again. It is frustrating that repeated calls for menu editing are > > falling on deaf ears! If Mandrake wasn't a GNOME release behind, I > > would consider switching. > > Pretty sure the upstream GNOME improvement was Mark and Dan's work to go > to the new menu format. Nothing changed with menus upstream in GNOME 2.8 :-) But switching to the new upstream format is the first thing I'm planning on tackling for 2.10: http://mail.gnome.org/archives/desktop-devel-list/2004-May/msg00232.html Cheers, Mark. From otaylor at redhat.com Mon Sep 13 14:25:11 2004 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 13 Sep 2004 10:25:11 -0400 Subject: Fedora Core 3 Schedule Update - Test 2 Delayed In-Reply-To: <20040910221424.GA31318@nostromo.devel.redhat.com> References: <20040910221424.GA31318@nostromo.devel.redhat.com> Message-ID: <1095085510.2898.7.camel@localhost.localdomain> On Fri, 2004-09-10 at 18:14, Bill Nottingham wrote: > Due to various issues with candidate trees so far, Test 2 > has been pushed out one week, to September 20th. > > Updated schedule is at: > > http://fedora.redhat.com/participate/schedule/ Hmm, with this change, Test 2 is going to be after the final GNOME-2.8 package releases. If we can get the final packages past the release managers, I think we should get them in; the value of getting the Test 2 testing with the newer packages I think outweighs the small chance of causing additional problems. Regards, Owen -------------- 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 tjb at unh.edu Mon Sep 13 20:20:46 2004 From: tjb at unh.edu (Thomas J. Baker) Date: Mon, 13 Sep 2004 16:20:46 -0400 Subject: User space filesharing In-Reply-To: <1094744292.25251.223.camel@greebo.homeip.net> References: <1094737904.25251.195.camel@greebo.homeip.net> <1094740991.14698.17.camel@wintermute.sr.unh.edu> <1094742076.25251.218.camel@greebo.homeip.net> <1094743896.14698.23.camel@wintermute.sr.unh.edu> <1094744292.25251.223.camel@greebo.homeip.net> Message-ID: <1095106846.26738.3.camel@wintermute.sr.unh.edu> On Thu, 2004-09-09 at 17:38 +0200, Alexander Larsson wrote: > On Thu, 2004-09-09 at 11:31 -0400, Thomas J. Baker wrote: > > On Thu, 2004-09-09 at 17:01 +0200, Alexander Larsson wrote: > > > > > > I'm not sure why it didn't work on the other machine. Did it have > > > nautilus 2.7, and howl installed and mDNSResponder running? Seems to be > > > a problem with rendezvous. Maybe a firewall issue? > > > > > > I'm not sure why installing schemas doesn't trigger reloading them in an > > > already running gconfd. I've seen it happen for other packages, so its a > > > general problem. But it matters little in this case, just set the key to > > > true. > > > > I set it up on two systems. They each can see themselves but not each > > other. Both are up to date rawhide systems. Both can see other > > rendezvous broadcasting network services (the same two ftp servers). > > There is no firewall between them (same subnet) and no local firewalls > > running. > > Bizzare. I have no idea why this is happening. It seems like publishing > from the rawhide machine on non-loopback isn't working. It smells like a > firewall or something blocking the outgoing mDNS publishing traffic. > I'm able to cadaver directly to the dav share so it is related to mDNS publishing. Do I have to set that up manually? tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From alexl at redhat.com Tue Sep 14 06:24:33 2004 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 14 Sep 2004 08:24:33 +0200 Subject: User space filesharing In-Reply-To: <1095106846.26738.3.camel@wintermute.sr.unh.edu> References: <1094737904.25251.195.camel@greebo.homeip.net> <1094740991.14698.17.camel@wintermute.sr.unh.edu> <1094742076.25251.218.camel@greebo.homeip.net> <1094743896.14698.23.camel@wintermute.sr.unh.edu> <1094744292.25251.223.camel@greebo.homeip.net> <1095106846.26738.3.camel@wintermute.sr.unh.edu> Message-ID: <1095143073.7807.17.camel@greebo.homeip.net> On Mon, 2004-09-13 at 16:20 -0400, Thomas J. Baker wrote: > > I'm able to cadaver directly to the dav share so it is related to mDNS > publishing. Do I have to set that up manually? No, all you should need is howl installed and mDNSResponder running. The howl sources have a few test programs in the samples subdir for publishing and browsing. You could try to experiment a bit with them. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a maverick small-town farmboy on a search for his missing sister. She's a sharp-shooting tomboy archaeologist from Mars. They fight crime! From linux_fan at spymac.com Sat Sep 18 00:27:41 2004 From: linux_fan at spymac.com (McArthor Lee) Date: Fri, 17 Sep 2004 18:27:41 -0600 Subject: how to change the default desktop icon space in FC2 KDE? Message-ID: <20040918002741.C89E438048@spy23.spymac.net> hi all, i'm using KDE in FC2 and find the default desktop icon space is rather small. how to enlarge the default value? ======================= Thanks & Regards McArthor Lee ---- Introducing Spymac MailPro: http://www.spymac.com/mailpro/ From nandox7 at myrealbox.com Sun Sep 19 13:00:39 2004 From: nandox7 at myrealbox.com (Fernando Morais) Date: Sun, 19 Sep 2004 14:00:39 +0100 Subject: Changing Gnone desktop font color. Message-ID: <000e01c49e48$aaed7860$0901a8c0@frozzen.com> Hi all, is it not possible to change the global desktop font color in gnome? I've only found possible to change type and size, and changing the color could be good for some themes. Thank you, Nando -------------- next part -------------- An HTML attachment was scrubbed... URL: From hp at redhat.com Sun Sep 19 15:26:47 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 19 Sep 2004 11:26:47 -0400 Subject: Changing Gnone desktop font color. In-Reply-To: <000e01c49e48$aaed7860$0901a8c0@frozzen.com> References: <000e01c49e48$aaed7860$0901a8c0@frozzen.com> Message-ID: <1095607607.5357.5.camel@localhost.localdomain> On Sun, 2004-09-19 at 14:00 +0100, Fernando Morais wrote: > Hi all, > > is it not possible to change the global desktop font color in gnome? > I've only found possible to change type and size, and changing the > color could be good for some themes. > The font color comes from the theme, so the theme should set a sensible one for that theme. If it doesn't, it's a theme bug basically. A "colors control panel" to override the colors in themes is a longtime wishlist item, but has trouble making the top of the priority queue. Havoc From p.vandenberg at personainternet.com Sun Sep 19 17:03:29 2004 From: p.vandenberg at personainternet.com (Paul Vandenberg) Date: Sun, 19 Sep 2004 13:03:29 -0400 Subject: Changing Gnone desktop font color. In-Reply-To: <1095607607.5357.5.camel@localhost.localdomain> References: <000e01c49e48$aaed7860$0901a8c0@frozzen.com> <1095607607.5357.5.camel@localhost.localdomain> Message-ID: <414DBBE1.5060000@personainternet.com> Havoc Pennington wrote: >On Sun, 2004-09-19 at 14:00 +0100, Fernando Morais wrote: > > >>Hi all, >> >>is it not possible to change the global desktop font color in gnome? >>I've only found possible to change type and size, and changing the >>color could be good for some themes. >> >> >> > >The font color comes from the theme, so the theme should set a sensible >one for that theme. If it doesn't, it's a theme bug basically. > >A "colors control panel" to override the colors in themes is a longtime >wishlist item, but has trouble making the top of the priority queue. > >Havoc > > > > > That would be awesome! That is one of the things KDE does better than GNOME, customizing colours. Paul From maxx at krakoa.dk Sun Sep 19 17:33:22 2004 From: maxx at krakoa.dk (Mads Villadsen) Date: Sun, 19 Sep 2004 19:33:22 +0200 Subject: Changing Gnone desktop font color. In-Reply-To: <1095607607.5357.5.camel@localhost.localdomain> References: <000e01c49e48$aaed7860$0901a8c0@frozzen.com> <1095607607.5357.5.camel@localhost.localdomain> Message-ID: <1095615203.2890.1.camel@ice> On Sun, 2004-09-19 at 11:26 -0400, Havoc Pennington wrote: > The font color comes from the theme, so the theme should set a sensible > one for that theme. If it doesn't, it's a theme bug basically. > > A "colors control panel" to override the colors in themes is a longtime > wishlist item, but has trouble making the top of the priority queue. Just to hype my own program :-) Look at GNOME Configurator here: http://www.krakoa.dk/linux-software.html It can (among other things) change theme colors. -- Mads Villadsen From p.vandenberg at personainternet.com Sun Sep 19 17:52:53 2004 From: p.vandenberg at personainternet.com (Paul Vandenberg) Date: Sun, 19 Sep 2004 13:52:53 -0400 Subject: Changing Gnone desktop font color. In-Reply-To: <1095615203.2890.1.camel@ice> References: <000e01c49e48$aaed7860$0901a8c0@frozzen.com> <1095607607.5357.5.camel@localhost.localdomain> <1095615203.2890.1.camel@ice> Message-ID: <414DC775.5080900@personainternet.com> Mads Villadsen wrote: >On Sun, 2004-09-19 at 11:26 -0400, Havoc Pennington wrote: > > >>The font color comes from the theme, so the theme should set a sensible >>one for that theme. If it doesn't, it's a theme bug basically. >> >>A "colors control panel" to override the colors in themes is a longtime >>wishlist item, but has trouble making the top of the priority queue. >> >> > >Just to hype my own program :-) Look at GNOME Configurator here: > >http://www.krakoa.dk/linux-software.html > >It can (among other things) change theme colors. > > Awesme program! I've wanted something like this for GNOME! Paul From nandox7 at myrealbox.com Sun Sep 19 23:21:35 2004 From: nandox7 at myrealbox.com (Fernando Morais) Date: Mon, 20 Sep 2004 00:21:35 +0100 Subject: Changing Gnone desktop font color. References: <000e01c49e48$aaed7860$0901a8c0@frozzen.com> <1095607607.5357.5.camel@localhost.localdomain><1095615203.2890.1.camel@ice> <414DC775.5080900@personainternet.com> Message-ID: <001201c49e9f$6a34f260$0601a8c0@stingray> Your program seems very good. I'm going to try it for sure... Regarding the so called wishlist queues, i think that is causing some slow evolution of fedora. The blocking of some basic and really needed features, like the gnome menu editing, is putting fedora some steps behind. If testing versions are always being released why not activate those features, those that are really needed. Everyone knows that they aren't expected to work at 100%. Nando ----- Original Message ----- From: "Paul Vandenberg" To: "Discussions about development for the Fedora desktop" Sent: Sunday, September 19, 2004 6:52 PM Subject: Re: Changing Gnone desktop font color. > Mads Villadsen wrote: > >>On Sun, 2004-09-19 at 11:26 -0400, Havoc Pennington wrote: >> >>>The font color comes from the theme, so the theme should set a sensible >>>one for that theme. If it doesn't, it's a theme bug basically. >>> >>>A "colors control panel" to override the colors in themes is a longtime >>>wishlist item, but has trouble making the top of the priority queue. >>> >> >>Just to hype my own program :-) Look at GNOME Configurator here: >> >>http://www.krakoa.dk/linux-software.html >> >>It can (among other things) change theme colors. >> > Awesme program! I've wanted something like this for GNOME! > > Paul > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-desktop-list > > From kyrre at solution-forge.net Mon Sep 20 16:53:09 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 20 Sep 2004 18:53:09 +0200 Subject: Changing Gnone desktop font color. Message-ID: <1095699189.2757.62.camel@kyrre> Regarding the so called wishlist queues, i think that is causing some slow evolution of fedora. The blocking of some basic and really needed features, like the gnome menu editing, is putting fedora some steps behind. If testing versions are always being released why not activate those features, those that are really needed. Everyone knows that they aren't expected to work at 100%. Ehh... "Everyone knows that they aren't expected to work at 100%" What? I would be seriously pissed if i had tried to edit my menu, and it completely screwed up on me, ending with ex. deleting all my menu items. I thought there stood somewhere "fedora is not supposed to become a dumping ground for old, unsupported software that don't work right"? Doing so would be completely wrong. Linux today has a big red "top quality" stamp - and we should be very carefull not to loose that stamp. Kyrre From hp at redhat.com Mon Sep 20 17:55:09 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 20 Sep 2004 13:55:09 -0400 Subject: Changing Gnone desktop font color. In-Reply-To: <001201c49e9f$6a34f260$0601a8c0@stingray> References: <000e01c49e48$aaed7860$0901a8c0@frozzen.com> <1095607607.5357.5.camel@localhost.localdomain> <1095615203.2890.1.camel@ice> <414DC775.5080900@personainternet.com> <001201c49e9f$6a34f260$0601a8c0@stingray> Message-ID: <1095702909.28058.23.camel@localhost.localdomain> On Mon, 2004-09-20 at 00:21 +0100, Fernando Morais wrote: > Your program seems very good. > I'm going to try it for sure... > > Regarding the so called wishlist queues, i think that is causing some slow > evolution of fedora. The blocking of some basic and really needed features, > like the gnome menu editing, is putting fedora some steps behind. If testing > versions are always being released why not activate those features, those > that are really needed. Everyone knows that they aren't expected to work at > 100%. > Our general policy (for final releases, not test releases) is that if something is totally busted it's better to just turn it off. It looks worse to have broken functionality than to have missing functionality. Havoc From kyrre at solution-forge.net Tue Sep 21 17:26:04 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 21 Sep 2004 19:26:04 +0200 Subject: Fedora-desktop-list Digest, Vol 7, Issue 8 In-Reply-To: <20040921160016.C56A873D1E@hormel.redhat.com> References: <20040921160016.C56A873D1E@hormel.redhat.com> Message-ID: <1095787564.2828.7.camel@kyrre> > Date: Mon, 20 Sep 2004 13:55:09 -0400 > From: Havoc Pennington > Subject: Re: Changing Gnone desktop font color. > To: Discussions about development for the Fedora desktop > > Message-ID: <1095702909.28058.23.camel at localhost.localdomain> > Content-Type: text/plain > > On Mon, 2004-09-20 at 00:21 +0100, Fernando Morais wrote: > > Your program seems very good. > > I'm going to try it for sure... > > > > Regarding the so called wishlist queues, i think that is causing some slow > > evolution of fedora. The blocking of some basic and really needed features, > > like the gnome menu editing, is putting fedora some steps behind. If testing > > versions are always being released why not activate those features, those > > that are really needed. Everyone knows that they aren't expected to work at > > 100%. > > > > Our general policy (for final releases, not test releases) is that if > something is totally busted it's better to just turn it off. It looks > worse to have broken functionality than to have missing functionality. > > Havoc I know - that s why i wonder what up2date is still doing in core... An option could ofcource be (if it dont have to be compiled out/in) to make it possible to turn it on (through preferences - or maybe even just gconf) - and attach a big, fat, and generally ugly warning to the checkbox. From veillard at redhat.com Tue Sep 21 18:05:08 2004 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 21 Sep 2004 14:05:08 -0400 Subject: Some analysis of starting a Gnome session under valgrind Message-ID: <20040921180508.GS18866@redhat.com> I wanted to do this for a long time but only now I had the time and a destop beefy enough to try this. Basically I replaced /usr/bin/gnome-session by a shell script : #!/bin/sh /usr/bin/valgrind --trace-children=yes --log-file=/tmp/valgrind /usr/bin/gnome-session.orig $* Then logged on in gdm , and checked what happened from an ssh connection top the box. The good news: - logging went through, but it took a few minutes - everything looked functional though extremely slow - there wasn't many logs reported by valgrind The bad news: - I had to stop the session shortly after the login fully complete the VM was full (1G of Ram + 500M of swap) - reports from the logs are a pain to try to analyze. - one python (rhn applet I suspect) generated a huge log, python-2.3 doesn't seems valgrindable. I them eliminated all the empty /tmp/valgrind.pid* files, I was left with reports from oly 25 processes. First a word of warning, I used the normal optimized code as shipped as part of Fedora devel (fully up-to-date box for todays version), some of the optimizations sometimes defeat valgrind so there may be false positive. I have tried to sort all the reports to gather together what was frequently reported because all apps went through the same code path, for example there is an error reported when opening gdk display which is reported like 30 times by various apps. So what I saw most: - gdk_display_open leading to write(buf) contains uninitialised or unaddressable byte in __write_nocancel though _X11TransWrite hard to tell without a debugging lib if the error is a false positive a lack of initialization gdk_display_open() or within X. Strange thing is that valgrind report the block as being alloc'ed with calloc() offending address is 128 bytes inside a block of size 16384 - giop_send_buffer_write in libORBit-2 leading to Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) that time the uninitialized data is 10 bytes inside a block of size 2048 allocated within orbit itself. - pango read_line raises a strange pthread mutex error: pthread_mutex_lock/trylock: mutex has invalid owner in pthread_mutex_lock called by pango_read_line from pango_find_map Apparently the GStreamer code detects it's running under valgrind and manage to shut it up :-) Except those 3 repeated all other the place and consisting of the bulk of the reports, I have seen errors in: - /usr/bin/gnome-session: invalid file descriptors, pango_attr_list_get_iterator uninitialized value. - /usr/bin/pam-panel-icon: 2 invalid file descriptor, seems the same as for gnome-session with value 828 too. - /usr/lib/libwnck: uninitialized values in _wnck_read_icons - /usr/libexec/gconfd-2: repeated g_strdup of initialized values from gconf_set_daemon_ior, gconf_get_lock, gconf_object_to_string, gconf_quote_string, and an fprintf - /usr/libexec/bonobo-activation-server: uninitialized values in CORBA_ORB_object_to_stringr,fprintf,giop_send_buffer_write - gam_server : I got one too :-) - metacity: uninitialized values in gdk_window_new, gdk_window_resize, gdk_region_rectangle, gdk_region_subtract, a couple of strange g_int_equal bugs, meta_display_begin_grab_op, meta_display_end_grab_op - gnome-terminal: terminal_profile_update and _vte_pty_open The best way to double check is to do the same trick as I did for gnome-session, move the original somewhere else, replace it by a script calling valgrind but without recursion to child on a local copy of the program in debugging mode. Enclosed are the data as sorted and recouped for more informations. happy valgrinding, Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -------------- next part -------------- XXXXXXXXXXXXXXXXXXXXXXXXXXXX ==10137== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==10137== at 0x39FC5E: __write_nocancel (in /lib/tls/i486/libc-2.3.3.so) ==10137== by 0x1BE6002F: (within /usr/X11R6/lib/libX11.so.6.2) ==10137== by 0x1BE602F2: _X11TransWrite (in /usr/X11R6/lib/libX11.so.6.2) ==10137== by 0x1BE443F2: (within /usr/X11R6/lib/libX11.so.6.2) ==10137== Address 0x1C0BD870 is 128 bytes inside a block of size 16384 alloc'd ==10137== at 0x1B90140D: calloc (vg_replace_malloc.c:176) ==10137== by 0x1BE34825: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2) ==10137== by 0x1BD0C693: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==10137== by 0x1BCED3DC: gdk_display_open_default_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.400.9) also happen from data allocated in calloc/IceOpenConnection/SmcOpenConnection/gnome_client_connect, sometimes Address 0x1C0B89F5 is 525 bytes inside a block of size 16384 alloc'd also calloc/IceOpenConnection/SmcOpenConnection/meta_session_init XXXXXXXXXXXXXXXXXXXXX ==10137== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) ==10137== at 0x3A65AB: writev (in /lib/tls/i486/libc-2.3.3.so) ==10137== by 0xDA6196: (within /usr/lib/libORBit-2.so.0.0.0) ==10137== by 0xDA650B: link_connection_writev (in /usr/lib/libORBit-2.so.0.0.0) ==10137== by 0xD87FE0: giop_send_buffer_write (in /usr/lib/libORBit-2.so.0.0.0) ==10137== Address 0x1C0F4A62 is 10 bytes inside a block of size 2048 alloc'd ==10137== at 0x1B900A90: malloc (vg_replace_malloc.c:131) ==10137== by 0x549922: g_malloc (in /usr/lib/libglib-2.0.so.0.400.6) ==10137== by 0xD87E3E: (within /usr/lib/libORBit-2.so.0.0.0) ==10137== by 0xD87F77: (within /usr/lib/libORBit-2.so.0.0.0) ==10137== XXXXXXXXXXXXX ==10137== pthread_mutex_lock/trylock: mutex has invalid owner ==10137== at 0x1B9D1AF7: pthread_mutex_lock (vg_libpthread.c:1324) ==10137== by 0x1B9D6FD1: _IO_flockfile (vg_libpthread.c:3395) ==10137== by 0x1BD90533: pango_read_line (in /usr/lib/libpango-1.0.so.0.600.0) ==10137== by 0x1BD7F8FF: pango_find_map (in /usr/lib/libpango-1.0.so.0.600.0) X ==10137== Conditional jump or move depends on uninitialised value(s) ==10137== at 0x212285: _wnck_read_icons (in /usr/lib/libwnck-1.so.4.9.0) ==10137== by 0x1FC2DD: (within /usr/lib/libwnck-1.so.4.9.0) ==10137== by 0x1FC9E5: wnck_application_get_icon (in /usr/lib/libwnck-1.so.4.9.0) ==10137== by 0x1FD5C5: _wnck_class_group_add_window (in /usr/lib/libwnck-1.so.4.9.0) XX **10221** GStreamer has detected that it is running inside valgrind. **10221** It might now take different code paths to ease debugging. **10221** Of course, this may also lead to different bugs. got it with process 8101 too 8077 seems to be /usr/bin/gnome-session ==8077== Warning: invalid file descriptor -1 in syscall close() ==8077== Warning: invalid file descriptor -1 in syscall close() ==8077== Conditional jump or move depends on uninitialised value(s) ==8077== at 0xAD7093: __libc_res_nquery (in /lib/libresolv-2.3.3.so) ==8077== by 0x1C380C1B: _nss_dns_getcanonname_r (dns-canon.c:61) ==8077== by 0x398525: gaih_inet (in /lib/tls/i486/libc-2.3.3.so) ==8077== by 0x398AFF: getaddrinfo (in /lib/tls/i486/libc-2.3.3.so) XX ==8077== Conditional jump or move depends on uninitialised value(s) ==8077== at 0x1BE563E5: pango_attr_iterator_next (in /usr/lib/libpango-1.0.so.0.600.0) ==8077== by 0x1BE564FA: pango_attr_list_get_iterator (in /usr/lib/libpango-1.0.so.0.600.0) ==8077== by 0x1BE5F3A8: (within /usr/lib/libpango-1.0.so.0.600.0) ==8077== by 0x1BE602A6: (within /usr/lib/libpango-1.0.so.0.600.0) 8081 seems to be /usr/libexec/gconfd-2 ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0xD8A818: CORBA_ORB_object_to_string (in /usr/lib/libORBit-2.so.0.0.0) ==8081== by 0x8050BC8: main (in /usr/libexec/gconfd-2) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0xD8A830: CORBA_ORB_object_to_string (in /usr/lib/libORBit-2.so.0.0.0) ==8081== by 0x8050BC8: main (in /usr/libexec/gconfd-2) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x558298: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== by 0x659D7AA: gconf_set_daemon_ior (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x8050BD2: main (in /usr/libexec/gconfd-2) ==8081== ==8081== Use of uninitialised value of size 4 ==8081== at 0x558298: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== by 0x659D7AA: gconf_set_daemon_ior (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x8050BD2: main (in /usr/libexec/gconfd-2) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x65A20E1: gconf_get_lock_or_current_holder (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x65A2434: gconf_get_lock (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80511F1: main (in /usr/libexec/gconfd-2) ==8081== ==8081== Use of uninitialised value of size 4 ==8081== at 0x65A20E1: gconf_get_lock_or_current_holder (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x65A2434: gconf_get_lock (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80511F1: main (in /usr/libexec/gconfd-2) ==8081== ==8081== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==8081== at 0x39FC5E: __write_nocancel (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x65A20FD: gconf_get_lock_or_current_holder (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x65A2434: gconf_get_lock (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80511F1: main (in /usr/libexec/gconfd-2) ==8081== Address 0x1B98E4A6 is 6 bytes inside a block of size 637 alloc'd ==8081== at 0x1B900A90: malloc (vg_replace_malloc.c:131) ==8081== by 0x549922: g_malloc (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== by 0x5582A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== by 0x659D7AA: gconf_set_daemon_ior (in /usr/lib/libgconf-2.so.4.1.0) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0xD8A818: CORBA_ORB_object_to_string (in /usr/lib/libORBit-2.so.0.0.0) ==8081== by 0x65A2471: gconf_object_to_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80512E2: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0xD8A830: CORBA_ORB_object_to_string (in /usr/lib/libORBit-2.so.0.0.0) ==8081== by 0x65A2471: gconf_object_to_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80512E2: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x558298: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== by 0x65A247F: gconf_object_to_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80512E2: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== ==8081== Use of uninitialised value of size 4 ==8081== at 0x558298: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== by 0x65A247F: gconf_object_to_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80512E2: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x659F8B1: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80512F3: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== by 0x5394B0: g_hash_table_foreach (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== ==8081== Use of uninitialised value of size 4 ==8081== at 0x659F8B1: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80512F3: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== by 0x5394B0: g_hash_table_foreach (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x659F8EB: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80512F3: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== by 0x5394B0: g_hash_table_foreach (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x659F8F3: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80512F3: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== by 0x5394B0: g_hash_table_foreach (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x659F8DC: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x80512F3: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== by 0x5394B0: g_hash_table_foreach (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x33326C: _IO_vfprintf_internal (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x337D8D: __GI_fprintf (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x805136D: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== ==8081== Use of uninitialised value of size 4 ==8081== at 0x33326C: _IO_vfprintf_internal (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x337D8D: __GI_fprintf (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x805136D: gconfd_logfile_change_listener (in /usr/libexec/gconfd-2) ==8081== by 0x8051531: (within /usr/libexec/gconfd-2) ==8081== ==8081== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==8081== at 0x39FC5E: __write_nocancel (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x34E36C: _IO_do_write@@GLIBC_2.1 (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x34EE81: _IO_file_sync@@GLIBC_2.1 (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x34623D: _IO_fflush_internal (in /lib/tls/i486/libc-2.3.3.so) ==8081== Address 0x1B91304B is not stack'd, malloc'd or (recently) free'd ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0xD8A818: CORBA_ORB_object_to_string (in /usr/lib/libORBit-2.so.0.0.0) ==8081== by 0x65A2471: gconf_object_to_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x805173D: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0xD8A830: CORBA_ORB_object_to_string (in /usr/lib/libORBit-2.so.0.0.0) ==8081== by 0x65A2471: gconf_object_to_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x805173D: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x558298: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== by 0x65A247F: gconf_object_to_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x805173D: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== ==8081== Use of uninitialised value of size 4 ==8081== at 0x558298: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== by 0x65A247F: gconf_object_to_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x805173D: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x659F8B1: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x805175A: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== by 0x65B98C7: _ORBIT_skel_small_ConfigServer_add_client (in /usr/lib/libgconf-2.so.4.1.0) ==8081== ==8081== Use of uninitialised value of size 4 ==8081== at 0x659F8B1: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x805175A: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== by 0x65B98C7: _ORBIT_skel_small_ConfigServer_add_client (in /usr/lib/libgconf-2.so.4.1.0) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x659F8EB: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x805175A: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== by 0x65B98C7: _ORBIT_skel_small_ConfigServer_add_client (in /usr/lib/libgconf-2.so.4.1.0) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x659F8F3: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x805175A: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== by 0x65B98C7: _ORBIT_skel_small_ConfigServer_add_client (in /usr/lib/libgconf-2.so.4.1.0) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x659F8DC: gconf_quote_string (in /usr/lib/libgconf-2.so.4.1.0) ==8081== by 0x805175A: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== by 0x65B98C7: _ORBIT_skel_small_ConfigServer_add_client (in /usr/lib/libgconf-2.so.4.1.0) ==8081== ==8081== Conditional jump or move depends on uninitialised value(s) ==8081== at 0x33326C: _IO_vfprintf_internal (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x337D8D: __GI_fprintf (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x80517A1: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== ==8081== Use of uninitialised value of size 4 ==8081== at 0x33326C: _IO_vfprintf_internal (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x337D8D: __GI_fprintf (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0x80517A1: (within /usr/libexec/gconfd-2) ==8081== by 0x8051A5B: (within /usr/libexec/gconfd-2) ==8081== ==8081== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) ==8081== at 0x3A65AB: writev (in /lib/tls/i486/libc-2.3.3.so) ==8081== by 0xDA6196: (within /usr/lib/libORBit-2.so.0.0.0) ==8081== by 0xDA650B: link_connection_writev (in /usr/lib/libORBit-2.so.0.0.0) ==8081== by 0xD87FE0: giop_send_buffer_write (in /usr/lib/libORBit-2.so.0.0.0) ==8081== Address 0x1B98BE21 is 329 bytes inside a block of size 2048 alloc'd ==8081== at 0x1B900A90: malloc (vg_replace_malloc.c:131) ==8081== by 0x549922: g_malloc (in /usr/lib/libglib-2.0.so.0.400.6) ==8081== by 0xD87E3E: (within /usr/lib/libORBit-2.so.0.0.0) ==8081== by 0xD87F77: (within /usr/lib/libORBit-2.so.0.0.0) 8096 seems to be /usr/libexec/bonobo-activation-server ==8096== Conditional jump or move depends on uninitialised value(s) ==8096== at 0xD8A818: CORBA_ORB_object_to_string (in /usr/lib/libORBit-2.so.0.0.0) ==8096== by 0x8055049: main (in /usr/libexec/bonobo-activation-server) ==8096== ==8096== Conditional jump or move depends on uninitialised value(s) ==8096== at 0xD8A830: CORBA_ORB_object_to_string (in /usr/lib/libORBit-2.so.0.0.0) ==8096== by 0x8055049: main (in /usr/libexec/bonobo-activation-server) ==8096== ==8096== Conditional jump or move depends on uninitialised value(s) ==8096== at 0x33326C: _IO_vfprintf_internal (in /lib/tls/i486/libc-2.3.3.so) ==8096== by 0x337D8D: __GI_fprintf (in /lib/tls/i486/libc-2.3.3.so) ==8096== by 0x8055086: main (in /usr/libexec/bonobo-activation-server) ==8096== ==8096== Use of uninitialised value of size 4 ==8096== at 0x33326C: _IO_vfprintf_internal (in /lib/tls/i486/libc-2.3.3.so) ==8096== by 0x337D8D: __GI_fprintf (in /lib/tls/i486/libc-2.3.3.so) ==8096== by 0x8055086: main (in /usr/libexec/bonobo-activation-server) ==8096== ==8096== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==8096== at 0x39FC5E: __write_nocancel (in /lib/tls/i486/libc-2.3.3.so) ==8096== by 0x34E36C: _IO_do_write@@GLIBC_2.1 (in /lib/tls/i486/libc-2.3.3.so) ==8096== by 0x34DC5F: _IO_file_close_it@@GLIBC_2.1 (in /lib/tls/i486/libc-2.3.3.so) ==8096== by 0x345F5B: _IO_fclose@@GLIBC_2.1 (in /lib/tls/i486/libc-2.3.3.so) ==8096== Address 0x1B904006 is not stack'd, malloc'd or (recently) free'd ==8096== ==8096== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) ==8096== at 0x3A65AB: writev (in /lib/tls/i486/libc-2.3.3.so) ==8096== by 0xDA6196: (within /usr/lib/libORBit-2.so.0.0.0) ==8096== by 0xDA650B: link_connection_writev (in /usr/lib/libORBit-2.so.0.0.0) ==8096== by 0xD87FE0: giop_send_buffer_write (in /usr/lib/libORBit-2.so.0.0.0) ==8096== Address 0x1B9637D5 is 341 bytes inside a block of size 2048 alloc'd ==8096== at 0x1B900A90: malloc (vg_replace_malloc.c:131) ==8096== by 0x549922: g_malloc (in /usr/lib/libglib-2.0.so.0.400.6) ==8096== by 0xD87E3E: (within /usr/lib/libORBit-2.so.0.0.0) ==8096== by 0xD87F77: (within /usr/lib/libORBit-2.so.0.0.0) 8120 seems to be gam_server ==8120== Conditional jump or move depends on uninitialised value(s) ==8120== at 0x804B727: (within /usr/libexec/gam_server) ==8120== by 0x804BB75: (within /usr/libexec/gam_server) ==8120== by 0x804BE32: (within /usr/libexec/gam_server) ==8120== by 0x5460A7: (within /usr/lib/libglib-2.0.so.0.400.6) 8192 seems to be metacity ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x80614A2: (within /usr/bin/metacity) ==8192== by 0x8090C2C: (within /usr/bin/metacity) ==8192== by 0x1BC3191D: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC323FA: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x8061478: (within /usr/bin/metacity) ==8192== by 0x8090C2C: (within /usr/bin/metacity) ==8192== by 0x1BC3191D: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC323FA: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC493E0: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x8090F5A: meta_ui_create_frame_window (in /usr/bin/metacity) ==8192== by 0x8064C95: meta_window_ensure_frame (in /usr/bin/metacity) ==8192== by 0x809A704: meta_window_new_with_attrs (in /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC493F5: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x8090F5A: meta_ui_create_frame_window (in /usr/bin/metacity) ==8192== by 0x8064C95: meta_window_ensure_frame (in /usr/bin/metacity) ==8192== by 0x809A704: meta_window_new_with_attrs (in /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC37DD0: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38121: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC49424: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x8090F5A: meta_ui_create_frame_window (in /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC37DF7: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38121: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC49424: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x8090F5A: meta_ui_create_frame_window (in /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1C678: gdk_rectangle_intersect (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC3807C: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38121: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC49424: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1C696: gdk_rectangle_intersect (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC3807C: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38121: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC49424: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1C6AF: gdk_rectangle_intersect (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC3807C: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38121: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC49424: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC38E01: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC452D5: gdk_window_resize (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x8090F72: meta_ui_create_frame_window (in /usr/bin/metacity) ==8192== by 0x8064C95: meta_window_ensure_frame (in /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1C892: gdk_region_rectangle (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386A2: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38EE5: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC452D5: gdk_window_resize (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1C899: gdk_region_rectangle (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386A2: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38EE5: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC452D5: gdk_window_resize (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1E176: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38EE5: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC452D5: gdk_window_resize (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1E18E: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38EE5: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC452D5: gdk_window_resize (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1D1AE: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1E1B7: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38EE5: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1D1BF: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1E1B7: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38EE5: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1DF3C: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1D3CF: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1E1B7: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1DFF6: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1D3CF: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1E1B7: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1D1F0: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1E1B7: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38EE5: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1D1FF: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1E1B7: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38EE5: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1D263: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1E1B7: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC38EE5: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== pthread_mutex_lock/trylock: mutex has invalid owner ==8192== at 0x1BDAEAF7: pthread_mutex_lock (vg_libpthread.c:1324) ==8192== by 0x1BDB3FD1: _IO_flockfile (vg_libpthread.c:3395) ==8192== by 0x1BCAE533: pango_read_line (in /usr/lib/libpango-1.0.so.0.600.0) ==8192== by 0x1BC9D8FF: pango_find_map (in /usr/lib/libpango-1.0.so.0.600.0) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC1CFD4: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1D2A8: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC1E1B7: gdk_region_subtract (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x1BC386E3: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== ==8192== Invalid read of size 4 ==8192== at 0x5670AC: g_int_equal (in /usr/lib/libglib-2.0.so.0.400.6) ==8192== by 0x80658D7: (within /usr/bin/metacity) ==8192== by 0x8067CAA: (within /usr/bin/metacity) ==8192== by 0x1BA4EA66: (within /usr/lib/libgtk-x11-2.0.so.0.400.9) ==8192== Address 0x52BFD8DC is just below %esp. Possibly a bug in GCC/G++ ==8192== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes ==8192== ==8192== Invalid read of size 4 ==8192== at 0x5670AC: g_int_equal (in /usr/lib/libglib-2.0.so.0.400.6) ==8192== by 0x806599B: (within /usr/bin/metacity) ==8192== by 0x8067CAA: (within /usr/bin/metacity) ==8192== by 0x1BA4EA66: (within /usr/lib/libgtk-x11-2.0.so.0.400.9) ==8192== Address 0x52BFD8DC is just below %esp. Possibly a bug in GCC/G++ ==8192== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC493E0: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x8090F5A: meta_ui_create_frame_window (in /usr/bin/metacity) ==8192== by 0x8064C95: meta_window_ensure_frame (in /usr/bin/metacity) ==8192== by 0x8097E70: (within /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x1BC493F5: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.9) ==8192== by 0x8090F5A: meta_ui_create_frame_window (in /usr/bin/metacity) ==8192== by 0x8064C95: meta_window_ensure_frame (in /usr/bin/metacity) ==8192== by 0x8097E70: (within /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x5393F5: g_hash_table_lookup_extended (in /usr/lib/libglib-2.0.so.0.400.6) ==8192== by 0x80658D7: (within /usr/bin/metacity) ==8192== by 0x8065A05: (within /usr/bin/metacity) ==8192== by 0x8065D4C: meta_frames_apply_shapes (in /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x53A0D9: g_hash_table_replace (in /usr/lib/libglib-2.0.so.0.400.6) ==8192== by 0x806599B: (within /usr/bin/metacity) ==8192== by 0x8065A05: (within /usr/bin/metacity) ==8192== by 0x8065D4C: meta_frames_apply_shapes (in /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x805E307: meta_display_begin_grab_op (in /usr/bin/metacity) ==8192== by 0x809B96D: meta_window_client_message (in /usr/bin/metacity) ==8192== by 0x80607DD: (within /usr/bin/metacity) ==8192== by 0x8090C2C: (within /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x545A11: g_source_remove (in /usr/lib/libglib-2.0.so.0.400.6) ==8192== by 0x805E6FA: meta_display_begin_grab_op (in /usr/bin/metacity) ==8192== by 0x809B96D: meta_window_client_message (in /usr/bin/metacity) ==8192== by 0x80607DD: (within /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x5458E5: g_main_context_find_source_by_id (in /usr/lib/libglib-2.0.so.0.400.6) ==8192== by 0x545A71: g_source_remove (in /usr/lib/libglib-2.0.so.0.400.6) ==8192== by 0x805E6FA: meta_display_begin_grab_op (in /usr/bin/metacity) ==8192== by 0x809B96D: meta_window_client_message (in /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x545912: g_main_context_find_source_by_id (in /usr/lib/libglib-2.0.so.0.400.6) ==8192== by 0x545A71: g_source_remove (in /usr/lib/libglib-2.0.so.0.400.6) ==8192== by 0x805E6FA: meta_display_begin_grab_op (in /usr/bin/metacity) ==8192== by 0x809B96D: meta_window_client_message (in /usr/bin/metacity) ==8192== ==8192== Conditional jump or move depends on uninitialised value(s) ==8192== at 0x805E948: meta_display_end_grab_op (in /usr/bin/metacity) ==8192== by 0x80601E7: (within /usr/bin/metacity) ==8192== by 0x8090C2C: (within /usr/bin/metacity) ==8192== by 0x1BC3191D: (within /usr/lib/libgdk-x11-2.0.so.0.400.9) Unknown program... ==8231== Invalid read of size 4 ==8231== at 0xDA059F: (within /usr/lib/libORBit-2.so.0.0.0) ==8231== by 0xDA0714: ORBit_handle_request (in /usr/lib/libORBit-2.so.0.0.0) ==8231== by 0xD89FB7: giop_connection_handle_input (in /usr/lib/libORBit-2.so.0.0.0) ==8231== by 0xDA6C38: (within /usr/lib/libORBit-2.so.0.0.0) ==8231== Address 0x18 is not stack'd, malloc'd or (recently) free'd gnome-terminal: ==8256== Conditional jump or move depends on uninitialised value(s) ==8256== at 0x80682F3: (within /usr/bin/gnome-terminal) ==8256== by 0x8069162: terminal_profile_update (in /usr/bin/gnome-terminal) ==8256== by 0x805DD1A: (within /usr/bin/gnome-terminal) ==8256== by 0x806157A: main (in /usr/bin/gnome-terminal) ==8256== ==8256== Conditional jump or move depends on uninitialised value(s) ==8256== at 0x80682FF: (within /usr/bin/gnome-terminal) ==8256== by 0x8069162: terminal_profile_update (in /usr/bin/gnome-terminal) ==8256== by 0x805DD1A: (within /usr/bin/gnome-terminal) ==8256== by 0x806157A: main (in /usr/bin/gnome-terminal) ==10010== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==10010== at 0x39FC81: (within /lib/tls/i486/libc-2.3.3.so) ==10010== by 0x1BA14155: (within /usr/lib/libvte.so.4.4.0) ==10010== by 0x1BA145F6: (within /usr/lib/libvte.so.4.4.0) ==10010== by 0x1BA1521D: _vte_pty_open (in /usr/lib/libvte.so.4.4.0) ==10010== Address 0x52BFCFAB is on thread 1's stack /usr/bin/pam-panel-icon: ==8262== Warning: invalid file descriptor 828 in syscall pipe() ==8262== Warning: invalid file descriptor 828 in syscall close() From walters at redhat.com Tue Sep 21 20:26:02 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 21 Sep 2004 16:26:02 -0400 Subject: Some analysis of starting a Gnome session under valgrind In-Reply-To: <20040921180508.GS18866@redhat.com> References: <20040921180508.GS18866@redhat.com> Message-ID: <1095798362.3978.17.camel@nexus.verbum.private> On Tue, 2004-09-21 at 14:05 -0400, Daniel Veillard wrote: > I wanted to do this for a long time but only now I had the time and > a destop beefy enough to try this. Basically I replaced /usr/bin/gnome-session > by a shell script : > #!/bin/sh > /usr/bin/valgrind --trace-children=yes --log-file=/tmp/valgrind /usr/bin/gnome-session.orig $* Cool, definitely useful stuff. > - one python (rhn applet I suspect) generated a huge log, python-2.3 > doesn't seems valgrindable. Yeah, I think the problem is that Python does its own internal memory management. > - giop_send_buffer_write in libORBit-2 leading to > Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) > that time the uninitialized data is 10 bytes inside a block of size 2048 > allocated within orbit itself. It's my understanding that ORBit often allocates large buffers and writes the whole thing even after only using a small portion, this works in the CORBA protocol. You can compile ORBit with some special configure option to make it initialize the buffers. > - pango read_line raises a strange pthread mutex error: > pthread_mutex_lock/trylock: mutex has invalid owner > in pthread_mutex_lock called by pango_read_line from pango_find_map This one is odd, maybe Owen has an idea. -------------- 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 otaylor at redhat.com Tue Sep 21 20:47:40 2004 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 21 Sep 2004 16:47:40 -0400 Subject: Some analysis of starting a Gnome session under valgrind In-Reply-To: <1095798362.3978.17.camel@nexus.verbum.private> References: <20040921180508.GS18866@redhat.com> <1095798362.3978.17.camel@nexus.verbum.private> Message-ID: <1095799660.2950.10.camel@localhost.localdomain> On Tue, 2004-09-21 at 16:26 -0400, Colin Walters wrote: > It's my understanding that ORBit often allocates large buffers and > writes the whole thing even after only using a small portion, this works > in the CORBA protocol. You can compile ORBit with some special > configure option to make it initialize the buffers. > > > - pango read_line raises a strange pthread mutex error: > > pthread_mutex_lock/trylock: mutex has invalid owner > > in pthread_mutex_lock called by pango_read_line from pango_find_map > > This one is odd, maybe Owen has an idea. Presumably it's the flockfile() funlockfile() calls in that function. I can't see anything in this that looks wrong, so it's probably a bad valgrind/libc interaction. Regards, Owen -------------- 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 dalive at flashmail.com Tue Sep 21 23:15:52 2004 From: dalive at flashmail.com (DALive Editor) Date: Tue, 21 Sep 2004 19:15:52 -0400 Subject: Critical Defense Daemon Message-ID: <4150B628.3020007@flashmail.com> I propose that a system/application (which I've chosen to call Critical Defense Daemon) be developed and integrated into Pfc. Such a system have the following properties: - be installed by default, but could be disabled during Anaconda installer - kick into action as soon as the presence of Internet connectivity is detected - reference a central server (group of servers) sending it's distro version - accept of packages vulnerable to attack over the Internet - check this list against installed package list - request iptable rules to block such an attack(s) if any installed packages are vulnerable - alert the user that said rules were about to be entered into their firewall, giving the user an opportunity to Cancel - implement said rules - if rule implementation failed alert user of failure and give user option to block all packets except packets outgoing to port 80 - forward user to a detailed or simplified advisory online which would, among other things give instructions on how to prevent attack, etc. - would reverse rules once package version has been upgrade to a non affected version, or user requests that rules be reversed - check for update advisories at user defined intervals for users permanently connected to the Internet, and for dial up users do check on Internet connection The reason I propose such a system is because over the past up I've installed a few fresh installs of Windows, and without service packs installed from cdrom, the machines last approx 20 mins on the net before they are bogged down my malaware. Such a system would serve as a simple preemptive move that would protect a Linux desktop from such problems now, and in the future. Just an idea Arturo From alexl at redhat.com Wed Sep 22 08:06:59 2004 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 22 Sep 2004 10:06:59 +0200 Subject: Some analysis of starting a Gnome session under valgrind In-Reply-To: <20040921180508.GS18866@redhat.com> References: <20040921180508.GS18866@redhat.com> Message-ID: <1095840419.24266.157.camel@greebo.homeip.net> On Tue, 2004-09-21 at 14:05 -0400, Daniel Veillard wrote: > - giop_send_buffer_write in libORBit-2 leading to > Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) > that time the uninitialized data is 10 bytes inside a block of size 2048 > allocated within orbit itself. For "performance reason" orbit doesn't initialize padding bytes. To make it do this, build with --enable-purify. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a time-tossed drug-addicted vagrant looking for a cure to the poison coursing through his veins. She's a tortured thirtysomething mechanic living on borrowed time. They fight crime! From pmatilai at welho.com Wed Sep 22 08:56:24 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 22 Sep 2004 11:56:24 +0300 (EEST) Subject: wall-messages and desktops Message-ID: Hi, I just had an incident - or almost had - which reminded me that AFAIK there's no way to receive wall-messages on GNOME (or KDE) unless you happen to have a terminal open. Developers probably always have a terminal or a dozen open at any given time but the casual user might not and thus simply miss a broadcast from root about system going down in 15min (for example) which could be nasty. Maybe a job for dbus? Hmm.. I see there are some plans for ACPI-dbus daemon: http://www.cs.bath.ac.uk/~occ/cgi-bin/ideas#acpi_dbus_daemon but that's a very special purpose thing and wont help the wall-case (I'm sure there are other similar cases as well). Thoughts? - Panu - From hp at redhat.com Wed Sep 22 13:47:01 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 22 Sep 2004 09:47:01 -0400 Subject: wall-messages and desktops In-Reply-To: References: Message-ID: <1095860822.20861.58.camel@localhost.localdomain> D-BUS could certainly be used to fix it, yes. You have to write two pieces, one piece runs systemwide and forwards wall messages over D-BUS; one piece runs in the user session and displays any such messages. Havoc On Wed, 2004-09-22 at 11:56 +0300, Panu Matilainen wrote: > Hi, > > I just had an incident - or almost had - which reminded me that AFAIK > there's no way to receive wall-messages on GNOME (or KDE) unless you > happen to have a terminal open. Developers probably always have a terminal > or a dozen open at any given time but the casual user might not and thus > simply miss a broadcast from root about system going down in 15min (for > example) which could be nasty. > > Maybe a job for dbus? Hmm.. I see there are some plans for ACPI-dbus > daemon: http://www.cs.bath.ac.uk/~occ/cgi-bin/ideas#acpi_dbus_daemon but > that's a very special purpose thing and wont help the wall-case (I'm sure > there are other similar cases as well). > > Thoughts? > > - Panu - > > From richardl at redhat.com Wed Sep 22 13:57:43 2004 From: richardl at redhat.com (Richard Li) Date: Wed, 22 Sep 2004 09:57:43 -0400 Subject: default fonts Message-ID: <415184D7.6080305@redhat.com> This morning I decided to experiment with the fonts on my FC2 laptop. A few minutes later, Thunderbird, Firefox, and my desktop look immensely better by simply switching to Bitstream Vera. Now, I don't want to start a which-font-looks-better-war, but the default of the generic "Sans" and "Sans Serif" fonts are pretty terrible and I think that there is no question that the defaults could be changed to something better. I had to change the default fonts in three places: o Thunderbird o Firefox o Preferences/Fonts in GNOME Is it possible to change the defaults for these apps? I searched through the archives and there has been some discussion, although it seemed to center around which font looks best: http://www.redhat.com/archives/fedora-desktop-list/2003-December/msg00055.html Honestly, I don't care, as long as it isn't Sans and Sans Serif ;-). Thoughts? Richard From rdieter at math.unl.edu Wed Sep 22 13:57:26 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Sep 2004 08:57:26 -0500 Subject: wall-messages and desktops In-Reply-To: <1095860822.20861.58.camel@localhost.localdomain> References: <1095860822.20861.58.camel@localhost.localdomain> Message-ID: <415184C6.4050003@math.unl.edu> > On Wed, 2004-09-22 at 11:56 +0300, Panu Matilainen wrote: >I just had an incident - or almost had - which reminded me that AFAIK >there's no way to receive wall-messages on GNOME (or KDE) unless you >happen to have a terminal open. KDE can do it, if you enable the "KDE Write Daemon" in Kcontrol->KDE Components->Service Manager -- Rex From rdieter at math.unl.edu Wed Sep 22 14:04:53 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Sep 2004 09:04:53 -0500 Subject: default fonts In-Reply-To: <415184D7.6080305@redhat.com> References: <415184D7.6080305@redhat.com> Message-ID: <41518685.9070007@math.unl.edu> Richard Li wrote: > This morning I decided to experiment with the fonts on my FC2 laptop. A > few minutes later, Thunderbird, Firefox, and my desktop look immensely > better by simply switching to Bitstream Vera. Now, I don't want to start > a which-font-looks-better-war, but the default of the generic "Sans" and > "Sans Serif" fonts are pretty terrible and I think that there is no > question that the defaults could be changed to something better. > > I had to change the default fonts in three places: > > o Thunderbird > o Firefox > o Preferences/Fonts in GNOME > > Is it possible to change the defaults for these apps? ... > Honestly, I don't care, as long as it isn't Sans and Sans Serif ;-). AFAIK, I believe the Luxi-* fonts were chosen as defaults for Sans, Serif, etc... (see /etc/fonts/fonts.conf details regarding font defaults) mostly because of Bitstream Vera's lack of support for non-English languages. -- Rex From pmatilai at welho.com Wed Sep 22 14:39:58 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 22 Sep 2004 17:39:58 +0300 Subject: wall-messages and desktops In-Reply-To: <1095860822.20861.58.camel@localhost.localdomain> References: <1095860822.20861.58.camel@localhost.localdomain> Message-ID: <1095863998.15042.15.camel@chip.laiskiainen.org> On Wed, 2004-09-22 at 16:47, Havoc Pennington wrote: > D-BUS could certainly be used to fix it, yes. You have to write two > pieces, one piece runs systemwide and forwards wall messages over D-BUS; > one piece runs in the user session and displays any such messages. ...which sounds like yet-another-daemon (or two) ... like we didn't have enough of 'em already :-/ Hmm.. dbus-0.21 changelog says "implement "auto activation" flag on messages, so the destination service can be launched automatically" which, if it means what I think, is exactly what I was hoping for: the ability to register a program for given type of messages which then do stuff with the information received from the bus. So you don't need a separate user daemon for each and every thing that you might want to communicate across dbus - or did I completely misunderstand that? - Panu - From jspaleta at gmail.com Wed Sep 22 15:33:16 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Sep 2004 11:33:16 -0400 Subject: Critical Defense Daemon In-Reply-To: <4150B628.3020007@flashmail.com> References: <4150B628.3020007@flashmail.com> Message-ID: <604aa79104092208336329fcbf@mail.gmail.com> On Tue, 21 Sep 2004 19:15:52 -0400, DALive Editor wrote: > Such a system have the following properties: > - be installed by default, but could be disabled during Anaconda > installer > - kick into action as soon as the presence of Internet connectivity > is detected > - reference a central server (group of servers) sending it's distro > version > - accept of packages vulnerable to attack over the Internet > - check this list against installed package list > - request iptable rules to block such an attack(s) if any installed > packages are vulnerable OR we could just have very secure default configurations where no outside accessible services are turned on by default AND a default firewall that blocks all incoming service requests. Which is very close to what we have right now. Doing a default install of fedora core.. using the default firewall settings...and default configuration choices what services are exposed? What you describe makes sense in a windows world where incoming services are enabled by default..but it seems a huge waste of effort to me to implement this for fedora, when reasonably secure default configuration is used that limits the exposure to malicious attack by default. http://www.advogato.org/person/mjcox/diary.html?start=126 http://blogs.redhat.com/people/archive/000133.html > - alert the user that said rules were about to be entered into their > firewall, giving the user an opportunity to Cancel > - implement said rules > - if rule implementation failed alert user of failure and give user > option to block all packets except packets outgoing to port 80 > - forward user to a detailed or simplified advisory online which > would, among other things give instructions on how to prevent attack, etc. > - would reverse rules once package version has been upgrade to a non > affected version, or user requests that rules be reversed This complicated scheme sounds fragile and prone to its own vulnerabilities. Imagine if someone was able to spoof a dns server response and point you to the wrong list of packages..and that list encouraged you to create iptables rules that users dont understand how to review... sounds like a recipe for a problem to me. > - check for update advisories at user defined intervals for users > permanently connected to the Internet, and for dial up users do check on > Internet connection Well rhn-applet checks for updates...or it should. And when connected to rhn up2date is able to give advisory text as well. I will agree with you that finding a way to get update advisory text into the ui again for fedora core updates is something worth doing. > The reason I propose such a system is because over the past up I've > installed a few fresh installs of Windows, and without service packs > installed from cdrom, the machines last approx 20 mins on the net before > they are bogged down my malaware. Such a system would serve as a simple > preemptive move that would protect a Linux desktop from such problems > now, and in the future. I counter that secure default firewall settings and default configuration settings where inbound services are not exposed by default is more than enough to prevent a linux distribution from experiencing the problem windows experiences and what you want would be a drain on development resources for very little actual gain. If there is a problem with the default configuration and the default firewall rules that should be dealt with directly. I would say however, that it might be useful to think about how to have the ui for the system ask the user if they want to check for updates very soon after installationa is complete. Maybe firstboot could be taught to prompt the user about what updates are available, maybe something else. -jef From hp at redhat.com Wed Sep 22 18:43:33 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 22 Sep 2004 14:43:33 -0400 Subject: wall-messages and desktops In-Reply-To: <1095863998.15042.15.camel@chip.laiskiainen.org> References: <1095860822.20861.58.camel@localhost.localdomain> <1095863998.15042.15.camel@chip.laiskiainen.org> Message-ID: <1095878613.18936.22.camel@localhost.localdomain> On Wed, 2004-09-22 at 17:39 +0300, Panu Matilainen wrote: > On Wed, 2004-09-22 at 16:47, Havoc Pennington wrote: > > D-BUS could certainly be used to fix it, yes. You have to write two > > pieces, one piece runs systemwide and forwards wall messages over D-BUS; > > one piece runs in the user session and displays any such messages. > > ...which sounds like yet-another-daemon (or two) ... like we didn't have > enough of 'em already :-/ > > Hmm.. dbus-0.21 changelog says "implement "auto activation" flag on > messages, so the destination service can be launched automatically" > which, if it means what I think, is exactly what I was hoping for: the > ability to register a program for given type of messages which then do > stuff with the information received from the bus. So you don't need a > separate user daemon for each and every thing that you might want to > communicate across dbus - or did I completely misunderstand that? > That doesn't avoid the daemon in this case, but nothing says this has to be a separate daemon. The feature could be packed into gnome-settings- daemon, gnome-panel, gnome-session, or any other existing process. The same is true of most of the desktop daemons; it's just a question of modularity vs. performance. Havoc From nandox7 at myrealbox.com Thu Sep 23 07:47:57 2004 From: nandox7 at myrealbox.com (Fernando Morais) Date: Thu, 23 Sep 2004 08:47:57 +0100 Subject: What happened to the package manager? Message-ID: <001901c4a141$a5ff3a90$0901a8c0@frozzen.com> What happened to the package manager, that the first test release of fedora had? Despite some of the features that weren't working it was a excellent tool, because currently the only tool to deal with the packages is quite limited. Some features like installing new packages, and being associated with the .rpm in nautilus, the possibility to see the dependencies, or even the files that it brings. Are all thing that can't be done. Was it totally remove from the plan? Nando -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at redhat.com Thu Sep 23 13:22:14 2004 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 23 Sep 2004 15:22:14 +0200 Subject: What happened to the package manager? In-Reply-To: <001901c4a141$a5ff3a90$0901a8c0@frozzen.com> References: <001901c4a141$a5ff3a90$0901a8c0@frozzen.com> Message-ID: <1095945734.24266.243.camel@greebo.homeip.net> On Thu, 2004-09-23 at 08:47 +0100, Fernando Morais wrote: > What happened to the package manager, that the first test release of > fedora had? > Despite some of the features that weren't working it was a excellent > tool, because currently the only tool to deal with the packages is > quite limited. > Some features like installing new packages, and being associated with > the .rpm in nautilus, the possibility to see the dependencies, or even > the files that it brings. Are all thing that can't be done. > > Was it totally remove from the plan? I'm not sure what app you're talking about, but if you mean system- config-packages, there was a bug that made it not be associated with rpms in nautilus. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132804 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a benighted moralistic matador looking for 'the Big One.' She's a scantily clad mutant research scientist with the power to see death. They fight crime! From byte at aeon.com.my Thu Sep 23 05:57:44 2004 From: byte at aeon.com.my (Colin Charles) Date: Thu, 23 Sep 2004 15:57:44 +1000 Subject: wall-messages and desktops In-Reply-To: References: Message-ID: <1095919064.21380.139.camel@albus.aeon.com.my> On Wed, 2004-09-22 at 18:56, Panu Matilainen wrote: > I just had an incident - or almost had - which reminded me that AFAIK > there's no way to receive wall-messages on GNOME (or KDE) unless you > happen to have a terminal open. Developers probably always have a terminal > or a dozen open at any given time but the casual user might not and thus > simply miss a broadcast from root about system going down in 15min (for > example) which could be nasty. There's been a bug open about this for a while: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114793 I wonder what has happened to the internal RFE that was mentioned -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From nandox7 at myrealbox.com Thu Sep 23 20:43:52 2004 From: nandox7 at myrealbox.com (Fernando Morais) Date: Thu, 23 Sep 2004 21:43:52 +0100 Subject: What happened to the package manager? References: <001901c4a141$a5ff3a90$0901a8c0@frozzen.com> <1095945734.24266.243.camel@greebo.homeip.net> Message-ID: <000b01c4a1ae$12978d80$0901a8c0@frozzen.com> I think not. It was a tool that only happered before the final release of Fedora Core 1. In the final FC! release, it wasn't htere anymore. It shows the package list complety, and not by groups, like the actual system-config-packages does. In the time it had the option to remove pakages, the add was there but not possible to select i think. ----- Original Message ----- From: "Alexander Larsson" To: "Fernando Morais" ; Sent: Thursday, September 23, 2004 2:22 PM Subject: Re: What happened to the package manager? > On Thu, 2004-09-23 at 08:47 +0100, Fernando Morais wrote: > > What happened to the package manager, that the first test release of > > fedora had? > > Despite some of the features that weren't working it was a excellent > > tool, because currently the only tool to deal with the packages is > > quite limited. > > Some features like installing new packages, and being associated with > > the .rpm in nautilus, the possibility to see the dependencies, or even > > the files that it brings. Are all thing that can't be done. > > > > Was it totally remove from the plan? > > I'm not sure what app you're talking about, but if you mean system- > config-packages, there was a bug that made it not be associated with > rpms in nautilus. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132804 > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a benighted moralistic matador looking for 'the Big One.' She's a > scantily clad mutant research scientist with the power to see death. They > fight crime! > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-desktop-list > > From wralphie at comcast.net Fri Sep 24 19:56:59 2004 From: wralphie at comcast.net (jludwig) Date: Fri, 24 Sep 2004 15:56:59 -0400 Subject: wall-messages and desktops In-Reply-To: <1095919064.21380.139.camel@albus.aeon.com.my> References: <1095919064.21380.139.camel@albus.aeon.com.my> Message-ID: <1096055818.3094.0.camel@jMOD.home> On Thu, 2004-09-23 at 01:57, Colin Charles wrote: > On Wed, 2004-09-22 at 18:56, Panu Matilainen wrote: > > > I just had an incident - or almost had - which reminded me that AFAIK > > there's no way to receive wall-messages on GNOME (or KDE) unless you > > happen to have a terminal open. Developers probably always have a terminal > > or a dozen open at any given time but the casual user might not and thus > > simply miss a broadcast from root about system going down in 15min (for > > example) which could be nasty. > > There's been a bug open about this for a while: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114793 > > I wonder what has happened to the internal RFE that was mentioned > -- > Colin Charles, byte at aeon.com.my > http://www.bytebot.net/ > "First they ignore you, then they laugh at you, then they fight you, > then you win." -- Mohandas Gandhi Wall seems to do fine on my systems using KDE. -- jludwig From stevelist at silverorange.com Sun Sep 26 23:16:23 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Sun, 26 Sep 2004 20:16:23 -0300 Subject: Unfocused Nautilus Selection Color with Bluecurve Message-ID: <41574DC7.4010905@silverorange.com> I've occasionally run into a situation where I mistake an unfocused Nautilus window in the background as the focused foreground window. The window title bar with Bluecurve makes a strong distinction between focused and unfocused windows, which is great. However, if you have icons selected in the *unfocused* window, you may notice that the unfocused icon selection color (that masks the icons, and becomes the background color of the icon title text) is very close to the icon selection color in *focused* windows. The two colors are different, but not by much. I would like to suggest making the unfocused icon selection color more significantly different than the focused icon selection color. Perhaps a bit lighter, and gray instead of blue (like the window title bar change). I've put together a screenshot illustrating focused and unfocused Nautilus windows and example swatches of the two colors in question: http://actsofvolition.com/images/screenshots/bluecurve-selection-focus.png I haven't worked on Gnome themes before, but some help and digging around turned up that this color is easy to change. In my Fedora Core 2 install, the color is on line #36 of the file /usr/share/themes/Bluecurve/gtk-2.0/gtkrc I'm experimenting using a gray color (#b5b5b5) for a few days on my own machine. Depending on feedback to this post (welcome and encouraged), I'll file a bug (and maybe a patch). Steven Garrity From martinalderson at gmail.com Mon Sep 27 00:35:29 2004 From: martinalderson at gmail.com (Martin Alderson) Date: Mon, 27 Sep 2004 01:35:29 +0100 Subject: Unfocused Nautilus Selection Color with Bluecurve In-Reply-To: <41574DC7.4010905@silverorange.com> References: <41574DC7.4010905@silverorange.com> Message-ID: <3d860078040926173528aff677@mail.gmail.com> On Sun, 26 Sep 2004 20:16:23 -0300, Steven Garrity wrote: > I've occasionally run into a situation where I mistake an unfocused > Nautilus window in the background as the focused foreground window. The > window title bar with Bluecurve makes a strong distinction between > focused and unfocused windows, which is great. > > However, if you have icons selected in the *unfocused* window, you may > notice that the unfocused icon selection color (that masks the icons, > and becomes the background color of the icon title text) is very close > to the icon selection color in *focused* windows. > > The two colors are different, but not by much. I would like to suggest > making the unfocused icon selection color more significantly different > than the focused icon selection color. Perhaps a bit lighter, and gray > instead of blue (like the window title bar change). > > I've put together a screenshot illustrating focused and unfocused > Nautilus windows and example swatches of the two colors in question: > http://actsofvolition.com/images/screenshots/bluecurve-selection-focus.png > > I haven't worked on Gnome themes before, but some help and digging > around turned up that this color is easy to change. In my Fedora Core 2 > install, the color is on line #36 of the file > /usr/share/themes/Bluecurve/gtk-2.0/gtkrc > > I'm experimenting using a gray color (#b5b5b5) for a few days on my own > machine. > > Depending on feedback to this post (welcome and encouraged), I'll file a > bug (and maybe a patch). > > Steven Garrity I like it. Simple change that makes it easier to identify windows - who can complain about that! -- Martin From wtogami at redhat.com Mon Sep 27 02:32:17 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 26 Sep 2004 16:32:17 -1000 Subject: What happened to Preferred Applications chooser? Message-ID: <41577BB1.9030307@redhat.com> /usr/bin/gnome-default-applications-properties The "Preferences" menu used to have an icon to launch this application, but it is missing now. Any ideas what happened? Warren Togami wtogami at redhat.com From dalive at flashmail.com Mon Sep 27 04:24:55 2004 From: dalive at flashmail.com (DALive Editor) Date: Mon, 27 Sep 2004 00:24:55 -0400 Subject: wall-messages and desktops In-Reply-To: <1096055818.3094.0.camel@jMOD.home> References: <1095919064.21380.139.camel@albus.aeon.com.my> <1096055818.3094.0.camel@jMOD.home> Message-ID: <41579617.2060307@flashmail.com> jludwig wrote: >On Thu, 2004-09-23 at 01:57, Colin Charles wrote: > > >>On Wed, 2004-09-22 at 18:56, Panu Matilainen wrote: >> >> >> >>>I just had an incident - or almost had - which reminded me that AFAIK >>>there's no way to receive wall-messages on GNOME (or KDE) unless you >>>happen to have a terminal open. Developers probably always have a terminal >>>or a dozen open at any given time but the casual user might not and thus >>>simply miss a broadcast from root about system going down in 15min (for >>>example) which could be nasty. >>> >>> >>There's been a bug open about this for a while: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114793 >> >>I wonder what has happened to the internal RFE that was mentioned >>-- >>Colin Charles, byte at aeon.com.my >>http://www.bytebot.net/ >>"First they ignore you, then they laugh at you, then they fight you, >>then you win." -- Mohandas Gandhi >> >> >Wall seems to do fine on my systems using KDE. > > I must admit that I always have a terminal open, but KWrited picks up wall messages, and I did not have to ask it to. From dalive at flashmail.com Mon Sep 27 04:40:36 2004 From: dalive at flashmail.com (DALive Editor) Date: Mon, 27 Sep 2004 00:40:36 -0400 Subject: Critical Defense Daemon In-Reply-To: <604aa79104092208336329fcbf@mail.gmail.com> References: <4150B628.3020007@flashmail.com> <604aa79104092208336329fcbf@mail.gmail.com> Message-ID: <415799C4.2020002@flashmail.com> Jeff Spaleta wrote: >On Tue, 21 Sep 2004 19:15:52 -0400, DALive Editor wrote: > > >>Such a system have the following properties: >> - be installed by default, but could be disabled during Anaconda >>installer >> - kick into action as soon as the presence of Internet connectivity >>is detected >> - reference a central server (group of servers) sending it's distro >>version >> - accept of packages vulnerable to attack over the Internet >> - check this list against installed package list >> - request iptable rules to block such an attack(s) if any installed >>packages are vulnerable >> >> > >OR we could just have very secure default configurations where no >outside accessible services are turned on by default AND a default >firewall that blocks all incoming service requests. Which is very >close to what we have right now. Doing a default install of fedora >core.. using the default firewall settings...and default configuration >choices what services are exposed? What you describe makes sense in a >windows world where incoming services are enabled by default..but it >seems a huge waste of effort to me to implement this for fedora, when >reasonably secure default configuration is used that limits the >exposure to malicious attack by default. >http://www.advogato.org/person/mjcox/diary.html?start=126 >http://blogs.redhat.com/people/archive/000133.html > > Point taken. What would you consider to be the worst case scenario for a fresh FC3 install in 2008, hyperthetically? > > > >> - alert the user that said rules were about to be entered into their >>firewall, giving the user an opportunity to Cancel >> - implement said rules >> - if rule implementation failed alert user of failure and give user >>option to block all packets except packets outgoing to port 80 >> - forward user to a detailed or simplified advisory online which >>would, among other things give instructions on how to prevent attack, etc. >> - would reverse rules once package version has been upgrade to a non >>affected version, or user requests that rules be reversed >> >> > >This complicated scheme sounds fragile and prone to its own >vulnerabilities. Imagine if someone was able to spoof a dns server >response and point you to the wrong list of packages..and that list >encouraged you to create iptables rules that users dont understand how >to review... sounds like a recipe for a problem to me. > > You have a point here for sure. Would ssh keys not lessen such a problem? And I'm doubtful the target audience would be expected to understand iptables rules at all. > > >> - check for update advisories at user defined intervals for users >>permanently connected to the Internet, and for dial up users do check on >>Internet connection >> >> > >Well rhn-applet checks for updates...or it should. And when connected >to rhn up2date is able to give advisory text as well. I will agree >with you that finding a way to get update advisory text into the ui >again for fedora core updates is something worth doing. > > Well, from my last two FC2 installs rhn-applet worked just well enough to tell me that here were updates to be made. It showed a 0 sizes for all the packages, I had to turn to Yumi for updates/installs (BTW I think Yumi or similar tool should be part of the distro). I hate to say this, but getting a sort of XPish poppup bubble to warn users of critcal upates at least would be a good step. > > >>The reason I propose such a system is because over the past up I've >>installed a few fresh installs of Windows, and without service packs >>installed from cdrom, the machines last approx 20 mins on the net before >>they are bogged down my malaware. Such a system would serve as a simple >>preemptive move that would protect a Linux desktop from such problems >>now, and in the future. >> >> > >I counter that secure default firewall settings and default >configuration settings where inbound services are not exposed by >default is more than enough to prevent a linux distribution from >experiencing the problem windows experiences and what you want would >be a drain on development resources for very little actual gain. If >there is a problem with the default configuration and the default >firewall rules that should be dealt with directly. > > Fair enough, you make valid points. Any idea if a more flexible firewall configuration tool is in mind for FC? And correct me if I'm wrong, but isn't the default firewall setup for FC with FTP, SSH, etc open? >I would say however, that it might be useful to think about how to >have the ui for the system ask the user if they want to check for >updates very soon after installationa is complete. Maybe firstboot >could be taught to prompt the user about what updates are available, >maybe something else. > > On this we both aggree. I for one don't think that enough is done in anticipation of novice users. I'm not suggesting a watering down of the desktop. Just some optional hand holding. Or is this the job of the KDE/GNOME guys? >-jef > > > > From breun at xs4all.nl Mon Sep 27 08:40:33 2004 From: breun at xs4all.nl (Nils Breunese) Date: Mon, 27 Sep 2004 10:40:33 +0200 Subject: Missing icons Message-ID: <4157D201.4050509@xs4all.nl> Hello, I'm running KDE 3.2.2 on Fedora Core 2 and have a problem with my menu items. When I first installed Fedora everything had its icon just in the right place, but after some upgrading I don't have any icons for openoffice.org (I reinstalled, but to no avail), KEdit and KWrite are no longer under Editors, etc. etc. This is only true for my user account, when I log in to X as root, the menu is fine. I already googled around and found that menu items for all users are stored in /usr/share/applications(/kde)/ and that user specific items are stored in ~/.kde/share/applnk/, but somehow it seems like there are some more locations/factors in play, because I still can't seem to find the openoffice.org items. Is there maybe a way to have (all) your rpm's recreate the icons they create at install time? I know I can manually add items, but I would really like to just have the default items created by the rpm's. Nils Breunese. -- "I got a funny feeling they got plastic in the afterlife" - Beck From xsos1982 at yahoo.com.sg Mon Sep 27 08:46:28 2004 From: xsos1982 at yahoo.com.sg (Rubi Sutanto) Date: Mon, 27 Sep 2004 15:46:28 +0700 Subject: Fedora ArtWork (BoxSet) In-Reply-To: <4157D201.4050509@xs4all.nl> References: <4157D201.4050509@xs4all.nl> Message-ID: <1096274788.10521.6.camel@> Helo, i just want to share my artwork fo fedora. so many artwork create for fedora is wallpaper, themes, icons, gdm, etc. But it is rare to make a box set. I try to make some box set here http://www.deviantart.com/deviation/10943151/ (like the brad did). Thanks before. -- Best Regards, Rubi Sutanto (xsos) Complaint Box and Philips Moderator www.forumponsel.com Registered Linux User #359772 From jspaleta at gmail.com Mon Sep 27 13:21:06 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 27 Sep 2004 09:21:06 -0400 Subject: What happened to Preferred Applications chooser? In-Reply-To: <41577BB1.9030307@redhat.com> References: <41577BB1.9030307@redhat.com> Message-ID: <604aa79104092706213bb9dc56@mail.gmail.com> On Sun, 26 Sep 2004 16:32:17 -1000, Warren Togami wrote: > /usr/bin/gnome-default-applications-properties > The "Preferences" menu used to have an icon to launch this application, > but it is missing now. Any ideas what happened? lingering control-center bug with the associated .desktop file is my guess. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133310 default-applications and sessions are the only menu items i think are still missing, previously it was nearly all the control-center items. -jef From rstrode at redhat.com Mon Sep 27 16:58:55 2004 From: rstrode at redhat.com (Ray Strode) Date: Mon, 27 Sep 2004 12:58:55 -0400 Subject: What happened to Preferred Applications chooser? In-Reply-To: <41577BB1.9030307@redhat.com> References: <41577BB1.9030307@redhat.com> Message-ID: <1096304335.3704.1.camel@localhost.localdomain> On Sun, 2004-09-26 at 16:32 -1000, Warren Togami wrote: > /usr/bin/gnome-default-applications-properties > The "Preferences" menu used to have an icon to launch this application, > but it is missing now. Any ideas what happened? It's a YellowPad bug to move it to More Preferences. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131605 --Ray From warren at togami.com Tue Sep 28 10:12:58 2004 From: warren at togami.com (Warren Togami) Date: Tue, 28 Sep 2004 00:12:58 -1000 Subject: What happened to Preferred Applications chooser? In-Reply-To: <1096304335.3704.1.camel@localhost.localdomain> References: <41577BB1.9030307@redhat.com> <1096304335.3704.1.camel@localhost.localdomain> Message-ID: <4159392A.4020009@togami.com> Ray Strode wrote: > On Sun, 2004-09-26 at 16:32 -1000, Warren Togami wrote: > >>/usr/bin/gnome-default-applications-properties >>The "Preferences" menu used to have an icon to launch this application, >>but it is missing now. Any ideas what happened? > > It's a YellowPad bug to move it to More Preferences. > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131605 > > --Ray Sigh... From peter.backlund at home.se Thu Sep 30 17:02:01 2004 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 30 Sep 2004 19:02:01 +0200 Subject: Evolution 2 repository Message-ID: <1096563721.6726.7.camel@h65n2fls33o1121.telia.com> Hello. If you're interested in running Evolution 2 on FC2, take a look at this: http://petrix.se/evolution2/ /Peter -- Peter Backlund From ecroft at OPENRATINGS.com Thu Sep 30 18:13:25 2004 From: ecroft at OPENRATINGS.com (Edward Croft) Date: Thu, 30 Sep 2004 14:13:25 -0400 Subject: Evolution 2 repository In-Reply-To: <1096563721.6726.7.camel@h65n2fls33o1121.telia.com> References: <1096563721.6726.7.camel@h65n2fls33o1121.telia.com> Message-ID: <1096568005.8496.1.camel@aine.hq.openratings.com> On Thu, 2004-09-30 at 13:02, Peter Backlund wrote: > Hello. > > If you're interested in running Evolution 2 on FC2, take a look at this: > > http://petrix.se/evolution2/ > > /Peter > > -- > Peter Backlund > > Thanks Peter, I tried but got:.Package ximian-connector needs libcal-client.so.0, this is not available. Package ximian-connector needs libcal-util.so.0, this is not available. Package ximian-connector needs libebook.so.0, this is not available. Package ximian-connector needs libename.so.0, this is not available. Package ximian-connector needs libical-evolution.so.0, this is not available. Package ximian-connector needs libversit.so.0, this is not available. Package ximian-connector needs libwombat.so.0, this is not available. Even tried just downloading Evo figuring it would install the libs and then download the connector. -- Edward M. Croft Sr. Systems Engineer Open Ratings, Inc. 200 West Street Waltham, MA 02451-1121 From fedora at leemhuis.info Thu Sep 30 18:28:17 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Sep 2004 20:28:17 +0200 Subject: Evolution 2 repository In-Reply-To: <1096563721.6726.7.camel@h65n2fls33o1121.telia.com> References: <1096563721.6726.7.camel@h65n2fls33o1121.telia.com> Message-ID: <1096568897.2702.26.camel@localhost.localdomain> Am Donnerstag, den 30.09.2004, 19:02 +0200 schrieb Peter Backlund: > Hello. > > If you're interested in running Evolution 2 on FC2, take a look at this: > > http://petrix.se/evolution2/ I still think we need more of such packages / mini repositories somewhere at download.fedora.us for those who don't want or can't follow rawhide. -- Thorsten Leemhuis From peter.backlund at home.se Thu Sep 30 18:40:13 2004 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 30 Sep 2004 20:40:13 +0200 Subject: Evolution 2 repository In-Reply-To: <1096568005.8496.1.camel@aine.hq.openratings.com> References: <1096563721.6726.7.camel@h65n2fls33o1121.telia.com> <1096568005.8496.1.camel@aine.hq.openratings.com> Message-ID: <1096569613.6726.9.camel@h65n2fls33o1121.telia.com> tor 2004-09-30 klockan 14:13 -0400 skrev Edward Croft: > On Thu, 2004-09-30 at 13:02, Peter Backlund wrote: > > Hello. > > > > If you're interested in running Evolution 2 on FC2, take a look at this: > > > > http://petrix.se/evolution2/ > > > > /Peter > > > > -- > > Peter Backlund > > > > > Thanks Peter, I tried but got:.Package ximian-connector needs > libcal-client.so.0, this is not available. > Package ximian-connector needs libcal-util.so.0, this is not available. > Package ximian-connector needs libebook.so.0, this is not available. > Package ximian-connector needs libename.so.0, this is not available. > Package ximian-connector needs libical-evolution.so.0, this is not > available. > Package ximian-connector needs libversit.so.0, this is not available. > Package ximian-connector needs libwombat.so.0, this is not available. Hmm, did you have ximian-connector installed before? rpm -q ximian-connector Probably should add an Obsoletes: to evolution-connector...try removing ximian-connector first, then install evolution and evolution-connector. /Peter > Even tried just downloading Evo figuring it would install the libs and > then download the connector. > > -- > Edward M. Croft > Sr. Systems Engineer > Open Ratings, Inc. > 200 West Street > Waltham, MA 02451-1121 > -- Peter Backlund