On Thu, Feb 06, 2014 at 07:39:26PM +0100, Achim Gratz wrote:

Greg KH writes:

...

If anyone has any problems, please let us know here on the Factory list.

After the installation, these eight patches must be locked to avoid an immediate re-installation of KDE 4.11.5:

openSUSE-2013-829 openSUSE-2013-873 openSUSE-2013-905 openSUSE-2013-928 openSUSE-2013-935 openSUSE-2013-979 openSUSE-2014-79 openSUSE-2014-102

What do you mean by this? How will anything be "reinstalled"? confused, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2014-02-06 16:59 GMT-02:00 Raymond Wooninck :

On Thursday 06 February 2014 10:55:25 Greg KH wrote:

...

On Thu, Feb 06, 2014 at 07:39:26PM +0100, Achim Gratz wrote:

...

After the installation, these eight patches must be locked to avoid an immediate re-installation of KDE 4.11.5:

openSUSE-2013-829 openSUSE-2013-873 openSUSE-2013-905 openSUSE-2013-928 openSUSE-2013-935 openSUSE-2013-979 openSUSE-2014-79 openSUSE-2014-102

What do you mean by this? How will anything be "reinstalled"?

This seems that besides the Tumbleweed repository, Achim still has the update repository for openSUSE 13.1 active. This would be the only way that 4.11.5 can be forced to be installed again as that only the update repo contains KDE 4.11.5.

Achiim, I don't think that you can mix Tumbleweed and the 13.1:Update repository. As far as I know this is mutual exclusive as this could deliver quite some issues.

Regards

Raymond

Hi, Tumbleweed [0] must have update repos added: and should be updated using zypper dup only. [0] http://en.opensuse.org/Portal:Tumbleweed Regards Luiz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, 6 Feb 2014 19:59, Raymond Wooninck wrote:

On Thursday 06 February 2014 10:55:25 Greg KH wrote:

...

On Thu, Feb 06, 2014 at 07:39:26PM +0100, Achim Gratz wrote:

...

After the installation, these eight patches must be locked to avoid an immediate re-installation of KDE 4.11.5:

openSUSE-2013-829 openSUSE-2013-873 openSUSE-2013-905 openSUSE-2013-928 openSUSE-2013-935 openSUSE-2013-979 openSUSE-2014-79 openSUSE-2014-102

What do you mean by this? How will anything be "reinstalled"?

This seems that besides the Tumbleweed repository, Achim still has the update repository for openSUSE 13.1 active. This would be the only way that 4.11.5 can be forced to be installed again as that only the update repo contains KDE 4.11.5.

Achiim, I don't think that you can mix Tumbleweed and the 13.1:Update repository. As far as I know this is mutual exclusive as this could deliver quite some issues.

Solvable by giving Tumbleweed-repo a higher prio (lower number) than 13.1:Update-repo. That way any package in Tumbleweed-repo will be prefered over 13.1:Main(oss/non-oss)-repo and 13.1:Update-repo. Normal install gives main-distro-repo a 99 for prio, and update a 98, so e.g. "zypper mr -p 90 Tumbleweed-repo" helps to avoid such trouble. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Yamaban writes:

Solvable by giving Tumbleweed-repo a higher prio (lower number) than 13.1:Update-repo. That way any package in Tumbleweed-repo will be prefered over 13.1:Main(oss/non-oss)-repo and 13.1:Update-repo.

Not solvable this way. Tumbleweed already has higher priority on my system (and has been long before the 13.1 transition).

Normal install gives main-distro-repo a 99 for prio, and update a 98, so e.g. "zypper mr -p 90 Tumbleweed-repo" helps to avoid such trouble.

