Bugzilla Bug 103966

I'd like to request that the following desklets be keyworded to go in ~ARCH (if
they aren't already there):
x11-plugins/desklet-clock
x11-plugins/desklet-discreetclock
x11-plugins/desklet-ftb
x11-plugins/desklet-hypertail
x11-plugins/desklet-newsgrab
x11-plugins/desklet-regexp
x11-plugins/desklet-rsstickerbar
x11-plugins/desklet-scweather
x11-plugins/desklet-sidecandy
x11-plugins/desklet-sidecandygmail
x11-plugins/desklet-sidecandyrhythmbox
x11-plugins/desklet-wirelessmonitor

I'd also like to request that the following be tested for stability (and
keyworded if acceptable):
x11-plugins/desklet-clock/desklet-clock-0.50.ebuild
x11-plugins/desklet-starterbar/desklet-starterbar-0.31.3-r1.ebuild

Thanks!

desklet-clock - alpha needs to update, repoman wasn't happy
desklet-hypertail - Just ate cpu cycles, hung gdesklet up
desklet-rsstickerbar - Neat looking app, but. I couldn't get any of the
preconfigured feeds to work. I added slashdot, it pulled it up initially,
clicked another feed and came back, didn't pull it up again.
desklet-clock-0.50 - Can't stable till maintaining arch does
desklet-starterbar - already stable
desklet-sidecandygmail - I don't have a gmail account
desklet-wirelessmonitor - No wireless in my desktop, will try to test later on
my laptop

Ok, enough bad news ;) The following got marked ~amd64:
desklet-discreetclock
desklet-ftb
desklet-newsgrab
desklet-regexp
desklet-scweather
desklet-sidecandy
desklet-sidecandyrythmbox

Please verify that gnome-extra/gdesklets-core-0.35.2-r1 can be marked stable. 
I just touched it this morning to update the homepage and the last time I
touched it (more than a month ago), it was for a packaging improvement.  I've
been running it with no problems on ~x86 since I added it in August.

When I tried wirelessmonitor and newsgrab desklets, I had to start ignoring
error messages from these desklets.

clock desklet seems to work nicely.

starterbar desklet works, but when you want to change command for a specific
starter, it cannot be done - i still saw old command being run in console
output.

I'll test gnome-extra/gdesklets-core-0.35.2-r1 for x86.

desklet-hypertail does not play nice this version of gdesklets. It hangs the
gdesklets daemon for about 20 minutes, with CPU at 100%, then eventually it
starts.

That's been a problem since at least 0.35_rc1 (see bug 93989).  I'll restrict
that package to <gnome-extra/gdesklets-core-0.35_rc1.

Uh, it appears that after the first startup of 20 minutes, subsequent startups
of hypertail and/or gdesklets daemon work just fine. This is weird, byt maybe
we could not restrict the package, but warn our users of this issue.

I saw that you blocked desklet-hypertail. I confirm that I'm using it happily
since yesterday with gnome-extra/gdesklets-core-0.35.2-r1. Anyway, I'll mark
gdesklets-core as x86 stable tomorrow, if nothing wrong happens...

gnome-extra/gdesklets-core-0.35.2-r1 marked stable for x86.

Taking out ppc as all desklets are at least in ~ppc and
gnome-extra/gdesklets-core-0.35.2-r1 is stable.

Marked x11-plugins/desklet-clock-0.50 stable on x86.

I think we are done.  Re-add us if necessary.

gdesklets-core got stable on amd64

Doesn't seem to be playing nice for us (sparc) lately.
I'll revisit/try to fix/patch when i get some time (or maybe some other sparc
dev gets interested).

