On Fri, Jan 29, 2016 at 11:50:46AM +0100, Dominique Leuenberger / DimStar wrote:

On Thu, 2016-01-28 at 19:05 -0600, Chan Ju Ping wrote:

...

I have the following mystery I would like to understand. When I run zypper dup  this is the output I get:

" The following 5 applications are going to be REMOVED:

ImagePlugin-Color ImagePlugin-Decorate ImagePlugin-Enhance ImagePlugin- FxFilters ImagePlugin-Transform

No additional space will be used or freed after the operation. Nothing to do. "

I don't see any of these packages in the repositories, though a quick online  search tells me they are digikam related. Anyone here who could inform me as  to what may be going on?

It says 'applictions' - not packages... there is a subtle difference. In this case, the issue is that the meta data generated for the packages is not fully correct. With the info at hand, zypper knows 'I have this now installed, but per the info I receive, the new 'package' no longer has the 'reference to the application'. In fact, it's about 'plugins' here.

Using zypper, you can search for apps for example using:   zypper se -t application

This is getting more an more interesting as 'users are interested in applications, not packages' - packages are a technicality.

Honestly I don't need it and several others too. Instead we're forced to download this meta data again and again and in particular when you're on the road this is more than annoying. Seife made a suggestion but the patch wasn't good enought. Instead to enhance it we're currently in the situation to get a quite missleading message presented while updating Tumbleweed. Please merge Seifes patch or help him to enhance it. Or drop this stuff which only is of use to Gnome users IIRC. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Fri, 2016-01-29 at 13:31 +0100, Lars Müller wrote:

On Fri, Jan Please merge Seifes patch or help him to enhance it.  Or drop this stuff which only is of use to Gnome users IIRC.

No. Help KDE Upstream to get their app center finally in a shape as well and stop arguing that this is a GNOME thing. Appstream is intentionally NOT DE-specific Sorry, this is mumbo jumbo non-sense. The fact that zypper is 'just learning how to interpret the complex data' is a different story - and this needs fixing / training (maybe wise for now to tell zypp not to show such messages except if you're a user that understands what he's doing and that understand appstream - so that the ones actually caring for it can fix it without confusing the others) Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2016-01-29 at 13:50 +0100, Lars Müller wrote:

  Ok, if this is non-sense, then it's time to stop using Tumbleweed?

???

You're not helping to get this issue out of the way.  Instead you blame the messanger.  Nice.

??? I don't blame zypper as messenger.. all I said is that it's still learning some of the feature set - AND most such messages can even be broken down to a packaging error (not in case of digikam though)

This noice is there and if it is independent of the DE than it's even worse and what's causing it should be removed.

RIGHT! Zypper is DE-agnostic. I would say if zypper behaves different based on the DE used, it would be broken. It's a CLI tool afeer all! NO DE is at fault here. digikam is a KDE app right? One can argue that Upstream CARES for this kind of meta info for Software Centers: or they would not ship the files. I still stand: let's FIX things, not reduce features. Cheers, Dominique (please keep the thread short so it does not bypass the size af AppStream metadata that I already have to download) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 29.01.2016 um 13:56 schrieb Dominique Leuenberger / DimStar:

On Fri, 2016-01-29 at 13:50 +0100, Lars Müller wrote:

...

Ok, if this is non-sense, then it's time to stop using Tumbleweed?

???

Well, Factory/Tumbleweed updates are painful because of having to download the metadata all the time.

??? I don't blame zypper as messenger.. all I said is that it's still learning some of the feature set - AND most such messages can even be broken down to a packaging error (not in case of digikam though)

And it would be very nice if libzypp could learn how to skip this completely. /etc/zypp/zypp.conf metadata.appstream.download = {never,on-demand,always} I would not even start to argue if the default would not be "never", but "on-demand" :-P

...

This noice is there and if it is independent of the DE than it's even worse and what's causing it should be removed.

RIGHT! Zypper is DE-agnostic. I would say if zypper behaves different based on the DE used, it would be broken. It's a CLI tool afeer all! NO DE is at fault here. digikam is a KDE app right? One can argue that Upstream CARES for this kind of meta info for Software Centers: or they would not ship the files.

I still stand: let's FIX things, not reduce features.

I still stand: don't waste everyone's time and bandwidth for marginal benefits of a few users.

(please keep the thread short so it does not bypass the size af AppStream metadata that I already have to download)

You don't, just use my patched libzypp from home:seife:testing! :-) And to exceed the size of these metadata, we would need to write waaaay more mails :-) Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2016-01-29 at 16:34 +0100, Stefan Seyfried wrote:

By the way -- a (not so) fun fact: the metadata is published and downloaded multiple times.

* http://download.opensuse.org/factory/repo/oss * http://download.opensuse.org/factory/repo/debug * http://download.opensuse.org/factory/repo/src-oss

All contain similar sized appdata-* files.