Slightly redacted repo configuration: # | Alias | Enabled | Refresh | Priority ---+---------------------------------+---------+---------+--------- 9 | Tumbleweed | Yes | Yes | 97 11 | openSUSE-current-Non-OSS | Yes | Yes | 99 12 | openSUSE-current-OSS | Yes | Yes | 99 13 | openSUSE-current-Update-Non-OSS | Yes | Yes | 99 14 | openSUSE-current-Update-OSS | Yes | Yes | 99 15 | openSUSE-current-Update-debug | Yes | Yes | 99 16 | openSUSE-current-debug | Yes | Yes | 99 The other repos are either disabled or not involved in the KDE package selection (tested by temporarily disabling them). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 06, 2014 at 08:02:30PM +0100, Achim Gratz wrote:

Greg KH writes:

...

What do you mean by this? How will anything be "reinstalled"?

One of these is the patch that updates KDE 4.11.5 on 13.1. After installation of KDE 4.12 it triggers again because it doesn't seem to check for any later version of KDE. The others are triggering again because they also check for the build version and the packages in Tumbleweed actually have a lower build number. So zypper / PackageKit figure that they should install these patches from openSUSE Updates, after which they'd decide to install KDE 4.12 again from Tumbleweed, ad nauseam – until you lock these out.

I can't duplicate this here, how are you updating? You have to use: zypper dup to use Tumbleweed, with no priority differences for any repo or anything else odd. How are you updating? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg KH writes:

I can't duplicate this here, how are you updating? You have to use: zypper dup to use Tumbleweed, with no priority differences for any repo or anything else odd.

How are you updating?

After another reboot and temporarily removing the locks again: zypper dup keeps the current installation, but zypper patch would do the rollback to KDE 4.11.5 if I let it. Locking the patches prevents this from happening and both dup and patch agree that they don't need to do anything. 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

Greg KH writes:

Don't mess with patches, just do 'zypper dup' and make all your repos the same level and all should be fine.

The actual setup is slightly more complex since I need some more software than what's offered by openSUSE and Tumbleweed, so I need to keep the priorities.

Tumbleweed is not "tricky", don't try to make it harder than it really is :)

I don't think this has anything to do with Tumbleweed, nor do the priority settings figure into the equation. The problem is that patches can switch packages to a lower version than what's installed and then also using a different (and lower priority) repo. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 06, 2014 at 09:12:21PM +0100, Achim Gratz wrote:

Greg KH writes:

...

Don't mess with patches, just do 'zypper dup' and make all your repos the same level and all should be fine.

The actual setup is slightly more complex since I need some more software than what's offered by openSUSE and Tumbleweed, so I need to keep the priorities.

I strongly recommend you don't do that, as it is unsupported. If you have to do this, keep the priority the same for Tumbleweed as the other openSUSE:13.1 repos, and you should be ok, as obviously you know what you are doing here :) Good luck, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Greg KH [02-06-14 14:56]:

On Thu, Feb 06, 2014 at 08:42:15PM +0100, Achim Gratz wrote:

...

Greg KH writes:

...

I can't duplicate this here, how are you updating? You have to use: zypper dup to use Tumbleweed, with no priority differences for any repo or anything else odd.

How are you updating?

After another reboot and temporarily removing the locks again: zypper dup keeps the current installation, but zypper patch would do the rollback to KDE 4.11.5 if I let it. Locking the patches prevents this from happening and both dup and patch agree that they don't need to do anything.

Don't mess with patches, just do 'zypper dup' and make all your repos the same level and all should be fine.

Tumbleweed is not "tricky", don't try to make it harder than it really is :)

No, it is not "tricky", but some of the manipulations make the use somewhat tricky. You just moved 4.12 into Tumbleweed standard as 4.12.2-2.1 or greater in a few instances, but the last last version in Tumbleweed Testing was 4.12.2-4.1 so "zypper dup" wants to downgrade 143 pkgs on my box to 4.12.2-1. So anyone who was using Tumbelweed_Testing should pay particular attention to the actions "zypper dup" propose until Tumbleweed_standard has caught up. I tend to revert to "zypper up" during these times. ps: the locks do me *no* good. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 6, 2014 at 3:12 PM, Patrick Shanahan wrote:

