Bug 351531

Sorry, SRPM URL is
http://home.arcor.de/christoph.wickert/fedora/review/ristretto-0.0.9-1.fc8.src.rpm
(F8 Mock build)

ristretto.i386: W: non-standard-group Applications/Graphics

Maybe 
User Interface/Desktops

It should certainly be cleaner to have buildrequires
libxfce4util-devel >= 4.4.0

In my tests I see the mini images, but the main place where 
the image should appear stays black.

gthumb has more mimetypes:
MimeType=image/bmp;image/jpeg;image/gif;image/png;image/tiff;image/x-bmp;image/x-ico;image/x-png;image/x-pcx;image/x-tga;image/xpm;image/svg+xml;
Also maybe the .eps? This is more for upstream.

It may be important to say that I am in fluxbox.

(In reply to comment #2)
> ristretto.i386: W: non-standard-group Applications/Graphics
> 
> Maybe 
> User Interface/Desktops

Sorry, this was a last minute change. I had "User Interface/Desktops", but
changed it to "Amusements/Graphics" in the spec.

> It should certainly be cleaner to have buildrequires
> libxfce4util-devel >= 4.4.0

Oops. I think I'll remove libxfce4util since it is redundant anyway,
libxfce4util-devel is pulled in by Thunar-devel.

> In my tests I see the mini images, but the main place where 
> the image should appear stays black.

This depends on whether you choose "Open" or "Open Folder" (which is the same as
the icon in the tool bar). If you choose to open a folder you need to click on
one of the thumbnails before it gets displayed in the main area.

> gthumb has more mimetypes:
>
MimeType=image/bmp;image/jpeg;image/gif;image/png;image/tiff;image/x-bmp;image/x-ico;image/x-png;image/x-pcx;image/x-tga;image/xpm;image/svg+xml;
> Also maybe the .eps? This is more for upstream.

Good catch, I can change that if you like, I'm working on a multilingual desktop
file that should be included in 0.1.0. I think we should add
image/tiff
image/x-bmp
image/x-png
image/x-pcx
image/x-tga
image/xpm

but ristretto doesn't handle svg or eps atm.

(In reply to comment #3)
> It may be important to say that I am in fluxbox.

Doesn't matter as long as you have Thunar installed (Thunar and ristretto are
sharing their thumbnail cache). Ristretto requires libthunar-vfs-1.so.2, so
Thunar will be installed automagically.

(In reply to comment #4)
> (In reply to comment #2)
> > ristretto.i386: W: non-standard-group Applications/Graphics
> > 
> > Maybe 
> > User Interface/Desktops
> 
> Sorry, this was a last minute change. I had "User Interface/Desktops", but
> changed it to "Amusements/Graphics" in the spec.

I am not sure that it is right. I would only put image editors in 
that Group. Not a big deal.

> > It should certainly be cleaner to have buildrequires
> > libxfce4util-devel >= 4.4.0
> 
> Oops. I think I'll remove libxfce4util since it is redundant anyway,
> libxfce4util-devel is pulled in by Thunar-devel.

(by exo-devel) but without version constraints. So it may make
sense to keep the versioned BR here.

> > In my tests I see the mini images, but the main place where 
> > the image should appear stays black.
> 
> This depends on whether you choose "Open" or "Open Folder" (which is the same as
> the icon in the tool bar). If you choose to open a folder you need to click on
> one of the thumbnails before it gets displayed in the main area.

i tried 
$ ristretto ristretto-screenshot.png

from
http://goodies.xfce.org/_media/projects/applications/ristretto-screenshot.png

and still a black main area. And even when i click on it
nothing happens.

> > gthumb has more mimetypes:
> >
>
MimeType=image/bmp;image/jpeg;image/gif;image/png;image/tiff;image/x-bmp;image/x-ico;image/x-png;image/x-pcx;image/x-tga;image/xpm;image/svg+xml;
> > Also maybe the .eps? This is more for upstream.
> 
> Good catch, I can change that if you like, I'm working on a multilingual desktop
> file that should be included in 0.1.0. I think we should add
> image/tiff
> image/x-bmp
> image/x-png
> image/x-pcx
> image/x-tga
> image/xpm

Looks sane.

> but ristretto doesn't handle svg or eps atm.

Ok. The mini images are shown, though.
 
> (In reply to comment #3)
> > It may be important to say that I am in fluxbox.
> 
> Doesn't matter as long as you have Thunar installed (Thunar and ristretto are
> sharing their thumbnail cache). Ristretto requires libthunar-vfs-1.so.2, so
> Thunar will be installed automagically.

Indeed, but I experienced sometimes different behavior when not in 
a desktop like gnome/kde/xfce, like
http://thunar.xfce.org/pwiki/documentation/faq
question
Why does Thunar display the fallback icon for all files and folders?

I have the same issue in xfce.

i also get warnings:
(ristretto:22815): GLib-GObject-CRITICAL **: g_value_get_pointer: assertion
`G_VALUE_HOLDS_POINTER (value)' failed

(ristretto:22819): GLib-GObject-CRITICAL **: g_value_get_pointer: assertion
`G_VALUE_HOLDS_POINTER (value)' failed

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > 
> > Sorry, this was a last minute change. I had "User Interface/Desktops", but
> > changed it to "Amusements/Graphics" in the spec.
> 
> I am not sure that it is right. I would only put image editors in 
> that Group. Not a big deal.

Well, there seems to be no common usage:
$ rpm -qi eog f-spot gthumb gimp mirage | grep Group
Group       : User Interface/Desktops       Source RPM: eog-2.18.2-2.fc7.src.rpm
Group       : Applications/Multimedia       Source RPM: f-spot-0.3.5-2.fc7.src.rpm
Group       : User Interface/X              Source RPM: gthumb-2.10.6-1.fc7.src.rpm
Group       : Applications/Multimedia       Source RPM: gimp-2.2.17-1.fc7.src.rpm
Group       : Amusements/Graphics           Source RPM: mirage-0.9-1.fc7.src.rpm

I agree we could use User Interface/Desktops

> 
> > > It should certainly be cleaner to have buildrequires
> > > libxfce4util-devel >= 4.4.0
> > 
> > Oops. I think I'll remove libxfce4util since it is redundant anyway,
> > libxfce4util-devel is pulled in by Thunar-devel.
> 
> (by exo-devel) but without version constraints. So it may make
> sense to keep the versioned BR here.

+1

> 
> i tried 
> $ ristretto ristretto-screenshot.png
> 
> and still a black main area. And even when i click on it
> nothing happens.

Ok, I'll test on a minimal system, there seems to be a missing requirement.

> 
> > but ristretto doesn't handle svg or eps atm.
> 
> Ok. The mini images are shown, though.

Maybe these are cached thumbnails (pngs) that are created by a running Thunar or
nautilus? Or it is indeed a bug in ristretto, the program is still in an early
state. Anyway, I tried all the other filetypes you suggested and they all work
except svg and eps.

>  
> > (In reply to comment #3)
> > > It may be important to say that I am in fluxbox.
> > 
> > Doesn't matter as long as you have Thunar installed (Thunar and ristretto are
> > sharing their thumbnail cache). Ristretto requires libthunar-vfs-1.so.2, so
> > Thunar will be installed automagically.
> 
> Indeed, but I experienced sometimes different behavior when not in 
> a desktop like gnome/kde/xfce, like
> http://thunar.xfce.org/pwiki/documentation/faq
> question
> Why does Thunar display the fallback icon for all files and folders?

This seems to be an error in the underlying thunar-vfs layer. Ristretto uses
thunar_vfs_mime_info_get_media to determine the file type, if it returns NULL,
no image is shown. shared-mime-data should be installed with Thunar, so I have
no idea what could be wrong here.

(In reply to comment #6)
> I have the same issue in xfce.

You mean, you have no icons in Thunar even in Xfce?
 
> i also get warnings:
> (ristretto:22815): GLib-GObject-CRITICAL **: g_value_get_pointer: assertion
> `G_VALUE_HOLDS_POINTER (value)' failed
> 
> (ristretto:22819): GLib-GObject-CRITICAL **: g_value_get_pointer: assertion
> `G_VALUE_HOLDS_POINTER (value)' failed
> 

Sorry, I don't see anything like that here in my F7 machine. When do these
errors appear?

(In reply to comment #7)


> Maybe these are cached thumbnails (pngs) that are created by a running Thunar or
> nautilus? 

maybe thunar thumbnails. But I don't have a running thunar or
nautilus in general. 


> This seems to be an error in the underlying thunar-vfs layer. Ristretto uses

No, no, I just showed that as an example that things can be
different when not in xfce. Forget about the end of comment #5,
it is irrelevant.

In xfce there is also no image opened in ristretto.

> > i also get warnings:
> > (ristretto:22815): GLib-GObject-CRITICAL **: g_value_get_pointer: assertion
> > `G_VALUE_HOLDS_POINTER (value)' failed
> > 
> > (ristretto:22819): GLib-GObject-CRITICAL **: g_value_get_pointer: assertion
> > `G_VALUE_HOLDS_POINTER (value)' failed
> > 
> 
> Sorry, I don't see anything like that here in my F7 machine. When do these
> errors appear?

When starting ristretto, they appear on the console.

Hey Patrice. Would you like to formally review this? 
Or shall I?

In any case I will try and duplicate the blank main area issue here... 

(In reply to comment #9)
> Hey Patrice. Would you like to formally review this? 
> Or shall I?

Since it doesn't work for me, I'd prefer if you reviewed it.

Thanks everybody for your comments. I haven't been able to reproduce the blank
main screen issue, even with a fresh, absolute minimal install. On the other
hand there have been two people who experienced this behavior. Any idea how to
track this down?

Alas, I am seeing it here too... 

My laptop is running rawhide/proto F8 right now. 
Could that be the issue? 

Christoph: Are you testing on F7 or devel?
How about you Patrice? 

I am on rawhide.

I'm still on F7, trying rawhide this weekend. Stay tuned.

(In reply to comment #6)
> I have the same issue in xfce.
> 
> i also get warnings:
> (ristretto:22815): GLib-GObject-CRITICAL **: g_value_get_pointer: assertion
> `G_VALUE_HOLDS_POINTER (value)' failed
> 
> (ristretto:22819): GLib-GObject-CRITICAL **: g_value_get_pointer: assertion
> `G_VALUE_HOLDS_POINTER (value)' failed
> 

I would like to point you to this comment:

http://bugzilla.xfce.org/show_bug.cgi?id=3479#c9

At the end of this bugreport, the conclusion is that we were dealing with a bug
in gtk 2.11 (since it works with 2.10 and 2.12).

It might be the case here aswell ;-)

The gtk version is
gtk2-2.12.1-5.fc8

and I still have the black main window (and thumbnails, although
I am in fluxbox without anything launched).

Hmm, this could be a regression since 2.12.0. 
The picture-viewer widget does not receive any adjustments from the scrolledwindow.

Can anyone confirm this?

My girlfriend had no issues with ristretto on Ubuntu 7.10 (with gtk 2.12.0).

(In reply to comment #16)
> The gtk version is
> gtk2-2.12.1-5.fc8
> 
> and I still have the black main window (and thumbnails, although
> I am in fluxbox without anything launched).

Which glib version do you have?
I have glib 2.14.1.

(I just discovered I have gtk 2.12.1 here aswell, with no issues)

glib2-2.14.2-1.fc8

After upgrading to F8 I'm seeing the errors Patrice described in comment #6.
Nevertheless I have updated the package and the spec to 0.0.11 now.

http://home.arcor.de/christoph.wickert/fedora/review/ristretto-0.0.11-1.fc8.src.rpm
http://home.arcor.de/christoph.wickert/fedora/review/ristretto.spec

$ rpm -q gtk2 glib2
gtk2-2.12.1-5.fc8
glib2-2.14.3-1.fc8

I must say that I am not really sure what causes these issues, I don't see it
with current ubuntu (7.10), and a gentoo-dev told me ristretto works fine there.

(gtk 2.12.1 and glib 2.14.3)

Does anyone know if the way the scrolledwindow behaves has changed since gtk 2.10?

Created attachment 265271 [details]
backtrace of ristretto 0.0.12 crashing

Ristretto 0.0.12 crashes as soon as I click on the black main area. Stephan,
please have a look at the trace I attached.

SPEC: http://home.arcor.de/christoph.wickert/fedora/review/ristretto.spec
SRPM:
http://home.arcor.de/christoph.wickert/fedora/review/ristretto-0.0.12-1.fc8.src.rpm

Created attachment 265451 [details]
test patch

Please try this patch against, and see if the behaviour changed. (eg, does it
still crash?)

Yes, still crashing, trace looks not much different. Still the
GLib-GObject-CRITICAL errors from comment #6.

When I open a folder the main area remains black, although the thumbnails are
being displayed. When I select a picture and hit the zoom button, ristretto
crashed, this time with another segfault. I have no idea why, but the same
package is working on Fedora 7.

Created attachment 265541 [details]
Trace of the crash when trying to zoom

I am pretty sure this is an environment issue, so I wonder: Is this bug still valid?

Yes, ristretto 0.0.16 still crashes and suffers from GLib-GObject-CRITICAL
errors on both F8 and rawhide.

Attaching two traces, this time with the necessary debuginfo installed ;). First
is the crash when you click on the main area, second is the crash when zooming.

Created attachment 295113 [details]
Trace of ristretto 0.0.16 crashing when the main area is clicked

Created attachment 295114 [details]
Trace of ristretto 0.0.16 crashing when trying to zoom

Stephan, I just read your announcement for 0.0.17 and updated my package. Still
no joy. You want me to do more traces?

No, I'll see what I can do with what you gave me so far.

It is really interesting to see that as of now, fedora is the only distro that
can reproduce this. Ristretto is available on several different
operating-systems and only you have this bug.

Thanks for the information so far, I'll take a look at it. ^_^

Hooray! 0.0.20 finally works! Browsing files and folders, zooming in and out
etc. Good work Stephan!

http://cwickert.fedorapeople.org/review/ristretto.spec
http://cwickert.fedorapeople.org/review/ristretto-0.0.20-1.fc10.src.rpm

Now that there are no more blockers, clould someone review this package soon?

I'd be happy to review this a bit later today unless someone beats me to it. 

Created attachment 306585 [details]
backtrace of 0.0.20 after segfault when clicking on thumbnail

Argh... did you mock the package or is it a local rebuild? What arch are you on?
I'm on i386.

It is a local rebuild, I am under fluxbox, i386.

Works for me under fluxbox. Can you try a mockbuild?

Something has changed on your system, since I haven't touched that part of
Ristretto in months. The fact that it still crashes with Patrice proves my point.

Still the same issue with adjustments not being set.

Did either one of you have a different build of glib / gtk?

Clearly the issue is different since previously I had a black main window.

Many things changed on my system, since I track rawhide:

glib2-2.16.3-5.fc10.i386
gtk2-2.13.0-2.fc10.i386

I still haven't have the occasion to do a mock build since there 
seems to be a bug in yum preventing the mock build.

Patrice, you can use koji scratch build if you want.

$ koji build --scratch <target> <srpm_you_want_to_try>
target can be dist-f10, dist-f9-updates-candidate, dist-f8-updates-candidate,
dist-fc7-updates-candidate and so on.

If build succeeds, the rebuilt binary rpms and some logs (such as
build.log) are placed under
http://koji.fedoraproject.org/scratch/<your_FAS_NAME>/task_<id>/

For now I just tried to rebuild comment 33 on dist-f10:
http://koji.fedoraproject.org/koji/taskinfo?taskID=627525
http://koji.fedoraproject.org/scratch/mtasaka/task_627525/

Just for the record: I'm on F9 i386 and for me _all_ 0.0.20 packages work: Local
rebuilds as well as mock builds (against F9 and rawhide) or Mamorus scratch build.

Same trace with Mamoru scratch build. 

I found which event leads to the segfault:
clicking outside of the application and clicking on 'zoom in', 
'zoom out', 'normal size'.

But in fact it seems that double clicking on a thumbnail 
does nothing.

(In reply to comment #40)
> Clearly the issue is different since previously I had a black main window.

Actually the same issue is still there, except that the main window 
doesn't seems to be black anymore.

@Christoph and Patrice:
Could you please analyze which library is different on your systems?

Something must be up, since it works for Christoph, and for most other
mainstream distributions. (inc Gentoo, Debian and OpenSuSE) 

They don't seem to have these problems, so I tend to believe it is an
environment issue. Something with one of the underlying libs (the way they are
compiled for example).

I'll go ahead and take this for review.
Look for a full review later today hopefully... 

(In reply to comment #45)
> @Christoph and Patrice:
> Could you please analyze which library is different on your systems?

Do you have any special packages in mind? As Fedora 9 has just been released
there shouldn't be much difference between F9 and Rawhide ATM and others also
reported ristretto to crash on the Rawhide that has now become F9.

I have switched back to i386 when I installed F9, so maybe this only happens on
x86_64?

rpm -qa libxfce\* gtk\* glib\* | sort
glib-1.2.10-29.fc9.i386
glib2-2.16.3-5.fc9.i386
glib2-devel-2.16.3-5.fc9.i386
glibc-2.8-3.i686
glibc-common-2.8-3.i386
glibc-devel-2.8-3.i386
glibc-headers-2.8-3.i386
glibmm24-2.16.0-1.fc9.i386
gtk+-1.2.10-61.fc9.i386
gtk2-2.12.10-2.fc9.i386
gtk2-devel-2.12.10-2.fc9.i386
gtk2-engines-2.14.2-1.fc9.i386
gtk-doc-1.9-4.fc9.noarch
gtkglext-libs-1.2.0-6.fc9.i386
gtkhtml2-2.11.1-3.fc9.i386
gtkhtml3-3.18.2-1.fc9.i386
gtkmm24-2.12.5-1.fc9.i386
gtk-nodoka-engine-0.7.0-1.fc9.i386
gtk-sharp2-2.10.3-3.fc9.i386
gtksourceview-1.8.5-4.fc9.i386
gtksourceview2-2.2.1-1.fc9.i386
gtkspell-2.0.11-8.fc9.i386
libxfce4mcs-4.4.2-2.fc9.i386
libxfce4mcs-devel-4.4.2-2.fc9.i386
libxfce4util-4.4.2-2.fc9.i386
libxfce4util-devel-4.4.2-2.fc9.i386
libxfcegui4-4.4.2-2.fc9.i386
libxfcegui4-devel-4.4.2-2.fc9.i386

ok, just tried on rawhide here (x86_64) and I can get it to segfault by just
loading a folder and then trying to zoom in. 

Here's the backtrace: 

(gdb) where
#0  0x0000000000410c0e in rstto_picture_viewer_set_scale (viewer=0x1c80c30, 
    scale=1.2) at picture_viewer.c:552
#1  0x0000003a8240b72d in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#2  0x0000003a8242144b in ?? () from /lib64/libgobject-2.0.so.0
#3  0x0000003a82422ad6 in g_signal_emit_valist ()
   from /lib64/libgobject-2.0.so.0
#4  0x0000003a82422e44 in g_signal_emit_by_name ()
   from /lib64/libgobject-2.0.so.0
#5  0x0000003a8826b98a in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#6  0x0000003a8240b72d in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#7  0x0000003a8242144b in ?? () from /lib64/libgobject-2.0.so.0
#8  0x0000003a82422ad6 in g_signal_emit_valist ()
   from /lib64/libgobject-2.0.so.0
#9  0x0000003a82423053 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#10 0x0000003a8808c322 in gtk_button_clicked ()
   from /usr/lib64/libgtk-x11-2.0.so.0
#11 0x0000003a8808daf2 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#12 0x0000003a8240b72d in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#13 0x0000003a82420d69 in ?? () from /lib64/libgobject-2.0.so.0
#14 0x0000003a82422ad6 in g_signal_emit_valist ()
   from /lib64/libgobject-2.0.so.0
#15 0x0000003a82423053 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#16 0x0000003a8808c28b in gtk_button_released ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib64/libgtk-x11-2.0.so.0
#17 0x0000003a8808d825 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#18 0x0000003a881689a3 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x0000003a8240b72d in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#20 0x0000003a8242112f in ?? () from /lib64/libgobject-2.0.so.0
#21 0x0000003a8242298d in g_signal_emit_valist ()
   from /lib64/libgobject-2.0.so.0
#22 0x0000003a82423053 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#23 0x0000003a882d14c7 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#24 0x0000003a882d0fe9 in gtk_widget_event ()
   from /usr/lib64/libgtk-x11-2.0.so.0
#25 0x0000003a88166c53 in gtk_propagate_event ()
   from /usr/lib64/libgtk-x11-2.0.so.0
#26 0x0000003a88165766 in gtk_main_do_event ()
   from /usr/lib64/libgtk-x11-2.0.so.0
#27 0x0000003a87860323 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#28 0x0000003a7c4373fa in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#29 0x0000003a7c43ab00 in ?? () from /lib64/libglib-2.0.so.0
#30 0x0000003a7c43afcd in g_main_loop_run () from /lib64/libglib-2.0.so.0
#31 0x0000003a88164ebd in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#32 0x00000000004080cc in main (argc=1, argv=0x7fff2927d698) at main.c:343

Happy to provide more info. 

I ran through my review checklist and everything else is just fine. 
I would approve this, but it would be nice to get it working for rawhide if
possible. 

So can anybody test this on i386 rawhide?

The problem is found, and solved in svn.

It is caused by a wrong marshaller. You can fix it by cherry-picking the changes
of revision 5016 of upstream svn. (http://svn.xfce.org/svn/goodies/ristretto/trunk)

(In reply to comment #49)
> So can anybody test this on i386 rawhide?

Of course I meant x86_64 ;)

(In reply to comment #50)
> The problem is found, and solved in svn.

Ok, here is a new package:
SRPM:
http://cwickert.fedorapeople.org/review/ristretto-0.0.21-0.1.20080630svn.fc10.src.rpm
SPEC: http://cwickert.fedorapeople.org/review/ristretto.spec

Hehe, you could better pick the diff from that revision and apply it against
0.0.20. Currently, trunk has a few partial modifications to allow saving an
image rotated. But these are not yet fully implemented.

So, when that fix is tested... 0.0.20 + patch is a better solution ;-)

(In reply to comment #52)
> Hehe, you could better pick the diff from that revision and apply it against
> 0.0.20.

Ok. To be honest I did not know what you meant by cherry-picking, but now I got
it :)

New SRPM:
http://cwickert.fedorapeople.org/review/ristretto-0.0.20-2.fc10.src.rpm
SPEC: http://cwickert.fedorapeople.org/review/ristretto.spec

OK - Package meets naming and packaging guidelines
OK - Spec file matches base package name.
OK - Spec has consistant macro usage.
OK - Meets Packaging Guidelines.
OK - License (GPLv2+)
OK - License field in spec matches
OK - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
12eaaea1aaaea024ad3ce8a114ff9e6d  ristretto-0.0.20.tar.gz
12eaaea1aaaea024ad3ce8a114ff9e6d  ristretto-0.0.20.tar.gz.orig
OK - BuildRequires correct
OK - Spec handles locales/find_lang
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
OK - Package has correct buildroot
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.
OK - Package has rm -rf RPM_BUILD_ROOT at top of %install

OK - Package is a GUI app and has a .desktop file

OK - Package compiles and builds on at least one arch.
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories other packages own.
OK - Package owns all the directories it creates.
See below - No rpmlint output.
OK - final provides and requires are sane.

SHOULD Items:

OK - Should build in mock.
OK - Should build on all supported archs
OK - Should function as described.
OK - Should have sane scriptlets.
OK - Should have dist tag
OK - Should package latest version

Issues:

1. rpmlint says:

ristretto.i386: W: incoherent-version-in-changelog 0.0.20.2 0.0.20-2.fc10
You have a typo there... a "." that should be a "-"

Thats super minor, fix when you import?
This package is APPROVED.

(In reply to comment #54)
> ristretto.i386: W: incoherent-version-in-changelog 0.0.20.2 0.0.20-2.fc10
> You have a typo there... a "." that should be a "-"
> 
> Thats super minor, fix when you import?

Will do, good catch.


New Package CVS Request
=======================
Package Name: ristretto
Short Description:  Image-viewer for the Xfce desktop environment
Owners: cwickert
Branches: F-8 F-9
InitialCC:
Cvsextras Commits: yes

cvs done.

If you want to make any changes before committing, please press Ctrl-C.
Otherwise press Enter to proceed to commit.

cvs commit...

**** Access denied: cwickert is not in ACL for rpms/ristretto/devel
cvs commit: Pre-commit check failed
cvs [commit aborted]: correct above errors first!
cvs commit: saving log message in /tmp/cvsYbu2e5

What's wrong? Where to proceed after this is fixed?

acls only sync 2x/hour... wait about another 5minutes and try again?

ristretto-0.0.20-2.fc9 has been submitted as an update for Fedora 9

ristretto-0.0.20-2.fc8 has been submitted as an update for Fedora 8

ristretto-0.0.20-2.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

ristretto-0.0.20-2.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Package Change Request
======================
Package Name: ristretto
New Branches: epel7
Owners: cwickert
InitialCC: nonamedotc

Git done (by process-git-requests).