On Mon, 23 Jan 2012 20:18:49 -0600, Archie Cobbs wrote:

 I understand 11.3 is EOL'd, but it seems like Tools repo should be  special,  as it contains zypper -- the tool that lets you upgrade.

Arguably, the version of zypper that you've got on your 11.3 box (assuming you've kept it up to date) will be the last version that's available on 11.3, so whether the repo is around or not doesn't seem particularly important, because the repo wouldn't be updated anyways. But you might check on some of the archive repo sites (like gwdg.de) and see if it's there. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

 OK forget zypper and openSUSE:Tools for the moment...  What I'm simply trying to say is: just because 11.3 is itself EOL, that  doesn't mean OBS projects should start dropping the 11.3 repo right away.  Do others not agree?  -Archie On Tue, Jan 24, 2012 at 3:27 AM, Adrian Schröter wrote:

Am Montag, 23. Januar 2012, 20:18:49 schrieb Archie Cobbs:

...

 I noticed that openSUSE:Tools has dropped its 11.3 repo already.

 I understand 11.3 is EOL'd, but it seems like Tools repo should be special, as it contains zypper -- the tool that lets you upgrade.

No, it was never part of that repo.

...

 I understand that EOL means no longer "community supported" - that's fine.. but it seems to me that "community supported" is a completely different concept than "exists as a repo in a project".

 After all, openSUSE:Tools has RHEL 4 and all these other non-SUSE repos...  are those distributions "community supported" by the openSUSE project??

 So I don't understand the rush to remove the repo.

 Needless to say, I still have stable 11.3 systems around that I'm not ready to upgrade just yet...

 Thanks,  -Archie -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

-- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Tue, Jan 24, 2012 at 11:22 AM, Bryen M Yunashko wrote:

...

 What I'm simply trying to say is: just because 11.3 is itself EOL, that  doesn't mean OBS projects should start dropping the 11.3 repo right away.

 Do others not agree?

 -Archie

I'm going to assume that the EOL'ed repos get dropped due to storage conservation reasons.  (only an assumption.)  If that is the case, what do you propose is the length of time such repos should exist?

Not only that, it's sometime not easy to keep the packages building on old distros. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Dienstag, 24. Januar 2012, 08:13:16 schrieb Archie Cobbs:

OK forget zypper and openSUSE:Tools for the moment...

What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.

The maintainers can build against DISCONTINUED:openSUSE:11.3 instead. If they don't we free the resources (storage for mirrors, on our servers and build power). So they can be used for more constructive work than just old build jobs no maintainer cares about anymore. bye adrian

Do others not agree?

-Archie

On Tue, Jan 24, 2012 at 3:27 AM, Adrian Schröter wrote:

...

Am Montag, 23. Januar 2012, 20:18:49 schrieb Archie Cobbs:

...

I noticed that openSUSE:Tools has dropped its 11.3 repo already.

I understand 11.3 is EOL'd, but it seems like Tools repo should be special, as it contains zypper -- the tool that lets you upgrade.

No, it was never part of that repo.

...

I understand that EOL means no longer "community supported" - that's fine.. but it seems to me that "community supported" is a completely different concept than "exists as a repo in a project".

After all, openSUSE:Tools has RHEL 4 and all these other non-SUSE repos... are those distributions "community supported" by the openSUSE project??

So I don't understand the rush to remove the repo.

Needless to say, I still have stable 11.3 systems around that I'm not ready to upgrade just yet...

Thanks, -Archie

-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

-- Archie L. Cobbs -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

On 1/24/2012 9:25 AM, Claudio Freire wrote:

On Tue, Jan 24, 2012 at 11:22 AM, Bryen M Yunashko wrote:

...

...

What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.

Do others not agree?

-Archie

I'm going to assume that the EOL'ed repos get dropped due to storage conservation reasons. (only an assumption.) If that is the case, what do you propose is the length of time such repos should exist?

Not only that, it's sometime not easy to keep the packages building on old distros.

It's difficult but I do it all the way back to 10.0 for most of my stuff and the availability of say the current openssh on production boxes that can't lightly be replaced is worth a lot more than the prettiness of the spec file or the time it took for one guy to produce it. In that particular case it was pretty easy to get openssh building back to 10.2, but I have a problem I may or may not solve that prevents it on 10.1 & 10.0. But 10.2 is pretty good and worth doing. I only have a few 10.0 and 10.1 boxes and a lot more 10.3 and up. Another scenario is, maybe you can't continue to track the current version of something, but it's still very valuable to have whatever was the last version that _did_ build in that environment. It's usually far newer than whats' in the oss or updates repo, and often new enough to get you by some other otherwise impasse. For instance, maybe I can't get php5.3 built on 10.1, but maybe 5.2 did build? Well the current codeigiter can use php 5.3 or 5.2 but not 5.1.7 that came with OS 10.1. So if I have a range of boxes in production, including some 10.0 and 10.1, and I want to start working on some new projects and I want the developers to use codeigniter, it means I can actually deploy the current codeigniter everywhere. If I had been tracking openssh in my home obs project earlier than a few weeks ago, maybe I still wouldn't have the current version on 10.0, but I'd surely have a lot newer version that what my 10.0 and 10.1 boxes are stuck with now. Wherever along the way it stopped being buildable, it was long after the day the 10.0 oss repo was published or even the final update to the updates repo, and I would _love_ to have that package right now. Having a repo that builds against a given old OS version, and tracks packages as long as it can, and simply stops updating packages once they can no longer be built in that environment, but does not delete those final package versions whatever they were, is very valuable for years afterwards. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 1/25/2012 8:30 AM, Claudio Freire wrote:

On Wed, Jan 25, 2012 at 5:46 AM, Brian K. White wrote:

...

Having a repo that builds against a given old OS version, and tracks packages as long as it can, and simply stops updating packages once they can no longer be built in that environment, but does not delete those final package versions whatever they were, is very valuable for years afterwards.

Good point.

So, you're saying openSUSE:Tools should add DISCONTINUED:openSUSE:11.3.

It would be nice. But it would be nice _for me_ if every repo did that. I _loved_ it when kotd was doing that. But I have to admit it would multiply the space requirements rather a lot and I'd rather have some OBS than no OBS. It would also not really help very much with some packages if they are already not buildable on 11.3 etc. For instance, package foo might have started out building for os11.3 at foo1.0 when os11.3 came out. 2 years later foo is up to foo3.1 and still builds for 11.3 without problem. Then foo3.2 comes out and somehow no longer is buildable on 11.3, or at least not without real effort. Maybe it requires newer autoconf or gcc or who knows what... At that point, in my own obs home repo where the various older targets have already been existing a while, my 11.3 repo has foo3.1 forever, and my 11.4 and above have foo3.2 and newer. But now that foo has already changed to 3.2, if I were to create my os11.3 repo _today_, I would _not_ be able to have a foo3.1. I would only have the current foo3.2 spec file and src.rpm and they would not build on os11.3 and so I'd have nothing, just the foo1.0 that os11.3 originally shipped with, and even then I'd only have that _if_ os11.3 happened to actually include foo in oss or non-oss. There is no git/svn-like history of old spec files and src.rpm's you can refer back to. (I would love that!) So adding the discontinued build targets would be nice yes, but just understand what adding it today will and will not get you. Some stuff will be buildable with little or no effort, some stuff will be buildable with a little effort, some stuff will be unbuildable or only with more effort than anyone will do. That's some value already. But at least half of the value only comes from having had it in place already since before that OS version goes EOL when every single package built perfectly, and maintained continuously after that so that as upstream packages and their current spec files go incompatible, at least the last-built binary packages are left behind, and their matching src.rpms which includes the all important spec file, so those binary packages are documented and reproducable also. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Thu, Jan 26, 2012 at 2:47 PM, Archie Cobbs wrote:

We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.

But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.

Just add the DISCONTINUED repo to your home, and all is fine. Just a question... do the DISCONTINUED repos have all updates applied? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Thu, Jan 26, 2012 at 12:04 PM, Claudio Freire wrote:

On Thu, Jan 26, 2012 at 2:47 PM, Archie Cobbs wrote:

...

We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.

But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.

Just add the DISCONTINUED repo to your home, and all is fine.

So that solves the problem for my home repository, but what about the 10-15 other repos that our machines depend on? For example, Apache2:Modules, server:monitoring, etc., etc. So that doesn't seem like a very scalable solution. -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

* Archie Cobbs [01-26-12 13:21]:

On Thu, Jan 26, 2012 at 12:11 PM, Patrick Shanahan wrote:

...

...

...

But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.

Just add the DISCONTINUED repo to your home, and all is fine.

and then your next stop would be "evergreen" which hasn't picked up 11.3 yet.

Good grief.

The fact that people have already gone to the trouble to create "Evergreen", a valiant but imperfect kludge, speaks for itself.

Not really, you are expecting something that is not provided from a *product that is presented up front as not-a-long-term-solution*, ie: 18 mos You *did* read the notices about the *supported* life of the product when you chose it for install, so why expect more now? If you really need long term, you need to use the commercial SuSE offerings, or the adaptations people are graciously maintaining as have been described to you. The choice is yours as it was when you originally installed. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

OBS has always done that (or at least for quite a while) All you have to do is go in to your project conf xml and add the DISCONTINUED_openSUSE_11.3_Update_standard build target. In a few months you will have to do the same with 11.4 etc... Once they go discontinued, they don't change any more and you don't have to worry about them disappearing any more. I actually use the web interface to edit the xml because the web interface for adding repositories is buggy and doesn't display all the targets that actually are available. But looking at the values that it created in the xml you can extrapolate the possible names for the targets it didn't display, and luckily they worked. So, I don't know the OSC command way to do this which would be a better and more reliable way to document a procedure, but here is the web ui way: Log in to obs, my projects, click a project (home:foo) Click the Advanced tab Then click the Meta tab that appears further to the right. Insert a repository stanza like this: <repository name="DISCONTINUED_openSUSE_11.2_Update_standard"> <path repository="standard" project="DISCONTINUED:openSUSE:11.2:Update"/> <arch>x86_64</arch> <arch>i586</arch> </repository> Only 11.3 Except, my home repo still shows a regular 11.3, maybe the purge is currently in progress and just hasn't reached my project? My xml still includes: <repository name="openSUSE_11.3"> <path repository="standard" project="openSUSE:11.3:Update"/> <arch>i586</arch> <arch>x86_64</arch> </repository> So, when my 11.3 repo disappears I'll go in here and edit or create <repository name="DISCONTINUED_openSUSE_11.3_Update_standard"> <path repository="standard" project="DISCONTINUED:openSUSE:11.3:Update"/> <arch>x86_64</arch> <arch>i586</arch> </repository> The way I got those magic values initially was from using the repositories tab and the "add repostitories" link there, then "pick one via advanced interface" Then enter "open" or "suse" or "DISCONTINUED" into the "Repositires:" box. It will generate an (incomplete) list of various suse and opensuse repos. (If nothing happens, just wait a few seconds, it's slow sometimes.) You want "DISCONTINUED_openSUSE_11.3_Update_standard" Except that doesn't seem to exist yet. Mine still just shows openSUSE_11.3 Anyways, select any one, even if the version you want doesn't show, pick 11.1 or 11.2 etc, then hit "add repository" Then hit the Advanced tab again, then the Meta tab, and edit the xml directly. You will see the new repository in there, just try manually editing the 11.2 or 11.1 to 11.3. And finally, if 11.3 is undergoing transition right now, then none of this may work for 11.3 specifically right at this moment. You may have to wait a day or so and try it then. Other repos will work. You could add 11.2 just to go through the process and verify that you are doing it right, even if you really want 11.3 and 11.3 isn't working right now. It's a drag for people trying to get work done and who need to support production machines I agree 100%. But, still, maintaining one spec file and one set of sources on OBS and having to dink around with the disappearing build targets and the slightly buggy web ui and the swiss cheese osc documentation is still better than building everything myself on all the different boxes, even with rpmbuild and maintaining my own install server to re-use rpms once built. -- bkw On 1/26/2012 12:47 PM, Archie Cobbs wrote:

Holy crap.

I just realized that OBS has blown away ALL 11.3 repos, including my home directory, not just openSUSE:Tools.

Argggh... trying to remain philosophical here...

We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.

But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.

So the aforementioned long term stability of openSUSE has just been invalidated as a feature!

The openSUSE community is not just a bunch of Linux kids who all like to live on the bleeding edge. It's used for serious applications all over the place. To some of you folks 11.3 may seem like ancient history but in my world it's chugging along nicely. It's only been out for 18 months for goodness sake!

OK, I can accept that I'm in the minority. So what is the right answer then for me? I guess Tumbleweed is supposed to be the solution to this problem?

In any case, here is one thing I still don't understand: will someone please explain to me why RHEL 4, released 7 years ago, is more important to the openSUSE community than openSUSE 11.3, released 18 months ago?

-Archie

On Tue, Jan 24, 2012 at 1:03 PM, Archie Cobbs wrote:

...

On Jan 24, 2012, at 8:22 AM, Bryen M Yunashko wrote:

...

On Tue, 2012-01-24 at 08:13 -0600, Archie Cobbs wrote:

...

What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.

Do others not agree?

I'm going to assume that the EOL'ed repos get dropped due to storage conservation reasons. (only an assumption.) If that is the case, what do you propose is the length of time such repos should exist?

Longer than (for example) RHEL, which was first released seven years ago... ?

-- Archie L. Cobbs

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

On Thu, Jan 26, 2012 at 1:06 PM, Brian K. White wrote:

I agree 100%. I made the mistake of using Server:Monitoring and some others and now I don't do that any more. Anything I really need maintained for myself, I copy to my own home project, which means living without a lot of things I would like to have newer because I can't maintain that much all by myself.

The supposedly great thing about OBS is that we all get to share common wisdom of how to build and deploy an incredibly wide range of software, no matter who you are or what you are doing, and everyone benefits. This is exactly what open source is all about. However, the way things are now, anyone who wants to use a stable platform for mission critical services is being forced to NOT share this wisdom.. just read the above quote for example. I'm surprised the powers that be wish to offend and exclude that group. What a pity. On Thu, Jan 26, 2012 at 12:28 PM, Claudio Freire wrote:

To attempt a justification as to why older RHEL distros still exist, non-opensuse repos get added with less frequency. Otherwise, it wouldn't be possible to keep them all, just as it isn't possible with opensuse ones. You have to draw a line somewhere.

I appreciate this attempted explanation, but it is completely inadequate. Still waiting for a good one. -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Donnerstag, 26. Januar 2012, 17:29:43 schrieb Claudio Freire:

On Thu, Jan 26, 2012 at 3:50 PM, Brian K. White wrote:

...

In a few months you will have to do the same with 11.4 etc... Once they go discontinued, they don't change any more and you don't have to worry about them disappearing any more.

Perhaps an extended support version should be appointed for every major version. To avoid this issue, and to appease the server folks. Which I would imagine is an important enough endeavor.

Perhaps the last minor of every major version should enjoy, if not extended *support*, at least extended *presence* in OBS.

So perhaps 11.4 shouldn't be phased out of OBS as soon as it reaches EOL. Maybe someone will volunteer for maintenance duties even, who knows.

check evergreen project, it still builds againt DISCONTINUED:openSUSE:11.1 As usual, it is just a matter of work. Reach out to Wolfgang Rosenauer if you want to help 11.1 or any other DISCONTINUED distro. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