No, it is not "tricky", but some of the manipulations make the use somewhat tricky. You just moved 4.12 into Tumbleweed standard as 4.12.2-2.1 or greater in a few instances, but the last last version in Tumbleweed Testing was 4.12.2-4.1 so "zypper dup" wants to downgrade 143 pkgs on my box to 4.12.2-1.

I don't know the details, but the implied assumption that 4.12.2-4 from one repo is newer than 4.12.2-1 from another repo is wrong. Anything after the - is repo specific and comparisons can simply not be made. Specifically if something at revision 4.12.2-4 is pushed as a brand new package to a different repo, it will be considered a virgin package in the new repo and will be numbered 4.12.2-1 Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 06, 2014 at 03:12:39PM -0500, Patrick Shanahan wrote:

* Greg KH [02-06-14 14:56]:

...

On Thu, Feb 06, 2014 at 08:42:15PM +0100, Achim Gratz wrote:

...

Greg KH writes:

...

I can't duplicate this here, how are you updating? You have to use: zypper dup to use Tumbleweed, with no priority differences for any repo or anything else odd.

How are you updating?

After another reboot and temporarily removing the locks again: zypper dup keeps the current installation, but zypper patch would do the rollback to KDE 4.11.5 if I let it. Locking the patches prevents this from happening and both dup and patch agree that they don't need to do anything.

Don't mess with patches, just do 'zypper dup' and make all your repos the same level and all should be fine.

Tumbleweed is not "tricky", don't try to make it harder than it really is :)

No, it is not "tricky", but some of the manipulations make the use somewhat tricky. You just moved 4.12 into Tumbleweed standard as 4.12.2-2.1 or greater in a few instances, but the last last version in Tumbleweed Testing was 4.12.2-4.1 so "zypper dup" wants to downgrade 143 pkgs on my box to 4.12.2-1.

As Greg points out, that is correct, as these files are no longer in :Testing, so zypper did the correct thing.

So anyone who was using Tumbelweed_Testing should pay particular attention to the actions "zypper dup" propose until Tumbleweed_standard has caught up. I tend to revert to "zypper up" during these times.

Nope, that should be fine, I use both repos here, and when the file "graduates" it moves out of :Testing and so you end up doing a "downgrade" due to the build number, but that is correct.

ps: the locks do me *no* good.

Don't use locks, again, this isn't "hard", trust zypper, it knows what it is doing :) greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 06, 2014 at 03:12:39PM -0500, Patrick Shanahan wrote:

* Greg KH [02-06-14 14:56]:

...

On Thu, Feb 06, 2014 at 08:42:15PM +0100, Achim Gratz wrote:

...

Greg KH writes:

...

I can't duplicate this here, how are you updating? You have to use: zypper dup to use Tumbleweed, with no priority differences for any repo or anything else odd.

How are you updating?

After another reboot and temporarily removing the locks again: zypper dup keeps the current installation, but zypper patch would do the rollback to KDE 4.11.5 if I let it. Locking the patches prevents this from happening and both dup and patch agree that they don't need to do anything.

Don't mess with patches, just do 'zypper dup' and make all your repos the same level and all should be fine.

Tumbleweed is not "tricky", don't try to make it harder than it really is :)

No, it is not "tricky", but some of the manipulations make the use somewhat tricky. You just moved 4.12 into Tumbleweed standard as 4.12.2-2.1 or greater in a few instances, but the last last version in Tumbleweed Testing was 4.12.2-4.1 so "zypper dup" wants to downgrade 143 pkgs on my box to 4.12.2-1.

As Greg points out, that is correct, as these files are no longer in :Testing, so zypper did the correct thing.

So anyone who was using Tumbelweed_Testing should pay particular attention to the actions "zypper dup" propose until Tumbleweed_standard has caught up. I tend to revert to "zypper up" during these times.

