Skip to main content
  1. Planet
  2. English
  3. Page 490

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Fixing Lighttpd in Debian on SheevaPlug

I was using SheevaPlug as my Home NAS, with and external usb hdd, until recently when I built my new NAS, based on ION ATOM, FreeBSD and ZFS.

I am thinking to add an usb webcam and to use it as a monitoring system.

I updated Debian "squeeze", which is running on an 8G SDHC card, but I got the error:

*After this operation, 0B of additional disk space will be used.  
Do you want to continue [Y/n]? y  
Setting up lighttpd (1.4.25-2) ...  
Starting web server: lighttpd2010-01-22 23:13:31: (network.c.345) can't
bind to port: :: 80 Address already in use  
failed!  
invoke-rc.d: initscript lighttpd, action "start" failed.  
dpkg: error processing lighttpd (--configure):  
subprocess installed post-installation script returned error exit
status 1  
Errors were encountered while processing:  
lighttpd  
E: Sub-process /usr/bin/dpkg returned an error code (1)  
sheeva:/home/ionut\#*

I didn't have anything running and listening on port 80, so, it seems that it is a known bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564556 and the solution is here:

Add in /etc/lighttpd/lighttpd.conf:

*server.use-ipv6 = "enable"*

And add in /etc/sysctl.d/bindv6only.conf:

"*net.ipv6.bindv6only = 0*"
a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

GNOME 2.28.2 on openSUSE 11.2 Updates more packages for openSUSE

Today the openSUSE GNOME team released the GNOME 2.28.2 update for 11.2. This also shows a different direction in openSUSE that is more user community oriented because isn't usual to have version bumps in updates.
So pick your gnome-packagekit or zypper up to get the latest GNOME update.

The news on openSUSE GNOME don't end here... i submitted a request today for gnome-color-manager, shared-color-profiles, libgee and tracker to be included on the main distro so expect these packages for 11.3 and GNOME:Factory/GNOME:Apps really soon.
The team also have GNOME 2.29.5 updated on GNOME:Factory repository including the latest zeitgeist and gnome-shell in case you want to test/develop/enjoy GNOME 3.
If you want a new package on openSUSE GNOME add it to the wishlist and i can take it (at least until i get a job :) )

With this good stuff it's also an important time to try openSUSE, join the team and have fun!

PS: Thanks to Magnus and Dominique for their work on this update

the avatar of Carlos Gonçalves
the avatar of Carlos Gonçalves

PySide packages for openSUSE, Mandriva and Fedora


As some are already aware of, I've been packaging PySide (including apiextractor, generatorrunner, and boostpythongenerator) for openSUSE since the project has been publicly announced.

Not only stable/released versions have been packaged, but also snapshots taken from mainline git repository with both built and hosted on the openSUSE Build Service in my home dir there (home:cgoncalves:pyside and home:cgoncalves:pyside:devel).

Yesterday I took some time updating the snapshots (ie. home:cgoncalves:pyside:devel) to now build against shiboken instead of the not-yet former boostpythongenerator. Apiextractor, generatorrunner and shiboken built successfully, while PySide did not because I've tried to build it with Qt 4.6 but due to bug #124 it failed, and in the meantime I've switched it back to Qt 4.5.

Moreover, I'm expanding this packaging work to other distributions namely Fedora 11, Fedora 12, Mandriva 2009.1, and Mandriva 2010 sharing the same specfile with openSUSE 11.1, openSUSE 11.2, and openSUSE Factory that already live there for quite some time.

Everything have been built okay for these distributions, except on Mandriva 2009.1 and openSUSE 11.1 where PySide (only) is failing (older gcc version version issues I suppose) and on Fedora 11 i586 and openSUSE 11.2 i586 with PySide failing, too, but due to bug #111

So, in case you are interested in testing these non-openSUSE packages, which I didn't I may add, please do so and report back to me whether they are okayish or not.

Finally, keep in mind that for now I'm only referring to repository home:cgoncalves:pyside:devel (snapshots) and not to stable versions. Plus, you won't get yet a full featured Python bindings for Qt since the PySide team is under heavy work on completing the QtCore module first with Shiboken before moving forward to other modules.

Please refer to [PySide] PySide packages for openSUSE, Mandriva and Fedora for further discussion.
the avatar of Katarina Machalkova
the avatar of Katarina Machalkova

On testing

( I promised this article to Lukáš  today, so now I really have to write it :) )

What is the most important part of software project? Experienced developers? Creative user interface designers? Good managers? Meticulous testers? Decision making in the right hands? Hmmm ... if you ask me, it's balanced combination of all of these, but this is not what I'm going to write about. Testing - that's (maybe along with l10n work) one of the most underestimated and largely invisible part of any software project, be it a small appliance or something as large-scale as Linux distribution.

Hackers often look down on QA guys and view them as those not being smart enough to actually write the code. Nothing can be further from the truth. A good tester is worth his/her weight in gold. Fairly recent experience with work on (partially closed-source) project taught me a lesson about vital importance of  testing that I'll never forget. Really. Even the best code is dead without somebody testing it.