* Claudio Freire [01-26-12 15:30]:

Perhaps an extended support version should be appointed for every major version. To avoid this issue, and to appease the server folks. Which I would imagine is an important enough endeavor.

Perhaps the last minor of every major version should enjoy, if not extended *support*, at least extended *presence* in OBS.

Well, there is *no* major/minor version of openSUSE and has not been for as long as I can remember. In spite of the dot numbers, *all* versions of openSUSE are *major*. In fact the published version numbers were changed effective 12.1 to always start with ##.1 to ensure the public that the issue was not a "first major changed" version. That apparently has failed, at least in this instance. Please feel informed. Voluminous discussion about major/minor numbering schemes for openSUSE may be viewed in the archives and, on request, a pointer will be provided. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Thu, Jan 26, 2012 at 05:29:43PM -0300, Claudio Freire wrote:

On Thu, Jan 26, 2012 at 3:50 PM, Brian K. White wrote:

...

In a few months you will have to do the same with 11.4 etc... Once they go discontinued, they don't change any more and you don't have to worry about them disappearing any more.

Perhaps an extended support version should be appointed for every major version. To avoid this issue, and to appease the server folks. Which I would imagine is an important enough endeavor.

http://www.suse.com/products/server/ there you get all you're requesting. And if you need you get extra years of support and there are partners available all around the world. Well this SUSE Linux Enterprise (SLE) advertisement might be as off topic as the complaiin about the short openSUSE lifetime¹ was. :)

Perhaps the last minor of every major version should enjoy, if not extended *support*, at least extended *presence* in OBS.

Why? SLE is available as a build target.

So perhaps 11.4 shouldn't be phased out of OBS as soon as it reaches EOL. Maybe someone will volunteer for maintenance duties even, who knows.

In many years we're maintaining old Samba versions for older products we've seen less than five external contributions. That was said to stress how likely it will be that someone will volunteer to maintain a huge amount of packages. That's a lot of work. And to all the guys complainimg again and again about how good all had been in the past: Please read once again http://lists.openSUSE.org/opensuse-factory/2011-11/msg00471.html Cheers, Lars ¹ http://en.openSUSE.org/Lifetime -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Thu, Jan 26, 2012 at 7:41 PM, Jim Henderson wrote:

On Thu, 26 Jan 2012 13:28:11 -0600, Archie Cobbs wrote:

...

On Thu, Jan 26, 2012 at 12:28 PM, Claudio Freire wrote:

...

To attempt a justification as to why older RHEL distros still exist, non-opensuse repos get added with less frequency. Otherwise, it wouldn't be possible to keep them all, just as it isn't possible with opensuse ones. You have to draw a line somewhere.

I appreciate this attempted explanation, but it is completely inadequate. Still waiting for a good one.

What exactly is inadequate about it?

1.  You're using a free distribution 2.  You're using services that are provided for free 3.  Those services require disk storage, bandwidth, and other resources that aren't free. 4.  Since those resources aren't free, it's not possible to keep everything for all versions going back forever. 5.  That means that when resources are constrained, something gets clipped, and the logical starting place is to start with the oldest stuff.

If you want something that's got LTS, SUSE has some commercial options with the resources necessary paid for by licensing fees paid by customers so the support is retained for a longer period.

Free (as in beer) does have its limitations.

Understood. I don't take anything for granted and understand that when it comes to service, you get what you pay for... and if you're paying nothing, you have a right to demand nothing. In addition I would even argue that OBS users have a moral responsibility to contribute back, in the form of patches, bug reports, builds of new software, etc. (and I try to do this). I'm not demanding anything, just asking a fairly narrow question. I'm simply seeking to better understand, because my previous assumptions were obviously wrong. Your #5 is: "That means that when resources are constrained, something gets clipped, and the logical starting place is to start with the oldest stuff." Sounds good to me! So let's look at the facts: openSUSE 11.3: 1.5 years old, and is a SUSE distribution RHEL 4: 7 years old, and is not a SUSE distribution My simple question is: why openSUSE 11.3 before (for example) RHEL 4? What are the underlying priorities that resulted in that choice? If the answer is "because 11.3 is EOL" well then I guess what I don't agree with is that equation. All openSUSE are (by definition) supported by their owners. These owners need the OBS repos in order to perform that support. If that support is unilaterally denied at the 18 month mark, then it dramatically reduces the usefulness of openSUSE for a large swath of possible use cases (basically, everything other than personal use). OK, let's just admit the obvious: Novell is a business and it doesn't want to allow business' "mission critical" software to run on openSUSE because that represents lost revenue for SLES. Their enforcement mechanism is to limit openSUSE support to 18 months. While this is entirely in their right, this is a very blunt instrument. It is similar to the airlines charging you a higher price if you don't stay over a Saturday night: another blunt instrument targeted at business travelers. However there is a difference between the airlines' business and the open source software business: the latter is a true ecosystem, where you depend on the contributions of your customers. Food for thought. Thanks, -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Fri, Jan 27, 2012 at 9:24 AM, Patrick Shanahan wrote:

* Archie Cobbs [01-27-12 10:15]:

...

If the answer is "because 11.3 is EOL" well then I guess what I don't agree with is that equation. All openSUSE are (by definition) supported by their owners. These owners need the OBS repos in order to perform that support. If that support is unilaterally denied at the 18 month mark, then it dramatically reduces the usefulness of openSUSE for a large swath of possible use cases (basically, everything other than personal use).

OK, let's just admit the obvious: Novell is a business and it doesn't want to allow business' "mission critical" software to run on openSUSE because that represents lost revenue for SLES. Their enforcement mechanism is to limit openSUSE support to 18 months. While this is entirely in their right, this is a very blunt instrument. It is similar to the airlines charging you a higher price if you don't stay over a Saturday night: another blunt instrument targeted at business travelers.

off-base     Novell != openSUSE

While, as I read the conversations on the mail lists, consideration is given to Novell's business model but not *defining* the path of openSUSE. Novell has no "enforcement mechanism" in place.  You are grasping straws and causing confusion, ie: spreading fud.

OK, if that's true then that makes things much simpler. If Novell is not influencing this process, then that means the community gets to fully decide. In which case, I think we should survey our community and see how many people are happy with the rapid deathcycle of openSUSE releases. I'm guessing there are many others out there who would like to "redefine" it. -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Fri, Jan 27, 2012 at 9:46 AM, Claudio Freire wrote:

On Fri, Jan 27, 2012 at 12:35 PM, Archie Cobbs wrote:

...

In which case, I think we should survey our community and see how many people are happy with the rapid deathcycle of openSUSE releases.

I'm guessing there are many others out there who would like to "redefine" it.

Why not bring evergreen into the equation?

Ie: synchronize EOL with incorporation into evergreen.

Right now the real problem is that 11.3 isn't in evergreen. If it was, all this would be moot.

Read this[0] thread. It requires quite a lot of manpower to be able to do so. Evergreen needs more people. So, gather volunteers. It's about backporting patches, IIRC, not major development.

[0] http://lists.rosenauer.org/pipermail/evergreen/2012-January/000560.html

Evergreen is a noble idea, with a good number of people interested (see thread above), yet it has stalled and there seem to be no plans by the OBS team to accommodate the idea. Really, the fact that Evergreen even exists is ridiculous. There are a bunch of people who need basic openSUSE repo availability to last more than 1.5 years, but their needs are not being addressed. And it seems like such a simple thing! But I don't know enough about the operation of OBS to advise intelligently. Do we need to start fundraising for more disk drives?? I'm curious to hear more informed opinions. -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Fri, 27 Jan 2012 09:13:00 -0600, Archie Cobbs wrote:

