On Fri, Apr 1, 2011 at 4:49 PM, Greg KH wrote:

On Fri, Apr 01, 2011 at 12:22:16PM -0400, Greg Freemyer wrote:

...

All,

Is there a simple way security updates can be tested to install cleanly on a Tumbleweed system?

Can we make that part of the process somehow?

No, that's not up to the security or maintance people, that's up to the tumbleweed developers.

...

== details

I just tried to do a YOU, but I get a conflict that a typical user should not have to face just because they're using Tumbleweed:

What's a "YOU"?

Yast Online Update It's the normal security update process that all users should use. ie. Hopefully everybody is pulling / installing security updates. I typically pull security updates by typing "you" at the command-line when I get the urge.

...

=== #### YaST2 conflicts list - generated 2011-04-01 11:29:43 ####

patch:python-virtualbox-4219.noarch conflicts with virtualbox-qt.x86_64 < 4.0.4-1.6.1 provided by virtualbox-qt-4.0.4-1.2.x86_64

What is causing this conflict?  What is "python-virtualbox"?  Does it not come from the main virtualbox repo?  If not, it looks like just adding it to tumbleweed would resolve the issue, right?

I'm getting python-virtualbox from the main 11.4 update repo. http://download.opensuse.org/update/11.4/ Nothing special at all. I didn't pay much attention, but I think the security announcement said there was a bug in python-virtualbox as released in 11.4 OSS, so they put out an update.

...

    [ ] Following actions will be done: install virtualbox-qt-4.0.4-1.6.1.x86_64 (with vendor change)   obs://build.opensuse.org/openSUSE:Tumbleweed  -->  openSUSE install virtualbox-4.0.4-1.6.1.x86_64 (with vendor change)   obs://build.opensuse.org/openSUSE:Tumbleweed  -->  openSUSE     [ ] do not install patch:python-virtualbox-4219.noarch

#### YaST2 conflicts list END ### ==========

If I revert virtualbox-qt to the OSS version, it will break due to a kernel incompatibility I'm pretty sure.

Because I know that, I can choose not to install the patch:python-virtualbox-4219.noarch.

For me it's not that big an issue, but it is not knowledge a typical user has.

Why not?  What's the "typical" tumbleweed user?  :)

I don't think the typical opensuse user knows virtualbox has to be compiled for a specific kernel. And I assume the goal is for the "typical tumbleweed user" to be similar to the typical opensuse user. Also, normally when there is a package conflict and one of the choices will break a package (or more), then the choices the user gets to select from explicitly say that. In this case, the choices don't make that clear.

thanks,

greg k-h

Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, Apr 1, 2011 at 6:11 PM, Marcus Meissner wrote:

On Fri, Apr 01, 2011 at 05:47:38PM -0400, Greg Freemyer wrote:

...

On Fri, Apr 1, 2011 at 4:49 PM, Greg KH wrote:

...

On Fri, Apr 01, 2011 at 12:22:16PM -0400, Greg Freemyer wrote:

...

All,

Is there a simple way security updates can be tested to install cleanly on a Tumbleweed system?

Can we make that part of the process somehow?

No, that's not up to the security or maintance people, that's up to the tumbleweed developers.

...

== details

I just tried to do a YOU, but I get a conflict that a typical user should not have to face just because they're using Tumbleweed:

What's a "YOU"?

Yast Online Update

It's the normal security update process that all users should use.

ie. Hopefully everybody is pulling / installing security updates.

I typically pull security updates by typing "you" at the command-line when I get the urge.

It was a bugfix update though.

...

I don't think the typical opensuse user knows virtualbox has to be compiled for a specific kernel.

And I assume the goal is for the "typical tumbleweed user" to be similar to the typical opensuse user.

Also, normally when there is a package conflict and one of the choices will break a package (or more), then the choices the user gets to select from explicitly say that.  In this case, the choices don't make that clear.

I still think that you need to have a certain level of knowledge to try Tumbleweed though, and this includes resolving of such minor conflicts.

Ciao, Marcus

Should "Who should use Tumleweed" at http://en.opensuse.org/Portal:Tumbleweed be updated to say that "Tumbleweed users will experience more package conflicts than users of the normal openSUSE releases and therefor Tumbleweed users should feel comfortable resolving minor conflicts." ? That would address my concern from a end-user perspective. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Greg KH wrote:

On Fri, Apr 01, 2011 at 06:26:16PM -0400, Greg Freemyer wrote:

...

On Fri, Apr 1, 2011 at 6:11 PM, Marcus Meissner wrote:

...

On Fri, Apr 01, 2011 at 05:47:38PM -0400, Greg Freemyer wrote:

...

On Fri, Apr 1, 2011 at 4:49 PM, Greg KH wrote:

...

On Fri, Apr 01, 2011 at 12:22:16PM -0400, Greg Freemyer wrote:

...

All,

Is there a simple way security updates can be tested to install cleanly on a Tumbleweed system?

Can we make that part of the process somehow?

No, that's not up to the security or maintance people, that's up to the tumbleweed developers.

...

== details

I just tried to do a YOU, but I get a conflict that a typical user should not have to face just because they're using Tumbleweed:

What's a "YOU"?

Yast Online Update

It's the normal security update process that all users should use.

ie. Hopefully everybody is pulling / installing security updates.

I typically pull security updates by typing "you" at the command-line when I get the urge.

It was a bugfix update though.

...

I don't think the typical opensuse user knows virtualbox has to be compiled for a specific kernel.

And I assume the goal is for the "typical tumbleweed user" to be similar to the typical opensuse user.

Also, normally when there is a package conflict and one of the choices will break a package (or more), then the choices the user gets to select from explicitly say that.  In this case, the choices don't make that clear.

I still think that you need to have a certain level of knowledge to try Tumbleweed though, and this includes resolving of such minor conflicts.

Ciao, Marcus

Should "Who should use Tumleweed" at

http://en.opensuse.org/Portal:Tumbleweed

be updated to say that

"Tumbleweed users will experience more package conflicts than users of the normal openSUSE releases and therefor Tumbleweed users should feel comfortable resolving minor conflicts."

"more"? Since when do users of "normal" openSUSE releases have _any_ such conflicts?

Since you're asking for _any_ such conflicts, here is one that appeared with 11.4: https://bugzilla.novell.com/show_bug.cgi?id=669498#c6 -- Per Jessen, Zürich (20.1°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2011/4/1 Greg KH :

On Fri, Apr 01, 2011 at 12:22:16PM -0400, Greg Freemyer wrote:

...

All,

Is there a simple way security updates can be tested to install cleanly on a Tumbleweed system?

Can we make that part of the process somehow?

No, that's not up to the security or maintance people, that's up to the tumbleweed developers.

...

== details

I just tried to do a YOU, but I get a conflict that a typical user should not have to face just because they're using Tumbleweed:

What's a "YOU"?

...

=== #### YaST2 conflicts list - generated 2011-04-01 11:29:43 ####

patch:python-virtualbox-4219.noarch conflicts with virtualbox-qt.x86_64 < 4.0.4-1.6.1 provided by virtualbox-qt-4.0.4-1.2.x86_64

What is causing this conflict?  What is "python-virtualbox"?  Does it not come from the main virtualbox repo?  If not, it looks like just adding it to tumbleweed would resolve the issue, right?

