Midori 0.4.7 for Fedora 17?
by Heiko Adams
Hi,
will Feodra 17 or even the Xfce 4.10 siderepo get updated packages for
midori 0.4.7?
--
Regards,
Heiko Adams
11 years, 3 months
Re: saving space on the Xfce Spin
by Raphael Groner
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.
11 years, 5 months
saving space on the Xfce Spin
by Christoph Wickert
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
11 years, 5 months
Claws-mail keep message?
by Frank Murphy
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
11 years, 5 months
candidate for Xfce comps
by Tim Lauridsen
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
11 years, 6 months
Re: heads up about f18+ and lid/power buttons
by Raphael Groner
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
11 years, 6 months
Re: Re: heads up about f18+ and lid/power buttons
by Raphael Groner
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
11 years, 6 months
Re: heads up about f18+ and lid/power buttons
by Raphael Groner
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/
11 years, 6 months
Re: heads up about f18+ and lid/power buttons
by Raphael Groner
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
11 years, 6 months
