GNOME Bugzilla – Bug 685243
can't differentiate different ISO images in list
Last modified: 2016-03-31 13:57:25 UTC
Created attachment 225531 [details] screenshot I have two different versions of the GNOME 3.6 iso image in Downloads. -rw-rw-r--. 1 mccann mccann 747634688 Sep 20 13:31 GNOME-3.5.92-LiveUSB.iso -rw-r--r--. 1 mccann mccann 758120448 Oct 1 15:05 GNOME36-LiveCD.iso -rw-r--r--. 1 mccann mccann 759169024 Oct 1 13:18 GNOME36-LiveCD.iso.old But when I go to create a box they look the same.
Also when I remove one of them from disk it still shows up in the list. I guess we aren't double checking them to see if they are gone.
(In reply to comment #1) > Also when I remove one of them from disk it still shows up in the list. I guess > we aren't double checking them to see if they are gone. This one is https://bugzilla.gnome.org/show_bug.cgi?id=674331
First thing i notice is that we really need to add GNOME ISOs to libosinfo and show the logo for it too. That will have the side-effect of differentiating between 'GNOME-3.5.92-LiveUSB.iso' and 'GNOME36-LiveCD.iso' but how do you propose we differentiate the last two in your list as they are basically the same? Show filename/path in the tooltip?
Created attachment 225603 [details] [review] Add logo for GNOME This logo file was specifically created by our designer, Jakub Steiner <jimmac@gmail.com> for Boxes. Since Boxes is part of GNOME, there should not be any legal issues with it using and shipping this logo.
(In reply to comment #4) > Since Boxes is part of GNOME, there should > not be any legal issues with it using and shipping this logo. I'd feel more comfortable with this if we got explicit clearance from the foundation to use it, especially since the TM is not present in the logo. They could also tell us if they want us to say anything about the logo in Boxes documentation.
As I mentioned on IRC, GNOME Boxes is a product of GNOME the community and foundation so I think it's a no-brainer to use it, but I've sent an e-mail to the Board for clearance just in case. I'm sure Karen can help us with what it should say in the documentation when she comes back from her parental leave.
Review of attachment 225603 [details] [review]: As discussed on IRC, getting this in while we wait for input from the Foundation seems ok to me. I'm not sure why you mention 'shipping' in the log? ::: README.logos @@ +37,3 @@ +and GNOME logo due to the fact that Boxes is part of it and use/shipping of a +project's logo by project itself should not raise any legal concerns. + I'd link to https://live.gnome.org/BrandGuidelines for people who want to reuse the logo in other contexts ::: data/gnome-boxes-logos-db.xml @@ +22,3 @@ + <logo>http://zeenix.fedorapeople.org/gnome-logo.svg</logo> + </os> + why not http://people.gnome.org/~zeenix ?
Karen said she'll be taking care of this in a week or two when she's back from parental leave.
(In reply to comment #7) > Review of attachment 225603 [details] [review]: > > As discussed on IRC, getting this in while we wait for input from the > Foundation seems ok to me. I'm not sure why you mention 'shipping' in the log? Its because at first I tried to ship it too but then gave-up on that as it turned out to be not as trivial as it seemed. > ::: README.logos > @@ +37,3 @@ > +and GNOME logo due to the fact that Boxes is part of it and use/shipping of a > +project's logo by project itself should not raise any legal concerns. > + > > I'd link to https://live.gnome.org/BrandGuidelines for people who want to reuse > the logo in other contexts Sure. > ::: data/gnome-boxes-logos-db.xml > @@ +22,3 @@ > + <logo>http://zeenix.fedorapeople.org/gnome-logo.svg</logo> > + </os> > + > > why not http://people.gnome.org/~zeenix ? Because I didn't know of it. :) I'll submit a new version soon..
Created attachment 225908 [details] [review] Add logo for GNOME v2: Address issues pointed out in review.
Review of attachment 225908 [details] [review]: Looks good to me, I'll leave the decision to you whether to commit now or wait for official board approval ;) ::: README.logos @@ +37,3 @@ +and GNOME logo due to the fact that Boxes is part of it and use of a project's +logo by project itself should not raise any legal concerns. For use of GNOME +logo in other projects, please refer to: I'm not really convinced by this explanation, I'd rather just have the "For use ofthe logo in other projects" sentence until we hear from the board
Attachment 225908 [details] pushed as efbbebb - Add logo for GNOME
The logo combined with the fact that next libosinfo release will be able to recognise GNOME 3.6 ISO (hence we'll present it differently in the UI) fixes your main problem. I still haven't received any feedback on how to differentiate different ISO files that are actually the same? Does that even happen to most users?
(In reply to comment #13) > The logo combined with the fact that next libosinfo release will be able to > recognise GNOME 3.6 ISO (hence we'll present it differently in the UI) fixes > your main problem. I still haven't received any feedback on how to > differentiate different ISO files that are actually the same? Does that even > happen to most users? McCann? This will also apply to ISOs with minor differences or updates of the same OS: RHEL 6.3 vs RHEL 6.4. I'd imagine most people won't bother with older version of the same stable release cycle but they could happen to have older media around when they download the latest one.
Created attachment 233530 [details] [review] wizard-source: Show media path in tooltip
I think to disambiguate the items we should probably try to use something like how the user will likely differentiate the items in her own mind: the production date. Ideally, this date would be encoded into the ISO file at production time. This would solve the problem for snapshot/testing/unofficial releases as well. For official releases, we could show the database release date. As a fallback we could show some kind of (more cryptic) build-id.
(In reply to comment #16) > I think to disambiguate the items we should probably try to use something like > how the user will likely differentiate the items in her own mind: the > production date. > > Ideally, this date would be encoded into the ISO file at production time. This > would solve the problem for snapshot/testing/unofficial releases as well. > > For official releases, we could show the database release date. As a fallback > we could show some kind of (more cryptic) build-id. Yeah, makes sense but I don't see the need for build IDs. Debian already adds dates to ISO volume IDs so if we could do the same in GNOME, I've an idea on how libosinfo can get us this information (not from db). There is still the question of multiple instances of the exact same media (same build). This can easily happen when user downloads an ISO and then burn it on a DVD/USB. For different instances of the same ISO, we probably don't need to do an differentiating but the ISO vs hardware media, we probably do. The patch I attached solves that issue as well, although I'm not sure we want to expose this detail (file path) to user, even if in a tooltip.
Why do we need to display exact duplicates?
(In reply to comment #18) > Why do we need to display exact duplicates? C&P from IRC: <mccann> why would we want to show duplicates? <zeenix> because they are different instances <zeenix> unless there is a way to decide for the user? <mccann> if they are exactly the same I don't think we should show them both <mccann> though not sure if we have some kind of checksum to tell <zeenix> exactly my thought <zeenix> err.. actually no :) <mccann> it seems pretty easy to differentiate media from ISOs... <zeenix> yes but which one to present to user? <zeenix> i guess, the ISO? <zeenix> <mccann> though not sure if we have some kind of checksum to tell <zeenix> we got OS id and version, when we have this build date as well, we can be pretty certain its the same media <zeenix> if all those properties match
A couple of random notes: - some people may want to run older builds of a given image when they want to check if a bug in the latest build was already present in something older or not - currently all Windows editions for a given release (ie WinXP Home, WinXP Professional, ...) are just 'winxp' from a libosinfo point of view. This needs to be improved in libosinfo, but I"m under the impression that the approach described in the last comment would merge images of different win editions in a single item
Created attachment 250514 [details] Many Fedoras If two ISOs have otherwise-identical information, I'd like to see the filename. Of these three Fedoras, one is a live image, one is a DVD image, and one is a netinstall. I can't tell the difference between the DVD and the netinstall.
We now have variants support both in libosinfo and Boxes. Only OS using it currently is win7 though but its a matter of distributors setting a more specific volume ID now and us updating the libosinfo DB accordingly. So that takes care of differentiating btw variants. Please file separate specific bugs about unsupported variants.
Created attachment 264444 [details] [review] media-manager: Rename a method Rename compare_media() to compare_media_by_label().
Created attachment 264445 [details] [review] media-manager: Avoid listing duplicate media In case of duplicate media, prefer: * released OS over unreleased one * latest release * soft over hard media
Attachment 264444 [details] pushed as 0da8c8e - media-manager: Rename a method Attachment 264445 [details] pushed as 548f25b - media-manager: Avoid listing duplicate media