xfce October 2012

xfce@lists.fedoraproject.org

20 participants
18 discussions

Start a nNew thread

Midori 0.4.7 for Fedora 17?
by Heiko Adams 09 Jan '13

09 Jan '13

Hi, will Feodra 17 or even the Xfce 4.10 siderepo get updated packages for midori 0.4.7? -- Regards, Heiko Adams

4 8

Re: saving space on the Xfce Spin
by Raphael Groner 29 Oct '12

29 Oct '12

I think, we can't get completely rid of webkit. Further, there's Fancy HTML Viewer: "This [claws-mail] plugin renders HTML mail using the WebKit 1.8.1 library." So IMHO better remove all XULRunner related stuff. :p To be honest, I don't know anybody that still prefers Firefox over Chromium. Though, Chromium would be too much overkill for a live cd that's called Xfce. That's only as a side note, I wouldn't bring in Chromium in this saving space discussion. Midori is good for most of the common web pages, I know about a few pages where it sucks, but no matter in our case. -R. > Date: Sat, 27 Oct 2012 18:28:09 +0100 > From: Frank Murphy <frankly3d(a)gmail.com> > To: xfce(a)lists.fedoraproject.org > Subject: Re: saving space on the Xfce Spin > Message-ID: <508c19aa.475fb40a.435a.ffffed90(a)mx.google.com> > Content-Type: text/plain; charset=US-ASCII > > On Sat, 27 Oct 2012 14:34:35 -0200 > Sergio <secipolla(a)gmail.com> wrote: > > > > > > > > > remove liferea? > > > > > > > He meant that by removing both Midori and Liferea then there would > > be space saving (IIRC due to webkit-gtk). > > > > I meant you could replace liferea with the claws-mail plugin for rss > needs. It's still 500k, sometimes small steps.

6 8

saving space on the Xfce Spin
by Christoph Wickert 29 Oct '12

29 Oct '12

