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 attachment 85853 [details, diff] 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.
