Bug 544256

Summary: squeak-vm installs non-functional desktop file
Product: [Fedora] Fedora Reporter: Daniel Drake <dsd>
Component: squeak-vmAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: gavin, mattdm, simon, smparrish
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-11 23:59:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Remove the MySqueak option in the menu none

Description Daniel Drake 2009-12-04 11:56:41 UTC
Installing squeak-vm creates a menu entry for MySqueak which doesn't work.

There is some discussion of this in bug #527103 which seemed to lead off on a different topic. I think we should have a bug open until this is fixed properly, even if a manual workaround (i.e. installing an image) is possible.

Comment 1 Steven M. Parrish 2010-01-12 14:44:17 UTC
This bug has been triaged

Steven M. Parrish
KDE & Packagekit Triager 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Bug Zapper 2010-03-15 13:27:10 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Simon Schampijer 2010-11-03 17:18:07 UTC
Reading through the conversation on http://dev.laptop.org/ticket/9785 I concluded that it is fine to remove the desktop specific files from the squeak-vm package. I re-created the rpm and etoys still runs fine on Sugar and GNOME and the entry of "MySqueak" is gone. 

Gavin, what do you think about it?

Comment 4 Simon Schampijer 2010-11-03 17:19:41 UTC
Created attachment 457517 [details]
Remove the MySqueak option in the menu

Comment 5 Daniel Drake 2010-11-03 19:44:38 UTC
I think bug #527103 explains the use case for this: install this package then create your own squeak image. Then you can launch it from the menu.

I would suggest putting the MySqueak menu option in a subpackage, or moving everything except the menu item into a squeak-vm-engine subpackage.