Your #5 is:

"That means that when resources are constrained, something gets clipped, and the logical starting place is to start with the oldest stuff."

Sounds good to me! So let's look at the facts:

openSUSE 11.3: 1.5 years old, and is a SUSE distribution

RHEL 4: 7 years old, and is not a SUSE distribution

My simple question is: why openSUSE 11.3 before (for example) RHEL 4? What are the underlying priorities that resulted in that choice?

I couldn't tell you since I'm not privy to the business information. But at a guess, it's not based on age but number of releases. RHEL6 IIRC is the current release, and for customers running older releases, SUSE has an incentive to support them because they would like nothing better than to migrate those RH customers to SLES. By including RHEL4/5/6 in OBS, that lets custom packages those RHEL customers are building to be built cross-distribution making migration easier. But that's just a guess based on what I know/knew from when I was at Novell. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 1/27/2012 11:47 AM, Archie Cobbs wrote:

On Fri, Jan 27, 2012 at 9:46 AM, Claudio Freire wrote:

...

On Fri, Jan 27, 2012 at 12:35 PM, Archie Cobbs wrote:

...

In which case, I think we should survey our community and see how many people are happy with the rapid deathcycle of openSUSE releases.

I'm guessing there are many others out there who would like to "redefine" it.

Why not bring evergreen into the equation?

Ie: synchronize EOL with incorporation into evergreen.

Right now the real problem is that 11.3 isn't in evergreen. If it was, all this would be moot.

Read this[0] thread. It requires quite a lot of manpower to be able to do so. Evergreen needs more people. So, gather volunteers. It's about backporting patches, IIRC, not major development.

[0] http://lists.rosenauer.org/pipermail/evergreen/2012-January/000560.html

Evergreen is a noble idea, with a good number of people interested (see thread above), yet it has stalled and there seem to be no plans by the OBS team to accommodate the idea.

Really, the fact that Evergreen even exists is ridiculous.

There are a bunch of people who need basic openSUSE repo availability to last more than 1.5 years, but their needs are not being addressed.

And it seems like such a simple thing! But I don't know enough about the operation of OBS to advise intelligently.

Do we need to start fundraising for more disk drives?? I'm curious to hear more informed opinions.

-Archie

I would definitely chip in for more opensuse repo lifetime, and for more manpower to uphold a higher standard in the opensuse product wrt stability of interface , predictability, backward compatibility, general polish "if there's a button, it works". The usual response is "you want SLE". No, I do not want a cul-de-sac proprietary product environment that is somewhat like opensuse but different enough that packages and documentation and procedures etc for opensuse do not always apply to sle NOR vice versa. If I spend time working on a package, or documenting a procedure, and I'm giving my time away, then I want the result to be applicable to everyone else for free as I intended instead of some subset of people that pay Novell being the only ones that benefit. If I wanted that, I'd have done the work for pay and just my own customers would benefit. And when I look for help or clues from others experiences, I want to have a large pool of data to work from, not just the people who for some reason pay for SLE. "It's a free thing, you have no right to expectations" is a crap argument. Why bother working on a thing at all if you and the other people working on it do not mostly want it to be excellent? "X is willing to do the work so X gets to say how it goes." is also a crap argument. I'm "willing to do the work" to fix the text mode server model so that it has no branding or graphics anywhere in it, no splashy or gfxboot, unhacked upstream versions of grub & syslinux, no kdm, etc, but it ain't happening. And anybody can be willing to do the work for all manner of horrible ideas (systemd), but that shouldn't be enough of a reason to allow it to happen. There are just a lot of problems with the reponses to various complaints that I and others have raised in general. It's just starting to feel like the main opensuse contributors are no longer interested in making a system that's actually useful for others, instead mostly interested in amusing themselves. I haven't tracked other distros development closely so I don't know, it may be the same everywhere and maybe opensuse is no worse than any other in this respect. It may just be a generational thing. But back on topic, I'd pay for more repo lifetime. Also svn/git-like revision histories of spec files. Like what the wiki does. So you don't have to lose the various optimal points that are reached and then lost along the way right now, where a newer package might be possible to build on some older target, and it existed for a while, but now the knowledge of that is lost because the current version of that package isn't buildable on that old target, and the spec and src.rpm from that time no longer exist, maybe the whole repo no longer exists ala kotd, server:monitoring, etc, only the current ones and the much older ones that shipped with that older target and nothing in between. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 1/28/2012 1:35 PM, Malcolm wrote:

On Sat, 28 Jan 2012 06:40:15 -0500 "Brian K. White" wrote:

...

But back on topic, I'd pay for more repo lifetime.

Hi You can always create you own OBS (as in the obs server) environment and keep things going locally?

I do exactly that already. But it's incomplete. I only mirror my own little home repo and the main oss, non-oss, & updates repos for for i386 and x86_64, no src, no ppc, no other of the zillion home and devel repos, and no roll-back-able history for the spec files. But at least I have a few packages building current or at least a lot more-current for targets back to 10.0, and I have my own mirrors of oss, non-oss, and updates repos for 10.0 and up. So when I need to install something new on 10.0 I still can.

How much would you pay per annum?

I'm only a home user, but use SLED as well (with the SDK I get most of the other stuff found in SLE, on OBS and build myself), the last three year subscription to updates was US$35 per year.

Less than $100 per machine per year, but that's already thousands even for a modest operation. But I won't invest in a closed product or a unless I have no other choice. So I won't invest in SLE* when it has any source or binaries or repos that aren't equally freely available for all. Maybe I'd pay more if asked politely and I thought it was going where I wanted it to go and convinced it wasn't a wasted gesture like if too few others were doing likewise. But I won't have even $10 extracted by coercion. I don't need to get any personal service for that price either. It's not about not paying for value. It's about paying for uncountably wide spread and long term value instead of short term dead-end value. You have to help create the world you want to live in. I happen to hate the traditional software world of bombs hooked to treadmills. So you have to start living without whatever people are selling the old way no matter how nice it may look, and start paying the people who are giving their stuff away free. At least for software, art, and other information, which has only a high creation and development cost and not a high dissemination cost. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Tue, Jan 31, 2012 at 6:22 AM, Jos Poortvliet wrote:

The point is this: SUSE is the one who pays for openSUSE's lifetime. As in, SUSE pays the people working on security updates and fixes. SUSE pays the server space and processing power. We are committed to pay for keeping 2 openSUSE versions maintained and alive with a few months bonus. We're not going to pay for more as it is expensive and doing so would cut in our income - we're not exactly trying to kill our own company and land all our engineers on the street.

Hmm... I think there is a subtlety here that is worth mentioning... I realize security updates and fixes are costly, but for me that's actually not as important as simply having basic access to the repositories. In other words, I don't have a problem with SUSE not actively supporting 11.3 with updates and security fixes. For example, I have one 11.3 system which is working fine and only accessible from the outside world via SSH. So the only security issues I need to worry about are SSH bugs, and fortunately those are few and far enough between that I can manage them myself. What really hurts though is that the existing 11.3 repos of every OBS project were unilaterally deleted, which means now I can no longer even build 11.3 machines. So here's my question: why not let 11.3 just "live on", without any official maintenance? Let the laggards like me who continue to use it worry about security fixes and updates. And let each OBS project decide when supporting 11.3 builds is too much of a pain, instead of deciding for them. It seems that doing this this would only require a little more disk space and CPU power. It would allow lots of people who rely on stable systems to continue to be able to build and maintain those systems. As you pointed out, disk and CPU are not primary drivers of what gets kept, "actively maintained" is. So declare 11.3 "actively maintained but without updates or security fixes" and we're done. This would be analogous to RedHat's "Extended Life Phase" (which RHEL 4 will enter in February): see https://access.redhat.com/support/policy/updates/errata/ This seems like a simple compromise that would address most of what both sides of this discussion want. What do you think? -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

