[opensuse-project] [RFC] - Attempt to build open SLES-based distro
Hello community, this mail is the result of years of continuous development in my (corporate and private) environment as engineer favoring SUSE, and I kindly invite anyone to send thoughts, comments and ideas regarding this mail. I see this topic "as in progress" and if there aren't any ultimately bad reasons why not to do so, I will continue and support this as long as I can. - Disclaimer: This is all IMHO ;) - My idea is to build a SLES binary-compatible distribution completely supported by the community (and optionally supported by companies which are willing to do so) - most of you will probably see lots of similarities with CentOS in this way - And in fact: This is exactly what I intend it to be. Why? - SLES is one of two key players in the major distribution league. RH has CentOS, and whereever you see "respins" like for appliances, they use CentOS (or maybe some debian/ubuntu/knoppix-stuff) - no SUSE. Examples: Trixbox, ESVA, and _lots_ of projects in which I've been involved in development however its not officially communicated as CentOS. - SUSE is the best Distro in terms of packaging and distribution technology (OBS), has a huge community-base and uses technology which IMHO is unmatched for various reasons such as KIWI (thx to Marcus Schaefer ;)). - openSUSE is a "moving target" in terms of its faster release cycle and it in fact is a problem that older releases disappear from the mirrors pretty soon. (I would not change anything here) - But: This doesn't really allow you a "LTS"-like behaviour if things change so fast. - SUSE has a great community of highly motivated and skilled guys (and gals) ;) - lots of developments in openSUSE find their way right into SLES, approved and tested by SUSE engineers. What I can and will provide: - I'm just building up a rack to provide various build nodes. Target arch's include: x86, x86_64, sparc64, ia64, ppc64. Most of the parts are already available, but since I'm currently moving and I need to get a stable permanent internet connection this could take up to 2 months. So this enables us right from scratch to set up a parallel OBS for the intial build setup. Official OBS could always be used as soon as we have reached a "staging" level where we can provide a base set of packages. - I will provide anyone with an account and try to build a full "infrastructure" which then should also should get the transition to "community-controlled" behaviour. For all (eventually) upcoming questions: - Yes, I do know about openSUSE Evergreen, but it lacks some points I've mentioned above like "Enterprise Features", 1-on-1-("binary")compatibility with SLES and the great quality work by SUSE to get SLES certified by OEM's etc. - and no one really points its OBS tree to build against Evergreen, it points it to major channels like SLES11, SLES11SP1, oS11.4, etc. - No, I do not want to work "against" SUSE or anything like that. The complete opposite is the case: Without SUSE this would not work well. In fact I really think SUSE also can profit from a community base around the SLES packages. Take a look at CentOS - Does it really hurt RHEL? I don't think so, at least not to a major extent. Lets get the facts straight: If you are in a corporate environment you _will_ (or at least you _should_) buy a SLES. Reasons: Support, Updates, Faster upstream process, tracking, direct contact, etc. But: If you want to build a steady home system which you do not want to upgrade less than every year in a major way or you might want to build a distro fork for special purpose (like for system integrators, etc.) you (probably) wouldn't want to go with the fully blown SLES. - Yes, I see this as lots of work. Please let me know if you are willing to help. ;) Can't await reading your comments. Cheers, - mike -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le 27/09/2011 11:29, Michael Kromer a écrit :
Can't await reading your comments.
one thing that prevent me from using evergreeen is that my ISP uses a special kernel (fitted to the servers hardware he provide). Also some problems of my own :-( but I simply wanted to say that any non professional system should allow easy kernel setup jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Am 27.09.2011 12:06, schrieb Markus Slopianka:
open-slx is planning an SLE 12 clone with the completely retarded name Balsam Enterprise, although I don't know if they plan that with community participation.
According to the first announcement they are planning exactly the same business model as SLES but just a few bucks cheaper. "Kunden, die Support und Maintenance benötigen, sollen zudem entsprechende Leistungen bei open-slx ordern können." Wolfgang -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Honestly: No, this is not my intention. Of course, we all want to do good business, and as I said this could be optional - I really want to see this community controlled (with some guys for admin-stuff, tracking, etc.) - not company controlled (similar to what openSUSE does). open-slx simply looks to me as it wants to copy SLES, rebrand it, and make money of it. It is a business model, but none I would like to support. And BTW: Roadmap says SLES12 is to be released in Q3-4/2013[1]. Really: I want to get something done earlier, since open-slx could only start their work probably somewhere in 2013 (when the first betas come up if they really do) ... ;) @Wolfgang: Thx. I really appreciate your help! - mike [1] http://www.slideshare.net/NOVL/suse-linux-enterprise-technology-roadmap -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 09/27/2011 12:06 PM, Markus Slopianka wrote:
open-slx is planning an SLE 12 clone with the completely retarded name Balsam
balsam (n.) a fragrant ointment used as medication; a balm. balm (n.) A soothing, healing, or comforting agent or quality. hence, Balsm is distribution to soothe, heal and comfort your (computing) ills.. what is "retarded" about that? cites: <http://www.answers.com/topic/balsam> <http://www.answers.com/topic/balm> -- DD -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi, If you _really_ want to do it, you should first open a concept. You´re interested in doing it, I also would like to see such a system, and I think there also other people who wants to get into this. But we all know, /how/ difficuilt it is to create an enterprise system, even if you just "branch" an existing one. Remember that you have to remove all brandings because this might could hurt SUSE and they will hurt you, if you do it :-) On the other hand, what is your motivation to create such a project? You don´t seem to want money, so, just for fun? Then I really would suggest you to join the evergreen project, even if it isn´t 100% the same as SLES. You have the force to change it, by supporting the project. Also, I guess that there dozens of people who would like such a project, but who haven´t the time or who don´t want to support it, because they have enough to do with openSUSE or/and they are working for SUSE. I would suggest you to wait what open-slx is doing *or* to use SUSE Studio (____but____ you have to remove ***all*** branding and other non-free things. This will really be something I don´t wanna do, because it´s so f..... difficiult to do.) hope this helps, -- Kim Leyendecker openSUSE -- send from my notebook -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi,
In fact: I'm working on a concept already. Good to know that it is not only my point of view that this is something people would like to see.
Full ACK. It is a hard job. I've seen the guys at CentOS doing this, and I've seen also the typical ressources (such as buildsystems) as one bottleneck. The branding issue is in fact one very important (if not _the_ most important ;)) thing. One of the first things I am up to is to check the license on all packages within SLES, since there will be some packages which can not be included out of the box.
If even Wolfgang (as maintainer for Evergreen) is interested on this one I really think I'm moving a good direction. He himself stated, that he originally wanted to make a SLES clone. Really: It's a hard job, and you bet this will not be done within weeks or even months. Such a process is something you could rather calculate in quarters (if you really are into on this one). About my motivation: It's a mixture between fun and "business", but more for fun. Business is not what you may think from my side - It's about the motivation to get SUSE respinable also for complete different distro rebuilds, etc. There are companies out there which would love to use a SUSE-based distro, and in fact I want to rebuild a rock-solid SLES with no regulations, obligations or anything else on it. I mean, isn't this is what OSS is all about? As I said, all of this should not do any harm to SUSE at all. I love SUSE, probably will always do - I also have good contacts to SUSE employees and really admire all work they do and would never risk to get into a bad situation with them. For the fun side: Hey, how often do you have the chance to really something cool and have people asking for it? ;) Additionally: SUSE Studio (or kiwi in specific) is one hell of a nice piece of software. But what are the problems people will be facing with it: Yes, you can build with openSUSE, customize down like whatever you like, but sooner or later you will get into that specific update-problem (repos, etc. what I've mentioned earlier) - If you take SLES and you want updates: Go and get a subscription. About the pricing: SUSE in my opinion is cheap, really cheap (maybe even too cheap - my honest opinion) - But it is just too expensive if you might want to respin something with a rock solid basis (!and!) want to redistribute it. I know this fairly well, since about 4 years ago I've been in development with an asterisk-based appliance. Realistic I had 2 choices: CentOS and openSUSE, guess what I've taken. I bet you took CentOS - nope. I took openSUSE however this was really a pain in the a**. There have been updates which simply caused major changes and therefore we had to work around it in numerous ways. With SLES (or a clone of it) you might also have issues, but by far not at a comparable frequency.
I've taken this into account. I have no idea on how SUSE would handle this. Really, no idea. But I also have to make clear: My business day is >12 hours mostly, but my decision to do this is something I really have been thinking about. I had about 3 drafts already done to send to this list (the first time over a year ago) - Now I regret I hadn't done it before. As I said: This all should be about community - The same way with openSUSE, if people are dedicated and like what they see, they might go for it and help. So nothing really new here. I have no idea how much this might attract people, however: CentOS proves it _can_ work. What I offer to do is providing infrastructure, taking a look on legal issues, building a base system and providing the community with everything with as much time and ressources I can. As this might grow this concept might be something you have to think about after some time of course (since nobody can spend endless ressources for nothing), but there must be some way to start - And correct me if I'm wrong, but you have to start somewhere - and if this works out well it'll just be another community OS with maybe some companies backing infrastructure, etc.
No. As I said before, open-slx is not an option for me. And why should we wait? Is there any reason? I know, we IT guys can be called lazy at some point, but at least I'm not too lazy to wait for somebody else doing the job. Who knows: Maybe they'll branch off from us at some point. That in fact would be funny - just kidding.... ;)
hope this helps,
It does, really - The title "RFC" was screaming for valuable input such as yours. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 2011-09-27 11:29:17 (+0200), Michael Kromer <mkromer@medozas.de> wrote: [...]
Another question: how ? If you want it to be binary compatible with SLES, you will obviously need to get ahold of the source RPMs of SLES. So you need a SLES subscription. Do you plan to just copy over the source RPMs of SLES (including the SPs and security updates), hack the artwork, and rebuild? [...]
Not having the many repositories in OBS build against Evergreen 11.1 or 11.2 is indeed an issue. But something that can be taken care of independently of your approach. Is it about "LTS" or is it about binary compatibility? Or both? If so, why do you want binary compatibility with SLES?
- No, I do not want to work "against" SUSE or anything like
This discussion has taken place already ~ 2 years ago. I took it up to discuss this matter with Gerald Pfeifer. The situation back then, and I don't think it has changed, is that SUSE makes a non negligible part of its income through the subscription-only licenses -- that is, just the software, without support. I don't have numbers, and I don't want to, nor would I get them ;), but if there is a free of charge, binary compatible clone of SLES out there, it could potentially hurt the income of SUSE (at least as far as SLES is concerned). Gerald made it very clear that, because of those reasons, SUSE would not support such an effort in any way, at all. They probably cannot prevent it, but you get the picture. So you might not want to "work against SUSE", but, effectively, you might actually do so. Personally, after that discussion and after reporting about it on the list, I opted out of that initiative because I don't want to risk a single layoff at SUSE because of something like that. I'm not saying you shouldn't, you do whatever you want, but you might want to consider what I wrote above. And maybe check back with some people (e.g. with Gerald) to have their opinion -- at least, as long as you don't want to "work against SUSE".
Well, without SUSE this would not work well. So why reuse their work without them having a financial retribution? You said yourself that the subscription-only licenses are really cheap.
look at CentOS - Does it really hurt RHEL? I don't think so,
Ha, you don't *think* so :) Look, we probably all believe that CentOS is very beneficial to Redhat. It certainly has been in the past, and people from Redhat have also been saying that off the record. *But* there is no proof whatsoever that it has been the case, or that it would be the case for an "open SLES clone". No proof, no numbers, nobody can tell. And, actually, nowadays, Redhat isn't really all that fond of CentOS anymore.
Why binary compatibility with SLES then ?
- Yes, I see this as lots of work. Please let me know if you are willing to help. ;)
Do you believe it is more work than Evergreen ? Or less ? Don't you think that, instead, contributing to Evergreen has at least the potential of creating much more synergies, as it is part of the openSUSE project, on the same infrastructure as the rest of the project (build.o.o) ? I know very well that the current situation of Evergreen is not all that great, because there are barely any people who are contributing to it (and kudos again to Wolfgang). Why would that be different with a fork of SLES ? Why not, instead, try to revigorate Evergreen and contribute there ? If you create a fork of SLES, you will not be able to use build.opensuse.org, and you probably won't be able to even _link to it. So how does that increase chances of having the packages that currently aren't built for Evergreen being built for that SLES fork ? cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
Sorry, but this is not true. Take SLES DVD2-images - there you are. We are talking here about OSS, how do you think CentOS did it? GPL clearly states that you somehow must deliver the sources.
Do you plan to just copy over the source RPMs of SLES (including the SPs and security updates), hack the artwork, and rebuild?
No, as said before: We need to check out the license of each and every package. This actually gives the resultset of what is possible to be used. Since most of it _is_ OSS, I (at least at the moment) don't see any regulatory problems. My intention is to start with SLES11SP1 Images and work upwards. As GPL clearly states that redistribution _must_ be done (in short), updates should not be an issue. But, yes I have some SLES subscriptions, so at the moment this is not the breaking point. The short term agenda would be: - Build up secondary OBS infrastructure - Clean rebuild (non-public for the initial work) of the packages including original artwork (For example original opie rpm-rebuild results in a compile error) - Replace all Artwork, Deep check all packages - Create ISO-Builder Process - And lots of other tasks (just writing the list)
Both.
If so, why do you want binary compatibility with SLES?
Fairly simple, if you as a system engineer want to install/upgrade/test something you traditionally test your stuff _somewhere_. _Why_ should somebody buy a SLES for such tasks? And why is it a bad idea to also be capable of using OBS SLES11-rpms on such a clone? Or let me turn this question: What is so bad about it?
I guess you are talking about the upgrade subscription, right? However, as GPL clearly states that you cannot charge anything for the Software itself, you actually pay for the "service around packaging, power, ethernet - simply infrastructure and update service".
Why should it? Would you just switch over to SLES? At least I wouldn't. Critical and business related systems ("production systems") should never run on such "only community-supported" OS, not even CentOS. Even Canonical provides professional support for Ubuntu - This lets them also be a viable solution - But Debian for example: Well _if_ you use Debian on production systems you traditionally have the qualified staff to handle the problem. A colleague of mine _is_ debian maintainer and I was suprised that in Etch 4.0 there was a _major_ bug with the openssl-lib in combination with perl. Bad stuff. For us not too bad, since he could get that upstream pretty fast. For customers: Have fun. With SLES and RH you have support, somebody on the phone or via mail, you have first class engineers to your availability, doesn't matter how deep you are in package "a", "b" or "c". This is the reason where I think that SLES is too cheap (just my thought). However it shouldn't be too much higher since RH offers free RHN which also gives you a brief overview of all systems managed (which can only be reconstructed with SUSE Manager (SUSE)~=Spacewalk (OSS)~=Satellite (RH)~=Red Hat Network (RHN). If I want a system to test software (before setting them up on production systems), binary compatibility is the winner. People wanting to redistribute a solid "LTS" variant of the distro they like would then probably also see SUSE more strategical. As I've been doing this business now for a while I can tell you: There are more people moving from SLES to RHEL than the other way round (And this somewhat hurts badly, really). (_Also_) one large reason is that there _is_ CentOS. Believe me, RH benefits from CentOS as well. And I guess (though I don't know) there could be a break-even on loss/profit because of it.
I can understand this point. However I'm open to any discussion with any SUSE employee in this topic. SUSE shall not give support on it - but now it comes: They _could_! This is something you also won't hear from RH officially, but there is a division at Red Hat which exactly does support CentOS as well ("Professional Services"). Believe it or not. I hope a former colleague of mine (now at RH) is also reading this list - He could confirm what I'm talking about. In fact, SUSE could even have higher rates for support of this one ("if you really need it") - so you could then upsell even better. To keep this short: I've been thinking a long time about this one (really, really, really did) - and all your thoughts have bugged me more than once as well.
Nor would I want to do any harm. But to be clear: We are talking OSS, SUSE also profits from developers around the world as well. SUSE Manager is in fact an upstream patched Spacewalk with SUSE extensions (a bit simple, but I guess you get the point...)
I clearly do. Gerald: I invite you also for a beer so we could also discuss this one... Nuremberg? Munich? You tell. Maybe cdegen is a good option as well.
As I've written: They _could_ have financial retribution, if they want to - maybe not for the updates, but very much likely for support (which should be more expensive of course) and professional implementations (consultants at the customer, etc.). Yes, they are. For server-systems you just want deployed somewhere. Customers are willing to pay, this is what I can say so far. You wouldn't get the hardcore gentoo/debian-fanatics - they live in their own tombstones (just kidding) - but if customers would realize if they would have to pay more in case of something _not_ working with _no direct_ support attribution (calls, tickets, etc., typical: you broke it - you fix it stuff) - they will see the value added to SLES and still buy it. It won't be much of a difference from openSUSE in that way.
look at CentOS - Does it really hurt RHEL? I don't think so,
Ha, you don't *think* so :)
Well, I'm sorry, I don't have my crystal ball with me right at the moment, so I really _can't_ foresee the future. ;)
Jup. Agree.
Well, why should they have a problem? http://linux.slashdot.org/comments.pl?sid=349751&cid=21234239 - ok - yes - 4 years ago - but what should have changed since then? RH is just like SUSE a company not just investing as also taking profit from the whole open source model. I agree: Nobody can tell for real, since we simply don't have the possibility to take a look at parallel timelines for specific events .... ;)
And, actually, nowadays, Redhat isn't really all that fond of CentOS anymore.
Well, as far as I've been working with them I can simply say: They tolerate each other very well, since (please read the link in terms of "Gateway drug"). They might not never communicate on their relationsship to each other deeply, but I guess tolerating each other (now over YEARS) is not a bad thing. _If_ RH would have had any problems with CentOS in the past I think they would have done something. In fact I never heard some RH associate speaking bad about CentOS either behind the doors or in front of a customer. And RH being also willing to support CentOS ("in extreme cases" or "more expensive" or "only through professional services") is something which is a good model.
As I've written: Appliances, Release Cycle, Perfect Test-Platform, and some other reasons as well.
(Re-)Building SLES "from scratch" is by far way more work. Especially when you want to provide ISO's with some installer, etc. You need to repackage everything, Evergreen is so far more "value added", not base.
("Sorry Wolfgang"): Take a look at Evergreen, if this would have been accepted that much, this wouldn't only be a one-man-show, and he would have received way more support for this.
see above.
hmmm... this one really freaks me out. Since when...? In OBS I can see Debian, Fedora, Red Hat, Mandriva, <you name it>. Why whould a natively compatible distro be handled so differently? - mike -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, 27 Sep 2011 20:46:53 +0200, Michael Kromer wrote:
I don't believe this is correct. To the best of my knowledge, the GPL doesn't prohibit charging for the software, but it states that the source must be freely available. The GPL doesn't have a lot (if anything) to say about cost, because "free" doesn't mean "as in beer" in the GPL. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, 27 Sep 2011 18:56:10 +0000, Jim Henderson wrote:
Seems I am correct on this. See: http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney (As well as the other questions present) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi Jim,
Indeed this is something I wasn't aware of - Thanks for pointing this out! - mike -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 2011-09-27 21:28:48 (+0200), Michael Kromer <mkromer@medozas.de> wrote:
Actually, the only obligation SUSE has with SLES there, to comply with the GPL and other open source licenses, is to make the source of updates available when you have a subscription. As you can't get ahold of the updates without a subscription. The key here is the updates, as the release in itself is available anyway. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
On Tue, 27 Sep 2011 21:32:52 +0200, Pascal Bleser wrote:
I don't think that's entirely true either, though - someone has to have a subscription, sure, but AFAIK the GPL doesn't permit SUSE from restricting the distribution of those updates or the source by a recipient of those packages. So, if I don't have a subscription to SLES but I know someone who does, they are free to distribute any GPL'ed software from their subscription to me if they want to. If the code is GPL'ed, then the binary and source can be redistributed by anyone who obtains it from SUSE. (I'm not a lawyer nor do I play one on TV, but that seems to be pretty plainly spelled out in the GPL - both v2 and v3) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 2011-09-27 19:39:28 (+0000), Jim Henderson <hendersj@gmail.com> wrote:
Yes, correct, that is what I meant to say, thanks for the patch :) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
On Tue, 27 Sep 2011 21:51:47 +0200, Pascal Bleser wrote:
No problem, Pascal. :) (I've never considered something like that a 'patch' before, cool way of thinking of it <g>) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Sep 27, 2011 at 3:00 PM, Jim Henderson <hendersj@gmail.com> wrote:
The key feature of GPL for this discussion is any buyer of SLES / updates, must have the ability to get the source. And that source must still have the GPL in place, so the recipient can do anything with it that they want. How useable that source is another question. ie. providing it on paper would satisfy the GPL as far as I know. Fortunately, I've not heard of any company trying to abuse the GPL like that. Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, 27 Sep 2011 15:33:01 -0400, Greg Freemyer wrote:
Sure, but my comment was specifically about the incorrect assertion that one cannot charge for GPL'ed software, only for the services around packaging, power, etc. That's categorically not true according to the GPL FAQ. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Sep 27, 2011 at 03:33:01PM -0400, Greg Freemyer wrote:
I have, believe me, they are out there, I have the proof of an obfuscated kernel driver that was sent to me as a printout a long time ago. Fortunatly, SUSE is not such a company. greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Full ACK. Well, why should SUSE - Providing src rpms also drills down support costs, as partners etc. have the possibility to rebuild/patch rpms also in SLES, which in return makes the distro better after all. Printing out all code of a few thousand of packages consisting of millions of lines of code would for sure not be a good idea in terms of "green IT" as well... And SUSE _is_ green as we all know ... :) - mike -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (10)
-
DenverD -
Greg Freemyer -
Greg KH -
jdd -
Jim Henderson -
Kim Leyendecker -
Markus Slopianka -
Michael Kromer -
Pascal Bleser -
Wolfgang Rosenauer