Most of these are now keyworded ~ia64, at least the ones that make sense (for
example we don't do wireless on ia64)

Added ~alpha keyword to the following:
  desklet-clock-0.50
  desklet-starterbar-0.31.3-r1
  desklet-discreetclock-0.3
  desklet-regexp-1.0
  desklet-hypertail-2.01-r1
  desklet-newsgrab-1.5
  desklet-scweather-0.4

The following were not keyworded:
  desklet-rsstickerbar
    Got an error "No such property: cursor The element label does not have the
cursor property."
  desklet-sidecandyrhythmbox
    We don't have rhythmbox keyworded.
  desklet-wirelessmonitor
    We don't have wireless-tools keyworded.

desklet-sidecandy-0.10 and desklet-ftb-0.3.2 both fail to properly detect CPU
frequency in the CPU monitor desklets. This is because the format of
/proc/cpuinfo is different on alpha. See my porting guide for details:
http://dev.gentoo.org/~tcort/docs/alpha-porting-guide.html#doc_chap7
I'll post patches for desklet-sidecandy-0.10 and desklet-ftb-0.3.2 to this bug
later this weekend. Once applied, I'll re-test and keyword them.

Created an attachment (id=85853) [edit]
gdesklets-core-0.35.3-alpha.patch

The CPU detection problem was actually in libdesklets. This patch fixes CPU
detection on alpha. I'll be sending a copy upstream.

You'll notice that it modifies a Makefile.am, this implies that if this patch
is applied by an ebuild you'll need to inherit the autotools eclass and run
eautoreconf.

In gdesklets-core-0.35.3 I noticed that it downloads gdesklets-develbook even
if I have USE="-doc". Maybe SRC_URI could be changed to:
SRC_URI="http://www.gdesklets.org/downloads/${MY_P}.tar.bz2 \
         doc? ( mirror://gentoo/gdesklets-develbook-${PV}.tar.bz2 )"

(In reply to comment #16)
> The CPU detection problem was actually in libdesklets. This patch fixes CPU
> detection on alpha. I'll be sending a copy upstream.

Thanks - if you don't mind, please CC me on the email.

> You'll notice that it modifies a Makefile.am, this implies that if this patch
> is applied by an ebuild you'll need to inherit the autotools eclass and run
> eautoreconf.

If the patch is accepted by upstream, I'll do this too.  Thanks for the info,
I've never had to use eautoreconf before.

> In gdesklets-core-0.35.3 I noticed that it downloads gdesklets-develbook even
> if I have USE="-doc". Maybe SRC_URI could be changed to:
> SRC_URI="http://www.gdesklets.org/downloads/${MY_P}.tar.bz2 \
>          doc? ( mirror://gentoo/gdesklets-develbook-${PV}.tar.bz2 )"

Done, thanks again!

Assuming your patch is accepted and that I can find some time to look into the
rsstickerbar problem, we can probably hold off on marking the latest
gdesklets-core stable until the next revision has been in for 30 days.  0.35.3
has been tested for so long already, I don't expect many problems with a
possible 0.35.3-r1.

I sent the patch upstream and they accepted it. nixphoeni added the patch to
gdesklets-core-0.35.3. I keyworded desklet-sidecandy-0.10 and desklet-ftb-0.3.2
~alpha. 

I think gdesklets-core-0.35.3 can be marked stable before the 2006.1 release,
considering that it has been out since mid-January and has no open bugs. 
tcort's patch for alpha was checked in May 27, so I'll leave it up to arch
teams (esp. alpha, since that's the only one it affects) to decide if it's
reasonable to break the "30 days in unstable" rule of thumb.

Also up for keywording/marking stable:
desklet-calendar - keyword on all but x86
desklet-weeklycalendar - keyword on all but x86
desklet-justanicon - keyword on all but x86 and ia64
desklet-rsstickerbar - keyword on all but x86, ia64, and ppc

desklet-discreetclock - mark stable on all but sparc
desklet-ftb - mark stable on all but sparc
desklet-scweather - mark stable on all

I'll check on the others when my dev box is back up again.  Seems like most of
these need some consideration to their compatibility with 0.35.3.  Thanks for
the help!

Not for SPARC, nope.
It doesn't work well, sometimes it doesn't even work.

desklet-ftb-0.3.2, desklet-scweather-0.4 and desklet-discreetclock-0.3 with
gdesklets-core-0.35.3  USE="-debug -doc" are working fine for me on x86.

Marked the following stable on alpha: gdesklets-core, desklet-discreetclock,
desklet-ftb, desklet-scweather

Added ~alpha to the following: desklet-calendar, desklet-weeklycalendar,
desklet-justanicon, desklet-rsstickerbar

desklet-hypertail-2.01-r1 wants an older version than gdesklets-core-0.35.3:

RDEPEND="<gnome-extra/gdesklets-core-0.35_rc1
         >=x11-plugins/desklet-regexp-1.0"


And gdesklets-core-0.35.3 doesn't seem to like pyorbit-2.14.0:

gDesklets will start a requirements check now...

Checking requirements:
 - sys ... found
 - xml.parsers.expat ... found
 - xml.sax ... found
 - gtk ... found
 - ORBit ... found
Version check failed.

ORBit python bindings (pyorbit) version == 2.0.1 are required.

gdesklets-core-0.35.3
1) emerges fine
2) passes collision test
3) won't start because of pyorbit != 2.0.1 (installed is 2.14), downgrade to
pyorbit 2.0.1 helps
4) maybe the last comment about finding gdesklets in the Gnome menu should be
LINGUA neutral (it uses the English menu names)


