Hello, my Name is Sascha Manns from Germany. Now i try to post in lizards.
GNOME backports on openSUSE
November 27th, 2008 by Andrew WafaaAfter several requests to get GNOME 2.24 built and made available the GNOME Team (well Magnus Boman really), took on the challenge of making it so. Unfortunately we were a bit focused on the 11.1 release and didn’t actually think about doing any backports. This has kind of bitten us squarely on the behind, yes we must bow to the KDE Team‘s backporting powers – make the most of it chaps 🙂
Unfortunately there are too many dependencies for the backport, and will involve a heck of a lot of maintenece – more so than normal. After several attempts to coax things to work we must bow our heads in admission to being beaten 🙁 This doesn’t mean that we won’t be doing any backports in the future, the championship isn’t over just this match. It does mean that there wont be a GNOME 2.24 for openSUSE 11.0 however, sorry to disappoint.
We have learnt our lesson and with the aim of not disapointing you again we have already instigated measures to ensure that your backporting needs are met. We are already starting to build GNOME 2.25 against the current Factory and will continue to ensure that each release has the latest and greatest from the Enchanted Wood. There may well be occaisons where things just won’t work, but we will do our utmost to minimise them and give you plenty of notice.
One thing we do need is your help. Funny I always seem to be asking for help, but this time there is a really good reason (actually more than one 😉 ). We need more people to run Factory to test things and ensure that bugs and issues/comments are reported back. This doesn’t just apply to GNOME but openSUSE in general, please please test our latest releases and give us your feedback. There are several ways you can do this – Bugzilla, IRC and Mailing Lists, oh and at events like the upcoming FOSDEM.
New software in build service
November 18th, 2008 by Josef ReidingerI try testing xfce4 desktop and find some bugs. But I also find that some really interesting missing in opensuse build service, so I add two new applications to build service (gnome community repository…but now gaupol is available only in my personal repository, because in gnome pygtk wait for python 1.6) – osmo and gaupol.
Read the rest of this entry »
ARM support for openSUSE Buildservice and openSUSE
November 18th, 2008 by Martin MohringARM architecture going more to desktop style applications had been in press frequently during the last weeks. On top of were press releases of ARM and canonical officially announcing an ubuntu port in one of the next releases for the ARM architecture. Applications are more of type nettop or advanced PDA like the nokia n810, than what is currently known as traditional embedded applications (just to name a few examples).
This has been due to the fact that licensees of the ARM architecture, big semiconductor companies from the Top 10 list, have begun shipping a new generation of “mobile PC in the pocket” of System on a Chip semiconductors. They include now a really high clocked ARM core, DSPs for Video/Audio processing that can even decode HDTV streams, and OpenGL 2.0 capable HW engine and the peripherials included to build PDAs, mobile phones or nettops. All that within the energy budget of a mobile phone, and not of a Desktop PC. The google G1 phone had been one of the first products of this generation, although its software uses these features only in the beginnings.
What now does this all have to do with the openSUSE Buildservice and openSUSE distribution? As you might already guess it, we haven’t been sleeping either. And I am not a advocate of ubuntu on an .opensuse.org website. So read further what we have done so far.
Updated python-turbogears to 1.0.7
November 17th, 2008 by Ciaran FarrellLast weekend I spent some time on getting python-turbogears to build for Factory. In the process, I came across a spec file error which was causing not only python-turbogears to fail on Factory, but also dozens of other python packages. The problem was the spec file line:
%{__python} setup.py install –prefix=%{_prefix} –root=$RPM_BUILD_ROOT –record-rpm=INSTALLED_FILES
Once I fixed this for python-turbogears and it’s dependent packages (the solution is to replace –record with –record-rpm), I was able to get version 1.0.6 building for Factory. There were a few other issues which needed to be resolved (some deprecated def as() functions in python-peak and python-ruledispatch were causing syntax errors on python 2.6 – because ‘as’ is a reserved keyword), but finally I got it sorted out.
Once python 1.0.6 was successfully building on Factory, I decided to update the package to the most recent stable version of the 1.0.x package line from http://www.turbogears.org – 1.0.7. I had to rewrite the infamous cherrypy2 patch for 1.0.7 and also had to update the python-elixir package (the older 0.5 Elixir was incompatible with python-sqlalchemy >= 5) but now it builds properly.
You can now download and install python-turbogears using:
zypper in python-turbogears
(if you have the devel:languages:python repository, of course).
Thanks to Peter Poeml for his help packaging and fixing bugs.
Developing with libyui/libzypp & python – part4
November 11th, 2008 by Jan-Simon MöllerLet’s extend the application to make it even more useful!
* add support for YaST-Repositories
* add Support for different architectures
* use always a random temporary directory
Now, it looks like this:
You can grab it out of my home: in the openSUSE Build Service (for openSUSE 11.0).
Start it with “repoviewer”, add the repository’s url, select the type, the architecture and hit “Go!” .
You can choose the architectures only for the “highest” type of the family as they list the “lower” types, too.
So to see “ppc” packages. use “ppc64” in the combobox and later “ppc” in the “Arch” column.
For big repos (like factory) it takes some time to download and parse the metadata.
Also try in a console-window:
unset DISPLAY; repoviewer
😉 thanks to libyui, that just works !
Update: You can access also local directories (like mounted CDs/DVDs).
Just use “file:///” and the full path ! E.g.: “file:///media/SU1100.001/”
YaST releases independent of openSUSE releases?
November 7th, 2008 by Stanislav VisnovskyYaST is one of the cornerstones of openSUSE. It is developed for openSUSE and is released as part of openSUSE. There never was a release of YaST independent of openSUSE. Even the versioning of YaST is tied to openSUSE – the versions are 2.X.Y, where X is increased for every openSUSE release (17 for 11.1) and Y is simply a patch level, whenever a new fix or feature is added. Even more, every YaST package has its own versioning, so the only way to ensure you have a consistent set of YaST packages is via dependencies set in the .spec file of the YaST packages.
But in principle, YaST is a tool that can be used across distributions and there are people interested in this to happen. There are technical barriers to do releases independent of openSUSE (e.g. a lot of openSUSE-specific knowledge and behavior coded in YaST) as well as procedural. During past years, a lot of these non-technical issues has been addressed as we opened up the YaST development (re-licensing the code under GPL, opening up source control system and mailing lists, etc).
But still, there is one big thing left: YaST packages are released in concert with openSUSE. Yes, it is very convenient for openSUSE, but it makes it almost impossible to track the development during for people outside of our great distribution.
If one looks at the way the YaST packages are updated during the hotphase of an openSUSE release, the core parts of YaST (yast2-devtools, yast2-core, libyui, …) are rarely updated, they get a bug fix here and there. However, the distribution specific parts (yast2-pkg-bindings, yast2 common libraries, bootloader, storage, networking, …) get a fast flow of patch-level releases, typically several between openSUSE milestones.
Thus, the way forward I like the most right now is a compromise: a core YaST system should be released independently of the openSUSE release cycle while specific modules could keep their crescendo during openSUSE hot phase. How to do that?
For core YaST packages (a list to be defined) would be released independently of openSUSE and during hot phase, they would be handled the way other FOSS parts of openSUSE are – by patching the code in the package. The rest of the YaST, current practice would stay untouched.
There are clearly advantages – the YaST developers can do a proper release management of the core code and it is much more predictable how the core part of YaST will be released. On the other hand, people would need to be aware of the split.
However, I can imagine there is a lot of I did not realize. I’m definitely interested in comments about this topic.
Follow The Netbook Road
November 6th, 2008 by Andrew WafaaAs many people will have noticed from my ramblings on twitter and identi.ca and also from my sporadic almost dumb sounding questions on IRC (thanks very much for your patience in IRC btw), I have been working on getting a usable installation of openSUSE on the eeePC 701 – both GNOME and KDE4. As I have a 4GB SSD model my aim is to have a feature full install taking up no more than 2.6GB. Yes I know this doesn’t help those with the 2GB model, but I’m scratching my own itch here ;). Ultimately I would like to be able to create USB and CD images of the builds in time for 11.1’s release which is in about 43 days time, problem is KIWI does not like me 🙁 but I will persevere and see what I can conjure up in time. I am a happy user of openSUSE 11.0 with XFCE on my eeePC at the moment, but I fancy a bit of a challenge and a good dose of stress and anger trying to get it to work will be a welcome distraction from the stress and chaos I have to deal with at work 🙂
So what packages am I looking at putting on there? Below are a couple of tables of applications and what I have selected for each DE including ASUS eeePC related drivers (ACPI/Events) and also bluetooth; I have tried to stick to those that come with the DE e.g. all KDE apps are KDE4 variants, and if a DE provides an app for a function I try to use that. So the first iteration of the table is:
| KDE | GNOME | XFCE | |
| Terminal | Konsole | GNOME-Terminal | Terminal |
| Text Editor | Kwrite | Gedit | Mousepad |
| Web Browser | Konqueror | Epiphany | Epiphany |
| File Manager | Dolphin | Nautilus | Thunar |
| Music Player | Amarok2 | Banshee | xfmedia |
| Video Player | Dragon Player | Totem | xfmedia |
| PDF Viewer | Okular | Evince | Evince |
| IM client | Kopete | Pidgin | Pidgin |
| IRC client | irssi | Pidgin | Pidgin |
| Office Suite | OOo | OOo | OOo |
| Kmail | Evolution | Claws-Mail | |
| RSS | Akregator | Liferea | Liferea |
| Calendar | Korganiser | Evolution | Orage |
| Addressbook | Kaddressbook | Evolution | Claws-Mail |
| Flashplayer | Yes | Yes | Yes |
| Java | Java-1.6 | Java-1.6 | Java-1.6 |
| Codecs | Xine | Gstreamer | Xine |
| Photo Viewer | Gwenview | F-spot | Ristretto |
| FTP Client | Dolphin | Nautilus | Gftp |
| Networking | NetworkManager | NetworkManager | NetworkManager |
| Total Space Taken Up | 2.6GB / 2676552k | 2.7GB / 2752336k | 2.6GB / 2718412k |
As you can see KDE4 takes up the least amount of space followed by XFCE with GNOME dropping into third place. This surprised me as I actually expected XFCE to be way ahead in the lead. I then tried to minimise the number of applications and tried to use apps that could multi task, still prefering those that are included as part of the openSUSE distro:
| KDE | GNOME | XFCE | |
| Terminal | Konsole | GNOME-Terminal | Terminal |
| Text Editor | Kwrite | Gedit | Mousepad |
| Web Browser | Konqueror | Epiphany | Epiphany |
| File Manager | Dolphin | Nautilus | Thunar |
| Music Player | MPlayer | Totem | xfmedia |
| Video Player | MPlayer | Totem | xfmedia |
| PDF Viewer | Okular | Evince | Evince |
| IM client | Kopete | Pidgin | Pidgin |
| IRC client | irssi | Pidgin | Pidgin |
| Office Suite | OOo | OOo | OOo |
| Kmail | Claws-Mail | Claws-Mail | |
| RSS | Akregator | Claws-Mail | Claws-Mail |
| Calendar | Korganiser | Claws-Mail | Orage |
| Addressbook | Kaddressbook | Claws-Mail | Claws-Mail |
| Flashplayer | Yes | Yes | Yes |
| Java | Java-1.6 | Java-1.6 | Java-1.6 |
| Codec Framework |
ffmpeg | Gstreamer | Xine |
| Photo Viewer | Gwenview | Eye Of GNOME | Ristretto |
| FTP Client | Dolphin | Nautilus | Gftp |
| Networking | NetworkManager | NetworkManager | NetworkManager |
| Total Space Taken Up | 2.6GB / 2662540k |
2.6GB / 2682516k |
2.6GB / 2716364k |
As you can see KDE is still the leader, but GNOME has managed to close the gap significantly.
You will notice that there are some notable applications missing from both tables, both from the Mozilla family – FireFox and Thunderbird. I chose not to use FireFox as the browser as I have been experiencing some icky lockups with it, and this is irrespective of platform. I decided against Thunderbird because it just did not like to display correctly on the 7″ screen, even the version supplied by Xandros refused to display nicely. As KDE4 doesn’t have a native IRC client yet I have chosen irssi, i will update the list when a native KDE4 client is available – most likely Quassel. Also as it stands Kaffeine is not available for KDE4 yet, when that happens I would imagine I would replace MPlayer with it.
Both the GNOME and KDE4 builds were based on a minimal X install – for GNOME add gnome-panel and gnome-session; for for KDE add kdebase4-session, kdebase4-workspace and kde4-win; XFCE was based on the supplied pattern. One thing I did notice is that 11.1 (Beta4) seems to have put on a bit of weight in comparison to 11.0, a base install appears to be ~400MB more O_o. I am going to to do a verification shortly and file a bug so hopefully I can thin them out even further.
If people have any recommendations or suggestions as to what applications to use, then please let me know. My next step is to create both ISO and USB images, any and all help would be much appreciated – SUSEStudio access would be even better ;) This list is not meant to be the be all and end all, but more a matter of itch scratching. Yes I know I could reduce the space taken up if I didnt bother with any of that non-free codec crud, and drop flash from the equation, but I’m pragmatic and ultimately want to see people use openSUSE. Get them using our distro first, once thatis established then we can educate them on the ugly side of things. Once I manage to create the images with the above package list i will look at creating a completely free version with no colsed codecs/apps.
Once again I’d like to thank all those on IRC for there help and advice – JP Rosevear, James Wilcox, Stephan Binner, Will Stephenson, Martin Schandler and Hubert Figuiere.
Bootloader gets chattier
November 6th, 2008 by Steffen WinterfeldtSince openSUSE 11.0. we have some basic speech support in our bootloader. This enables visually impaired people to use the bootloader as there is usually no other output device available at that time (BIOS doesn’t really support braille displays).
It uses the PC-speaker for output (which has the benefit that you don’t need specialized sound drivers for every hardware).
If you didn’t try it yet: press F9 at the boot screen.
I’ve reworked that a good deal in openSUSE 11.1 RC1 (2MB sound samples) and now it reads all menus and dialogs to you and spells all chars you enter in input dialogs (actually it speaks the char left from cursor).
The sound samples are pre-generated with espeak. But you are of course free to replace them with your own voice if you like that more. 😉
What to do if every kernel update break your bootloader settings
November 6th, 2008 by Josef ReidingerPerl-Bootloader response for kernel post-install bootloader update script. Current target is ensure, that you have in your bootloader actually kernel and also that entries for old kernel is removed. This is problematic for some complex or manually enhanced configuration. In this case perl-Bootloader should somehow break your settings (this mean you still can boot, but your enhancement or extra sections can dismiss). This should change in future as noticed in bugzilla .
If you want maintain your configuration manually, you can simple set your bootloader to none. There is two ways how you can do it. First is set LOADER_TYPE=”none” in /etc/sysconfig/bootloader. Second is set this in yast2 bootloader. Another advantage is that this take almost no-time, so if obtain hardware configuration for update take to much time, this is workaround.
Warning, if you set bootloader type to none you must manually edit your bootloader configuration after kernel update. What can help you, is set image and initrd to symlinks which lead to actual kernel.