I never heard any response from the question below from the openSUSE folks. Is this idea feasible? Thanks, -Archie On Tue, Jan 31, 2012 at 11:24 AM, Archie Cobbs wrote:

I realize security updates and fixes are costly, but for me that's actually not as important as simply having basic access to the repositories.

In other words, I don't have a problem with SUSE not actively supporting 11.3 with updates and security fixes. For example, I have one 11.3 system which is working fine and only accessible from the outside world via SSH. So the only security issues I need to worry about are SSH bugs, and fortunately those are few and far enough between that I can manage them myself.

What really hurts though is that the existing 11.3 repos of every OBS project were unilaterally deleted, which means now I can no longer even build 11.3 machines.

So here's my question: why not let 11.3 just "live on", without any official maintenance?

Let the laggards like me who continue to use it worry about security fixes and updates. And let each OBS project decide when supporting 11.3 builds is too much of a pain, instead of deciding for them.

It seems that doing this this would only require a little more disk space and CPU power. It would allow lots of people who rely on stable systems to continue to be able to build and maintain those systems. As you pointed out, disk and CPU are not primary drivers of what gets kept, "actively maintained" is. So declare 11.3 "actively maintained but without updates or security fixes" and we're done.

This would be analogous to RedHat's "Extended Life Phase" (which RHEL 4 will enter in February): see https://access.redhat.com/support/policy/updates/errata/

This seems like a simple compromise that would address most of what both sides of this discussion want.

What do you think?

-- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Sonntag, 12. Februar 2012, 17:03:24 schrieb Archie Cobbs:

I never heard any response from the question below from the openSUSE folks.

Is this idea feasible?

As written quite some times ago, because it harms our mirrors and our build power. And we have way too many people not caring about to remove repos when it does not work properly anymore. So instead of opt-out, we have opt-in by using the DISCONTINUED:* project repositories. bye adrian

Thanks, -Archie

On Tue, Jan 31, 2012 at 11:24 AM, Archie Cobbs wrote:

...

I realize security updates and fixes are costly, but for me that's actually not as important as simply having basic access to the repositories.

In other words, I don't have a problem with SUSE not actively supporting 11.3 with updates and security fixes. For example, I have one 11.3 system which is working fine and only accessible from the outside world via SSH. So the only security issues I need to worry about are SSH bugs, and fortunately those are few and far enough between that I can manage them myself.

What really hurts though is that the existing 11.3 repos of every OBS project were unilaterally deleted, which means now I can no longer even build 11.3 machines.

So here's my question: why not let 11.3 just "live on", without any official maintenance?

Let the laggards like me who continue to use it worry about security fixes and updates. And let each OBS project decide when supporting 11.3 builds is too much of a pain, instead of deciding for them.

It seems that doing this this would only require a little more disk space and CPU power. It would allow lots of people who rely on stable systems to continue to be able to build and maintain those systems. As you pointed out, disk and CPU are not primary drivers of what gets kept, "actively maintained" is. So declare 11.3 "actively maintained but without updates or security fixes" and we're done.

This would be analogous to RedHat's "Extended Life Phase" (which RHEL 4 will enter in February): see https://access.redhat.com/support/policy/updates/errata/

This seems like a simple compromise that would address most of what both sides of this discussion want.

What do you think?

-- Archie L. Cobbs -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

On Mon, Feb 13, 2012 at 10:02 AM, Archie Cobbs wrote:

On Mon, Feb 13, 2012 at 3:00 AM, Adrian Schröter wrote:

...

Am Sonntag, 12. Februar 2012, 17:03:24 schrieb Archie Cobbs:

...

I never heard any response from the question below from the openSUSE folks.

Is this idea feasible?

As written quite some times ago, because it harms our mirrors and our build power. And we have way too many people not caring about to remove repos when it does not work properly anymore. So instead of opt-out, we have opt-in by using the DISCONTINUED:* project repositories.

I don't think that is the same thing as what I'm suggesting, and practically speaking, it's not a workable solution.

Here's the difference: today, if I want to (re)build a 11.3 server, I have to go find the maintainers of 15 different OBS projects and annoy them by asking them to add DISCONTINUED:11.3. Then of course every six months I have to do the same thing all over again.

And of course, only if I'm lucky enough to get 100% positive response can I build my 11.3 server. If the maintainer of, say, server:monitoring is just too busy or doesn't care about 11.3, we're out of luck forever.

In other words, the fact that you are unilaterally deleting repos after 18 months means - practically speaking - there's no way to get them back.

OK, let's try an even weaker proposal: declare that the last openSUSE version in each series (e.g., 11.4 for the 11.X series) is allowed to live a lot longer than 18 months, though not "officially supported". When it's 18 months are up, don't delete it, just leave it alone, so people can still use it. If some project doesn't want to keep it around they can choose to delete it themselves, but don't force it on them.

-Archie

Archie, I assume you know about the Evergreen project. http://en.opensuse.org/Evergreen A better proposal than yours in my mind would be for Evergreen supported openSUSE releases not have their sources in OBS renamed to discontinued until evergreen support drops. There is a current discussion thread on opensuse-project where it looks like 11.4 is likely to be designated the next evergreen release. If that works for you, I suggest you speak up in that thread. Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Archie Cobbs (archie.cobbs@gmail.com) wrote:

Why? First, it is worth observing that the very nature of OBS makes it difficult to pursue that goal. Because in OBS, for any project/package there is only one spec file - and therefore package version - for ALL repositories.

In other words, it would be impossible for a maintainer to configure a package to build foobar-1.2 on openSUSE 11.3 but foobar-2.1 on openSUSE 12.1.

So what happens? They either try to shoehorn foobar-2.1 onto 11.3, with lots of resulting build issues, or if that becomes too hard they just drop support for 11.3 or leave the build broken.

Some brave projects are willing to spawn sub-projects for each openSUSE version, e.g. Virtualization:openSUSE11.3. But this is unwieldy and hard to manage, and as a result most projects don't bother to do this.

I'm very new to the OBS, but I agree - to my inexperienced eyes, it does seem like there could be a more elegant solution.

(dreaming) Why not let each project be a simple git repo, with a branch for each repository, defaulting to 'master' if no such branch were defined?

Right, that was also my first reaction too the first time I found myself in a twisty maze of OBS repositories, all alike. Could it make sense to switch the OBS backend to git? Or at least build a git-obs bridge, in a similar manner to the existing git-svn bridge? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Adam Spiers wrote:

- rpmlint-mini.spec pulls in files from /usr on the build host; isn't that evil and wrong? - Why does rpmlint-mini include its own Python? - Why does rpmlint-mini even exist - isn't rpmlint good enough?

Plain rpmlint cannot be used in the build root as it would introduce python in each every build root. Therefore rpmlint-mini collects all necessary files from python and rpmlint and pre-compiles them to create a stand-alone package. The rpmlint-mini package is not meant to be used on real sytems, it's just a special hack for the build root.

First I found out that osc build doesn't use the rpmlint rpm at build-time; it uses rpmlint-mini, and rpmlint-Factory (even if not building for Factory, I think). The latter seems to be just a small layer of additional rpmlint configuration though.

Yes, rpmlint-Factory is a bit of a misnomer, rpmlint-policy-openSUSE or something like that would be better suited. It only contains badness settings.

https://build.opensuse.org/request/show/104823

Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Dienstag, 14. Februar 2012, 09:31:50 schrieb Ludwig Nussel:

Adam Spiers wrote:

...

...

https://build.opensuse.org/request/show/104823

Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories.

Please buildrequire obs-server in such situations, it does this. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am 14.02.2012 09:42, schrieb Adrian Schröter:

Am Dienstag, 14. Februar 2012, 09:31:50 schrieb Ludwig Nussel:

...

Adam Spiers wrote:

...

...

...

https://build.opensuse.org/request/show/104823

Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories.

Please buildrequire obs-server in such situations, it does this.

Factory packages can't require packages not in factory, so obs-filesystem sounds like a good compromise if you don't want or can't maintain obs in factory (with its long development cycle it shold be fine though *huest*). Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Ludwig Nussel (ludwig.nussel@suse.de) wrote:

Adrian Schröter wrote:

...

Am Dienstag, 14. Februar 2012, 09:31:50 schrieb Ludwig Nussel:

...

Adam Spiers wrote: ...

...

...

https://build.opensuse.org/request/show/104823

Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories.

Please buildrequire obs-server in such situations, it does this.

Well, please submit to Factory then.

I added obs-server to BuildRequires but I still get non-standard-[ug]id warnings. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Dienstag, 14. Februar 2012, 10:22:22 schrieb Stephan Kulow:

Am 14.02.2012 01:09, schrieb Adam Spiers:

...

obs-service-tar_scm.noarch: W: non-standard-uid /var/cache/obs/tar_scm/repourl obsrun> A file in this package is owned by an unregistered user id. To register the user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add the user to the "config" file and send a submitrequest.

This is a bug in the package if you ask me. the service package can be installed on every developer's machine and packaging it in a way that it only works on OBS server instances is *wrong*.

True, a reason to add obsrun user in this package to avoid to require obs- server. However, obs-server is never supposed to be to go into factory. So a simple obs-filesystem package may be needed indeed :/

Gretings, Stephan -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

Am 14.02.2012 11:08, schrieb Adrian Schröter:

Am Dienstag, 14. Februar 2012, 10:22:22 schrieb Stephan Kulow:

...

Am 14.02.2012 01:09, schrieb Adam Spiers:

...

obs-service-tar_scm.noarch: W: non-standard-uid /var/cache/obs/tar_scm/repourl obsrun> A file in this package is owned by an unregistered user id. To register the user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add the user to the "config" file and send a submitrequest.

This is a bug in the package if you ask me. the service package can be installed on every developer's machine and packaging it in a way that it only works on OBS server instances is *wrong*.

True, a reason to add obsrun user in this package to avoid to require obs- server.

No, it's not. Having the cache owned by obsrun won't fix anything as long as there is nothing running under this user. It's just a package that you install and it then spits in your face saying "sorry, for caching you need to fix me". So if it needs fixing anyway, then the obs boot scripts can just as well chown the directory to the user, OBS runs under. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Dienstag, 14. Februar 2012, 11:15:02 schrieb Stephan Kulow:

Am 14.02.2012 11:08, schrieb Adrian Schröter:

...

Am Dienstag, 14. Februar 2012, 10:22:22 schrieb Stephan Kulow:

...

Am 14.02.2012 01:09, schrieb Adam Spiers:

...

obs-service-tar_scm.noarch: W: non-standard-uid /var/cache/obs/tar_scm/repourl obsrun>

A file in this package is owned by an unregistered user id. To register the user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add the user to the "config" file and send a submitrequest.

This is a bug in the package if you ask me. the service package can be installed on every developer's machine and packaging it in a way that it only works on OBS server instances is *wrong*.

True, a reason to add obsrun user in this package to avoid to require obs- server.

No, it's not. Having the cache owned by obsrun won't fix anything as long as there is nothing running under this user. It's just a package that you install and it then spits in your face saying "sorry, for caching you need to fix me". So if it needs fixing anyway, then the obs boot scripts can just as well chown the directory to the user, OBS runs under.

There are no obs boot scripts running on developer workstations who use this just via osc.

Greetings, Stephan -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

Adrian Schröter wrote:

Am Dienstag, 14. Februar 2012, 11:11:50 schrieb Ludwig Nussel:

...

Adrian Schröter wrote:

...

However, obs-server is never supposed to be to go into factory.

Why?

Because we don't maintain it in the same time time frames as openSUSE distros.

So? You have to deal with that in openSUSE:Tools just as well, right?

And given to the experiences of total destroyed user data with 12.1 changes I am really frightend to run an OBS on a moving target.

In which way are the 217 packages in openSUSE:Tools less of a moving target? That's more frightening to me at least. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Adrian Schröter (adrian@suse.de) wrote:

Am Dienstag, 14. Februar 2012, 11:11:50 schrieb Ludwig Nussel:

...

Adrian Schröter wrote:

...

However, obs-server is never supposed to be to go into factory.

Why?

Because we don't maintain it in the same time time frames as openSUSE distros.

And given to the experiences of total destroyed user data with 12.1 changes I am really frightend to run an OBS on a moving target.

I think that might be a lot less frightening if we had full test coverage. I know that is probably a huge amount of work and not going to happen overnight, but I am planning a submitrequest today which will be a tiny step in that direction :) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Stephan Kulow (coolo@suse.de) wrote:

Am 14.02.2012 11:17, schrieb Adrian Schröter:

...

There are no obs boot scripts running on developer workstations who use this just via osc.

Right! And so it's pointless to have it owned by obsrun if no obs runs. "nobody" will do.

Well, this raises the question of security. Something called /var/cache/obs is clearly system-wide, but we don't want to allow multiple users on a non-OBS-server share the same cache (01777 permissions), because one user could poison the cache and cause another user to build trojaned packages. 01755 would work for the download_files service, but not for tar_scm where any user needs to be able to trigger an update of an existing cache entry (e.g. git pull). One way to do make cache poisoning difficult would be to make the source service set[ug]id obsrun, but of course history has shown that making a shellscript set[ug]id is generally a Bad Idea, and it still wouldn't protect against network hijacking. So maybe the best option is to stick with per-user caching, which is of course safe. I don't think it would be too wasteful, because in most cases outside the OBS server, there is only one developer per machine, and even if there are more, they are most likely building different packages anyway. obsrun and /var/cache/obs would only be used on the build server, so they should be set up by an obs-server / obs-filesystem package or similar, not the source services. If you agree, I'll remove them from the .spec files. When I added this caching layer to the tar_scm source service, I copied Adrian's configuration pattern from the download_files service: # config options for this host ? if [ -f /etc/obs/services/$SERVICE ]; then . /etc/obs/services/$SERVICE fi # config options for this user ? if [ -f "$HOME"/.obs/$SERVICE ]; then . "$HOME"/.obs/$SERVICE fi So then the server-only package would set up /etc/obs/services too. It would be nice if something automatically enabled the per-user cache though. Maybe osc could do this? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Adam Spiers (aspiers@suse.com) wrote:

Of course I'm biased because this is my idea ;-) but I think that git-obs would be a cool step towards a more decentralized model.

OK, so this is not a new idea - someone just pointed me at http://en.opensuse.org/openSUSE:Build_Service_Git_Backend What happened with that? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Tuesday 14 February 2012, Adam Spiers wrote:

Adrian Schröter (adrian@suse.de) wrote:

...

Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:

...

Could it make sense to switch the OBS backend to git?

There is a stub for that but a lot is missing like event handling and release counter handling.

I see. Would be interested to learn more about what's missing at some point ...

...

And you can't use git for entire projects

Agreed, that would be a bad idea, unless each project tracked its packages via sub-modules.

...

or even a repo for package repo,

This is what I had in mind.

...

because the size of the tar balls would kill you in default settings.

git-annex would easily solve that problem.

...

And git sub-projects are just the horror ...

Oh, OK :-) Why don't you like them?

...

...

Or at least build a git-obs bridge, in a similar manner to the existing git-svn bridge?

