July 2010 - openSUSE Project - openSUSE Mailing Lists

[opensuse-project] openSUSE @ FrOSCon needs you
by Jan Weber 27 Jul '10

27 Jul '10

Hi all, as you might know on August 21st and 22nd the FrOSCon [0] takes place in St. Augustin (near Bonn) in Germany. We have a confirmed booth at FrOSCon and I am now looking for volunteers to man the booth! So if you have some free time and want to help promoting openSUSE at FrOSCon, drop me a note and add yourself to the wiki page [1]. So long, Jan [0] http://www.froscon.org/ [1] http://de.opensuse.org/Veranstaltungen/FrOSCon/2010 -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

1 0

[opensuse-project] ICECC / ICECREAM - Two input files?
by Karl Krach 26 Jul '10

26 Jul '10

Hello, I'm looking for the Icecream mailing list. I found many references to http://en.opensuse.org/Icecream - but it looks like as if this page is discontinued. My problem: I'm using Icecream with a toolchain generated by Buildroot. It's a GCC 4.4 which supports the --sysroot flag. When compiling with makefiles generated by qmake, Icecream builds always local because it detects "-isysroot /path/to/toolchain" as second source file: found another non option on command line. Two input files? This patch would solve this problem: --- icecc-0.9.4/client/arg.cpp 2009-04-30 14:35:23.000000000 +0200 +++ icecc-0.9.4-patched/client/arg.cpp 2010-07-26 08:42:23.000000000 +0200 @@ -249,7 +249,8 @@ || str_equal("-iwithprefix", a) || str_equal("-isystem", a) || str_equal("-iwithprefixbefore", a) - || str_equal("-idirafter", a) ) { + || str_equal("-idirafter", a) + || str_equal("-isysroot", a) ) { args.append(a, Arg_Local); /* skip next word, being option argument */ if (argv[i+1]) { How can I submit it? Best regards, Charly -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

3 2

[opensuse-project] How do I delete a directory from my repositories?
by Jim Henderson 25 Jul '10

25 Jul '10

I've spent a little time working with OBS today for a small project I'm working on in Studio, and I noticed that I have a repository for openSUSE 11.0 in my home project at: http://download.opensuse.org/repositories/home:/hendersj/ You can see an openSUSE_11.0 directory there - there's no packages in the structure under that, but I'd like to clear it out if it's possible (just to avoid any confusion). I don't have 11.0 (even the discontinued 11.0 repo) in my obs configuration - all I have is 11.2 in there. Can someone point me in the right direction? Thanks, Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

1 1

[opensuse-project] Strategy: comment on users and contributors
by Andreas Jaeger 24 Jul '10

24 Jul '10

