Hi
Those days I am reading in the wiki about KIWI
(http://en.opensuse.org/Portal:KIWI) and I am very excited with
it,since there are many things I can make with it but from what I've
read all instructions are referred to openSUSE 11.1. Does anyone knows
if there are any changes I should know about before I start working
with it? I am also planning to make a presentation of it on an event,
since I believe it would interest a lot of people, so I need to be
sure about it.
Thanks
Kostas 'Warlordfff' Koudaras
--
http://opensuse.grhttp://amb.opensuse.grhttp://own.opensuse.grhttp://warlordfff.tk
me I am not me
-------
Time travel is possible, you just need to know the right aliens
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Oh yeah, here is *that* topic again ;)
(and make sure to read Greg's post about Tumbleweed as well, as it is a
similar kind of project, even though they are diametrically opposed ;D)
Wolfgang Rosenauer (our local firefox/mozilla hero) made an interesting
post on his blog, in case you're not following
http://planet.opensuse.org (shame on you!):
http://www.rosenauer.org/blog/2010/11/30/community-powered-long-term-suppor…
Stop here. Please read that post.
Done?
OK, here are my 0.02EUR to that.
The idea of an "openSUSE LTS" and/or "openSLES" aren't new indeed, and I
suppose that most can remember the discussions around it some time ago.
And from here on, by "LTS", I (and Wolfgang) mean "longer than 18
months" ;)
There are basically two options on how to achieve that, from a technical
perspective:
1) an LTS based on openSUSE
2) a rebranded SLES
With "openSUSE LTS", the idea is, as Wolfgang already explained in his
blog post, to pick up an openSUSE release when Novell (and the
community) stops supporting it, when it goes EOL, which is after 18
months as of now.
The effort can be a bit daunting, as it means keeping track of security
vulnerabilities, backport fixes for those, or possibly upgrade to a
newer version when backporting is too much work (e.g. Firefox).
That's pretty much what is being done by the SUSE Security team and us
(the community) during the lifetime of a release. But for longer and,
hence, it is also more work (the older the packages, the more work it is
to backport).
The infrastructure provided on build.opensuse.org would certainly come
in very handy. Especially when it'll have patch support :)
"openSLES" is a totally different beast, as it means using the source
packages of a SLES release and rebrand them. The obvious advantage is
that it would most presumably be less work, as the hard work will
already have been done by the Security team and the staff at Novell that
does the SLES maintenance.
But it would also be a rogue project: Novell cannot legally prevent
anyone from doing just that as, albeit you do need a subscription to
have access to them, the updates are also available as source packages.
Nevertheless, it is not something Novell would like to see happening as
they (or at least a few people I've talked to about it) believe it could
be hurting their SLES business. While I don't personally share that
opinion, and before 100 people comment negatively on this, it is a
*fact* that no one can give any assurance or hard proof that it will not
hurt the SLES business.
Yes, we all know about CentOS, and a few know a few things about CentOS
and Redhat I won't be citing in public (but let's say that some people
who might or might not be working for Redhat have or haven't said that
they believe that CentOS is effectively helping them spreading RHEL, but
only off the record. or not.). But there are no hard facts or numbers to
give any proof or guarantee that it would be the same with an "openSLES".
And, personally, the last thing I'd want is people from Novell/SUSE
losing their job because of that.
Furthermore, Novell would clearly not be supportive of such a move, and
it's not sure whether we would be able to use resources such as
build.o.o for it.
Long story short, I personally believe that the only viable option is
"openSUSE LTS", but it does bring some technical challenges which
require a certain number of committed contributors working on the
maintenance.
I really concur with Wolfgang's idea/proposal to start off with a
server-oriented subset/core of openSUSE and try to keep that maintained
for half a year or more, and learn from that experience to see whether
we can realistically take on doing that for a longer period of time.
Ideas, (constructive) criticism? :)
(and thanks for reading so far, I know my mails are way too long)
cheers
--
-o) Pascal Bleser <pascal.bleser(a)opensuse.org>
/\\ http://opensuse.org -- I took the green pill
_\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
Hi,
there was a lot of discussion on that list about the proposal for an LTS
effort or openSLE. There are pros and cons for both and those were
stated in many mails now.
So please let me sum up once again ;-)
I mentioned somewhere in the beginning that there was so much talk and
no action and I didn't want to repeat that.
I'm going to start now with the following including the risk of failure:
A community (we'll see) supported longer lifetime openSUSE 11.1.
No, I don't think it needs an extra name as it still is 11.1. But I
think I like "Evergreen" for now where that means that the "Project
Evergreen" is responsible for the maintenance of that thing.
Also note that I'm not against an openSLE approach and in case it
happens at some point we'll see what happens with this one. I already
mentioned that in the end I would be in favour to it and I also invite
people to discuss that further including myself.
But for now I want something to happen and I rather would like to fail
instead of talking about something to death.
I've already thought about technical details and how to utilize the OBS
@ build.opensuse.org. There are some issues and we probably can only
start with some limitations.
What I really want to get now is a feeling if (and how many) people are
willing to help.
So everyone who is interested in helping (does not matter how) is
invited to subscribe to
http://lists.rosenauer.org/mailman/listinfo/evergreen
(as I don't know if it really takes off and naming and stuff and it was
much easier for me I set this up on my own listserver. At some point it
might get transitioned to the openSUSE project, though.)
We can discuss all the glory technical details there.
Wolfgang
wondering if people will show up there
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
The Association of Greek Users and Friends of FS/OSS and the Greek
openSUSE Community invite you all to the presentation of the openSUSE
Project.
The presentation will have 4 parts:
-What is the openSUSE Project?
-Presentation of the Greek openSUSE Community and how to become a part of it.
-Presentation of the Revolutionary OBS (Building System).
-Installation of the openSUSE Distribution.
Come to meet the openSUSE Project and the Greek openSUSE Community.
The presentation will take place on Saturday December 18th, 2010,
17.00 at the Computer Lab of the Economic Science Department of
University of Macedonia, Thessaloniki, Greece
Kostas 'Warlordfff' Koudaras
--
http://opensuse.grhttp://amb.opensuse.grhttp://own.opensuse.grhttp://warlordfff.tk
me I am not me
-------
Time travel is possible, you just need to know the right aliens
On Mon, Dec 13, 2010 at 01:30:52PM -0500, Greg Freemyer wrote:
> On Mon, Dec 13, 2010 at 1:09 PM, Greg KH <gregkh(a)suse.de> wrote:
>
> > On Mon, Dec 13, 2010 at 05:49:56PM +0100, Marcus Meissner wrote:
> > > As some 2.6.27.stable support is done by the outside still (not Greg,
> > > but someone else), the critical things at least should be able to get
> > > picked up.
> >
> > Note, those .27-longterm kernel releases will be much more infrequent
> > than I was doing (if that could be possible), so anyone wishing to run
> > an "enterprise" distro on .27 will have to be responsible for keeping up
> > with the security issues on their own as they will end up being more
> > frequent than the .27-longterm releases will be.
> >
> > good luck,
> >
> > greg k-h
> >
>
> I didn't realize SLES made major kernel version updates like that.
This was one of the first times in a long time it did (we did it a long
time ago in 2.4 days as well.)
> Am I right in understanding Redhat keeps the same basic kernel for the full
> LTS period? (ie. Aren't they planning to support 2.6.18 in Redhat 5 for a
> few more years?)
I don't know, why not ask them?
> Timely security updates for the LTS kernel seems critical to me. (ie. If I
> don't need security updates, I can just leave any old openSUSE release in
> place for years.)
>
> Is any LTS distro supporting 2.6.27 (opensuse 11.1) or 2.6.31 (opensuse
> 11.2) for the long-term?
Not that I know of. All of the major "enterprise" distros agreed to
pick the .32 kernel to base their products on, and did so (RHEL6,
SLE11SP1, Debian, Ubuntu LTS, Oracle Unbreakable Linux, etc.) to try to
reduce the ammount of churn and support they had to individually do, and
instead, place it all on me :)
thanks,
greg k-h
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
On Sun, Dec 12, 2010 at 10:16 PM, Rajko M. <rmatov101(a)charter.net> wrote:
> On Sunday, December 12, 2010 12:36:09 pm Kim Leyendecker wrote:
>> Let me ask a technical question:
>>
>> Which kernel version will be supported?
>
> That was another comment on this discussion; a lot of words about names and
> none tried to start discuss for instance how to revive 11.1 as a test case
> (kernel is 2.6.27). It is just out of support, so it can be easy to continue
> adding security patches.
>
> I would like to see some action plan what one has to do to keep 11.1 alive for
> another 6 months as a test is whole idea feasible.
>
> In my humble opinion, better idea would be to think how to make upgrade path
> bullet proof, so that one has no fear what will happen on next change.
> That will help desktop and server use cases with single effort.
>
> --
> Regards,
> Rajko
My gut feeling is the answer is right (by chance?), but we have the
logic backwards.
The LTS project should not pick a release (11.1) and then use its
kernel for the long term support regardless.
I would think the kernel's supported for other LTS projects (SLES,
SLED, Redhat, etc.) should be identified, and then a openSUSE release
that uses a LTS kernel should be picked for LTS designation.
Backporting kernel security patches is a lot of work.
Also, a lot of LTS kernels get not just security updates, but
functional updates. ie. Redhat has back-ported ext4 to 2.6.18 I
believe so that older Redhat installs can use ext4. Redhat 6 is
2.6.32 based, so from a pure Redhat perspective 2.6.18 or 2.6.32 would
be the best kernels to drive a LTS release.
Fortunately SLES 11 is using the 2.6.27 kernel, so we know Novell will
be back-porting security patches to it for 3 more years (or more).
Does Novell also back-port new functionalities like Redhat does?
Regardless since both opensuse 11.1 and SLES 11 use the 2.6.27 kernel,
that kernel makes an excellent choice indeed.
Is there any reason for the openSUSE 11.1 LTS release to not
explicitly use the kernel from SLES 11? That way when patches come
out, etc. openSUSE LTS can leverage at least that one very important
security support from Novell.
Greg
--
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
CNN/TruTV Aired Forensic Imaging Demo -
http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrie…
The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
On Sat, Dec 11, 2010 at 7:54 AM, Kim Leyendecker
<kimleyendecker(a)hotmail.de> wrote:
> In the most points, I agree with you. But How shall we name it during the
> discussion on the Mailing list?
Given Tumbleweed is used for a rolling upgrade release, Cactus,
Redwood, Sequoia all sound good to me for a LTS release, but a
European may not grasp the last 2 very readily.
Even more long-lived and desert specific: Joshua Tree or Yucca.
http://en.wikipedia.org/wiki/Yucca_brevifolia
fyi: all of the above but the cactus can live thousands of years, but
they may be restricted to the American West, so not good international
names.
Greg
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Hi there,
I have a macbook pro aluminium crap on which I run opensuse... Due to my usage
the poor thing it is exposed to scratches... my wrist watch mainly... As I
have no intention of getting rid of the mac, the watch or the habit, I decided
to get a skin to protect the mac...
This is where I got an idea... It seems that there are plenty of websites that
offer the possibility to skin your laptop.
I was wondering if at project level we can "associate" in a way with one of
them... The project provides official artwork to skin the device, we the
supporters can buy it, for each bought the project gets back few shekels...
What do you think about? would be a good way to increase visibility of the
project and maybe get some money for it too.
regards,
Alin
--
I force myself to contradict myself in order to avoid conforming to my own
taste. -- Marcel Duchamp
Without Questions there are no Answers!
_____________________________________________________________________
Alin Marin ELENA
Advanced Molecular Simulation Research Laboratory
School of Physics, University College Dublin
----
Ardionsamblú Móilíneach Saotharlann Taighde
Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath
-----------------------------------------------------------------------------------
Address:
Room 318, UCD Engineering and Material Science Centre
University College Dublin
Belfield, Dublin 4, Ireland
-----------------------------------------------------------------------------------
http://alin.elenaworld.net
alin.elena(a)ucdconnect.ie, alinm.elena(a)gmail.com
______________________________________________________________________
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Hi all!
I bet most of you have heard of this website, news.opensuse.org. Sometimes
people post random vaguely openSUSE-related stuff there. Now I thought it
would be fun to create a team around that - work a bit more structured :D
People with the rights to post there now post whatever they like, whenever
they like. Not that that is always a bad thing, but having a little more
oversight to guarantee quality and timing would be good (eg 3 articles on one
day then nothing for 3 days sucks; and sometimes there is some Germanglish in
there too).
It ain't hard - if you are currently writing there every now and then you want
to be on the team. If you are willing and able to edit posts every now and
then - you want to be on the team.
If you want to WRITE for news, you don't HAVE to be on the team - you can just
submit stuff and the editors will edit and publish it.
So who's up for this? And I expect AJ and Henne at the very least to
volunteer, Sascha, you too :D I'm going for everyone who has contributed a lot
of stories to News.o.o to be on the team. Or those who can and want to
write... So Helen? You!
Cheers,
Jos
Hi all,
There's been many discussions over the past years about a "rolling
update" version of openSUSE on lots of different mailing lists and in
person a different conferences.
So the time now is to stop talking about it, and actually trying to do
it :)
So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling
updated version of openSUSE containing the latest "stable" versions of
packages for people to use.
To help clear up any questions about this, here are some answers to ones
that I have heard a lot recently when discussing this:
Q: How does this differ from Factory and the recently announced
Factory-Tested?
A: Factory always contains the bleeding edge versions of our packages
that the maintainers have created. Sometimes these packages don't
work well together and cause the machine to fail to boot (Hence the
need for Factory-Tested). Tumbleweed will contain "stable" versions
of these latest packages that have been deemed to "work" properly.
A good example of how Tumbleweed is different from Factory would be
to look at the kernel package today in Factory. It is 2.6.37-rc as
the goal is to have the final 2.6.37 release in the next 11.4
release. But, it is still under active development and not
recommended for some people who don't like reporting kernel bugs.
For this reason, Tumbleweed would track the stable kernel releases,
in this case, it would stay at 2.6.36 until the upstream kernel is
released in a "stable" format.
Q: What types of packages would be updated in Tumbleweed?
A: What do you want to see updated? Seriously, this is something that
anyone can request their packages to be updated. We will rely on the
maintainers of the packages to be the ones determining the "stable"
versions to be pushed into Tumbleweed.
This can help with projects that don't always line up their release
dates with existing openSUSE releases. If (for example) GNOME 3.0
comes out and is deemed "stable" 1 month after a openSUSE happens,
users would not have to wait 6 more months to use it in a semi-stable
form.
Q: But wait, can't you do this today on your own by just adding a bunch
of different repos to zypper and relying on that?
A: Yes, you can, but if my zypper repo list is any example, that gets
unwieldy (I seem to average about 12 per machine), and we don't want
to have every user be forced to do this on their own. Tumbleweed
would provide a single place for users that want to be on the
semi-bleeding edge of packages, to have it all in one place.
I'd like to do this "for real" after 11.4 is out, just due to the amount
of time it will take to get the workflow down properly, and due to some
other time constraints on my plate at the moment. I anticipate trying
this out to start with based on 11.3 but I don't guarantee it all
working properly right at the moment.
So, any thoughts, ideas, objections?
thanks,
greg k-h
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