Nope, that should be fine, I use both repos here, and when the file "graduates" it moves out of :Testing and so you end up doing a "downgrade" due to the build number, but that is correct.

ps: the locks do me *no* good.

Don't use locks, again, this isn't "hard", trust zypper, it knows what it is doing :) greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Feb 17, 2014 at 08:26:59PM +0100, Achim Gratz wrote:

Greg KH writes:

...

Don't mess with patches, just do 'zypper dup' and make all your repos the same level and all should be fine.

Here's the next patch that tries to roll back the system:

openSUSE-2014-134

BTW, I've upgraded the ol' spare computer from 12.3 to 13.1 Tumbleweed over the weekend (where I kept the recommended way of setting the repos all to the same priority). The upgrade itself went without a hitch, but there are packages in Tumbleweed that are shadowed by the same version, but higher buildnumber packages in either openSUSE-current or openSUSE-current-Updates.

That's fine, but I'm curious, what packages are they?

Just by setting Tumbleweed to the same priority as the other openSUSE repos I'm getting 71 packages to change from Tumbleweed to one of these repos (starting with NetworkManager and ending with a bunch of branding packages). So I guess I should keep the priorities or Tumbleweed should drop those packages or somehow bump the build numbers (like openSUSE-current-Updates does).

No, again, never mess with priorities, that way lies madness. Tumbleweed is really simple, don't mess with any priorities, and only update with: zypper dup and you should be fine. If you mix and match repos, again, you are on your own, and better know what you are doing, as you get to fix the resulting mess :) good luck, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Feb 19, 2014 at 08:11:43PM +0100, Achim Gratz wrote:

Greg KH writes:

...

That's fine, but I'm curious, what packages are they?

Mostly related to KDE, as said before. I don't get at the spare computer now, but here are a few examples that I remembered:

NetworkManager-kde4 | 0.9.0.10-2.1 | noarch | Tumbleweed NetworkManager-kde4 | 0.9.0.10-2.8.1 | noarch | openSUSE-current-Update-OSS yast2-qt-branding-openSUSE | 13.1-2.2 | noarch | Tumbleweed yast2-qt-branding-openSUSE | 13.1-10.4.13 | noarch | openSUSE-current OSS wallpaper-branding-openSUSE | 13.1-2.2 | noarch | Tumbleweed wallpaper-branding-openSUSE | 13.1-10.4.13 | noarch | openSUSE-current OSS kdm-branding-openSUSE | 13.1-2.1 | noarch | Tumbleweed kdm-branding-openSUSE | 13.1-10.4.13 | noarch | openSUSE-current OSS kwin | 4.11.6-2.5 | i586 | Tumbleweed kwin | 4.11.6-107.1 | i586 | openSUSE-current-Update-OSS

...

No, again, never mess with priorities, that way lies madness.

See above. You can install these packages from Tumbleweed manually, but without giving Tumbleweed higher priority, they will revert to the base repos on the next update. So again, you'd need to bump the build numbers the way the update repos do (only for KDE apparently) or else leave out these packages from Tumbleweed if they're supposed to be delivered from the base repos.

No, it's fine, as they came from the kde repos, and as you point out, will eventually catch up and start being used :)

Tumbleweed rebuilds a lot more often, so in some cases Tumbleweed will soon overtake the base repos and then "Zypper dup" would switch the provider. I've still not figured out why it does that many rebuilds, but now that KDE is in again that's about 700GB downloads every few days.

Lots of things cause it to rebuild, that's just the crazy dependancy chain we have. I err on the side of being cautious and rebuilding whenever the build system thinks it needs to.

This totally works for me, but the potential Tumbleweed user base would be broader if that wasn't happening.

Really, what do you base that statement on? Do you, or anyone else, even know what the current Tumbleweed user base is? Does it even matter? :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Feb 19, 2014 at 11:00:43PM +0100, Achim Gratz wrote:

Greg KH writes:

...

No, it's fine, as they came from the kde repos, and as you point out, will eventually catch up and start being used :)