During the openSUSE Strategy discussions, some questions were raised about users and contributors and their roles within our Community. I'd like to discuss and define these a bit in the context of our discussions. Community - users and contributors ================================== Community is often defined as a collection of people who interact together - but what does this mean concrete for the openSUSE project? I suggest to define the openSUSE community as an open community that includes everybody that likes to be part of it including users installing openSUSE on a system as well as contributors that shape the project. Still this large openSUSE community can be seens as a larger group of users and a smaller group of contributors. The users are an important part of the openSUSE ecosystem. They are a target and beneficiary of what we do in openSUSE and we also strive to reach out to our users to become contributors to the Project. This should be a virtuous circle - the more users we gain, the more our pool of contributors and contributions grow. And the more contributors the Project gains, the more users we gain. And in order to sustain that growth of users and contributors, we must ensure an environment that supports the needs of our contributors by providing them with the tools they need as well as delivering products that our users get excited about. Contribution to the openSUSE project ==================================== A lot has been discussed on what a contribution is and I'd like to highlight a few examples of contributions to the project. Let's start with the distribution first: A user downloads the openSUSE distribution from the Internet, buys a box, or gets the install media in some other way. If a problem is encountered, the user asks for help, e.g. via: * the openSUSE forums * the openSUSE IRC channels * via a social network like twitter, Identi.ca or Facebook * the openSUSE mailing lists * uses a search engine to see what others have said, this might bring him to any of the openSUSE wiki, forum, mail lists or archives I would expect that this new user receives positive answers from forums, IRC channels, social networks and mailing lists. This might be a friendly pointer (not a simple RTFM!) to specific sections of relevant documentation, a more appropriate place to ask or maybe an detailed answer to the concrete question. People helping this new user are contributing to the openSUSE Project. Users also become contributors by writing documentation, moderating discussions, administrating infrastructure, or by with translations existing documentations and openSUSE wiki pages. There are many other forms of contribution that do not require programming ability - for example openSUSE Ambassadors running booths or making presentations at conferences and local Linux user group meetings. Eventually, the user might download a new package from the openSUSE Build Service or report a bug using bugzilla. Obviously software developers are contributing to the community when their original and creative output is made especially for the openSUSE project, e.g. running on our infrastructure and improving the distribution through iterative testing/fixing, packaging FOSS software, integrating them into the openSUSE distribution, and coordinating with the upstream projects. Likewise, as innovations or improvements are made by developers, we spread the word of their efforts and successes through blogging, marketing, and other means, which then attracts even more users. The more users we attract, the more feedback is given to developers through conversations, bug reports, feature requests, and other venues. The large upstream OSS community is contributing with many packages, e.g. the Linux kernel, to the openSUSE project but not in the sense of a core contributor to the project - more as an "independent supplier" that rather than an openSUSE contributor. However, we extend an invitation to upstream developers to become openSUSE users and make it their platform of choice for developing and contributing both upstream and directly to the openSUSE Project. Growing Users and Contributors ============================== During the Strategy Team's discussions, we concluded that our primary goal at this time is to focus on increasing the number of contributors in our community by encouraging our users to grow into those roles and attracting contributors. To do that we know we must provide all with the tools and the ecosystem to "Have a lot of fun". And, by growing the contributor community we automatically support the goal of sparking that virtuous circle of sustained growth benefiting the entire community. Let me also emphasize that the above listed contributions is just a small set of examples. There are many more ways to contribute, and often we encounter fresh and new ideas from users who should be listened to, encouraged, mentored and grown into productive project contributors (where possible). Let us keep in mind that as a project we care about the whole diverse community - and the discussions have shown how diverse it can be - and I'd like to refer to our guiding principles: "We value choice. We accept and respect that there are different ways to work, different preferences for applications, environments, tools or interfaces and different goals of users and contributors. We value diversity and pluralism as a way of addressing the needs of a broad variety of people." What do you think? Is that a common ground? If yes, I'd like to add it the the collection of strategy pages and look forward to edits, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj(a){novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

12 14

[opensuse-project] Regarding codenames and colors
by Stephan Kleine 23 Jul '10

23 Jul '10

Hi guys, regarding the code names and colors discussion. Personally I'm just tired of having a "green" distro cause we are supposed to be "green". Also I liked coolos idea of code names that got drowned for known reasons. So here is my proposal: How about we use an animal as code name and its main colors as the distro colors for a release? This will give us enough room to play and select and as long as older themes still work noone should get harmed. An important part is that not only boot, but also KDM, GDM, OO & Gimp splash screens and so on should be easily exchangeable while maintaining a certain "corporate identity" which should also be adopted every now and then when it is necessary. Point being, if we get those things to adopt to certain colors "automatically" it shouldn't be that much work while choosing a nicely looking animal, it is, probably, pretty easy. E.g. we could use a Zebra for some stylish black and white theme or some exotic fish for some more colorful one or ... the choice is endless. The only important thing is that those themes shouldn't be "pressed" on anyone but it should be easy to revert to a previous one or .... What do you think? regards, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

8 23

[opensuse-project] Impovements in a mail list worflow
by Rajko M. 23 Jul '10

23 Jul '10

We often have to refer to some mail list article. Now we have to find article in a mail client, open and browse http://lists.opensuse.org to find that article and then copy link in our email. It is job measured in minutes for active lists. It would be very convenient to have list archive link added to the mail footer with existing links, or even instead of unsubscribe link. Such functionality is provided for forums users that access them via nntp as line in the footer: View this thread: <link to thread> In case of mail list archive that stores messages per month, threads at the end of the month are broken in 2 pieces, so reference to thread is not useful, but pointer to the article will be improvement. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

6 6

[opensuse-project] How to resurrect disappeared wiki pages?
by Michal Marek 22 Jul '10

22 Jul '10

Hi, I found that http://en-old.opensuse.org/Kernel_Git disappeared from the new wiki. Are there any guidelines where to put the old articles back? Other pages from http://old-en.opensuse.org/Category:Kernel are not found in the new wiki either :-(. Michal -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

2 1

[opensuse-project] openSUSE Strategy Discussion: another proposal
by Marcus Moeller 21 Jul '10

21 Jul '10

Hi all. As I did not take part in the strategy meeting, I want to add my proposal, here. openSUSE - #1 KDE distribution Statement Most Linux distributions rely on a (more or less customized) GNOME desktop as default environment. openSUSE's advantage has always been the great KDE integration (and now even defaults to KDE in the desktop environment selection dialog). We should focus on that and make openSUSE the best KDE based desktop distribution available. This is not meant to start another flamewar, nor to completely drop GNOME (of course there still could be community supported Spins available), it's just about our primary focus. We need to be excellent in the following * Create a visual unique desktop experience with KDE * Adopt the latest KDE technology early, but care about stability * Offer the best platform for QT/KDE AND Java developers * Integrate MeeGo (focus on QT) * Lobby for KDE We will try to do the following effectively * Deliver a build service for building distribution and applications * Provide best desktop experiences with KDE and MeeGo (focus on QT) * Integrate social service apps, bind to connect.openSUSE.org * Bugfixing * Testing * Improving KDE upstream * Collaboration with other Linux distros As project, we will not focus on the following anymore * other desktop environments -- Greets Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

37 318

[opensuse-project] Re: openSUSE versioning scheme
by Per Jessen 21 Jul '10

21 Jul '10

Vincent Untz wrote: > (I'm setting Mail-Followup-To to opensuse-project, since that's where > this discussion should happen, but I agree we might want to wait for > the end of the strategy discussion) > > Le samedi 03 juillet 2010, à 09:10 +0200, Martin Schlander a écrit : >> Fredag den 2. juli 2010 17:05:06 skrev Andreas Jaeger: >> > On Friday 02 July 2010 16:56:04 Thomas Schmidt wrote: >> > > Shouldn't we call this 12.0? >> > > Reassigning the features afterwards would be additional work. >> > >> > Naming of the next release is a separate discussion we might have. >> > I'm opposed to both 11.4 and 12.0 and look forward to great >> > proposals, >> >> Let's not get too creative here. No funky codenames! :-) > > We actually have code names, and it's the shades of greens. 11.3 is > Teal. We just don't advertize this -- yet. (I think we should). The codenames are visible on the console. Personally I think codenames ought to remain internal, project-only - like today, but _perhaps_ with a bit more awareness/usage. I really don't like the hip Ubuntu naming and I'd have to use a dictionary to find out what "teal" is. (same goes for most of the Ubuntu names). >> We should go for a simple numbering scheme, that doesn't cause the >> confusion that the old one has (a lot of people give different >> meanings to the numbers, even though they don't mean a thing - other >> than of course x.1 meaning "unusually buggy"). >> >> Either do it the Fedora way. openSUSE 12, 13, 14 etc. >> >> Or the Mandriva way 2011.0, 2011.1, 2012.0 etc. > > (Or the Ubuntu way, except that it doesn't work well with the next > version which would be 11.03: 11.03, 11.12, 12.07) What is wrong with the existing scheme? Two things that come to mind: 1) it's just a continuation of the SuSE Linux numbering 2) there's no implied meaning of '.x' I propose we name the next openSUSE "openSUSE 1.0". Wrt 2), I don't know if we really need/want an implied meaning of the '.x', but maybe we can come up with an idea in the context of strategy. (one thought: even = desktop release, odd = server release?) > One technical side of the decision that was pointed out in an earlier > discussion is that we want to keep some suse_version compatibility. > That means we still need to have, somehow, 11.3 < $nextversion. That did occur to me, but I'm unaware of the details. -- Per Jessen, Zürich (25.1°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

5 7

[opensuse-project] Possible strategy discussion topic: Education and Training
by Jim Henderson 21 Jul '10

21 Jul '10

I've been kicking this around for a little bit now in my own head, and I'd like to propose that the project develop a strategy around user education and training. For those who don't know, in my "day job", I work for Novell's Technical Training department as the testing program manager. In particular, I have responsibility for the business end of the practicum exam delivery (and if you want to talk about that with me, feel free to contact me off- list, I'm always happy to talk to people about their exam experiences, even if I can't get into specific details for their exam). In my role, I also am involved in technical certification, and work closely with people who develop training (I used to be a trainer myself for eDirectory, and developed the training materials to meet objectives we had for that product) as well as being involved to some extent in developing the next generation of training delivery. I was intrigued by an article in this month's Linux Format about Ubuntu's "Lernid" training system. It sounds like that project has a plan of sorts for training users on using their system, and this seems to me to be a way in which we could grow the community from which we are looking to draw contributors. In the forums, we've also had a couple of people express that some training on openSUSE would be very helpful and useful for them (either personally or to help people they knew learn about Linux and start using it). The way I see it, we could break down training into a few classifications: 1. End-user training 2. Contributor training (for example, how to write effective bugs, code style conventions, things like that) 3. Community training (where to ask what, what to expect, that sort of thing). In items 2 & 3, a lot of that content is in the wiki already - I see the largest opportunity as being #1. There may be a loose collection of things that fit in there as well (such as the howtos for configuring certain video cards), but from a training perspective, some structure and flow between the topics (along with analysis of how the topics can/should flow from one to another) is something that's I think is missing (I may be wrong and just haven't looked in the right places). What I'd like is for the project team to consider that end-user education (in particular) is something that could help us attract more users and help them achieve a more comprehensive view of how to use openSUSE more effectively. Things like skills migration from Windows to openSUSE would be something I see as key; one forum user put it as "people learn by making connections to that which they already know"; I see that in my official job role as well - the students who are most successful are the ones who can associate what they're learning with something they already know - even if it's not a direct 1:1 mapping. Thoughts? Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

11 23