Of course I'm biased because this is my idea ;-) but I think that git-obs would be a cool step towards a more decentralized model. It would only provide decentralization client-side (i.e. from the perspective of OBS users), but that makes sense to me anyway, since the OBS server is unavoidably centralized. Then it would allow users to visualize package branches with standard tools like gitk, submit requests would map to pull requests (à la github), and merges could also be done with standard tools like kdiff3.

Yes, git support is IMO a must have. The major advantages I see would be - not losing commit history when sr'ing/merging or linking packages - locally doing atomic (readable) commits, pushing them squashed to OBS to avoid re-building every commit. - offline work is possible when OBS is down (which happened very often in the last time) - fetching several package clones (regardless their names) into the same working copy to speed up testing/comparing - rebasing commit history to have nice commit series to be pulled from the major projects (devel, factory etc.). cu, Rudi

On my last team which was organised around a central svn server, I used git-svn for two years and it gave me most of the advantages of decentralized development without anyone else on the team even needing to know. Then some of the other guys started getting interested, and it allowed us to collaborate in a decentralized way independently of the central svn server:

https://twiki.innerweb.novell.com/pub/PSO/GitHOWTO/_801___Screenshot. png

When's the next hackweek? ;-)

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

On Tue, Feb 14, 2012 at 9:22 AM, Adam Spiers wrote:

So maybe the best option is to stick with per-user caching, which is of course safe.  I don't think it would be too wasteful, because in most cases outside the OBS server, there is only one developer per machine, and even if there are more, they are most likely building different packages anyway.  obsrun and /var/cache/obs would only be used on the build server, so they should be set up by an obs-server / obs-filesystem package or similar, not the source services.  If you agree, I'll remove them from the .spec files.

First, I agree. But remember that though they'll be building different packages, many (and I mean MANY) dependencies that would be downloaded into the cache could be shared among users. Security takes precedence IMO, but it's not as inconsequential in the multiuser case as you may think. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Claudio Freire (klaussfreire@gmail.com) wrote:

On Tue, Feb 14, 2012 at 9:22 AM, Adam Spiers wrote:

...

So maybe the best option is to stick with per-user caching, which is of course safe.  I don't think it would be too wasteful, because in most cases outside the OBS server, there is only one developer per machine, and even if there are more, they are most likely building different packages anyway.  obsrun and /var/cache/obs would only be used on the build server, so they should be set up by an obs-server / obs-filesystem package or similar, not the source services.  If you agree, I'll remove them from the .spec files.

First, I agree.

Great ;-)

But remember that though they'll be building different packages, many (and I mean MANY) dependencies that would be downloaded into the cache could be shared among users.

This is a cache for upstream sources only (retrieved via tar_scm / download_files source services), so the dependencies would only get cached if they are being rebuilt too.

Security takes precedence IMO, but it's not as inconsequential in the multiuser case as you may think.

Sorry, I'm not sure I follow. What multiuser case are you envisioning here? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Tue, Feb 14, 2012 at 11:32 AM, Adam Spiers wrote:

...

But remember that though they'll be building different packages, many (and I mean MANY) dependencies that would be downloaded into the cache could be shared among users.

This is a cache for upstream sources only (retrieved via tar_scm / download_files source services), so the dependencies would only get cached if they are being rebuilt too.

Oh... so the rpm cache for dependencies uses another mechanism?

...

Security takes precedence IMO, but it's not as inconsequential in the multiuser case as you may think.

Sorry, I'm not sure I follow.  What multiuser case are you envisioning here?

Multiple users using the same machine for building of OBS packages. I've worked at at least one place where this was the norm. (because I told everybody just how great OBS is ;-) ) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Dienstag, 14. Februar 2012, 15:18:32 schrieb Ruediger Meier:
> On Tuesday 14 February 2012, Adrian Schröter wrote:
> > Am Dienstag, 14. Februar 2012, 14:14:21 schrieb Ruediger Meier:
> > > On Tuesday 14 February 2012, Adam Spiers wrote:
> > > > Adrian Schröter (adrian@suse.de) wrote:
> > > > > Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
...
> > > - not losing commit history when sr'ing/merging or linking packages
> > 
> > Actually, this would be also a not acceptable regression, if you do
> > not see anymore when you have merged requests. So, there would be a
> > concept needed how to tag and handle reverts.
> 
> Of course always "git merge --no-ff" into factory/master.

that is not a solution.

> > > - locally doing atomic (readable) commits, pushing them squashed to
> > > OBS to avoid re-building every commit.
> > 
> > Oh, well, priorisation system should take care of that.
> 
> My major point here is that changes across different topics should never
> be mixed into the same commit. But svn-like VCS leads to do it the bad
> way. Submit requests could be reviewed much easier if you see all the
> atomic commits behind a huge submit-request.

Frankly, I see this really as a minor thing during packaging work.

If you are unsure about your work, you branch anyway before submitting.

> > > - offline work is possible when OBS is down (which happened very
> > > often in the last time)
> > 
> > actually, offline work (offline build) is supported meanwhile in osc.
> 
> Is it possible to commit local only?

No. But again, I think this is a minor thing. It is way more important to have 
offline builds to be able to do packaging work.

> > And dependency calculation is still required server side in any case,
> > independend of the used src revisions system.
> > 
> > > - fetching several package clones (regardless their names) into the
> > > same working copy to speed up testing/comparing
> > 
> > we would need that anyway in seperate build environements or we can
> > handle the parallel build on server.
> > 
> > > - rebasing commit history to have nice commit series to be pulled
> > > from the major projects (devel, factory etc.).
> > 
> > ...
> > 
> > Do not get me wrong, I am not against an additional git backend. But
> > there are _MANY_ of unresolved problems with that and there do not
> > even exists concepts at all how to solve all the regressions and
> > major problems a git backend would have.
> > 
> > But everybody can take of course the existing code and work on it.
> > But the resulting code needs not to work on a single small package,
> > but scale also for projects like openSUSE:Factory.
> > 
> > The api test suite may be helpfull to see _some_ of the problems when
> > you replace the backend.
> 
> For now I just do "git init" within ocs working copies. It does already
> much of what I need allthough it can be confusing. An intermediate next
> step could be to improve the client side only by providing a git-osc
> similar to git-svn.
> Finally having git backend on OBS side someday would be really nice.

Well, if that works for you that is fine. But using git as repo is a complete 
different level of problems. Just because git offers a feature for you it does
not mean it offers all the features (revision counting, on-the-fly-merge, 
revision tracking, shadows sources and so on) the obs needs.

Anyway, since people always only say that git would solve everything but no
one works on it, I am stopping now here ;)

Feel free to work on it and I promise we will help you run into problems...

bye
adrian

-- 
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian@suse.de

Claudio Freire (klaussfreire@gmail.com) wrote:

On Tue, Feb 14, 2012 at 11:32 AM, Adam Spiers wrote:

...

...

But remember that though they'll be building different packages, many (and I mean MANY) dependencies that would be downloaded into the cache could be shared among users.

This is a cache for upstream sources only (retrieved via tar_scm / download_files source services), so the dependencies would only get cached if they are being rebuilt too.

Oh... so the rpm cache for dependencies uses another mechanism?

Yes, that's completely different - see the 'packagecachedir' config parameter in ~/.oscrc. I'm talking about a new cache just for source services which isn't even used it ...

...

...

Security takes precedence IMO, but it's not as inconsequential in the multiuser case as you may think.

Sorry, I'm not sure I follow.  What multiuser case are you envisioning here?

Multiple users using the same machine for building of OBS packages. I've worked at at least one place where this was the norm.

OK, so in that scenario you are saying it's not as inconsequential as I may think - but actually I think security is pretty important, so I'm still not sure what your point was ;-)

(because I told everybody just how great OBS is ;-) )

It's pretty amazing yes. We should not forget that while we are busy coming up with ways to make Adrian more stressed ;-) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Dienstag, 14. Februar 2012, 15:37:11 schrieb Adam Spiers:

Ludwig Nussel (ludwig.nussel@suse.de) wrote:

...

Adam Spiers wrote:

...

Ludwig Nussel (ludwig.nussel@suse.de) wrote:

...

Adam Spiers wrote:

...

- rpmlint-mini.spec pulls in files from /usr on the build host;

isn't that evil and wrong?

- Why does rpmlint-mini include its own Python? - Why does rpmlint-mini even exist - isn't rpmlint good enough?

Plain rpmlint cannot be used in the build root as it would introduce python in each every build root.

Sure - my question was really "why can't we have Python in every build root?"

That would make every single package implicitly build depend on python.

But every single package does already, it's just hidden inside rpmlint-mini. What's the advantage of doing that?

...

The amount of default installed packages needs to be reduced rather than adding even more.

For speeding up builds, or other reasons?

for that and to avoiding cycles which makes it hard to bootstrap a system. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

Am Dienstag, 14. Februar 2012, 10:34:44 schrieb Archie Cobbs:

On Tue, Feb 14, 2012 at 5:19 AM, Adrian Schröter wrote:

...

Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:

...

Archie Cobbs (archie.cobbs@gmail.com) wrote:

...

Why? First, it is worth observing that the very nature of OBS makes it difficult to pursue that goal. Because in OBS, for any project/package there is only one spec file - and therefore package version - for ALL repositories.

It is the easiest way, but there are also other ways with multiple spec files.>

...

...

In other words, it would be impossible for a maintainer to configure a package to build foobar-1.2 on openSUSE 11.3 but foobar-2.1 on openSUSE 12.1.

no.

...

...

So what happens? They either try to shoehorn foobar-2.1 onto 11.3, with lots of resulting build issues, or if that becomes too hard they just drop support for 11.3 or leave the build broken.

Some brave projects are willing to spawn sub-projects for each openSUSE version, e.g. Virtualization:openSUSE11.3. But this is unwieldy and hard to manage, and as a result most projects don't bother to do this.

that makes no sense usually. You can still build against DISCONTINUED:openSUSE:11.3 from same project. It is just that an absolute minority wants to support that at all.

Adrian I'm sure you're getting tired of this conversation thread, and me too.

I'm am going to give up trying to suggest solutions because I don't have the knowledge that you do and you can see all the flaws in my naive ideas.

So let me just describe the problem one last time and ask you to please suggest the right answer.

Right now it is impossible to (re)build our openSUSE 11.3-based server because, to take just ONE EXAMPLE, the mapserver package is not available for 11.3. This is because the Application:Geo/openSUSE_11.3 repo was destroyed.

It was removed because it is not anymore maintained. And as the Application:Geo maintainer I can tell you that I will not spend the additional work to do so in future. (Keep in mind that maintaining for old distros costs way more time then for current ones). If you need that particular package, then branch the sources and maintain it in your project. But you can't expect other to do your work. period adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

On Tue, Feb 14, 2012 at 11:19:35AM -0600, Archie Cobbs wrote: [ 8< ]

Or are you implying that openSUSE will never be a practical choice for the >18 month crowd?

There is the openSUSE evergreen approach. It has a page in the wiki. I suggest to join the efforts Wolfgang and others are focusing on. The life time of openSUSE 11.3 had been announced from the beginning. We also need to free the resources openSUSE 11.3 based builds consumed. And there is an alternative. Go with SUSE Linux Enterprise based products and you'll get something going much, much longer. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Tue, Feb 14, 2012 at 2:45 PM, Adam Spiers wrote:

...

...

OK, so in that scenario you are saying it's not as inconsequential as I may think - but actually I think security is pretty important, so I'm still not sure what your point was ;-)

Only that it shouldn't be pushed silently.

That what shouldn't be pushed?  (Sorry, brained fried today ;-)

Well, I feel I'm reading this out of context too, because the starting message on the thread looks like it came from an on-going discussion I'm missing. But, I'm assuming, this is something relating the "osc" tool. So, in that case, a warning in the changelog at least? As a warning for those following the list, maybe this thread is warning enough, but for those that do not, a note in the changelog might be a good thing as well. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Tue, Feb 14, 2012 at 1:07 PM, Greg Freemyer wrote:

If you could do the following, would it work for you?

At the EOL of a distro:

# clean the repo cache's, this works today I think. zypper clean --all

# rebuild the metadata, this works today I think. zypper refresh --force

# populate the cache's with a copy of all the packages you have installed,  this is new functionality I think zypper install --force --download-only \*

Then burn /etc/zypp/ and /var/cache/zypp to DVD (or whatever)

Then if you need to recreate a server, its restore those 2 directories and use

zypper --no-remote

==> I don't know if that would put to much load on OBS, or how hard it would be to add the missing zypper functionality, but it seems reasonably doable.

Yes, something like that would be a good start. Thanks for offering a constructive idea. Still, it seems like an unfortunate hack... Why not set up a new server http://download-discontinued.opensuse.org/, where right when openSUSE X.Y is EOL, all the openSUSE X.Y repos are moved there. Once moved, they would no longer be maintained, but would still be available for download. They would just be a static snapshot. Then the original download.opensuse.org could simply send back 302 Redirect responses for the EOL'd repos to fetch to http://download-discontinued.opensuse.org/ instead. This would only cost a few gigabytes, one simple copy operation every 8 months, and zero additional packager maintenance burden. Like I previously mentioned, there is a basic disconnect here caused by the "port" of openSUSE to OBS. Evidence for this disconnect is visible in the fact that openSUSE 11.3 itself is still available for download on download.opensuse.org, yet the openSUSE 11.3 OBS repos are not. This solution would simply remedy that disconnect. It seems very easy and it would solve a big problem for some of us. -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Archie Cobbs wrote:

[...] Right now it is impossible to (re)build our openSUSE 11.3-based server because, to take just ONE EXAMPLE, the mapserver package is not available for 11.3. This is because the Application:Geo/openSUSE_11.3 repo was destroyed.

Also, mapserver does not exist in any of the DISCONTINUED:openSUSE:11.3 repos, or Evergreen, or anywhere else.

So that's the problem: I need to be able to build and support servers that last more than 18 months and it's become practically impossible.

I really don't understand how you managed to get into that situation. Was the fact that openSUSE gets updates for 18 months and that 11.3 is going EOL in January 2012 not communicated prominently enough? Did you miss the discontinuation reminder that was sent six weeks before the fact? At this point you should bite the bullet and upgrade to 11.4 or 12.1 ASAP. Set a reminder in your calendar to prepare for the next distro upgrade in time. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Wed, Feb 15, 2012 at 2:44 AM, Ludwig Nussel wrote:

...

Right now it is impossible to (re)build our openSUSE 11.3-based server because, to take just ONE EXAMPLE, the mapserver package is not available for 11.3. This is because the Application:Geo/openSUSE_11.3 repo was destroyed.

Also, mapserver does not exist in any of the DISCONTINUED:openSUSE:11.3 repos, or Evergreen, or anywhere else.

So that's the problem: I need to be able to build and support servers that last more than 18 months and it's become practically impossible.

I really don't understand how you managed to get into that situation. Was the fact that openSUSE gets updates for 18 months and that 11.3 is going EOL in January 2012 not communicated prominently enough? Did you miss the discontinuation reminder that was sent six weeks before the fact?

It's 100% my own fault, I agree with that. My mistake was to believe that "EOL" meant merely "no longer supported" instead of "deleted immediately". And I'm not describing the problem here in order to assign blame to anyone. Rather I was hoping that we can discuss how things might work better for people who want to use openSUSE for longer than 18 months, without imposing an additional burden on package maintainers. I've offered an idea and would appreciate feedback on it. Thanks, -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org