Grrr… that feels dirty.

I agree. It's a well-known issue when mixing packages between repos and there is no known solution for it at this time. It's one of the reasons that Tumbleweed can't be a "real" solution for a rolling release, unless I want to import _all_ of openSUSE into the tumbleweed repo, which at this point in time, I don't want to do.

...

Lots of things cause it to rebuild, that's just the crazy dependancy chain we have. I err on the side of being cautious and rebuilding whenever the build system thinks it needs to.

So let me ask, what specifically would be a reason to rebuild KDE?

The dependancy change causes it to rebuild.

I cannot remember that it was ever rebuilt for base.

What do you mean by "base"? Once an openSUSE release happens, packages don't get rebuilt unless there is an api change/fix or some other very necessary reason. And then it's done "by hand" which is how Factory also works. I rely on the dependancy chain to rebuild Tumbleweed, which causes rebuilds way more often than is "necessary". I do this to keep things "consistant" as I don't have the time/energy to manage the dependancies by hand and deal with any potential problems where I miss a rebuild.

And if it does rebuild, then surely all that noarch stuff (wallpapers, icons, etc.) that makes up the bulk of it is not going to change anyway (I've looked at some logs and unfortunately there's metadata in the image files that contains the date and that seems to be enough to mark the whole package as "new", bummer).

Yeah, welcome to obs :)

...

...

This totally works for me, but the potential Tumbleweed user base would be broader if that wasn't happening.

Really, what do you base that statement on?

My own experience with an internet connection that was slow, unreliable and metered.

...

Do you, or anyone else, even know what the current Tumbleweed user base is? Does it even matter? :)

I don't really know. As long as you don't decide there aren't enough people to make it worth your while I probably shouldn't care?

I don't know a solution for the version numbering, or the rebuilds, that doesn't take a lot of obs feature-work, or manual labor in handling package dependancies at this point in time, sorry. It's just the way that Tumbleweed works, and has been for many years now, this isn't anything new... thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 20, 2014 at 08:48:28PM +0100, Achim Gratz wrote:

Greg KH writes:

...

...

So let me ask, what specifically would be a reason to rebuild KDE?

The dependancy change causes it to rebuild.

My question actually was "what dependency" (I can't figure it out, sorry). One of the recent KDE rebuilds seems to have been triggered by a kernel rebuild and I still don't see how KDE depends on the kernel.

No, the kernel didn't cause it, I think it was an update to util-linux, which, in the end, almost every package depends on. Same thing with other "core" packages that get updated, like systemd/udev. There's also fun things that happen when packages like e2fsprogs gets updated (Libreoffice ends up depending on that one, go figure...) Hopefully with the "unbundling" that is happening in the Factory rework, some of these dependancy chains will get broken. But openSUSE is not alone in this issue at all, all other distros have the same problems, some solve it in different ways than others... thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Christian Boltz writes:

If the image metadata contains the build date, I'd consider this a bug. Please open a bugreport [1] ;-) (The file's timestamp (as shipped in the tarball) is a good replacements for the build date.)

It's been some time since I looked at this. It may not have been a date but something else leaked from the build environment into the metadata, I don't remember exactly.

Fixing this will probably not avoid the rebuild itsself, but OBS will notice that the package is unchanged, and will throw away the just-build package instead of releasing it as a "new" version.

Yes. The comparison was done for the whole file, even though the actual image data was (and always will be) identical.

[1] against KDE - this is not a tumbleweed bug

Wouldn't this be an OBS bug? The build uses something like imagemagick (I'm fuzzy on those details, too) to convert from the source to several derivative formats. Then the OBS build process compares the full files, not just the image data, to find that yes, each time that conversion is done a different image was created. This is true at some level, but for all practical purposes these images should be treated as unchanged from any other build if only the metadata differs. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 20, 2014 at 07:38:29PM +0100, Christian Boltz wrote:

Hello,

