Pavol Rusnak #cypherpunk #hacker #openhw #privacy #bitcoin #newmediaart

SVG-edit 2.3 is out!

During the last weekend we released version 2.3 of our in-browser SVG editor called SVG-edit. If I was a DnB producer I would call this a “massive” release, because it includes lots of new features. :-) To name some of them:

  • Rotate tool
  • Polygon/Polyline Editing
  • Linear Gradient Picking
  • View and Edit Source
  • Clone tool
  • Align tool
  • Firefox extension
  • Opera widget

Jeff Schiller also prepared two screencasts. The older one is an introduction to SVG-edit, where he uses 2.2 version. And the newer one, which presents some of the new features included in 2.3 release.

Head here if you’d like to try SVG-edit yourself!

New RPM in openSUSE Factory

rpmlogo

Michael Schroeder has finally updated the RPM package in openSUSE to the latest upstream version 4.7.1. \o/ There were LOTS of bugfixes, enhancements and internal API changes which are probably not very interesting for mere mortals, but what do they mean for packagers? Here’s a list of important changes for them:

  • Macro %patch does not behave like %patch0 anymore. Stop mixing Patch: with %patch0 and vice versa and use them consistently - i.e. either use the numbers in preamble and in %prep phase or don’t.
  • Fuzz tolerance for patches was changed from 2 to zero. All patches must apply cleanly now.
  • Sub-packages can be declared as “noarch” now. Such .spec file is incompatible with older RPM but the resulting binary packages are compatible.
  • Section %files now supports multiple file lists. No need to join the files into one in %install section.
  • The new macros %{patches} and %{sources} are available. You can use them in for loops to iterate over all patches and sources respectively.
  • %ghost files do not have to be present in the build root anymore. In this case you have to specify their attributes like this: %attr(0644,root,root) %ghost ghostfile.

Few months ago we began discussion with Fedora guys about how to bring our packaging habits more closer. We identified some points by comparing their Packaging Guidelines with our routines and I created a list of differences at RPM wiki. The main idea is to find a solution which is acceptable by both parties and to create a mechanism (usually macros) for it in RPM upstream, so both distributions can benefit from it. Some of the problems are already sorted out, but there is still a long way to go. If you are aware of such differences or even would like to propose the solution, please contact me. I’ll add the items to the list and we’ll discuss them at the openSUSE Conference - RPM Summit, where people from RPM upstream will be present as well. By looking at the “Solved” part (at the bottom) of the mentioned wiki page you can see the following changes to be more compatible:

  • Our %makeinstall macro is called %make_install in RPM upstream. Change it to the new form when you touch your package (also replace make DESTDIR=${buildroot} install with this macro).
  • Build root is created in a safe way, you don’t need to specify the location with BuildRoot:. Also it is automatically cleaned after the build if the %clean phase is omitted from .spec file (i.e. not mentioned at all, if it is there but is empty no removal is done).
  • Use %{python_sitelib} macro for noarch Python packages and %{python_sitearch} for the architecture dependent ones, instead of the old %{py_sitedir} one. (Yes you can now create noarch Python packages!) Stop using %{py_requires} as well, because dependencies are added automatically now.

Important! Nearly all of these changes are effective from 11.2 and will not work with earlier releases in openSUSE. If you plan to use the same .spec file for backporting inside BuildService, you’ll need to keep the old and the new stuff in corresponding %if 0?%{?suse_version} ... %endif blocks for a while (well, until 11.1 is EOL).

PS: I will try to keep this post updated until 11.2 is released so you might want to check it from time to time.

Chameleón má už svoje meno

Počas minulého týždňa sa viac ako 130 z vás zapojilo do súťaže o výber mena pre nášho chameleóna v pražskej ZOO. Obdržali sme viac ako 150 skvelých nápadov a naša skalná komunita, ktorá sa zdržuje na IRC kanáli #susecz mala čo robiť, aby z nich vybrala najlepší. Medzi návrhmi sa objavili rôzne pôvabné mená ako Bugísek, Susík či Zmizík, ale nakoniec zvíťazil Jastík. Z pekných cien odfotených na obrázku nižšie sa môžu radovať Petr Dvořák zo Studenej a Jan Hora z Prahy.

sutaz-ceny

Chameleón obrovský v ZOO

English version below …

Pred pár dňami sa pražská pobočka SUSE Linux, s.r.o. stala adoptívnym rodičom Chameleóna obrovského (Furcifer oustaleti) v ZOO Praha. Ako každý vzorný rodič musíme nášmu potomkovi vybrať meno (a anglické Geeko sa mu predsa nehodí). Keďže je openSUSE komunitný projekt, nenechávame si túto radosť iba pre seba a chceme Vás poprosiť o pomoc pri výbere. Vaše nápady nám píšte do konca tohto týždňa (23.8.2009 23:59). Najlepší z nich odmeníme zaujímavou cenou!

Na záver ešte prikladám certifikát a dve fotografie nášho krásavca:

zoo_certifikat

zoo_chameleon_1

zoo_chameleon_2

A few days ago the Prague SUSE office became the adoptive parent of the giant chameleon (Furcifer oustaleti) in the Prague ZOO. You can see the adoption certificate and two photographs of our beauty above.

Daisy Plasmoid - A dock for KDE 4

From time to time I use Mac OS X and I really like the application management with its dock. I came across several different implementations for KDE 4, but they were usually too immature and not very pretty. I was very surprised when I finally found a decent implementation called Daisy. I immediately dropped the default KDE taskbar and started to use Daisy in conjunction with desktop effects “Box Switch” and “Present Windows” a.k.a Exposé. You can look at my setup here (only bottom 64 pixels are shown, the rest is usually occupied with maximized application):

daisytray

Daisy detects running instances of applications by Window Class, so it doesn’t try to start another instance, it rather activates the already running one. The experience is very similar to the Mac OS X one, but still, there are three problems:

  • I still have to use the panel for Battery Monitor and Device Notifier widgets
    • Daisy could act as a host for other widgets and show them as icons
  • Applications started manually (e.g. with KRunner) do not appear in the dock
    • Daisy could act as a taskbar and show icons of all running windows
  • Applications like instant messengers or IRC clients use tray for notifications
    • Daisy could act as a tray and replace the launcher icon with the one added to tray by application after its start (so it will flash in the dock)

Once these three points are met, Daisy will become a complete counterpart of Mac OS X dock. I’ve already written these suggestions to Lechio (upstream developer), but I’m not sure if this is the direction he wants to go and whether it is possible to do without any extra hacks at the KDE/Plasma side. (I’m sure that Lechio will accept any help :-) ) Anyway, have a look at the project page, KDE-Look page or try the plasmoid from the Build Service. The package is called plasmoid-daisy and is present in KDE:KDE4:Community project.