It is a tester who has to, using his/her experience and intuition, be able to pinpoint weak points of the software. When implementing a feature or creating a bugfix, developer's time is just enough to do some basic testing, verify it works, the bug is really fixed and be done with it. Tester has to use his/her creativity and come up with scenarios developer never dreamed about.

Tester has to have enough patience to go through the same boring set of basic routines with each and every new build. His/her learning curve with a new software has to be pretty steep. In limited time, s/he has to understand principles and configuration of the software and start using it as if s/he was an advanced user. At the same time, s/he has to quickly find out where the borderline between PEBCAK (Problem Exists Between Chair And Keyboard aka Layer 8 issue) and a real bug lies. I have to admit that this was the reason why I pretty much sucked at testing - I was so anxious about "I don't want to look stupid and file an invalid bug" that I spent hours and days studying docs and verifying it's not just me doing something wrong. I didn't realize that misleading documentation or confusing UI qualify as bugs as well.

When the project is finished, hackers are the guys in the spotlight and, sadly enough, QA work often stays unnoticed. Worse even, if the whole thing is a failure, testing squad is the first one to blame ("Damn, those guys must've had no QA. What? They had some? What they have been doing all that time then?"). Needless to say, that doesn't exactly boost one's confidence in the meaningfulness of his/her work.

To conclude, I'd like to dedicate this post to all our Four-Letter-Project testers (especially to the most active one of them) and to all former, present and future openSUSE testers. Ladies and gentlemen, a big round of applause for all those heroes, known and unknown!

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

hmm

Fall happened, Winter started happening, Snow fell and thawed, Christmas came and went,
New year came and went.

Oh, and I became godfather to my niece 2 weeks ago.

Nothing much more interesting to see here, move along.

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

My ZFS Home NAS/HTPC Box Build

I was looking to build a NAS (Network Attached Storage) to store all my music, photos, files, e-books and important work related files. I also wanted to have a central place for my backups and to be used sometimes as HTPC. So, a "two in one" solution (NAS and HTPC).

Even if there are many ready-to-go NAS solutions I decided to build myself one and having the HTPC on the same machine. Here is mainly what I wanted:

  • low powered system (64-bit microprocessor)
  • used as a media server (stream movies/music)
  • to be used sometimes as a HTPC, so I wanted HDMI (for HD video)
  • ZFS file system with all its goodies
  • gigabit ethernet interface to take advantage of the network bandwidth
  • nice chassis with four hot-swappable 3.5" SATA HDD (I am using just two HDD right now because the motherboard has only 3 SATA)

My NAS/HTPC specs are here:

home_server1es34069

I choosed FreeBSD as operating system, because I am more familiar with it than with Solaris. I recompiled mplayer with vdpau support (for HD video).