repo-oss:  appdata.xml.gz                   27-Jan-2016 03:15  1.6M  repo-debug: appdata.xml.gz                     27-Jan-2016 03:27   94   repo-src-oss: appdata.xml.gz                          27-Jan-2016 03:31   94  'almost the same size' - the two times 94bytes are exactly the same size (and same content) But I *do* see an error there: there is actually no reason why the appdata-icons would have content in src/debug repo... *THAT* is called a bug. I'll have a look at that one (somebody feel free to file one if you want to monitor on it) Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2016-01-29 at 17:10 +0100, Stefan Seyfried wrote:

Am 29.01.2016 um 16:52 schrieb Dominique Leuenberger / DimStar:

...

On Fri, 2016-01-29 at 16:34 +0100, Stefan Seyfried wrote:

...

By the way -- a (not so) fun fact: the metadata is published and downloaded multiple times.

* http://download.opensuse.org/factory/repo/oss * http://download.opensuse.org/factory/repo/debug * http://download.opensuse.org/factory/repo/src-oss

All contain similar sized appdata-* files.

repo-oss:  appdata.xml.gz                   27-Jan-2016 03:15  1.6M 

repo-debug: appdata.xml.gz                     27-Jan-2016 03:27   94  

repo-src-oss: appdata.xml.gz                          27-Jan-2016 03:31   94 

'almost the same size' - the two times 94bytes are exactly the same size (and same content)

I looked at the icons, which are the biggest (and -- in case of zypper -- absolutely useless ;-)) part.

And the icons were the part which initially made me notice this slow-updates-down-to-a-crawl "feature" :-)

Actually I already  managed to spot where things go wrong, fixed it, submitted it and some of the future TW snaoshots will publish the icon tarball only once, in the repo where the apps actually live... so /debug and /src repos will both save quite some bandwidth here Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 29.01.2016 um 18:38 schrieb Stefan Bruens:

Althoug I understand some tumbleweed (or any other (open)SUSE) variant) users are perfectly happy with the current package information and software install process, it would be nice if these persons would try to adapt their view to one of a new openSUSE/Linux user.

It's unlikely I'll change my opinion about the usefulness of this appstream stuff *for me*.

A modern software manager has to compete with todays smartphone "App stores" - screenshots, no-techno-babble description.

I partly agree with that, and I have stated that before. But not by forcing everyone to carry the burden with every update.

If there are technical problems, solve them.

Exactly. Download "the crap" ;) on demand, when you have a system that will actually use them.

The icons should be almost static data, so downloads should be rare.

Should. Fact is, the tarball is obviously rebuilt on every publish of the repo.

If small changes cause whole metadata download, change the metadata format, make containers/archives rsyncable. Huge downloads are bad, but this can be solved on a technical level.

No matter how big or small: just not downloading them at all if they are not needed saves both bandwidth (on both sides) and storage (on my side). (I do not agree that smartphone-like appstores are the best solution -- e.g. it is often impossible to even find out a version number of the stuff you are installing.) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2016-01-29 at 19:34 -0500, Patrick Shanahan wrote:

* Dominique Leuenberger / DimStar [01-29-16 11:14]:

...

On Fri, 2016-01-29 at 17:10 +0100, Stefan Seyfried wrote:

...

Am 29.01.2016 um 16:52 schrieb Dominique Leuenberger / DimStar:

...

On Fri, 2016-01-29 at 16:34 +0100, Stefan Seyfried wrote:

...

By the way -- a (not so) fun fact: the metadata is published and downloaded multiple times.

* http://download.opensuse.org/factory/repo/oss * http://download.opensuse.org/factory/repo/debug * http://download.opensuse.org/factory/repo/src-oss

All contain similar sized appdata-* files.

repo-oss:  appdata.xml.gz                   27-Jan-2016 03:15  1.6M 

repo-debug: appdata.xml.gz                     27-Jan-2016 03:27   94  

repo-src-oss: appdata.xml.gz                          27-Jan-2016 03:31   94 

'almost the same size' - the two times 94bytes are exactly the same size (and same content)

I looked at the icons, which are the biggest (and -- in case of zypper -- absolutely useless ;-)) part.

And the icons were the part which initially made me notice this slow-updates-down-to-a-crawl "feature" :-)

Actually I already  managed to spot where things go wrong, fixed it, submitted it and some of the future TW snaoshots will publish the icon tarball only once, in the repo where the apps actually live... so /debug and /src repos will both save quite some bandwidth here

here are two that didn't get fixed:     calibre-ebook-viewer     calibre-gui

Not surprising - I referred to having fixed the multiple publishing of the icons tarball in multiple repositories, where it should only be in the main repo. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2016-01-29 at 13:55 +0100, Yamaban wrote:

On Fri, 29 Jan 2016 13:36, Dominique Leuenberger / DimStar wrote:

...

On Fri, 2016-01-29 at 13:31 +0100, Lars Müller wrote:

...

On Fri, Jan

Please merge Seifes patch or help him to enhance it.  Or drop this stuff which only is of use to Gnome users IIRC.

No. Help KDE Upstream to get their app center finally in a shape as well and stop arguing that this is a GNOME thing. Appstream is intentionally NOT DE-specific

