Quite a few people are going to be installing Fedora 22 in the coming days, searching for things in the software center and not finding their esoteric GUI tool. This is because some applications still don’t ship AppData files, which have become compulsory in the workstation spin for this release. Luckily, the vast majority of applications that don't include AppData are not popular and most have little-to-no upstream activity.
If you want to check an application without installing F22 you can use this link http://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html -- if you fix an application I'll be regenerating that status page every 48 hours and shipping new a metadata release in a couple of weeks.
Richard
Hi,
On 05/26/2015 05:33 PM, Richard Hughes wrote:
Quite a few people are going to be installing Fedora 22 in the coming days, searching for things in the software center and not finding their esoteric GUI tool. This is because some applications still don’t ship AppData files, which have become compulsory in the workstation spin for this release. Luckily, the vast majority of applications that don't include AppData are not popular and most have little-to-no upstream activity.
If you want to check an application without installing F22 you can use this link http://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html
What does "dead" in that table mean? I see a lot of games marked this way, and yes many games see little upstream activity, because once a game is finished it typically really is finished.
If I add appdata files to packages marked dead, will that make them available in the software center? Or ... ?
Regards,
Hans
On 26 May 2015 at 19:56, Hans de Goede hdegoede@redhat.com wrote:
What does "dead" in that table mean? I see a lot of games marked this way, and yes many games see little upstream activity, because once a game is finished it typically really is finished.
Dead means "no upstream release in 5 years".
If I add appdata files to packages marked dead, will that make them available in the software center? Or ... ?
Yes, that shows you care as a packager and allows you to "rescue" otherwise unloved applications.
Richard
Am 26.05.2015 um 22:48 schrieb Richard Hughes:
On 26 May 2015 at 19:56, Hans de Goede hdegoede@redhat.com wrote:
What does "dead" in that table mean? I see a lot of games marked this way, and yes many games see little upstream activity, because once a game is finished it typically really is finished.
Dead means "no upstream release in 5 years"
that definition is simply broken if it ain't broken don't fix it
no idea why people these days always think everything needs massive change sand new releases each week to be fresh (and buggy all the time)
you need learn to accept that software reaches the point where iot is just *read yand finished* just because it does what it is supposed to do and needs ntohing fixed or changed all the time
If I add appdata files to packages marked dead, will that make them available in the software center? Or ... ?
Yes, that shows you care as a packager and allows you to "rescue" otherwise unloved applications
who are you to define if an application is "loved"
there are likely users who love it longer than you appeared with the appdata idea at all and install, upgrade it with no need for any shiny interface
On Tue, May 26, 2015 at 11:10:55PM +0200, Reindl Harald wrote:
Yes, that shows you care as a packager and allows you to "rescue" otherwise unloved applications
who are you to define if an application is "loved"
I think there is a language / cultural barrier here — I don't think Richard at all means to say that no one cares for these.
On 26 May 2015 at 22:10, Reindl Harald h.reindl@thelounge.net wrote:
you need learn to accept that software reaches the point where iot is just *read yand finished* just because it does what it is supposed to do and needs ntohing fixed or changed all the time
I assume you can point to several high-quality desktop GUI applications with 100% translator coverage with no reported bugs without a release in the last five years?
who are you to define if an application is "loved"
I'm the upstream and downstream maintainer of libappstream-glib, appstream-data, gnome-software, libhif, PackageKit and other software. I've been working in open source software for over a decade, most of that time working for Red Hat maintaining my packages in Fedora and RHEL. I've put significant amounts of work and personal time into making installing software easier. I like to believe software should be managed as a meritocracy, where the people doing all the hard work get to decide the direction a project gets to go.
there are likely users who love it longer than you appeared with the appdata idea at all and install, upgrade it with no need for any shiny interface
Sure, I'm not taking applications away from users. I'm saying that we need to raise the bar on application quality. If you want to be in the club, you have to play by the rules[1].
Richard
[1] https://github.com/hughsie/appstream-glib/blob/master/README.md#guidelines-f...
----- Original Message -----
Quite a few people are going to be installing Fedora 22 in the coming days, searching for things in the software center and not finding their esoteric GUI tool. This is because some applications still don’t ship AppData files, which have become compulsory in the workstation spin for this release. Luckily, the vast majority of applications that don't include AppData are not popular and most have little-to-no upstream activity.
If you want to check an application without installing F22 you can use this link http://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html -- if you fix an application I'll be regenerating that status page every 48 hours and shipping new a metadata release in a couple of weeks.
I tried to install Midnight Commander using software center, without success and I don't see it in the matrix you sent.
Is it GUI only or is there any chance to get at least TUI apps? Some as mc are pretty popular even in the group of GUI only users.
Jaroslav
Richard
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 27 May 2015 at 09:32, Jaroslav Reznik jreznik@redhat.com wrote:
Is it GUI only or is there any chance to get at least TUI apps? Some as mc are pretty popular even in the group of GUI only users.
I think mc fails quite a few of the criteria: https://github.com/hughsie/appstream-glib/blob/master/README.md -- apps without .desktop files for instance don't even make it into the logs.
The biggest reason of not including text programs is probably to avoid the slippery slope. Is a web service an application? What about text mode kernel development tools? Unless we can launch the application in the gnome-shell then we don't have a way to actually run the newly installed thing.
A few apps have found a way around these restrictions which is to include a .desktop file and .appdata.xml filr which launches a terminal with the command line tool running. Whether this is a fix or a hack is probably not for me to decide.
Richard
On Tue, 26 May 2015 16:33:19 +0100, Richard Hughes wrote:
http://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html
It kinda sucks that you list a "No keywords in .desktop file" warning for almost all packages even if they meet the packaging guidelines and the specific requirements of the F22 development cycle, i.e. running "appstream-util validate-relax" on the appdata file and "desktop-file-install" on the .desktop file. Normally one uses the development period to fix such issues.
What is that warning about?
There is no such warning in the build.log output:
+ desktop-file-install --dir /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/applications /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/applications/audacious.desktop + install -D -m0644 contrib/audacious.appdata.xml /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/appdata/audacious.appdata.xml + appstream-util validate-relax --nonet /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/appdata/audacious.appdata.xml /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/appdata/audacious.appdata.xml: GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. OK
On 27 May 2015 at 11:57, Michael Schwendt mschwendt@gmail.com wrote:
It kinda sucks that you list a "No keywords in .desktop file" warning for almost all packages even if they meet the packaging guidelines and the specific requirements of the F22 development cycle, i.e. running "appstream-util validate-relax" on the appdata file and "desktop-file-install" on the .desktop file. Normally one uses the development period to fix such issues.
It's not only the "green" applications that make the cut, the amber ones go in too. Having keywords makes the search functionality much better, but isn't actually required for your application to be shown in the software center. It would be disingenuous at best to show OK and use a green line when we're missing this extra data. I'll probably start nagging people about missing keywords in F23, i.e. real soon now.
There is no such warning in the build.log output:
I guess we should make desktop-file-validate check for keywords too, although they're not actually *required* to be a valid .desktop file.
Richard.
On Wed, 27 May 2015 12:47:04 +0100, Richard Hughes wrote:
It's not only the "green" applications that make the cut, the amber ones go in too.
Okay. Glad to hear we're not supposed to "fix" something like that post release.
Having keywords makes the search functionality much better, but isn't actually required for your application to be shown in the software center.
What would they add that's not found within the RPM package %description and %summary already?
It would be disingenuous at best to show OK and use a green line when we're missing this extra data. I'll probably start nagging people about missing keywords in F23, i.e. real soon now.
There is no such warning in the build.log output:
I guess we should make desktop-file-validate check for keywords too, although they're not actually *required* to be a valid .desktop file.
Anything that *upstream* would see, too, would be the best solution. Else it becomes a continuous race of upstream releasing files that follow the specs, and Fedora asking for extra optional (!) things to be added just to get rid of some warnings. Not even considering the translations of such keywords.
Crazy idea...
Could keywords be pulled from tagger which have been upvoted to a specific level?
Thanks, Richard
On Wed, May 27, 2015 at 10:11:55AM -0500, Richard Shaw wrote:
Crazy idea... Could keywords be pulled from tagger which have been upvoted to a specific level?
Hah, yes, this. :)
On Wed, May 27, 2015 at 05:07:52PM +0200, Michael Schwendt wrote:
Having keywords makes the search functionality much better, but isn't actually required for your application to be shown in the software center.
What would they add that's not found within the RPM package %description and %summary already?
Often, synonyms — terms that should apply, but for whatever reason isn't in the description.
Richard, sorry for the dumb question, but is there a path to pull in keywords from https://apps.fedoraproject.org/tagger/? Or, going the other way, can we get the Fedora apps team to highlight/prioritize packages which match applications on your list within Tagger?
On 27 May 2015 at 16:19, Matthew Miller mattdm@fedoraproject.org wrote:
Richard, sorry for the dumb question, but is there a path to pull in keywords from https://apps.fedoraproject.org/tagger/? Or, going the other way, can we get the Fedora apps team to highlight/prioritize packages which match applications on your list within Tagger?
We could certainly write a pretty simple plugin to query tagger for extra keywords, but I'd rather do this once for all packages and then cache the results as we actually need the keywords for searching.
Richard.
On Fri, May 29, 2015 at 02:45:51PM +0100, Richard Hughes wrote:
Richard, sorry for the dumb question, but is there a path to pull in keywords from https://apps.fedoraproject.org/tagger/? Or, going the other way, can we get the Fedora apps team to highlight/prioritize packages which match applications on your list within Tagger?
We could certainly write a pretty simple plugin to query tagger for extra keywords, but I'd rather do this once for all packages and then cache the results as we actually need the keywords for searching.
Yeah, that makes a lot of sense. I was thinking of something periodic rather than just once, though.
On 29 May 2015 at 15:57, Matthew Miller mattdm@fedoraproject.org wrote:
Yeah, that makes a lot of sense. I was thinking of something periodic rather than just once, though.
Does anybody know the URL to get the tags for all packages?
Richard.
On Fri, May 29, 2015 at 04:38:58PM +0100, Richard Hughes wrote:
On 29 May 2015 at 15:57, Matthew Miller mattdm@fedoraproject.org wrote:
Yeah, that makes a lot of sense. I was thinking of something periodic rather than just once, though.
Does anybody know the URL to get the tags for all packages?
According to the documentation: https://apps.fedoraproject.org/tagger/api/v1/
That would be: https://apps.fedoraproject.org/tagger/api/v1/tag/dump/ (takes a little while)
Pierre
----- Original Message -----
On 27 May 2015 at 16:19, Matthew Miller mattdm@fedoraproject.org wrote:
Richard, sorry for the dumb question, but is there a path to pull in keywords from https://apps.fedoraproject.org/tagger/? Or, going the other way, can we get the Fedora apps team to highlight/prioritize packages which match applications on your list within Tagger?
We could certainly write a pretty simple plugin to query tagger for extra keywords, but I'd rather do this once for all packages and then cache the results as we actually need the keywords for searching.
Just a drive-by remark to check whether those tags are translated...
On Wed, 27 May 2015 at 17:19 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, May 27, 2015 at 05:07:52PM +0200, Michael Schwendt wrote:
Having keywords makes the search functionality much better, but isn't actually required for your application to be shown in the software center.
What would they add that's not found within the RPM package %description and %summary already?
Often, synonyms — terms that should apply, but for whatever reason isn't in the description.
Richard, sorry for the dumb question, but is there a path to pull in keywords from https://apps.fedoraproject.org/tagger/? Or, going the other way, can we get the Fedora apps team to highlight/prioritize packages which match applications on your list within Tagger?
The fedora repository contains <ID>-pkgtags.sqlite.gz metadata, they was used by yum, but IFAIK not supported in dnf/hawkey/librepo but the information exist in the repositories.
/Tim
-
Bastien Nocera -
Hans de Goede -
Jaroslav Reznik -
Matthew Miller -
Michael Schwendt -
Pierre-Yves Chibon -
Reindl Harald -
Richard Hughes -
Richard Shaw -
Tim Lauridsen