Review Request 128590: Let kpackagetool5 generate appstream information for kpackage components

Marco Martin notmart at gmail.com
Wed Aug 3 08:45:49 UTC 2016


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128590/#review98036
-----------------------------------------------------------


Fix it, then Ship it!




can't really comment on appstream related things, just some code style comments below, otherwise is ok


src/kpackagetool/kpackagetool.cpp (line 353)
<https://git.reviewboard.kde.org/r/128590/#comment66029>

    if () {
    
    }



src/kpackagetool/kpackagetool.cpp (line 392)
<https://git.reviewboard.kde.org/r/128590/#comment66030>

    if () {
    
    }



src/kpackagetool/kpackagetool.cpp (line 395)
<https://git.reviewboard.kde.org/r/128590/#comment66033>

    my first instinct would be to use qxmlstreamwriter there, but indeed i would rather not add dependencies



src/kpackagetool/kpackagetool.cpp (line 398)
<https://git.reviewboard.kde.org/r/128590/#comment66031>

    if () {
    
    }



src/kpackagetool/kpackagetool.cpp (line 402)
<https://git.reviewboard.kde.org/r/128590/#comment66032>

    if () {
    
    }


- Marco Martin


On Aug. 3, 2016, 12:56 a.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128590/
> -----------------------------------------------------------
> 
> (Updated Aug. 3, 2016, 12:56 a.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, Matthias Klumpp, and Harald Sitter.
> 
> 
> Repository: kpackage
> 
> 
> Description
> -------
> 
> We want our components to be exposed on software using Appstream (such as Discover, but not exclusively). Some of the most hidden components we have nowadays are Plasma addons, since they're not documented there. This attempts to fix this by reusing the metadata we already have and turning it into files that appstream can consume, without having to write yet another time the plugin metadata.
> 
> This is done in 2 steps:
> 
> * Introduces `kpackagetool5 --appstream-metainfo` argument
> * The cmake macro will automatically grab the file and process it. See: https://git.reviewboard.kde.org/r/128579/
> 
> 
> Diffs
> -----
> 
>   KF5PackageMacros.cmake 9163de9 
>   autotests/CMakeLists.txt c84379d 
>   autotests/data/testfallbackpackage/testfallbackpackage.appdata.xml PRE-CREATION 
>   autotests/data/testpackage/testpackage.appdata.xml PRE-CREATION 
>   autotests/kpackagetoolappstreamtest.cmake PRE-CREATION 
>   src/kpackagetool/kpackagetool.h dc056c6 
>   src/kpackagetool/kpackagetool.cpp 2758f70 
>   src/kpackagetool/main.cpp a8eb5ab 
> 
> Diff: https://git.reviewboard.kde.org/r/128590/diff/
> 
> 
> Testing
> -------
> 
> Tests pass, everything else still compiles (including r128579), we get quite some metadata.
> `appstreamcli validate` doesn't choke on output files.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160803/7d54ddde/attachment.html>


More information about the Kde-frameworks-devel mailing list