Comment 6 Simon Schampijer 2010-11-04 06:48:21 UTC
(In reply to comment #5)
> I think bug #527103 explains the use case for this: install this package then
> create your own squeak image. Then you can launch it from the menu.
> 
> I would suggest putting the MySqueak menu option in a subpackage, or moving
> everything except the menu item into a squeak-vm-engine subpackage.

Hmm, I think the issue from a user perspective is that you do not get any feedback when clicking on the MySqueak option in the menu. If this functionality of running your own images is desired there should be better notification. In the case when there is no image in the appropriate folder there should be an error message indicating this and telling the user what are the steps he need to do. 

So, thinking about it a bit more, it is not a packaging issue. But you can work around it by removing the desktop option and rely on the advanced users to run it from the command line. Or you improve the graphical interface to be more user friendly. Counting the many people that have been trying to understand what is happening here the current solution can't be right.

Comment 7 Daniel Drake 2010-11-25 16:43:40 UTC
That idea (error message instead of silent failure) sounds like a valid approach.

I still think it would warrant a subpackage (in the OLPC case) to avoid the menu item, which would still be just as useless for us (error message or not).

And I still think that complete removal of the menu item is the wrong approach. 2 use cases listed in the other bug would then be broken:

 1. Install squeak-vm and squeak-image. Without the menu item you have no way of running squeak from the desktop environment.
 2. Install squeak-vm and install your own squeak image. No way to launch it from desktop environment.

Comment 8 Simon Schampijer 2010-11-26 08:59:41 UTC
(In reply to comment #7)
> That idea (error message instead of silent failure) sounds like a valid
> approach.
> 
> I still think it would warrant a subpackage (in the OLPC case) to avoid the
> menu item, which would still be just as useless for us (error message or not).
> 
> And I still think that complete removal of the menu item is the wrong approach.
> 2 use cases listed in the other bug would then be broken:
> 
>  1. Install squeak-vm and squeak-image. Without the menu item you have no way
> of running squeak from the desktop environment.
>  2. Install squeak-vm and install your own squeak image. No way to launch it
> from desktop environment.

Right, from my perspective the best approach would be to improve the workflow and user feedback. At the moment there is no way to know what happened after clicking that item, or what you have to do to get any results (see #c7).

Comment 9 Simon Schampijer 2010-11-26 09:00:23 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > That idea (error message instead of silent failure) sounds like a valid
> > approach.
> > 
> > I still think it would warrant a subpackage (in the OLPC case) to avoid the
> > menu item, which would still be just as useless for us (error message or not).
> > 
> > And I still think that complete removal of the menu item is the wrong approach.
> > 2 use cases listed in the other bug would then be broken:
> > 
> >  1. Install squeak-vm and squeak-image. Without the menu item you have no way
> > of running squeak from the desktop environment.
> >  2. Install squeak-vm and install your own squeak image. No way to launch it
> > from desktop environment.
> 
> Right, from my perspective the best approach would be to improve the workflow
> and user feedback. At the moment there is no way to know what happened after
> clicking that item, or what you have to do to get any results (see #c7).

sorry, I meant: https://bugzilla.redhat.com/show_bug.cgi?id=544256#c6

Comment 10 Bug Zapper 2011-06-02 17:12:36 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Simon Schampijer 2011-06-06 08:17:05 UTC
The issue is still valid, would be great to fix it.

Comment 12 Bug Zapper 2011-06-27 14:38:37 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 13 Matthew Miller 2012-09-29 15:17:49 UTC
If squeak-image is installed, the menu entry works. The desktop file should probably be moved to squeak-image.

Comment 14 Fedora Admin XMLRPC Client 2012-10-22 20:29:16 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 15 Fedora Update System 2012-11-23 15:06:16 UTC
squeak-image-4.3-1.fc18,squeak-vm-4.10.2.2614-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/squeak-image-4.3-1.fc18,squeak-vm-4.10.2.2614-1.fc18

Comment 16 Fedora Update System 2012-11-23 19:54:53 UTC
Package squeak-image-4.3-1.fc18, squeak-vm-4.10.2.2614-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing squeak-image-4.3-1.fc18 squeak-vm-4.10.2.2614-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-18919/squeak-image-4.3-1.fc18,squeak-vm-4.10.2.2614-2.fc18
then log in and leave karma (feedback).

Comment 17 Fedora Update System 2012-11-27 04:44:09 UTC
squeak-image-4.3-1.fc18, squeak-vm-4.10.2.2614-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Daniel Drake 2012-12-19 07:28:34 UTC
The issue is still present in squeak-vm-4.10.2.2614-1. The desktop file is installed by squeak-vm and doesn't work unless the user performs some specific action, or additionally installs squeak-image.

Comment 19 Jaroslav Škarvada 2012-12-19 12:48:36 UTC
I cannot see any problem here.

The squeak-image is not technically required - the user may use their own images, thus we cannot enforce its dependency.

For newcomers it clearly shows what needs to be done for the initialization - and the initialization needs to be done for each user that will use the squeak (this is something we cannot workaround), thus the $subj of this bug is resolved - the desktop file is functional. I am going to close this because I cannot see anything more we could do here.

Comment 20 Daniel Drake 2012-12-19 12:54:51 UTC
The common case that is not covered in these considerations (and annoying OLPC) is: yum install etoys

This installs etoys and squeak-vm. Two menu items are created: etoys (working), Squeak (not working).


What do you think about this approach (happy to do the spec work myself):
- squeak-vm desktop icon is moved into new subpackage squeak-vm-launcher
- squeak-image Requires squeak-vm-launcher
- etoys unmodified (depends on squeak-vm)

Then, for the case where the user is going to install squeak-vm and then manually install a squeak image, they just have to add 1 more step to the manual process: install squeak-vm-launcher too.

Comment 21 Jaroslav Škarvada 2012-12-19 13:27:05 UTC
(In reply to comment #20)
> What do you think about this approach (happy to do the spec work myself):
> - squeak-vm desktop icon is moved into new subpackage squeak-vm-launcher
> - squeak-image Requires squeak-vm-launcher
> - etoys unmodified (depends on squeak-vm)
> 
I don't like this approach, I think the added complexity is not worth the benefit.

What about just removing the squeak desktop file? Are you OK with such solution?

Comment 22 Daniel Drake 2012-12-19 13:38:56 UTC
We could do that, but of course having this solved in Fedora is preferable. This would also affect other etoys users/distributors.

Comment 23 Daniel Drake 2012-12-19 13:42:37 UTC
Another option... What about shipping the .desktop file in squeak-image, and for users with a custom image, let them install their own .desktop file in their home dir as part of the manual process? That would also solve the inconsistency of the systemwide .desktop file vs the user-specific homedir Squeak image that you mentioned in comment 19.

Comment 24 Jaroslav Škarvada 2012-12-19 13:57:01 UTC
(In reply to comment #22)
> We could do that, but of course having this solved in Fedora is preferable.
> This would also affect other etoys users/distributors.

I thought about Fedora, I think we could go without the desktop file - it is Feodra addon, not part of the upstream code.

Comment 25 Jaroslav Škarvada 2012-12-19 14:01:30 UTC
(In reply to comment #23)
> Another option... What about shipping the .desktop file in squeak-image, and
> for users with a custom image, let them install their own .desktop file in
> their home dir as part of the manual process? That would also solve the
> inconsistency of the systemwide .desktop file vs the user-specific homedir
> Squeak image that you mentioned in comment 19.

I don't like shipping the squeak-vm desktop file in squeak-image package, but the homedir solution doesn't seem bad. I will think a bit about it, but currently my favourite solution is desktop file removal.

Comment 26 Daniel Drake 2012-12-19 14:07:39 UTC
Oh, sorry, I misunderstood your earlier suggestion (thought you were saying that OLPC should remove it to just forget about this bug - but you were actually talking about Fedora itself).

Yes, I also like the idea of dropping the desktop file from the Fedora packages.

Comment 27 Fedora Update System 2012-12-21 12:38:16 UTC
squeak-vm-4.10.2.2614-5.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/squeak-vm-4.10.2.2614-5.fc18

Comment 28 Fedora Update System 2012-12-21 20:03:20 UTC
Package squeak-vm-4.10.2.2614-5.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing squeak-vm-4.10.2.2614-5.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20819/squeak-vm-4.10.2.2614-5.fc18
then log in and leave karma (feedback).

Comment 29 Fedora Update System 2013-01-12 00:00:00 UTC
squeak-vm-4.10.2.2614-5.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.