On Saturday 2014-03-08 18:13, Andrey Borzenkov wrote:

...

...

S | Name | Type | Version | Arch | Repository --+----------------------+---------+----------------------+--------+------------------ i | kernel-desktop | package | 3.13.5-18.2.gbb654e2 | x86_64 | i | kernel-desktop | package | 3.13.5-18.1.gbb654e2 | x86_64 | i | kernel-desktop | package | 3.13.5-17.1.g4e9ddcc | x86_64 | i | kernel-desktop | package | 3.13.4-16.1.g6eda950 | x86_64 | i | kernel-desktop | package | 3.13.3-15.2.g7ccf96b | x86_64 | i | kernel-desktop | package | 3.13.3-15.1.g7ccf96b | x86_64 |

The following NEW package is going to be installed: kernel-desktop-3.13.5-18.3.gbb654e2

zypper dup wants to re-install nearly 200 already install packages.

Perhaps the crazy versioning happening with TW? I just noticed the diff of .1.gbb654e2 and .3.gbb654e2. Is this kernel different or the same?

Second digit is usually RPM rebuild count. It may happen when just RPM spec changed or when some requisite package was changed triggering rebuild.

In other words, the gbb654e2 identifer is placed in the wrong spot. It really should be part of %version, not %release. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

В Sat, 08 Mar 2014 18:34:09 +0100 Stefan Seyfried пишет:

Am 08.03.2014 18:31, schrieb Jan Engelhardt:

...

On Saturday 2014-03-08 18:13, Andrey Borzenkov wrote:

...

Second digit is usually RPM rebuild count. It may happen when just RPM spec changed or when some requisite package was changed triggering rebuild.

In other words, the gbb654e2 identifer is placed in the wrong spot. It really should be part of %version, not %release.

No, because it does not necessarily increase with each checkin.

So what? Version numbers do not normally increase with each checkin in OBS. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 2014-03-08 19:04, Stefan Seyfried wrote:

Am 08.03.2014 19:03, schrieb Andrey Borzenkov:

...

So what? Version numbers do not normally increase with each checkin in OBS.

But they also should not decrease. Which they might if the git id would be in %version.

That's why there should be a linear monotonic offset in the number; a discussion not too long ago I remember... ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Greg, On Saturday, March 08, 2014 23:13:08 Greg KH wrote:

On Sat, Mar 08, 2014 at 11:59:07AM -0500, Ken Schneider wrote:

...

Running zypper dup wants to install already installed packages.

_Example:_

[code]

toshiba-lt:~ # zypper se -is kernel-desktop Loading repository data... <snip>> > The following NEW package is going to be installed: kernel-desktop-3.13.5-18.3.gbb654e2

1 new package to install. Overall download size: 42.6 MiB. After the operation, additional 174.5 MiB will be used. Continue? [y/n/? shows all options] (y): n toshiba-lt:~ #

[/code]

zypper dup wants to re-install nearly 200 already install packages.

That's because all of the Tumbleweed repo just rebuild due to KDE updates, as well as other core updates (kmod and util-linux).

So this is to be expected, and just part of the deal with Tumbleweed.

re: kde update, is it possible to have it pushed once a week or so? Currently, I'm getting them 450MB at a time two to three times a week. Not that I mind really, connection can take it, but taking the median denominator I'm sure not everyone is happy with it. In this, I'm probably missing something else so please correct me if my point of view is wrong.

thanks,

greg k-h

Kind regards, Jason -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg KH writes:

That's because all of the Tumbleweed repo just rebuild due to KDE updates, as well as other core updates (kmod and util-linux).

The kernel should either a) never rebuild or b) the version number needs to change with each rebuild or c) all tools making use of the version number need to recognize that a rebuild of the kernel actually overwrites any earlier builds of the same version kernel so the old build is no longer available or d) the kernel installation needs to include the build number so that multiple builds of the same versions can coexist on disk.

So this is to be expected, and just part of the deal with Tumbleweed.

I'm not going into that discussion again as it should really be about osc and not Tumbleweed, but the current handling of kernel rebuilds when multiversion kernels are enabled is buggy. Depending on which option above you're most comfortable with, that bug may be in Tumbleweed or some place else, I've asked that question before and got no answer (which is why no bugreport has yet been filed). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg KH writes:

On Sun, Mar 09, 2014 at 11:11:04AM +0100, Achim Gratz wrote:

...

Greg KH writes:

...

That's because all of the Tumbleweed repo just rebuild due to KDE updates, as well as other core updates (kmod and util-linux).

The kernel should either a) never rebuild

It rebuilds when a new kernel update happens, or a dependency of the kernel packages are updated. What is wrong with that?

Nothing, if one of the other points is getting fixed. On the other hand I can't see anything changing that would invalidate the existing kernel build.

...

or b) the version number needs to change with each rebuild

It does.

Specifically, the build number is incremented, not the version (which really hasn't changed, so there's probably nothing to do here).

...

or c) all tools making use of the version number need to recognize that a rebuild of the kernel actually overwrites any earlier builds of the same version kernel so the old build is no longer available or

I don't understand what you mean by this.

