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

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. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

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 -- 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: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. -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 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

On 1/26/2012 1:15 PM, Archie Cobbs wrote:

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

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. Your comment about the existence of evergreen speaking for itself I also agree completely with. We who chose suse a few years ago because it had qualities that said "we will be able to count on this for a long time" have now all gotten burned. Suse is changing way too much from month to month, but we're all invested in it now, servers already installed and deployed and 24/7 customers running their entire business on them, many with special EDI setups with other parties requiring non-trivial firewall coordination with customers-of-customers and vendors-of-customers IT people, If an IP changes, it no longer matches the external peoples firewalls and all the EDI transactions break... Uncountable business damage with orders not received or processed, etc, so it's rather non-trivial to upgrade or migrate these customers to other boxes just because the os version went eol a few months later. In place upgrades are out because as difficult as a migration to another newer box is, at least it can be reverted instantly with 100% confidence and safety. Not so with an in-place upgrade. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

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. 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

* 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. The lifetime of each issue of openSUSE is well documented. -- (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 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 -- 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 10:47:57AM -0600, 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.

Real disk storage and compute power. The 18 months are however mostly a manpower issue. Maintenance and security is still being coordinated 100% by SUSE employees. With 12.1 we are currently switching to a model where commnunity members can be integrated in the full process. So if community members do maintenance of openSUSE x.y, it basically never needs to end. Just SUSE mandates only 18 months currently. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

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? 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. -- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 12.1 (x86_64) Kernel 3.1.0-1.2-desktop up 13:47, 5 users, load average: 0.03, 0.07, 0.06 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Saturday, January 28, 2012 06:40:15 Brian K. White wrote:

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.ht ml> 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.

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. All that seems to me to be very much a community thing: a community member (SUSE) does work. When SUSE stops doing that work and nobody takes over, well, it stops. If someone wants to take over (like Wolfgang did) or pay to keep it alive: awesome. If you are willing to pay to keep openSUSE 11.3 alive for say 2 more years I'd be happy to try and get you a quote for support. If you think it's stupid to pay for such a service and you don't want to do the work, well, what do you expect? SUSE employees need to eat and donations won't pay for that. Heck, selling the openSUSE Box makes so little money we don't even bother anymore... I see nothing that warrants the anger you and Archie are displaying, sorry. About the "but why RHEL and not openSUSE 11.3" - simple, we keep versions which are actively maintained. RHEL is, openSUSE 11.3 is not.

On 1/31/2012 12:24 PM, Archie Cobbs wrote:

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

It would pretty quickly begin to take up a LOT more storage space. It's not nearly a free proposition. But like I said, and like he ignored, I'd be willing to pay for MY SHARE of more storage and lifetime. Of course I can't do it all myself. Yet another stupid response designed to end the discussion without actually reflecting on the fact that there is a problem and it is addressable. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

* Archie Cobbs [02-12-12 18:04]:

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?

I would guess that you do not read this forum from your question. 11.3 and other do _live_ on w/o maintenance, see: http://download.opensuse.org/repositories/DISCONTINUED:/openSUSE:/ -- (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 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 L. Cobbs -- 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 9:17 AM, Greg Freemyer wrote:

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.

Yes. This is simply the union of what we both want :)

There is a current discussion thread on opensuse-project where it looks like 11.4 is likely to be designated the next evergreen release.

Evergreen is a great idea and I like it. My only problem is that it shouldn't have to exist. Let me try to be a little bit philosophical... I think this quote from Carlos (on opensuse-project) hints at the root cause of all the trouble: "Carlos E. R." <> wrote:

No, the team doing the dev and packaging have different goals than a long time support.