openSUSE comes with python-virtualbox 4.0.4-1.2.3, and an update was released: python-virtualbox 4.0.4-1.6.1 No problem with these *packages*, but then there are the *patches*. Patches are something only ZYpp devs fully understand that are useful, if I understood it correctly, because provides a way to give more and better information to the user (multiple packages as a single security update, whether a reboot is needed, category, etc.). To make users update the python-virtualbox *package* to 4.0.4-1.6.1, the python-virtualbox 4219 *patch* is provided. These *patches* conflict with the old versions of the *packages*, so forcing the update. A "zypper info -t patch python-virtualbox" will show you: Conflicts: python-virtualbox.i586 < 4.0.4-1.6.1 python-virtualbox.x86_64 < 4.0.4-1.6.1 .... So it conflicts with the version from the openSUSE repo but doesn't conflict with the version from the updates repo. This works because who created the patch knew the version-release numbers of the packages in the main openSUSE repo and in the updates repo... but can break with any other repository. Has happened already with Packman a few times in the past. Tumbleweed provides python-virtualbox 4.0.4-1.2. That match the "python-virtualbox.<arch> < 4.0.4-1.6.1" conflict from the python-virtualbox 4219 *patch*. When you have the version from Tumbleweed installed and try to install the patch, ZYpp finds that: - It can't install python-virtualbox 4.0.4-1.6.1 from the updates repo since it would mean a vendor change - It can't install the patch since it conflicts with the version from the Tumbleweed repo The problem is those conflicts from patches are way too fragile. They are conflicting with the Tumbleweed version just by chance, since the release numbers have no real meaning inter-repo. Once Tumbleweed updates virtualbox to 4.0.5 the conflict will disappear (Tumbleweed could just artificially increase the release number now, but...) Anyway, the problem only happens if the users uses patches. Something that can be easily avoided: - zypper will only use patches with the "zypper up -t patch" command - if the updater applet is configured to not update packages it does the equivalent of a "zypper up -t patch"... not really sure if it does a "zypper up" or something more complex if it's configured to update packages (this is new from 11.4) - YOU uses patches (equivalent of "zypper up -t patch"), but somebody really uses YOU? To make it clear. You can avoid using patches and still get the updates from the updates repository, patches only give the extra pretty information. And for people that uses zypper to update its systems it's a lot more normal to run "zypper up" (equivalent of zypper up -t packages) than zypper up -t patch. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2 April 2011 12:48, Marcus Meissner wrote:

On Sat, Apr 02, 2011 at 01:18:55AM +0200, Cristian Morales Vega wrote:

...

openSUSE comes with python-virtualbox 4.0.4-1.2.3, and an update was released:  python-virtualbox 4.0.4-1.6.1 No problem with these *packages*, but then there are the *patches*. Patches are something only ZYpp devs fully understand that are useful, if I understood it correctly, because provides a way to give more and better information to the user (multiple packages as a single security update, whether a reboot is needed, category, etc.).

The idea if patches is quite simple. :)

A patch has multiple relations of        packageN >= versionN

If you have packageN installed, the update stack will ensure that it at least versionN as listed in the patch to guarantee that bug X or security issue Y is fixed.

The patch also contains some metadata (text, links) to bring knowledge of above bugs/security issues.

The issue here is that there are 2 different package release number spaces, one is 11.4 + updates and 11.4 + tumbleweed, both might be difficult to keep in sync. We could bring this up to Adrian or other OBS developers to see if they can do something.

Currently, a new package in tumbleweed is not automatically picked up; at least I could not find out how to do so. It would be desirable not to have to use 'dup' option after the initial conversion. It would also be nice to have delta rpm packages in Tumbleweed repository. Thanks Anil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, on Samstag, 2. April 2011, Greg KH wrote:

On Sat, Apr 02, 2011 at 01:03:24PM +0530, Anil Seth wrote:

...

Currently, a new package in tumbleweed is not automatically picked up;

What do you mean by this?

I guess Anil meant zypper up doesn't offer new tumbleweed packages, which is IMHO confirmed with mentioning zypper dup in the next sentence.

...

at least I could not find out how to do so. It would be desirable not to have to use 'dup' option after the initial conversion.

You don't, unless new packages are added. That's just the way zypper works.

zypper up doesn't do automatic vendor changes. However, my understanding of tumbleweed is that new packages are constantly added. Doesn't fit too good, right? ;-) zypper dup ignores the vendor change and therefore also picks new packages in tumbleweed - but unfortunately you might also get some "accidential" vendor changes if you are using additional repos. The good news is that there's a way to allow specific vendor changes with zypper up (zypper handles them as being the same vendor). Credits go to the Evergreen team, they recommend this way on http://en.opensuse.org/Evergreen#How_to_activate In short, create a file /etc/zypp/vendors.d/evergreen with the following two lines: [main] vendors = openSUSE Evergreen,suse,opensuse If you replace "openSUSE Evergreen" with tumbleweed (use the exact Vendor: tag!), zypper should pick up new tumbleweed packages when running zypper up. Regards, Christian Boltz -- wer Windows in irgendeiner Form verwendet (ausser als abschreckendes Beispiel) ist selbst schuld. [Carsten Becher in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On 3 April 2011 00:16, Greg KH wrote:

On Sat, Apr 02, 2011 at 01:03:24PM +0530, Anil Seth wrote:

...

It would also be nice to have delta rpm packages in Tumbleweed repository.