Hi, currently the Xfce spin is overweight, at least for x86_64. It's 726M, that is 30M more than i686, but this seems normal. That means that we need to find a way to save 26M. First thing that comes to my mind are the gnome packages we ship: # rpm -qa --qf %{NAME}-%{VERSION}-%{VERSION}\\n| grep gnome | sort desktop-backgrounds-gnome-18.0.0-18.0.0 gnome-bluetooth-libs-3.6.0-3.6.0 gnome-desktop3-3.6.0.1-3.6.0.1 gnome-icon-theme-3.6.0-3.6.0 gnome-icon-theme-legacy-3.6.0-3.6.0 gnome-icon-theme-symbolic-3.6.0-3.6.0 gnome-keyring-3.6.0-3.6.0 gnome-python2-2.28.1-2.28.1 gnome-python2-bonobo-2.28.1-2.28.1 gnome-python2-canvas-2.28.1-2.28.1 gnome-python2-desktop-2.32.0-2.32.0 gnome-python2-gconf-2.28.1-2.28.1 gnome-python2-gnome-2.28.1-2.28.1 gnome-python2-gnomekeyring-2.32.0-2.32.0 gnome-python2-gnomevfs-2.28.1-2.28.1 gnome-session-3.6.0-3.6.0 gnome-themes-2.32.0-2.32.0 gnome-themes-standard-3.6.0.2-3.6.0.2 gnome-vfs2-2.24.4-2.24.4 gnome-video-effects-0.4.0-0.4.0 imsettings-gnome-1.3.1-1.3.1 libgnome-2.32.1-2.32.1 libgnomecanvas-2.30.3-2.30.3 libgnomekbd-3.6.0-3.6.0 libgnome-keyring-3.6.0-3.6.0 libgnomeui-2.24.5-2.24.5 libopenraw-gnome-0.0.8-0.0.8 polkit-gnome-0.105-0.105 spherical-cow-backgrounds-gnome-17.92.0-17.92.0 Next I investigated their dependencies. First is the package name and then what pulls it in. Dependencies are marked with -> while a colon indicates a new package or dependency chain: * desktop-backgrounds-gnome: system-backgrounds-gnome (virtual provides of spherical-cow-backgrounds-gnome) -> gnome-desktop3 -> cheese * gnome-bluetooth-libs: nm-connection-editor -> anaconda and NetworkManager * gnome-desktop3: cheese (it only requires libgnome-desktop3) * gnome-icon-theme: system-config-printer, gnome-themes-standard -> gnome-desktop3 -> cheese, nm-connection-editor, network-manager-applet, gnome-themes * gnome-icon-theme-legacy: libxfcegui4, ibus-gtk2 * gnome-icon-theme-symbolic: anaconda-18.8-2.fc18.i686 * gnome-keyring * gnome-python2: gnome-python2-* * gnome-python2-bonobo: blueman -> dbus-bluez-pin-helper (virtual provides) -> bluez * gnome-python2-canvas: gnome-python2-bonobo -> blueman, system-config-date -> firstboot, gnome-python2-gnome -> gnome-python2-desktop -> gnome-python2-gnomekeyring -> system-config-printer * gnome-python2-desktop: ... (see above) -> system-config-printer * gnome-python2-gconf: blueman * gnome-python2-gnome: blueman * gnome-python2-gnomekeyring: system-config-printer * gnome-python2-gnomevfs: gnome-python2-gnome -> blueman * gnome-session: blueman (update without this dep is pending) * gnome-themes: fedora-icon-theme * gnome-themes-standard: gnome-desktop3 -> cheese * gnome-vfs2: gnome-python2-gnomevfs -> blueman * gnome-video-effects: cheese * imsettings-gnome: ibus * libgnome: gnome-python2-bonobo, gnome-python2-gnome, libgnomeui, libbonoboui -> blueman, bluez * libgnomecanvas: gnome-python2-canvas (see above) * libgnomekbd: ibus, anaconda * libgnome-keyring: gnome-python2-gnomekeyring -> system-config-printer * libgnomeui: gnome-python2-gnome -> blueman * libopenraw-gnome: ristretto and tumbler * polkit-gnome: we use this one * spherical-cow-backgrounds-gnome: gnome-desktop3 -> cheese Observations: * As for the libraries, there is nothing we can do. They are not big either. * Same goes for the gnome-python2-* packages. Most of them are required by blueman or by system-config-* stuff. blueman adds ~23M (installed size, not iso size), but compared to gnome-bluetooth and it's dependencies, it is still good (~130M!) * gnome-desktop3 is big and has a lot of deps (themes!), while we only need the libgnome-desktop-3 for cheese. That's why I filed https://bugzilla.redhat.com/show_bug.cgi?id=693545 but I don't think it will be fixed, at least not in time for F18. * libxfcegui4 depdends on gnome-icon-theme-legacy. This is a workaround to prevent missing icons (#647734 and #650504). The legacy package depends on gnome-icon-theme and only provides symlinks from the old icon names to new freedesktop.org names. Unfortunately Xfce still hardcodes a lot of old names, even in 4.10. We need to work with the Xfce developers to fix this for Xfce 4.12 and then we can remove this ugly dependency. It's definitely too late to do this for F18 now - unless somebody has time to look into this. * We only have gnome-themes in the spin because it is a dependency of fedora-icon-theme. And this is weird: The Fedora theme inherits the 'Mist', which is part of gnome-themes. We could make two separate packages mist-icon-theme and crux-icon-theme, but I wonder if fedora-icon-theme should inherit 'Mist' in first place. AFAIK GNOME now now uses gnome-icon-theme. Next I looked how much space we could save if we remove packages. I tested this with 'yum remove --remove-leaves foo' on the live system, so again, this is installed size, not iso size: 78M cheese (gnome-desktop3 and wallpapers, gstreamer1) 61M firefox (xulrunner) 45M midori and liferea (webkitgtk) 33M claws-mail and plugins 33M pidgin 33M gnumeric 32M abiword 23M blueman 14M claws-mail-plugins-bogofilter (bogofilter, gsl, atlas) 14M abrt-desktop 12M geany 8.3M xfce4-icon-theme 7.8M pavucontrol 6.3M seahorse 6.3M transmission 5.3M xfburn 5.1M orage 4M midori 4.1M system-config-printer 3.5M remmina 2.7M lifearea 2.5M xfce4-screenshooter 2.2M parole 1.6M gnome-session (will be gone when the blueman update is stable) 1.5M asunder 1.5M xarchiver 1.4M xfce4-clipman-plugin 1.3M iok 1.1M ristretto 955k pragha 690k galcultor 529K xfce4-dict + -plugin 518k xfce4-notes-plugin 466k xfce4-mixer (we would need to package the panel plugin separate and make it launch pavucontrol) 396k epdfview 226k setroubleshoot 187k catfish Conclusion: * Xfce components are small, it does not make sense to remove any of them. The only exception is xfce4-icon-theme. * The killer is cheese. It's not only the the gnome-desktop3 problem I explained earlier, but also that it uses gstreamer 1.0. This means we would install two complete gstreamer stacks or we would have to build xfce4-mixer, pragha and parole and with gstreamer 1.0, too. Not sure if this is already possible. * Removing midori or lifearea doesn't save much space, but removing both of them makes a huge difference because we don't need webkitgtk. Suggestions: 1. Drop xfce4-icon-theme, it's broken anyway. I suggest to mark it as "optional" in comps so it no longer gets installed by default (and on the spin). 2. Drop claws-mail-plugins-bogofilter, people will hardly notice it. 3. Drop cheese, at least if we cannot get gnome-desktop3 split up. xfce4-icon-theme and claws-mail-plugins-bogofilter will not help us much, but cheese alone could do the trick. 4. Get rid of one browser, either firefox or midori. midori only makes sense if we also remove lifearea. Additional packages: There are two more packages I'd like to see in the spin. 1. For some reason, net-tools doesn't get installed, so there is no ifconfig. It's only 294k. 2. I's like to see the new mousepad version in the spin, but unfortunately it adds another 4.1 through it's dependency to gtksourceview2. leafpad on the other hand is only 322k. I suggest to first discuss this a little here on this list and once we have agreed on something, we'll move forward with the bug at https://bugzilla.redhat.com/show_bug.cgi?id=853590 Best regards, Christoph

9 24

Claws-mail keep message?
by Frank Murphy 28 Oct '12

28 Oct '12

One thing I havn't figured out, how to keep an email. In TB you starred a mail, and in the account properties, went never delete starred message. What's the equivalent in claws-mail. -- Regards, Frank

1 0

candidate for Xfce comps
by Tim Lauridsen 24 Oct '12

24 Oct '12

Hi Are any reason why xfce-volumed is not in the comps for xfce live cd, it is great to have keyboard volume ud/down working out of the box and it is only 68Kb Name : xfce4-volumed Version : 0.1.13 Release : 4.fc18 Architecture: x86_64 Install Date: Tue 23 Oct 2012 12:15:41 PM EDT Group : User Interface/Desktops Size : 68060 License : GPLv3+ Signature : RSA/SHA256, Wed 08 Aug 2012 06:44:50 PM EDT, Key ID ff01125cde7f38bd Source RPM : xfce4-volumed-0.1.13-4.fc18.src.rpm Build Date : Sun 22 Jul 2012 09:04:08 AM EDT Build Host : buildhw-01.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : https://launchpad.net/xfce4-volumed Summary : Daemon to add additional functionality to the volume keys of the keyboard Description : The xfce4-volumed adds additional functionality to the volume up/down and mute keys of the keyboard. It makes the keys work without configuration and uses the XFCE 4 mixer's defined card and track for choosing which track to act on. The volume level is shown in a notification. Best Regards, Tim

2 2

Re: heads up about f18+ and lid/power buttons
by Raphael Groner 23 Oct '12

23 Oct '12

Am Mon, 22 Oct 2012 12:00:10 +0000 schrieb xfce-request(a)lists.fedoraproject.org: > Date: Sun, 21 Oct 2012 12:24:51 -0600 > From: Kevin Fenzi <kevin(a)scrye.com> > To: xfce(a)lists.fedoraproject.org > Subject: Re: heads up about f18+ and lid/power buttons > Message-ID: <20121021122451.7789739c(a)jelerak.scrye.com> > Content-Type: text/plain; charset="utf-8" > {…} > I think the best option here is for xfce4-power-manager to inhibit > systemd when it's running and handle all those events as the user > wishes. Unfortunately, that requires upstream code. As written already: Maybe it's better to disable systemd's power management for the Xfce spin, till all that issues are fixed for sure. Look into /etc/systemd/logind.conf, propably a working solution so far for the Xfce Live CD. On installed systems, the user should be able to decide what component is allowed to handle power management, it can go well with a disabled systemd component in case of xfce4-power-manager, or in doubt then vice-versa. I wonder if that can be an upstream solution for the long run, and what other distribution with usage of systemd as a replacement for init would do about this issue here. > kevin Raphael

2 1

Re: Re: heads up about f18+ and lid/power buttons
by Raphael Groner 21 Oct '12

21 Oct '12

Hi Kevin, thanks for giving the hint for the workaround to inhibit systemd trying to take over the lid handling. This is not senseful for Xfce systems, right! I am on a freshly updated Manjaro system (ArchLinux) here. So this issue has nothing to do with Fedora in particular and should be handled upstream somewhere, either systemd (looks for other power managers already active in the system, maybe…) or desktop handlers should instruct systemd as the backend what to do. That design needs clearly rethinking, IMHO. I've added a comment to the upstream bug. -R. > Just a note here in case any folks run into it before we fix it. > > systemd now by default handles lid button, power button, etc. > > This means that if you have xfce4-power-manager and have it doing > something different from 'suspend' on lid close (I have mine set to > "lock screen"), systemd will suspend for you. > > You can work around this by setting a startup command: > > systemd-inhibit --mode=block --what=handle-lid-switch sleep 1000000 & > > Ideally we would fix this in xfce4-power-manager and it would inhibit > anything that it wants to handle itself. Failing that, we could add > the inhibit to startxfce4, but that means that none of those buttons > would get handled if xfce4-power-manager wasn't installed or running. > > See upstream bugs: > https://bugzilla.xfce.org/show_bug.cgi?id=9326 > https://bugzilla.xfce.org/show_bug.cgi?id=9335 > > kevin

3 4

Re: heads up about f18+ and lid/power buttons
by Raphael Groner 21 Oct '12

21 Oct '12

Date: Sun, 21 Oct 2012 09:20:17 -0200 From: Sergio <secipolla(a)gmail.com> To: xfce(a)lists.fedoraproject.org Subject: Re: heads up about f18+ and lid/power buttons Message-ID: <5083DA71.5030909(a)gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed > I know the people who are going to take care of this will define the > approach but nowadays (in Fedora 17) there is acpid that can take > care of these power related button presses. > It checks if gnome or xfce4 power-manager are running and if so it > disables itself. > > Just reminding. +1 That's exactly the point. By re-implementing such "features", not only acpid gets a lot of redundancy, but also upower. And that means unneeded bugs bugs bugs. Nice little approaches and related projects are being killed with one single growing complex system component [*]. SCNR For a desktop distribution, power management should be kept configurable for the individual user, no matter what desktop environment she uses, with a nice settings dialog, just like xfce4-power-manager does. XFPM uses DBus to call the power functionalities and it doesn't matter what backend is there to implement those power functions, e.g. consolekit/upower or (some part of) systemd. IMHO There should be more love available for systemd support from the general non-Gnome developers site. -R. [*] http://lwn.net/Articles/447932/

2 1

Re: heads up about f18+ and lid/power buttons
by Raphael Groner 20 Oct '12

20 Oct '12

Hi, as it seems, Fedora has several other issues with systemd's inhibit. system hibernation should be prohibited after kernel update https://bugzilla.redhat.com/show_bug.cgi?id=843014 Systemd service should inhibit suspend while remote users are logged in via ssh https://bugzilla.redhat.com/show_bug.cgi?id=837109 Maybe it's better to disable systemd power management for the Xfce spin, till all that issues are fixed for sure. -R. > Date: Sat, 20 Oct 2012 10:29:52 +0200 > From: Raphael Groner <raphgro(a)web.de> > To: xfce(a)lists.fedoraproject.org > Subject: Re: Re: heads up about f18+ and lid/power buttons > Message-ID: <20121020102952.49cd3574@schlebby> > Content-Type: text/plain; charset=UTF-8 > > Hi Kevin, > > thanks for giving the hint for the workaround to inhibit systemd > trying to take over the lid handling. This is not senseful for Xfce > systems, right! > > I am on a freshly updated Manjaro system (ArchLinux) here. So this > issue has nothing to do with Fedora in particular and should be > handled upstream somewhere, either systemd (looks for other power > managers already active in the system, maybe…) or desktop handlers > should instruct systemd as the backend what to do. That design needs > clearly rethinking, IMHO. > > I've added a comment to the upstream bug. > > -R. > > > > Just a note here in case any folks run into it before we fix it. > > > > systemd now by default handles lid button, power button, etc. > > > > This means that if you have xfce4-power-manager and have it doing > > something different from 'suspend' on lid close (I have mine set to > > "lock screen"), systemd will suspend for you. > > > > You can work around this by setting a startup command: > > > > systemd-inhibit --mode=block --what=handle-lid-switch sleep 1000000 > > & > > > > Ideally we would fix this in xfce4-power-manager and it would > > inhibit anything that it wants to handle itself. Failing that, we > > could add the inhibit to startxfce4, but that means that none of > > those buttons would get handled if xfce4-power-manager wasn't > > installed or running. > > > > See upstream bugs: > > https://bugzilla.xfce.org/show_bug.cgi?id=9326 > > https://bugzilla.xfce.org/show_bug.cgi?id=9335 > > > > kevin

1 0

preliminary patch with GStreamer 1.0 support for Parole
by Dan Horák 17 Oct '12

17 Oct '12

Hi, attached is the preliminary patch I wrote during FUDCon hackfest day that makes Parole build with both GStreamer 0.10 and the new 1.0. It's made similar how Pragha adds GStreamer 1.0 to its sources. Parole builds fine with both versions, but seems to segfault with 1.0 on f18 for me. The quite long GStreamer 1.0 porting notes are at [1] With regards, Dan [1] http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random/porting-to…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

xfce October 2012