After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 741999 - Update displayed with inconsistent update description
Update displayed with inconsistent update description
Status: RESOLVED FIXED
Product: gnome-software
Classification: Applications
Component: General
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Software maintainer(s)
GNOME Software maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-12-26 14:38 UTC by Michael Catanzaro
Modified: 2016-02-23 09:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot #1 (60.53 KB, image/png)
2014-12-26 14:38 UTC, Michael Catanzaro
Details
screenshot #2 (19.65 KB, image/png)
2014-12-26 14:38 UTC, Michael Catanzaro
Details

Description Michael Catanzaro 2014-12-26 14:38:02 UTC
Created attachment 293356 [details]
screenshot #1

I have an update available for Evolution. On the update overview page, the description of the update is presented correctly. But when clicking the update, the description presented is completely different. Screenshots attached.

evolution-help and evolution-data-server are also listed as updates under OS Updates. These packages had a THIRD description when I first checked them five minutes ago, but now when I check again they say "no update description available."

The other updates are all fine.

This is gnome-software-3.14.2-2.fc21, PackageKit 1.0.3-4.fc21.
Comment 1 Michael Catanzaro 2014-12-26 14:38:27 UTC
Created attachment 293357 [details]
screenshot #2
Comment 2 Michael Catanzaro 2016-01-16 01:46:39 UTC
It happened again to me today, one year later, this time with Shotwell, exactly the same: the correct description was displayed for Shotwell in the updates list, but when I clicked to view details, the details were exactly the same nonsense:

New in kmod 14-1
 * Moo
 * bar
Comment 3 Rafal Luzynski 2016-01-16 14:25:35 UTC
(In reply to Michael Catanzaro from comment #2)
> New in kmod 14-1
>  * Moo
>  * bar

This is a default and temporary content of this label: https://git.gnome.org/browse/gnome-software/tree/src/gs-update-dialog.ui#n225 and it should never appear to the user's eyes because should be replaced by the actual content. I have no idea how this could not work, maybe gs_markdown_parse() fails and returns NULL?

Is this bug reproducible? Probably you can't install updates which have already been installed but you can recall this dialog with:

    killall gnome-software
    gnome-software --mode=updated

When the most recent updates appear can you reproduce this bug? Can you see any suspected error messages or warnings on the console? What if you also add --verbose command line option? What if you run it under valgrind?

When you launch this command:

    pkcon get-update-detail shotwell

what does it say, especially as the Update text?

Is the Shotwell still available for the update? For example, was a newer version released just after you updated so your most recent update became the most recent minus one?
Comment 4 Michael Catanzaro 2016-01-16 15:38:29 UTC
(In reply to Rafal Luzynski from comment #3)
> Is this bug reproducible? Probably you can't install updates which have
> already been installed but you can recall this dialog with:
> 
>     killall gnome-software
>     gnome-software --mode=updated

Yes, it reproducibly appears with the incorrect update description when I run that command. Turns out there is a warning when I run it from a terminal

Gtk-WARNING **: Failed to set text 'Update to git snapshot. Port to WebKit2 and verify TLS certificates. See <a href="https://bugzilla.gnome.org/show<i>bug.cgi?id=754488">https://bugzilla.gnome.org/show</i>bug.cgi?id=754488</a>' from markup due to error parsing markup: Error on line 1 char 178: Element 'i' was closed, but the currently open element is 'a

So it happens when the update description is borked.

> When you launch this command:
> 
>     pkcon get-update-detail shotwell
> 
> what does it say, especially as the Update text?

$ pkcon get-update-detail shotwell
Resolving                     [=========================]         More than one Getting update details        [=========================]         
Starting                      [=========================]         
Finished                      [=========================]         
Details about the update: package: 2
 Package: shotwell-0.23.0-0.1.20160105gitf2fb1f7.fc23.x86_64
 Update text: Update to git snapshot. Port to WebKit2 and verify TLS certificates. See https://bugzilla.gnome.org/show_bug.cgi?id=754488

 Changes: 
 State: stable
 Issued: 
 Updated: 

> Is the Shotwell still available for the update? For example, was a newer
> version released just after you updated so your most recent update became
> the most recent minus one?

No, only one recent Shotwell update.
Comment 5 Michael Catanzaro 2016-01-16 15:40:27 UTC
By the way, here is the update in Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2016-902a2b18d8

If you think there is a Bodhi bug in addition to this bug, I don't mind reporting it.
Comment 6 Rafal Luzynski 2016-01-16 21:39:20 UTC
(In reply to Michael Catanzaro from comment #4)
> 
> Gtk-WARNING **: Failed to set text 'Update to git snapshot. Port to WebKit2
> and verify TLS certificates. See <a
> href="https://bugzilla.gnome.org/show<i>bug.cgi?id=754488">https://bugzilla.
> gnome.org/show</i>bug.cgi?id=754488</a>' from markup due to error parsing
> markup: Error on line 1 char 178: Element 'i' was closed, but the currently
> open element is 'a
> 
> So it happens when the update description is borked.

Here we've got it! Thanks for tracking it down, Michael. So we need:

- fix constructing the markup,
- I'd like also to see the fallback to display when the markup fails.

I think that Richard is the best person to fix it.

> 
> [...]
>  Update text: Update to git snapshot. Port to WebKit2 and verify TLS
> certificates. See https://bugzilla.gnome.org/show_bug.cgi?id=754488

This is the example of the update text which causes the problem.
Comment 7 Richard Hughes 2016-01-17 20:52:45 UTC
So, this looks to be the markdown parser doing the wrong thing. I'm now slightly confused what format the update string is in, is it markdown or HTML? At the moment it's both, which is kinda hard to parse...
Comment 8 Richard Hughes 2016-01-19 12:10:30 UTC
I'm still looking at libmarkdown, but this fixes the displayed string:

commit cf92e458147f014ece5aca996464ca6810bae0ad
Author: Richard Hughes <richard@hughsie.com>
Date:   Tue Jan 19 12:08:40 2016 +0000

    Show something sensible if the markdown parser fails
    
    Resolves: https://bugzilla.gnome.org/show_bug.cgi?id=741999
Comment 9 Rafal Luzynski 2016-01-20 23:37:48 UTC
Thanks, Richard. I wouldn't say this patch resolves the bug but it is a huge step forward.
Comment 10 Richard Hughes 2016-02-23 09:07:51 UTC
I think showing the raw text is the best we can do with the parser we have. Rafal, if you do want to write a proper parser please re-open this bug, thanks.