set the time??
by Beartooth
How do I tell xfce to use the local timeservers?
--
Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User
I have precious (very precious!) little idea where up is.
10 years, 7 months
Power manager issues (double wake up, etc.)
by Miro Hrončok
Hi,
because of previous incompatibility with xfce4-power-manager-settings
and /etc/systemd/logind.conf, I've disabled every action in logind.conf
by setting things to ignore.
Yesterday, I've finally managed to comment that out and set things
properly in xfce4-power-manager-settings as desired.
Here is what I want and what I have set in the
xfce4-power-manager-settings (except using slock, because there is no
option for used screen lock):
- When I am not connected to AC and I close the lid, lock the screen
(with slock), but do not suspend/hibernate/whatever. When I am
connected, do not lock.
- When pressed any of the buttons poweroff/suspend/hibernate, ask for
action.
- When suspending/hibernate, lock the screen with slock.
Here is, what really happens:
- Closing lid and using slock to lock the screen (only without AC) works
as expected.
- When I press poweroff or suspend button, I am only asked sometimes,
sometimes nothing happens. (When I change the action from Ask to
Suspend, it works the same, only goes to suspend sometimes, sometimes
nothing happens)
- When going to suspend and wake up, screen is unlocked.
- When I open the lid when suspended, PC wakes up (as expected), but
goes to suspend immediately again, but when I wake up for the second
time, it's not going again to suspend, it's not an infinite loop.
Basicaly, I have to wake up twice (open the lid, wake up, suspend, press
power on, wake up).
I'm using Fedora 18 64bit on Lenovo Thinpad X230. I have no idea, what's
wrong, or whom to report this.
Thanks for any help.
--
Miro Hrončok
--
Phone: +420777974800
Jabber: miro(a)hroncok.cz
10 years, 9 months
Re: pyupdatesd: A Yum Updates Tray Icon for XFCE
by Noah Petherbridge
@Heiko:
I just installed the Fedora 19 Alpha in VirtualBox, downloaded
pyupdatesd and then modified its configuration section to change the
"interval" from 900 seconds down to 10 (to get quicker feedback on
whether the script is working or not). It worked for me. After about 10
seconds from running the script, the tray icon and message appeared, and
clicking it brought me to the yumex GUI.
This script waits /at least/ until the interval is first reached (i.e.
15 minutes after the script is run, in the default configuration),
before it runs `yum check-update` to see if there are updates. When
there are, `yum check-update` exits with status 100, and that's how the
script knows when to show the icon and notification. If this isn't
working, can you try debugging it? Around this part of the code, you can
have it print the status and output of check-update:
if int(time()) >= next_check:
status, output = commands.getstatusoutput(c['check'])
status = status >> 8
+ print "status:", status
+ print "output:", output
# Updates?
if status == 100:
Also the results of running, in bash: `yum check-update; echo $?`
@Frank:
Make sure you're running the script from within X11 (so that $DISPLAY is
set). I see that error message if I attempt to run the script from text
mode. ;) In my XFCE desktop, adding the script to my session startup
list works for me.
$ cat ~/.config/autostart/Update\ Daemon.desktop
[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=Update Daemon
Comment=
Exec=/home/kirsle/bin/pyupdatesd
OnlyShowIn=XFCE;
StartupNotify=false
Terminal=false
Hidden=false
-Noah
On 05/26/2013 05:00 AM, xfce-request(a)lists.fedoraproject.org wrote:
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 26 May 2013 09:37:52 +0200
> From: Heiko Adams <heiko.adams(a)gmail.com>
> To: Fedora Xfce users and developers <xfce(a)lists.fedoraproject.org>
> Subject: Re: pyupdatesd: A Yum Updates Tray Icon for XFCE
> Message-ID: <51A1BBD0.2020707(a)gmail.com>
> Content-Type: text/plain; charset=UTF-8
> Hi,
> it looks like your script doesn't work on Fedora 19. I've tested it this
> morning and absolutely nothing happened. No errormessages but also no
> notifications about new updates - but updates were available.
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 26 May 2013 09:41:10 +0100
> From: Frank Murphy <frankly3d(a)gmail.com>
> To: xfce(a)lists.fedoraproject.org
> Subject: Re: pyupdatesd: A Yum Updates Tray Icon for XFCE
> Message-ID: <51a1caa8.c248b40a.5742.ffffb486(a)mx.google.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Fri, 24 May 2013 14:15:50 -0700
> Noah Petherbridge <root(a)kirsle.net> wrote:
>
> Fedora 18.x86_64
>
> traceback (most recent call last):
> File "/etc/sysconfig/pyupdatesd", line 55, in <module>
> import gtk
> File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py",
> line 64, in <module> _init()
> File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py",
> line 52, in _init _gtk.init_check()
> RuntimeError: could not open display
>
> -- Regards, Frank - I check for new mail app. 20min www.frankly3d.com
10 years, 10 months
4.10 for SL?
by Todd And Margo Chester
Hi All,
Will we ever see Xfce 4.10 support for Scientific Linux 6.4?
Many thanks,
-T
10 years, 11 months
Re: Download manager
by Raphael Groner
Hi Christoph,
thanks for your reply and your opinion.
Gwget - If you ask me, I would keep gwget packaged while it is working
and it seems still to do the easy job currently. Right, it should be
removed from Fedora when upstream doesn't care any more about new
guidelines. I guess Gwget is irrelevant in regard to Gnome3 goals.
flareGet - commercialized crap on Sourceforge (yes, Sourceforge!).
Forget about it, it makes no sense for Fedora.
MultiGet - dead upstream, okay. Just wondered why not packaged.
Steadyflow vs. uGet - thanks for the hint.
. How usable is the GUI? I am still considering uGet as feature
complete.
. I don't understand the argument with the bigger package size
towards lesser features. Why was Firefox then removed from the image
due to size limitation but OpenJDK is kept cause of usability? Maybe
this is marketing talk, dunno.
. uGet seems to lack translation work, that's true. For instance, the
german po is incomplete.
. Better integration of Steadyflow into Midori has no value. uGet has a
nice clipboad monitor that brings up a download window just after
copying the link from the browser.
Another 2¢ in the box.
-R.
Am Thu, 30 May 2013 12:00:04 +0000
schrieb xfce-request(a)lists.fedoraproject.org:
> Date: Wed, 29 May 2013 22:18:18 +0200
> From: Christoph Wickert <christoph.wickert(a)gmail.com>
> To: xfce(a)lists.fedoraproject.org
> Subject: Re: Download manager
> Message-ID: <1369858698.32493.12.camel(a)thinkmatic.localdomain>
> Content-Type: text/plain; charset="UTF-8"
>
> Am Mittwoch, den 29.05.2013, 15:18 +0200 schrieb Raphael Groner:
> > I would like to see a download
> > manager included in the live image, especially Xfce. There are
> > several dl managers available on the base of Gtk.
> >
> > - gwget
> > ** already packaged but upstream is dead(?), patches available
>
> Where? What for?
>
> Frankly speaking I am considering to orphan gwget. It's dead for
> years.
>
> > - flareGet
> > ** not (yet) packaged in Fedora
> > ** ships browser integration: firefox, chrome, chromium, opera etc.
> > ** also available for win_ows (so people may feel at home :P )
> > ** semi-commercial license model, may be difficult for Fedora
> > http://flareget.com/features
>
> I cannot find the code anywhere. What license is it?
>
> > - MultiGet
> > ** not (yet) packaged in Fedora
> > ** also available for win_ows (so people may feel at home :P )
> > ** multiple mirrors for one download possible
> > ** wxWidgets for the GUI, so it means another unwanted dependency
> > ** Does anyone know what concrete license it has? I can't find it.
> > http://multiget.sourceforge.net/
>
> It's packaged but orphaned as it is dead upstream.
> https://admin.fedoraproject.org/pkgdb/acls/name/multiget
>
> > - uGet
> > ** already packaged and actively maintained
> > ** similiar to gwget and multiget, but even more feature-rich
> > ** optional support for Aria2, instead of direct curl usage
> > ** browser integration could be easily done via incl. clipboard
> > monitor
>
> Looks nice IHMO it's too overblown for Xfce.
>
> > I would prefer uGet cause it seems to need the lowest effort to
> > integrate it to live image.
>
> I would suggest steadyflow. It's lean slick interface fits Xfce
> better I think. It's is a little bigger than uget (768k compared to
> 560k) but this mainly due to the translations - and I consider proper
> localization important.
>
> However I am not sure if we need a download manager anyway. We
> already ship a webbrowser with download manager. This should do for
> most people, I don't want to duplicate functionality. For each task,
> we should have one program in the default install.
>
> Just my 2¢.
>
> Best regards,
> Christoph
10 years, 11 months
Download manager
by Raphael Groner
Hi,
to complete the request show (SCNR), I would like to see a download
manager included in the live image, especially Xfce. There are several
dl managers available on the base of Gtk.
- gwget
** already packaged but upstream is dead(?), patches available
- flareGet
** not (yet) packaged in Fedora
** ships browser integration: firefox, chrome, chromium, opera etc.
** also available for win_ows (so people may feel at home :P )
** semi-commercial license model, may be difficult for Fedora
http://flareget.com/features
- MultiGet
** not (yet) packaged in Fedora
** also available for win_ows (so people may feel at home :P )
** multiple mirrors for one download possible
** wxWidgets for the GUI, so it means another unwanted dependency
** Does anyone know what concrete license it has? I can't find it.
http://multiget.sourceforge.net/
- uGet
** already packaged and actively maintained
** similiar to gwget and multiget, but even more feature-rich
** optional support for Aria2, instead of direct curl usage
** browser integration could be easily done via incl. clipboard monitor
I would prefer uGet cause it seems to need the lowest effort to
integrate it to live image.
$ $ yum deplist uget | grep provider | sort | uniq -c
1 provider: atk.x86_64 2.6.0-1.fc18
1 provider: bash.x86_64 4.2.45-1.fc18
1 provider: cairo-gobject.x86_64 1.12.14-1.fc18
1 provider: cairo.x86_64 1.12.14-1.fc18
1 provider: gdk-pixbuf2.x86_64 2.26.5-1.fc18
5 provider: glib2.x86_64 2.34.2-2.fc18
1 provider: glibc.i686 2.16-31.fc18
8 provider: glibc.x86_64 2.16-31.fc18
1 provider: gstreamer1.x86_64 1.0.7-1.fc18
2 provider: gtk3.x86_64 3.6.4-1.fc18
1 provider: libcurl.x86_64 7.27.0-10.fc18
1 provider: libnotify.x86_64 0.7.5-3.fc18
2 provider: pango.x86_64 1.32.3-1.fc18
$ du -hs $(rpm -ql uget)
268K /usr/bin/uget-gtk
4,0K /usr/share/applications/uget-gtk.desktop
48K /usr/share/doc/uget-1.10.3
12K /usr/share/icons/hicolor/128x128/apps/uget-icon.png
4,0K /usr/share/icons/hicolor/16x16/apps/uget-icon.png
4,0K /usr/share/icons/hicolor/16x16/apps/uget-tray-default.png
4,0K /usr/share/icons/hicolor/16x16/apps/uget-tray-downloading.png
4,0K /usr/share/icons/hicolor/16x16/apps/uget-tray-error.png
4,0K /usr/share/icons/hicolor/22x22/apps/uget-icon.png
4,0K /usr/share/icons/hicolor/22x22/apps/uget-tray-default.png
4,0K /usr/share/icons/hicolor/22x22/apps/uget-tray-downloading.png
4,0K /usr/share/icons/hicolor/22x22/apps/uget-tray-error.png
4,0K /usr/share/icons/hicolor/24x24/apps/uget-icon.png
4,0K /usr/share/icons/hicolor/24x24/apps/uget-tray-default.png
4,0K /usr/share/icons/hicolor/24x24/apps/uget-tray-downloading.png
4,0K /usr/share/icons/hicolor/24x24/apps/uget-tray-error.png
4,0K /usr/share/icons/hicolor/32x32/apps/uget-icon.png
4,0K /usr/share/icons/hicolor/32x32/apps/uget-tray-default.png
4,0K /usr/share/icons/hicolor/32x32/apps/uget-tray-downloading.png
4,0K /usr/share/icons/hicolor/32x32/apps/uget-tray-error.png
4,0K /usr/share/icons/hicolor/48x48/apps/uget-icon.png
4,0K /usr/share/icons/hicolor/48x48/apps/uget-tray-default.png
4,0K /usr/share/icons/hicolor/48x48/apps/uget-tray-downloading.png
4,0K /usr/share/icons/hicolor/48x48/apps/uget-tray-error.png
8,0K /usr/share/icons/hicolor/64x64/apps/uget-icon.png
8,0K /usr/share/icons/hicolor/96x96/apps/uget-icon.png
20K /usr/share/icons/hicolor/scalable/apps/uget-icon.svg
20K /usr/share/locale/be/LC_MESSAGES/uget.mo
16K /usr/share/locale/cs/LC_MESSAGES/uget.mo
8,0K /usr/share/locale/de/LC_MESSAGES/uget.mo
12K /usr/share/locale/es/LC_MESSAGES/uget.mo
16K /usr/share/locale/fr/LC_MESSAGES/uget.mo
16K /usr/share/locale/hu/LC_MESSAGES/uget.mo
16K /usr/share/locale/it/LC_MESSAGES/uget.mo
16K /usr/share/locale/pl/LC_MESSAGES/uget.mo
16K /usr/share/locale/ru/LC_MESSAGES/uget.mo
12K /usr/share/locale/tr/LC_MESSAGES/uget.mo
16K /usr/share/locale/uk/LC_MESSAGES/uget.mo
16K /usr/share/locale/zh_CN/LC_MESSAGES/uget.mo
16K /usr/share/locale/zh_TW/LC_MESSGES/uget.mo
20K /usr/share/pixmaps/uget
16K /usr/share/sounds/uget
What you guys think?
-R.
10 years, 11 months
pyupdatesd: A Yum Updates Tray Icon for XFCE
by Noah Petherbridge
A few versions ago in Fedora (v15), the PackageKit daemon doesn't work
in XFCE anymore, so I wrote a small Perl Gtk2 app that would watch for
available yum updates and put a tray icon in your Notification Area to
notify you (Perl version: http://sh.kirsle.net/kupdatesd)
I've recently ported the app over to Python 2. I heard that the Fedora
XFCE spins are going to drop Perl (or at least severely shrink the Perl
installation) to save space, so the Python version of this app will be
useful going forward (on my current Fedora 18 XFCE desktops, pygtk2 was
already installed, which is pretty much this script's only dependency). :)
Source code to pyupdatesd: http://sh.kirsle.net/pyupdatesd- this code is
open domain and you can do with it what you please. It would be neat if
this could be shipped with future releases of the Fedora XFCE spin.
Here's the source code here also, in case the links are down. This
version has only been lightly tested (I literally just finished writing
it an hour ago), but seems to work so far.
_____________________________________
#!/usr/bin/env python
"""
pyupdatesd: A simple yum update checker.
This script will watch for available yum updates and show a Gtk2 tray icon and
notification pop-up when updates become available.
This is intended for desktop environments like XFCE that don't have a native
PackageKit update watcher.
Set this script to run on session startup, and it will check for updates every
15 minutes (by default; this is configurable in the source code).
This software is open domain and may be freely modified and distributed.
Requires: pygtk2
--Kirsle
http://sh.kirsle.net
"""
################################################################################
# Configuration Section Begins Here #
################################################################################
c = dict(
# The title to be shown on the pop-up and the icon tooltip.
title = "Updates Available",
# The message to be shown in the pop-up.
message = "There are updates available to install.",
# Icon to use in the system tray and pop-up.
icon = "/usr/share/icons/gnome/32x32/status/software-update-available.png",
# Frequency to check for available updates.
interval = 900, # 15 minutes
# Command to run to check for available updates, and the expected status
# code that indicates updates are available.
check = "/usr/bin/yum check-update",
# Path to notify-send (set to None if you don't want notifications)
notify = "/usr/bin/notify-send",
# Command to run for your graphical updater (i.e. yumex, gpk-update-viewer)
gui = "/usr/bin/yumex",
)
################################################################################
# Configuration Section Ends Here #
################################################################################
import gtk
import gobject
import commands
import subprocess
from time import time
def do_updates():
"""Show your graphical update manager."""
subprocess.call(c['gui'], shell=True)
def onClick(widget):
"""Event handler for the tray icon being clicked."""
widget.set_visible(False)
gobject.timeout_add(1, do_updates)
def show_notify():
subprocess.call([c['notify'],
'-a', __name__,
'-i', c['icon'],
c['message'],
])
tray = gtk.StatusIcon()
tray.set_from_file(c['icon'])
tray.set_title(c['title'])
tray.set_tooltip(c['title'])
tray.set_visible(False)
tray.connect('activate', onClick)
next_check = int(time()) + c['interval']
def main_loop():
# Time to check?
global next_check
if int(time()) >= next_check:
status, output = commands.getstatusoutput(c['check'])
status = status >> 8
# Updates?
if status == 100:
tray.set_visible(True)
show_notify()
elif tray.get_visible() == True and status == 0:
# Updates have disappeared behind our back!
tray.set_visible(False)
next_check = int(time()) + c['interval']
gobject.timeout_add(1000, main_loop)
gobject.timeout_add(1000, main_loop)
gtk.main()
# vim:expandtab
10 years, 11 months
Update error
by Jim Dean
Getting an error when updating my 17 4.10 system, had it for a couple of
days. I left it thinking it might be sorted but no luck yet.
Package: xfce4-notifyd-0.2.4-1.fc17.x86_64 (updates)
Requires: libxfce4util.so.4()(64bit)
Available: libxfce4util-4.8.2-2.fc17.x86_64 (fedora)
libxfce4util.so.4()(64bit)
Installed: libxfce4util-4.10.0-1.fc17.x86_64 (@fedora-xfce-4.10)
Not found
Thanks
--
Jim Dean
10 years, 11 months
spins size changes
by Kevin Fenzi
Greetings.
We are coming up on Beta and thats when we start wanting to make sure
we hit our size target (700MB cd).
Beta-TC4 Xfce is at 756M
The issues around perl have been cleaned up, so removing perl only
removes the xfce4-sensors-plugin (and all the perl modules).
I went ahead and pushed a exo update to drop the perl update in it:
https://admin.fedoraproject.org/updates/FEDORA-2013-7881/exo-0.10.2-3.fc19
karma very welcome. Hopefully we can push it stable before Beta freeze.
With that update and removing perl and xfce4-sensors saves us ~40MB or
so on the uncompressed image (likely less on the iso).
I also removed:
foomatic-db-ppds
foomatic
(only used by really old printers)
stix-fonts
ibus-typing-booster
(large and not needed)
Those should save another ~40MB uncompressed (less on iso).
Also, I did a:
rm -f /usr/share/icons/HighContrast/icon-theme.cache
which the desktop folks are already doing. This cache can be
regenerated easily and we aren't using that icon theme by default.
This saves ~105MB uncompressed.
So, hopefully with all these we will drop the ~56MB we need.
If not we will need to look at more savings.
kevin
10 years, 11 months