Am Mittwoch, 19. Februar 2014 schrieb Achim Gratz:

...

Greg KH writes:

...

No, it's fine, as they came from the kde repos, and as you point out, will eventually catch up and start being used :)

Grrr… that feels dirty.

Indeed :-(

That said - I wonder why this happens at all. Tumbleweed builds against 13.1:Update, so in theory OBS should ensure that the version number is always higher (or does this only work with _link'ed packages?).

We do use linked packages in Tumbleweed, but rebuild numbers do not cross OBS projects. And, after thinking about it for a while, you will see that this is a good thing, otherwise it would be totally crazy to try to work things out. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 20, 2014 at 10:53:10PM +0100, Yamaban wrote:

On Thu, 20 Feb 2014 21:38, Greg KH wrote:

...

On Thu, Feb 20, 2014 at 07:38:29PM +0100, Christian Boltz wrote:

...

Am Mittwoch, 19. Februar 2014 schrieb Achim Gratz: <snip> That said - I wonder why this happens at all. Tumbleweed builds against 13.1:Update, so in theory OBS should ensure that the version number is always higher (or does this only work with _link'ed packages?).

We do use linked packages in Tumbleweed, but rebuild numbers do not cross OBS projects. And, after thinking about it for a while, you will see that this is a good thing, otherwise it would be totally crazy to try to work things out.

Preface: I'm no OBS guru.

That said: Is it possible to 'preset' the build numbers?

Not that I know of, sorry. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Feb 21, 2014 at 12:26:16AM +0100, Guido Berhoerster wrote:

* Greg KH [2014-02-21 00:21]:

...

On Thu, Feb 20, 2014 at 10:53:10PM +0100, Yamaban wrote:

...

On Thu, 20 Feb 2014 21:38, Greg KH wrote:

...

On Thu, Feb 20, 2014 at 07:38:29PM +0100, Christian Boltz wrote:

...

Am Mittwoch, 19. Februar 2014 schrieb Achim Gratz: <snip> That said - I wonder why this happens at all. Tumbleweed builds against 13.1:Update, so in theory OBS should ensure that the version number is always higher (or does this only work with _link'ed packages?).

We do use linked packages in Tumbleweed, but rebuild numbers do not cross OBS projects. And, after thinking about it for a while, you will see that this is a good thing, otherwise it would be totally crazy to try to work things out.

Preface: I'm no OBS guru.

That said: Is it possible to 'preset' the build numbers?

Not that I know of, sorry.

You can add a prefix to the release: http://en.opensuse.org/openSUSE:Build_Service_prjconf#Release

I'm not going to edit spec files, sorry, I rely on the build system to handle this by using 'osc setlinkrev'. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Feb 22, 2014 at 11:50:36PM +0100, Guido Berhoerster wrote:

* Greg KH [2014-02-22 23:41]:

...

On Fri, Feb 21, 2014 at 12:26:16AM +0100, Guido Berhoerster wrote:

...

* Greg KH [2014-02-21 00:21]:

...

On Thu, Feb 20, 2014 at 10:53:10PM +0100, Yamaban wrote:

...

On Thu, 20 Feb 2014 21:38, Greg KH wrote:

...

On Thu, Feb 20, 2014 at 07:38:29PM +0100, Christian Boltz wrote: >Am Mittwoch, 19. Februar 2014 schrieb Achim Gratz: <snip> >That said - I wonder why this happens at all. Tumbleweed builds against >13.1:Update, so in theory OBS should ensure that the version number is >always higher (or does this only work with _link'ed packages?).

We do use linked packages in Tumbleweed, but rebuild numbers do not cross OBS projects. And, after thinking about it for a while, you will see that this is a good thing, otherwise it would be totally crazy to try to work things out.

Preface: I'm no OBS guru.

That said: Is it possible to 'preset' the build numbers?

Not that I know of, sorry.

You can add a prefix to the release: http://en.opensuse.org/openSUSE:Build_Service_prjconf#Release

I'm not going to edit spec files, sorry, I rely on the build system to handle this by using 'osc setlinkrev'.

This is a setting in prjconf not spec files, it determines how the Release is inserted into the spec files by OBS.

And how would I do that for Tumbleweed? I don't want a "-tw" tag everywhere, do you? Or maybe that would be good to have, makes things more obvious as to where packages came from? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 21.02.2014 00:23, schrieb Greg KH:

On Thu, Feb 20, 2014 at 10:53:10PM +0100, Yamaban wrote:

...

On Thu, 20 Feb 2014 21:38, Greg KH wrote:

...

On Thu, Feb 20, 2014 at 07:38:29PM +0100, Christian Boltz wrote:

...

Am Mittwoch, 19. Februar 2014 schrieb Achim Gratz: <snip> That said - I wonder why this happens at all. Tumbleweed builds against 13.1:Update, so in theory OBS should ensure that the version number is always higher (or does this only work with _link'ed packages?).

We do use linked packages in Tumbleweed, but rebuild numbers do not cross OBS projects. And, after thinking about it for a while, you will see that this is a good thing, otherwise it would be totally crazy to try to work things out.

Preface: I'm no OBS guru.

That said: Is it possible to 'preset' the build numbers?

Not that I know of, sorry.

Hi Greg, The Release: field in the spec file is actually a minimum, but that is a bit too much work. If you link to a package, the release will be higher than the one in the link target - but only if you link plainly. Tumbleweed puts a rev in the _link file, which breaks this concept. To fix that you also need to include a vrev in your _link file. E.g. coolo@goneril#~>osc api /source/KDE:Release:412/amor?view=info <sourceinfo package="amor" rev="5" vrev="30" srcmd5="56369c0dd5120993abdea6278cef96e7" lsrcmd5="73552d985f98e9e614fafb438125f5b8" verifymd5="7aff2d609b5c805b1a7d29d1c59dc999"> <filename>amor.spec</filename> <linked project="KDE:Distro:Factory" package="amor" /> </sourceinfo> So amor in KDE prj has a release of 30 (vrev). So you put in your _link file rev="56369c0dd5120993abdea6278cef96e7" (you're already doing that) and vrev="31". Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Feb 21, 2014 at 08:22:05AM +0100, Stephan Kulow wrote:

Am 21.02.2014 08:17, schrieb Stephan Kulow:

...

So amor in KDE prj has a release of 30 (vrev). So you put in your _link file rev="56369c0dd5120993abdea6278cef96e7" (you're already doing that) and vrev="31".

BTW: in case you're using osc linkpac -c to create these _link files, https://github.com/openSUSE/osc/issues/72 is your bug :)

That's good to know, but I'm currently doing: osc setlinkrev -r how do I specify the vrev in an 'osc' command line? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Feb 23, 2014 at 07:22:49AM +0100, Stephan Kulow wrote:

Am 22.02.2014 23:43, schrieb Greg KH:

...

On Fri, Feb 21, 2014 at 08:22:05AM +0100, Stephan Kulow wrote:

...

Am 21.02.2014 08:17, schrieb Stephan Kulow:

...

So amor in KDE prj has a release of 30 (vrev). So you put in your _link file rev="56369c0dd5120993abdea6278cef96e7" (you're already doing that) and vrev="31".

BTW: in case you're using osc linkpac -c to create these _link files, https://github.com/openSUSE/osc/issues/72 is your bug :)

That's good to know, but I'm currently doing: osc setlinkrev -r how do I specify the vrev in an 'osc' command line?

It's a bug in osc that if it doesn't add it automatically. Actually there is code at least in osc 0.143 to do that - so the least you can do is making sure your osc is always uptodate :)

Ah, nice, I've now updated to the 0.143 release (which identifies as 0.142git, seems odd...) and this should now be resolved for future packages. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thanks for the heads up, got hit by this today, though I only had two of these on restart; 102 and 873. It also reminded me the times during 12.3, this same issue cropped up at some point. Is there a bug-report or request related to the patch sanity checks? imo it shouldn't show up if you have => version installed. I don't know if it's of any relevance but to put it out there anyway, there are some KDE components still at v4.11.*: kdeartwork4-sounds-4.11.2-4.5.noarch kdebase4-workspace-4.11.6-2.2.x86_64 kde4-kgreeter-plugins-4.11.6-2.2.x86_64 kdebase4-workspace-liboxygenstyle-4.11.6-2.2.x86_64 kdebase4-workspace-plasma-calendar-4.11.6-2.2.x86_64 kdebase4-workspace-ksysguardd-4.11.6-2.2.x86_64 kwin-4.11.6-2.2.x86_64 Kind regards, Jason On Fri, Feb 7, 2014 at 2:39 AM, Achim Gratz wrote:

Greg KH writes:

...

If anyone has any problems, please let us know here on the Factory list.

After the installation, these eight patches must be locked to avoid an immediate re-installation of KDE 4.11.5:

openSUSE-2013-829 openSUSE-2013-873 openSUSE-2013-905 openSUSE-2013-928 openSUSE-2013-935 openSUSE-2013-979 openSUSE-2014-79 openSUSE-2014-102

Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

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

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

Dear Mr Raymond, Thank you for your feedback! How about kwin, do you have any info about this? Patch related, is the current behavior something to be adjusted/create bug submission for? Kind regards, Jason On Thu, Feb 13, 2014 at 8:56 PM, Raymond Wooninck wrote:

On Thursday 13 February 2014 20:43:22 Baron Kelvin wrote:

...

I don't know if it's of any relevance but to put it out there anyway, there are some KDE components still at v4.11.*:

Hi, This is absolutely correct. kdebase4-workspace has been frozen upstream on 4.11 while working on KDE Frameworks 5.

...

kdeartwork4-sounds-4.11.2-4.5.noarch

This package no longer exists. It was removed shortly after release of 4.11.2 due to legal reasons.

...

kdebase4-workspace-4.11.6-2.2.x86_64 kde4-kgreeter-plugins-4.11.6-2.2.x86_64 kdebase4-workspace-liboxygenstyle-4.11.6-2.2.x86_64 kdebase4-workspace-plasma-calendar-4.11.6-2.2.x86_64 kdebase4-workspace-ksysguardd-4.11.6-2.2.x86_64 kwin-4.11.6-2.2.x86_64 As indicated kdebase4-workspace has been frozen upstream and will have only minor releases based on its 4.11 branch. So with 4.12.3, you could expect 4.11.7 for kdebase4-workspace (if there are enough commits to justify a new version).

So everything is as expected on your system.

Regards

Raymond

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

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

Baron Kelvin writes:

Thanks for the heads up, got hit by this today, though I only had two of these on restart; 102 and 873.

This likely depends on the package selection you have.

It also reminded me the times during 12.3, this same issue cropped up at some point.

Yes, I think I've had around 20 patch packages locked before the rollover to 13.1. As Greg will surely be pointing out again, if you never use the updater applet from KDE or issue a "patch" in zypper you shouldn't need any patch locks, YMMV.

Is there a bug-report or request related to the patch sanity checks? imo it shouldn't show up if you have => version installed.

Well, I've asked around at least twice on this list and nobody else thought that was a bug and I'm not really sure what zypper is supposed to do with patches that target things in different repos. So no, I haven't filed a bug.

kdebase4-workspace-4.11.6-2.2.x86_64 kde4-kgreeter-plugins-4.11.6-2.2.x86_64 kdebase4-workspace-liboxygenstyle-4.11.6-2.2.x86_64 kdebase4-workspace-plasma-calendar-4.11.6-2.2.x86_64 kdebase4-workspace-ksysguardd-4.11.6-2.2.x86_64 kwin-4.11.6-2.2.x86_64

This is normal, something done upstream, IIRC. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org