tested following desklets

x11-plugins/desklet-clock
x11-plugins/desklet-discreetclock
x11-plugins/desklet-ftb
x11-plugins/desklet-hypertail
x11-plugins/desklet-rsstickerbar
x11-plugins/desklet-sidecandy
x11-plugins/desklet-sidecandyrhythmbox

a) hypertail wants to pull in a lower version of core (already stated in
comment #23).
b) work so far


Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4,
2.6.16-gentoo-r13 i686)
=================================================================
System uname: 2.6.16-gentoo-r13 i686 AMD Athlon(tm) XP 2500+
Gentoo Base System version 1.6.15
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash
/etc/terminfo"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer
parallel-fetch sandbox sfperms strict test"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
LINGUAS="de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage"
USE="x86 3dnow 3dnowext X Xaw3d a52 alsa artworkextra asf audiofile avi
bash-completion beagle berkdb bidi bitmap-fonts bootsplash branding bzip2 cairo
cdda cddb cdparanoia cdr cli cracklib crypt css cups curl custom-cflags dbus
dga directfb divx4linux dlloader dri dts dvd dvdr dvdread dvi eds emacs emboss
encode esd evo exif expat fam fat fbcon fdftk ffmpeg firefox foomaticdb fortran
ftp gb gcj gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml hal icq idn
imagemagick imap imlib ipv6 isdnlog java javascript jikes jpeg jpeg2k ldap leim
libg++ libwww lm_sensors mad maildir matroska mbox mikmod mime mmx mmxext mng
mono motif mp3 mpeg mpeg2 mule nautilus ncurses nforce2 nls nocardbus nptl
nptlonly nsplugin nvidia ogg opengl pam pcre pdf pdflib perl plotutils pmu png
ppds pppd preview-latex print python qt qt3 qt4 quicktime readline reflection
reiserfs samba sdk session slang spell spl sse ssl svg svga t1lib tcltk tcpd
theora thunderbird tiff truetype truetype-fonts type1-fonts udev usb vcd videos
vorbis win32codecs wmf wxwindows xine xml xorg xosd xv xvid zlib elibc_glibc
input_devices_mouse input_devices_keyboard kernel_linux linguas_de userland_GNU
video_cards_radeon video_cards_vesa video_cards_fbdev"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

I've hit the ORBit version check failed bug too.

Checking requirements:
 - sys ... found
 - xml.parsers.expat ... found
 - xml.sax ... found
 - gtk ... found
 - ORBit ... found
Version check failed.

ORBit python bindings (pyorbit) version == 2.0.1 are required.

I have pyorbit-2.14.0 installed.

My arch: amd64

Tested on:
gdesklets-core-0.35.2-r1 (stable)
gdesklets-core-0.35.3 (~amd64)

Blindly downgrading pyorbit seems ugly to me.

fix deps?

