Hi all,
April 16-17 in Antwerp, Belgium, the Linux Open Administration Days will
take place. This free event offers a chance for LPI certification as
well as meeting and talking to linux sysadmins. There is a call for
presentations here: http://www.loadays.org/content/call-presentations
If you want to go and give a talk there about openSUSE tech - that's be
awesome. If you can't afford to go there due to travel or hotel costs,
let me know, we might be able to work something out ;-)
cheers,
Jos
Hello,
I'm applying at this year's GSoC to work on the bug reporting tool [0]. I've
made my list of features to implement but, before I finalized my proposal,
I thought it would be a good idea to ask you, guys:
Is there's any particular feature that you wish to find in the openSUSE bug
reporting tool?
Thank you!
Mihnea Dobrescu-Balaur
[0] http://en.opensuse.org/openSUSE:GSOC_2011_Ideas#Bug_reporting_tool_for_open…
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
We had a couple of discussions in the past about how to improve the openSUSE
trademark guidelines (see e.g.
http://en.opensuse.org/openSUSE:Trademark_guidelines or
https://features.opensuse.org/311039). One of the main issues with the current
guidelines is that it's very strict about derivatives, and doesn't easily
allow people using openSUSE as a base for their own systems, to keep a visible
association with openSUSE.
So attached is a proposal how to adapt the trademark guidelines and provide a
better solution to this issue. It also contains a few smaller clarifications.
It's based on the input I was able to gather from the Wiki, openFATE, mailing
lists and some personal feedback. It's a draft, so feedback is welcome.
The central change is to allow people to create variants of openSUSE and use a
"Based on openSUSE" branding under more liberal conditions than now. We would
provide a specific branding for that, which keeps the relation to openSUSE,
but is done in a way to not be confused with the branding of the official
openSUSE distribution. Technically this would be a set of branding packages,
which can be used instead of the default branding of the official
distribution.
Please let me know, if there is additional feedback on the proposed changes,
so we can incorporate that, and then move forward with getting the needed
approvals to officially adopt the improved guidelines. In parallel to that we
can look into doing the proposed branding packages.
Attached is the proposed text for the revised guidelines, and the diff to the
current official version.
--
Cornelius Schumacher <cschum(a)suse.de>
Hello-
I have put together a simple search interface to opensuse.org that uses
Google CSE by default but allows for submissions to application specific
webforms. You can find it here:
http://search.opensuse.org/
Found a bug? Want to contribute? Fork it on gitorious.org:
http://gitorious.org/search-opensuse-org/search-opensuse-org
I would like to thank Marcus Rückert and Pascal Bleser for their help.
Have Fun,
Brandon
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Hi all,
I am writing my proposal here before uploading to the gsoc-melange
portal , please do let me know how i can further refine it:
Title: spec-cleaner redesign to make it modular and easy to extend.
Abstract:
RPM packaging is done using a build recipe , the "spec file". Spec
file authoring has been done for a very long time.
As the distribution moves to newer releases of rpm, the old spec files
(and newer ones) must be checked to make sure they use
newer macros and better spec authoring practices.
The project aims to facilitate this by further improving the
spec-cleaner project with a spec file parser, and an xml based
extension
system (to add more cleaning recipes in the future).
Detailed Description:
Background:
The project is a simple spec file checker and cleaner. The code goes
over all available spec files looking for common spec authoring errors
and replaces them
with more readable and correct code.
As opensuse moves to newer versions of rpm, older macros may be
deprecated , some shorthand used in earlier versions of the spec file
may break with newer rpmbuild.
It is not possible to manually look at each spec file and modify them.
This project aims to perform a bunch of the checking and modification
task automatically leaving the packager to look for only subtle
details, there by greatly reducing his/her workload.
Use Cases:
This project will mainly be used by the packagers (actors).
When opensuse moves to newer releases the packagers run the
spec-cleaner through all their spec files.
Spec-cleaner reports any errors along with changes made to files.
The packager can then run tests on the modified spec files to make
sure nothing breaks. He/she then rpmbuilds from the spec-files and
corrects small errors if any to make
the spec file run with newer versions of rpm.
Benefits:
The packager's time looking for common coding errors is greatly reduced.
Specification changes between different version of rpms is taken care
of automatically.
Caveats:
This is an automatic code checker and cleaner. It will not be able to
look for hacks that the packager might have employed to package a
particular software. In some cases it might regard the hack as a bad
coding practice. The packager must look for these manually and apply
necessary corrections.
Technical Details:
The Project would be divided into 3 parts:
Part 1: Read existing code and evaluate how best to modularize it. Run
tests on existing code to make sure the working and the
caveats are well understood.
Part 2: Implement the changes:
Write a spec file parser
Having done a preliminary search for spec file parsers , i
have not found any.
I have looked at python-rpm and its more of a package to
work with rpm packages than spec files, so there arises a need for
a generic spec file parser.
python-rpm and rpm in general contains a specific module
called "rpmSpecParse()" which could be isolated and used as a
parser for the cleaner, this needs further looking into.
Come up with a XML schema which is easy to understand and
easy to extend.
Adding new clean-up recipes is not very semantically
organized. A simple XML file wrapping new cleaning recipes in
appropriate tags would be more appropriate.
The rough markup could be ,
<recipe>
<rpm version>
<macro affected>
<regexp>
</regexp>
<replace with>
</replace with>
</macro affected>
</rpm version>
</recipe>
Move portions of current spec-cleaner code that are hard
coded , into separate configuration files so that they can be
modified without touching the code and also have more
semantically organized.
Part 3:
Extend available test cases and write a more if time permits.
Write documentation / augment the code written with doxygen headers.
Why me:
I have used python extensively in my projects (reference
https://github.com/face-rec-mvit/Code_PyRec )
also i am working on converting IPS (opensolaris) binary packages to
RPM, for belenix.org (here we use rpm5)
so i have a fair understanding of how the spec file is authored and
what are the available macros etc.
Also , from past projects i have worked on. I have learnt (the hardway
:( ) that "shipping" of the project must be a feature and
i will follow the same in the current spec-cleaner project and all
future projects.
Contact Information:
IRC nick: gancient (on most irc channels , freenode ,oftc)
email: kunal.t2(a)gmail.com
IM : kunal.t2 (on gtalk)
--
regards
-------
Kunal Ghosh
Dept of Computer Sc. & Engineering.
Sir MVIT
Bangalore,India
permalink: member.acm.org/~kunal.t2Blog:kunalghosh.wordpress.comWebsite:www.kunalghosh.net46.net
--
regards
-------
Kunal Ghosh
Dept of Computer Sc. & Engineering.
Sir MVIT
Bangalore,India
permalink: member.acm.org/~kunal.t2Blog:kunalghosh.wordpress.comWebsite:www.kunalghosh.net46.net
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Dear Geeckos!
This is for everyone who´s interested and want to do it. If so please
mail me (kimleyendecker(a)hotmail.de) and answer the questions. I will
publish the interviews later ;)
Questions:
*What´s your releationship with openSUSE?
*Since when you´re using openSUSE?
*Do you used any other distros before or beside openSUSE? If so, which
distros?
*What´s your favourite open source tool?
*Why are you using openSUSE? And why are you contribute to the openSUSE
project?
If you want so, you can add something about yourself or your other
projects/hobbies or just a little greeting to your wife/husband
girl/boyfriend or to a person you want to greet ;)
I will publish the interviews between 26th April and 1th May on the
Ambassador-List under the GNU Free Document License v1.3 and also on my
blog. If the interviews published, I beg you to spread them over
Facebook and Twitter or any other social network you have.
*Why that all?*
Because this is a nice thing for everyone outside the project, to learn
about the project members and the people who take care of their distro.
It also maybe motivate people to contribute to openSUSE and open source
projects as well, because they see who wonderful you all are :) and
maybe get some new paragons :)
thanks
--
Kim Leyendecker (kimleyendecker(a)hotmail.de)
openSUSE Ambassador
http://www.opensuse.org
Have you tried SUSE Studio? Need to create a Live CD, an app you want
to package and distribute , or create your own linux distro. Give SUSE
Studio a try. www.susestudio.com.
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Hi All
SaX3 is a GSoC 2011 project. I have applied for it. So in order to
strengthen my proposal I need some help from you guys. So if you can
help me.
During my project, I would like to focus on these hardware components.
1. Monitors / Graphic Cards
2. Keyboard
3. Mouse
4. Touchpad
What I would like to know is how SaX2 etc helped you in crisis
situations. All suggestions are highly valuable to me.
--
Regards
Manu Gupta
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Hi,
I'd like to work on the improvement of the Suse Studio command line
client(ssc) idea for GSOC this year. I've gone through the current ssc
code but found no documentation on it. Is there someone here I can
talk to who has worked on it and would know what is lacking. It would
help me formulate a detailed project proposal.
As I see it I'd first write a wrapper for the suse studio
api(http://susestudio.com/help/api/v1) and a command like client to
use the wrapper. It would be a good idea to separate the two so that
the wrapper can be used programatically as well.
Let me know what you think.
Thanks.
--
Ratan Sebastian
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
On Wed, Mar 30, 2011 at 10:51 PM, Manu Gupta <manugupt1(a)gmail.com> wrote:
> Hi All
>
> SaX3 is a GSoC 2011 project. I have applied for it. So in order to
> strengthen my proposal I need some help from you guys. So if you can
> help me.
Excellent idea! One of my most common usages for sax2 was something
like "sax2 -r -m 0=fbdev" whenever I'd bork fglrx. A few releases
ago, when I had a radeon 200m, the radeon module didn't work at all,
so it used to be a hair simpler to use sax to switch modules for me.
Making sax3 as much cli-oriented as well as the sax3 gui would help.
On Thu, Mar 31, 2011 at 11:00 AM, Christian Boltz <opensuse(a)cboltz.de> wrote:
> And in general: SaX should write out only the config parts that are
> needed/wanted by the user, not a complete xorg.conf. So if someone only
> changes the keyboard layout, SaX should only generate a configuration
> sniplet for the keyboard.
Agreed, however I think sax3 should use the xorg.conf.d, splitting the
sections up in to files, and not making one big nasty xorg.conf like
sax2 did.
As crazy as the question might sound, would it be possible to merge
xrandr with sax3? So for example, if the user asks for a change that
can be done with KMS, to do the change immediately (if the user
agrees) and/or to write it to the xorg.conf.d at the same time? That
way there'd be just one central place to go to for playing around with
monitors?
Accompanying sax3, there'd be a yast-sax3 module, right (this would
benefit new users, primarly), and it would be re-integrated in to the
non-automatic configuration during the installation process?
Zack Buhman
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Hello!
I have already posted my ideas for this GSoC and a little bit about me
(http://lists.opensuse.org/opensuse-project/2011-03/msg00459.html)
I looked at the Smolt code more closely and have submitted the proposal
on GSoC site. I want to repeat my proposal to discuss it here.
I'll be very happy to your suggestions and comments!
Br, Max Usachev
-----------------------------------------------
Title
GTK+ client for smolt
Abstract
The goal of this GSoC project is to create program architecture which
supports two or more independent UIs and redesign current codebase using
this architecture. Implement GTK UI for Smolt and adapt current QT-based
UI for new architecture. It's necessary to refactor and improve current
codebase to get better perfomance and code style. I'm also going to
implement some important and necessary wishes from Smolt wish list. The
proposal is based on
http://en.opensuse.org/openSUSE:GSOC_2011_Ideas#GTK.2B_client_for_smolt.
Detailed Description
Background
Smolt is a project for gathering hardware information from computers
running Linux. Currently smolt-gui is written in PyQt and it's difficult
to add this client to GNOME installation of openSUSE. So it's definitely
important to have a GNOME integration to ship on the default install.
It's also important to bring new features, which users proposed (Smolt
wishlist). There is a separate request in openFATE for implementing GTK
smolt client: https://features.opensuse.org/310490.
Use Cases
Use graphical version of Smolt client with native GNOME UI.
Benefits
The biggest advantage of this project is that openSUSE will get native
Smolt client for GNOME desktop environment.Users, who use Gnome
environment will get native Smolt client. Smolt client will be
redesigned and will get good program architecture, clean code and new
features (from Smolt wish list).
Caveats
The most difficult task from my point of view will be to design support
of multiple UI toolkits. Smolt was designed and developed as QT
application, so some work will be required to make it to support QT and
GTK UIs. However I have skills in adapting Qt-based UI to multi UI
architecture and I'm sure that I can do this task.
Technical Details
The project tasks can be devided into 4 parts:
1) Analizing current codebase and choose the best solution for new
program architecture. The first ideas that come to my mind is use
factory pattern to generate UI instances and maybe modified MVC pattern
as program architecture. We can use factory pattern for all widgets or
factory only for general UI. For example:
"""
from factory import ui_factory
ui = ui_factory(args)
ui.run()
"""
All logic about creating necessary UI placed in factory module and
returns suitable UI depending on desktop environment. The good idea it
to move each UI to separate module, as I did in 'Mnemosyne for Maemo':
qt_ui, gtk_ui. My proposals about starting the program: smolt-gui -u
gtk|qt, something like that.
2) Adapting current QT-based UI to new program architecture. It's very
important task, because while implementing some new features we must not
forget about old features. I think it will not take much time, because
current codebase looks very clear and understandable. It's necessary to
move all Qt related code to qt_ui package and some helpful UI functions
in qt_ui/utils.py module.
3) Writing tests. It's necessary part of the task, because these test
will help while implementing GTK UI and also cover most part of
exisiting code. I'm going to refactor some modules and add new features,
so, the test are vital to prevent code breaking.
4) Implementing GTK-based UI. It's very important and the biggest part
of the task. We should decide, will new UI be looks the same as Qt UI or
not. If we decide to change UI, we should also take time for UI design
process. Anyway, I think we should take as a basis current Qt UI.
5) Refactoring the code and add new features accroding to wish list.
There are many parts of the code, which we can improve. For example, the
gate.py module. It't better to implement the _Gate class as singleton
(there are some ideas about it:
http://stackoverflow.com/questions/42558/python-and-the-singleton-pattern)
and remove Gate function. It's necessary to use Pylint and pep8 checker
to catch invisible errors and clean the code and make it beautiful and
correct.
Why Me
I've been programming in Python for 4 years already. I have developed
many applications - scripts, services, parsers, web applications, but
most of them are GUI programs based on PyGTK. Also I have good skills in
UI designing and vast knowledge in architecture of GUI programs. I've
learnt a lot about porting Qt-based applications to PyGTK, when I was
porting PyQt application to Maemo platform, during my previous GSoC
project. I use Linux and know it very well. I am sure that I am the best
candidate for this project, because my skills very suitable for this
project and I have good theoretical and practical knowledges and strong
ambitions.
Contact Information
Mail: maxusachev(a)gmail.com
Jabber: maxusachev(a)gmail.com
Skype: maxusachev
ICQ: 468893421
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