Sorry, this is mumbo jumbo non-sense. The fact that zypper is 'just learning how to interpret the complex data' is a different story - and this needs fixing / training (maybe wise for now to tell zypp not to show such messages except if you're a user that understands what he's doing and that understand appstream - so that the ones actually caring for it can fix it without confusing the others)

IMHO, it a matter of wrong defaults. The cli tool 'zypper' should NOT show such messages unless an option is explicitly set to show this data.

The cli tool is either used by experts, which are able to read "zypper help" or "man zypper" - or - and this is even more dangerous in the way of missinterpration: a casual user, that has no real experiance and/or training in administration of a system.

So, in the interest of KISS, keep that data hidden until explicitly asked for.

That libzypp provides this data is well and good. Just not in default for the cli.

Idea: use a option: "showApplicationData" type "boolean", default "no" in the /etc/zypp/zypper.conf file.

That way all will be happy, and served well.

Have a nice weekend   - Yamaban.

That goes pretty much in line with the idea I formulated, you just did a much better job in thinking implementation wise, I only formulated feature wise. We should ensure though that sufficient people switch it on and report on issues - or zypper / libzypp / libsolv won't ever have the chance to fix all the issues (and yes: the bugs reported ARE being worked on) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

...

That libzypp provides this data is well and good. Just not in default for the cli.

It does not need to gather / download this data at all if there is no user for it.

zypper IS a user of it: zypper in -t application JuK zypper in -t application "moserial Terminal" zypper se -t application Just because one does not know about the feature does not make the feature go away. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 29.01.2016 um 13:36 schrieb Dominique Leuenberger / DimStar:

On Fri, 2016-01-29 at 13:31 +0100, Lars Müller wrote:

...

On Fri, Jan Please merge Seifes patch or help him to enhance it. Or drop this stuff which only is of use to Gnome users IIRC.

No. Help KDE Upstream to get their app center finally in a shape as well and stop arguing that this is a GNOME thing. Appstream is intentionally NOT DE-specific

Thanks, but I'm also not interested in a KDE solution. The whole concept of "APPS" instead of packages does not make sense *for me* (and I have a slight guess that Lars also does not really see the benefit he gets from it ;-). I understand and acknowledge that there are users who might have a different view on this, but I do not understand and approve that all other users have to suffer badly from this.

Sorry, this is mumbo jumbo non-sense. The fact that zypper is 'just learning how to interpret the complex data' is a different story - and this needs fixing / training (maybe wise for now to tell zypp not to show such messages except if you're a user that understands what he's doing and that understand appstream - so that the ones actually caring for it can fix it without confusing the others)

It still forces me to download huge, useless (for me) metadata. And because it is metadata, it is (AFAICT) always downloaded from the slow main mirror, making this a pain even with an 100mbit downstream pipe. The whole reason I even found out about this appstream stuff is that I was wondering why minimal daily Factory updates took so long. Guess what, it was *not* the few packages that got updated. The right thing (IMO) would be that a "appcenter" that wants to have the appstream metadata either downloads it by itself or, probably better, libzypp gets an interface for the "client" to request this metadata. And plain zypper will certainly not request this by default, since obviously it cannot handle it anyway. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday, January 29, 2016 11:50:46 AM CST Dominique Leuenberger / DimStar wrote:

It says 'applictions' - not packages... there is a subtle difference. In this case, the issue is that the meta data generated for the packages is not fully correct. With the info at hand, zypper knows 'I have this now installed, but per the info I receive, the new 'package' no longer has the 'reference to the application'. In fact, it's about 'plugins' here.

Using zypper, you can search for apps for example using: zypper se -t application

This is getting more an more interesting as 'users are interested in applications, not packages' - packages are a technicality.

Cheers, Dominique

Thanks Dominique. What would be the recommended action in with this output? Follow Zypper's advise and try to remove it manually, or wait for future snapshots to hopefully cover the issue? -Ju Ping.

On Friday, 29 January 2016 11:50:46 CST Dominique Leuenberger / DimStar wrote:

On Thu, 2016-01-28 at 19:05 -0600, Chan Ju Ping wrote:

...

Hello mailing list!

I have the following mystery I would like to understand. When I run zypper dup this is the output I get:

" The following 5 applications are going to be REMOVED:

ImagePlugin-Color ImagePlugin-Decorate ImagePlugin-Enhance ImagePlugin- FxFilters ImagePlugin-Transform

No additional space will be used or freed after the operation. Nothing to do. "

I don't see any of these packages in the repositories, though a quick online search tells me they are digikam related. Anyone here who could inform me as to what may be going on?

It says 'applictions' - not packages... there is a subtle difference. In this case, the issue is that the meta data generated for the packages is not fully correct. With the info at hand, zypper knows 'I have this now installed, but per the info I receive, the new 'package' no longer has the 'reference to the application'. In fact, it's about 'plugins' here.

Using zypper, you can search for apps for example using: zypper se -t application

This is getting more an more interesting as 'users are interested in applications, not packages' - packages are a technicality.

Cheers, Dominique

Latest zypper dup seems to have fixed the problem on the computer I am writing this email from. Interestingly enough, I am sitting beside another laptop I just converted to a Tumbleweed machine mere hours ago showing the same message. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org