(In reply to comment #25)
> I've hit the ORBit version check failed bug too.

Can you please open a new bug for this?  I'll make that a dependency of this
one and, since I can't duplicate it immediately, I'd like to discuss this
elsewhere.  I have pyorbit-2.14.0 and the only thing that fails is `gdesklets
check` (which is fixed with a simple patch).

(In reply to comment #23)
> desklet-hypertail-2.01-r1 wants an older version than gdesklets-core-0.35.3

As soon as I have some time to verify that it doesn't need that specific
version, I'll revert the deps.  Admittedly, I was too hasty on that originally.

When I tried to repeat the bug to open a new one, running `/usr/bin/gdesklets
start` nothing happened, gdesklet started.

Maybe logging out/logging in changed something in the environment that fixed
the startup check?

I use gdesklets-core-0.35.3 in ~amd64.

I'm really curious because except from logging out/in and reboots, nothing
happened on my system.

ORBit check fix in CVS.

OK, so what is the current request for arch teams to do ?

Original request was bunch of desklets to ~arch, two to stable arch. x86 has
that done. Is there anything else?

(In reply to comment #29)
> OK, so what is the current request for arch teams to do ?

Be patient :)

But seriously, since I just checked in a patch, I'll whine in 30 days or so to
stabilize gdesklets-core-0.35.3-r1.  I intended for this to be a tracker bug so
it'll always be open.  I'll add arch teams when I make a new request for
stabilization and they can remove themselves when it's done.  So for now, I
think it's okay to leave everything as it is.

Wonderful - so, in the name of cleaner buglist for x86 arch, see you. :)

status for amd64 is:

desklet-clock-0.50 amd64
desklet-starterbar-0.31.3-r1 amd64
desklet-discreetclock-0.3 ~amd64
desklet-ftb-0.3.2 ~amd64
desklet-hypertail-2.01-r1 ~amd64
desklet-newsgrab-1.5 ~amd64
desklet-regexp-1.0 ~amd64
desklet-rsstickerbar no keyword
desklet-scweather-0.4 ~amd64
desklet-sidecandy-0.10 ~amd64
desklet-sidecandygmail no keyword
desklet-sidecandyrhythmbox-0.72-r1 ~amd64
desklet-wirelessmonitor-0.72-r1 ~amd64

I tried sidecandygmail, it loads up, but always tells me that my login is
incorrect.

(In reply to comment #30)
> But seriously, since I just checked in a patch, I'll whine in 30 days or so to
> stabilize gdesklets-core-0.35.3-r1.  I intended for this to be a tracker bug so
> it'll always be open.  I'll add arch teams when I make a new request for
> stabilization and they can remove themselves when it's done.  So for now, I
> think it's okay to leave everything as it is.

If I could make a small suggestion, it might be better to file new bugs for new
requests and make them block this tracker.  It should save the confusion over
exactly what's needed and keep people from having to read pages of unrelated
info from other requests.  You can always remove the blockers as they're
resolved.

x11-plugins/desklet-rsstickerbar-0.15 works on amd64,
x11-plugins/desklet-sidecandygmail-0.4.2 gives me a runtime error on execution:
ssl() argument 1 must be _socket.socket, not _socketobject                      
/usr/lib64/gdesklets/Displays/SideCandyGmail/gmail.display
   18   elif(key == "passwd"):                                                  
   19           mail.password = value                                           
   20           ClearInfo()                                                     
   21           Dsp.lbl_subjects[0].value = "Checking new input"                
>  22           if(mail.login == True): mail.checkmail  

ppc for now:
desklet-calendar ~ppc
desklet-clock ppc
desklet-cornerxmms ~ppc
desklet-discreetclock ppc
desklet-ftb ppc
desklet-justanicon ~ppc
desklet-newsgrab ppc
desklet-rssgrab ppc
desklet-rsstickerbar ppc
desklet-sidecandy ppc
desklet-sidecandyrhythmbox ppc
desklet-starterbar ppc
desklet-sudoku ~ppc
desklet-weeklycalendar ~ppc

desklet-hypertail core          still ~ppc, needs an older gdesklets-core
desklet-regexp                  no idea how to test this
desklet-scweather               doesn't show any weather
desklet-sidecandygmail          doesn't log into gmail
desklet-wirelessmonitor         vague repeating error messages:
invalid syntax (<inline '<internal>_-1461179790'>, line 1)                      
<internal>                                                                      
>   1 __retrieve__ = Wireless Monitor    

ia64 should be done now.

I'm taking ppc off the CC list since nixnut went through them already.  Please
let us know with a new bug when you'd like additional desklets stabilized.

I am confused about what to mark stable here. Could you please re-add amd64
once there is a list of packages that need love?

(In reply to comment #33)
> If I could make a small suggestion, it might be better to file new bugs for new
> requests and make them block this tracker.  It should save the confusion over
> exactly what's needed and keep people from having to read pages of unrelated
> info from other requests.  You can always remove the blockers as they're
> resolved.
> 

Noted - that's what I'll do from now on.  Thanks.

Updated URL

Well, anything to be done here still? What a mess.

Yeah, I'll submit stabilization requests for specific packages and versions in
the future.