I talked yesterday with Coolo about the openSUSE Build Service and mentioned that I have now a lot of branched projects in my home project since I looked at many different packages that have different devel packages. He showed me his script and also gave another hint that I wanted to share (thanks Coolo for sharing this with me!).
Archive for July, 2009
openFATE feature 306967, KDE default
July 31st, 2009 by Michael LöfflerThere are pretty many pros and cons and even more people with their opinion about the feature. I’d like to summarize what has been said in the discussion in the feature itself and during yesterday’s openSUSE project meeting. Unfortunately the only sure thing is whatever decision is taken – it will be wrong for some. This is why, at this time, we have no default – because openSUSE has strong GNOME and KDE implementations, we offer them side-by-side as equals. And we made 2 years ago on opensuse-project the decision that we stay with “no default” desktop.
So what do we have so far?
- a feature request from one of the KDE e.V. board members
- the feature asks to make KDE default. Reason for that, is to make openSUSE more simple for newbies and to make openSUSE the best KDE distribution around
- Through the discussion in the feature I’d translate that feature into put the radio button as default to KDE on the desktop selection screen during installation instead of today’s status where everybody needs to make a choice between
- the highest rated feature in openFATE until today
- a majority of people supporting this feature (currently approx. 90% pro, 1% neutral, 9% against)
New Package: Association Subscribers Manager 3.0
July 30th, 2009 by Sascha MannsI’m happy to announce, that i imported the Assuma Manager to openSUSE. Special Thanks goes to David Haller. The Package can recieved in KDE:KDE4:Community.
More Infos there: http://www.opendesktop.org/content/show.php?content=109313
Testing Packages and Their Dependencies
July 30th, 2009 by Andreas JaegerWith many packages, it’s easy to test that the package itself builds after a major change, e.g. a version update. But once you add the package to your devel project or to factory, you notice that other packages do not build anymore due to your new package.
So, what can you do? You can create your own project in the openSUSE Build Service that contains your package and create links for those packages that need your package during build. That way you can find out which packages fail and fix them – instead of submitting your package to the devel project or factory and get lots of failures.
Do you have other tips about the Build Service? Please post them!
Improved mirror selection for India
July 29th, 2009 by Peter PömlRecently, it became evident that users in India don’t get good mirrors. This was solved by configuring a few German and US mirrors to serve users from India.
Courtesy of Adrian Reber from Esslingen University of Applied Sciences, there is an illustrative screenshot that visualizes the efficacy of this. The world map shows accesses to their openSUSE mirror by country (live view). In openSUSE’s MirrorBrain configuration, this mirror is set up to receive German, Danish, Polish, and Indian requests.
The background is that India has bad connectivity to neighbouring countries, but good connection to German and US mirrors. Therefore, now a few German and US mirrors are configured to serve India. The screenshot below demonstrates this for the mirror of the Esslingen University of Applied Sciences:
The world map clearly shows how the mirror gets nearly exclusively German requests, as well as those from India. The same happens for some other German and some US mirrors.
Note that if a mirror in India should become available (would be nice!), it would automatically be preferred, and the other mirrors become fallback mirrors.
While it is not new that we do this, the screenshot of Adrian’s analysis illustrates the issue very nicely. We have similar configuration for a number of countries, where a mirror selection purely based on countries and regions wouldn’t work. For this kind of tuning, we depend on user input.
Hints about how to improve serving our downloads are always appreciated. Please write to admin at opensuse dot org with input in this regard. Thanks!
Hackweek IV: Novell Bugzilla access from command line
July 29th, 2009 by Michal VyskocilDuring a last Hackweek I decided to work on some tool which will helps users with submitting a new bug. My idea is to create something like reportbug from Debian, but targeted to SUSE. So the first step was find the way how to communicate with a bugzilla (especially to bugzilla.novell.com – bnc). Fortunately I found several libraries, which should be used for it:
- perl-SUSE-BugzillaClient
- pybugz
- python-bugzilla
perl-SUSE-BugzillaClient is written by Thomas Schmidt especially for bnc, so it is able to login using iChain. It also provides few functions for bugzilla communication, but unfortunately only for querying. Pybugz is written by Alastair Tse for Gentoo development in Python. But it is not able to login through iChain and I did not extended it for bnc, because it uses a plain GET/POST communication with parsing of HTML using regexes.
The reason why I have used the python-bugzilla written by Will Woods from RedHat is simple. It uses XMLRPC API, which bugzilla provides. And it’s also written with a flexibility in mind, so writing of another type of Bugzilla was easy. Just some subclassing and reimplementing of few methods and voila, the NovellBugzilla type is here. Because it uses iChain, it was necessary to reimplement login/logout methods – I spend a lot of time to understand how it works. Osc uses a HTTP authentication, which should be supported too, but even if it works with api.opensuse.org, it did not work with bnc. So I used a Firefox and LiveHTTP headers extension to track a communication and implemented the login according it.
The useful advantage of Novell bugzilla is that I extended a method readconfig, which reads a config file. Novell Bugzilla can read the username/password from ~/.oscrc, so you don’t need to have a same password in another config file, if you use osc.
So on the end those few lines of Python code
import bugzilla bnc = bugzilla.NovellBugzilla(url="https://bugzilla.novell.com", user="mvyskocil", password="XXXXX") kwargs = { 'product': 'openSUSE 11.2', 'severity': 'Normal', 'cc': [], 'rep_platform': 'x86-64', 'component': 'Java', 'summary': '[Java:packages/ant]: Cannot find a Java virtual machine', 'version': 'unspecified', 'assigned_to': 'mvyskocil@novell.com', 'op_sys': 'Linux', 'description': 'This is a testing bug report\n' } bug = bnc.createbug(**kwargs) print bug.bug_id
Have created this bug#525549. Even if Python is readable for regular programmers, the **kwargs should be expressed. It maps the dictionary to named function arguments (called keyword arguments – kwargs – in a Python world), so both calls in following snippet are equivalent.
d = {'name' : 'value') call(**d) call(name='value')
The python-bugzilla comes also with a simple command line tool called bugzilla, so this tool should be used also from shell scripts. It is sometimes little bit raw. For example listing of all products returns an output as a Python dictionary
bugzilla --bztype NovellBugzilla --user mvyskocil --password xxxxxx info -p ... {'description': 'openSUSE 11.1', 'internals': {'disallownew': 0, 'classification_id': 7340, 'name': 'openSUSE 11.1', 'votestoconfirm': 0, 'milestone_required': 0, 'id': 651, 'votesperuser': 20, 'maxvotesperbug': 5, 'defaultmilestone': '---', 'milestoneurl': '', 'description': 'openSUSE 11.1'}, 'name': 'openSUSE 11.1', 'id': 651} {'description': 'openSUSE 11.2', 'internals': {'disallownew': 0, 'classification_id': 7340, 'name': 'openSUSE 11.2', 'votestoconfirm': 0, 'milestone_required': 0, 'id': 755, 'votesperuser': 20, 'maxvotesperbug': 5, 'defaultmilestone': '---', 'milestoneurl': '', 'description': 'openSUSE 11.2'}, 'name': 'openSUSE 11.2', 'id': 755} ...
which might be hard to parse in other language. But it provides a lot of functionality, so for other informations about usage, please use man bugzilla.
SUSE Studio Launch – and openSUSE
July 28th, 2009 by Andreas JaegerToday the SUSE Appliance program was launched by Novell. The interesting part for openSUSE is the launch of SUSE Studio. SUSE Studio is a web-based tool to build complete software appliances based on SUSE Linux Enterprise and also openSUSE. A software appliance is a ready-to run image that you can copy on your harddisk and start directly – or it comes packaged as a virtual image that you can boot using e.g. Xen. Normally software appliances are custom made for a specific purpose, e.g. a database server.
I just build on top of openSUSE 11.1 a git server appliance. The interface is very intuitive so that most of the time used was waiting for the image to be created – and building the images is extremely fast (the LiveDVD image took 4:21min to build, the hard disk image only 2:35mins)! The SUSE Studio folks have created a great product – congratulations!
Fresh & Fruity
July 28th, 2009 by Marcus SchaeferAvailable today as part of the SUSE Appliance Program is SUSE Studio 1.0 based on the image creator technology called kiwi. When creating an appliance with SUSE Studio you also have the possibility to export the appliance description to your local computer and use the kiwi backend directly to understand more about image creation and deployment
A professional linux distribution should be able to work as an appliance which is an ll-in-one solution including the application and the operating system. A basic appliance to start with is the JeOS – Just Enough Operating System. kiwi provides these as examples in the kiwi-templates package. To create your first SUSE 11.1 appliance just type:
kiwi --build suse-11.1-JeOS -d /destination/path
The primary image type of a JeOS template is a virtual disk which you can run in a virtual machine like QEmu, KVM, Vmware, VirtualBox, etc… To do this with qemu just call:
qemu /destination/path/LimeJeOS-openSUSE-11.1.i686-1.11.1.vmdk
and here you go with your first appliance. You want to know more about kiwi, just take a look at the wiki here:
or read the full system documentation as PDF here:
Remember to have fun 🙂
OpenOffice_org 3.1.1 beta1 available for openSUSE
July 27th, 2009 by Petr MladekI’m happy to announce OpenOffice.org 3.1.1 beta1 packages for openSUSE. They are available in the Build Service OpenOffice:org:UNSTABLE project and include many upstream and Go-oo fixes. Please, look for more details about the openSUSE OOo build on the wiki page.
The packages are beta versions and might include even serious bugs. Therefore they are not intended for data-critical usage. A good practice is to archive any important data before an use, …
As usual, we kindly ask any interested beta testers to try the package and report bugs.
Other information and plans:
The next build will be 3.1.1-beta2 and should be available within next two weeks. The final OOo-3.1.1 packages should be available at the beginning of September.
GSoC – summary of this week’s meeting
July 24th, 2009 by Marcus HüweDuring the past few weeks I spend most of my time on implementing a basic user interface to manage oauth tokens. Again I’m quite impressed about this powerful rails framework 🙂
Additionally I worked on the “Accept-Authentication” stuff (see my last post for the details).
I also found a small bug in osc when doing a POST request. For every POST request it used “application/x-www-form-urlencoded” which is wrong when e.g. POST’ing a specfile which isn’t urlencoded. For now we use “application/octet-stream” if we have POST request + POST data.
The plan for this week is some code restructering, testing and bugfixing.