openSUSE Project March 2011

project@lists.opensuse.org

114 participants
84 discussions

[opensuse-project] talk at or visit Linux Open Administration Days

by Jos Poortvliet

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

10 years, 1 month

[opensuse-project] GSoC 2011: Bug reporting tool.

by Mihnea Dobrescu-Balaur

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

10 years, 9 months

[opensuse-project] Proposal for adapting the trademark guidelines

by Cornelius Schumacher

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>

10 years, 11 months

[opensuse-project] Announcing search.opensuse.org

by Brandon Philips

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

11 years, 1 month

[opensuse-project] Fwd: [GSoC Proposal] spec-cleaner

by kunal ghosh

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.t2 Blog:kunalghosh.wordpress.com Website:www.kunalghosh.net46.net -- regards ------- Kunal Ghosh Dept of Computer Sc. & Engineering. Sir MVIT Bangalore,India permalink: member.acm.org/~kunal.t2 Blog:kunalghosh.wordpress.com Website: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

11 years, 1 month

[opensuse-project] Interviews with openSUSE people

by Kim Leyendecker

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

11 years, 1 month

[opensuse-project] Introducing SaX3 as a GSoC Project

by Manu Gupta

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

11 years, 1 month

[opensuse-project] GSOC Idea: Command line client for SSC

by Ratan Sebastian

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

11 years, 1 month

Re: [opensuse-project] Introducing SaX3 as a GSoC Project

by Zack Buhman

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

11 years, 1 month

[opensuse-project] [GSoC 2011] - GTK+ client for smolt

by Max Usachev

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

11 years, 1 month

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Project March 2011