Here are the steps:

  • download the latest mplayer snapshot from their website
  • download these two files (ftp://download.nvidia.com/XFree86/vdpau/include/vdpau/) and put them in /usr/include/vdpau (create that directory)
  • ./configure --disable-x264-lavc --disable-x264 -–enable-vdpau
  • gmake
  • gmake install
  • check to see if you have vdpau support with: "mplayer -vo help". If you see something like: "vdpau VDPAU with X11" then everything is ok.

Some additional steps/configs:

  • add zfs_enable="YES" in /etc/rc.conf
  • add  the following in /boot/loader.conf:
vm.kmem_size_max="1024M"
vm.kmem_size="1024M"
vfs.zfs.arc_max="100M"
  • zpool create storage mirror ad4 ad10
  • zfs create storage/archives
  • zfs create storage/backups
  • install samba, duplicity, rsnapshots, rsync, unison, ushare, ...

Right now, everything is working very well, I am very happy with the setup, but I still didn't manage to have sound over HDMI, so, a temporary solution will be to connect an additional speaker system to it.

I don't need any fancy remote control, I have a logitech wifi keyboard/mouse, because I like to be able to read the news in the morning (during cofee time) using google reader

The total power consumption is about 35W idle / 45W load which is pretty good, I think.

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

A stable repository for kolab

During the X-mas holidays Kolab, the groupware server got a stable repository for 11.1 and 11.2 on the openSUSE build service (OBS). All packages that are not provided by the openSUSE base distribution have been copied (using osc copypac) to the STABLE repository. Another possiblity to achieve the same result could be by making a fixed link to the unstable package using osc linkpac -r <rev>. Once the unstable package works again the link could be updated with osc setlinkrev -r <newrev> to point to the working revision or updated revision.

The stable repository already shows its benefits, as cyrus-imapd was updated from version 2.3.14 to 2.3.16 in the server:mail, being the cyrus-imapd development repository for Factory. As the cyrus-imapd package in kolab:UNSTABLE links to the server:mail one, it no longer builds as the kolab patches no longer apply. Unfortunately my computer went South, and real package development is at the moment not possible. A good thing to mention here is, that cyrus-imapd-2.3.16 includes patches that are needed for Kolab and which have been in the review queue for multiple years!

Just before X-mas Kolab-2.2.3 was announced. This version is not used in the openSUSE packages, as we package the version from trunk. After the 2.2.3 release the kolab development, moved back to trunk and the next version will be from trunk.

During the 8th annual KDE PIM meeting in Osnabrück, Northern Germany Kolab got some attention as well, with the following exciting announcement: KDAB and Intevation will be working on making a functional PIM suite and Kolab Groupware client based on Kontact for mobile platforms.

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Talk Teaser: Image processing with Mono.Simd

The facts:

Processing time using gdk_pixbuf: 431ms
Same method ported to Mono.Simd: 66ms
That means roughly 6.5 times faster !

Some explanations:
  • The gdk-pixbuf is an unoptimized standard gdk operation (gtk+ 2.18.1), but I don't think a lot of them are optimized either using mmx or SSEx for this platform (x86-64). Feel free to prove me wrong here.
  • Times are averaged.
  • Loading and saving times aren't taken into account here, but both are using gdk_pixbuf operations.
  • The Mono.Simd method acts on vanilla pixbufs, and results are plain old usable pixbufs, not some kind of memory buffer or whatnot.
  • The image attached to this post is not the result of the processing.
This is only a teaser for the short talk I'll be giving at FOSDEM on Sunday Feb 7. Be there if you want to learn more, see the code, or question my sanity for doing this in Mono and not directly as a gdk-pixbuf patch.
the avatar of Will Stephenson
the avatar of Will Stephenson

openSUSE at Camp KDE!

At the last minute I'm getting away from the snow and ice to visit Camp KDE in San Diego this weekend. I'll be there waving the openSUSE flag, giving a talk about using the Build Service to package and distribute your KDE applications for many Linux distributions, generally enthusing people about openSUSE and thinking about ways for KDE to be better as distributed. So if you see a guy with an SUSE t-shirt on staggering under a huge pile of DVDs, say hi! I hear San Diego has a very good zoo, perhaps they'll lend me a chameleon for even better recognisability...

the avatar of Katarina Machalkova
the avatar of Katarina Machalkova

bYnary incompatiDEbility

All I really need know I learned in kindergarten ... Come on, say you're sorry when you mess things up. Allright, we released a YaST (ncurses) update. It broke ncurses packager in openSUSE 11.1 and 11.2 for everyone. One could still use GUI (qt/gtk) packager or zypper CLI - instead, or to fix things up (e.g. to downgrade), but this is not exactly the thing that boosts user's trust in the distribution, is it? Many thanks to Marcus  for prompt response - a new update has  been released swiftly  and it can be downloaded by now. It was enough to rebuild ncurses packager against updated YaST ncurses UI lib ...

Logically, one could now ask "How comes you guys released such a crappy update? Hasn't it been tested at all?". Well, as Marcus already stated in bzilla, openSUSE update testing largely depends on those community members who use Update:Test repo and apply patches (almost) ready for the release before they hit official update repositories.
To improve the quality of updates (and to prevent buggy updates from hitting many users), we need more hero testers. What does it mean? Go subscribe Update:Test repo and/or look here how you can help maintenance team otherwise. Oh, and you may also talk your neighbour (sister, cousin, ... ) into doing the same :)

Moreover, in this particular case, it was few other little things that summed up and resulted in failure.
  • The original bug ("paging bug") this update was about to fix was reported against Package1 (yast2-backup), fixed in Package2 (yast2-ncurses) and the resulting patch crashed Package3 (yast2-ncurses-pkg). Package3 is one of approx. 80 YaST packages. Taking also update description into account, even a seasoned tester would probably pick the original module (yast2-backup) for testing here.
  • With dramatic increase in the popularity of zypper and "mainstreamness" of GUI tools, I wouldn't be surprised to find out that very few of our update testers actively use ncurses packager
  • This was the first yast2-ncurses update introducing ABI incompatibility since its split (package manager used to be integral part of the library in the past). We didn't have the experience "a dependent pack must be also included in the update"  yet

Wanted: plugin lib versioning know-how

When sh** hit the fan, my thoughts followed along this line: "Now, if we introduce some system of tracking ABI changes in YaST libs .. " (shared library versioning it is called, now I know it) "... and have dependent packages require the correct version of shared library, we can avoid breakages like this in the future." But alas, my visit to YaST core wizard made me pretty pessimistic. Not only YaST core doesn't encourage shared lib writers to version their libs correctly, it makes (in its current form) the versioning impossible. 

YaST core doesn't link against shared libs, it loads ( dlopen()s ) them on demand as plugins and the existence of different versions of plugins would complicate the situation ... So, my dear readers, if you happen to know some (preferably) open-source project that is already proficient in this i.e. it loads its components as plugins AND applies solid library versioning policy at the same time, let us (include MVidner the Wizard in the loop, too) know. Kingdom for know-how !

And now .... winter hibernation again.