That would be messy, it's really not worth it, sorry.

Well, worthiness depends on the bandwidth availability. I found the archdelta experiment very useful - https://bbs.archlinux.org/viewtopic.php?id=92085 . Unfortunately, it did not make it to the main Arch Linux repositories either. I was hoping that at least delta rpm with the immediately preceding version would be available. I can understand and appreciate the complications. Regards Anil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, Apr 02, 2011 at 01:18:55AM +0200, Cristian Morales Vega wrote:

To make it clear. You can avoid using patches and still get the updates from the updates repository, patches only give the extra pretty information.

Uh, that's not really true. Patches not only give you some pretty information, but they also force updates. 'zypper up' will not bother the user with problems, it'll just not do the update. 'zypper patch' will force the installation of all patches, thus the user has to resolve all problems.

And for people that uses zypper to update its systems it's a lot more normal to run "zypper up" (equivalent of zypper up -t packages) than zypper up -t patch.

Maybe more normal, but your system is not secure. Regarding the initial problem, Tumbleweed and 11.4 seem to be unrelated in the build service right now, thus there's no release number synchronization. If Tumbleweed is designed to be "on top" of some other project, it should use source links for the packages. That way, the build service knows that the package from Tumbleweed should get a higher release number that the one in 11.4. *BUT*: This only makes sense if all security updates are ported to Tumbleweed right away! Otherwise you'll just get an insecure system. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Apr 04, 2011 at 11:01:59AM +0200, Michael Schroeder wrote:

On Sat, Apr 02, 2011 at 01:18:55AM +0200, Cristian Morales Vega wrote:

...

To make it clear. You can avoid using patches and still get the updates from the updates repository, patches only give the extra pretty information.

Uh, that's not really true. Patches not only give you some pretty information, but they also force updates. 'zypper up' will not bother the user with problems, it'll just not do the update. 'zypper patch' will force the installation of all patches, thus the user has to resolve all problems.

...

And for people that uses zypper to update its systems it's a lot more normal to run "zypper up" (equivalent of zypper up -t packages) than zypper up -t patch.

Maybe more normal, but your system is not secure.

Regarding the initial problem, Tumbleweed and 11.4 seem to be unrelated in the build service right now, thus there's no release number synchronization.

They are not "unrelated" at all, Tumbleweed is built on top of 11.4.

If Tumbleweed is designed to be "on top" of some other project, it should use source links for the packages.

It does. But it only includes "newer" versions of packages than 11.4 so far, so the version number will always be bigger.

That way, the build service knows that the package from Tumbleweed should get a higher release number that the one in 11.4.

*BUT*: This only makes sense if all security updates are ported to Tumbleweed right away! Otherwise you'll just get an insecure system.

That's why I didn't duplicate all of 11.4 to go into Tumbleweed to have it be a stand-alone release. But, for some library work, we will need to rebuild packages that are identical to the 11.4 version, and I will use links, but how do you create a "source link" that will keep the version number greater, than the 11.4 one? Help with this would be appreciated. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Apr 05, 2011 at 10:56:51AM +0200, Michael Schroeder wrote:

On Mon, Apr 04, 2011 at 07:26:21PM -0700, Greg KH wrote:

...

But, for some library work, we will need to rebuild packages that are identical to the 11.4 version, and I will use links, but how do you create a "source link" that will keep the version number greater, than the 11.4 one?

You mean the release number? If it's a source link, the built packages will always have a bigger release number.