According to this statement, package maintainers are not interested in working towards the goal of stable versions of packages running on stable long term versions of openSUSE. However, I'm not sure that's actually true. 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. (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? (back to reality) In other words, I'm suggesting we think about how improving the structure of OBS might make it easier to please everyone, instead of forcing a bias against long term support. -Archie -- Archie L. Cobbs -- 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:

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

...

(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.

Speaking of twisty mazes, here's a scenario I just found myself :-( I'm working on improving some of the OBS source services, during which I noticed that 'obsrun' is a standard user/group used by the OBS backend. However, when building from .spec files which reference this in the %files section, rpmlint complains: 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. So, wanting to be a good citizen, I branched and made the change. Before sending the submitrequest, I wanted to test it, so I did an 'osc build' locally, installed the resulting rpm, and then rebuilt obs-service-tar_scm, hoping to see the warning disappear. Unfortunately it was a lot harder than that! TL;DR summary ------------- - 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? - If submitrequests for rpmlint are to be encouraged, IMHO this all needs to be made a lot more obvious. The full saga ------------- I'm not entirely sure what the moral of this story is, but I'm including it here in case it's of use to anyone in the future ... 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. OK, so I needed to get my change into rpmlint-mini somehow. Looking in its .spec file, I saw the %install section has some very strange lines - in particular: install -m 644 -D /usr/share/rpmlint/config $RPM_BUILD_ROOT/opt/testing/share/rpmlint/config So the contents of the rpmlint-mini rpm you are building will depend directly on whichever rpmlint config you happened to have installed on the build machine at build-time! I thought that there was a golden rule about .spec files only referring to sources in the SOURCES/ directory, otherwise the generated .src.rpm will not contain all the sources required to be able to consistently reproduce the same binary .rpm. Did I get that wrong, or is there a good reason why rpmlint-mini should be an exception to this rule? Anyway, I figured that if I rebuilt rpmlint-mini on the same machine which had my patched rpmlint installed, it would inherit the same patched config via the install line above. However, rpmlint-mini also contains: %define _use_internal_dependency_generator 0 %define __find_requires %my_requires The point of this seems to be to ensure that all packages found by the built-in %{__find_provides} are filtered out of the resulting 'requires' list. I'm guessing that this is something to do with the way that rpmlint-mini contains its own copy of Python (why?!), but the end result is that my freshly built rpmlint-mini includes the following dependencies: ... auto: libc.so.6()(64bit) auto: libc.so.6(GLIBC_2.11)(64bit) auto: libc.so.6(GLIBC_2.14)(64bit) auto: libc.so.6(GLIBC_2.15)(64bit) ... In particular, the dependency on glibc 2.15 presumably comes from the rpm being built inside an openSUSE Factory buildroot. So that means I can only install it inside the buildroot, not on the 12.1 host: sudo rpm -Uhv /var/tmp/build-root/openSUSE_Factory/x86_64/home/abuild/rpmbuild/RPMS/x86_64/rpmlint-mini-1.3-0.x86_64.rpm error: Failed dependencies: libc.so.6(GLIBC_2.15)(64bit) is needed by rpmlint-mini-1.3-0.x86_64 But that's OK, because it's the buildroot which needs it anyway. Unfortunately installing it in the buildroot doesn't work either, because /usr/lib/build/init_buildsystem happily replaces it with the unpatched version every time: processing specfile /home/adam/SUSE/OBS/home/aspiers/branches/devel/openSUSE/Factory/rpmlint/rpmlint-mini/rpmlint-mini.spec ... running changelog2spec --target rpm --file /home/adam/SUSE/OBS/home/aspiers/branches/devel/openSUSE/Factory/rpmlint/rpmlint-mini/rpmlint-mini.spec init_buildsystem --cachedir /var/cache/build --rpmlist /tmp/rpmlist.Zl1T5W /home/adam/SUSE/OBS/home/aspiers/branches/devel/openSUSE/Factory/rpmlint/rpmlint-mini/rpmlint-mini.spec ... reordering...cycle: gio-branding-upstream -> libgio-2_0-0 breaking dependency libgio-2_0-0 -> gio-branding-upstream cycle: libcrack2 -> cracklib breaking dependency libcrack2 -> cracklib done deleting unwanted rpmlint-1.3-0 installing rpmlint-1.3-109.1 Next I tried injecting the patched rpmlint rpm into /var/tmp/osbuild-packagecache, but that didn't work either. After wading through /usr/lib/build/{build,init_buildsystem}, I finally found that the list of rpms to install in the buildroot is actually generated and passed into build by osc, and there's a nice --prefer-pkgs=DIR option to osc build which enabled me to ensure that my patched rpmlint was installed in the buildroot whilst rpmlint-mini was built. Then I could finally copy the patched rpmlint-mini back to the preferred package directory and rebuild my source service to ensure that the non-standard-[ug]id warnings no longer appeared. They didn't - hooray! So here's the request: https://build.opensuse.org/request/show/104823 -- 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

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 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

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. The amount of default installed packages needs to be reduced rather than adding even more. See efforts to remove automake etc from the default set. 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, 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: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 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.

cu Ludwig -- 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 (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

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

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

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

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

Claudio Freire (klaussfreire@gmail.com) wrote:

On Tue, Feb 14, 2012 at 12:41 PM, Adam Spiers wrote:

...

...

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 ;-)

Only that it shouldn't be pushed silently.

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

A warning for users might be in order if disk usage will grow considerably in that use case.

Yeah, well, arguably disk usage monitoring should be in place anyway ;-) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

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.

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?

There is a stub for that but a lot is missing like event handling and release counter handling. And you can't use git for entire projects or even a repo for package repo, because the size of the tar balls would kill you in default settings. And git sub-projects are just the horror ...

Or at least build a git-obs bridge, in a similar manner to the existing git-svn bridge? -- 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

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 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:

...

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

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.

...

- 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.

...

- 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?

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.

...

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___Screens hot.

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 Tuesday 14 February 2012, Adrian Schröter wrote:

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.

Oh, then I haven't understood the problem.

...

...

...

- 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.

That's the way I do it but it doesn't change the fact that currently branching is a very slow remote operation, check out again, switching working copy, etc. And moreover after sr the commit history is lost,

...

...

...

- 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.

It might be a minor thing from OBS admin's view. From developers view I wouldn't leave the room as long as my working copy is dirty. And I wouldn't even start to work if my VCS does not have full functionality yet. That's why I _workaround_ with "git init". Just pity that I can't save my local git history directly on OBS so I need to hope that I don't make mistakes when manually synchronizing my work between local git and remote OBS.

...

...

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...

Hey, I don't want to force you moving OBS to git. Just mentioned that it would be a real improvement (at least for the packagers who care as much about history and commit style like me). cu,Rudi -- 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 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. 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. And I really don't think I am in a "small minority" in that need. I love openSUSE and the OBS. Unfortunately, while the idea of creating OBS was a brilliant one, the idea of forcing openSUSE to live within its constraints has this bad unintended side-effect. Adrian please use your wisdom and help think of how the problem I've described might be improved. 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 Tue, Feb 14, 2012 at 11:04 AM, Adrian Schröter 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.

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.

That is understood. I appreciate the maintainers' efforts and I'm not asking anyone to continue maintain something they don't want to. Rather, just don't delete it... OR, better yet please suggest a solution to the dilemma I described in the previous email. Really, I'm simply asking for your creative guidance and suggestions. I'm not the expert (you are of course). Or are you implying that openSUSE will never be a practical choice for the >18 month crowd? 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 Tue, Feb 14, 2012 at 12:19 PM, Archie Cobbs wrote:

On Tue, Feb 14, 2012 at 11:04 AM, Adrian Schröter 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.

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.

That is understood. I appreciate the maintainers' efforts and I'm not asking anyone to continue maintain something they don't want to.

Rather, just don't delete it... OR, better yet please suggest a solution to the dilemma I described in the previous email.

Really, I'm simply asking for your creative guidance and suggestions. I'm not the expert (you are of course).

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

Thanks, -Archie

Archie, 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. Greg -- 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

On Tue, Feb 14, 2012 at 2:40 AM, Ludwig Nussel wrote:

Archie Cobbs 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.

First and foremost get the package into the distro instead of building it in some random repo. The whole point of the distro is to be a collection of packages that work together.

Agreed.

Secondly, you can have different versions of foobar in the same project by naming the source directories e.g. foobar and a foobar.openSUSE_xy. Only the latter would be build enabled for openSUSE xy while the former builds for everything else.

That works for one project but is impractical as a general solution ... it would require an explicit action (and new source directory) for every package in every OBS project every 8 months. -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

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

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

On Thu, Jan 26, 2012 at 5:59 PM, Patrick Shanahan wrote:

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.

Already feeling the information flowing in :-) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 24/01/12 11:13, Archie Cobbs wrote:

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.

They should, to save a significant amount of build resources. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org