Re: AppData in RPMFusion
On Thu, 2014-08-14 at 02:07 +1000, Ankur Sinha wrote: > 2. Who will generate the metadata and where? > > 3. How will the metadata be packaged to ship in the repositories? I did a trial run today. Interested folks can see the results on the bug here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2998#c10 The generated metadata and rpm are only about 350K at the moment. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part
Re: AppData in RPMFusion
On Wed, 2014-08-13 at 18:27 +0300, Nikos Roussos wrote: > Elad's proposal is about deciding if we want RPMFusion packages to be > accessible to Desktop Fedora users or not. It's that simple. Bringing the thread back to topic. Questions that need answering: 0. Do we want to ship appdata for RPMFusion packages? If we do: 1. do we start filing bugs with packages that do not currently ship appdata files asking maintainers to: a. ship an appdata file b. send the file upstream for inclusion 2. Who will generate the metadata and where? 3. How will the metadata be packaged to ship in the repositories? Please see my comment on the tracker bug for more details on the complete workflow: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2998#c4 -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part
Re: AppData in RPMFusion
Karel Volný wrote: > > Hi, > > not that I'd oppose the idea as a whole, but I'm a bit concerned about > this part: > >> The AppData metadata includes simple XML files with app descriptions, and > a >> tarball of app icons. >> They can be distributed in the rpmfusion-free-release and >> rpmfusion-nonfree-release packages and will only add a couple more >> megabytes. I'd suggest you followup on appdata discussion and (constructive) criticism on fedora's -devel list. At this point, it's not a matter of *if* appdata will be adopted, but when (f22). Be a part of the discussion (and solution) there. -- rex
Re: AppData in RPMFusion
The point of this thread is not to judge how the new Software app works. If someone has suggestions that would improve it, he/she should go upstream (Gnome). Elad's proposal is about deciding if we want RPMFusion packages to be accessible to Desktop Fedora users or not. It's that simple. signature.asc Description: This is a digitally signed message part
Re: AppData in RPMFusion
Your mail was full of personal attacks on me and other gnome-software / appstream developers. As such I am not going to respond to any of the points you raised. Goodbye.
Re: AppData in RPMFusion
Hi, Dne středa, 13. srpna 2014 10:32:58 CEST, Elad Alfassa napsal(a): On Tue, Aug 12, 2014 at 4:52 PM, Karel Volný wrote: now I'm confused, as you talked about putting it into *-release ...? Re-read my message please. I suggested two options: putting the metadata in the release packages *or* in a separate package. I thought I've read that carefully ... in the first e-mail, you've written: "They can also be distributed in a different package ... but the user experience will suffer" from which I boldly deduced that putting it into *-release is your preferred method then you change to "That's why I suggested ... using a separate package." the fact is that now you're formally correct, you've really mentioned both options but you've put one before the second and treated the second as inferior and in the followup you turn 180 degrees and say you have reasons for the second maybe I was too hasty to deduce that you'd prefer the method where user experience won't suffer, but I just don't like this style of communication where you say you're suggesting something you were arguing against, dude You update the appdata xml that is in your package, and at some point the appstream-data-rpmfusion package will get rebuilt either by automatic process or manual rebuild. "you" in this context refers either to rpmfusion infrastructure or the person who will manually rebuild the appdata package. Ideally it should be automated. As a packager, all you'd need to do is make sure you install your appdata xml to /usr/share/appdata so, the application package will install a file that is of no use except "when building and composing distributions"[1] on which ocassion the contents will be copied to some database (probably in /usr/share/app-info/xmls [2]), that takes some more 3.3 MB / 769 KB un/packed[3]? either I am missing something, or the design is heavily flawed the cherry on top is (again [1]): What happens if I don't ship this file? The GNOME Software Center currently shows a nag message that the upstream project doesn't ship the additional data. Additionally, we will penalize apps that do not ship the extra metadata by showing them lower in the search results. - cool, so the project is here not to help users, but to boost ego of some developers that have the urge to force others to do additional work to implement the one and only right_way(tm) of providing application description ... or how should I interpret the fact that they are going to make it harder for users to find what they search for? [1] from http://people.freedesktop.org/~hughsient/appdata/ [2] guessing from http://people.freedesktop.org/~hughsient/temp/appstream-data.spec [3] http://people.freedesktop.org/~hughsient/temp/fedora-20.xml.gz what seems interesting is "+@INTLTOOL_XML_RULE@", okay, so let's take a look how does it work, let's go to homepage: http://freedesktop.org/wiki/ Software/intltool/ um, no single mention of any such macro, well, in fact, no documentation at all? seriously? do I really have to read sources of that crap to get basic understanding what does it do? Crap? Okay, dude, calm down, there's no call for name calling. why not to call things the names they deserve? good documentation is an essential part of good project Of course you don't see localized strings in the patch, you never put localized strings in the source files. however, I do put it into the source tree (be the files *.po or *.ts or whatever) - and there is nothing like that in the example patch[4], that touches more files than just gcm-viewer.appdata.xml.in [4] http://people.freedesktop.org/~hughsient/appdata/example-intltool.patch You do it in .po file. Regenerating the .pot file will make it have the strings from the appdata for translators to translate. ok, so it is like xgettext[5] but it handles xml ... [5] btw, https://www.gnu.org/software/gettext/manual/gettext.html If you want to see the RESULT, just cat /usr/share/appdata/totem.appdata.xml okay, that explains the question - so the locales are not in some kind of *.mo files but directly inside the *.xml file distinguished by the 'xml:lang="code"' attribute it may seem trivial to you, but I've never worked with this before and I just can't get information out of vacuum - xml is only a container that can be used in many ways, and the sole possibility to add Language identification as per section 2.12 of the XML 1.0 recommendation doesn't imply anything about actual implementation (it could have been e.g. multiple files, one per language, as the abovementioned .mo works, or the translations could have been kept separately in message catalogs etc.) But these are things you need as an app author, not a packager. I'd tend to disagree - if file(s) installation is involved then the packager should know how do the things work; he may even assist upstream (author) if the request to provide the file comes from downstream (
Re: AppData in RPMFusion
On Tue, 2014-08-12 at 11:34 +0300, Nikos Roussos wrote: > +1. I think it's really frustrating for end users that they can't > currently find RPMfusion applications through Software Center (which > is > the default and only preinstalled application for installing new > software). +1 The fedora packages have already been receiving quite a bit of love when it comes to appdata. It'll be a good idea to have it for rpmfusion as well. This is all from the point of a normal, non advanced end user who will use gnome-software to install applications. More advanced users that do not use gnome-software and prefer yum/yumex/dnf etc. will know that they can add the package to their list of "excludes" if they want to save their bandwidth. This isn't rpmfusion specific, this applies to any repositories and a general usage of gnome-software. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part
Re: AppData in RPMFusion
On Tue, Aug 12, 2014 at 4:52 PM, Karel Volný wrote: > > now I'm confused, as you talked about putting it into *-release ...? Re-read my message please. I suggested two options: putting the metadata in the release packages *or* in a separate package. > > so it will be duplicated ... rpm still cannot handle multiple ownership of > a file? No. Your regular packages will NOT install icons to the /usr/share/app-info folder. The package containing the metadata will own that folder and all the files with it. I fail to see why this confuses you so much. Your regular package will keep installing the icons in the same place it always have, this doesn't change that. > > To ensure they "won't get out of sync" you need to do weekly/monthly >> rebuilds of the metadata and issue it as a regular package update. >> > > "you" means me as the application maintainer, or someone else who will > maintain AppData? > > "regular package update" means AppData upgrade and not e.g. in my example > qmmp? You update the appdata xml that is in your package, and at some point the appstream-data-rpmfusion package will get rebuilt either by automatic process or manual rebuild. "you" in this context refers either to rpmfusion infrastructure or the person who will manually rebuild the appdata package. Ideally it should be automated. As a packager, all you'd need to do is make sure you install your appdata xml to /usr/share/appdata > > > hm, I don't feel any wiser now :-( > > I (or the upstream developer) can implement my own way of getting > translations to the XML files only if I know how it should look like in the > XML file? > - there doesn't seem to be any DTD available, and the "File specification" > doesn't give a damn about different languages handling (except for the note > that screenshots should be taken in English) > > looking at the example: > http://people.freedesktop.org/~hughsient/appdata/example-intltool.patch > > I see exactly _zero_ localised strings > > what seems interesting is "+@INTLTOOL_XML_RULE@", okay, so let's take a > look how does it work, let's go to homepage: http://freedesktop.org/wiki/ > Software/intltool/ > > um, no single mention of any such macro, well, in fact, no documentation > at all? seriously? do I really have to read sources of that crap to get > basic understanding what does it do? > > Crap? Okay, dude, calm down, there's no call for name calling. Of course you don't see localized strings in the patch, you never put localized strings in the source files. You do it in .po file. Regenerating the .pot file will make it have the strings from the appdata for translators to translate. If you want to see the RESULT, just cat /usr/share/appdata/totem.appdata.xml If you need a schema, here it is https://github.com/hughsie/appdata-tools/blob/master/data/appdata.xsd https://github.com/hughsie/appdata-tools/blob/master/data/appdata.rnc Here is another Makefile example https://git.gnome.org/browse/totem/tree/data/appdata/Makefile.am But these are things you need as an app author, not a packager. This is not the place to discuss this thing, if you want you can send a mail to Richard or to the fedora devel list, I'm sure they'll be happy to assist you. Furthermore, regarding your concerns about size, the appdata package for RPMFusion will be less than 3MB according to my calculations. It's small enough for everyone, we are in 2014, not 1995. -- -Elad Alfassa.
Re: AppData in RPMFusion
Hi, The AppData metadata includes simple XML files with app descriptions, and a tarball of app icons. They can be distributed in the rpmfusion-free-release and rpmfusion-nonfree-release packages and will only add a couple more megabytes. from the user's point of view, even if it is only "a couple megabytes", I'm not that happy if my precious resources are eaten up by things I do not use (while not that important on a desktop with unlimited 100 Mbps internet connection, situation could be quite a different on some mobile device with pretty expensive mobile connection) That's why I suggested the approach currently taken by fedora of using a separate package. now I'm confused, as you talked about putting it into *-release ...? For Fedora, the metadata + icons is 7.3MB according to yum info appstream-data. This would be much less for rpmfusion as rpmfusion has much less graphical applications. I don't consider 7.3MB a lot, in these days when storage is relatively cheap. "relatively" is the key what is cheap for you doesn't mean cheap for everyone - for sure, storage is much cheaper than x years ago, but many people keep those x years old computers as they still work and I don't see any reasons to force them to upgrade just for _optional_ features (in fact, they often switched to linux because Windows would force them to buy new hardware) ... maybe you change the furniture in your house (and the whole house?) each two years or so, but I keep it until it is broken beyond repair, and the same goes for electronic devices, they serve until they are able to serve ... I just hate those piles of old crap in our backyards, and those poisons in the air/water/soil emitted while manufacturing all the new crap ... 7 MB in a distro that has about 10 GB installed packages by default seems like nothing ... but I just find the attitude wrong - how did we got to those 10 GB when my (and hardly any other _home_ user's) productivity with the software hasn't increased since early nineties when I had about 30 MB for system and 50 MB for data (and in some cases, software that had output/workflows of the same quality as recent applications existed even in 1980's ...)? and it's not only the old hardware - another thing is miniaturization, it may be cheap to buy a new SD card, but if you have just one slot in your Raspberry Pi ... similarly it goes for the bandwith as mentioned by Emmanuel - deltarpm is nice, but it has its own problems ... if the estimated number of Fedora users is about 2.5 million, in theory, if 1% of them would have pay-per-megabyte connection, the price would be 0.005 cents per kilobyte on average[*], and deltarpm would manage to squeeze the update to 10 kilobytes, that's 2.5 M * 1% * 10 KB * 0.005 c = $1250 per one update [*] I'm using the price of my mobile connection which I think is somewhere in the middle between developed and developing countries of course, the number is completely made up, it's just for putting things into context ... it's cheap when you don't have to pay those $1250 weekly from your pocket (and no single person would care about 0.05 cents), right? (... and no one cares how much that additional load costs the owners of download mirrors) now let's go further ... if the typical installation has about 2000 packages, what if there would be something "nice to have" for each of them that would increase the size of the package by those "cheap" seven megabytes? dismissing concerns as "it is just one slice of salami, that's nothing" is IMO very misleading we need to think in the global numbers - take UPS as an example: planning for one car doesn't make difference, planning for tens thousands? - http://www.pressroom.ups.com/Fact+Sheets/Saving+Fuel:+UPS+Saves+Fuel+and+Reduces+Emissions+the+"Right"+Way+by+Avoiding+Left+Turns so yes, provide new features, but think how to minimalise the negative impact and how to allow opt-out for those who do not need/want them (and even if it shouldn't be rather opt-in than default that needs to be opted-out) from the developers point of view, I just wonder what will happen with the icons packaged with the applications - are they going to be moved (i.e. a lot of cross-dependencies created and some extra work as we'd need to update two packages), or are they going to be duplicated (how will we ensure that it wouldn't get out of sync), or what? The app icons for the appdata are extracted to /usr/share/app-info/icons/fedora-21/ - they are not installed in /usr/share/icons or similar, so no conflict or anything like that. They are always there when the metadata is installed. so it will be duplicated ... rpm still cannot handle multiple ownership of a file? To ensure they "won't get out of sync" you need to do weekly/monthly rebuilds of the metadata and issue it as a regular package update. "you" means me as the application maintainer, or someone else who will maintai
Re: AppData in RPMFusion
On Tue, Aug 12, 2014 at 12:48 PM, Emmanuel Seyman wrote: > * Elad Alfassa [11/08/2014 19:28] : > > > > I don't consider 7.3MB a lot, in these days > > when storage is relatively cheap. > > The problem isn't so much storage but bandwidth. Some people have capped or > slow bandwidth and don't appreciate packages that are regularly rebuilt and > pushed as updates. You have to update the metadata *somehow*. There are delta RPMs if you want to conserve bandwidth. > > I'ld love some data so that we can better make up our minds. How many > .desktop > files do we ship? How many of these do we want to advertise via > gnome-software? > Etc... > > Emmanuel > There are around 126 desktop files in RPM Fusion, some of which we'll probably want to blacklist (or are already blacklisted by the rules in createrepo_as). Assuming an average of 10KB for each icon file this means 1.2MB of icons (the actual number will probably be smaller). This is not much, even for people with limited bandwidth. -- -Elad Alfassa.
Re: AppData in RPMFusion
* Elad Alfassa [11/08/2014 19:28] : > > I don't consider 7.3MB a lot, in these days > when storage is relatively cheap. The problem isn't so much storage but bandwidth. Some people have capped or slow bandwidth and don't appreciate packages that are regularly rebuilt and pushed as updates. I'ld love some data so that we can better make up our minds. How many .desktop files do we ship? How many of these do we want to advertise via gnome-software? Etc... Emmanuel
Re: AppData in RPMFusion
On Mon, 2014-08-11 at 18:06 +0300, Elad Alfassa wrote: > Hello RPM Fusion developers. > > > I'm interested in adding AppData metadata for RPM Fusion. > > This will make RPMFusion apps look better in gnome-software (the > default app installer in Fedora) and greatly improve our user > experience. RPM Fusion apps will be easily discoverable by users and > will get more exposure. Users will no longer need to use a command > line to install VLC, for example. > > > The AppData metadata includes simple XML files with app descriptions, > and a tarball of app icons. > > They can be distributed in the rpmfusion-free-release and > rpmfusion-nonfree-release packages and will only add a couple more > megabytes. > > They can also be distributed in a different package (that would be > pulled by a comps group like RPM Fusion already does for certain > codecs), but the user experience will suffer because the users need to > run an update to get the metadata. > > > The generated metadata can also contain screenshots, but those are not > installed on the user's computer but rather pulled from a web server. > > > > I'm willing to help to get RPM Fusion to have application metadata, > but I'm unfamiliar with the rpmfusion infrastructure and workflows, so > I'll need help with someone who is familiar with rpmfusion more. > > > > So, what do you say? Do you want RPM Fusion to have AppData metadata? +1. I think it's really frustrating for end users that they can't currently find RPMfusion applications through Software Center (which is the default and only preinstalled application for installing new software). ~nikos signature.asc Description: This is a digitally signed message part
Re: AppData in RPMFusion
On Mon, Aug 11, 2014 at 6:34 PM, Karel Volný wrote: > > Hi, > > not that I'd oppose the idea as a whole, but I'm a bit concerned about > this part: > > > The AppData metadata includes simple XML files with app descriptions, and >> > a > >> tarball of app icons. >> They can be distributed in the rpmfusion-free-release and >> rpmfusion-nonfree-release packages and will only add a couple more >> megabytes. >> > > from the user's point of view, even if it is only "a couple megabytes", > I'm not that happy if my precious resources are eaten up by things I do not > use (while not that important on a desktop with unlimited 100 Mbps internet > connection, situation could be quite a different on some mobile device with > pretty expensive mobile connection) > That's why I suggested the approach currently taken by fedora of using a separate package. For Fedora, the metadata + icons is 7.3MB according to yum info appstream-data. This would be much less for rpmfusion as rpmfusion has much less graphical applications. I don't consider 7.3MB a lot, in these days when storage is relatively cheap. > from the developers point of view, I just wonder what will happen with the > icons packaged with the applications - are they going to be moved (i.e. a > lot of cross-dependencies created and some extra work as we'd need to > update two packages), or are they going to be duplicated (how will we > ensure that it wouldn't get out of sync), or what? > The app icons for the appdata are extracted to /usr/share/app-info/icons/fedora-21/ - they are not installed in /usr/share/icons or similar, so no conflict or anything like that. They are always there when the metadata is installed. To ensure they "won't get out of sync" you need to do weekly/monthly rebuilds of the metadata and issue it as a regular package update. > > K. > > p.s. somehow I cannot understand how do the translations work ... > Each upstream project can implement their own way of getting translations to the XML files, using gettext and similar things. You can look in some GNOME projects if you want to see examples. gnome-boxes for example uses INTLTOOL_XML_RULE for this. -- -Elad Alfassa.
Re: AppData in RPMFusion
Hi, not that I'd oppose the idea as a whole, but I'm a bit concerned about this part: The AppData metadata includes simple XML files with app descriptions, and a tarball of app icons. They can be distributed in the rpmfusion-free-release and rpmfusion-nonfree-release packages and will only add a couple more megabytes. from the user's point of view, even if it is only "a couple megabytes", I'm not that happy if my precious resources are eaten up by things I do not use (while not that important on a desktop with unlimited 100 Mbps internet connection, situation could be quite a different on some mobile device with pretty expensive mobile connection) from the developers point of view, I just wonder what will happen with the icons packaged with the applications - are they going to be moved (i.e. a lot of cross-dependencies created and some extra work as we'd need to update two packages), or are they going to be duplicated (how will we ensure that it wouldn't get out of sync), or what? K. p.s. somehow I cannot understand how do the translations work ... -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp ka...@jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity."