Yes, the release number will always be the same, that's easy, it's the "build number" that is the issue. When linking a new package into tumbleweed, the build number starts over and I know of no way to have it start at a higher number other than to manually rebuild it multiple times :( thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Apr 05, 2011 at 05:02:02PM +0200, Michael Schroeder wrote:

On Tue, Apr 05, 2011 at 06:52:59AM -0700, Greg KH wrote:

...

On Tue, Apr 05, 2011 at 10:56:51AM +0200, Michael Schroeder wrote:

...

On Mon, Apr 04, 2011 at 07:26:21PM -0700, Greg KH wrote:

...

But, for some library work, we will need to rebuild packages that are identical to the 11.4 version, and I will use links, but how do you create a "source link" that will keep the version number greater, than the 11.4 one?

You mean the release number? If it's a source link, the built packages will always have a bigger release number.

Yes, the release number will always be the same, that's easy, it's the "build number" that is the issue. When linking a new package into tumbleweed, the build number starts over and I know of no way to have it start at a higher number other than to manually rebuild it multiple times :(

Hmm, the "checkin counter" of the resulting rpm (i.e. the first part of the release number) should be bigger than the 11.4 one. Do you have an example where this isn't the case?

I think one issue is that Greg not just links to openSUSE:Factory, but also to other devel projects. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 04/05/2011 05:16 PM, Greg KH wrote:

On Tue, Apr 05, 2011 at 05:04:32PM +0200, Marcus Meissner wrote:

...

On Tue, Apr 05, 2011 at 05:02:02PM +0200, Michael Schroeder wrote:

...

On Tue, Apr 05, 2011 at 06:52:59AM -0700, Greg KH wrote:

...

On Tue, Apr 05, 2011 at 10:56:51AM +0200, Michael Schroeder wrote:

...

On Mon, Apr 04, 2011 at 07:26:21PM -0700, Greg KH wrote:

...

But, for some library work, we will need to rebuild packages that are identical to the 11.4 version, and I will use links, but how do you create a "source link" that will keep the version number greater, than the 11.4 one?

You mean the release number? If it's a source link, the built packages will always have a bigger release number.

Yes, the release number will always be the same, that's easy, it's the "build number" that is the issue. When linking a new package into tumbleweed, the build number starts over and I know of no way to have it start at a higher number other than to manually rebuild it multiple times :(

Hmm, the "checkin counter" of the resulting rpm (i.e. the first part of the release number) should be bigger than the 11.4 one. Do you have an example where this isn't the case?

I think one issue is that Greg not just links to openSUSE:Factory, but also to other devel projects.

No, that's not the issue, when I do that, the main release number will always be bigger than what is in openSUSE:11.4 (otherwise why would it be an update?)

The issue is when I link to packages in openSUSE:11.4. When doing that, the build number is reset to start over and doesn't have any relation to the build number of the package in openSUSE:11.4.

I'm confused a bit by the terminology here. I'm not sure what do you call a build number? In this example: kernel-source-2.6.38-18.5.src.rpm is build number == 5? If that's the case, doesn't the _link where this is an issue contain a cicount attribute? OBS should default to "add" behaviour so it should add 1 to the original "build number". If you have cicount=local or copy it will start over from 0 or be the same as linked package respectively. regards, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, 2 Apr 2011 11:45:26 -0700 Greg KH wrote:

I really don't recommend anyone running it on their systems the kernel stuff is just too looney. Especially as things like KVM work so much better in the end.

Unfortunately not an option if you only have a windows host :-) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, 2 Apr 2011 13:40:24 -0700 Greg KH wrote:

On Sat, Apr 02, 2011 at 10:22:00PM +0200, Stefan Seyfried wrote:

...

On Sat, 2 Apr 2011 11:45:26 -0700 Greg KH wrote:

...

I really don't recommend anyone running it on their systems the kernel stuff is just too looney. Especially as things like KVM work so much better in the end.

Unfortunately not an option if you only have a windows host :-)

Then use hyper-v if you are stuck with Windows.

Only an option if you run a Windows server variant. Not an option for many people.

Or vmware,

The *user* experience is much worse: at least an 11.4 guest can not mount shared folders (the kernel module complaining about missing symbols), the window can not be resized to arbitrary sizes and having to answer personal questions to be able to download the closed source software is something I'd rather avoid. So even if you detest the open source solution VirtualBox, the user experience with it is usually pretty smooth.

get involved in making sure that Linux works as a guest properly, unlike the virtualbox people :(

Well, they probably got the false impression that simply putting the code under GPL will make someone fix it for them ;-) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, Apr 14, 2011 at 09:15:09AM +0200, Michal Šebeň wrote:

ah, virtualbox was dropped from Tumbleweed :-/

so, If you are using Tumbleweed and you want to also use virtualbox, I suggest you to add this repo : "zypper ar http://download.opensuse.org/repositories/Virtualization:/VirtualBox_Tumblew..." it contains virtualbox sources (link) from openSUSE:Factory, build against Tubleweed repo (this is crucial for vbox kernel modules)

Thanks for creating this. Best of luck handling the kernel changes needed to keep this alive :( greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org