If you install all those rebuilds on a kernel multiversion enabled system and query for installed packages, you will see that the package system thinks that all combinations of <version>.<buildnumber> are still installed (look at the zypper output earlier to this thread). But only the latest build of each version that you installed is actually present on the system – the files for each build do not actually coexist, since they are overwritten when the new build gets installed. This confuses the hell out of the script that tries to delete old kernels for instance and makes it delete kernel versions that you are actively trying to keep. You can actually zypper rm the old builds without causing damage (but that is a scary thing to do since you can't really tell that it's not removing the current kernel).

...

d) the kernel installation needs to include the build number so that multiple builds of the same versions can coexist on disk.

It should do that today.

No it doesn't, otherwise there'd be a ".2" right after the "-18" in the following path on my system: /lib/modules/3.13.5-18.gbb654e2-pae As I understand, each package that enables multiversion coexistence must either use an installation path that does include the build number, must never rebuild or must be cleaning up after itself when the install of a rebuilt package overwrites an earlier one. Including the build number is not appropriate for kernels as you almost assuredly want to keep a number of previous versions and not builds of the same version.

I don't understand the problem here, everything works fine on my machines...

Do you use a multiversion enabled kernel or not? If not, it is easy to see why you never encounter the problem since it never presents itself. If yes, then I don't understand why that problem isn't obvious to you. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/09/2014 01:26 PM, Greg KH pecked at the keyboard and wrote:

On Sun, Mar 09, 2014 at 11:11:04AM +0100, Achim Gratz wrote:

...

Greg KH writes:

...

That's because all of the Tumbleweed repo just rebuild due to KDE updates, as well as other core updates (kmod and util-linux).

The kernel should either a) never rebuild

It rebuilds when a new kernel update happens, or a dependency of the kernel packages are updated. What is wrong with that?

...

or b) the version number needs to change with each rebuild

It does.

...

or c) all tools making use of the version number need to recognize that a rebuild of the kernel actually overwrites any earlier builds of the same version kernel so the old build is no longer available or

I don't understand what you mean by this.

...

d) the kernel installation needs to include the build number so that multiple builds of the same versions can coexist on disk.

It should do that today.

...

...

So this is to be expected, and just part of the deal with Tumbleweed.

I'm not going into that discussion again as it should really be about osc and not Tumbleweed, but the current handling of kernel rebuilds when multiversion kernels are enabled is buggy. Depending on which option above you're most comfortable with, that bug may be in Tumbleweed or some place else, I've asked that question before and got no answer (which is why no bugreport has yet been filed).

I don't understand the problem here, everything works fine on my machines...

greg k-h

The problem is the unnecessary build that takes place which then requires unnecessary download and install. If there is no change in package it does not require a rebuild. Just because one KDE package changes does not mean 100% of the KDE packages need rebuild. And, why the hell does a KDE update require a rebuild of the kernel? Are the kernel devs now employing code from the KDE devs? That's all we're saying. :-) ****************** By the way I subscribe to the factory list so I do not appreciate private replies in addition to the list mail! -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/10/2014 05:44 AM, Stephan Kulow pecked at the keyboard and wrote:

On 09.03.2014 20:56, Ken Schneider - openSUSE wrote:

...

The problem is the unnecessary build that takes place which then requires unnecessary download and install. If there is no change in package it does not require a rebuild. Just because one KDE package changes does not mean 100% of the KDE packages need rebuild. And, why the hell does a KDE update require a rebuild of the kernel? Are the kernel devs now employing code from the KDE devs?

That's all we're saying. :-)

But that's how OBS repos work - if you don't want daily updates, then don't call zypper dup daily.

OK. Does packman use the OBS? If so how do they keep from triggering a rebuild of every package in their repos which would require a reinstall of all of their installed packages?

...

****************** By the way I subscribe to the factory list so I do not appreciate private replies in addition to the list mail!

Google for gratitude.

Oh I am quite grateful for all of work done. It has nothing to do with keeping replies to the list. http://en.opensuse.org/openSUSE:Mailing_list_netiquette#Personal_and_mail_li... -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/10/2014 11:22 AM, Dmitriy Perlow pecked at the keyboard and wrote:

Ken Schneider - openSUSE Mon, 10 Mar 2014 17:49:51 +0300:

...

On 03/10/2014 05:44 AM, Stephan Kulow pecked at the keyboard and wrote:

...

On 09.03.2014 20:56, Ken Schneider - openSUSE wrote:

...

The problem is the unnecessary build that takes place which then requires unnecessary download and install. If there is no change in package it does not require a rebuild. Just because one KDE package changes does not mean 100% of the KDE packages need rebuild. And, why the hell does a KDE update require a rebuild of the kernel? Are the kernel devs now employing code from the KDE devs?

That's all we're saying. :-)

But that's how OBS repos work - if you don't want daily updates, then don't call zypper dup daily.

OK. Does packman use the OBS? If so how do they keep from triggering a rebuild of every package in their repos which would require a reinstall of all of their installed packages?

Yes it uses OBS and they don't keep from triggering in any way.

OK, clears up the mystery for me and perhaps many more. Sorry for the noise. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org