Home Home > 2011 > 05
Sign up | Login

Archive for May, 2011

Some updates on the Banshee repositories…

May 31st, 2011 by

Sometime ago Gabriel asked me if I could give him help with the Banshee repositories for openSUSE; This repositories have many users hanging around and some packages are enabled on other projects, which makes them somehow sensible to deep changes.

Today I’ve pushed to openSUSE:Factory Banshee 2.0.1 (latest stable release) and a few packages which live in the Banshee repository. I’ve also submitted a deletion request to ipod-sharp which is no longer maintained and was replaced in the past for libgpod.

I’ve fixed the pending issues I’ve seen on the Banshee repository and Banshee 2.0.1 and disabled SLE 11 builds (not requiring all the dependencies). The repository serves now the following platforms (banshee and banshee-community-extensions):
* SLE 11 SP1;
* openSUSE 11.3;
* openSUSE 11.4;
* openSUSE Factory;
* openSUSE Tumbleweed (new).

On Banshee:Unstable (which should hold the unstable releases, currently 2.1.0) I’ll be introducing some changes during the next days which will feature:
* Package being renamed to ‘banshee’, thus dropping the current banshee-1;
* Migration to pkgconfig() calls for >= 1130;
* Packages banshee and banshee-core get merged into banshee (currently banshee had only 4 documentation files);
*  New sub-package banshee-common to hold all the architecture independent files (ex: text files, icons, etc);
* A few cleanups on the spec file for unsupported platforms (SLE11 and SLE11SP1 do not meet the requirements for this version and superior).

Once this is implemented and tested I will look into Banshee:Alpha and see the best way to start building daily/weekly snapshots using the OBS magic available and some magic tricks hidden in Dimstar’s sleeve which kindly accepted my request to give me a hand on such evil task.

In the future, on the next stable release (2.2.0), I’ll move the changes from Banshee:Unstable to Banshee and hopefully change the development repository to Banshee (as if Factory has the latest stable release it makes no sense in having Banshee’s development repository in Banshee:Unstable) and synch all at once.

Users subscribed to Banshee:Unstable repository might see some turbulence during the next days, while users subscribing now through the 1-Click installer will already be installing Banshee with the changes described above.

[gsoc] summary of week 1

May 28th, 2011 by

Hi,

this is a short summary of this week:

  • published proposal of the new user interface:
    we got some really constructive feedback (see thread)

The next task is to create model classes which represent a project, package, request etc.
This way we can modify the package metadata (for instance) in a object orientated manner. Our plan
is to write tests first and afterwards we start with the implementation (TDD).

Factory Progress

May 27th, 2011 by

A lot of things are happening in our Factory distribution that will be released in November 2011 as openSUSE 12.1 and I’d like to point out a few things from the last few weeks that users and developers of factory shouldn’t miss.

Roadmap openSUSE 12.1

Stephan “Coolo” Kulow has updated the openSUSE 12.1 Roadmap, the next milestone is Milestone 1 which is delayed and targeted now for release on Tuesday, 30th May. The next paragraphs highlight some of the updates for this versions.

GCC 4.6

The GNU Compiler Collection has been updated to version 4.6, the list of  changes includes the following new warning that will be visible while compiling packages for openSUSE Factory:

  • “New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were added for C, C++, Objective-C and Objective-C++. These warnings diagnose variables respective parameters which are only set in the code and never otherwise used. Usually such variables are useless and often even the value assigned to them is computed needlessly, sometimes expensively. The -Wunused-but-set-variable warning is enabled by default by -Wall flag and -Wunused-but-set-parameter by -Wall -Wextra flags.”

Some packages have been failing by the new GCC due to new warnings and new optimizations and most have been fixed already but please double check that your packages are building and running fine.

RPM 4.9

Michael Schröder announced RPM 4.9 for Factory. He explains the main packager visible changes as:

“Besides some bug fixes and an update to a newer BerkeleyDB
library rpm-4.9.0 contains plugin architecture for dependency
generation. In older rpms, the internal dependency generator
was pretty much hardcoded in C, so we always used the old
external one to generate dependencies. With rpm-4.9.0, the
internal generator has become flexible enough so that we
can use it.

This means for you, that rpm will no longer use the %__find_provides and %__find_requires macros. Some packages redefined those macros to be able to filter the generated dependencies.
This will no longer work in rpm-4.9.0. Instead, support for
dependency filtering was added to rpm…”

GNOME 3

GNOME 3 has now hit Factory as well and Vincent Untz explained how to fix failures due to the large push.

Linux Kernel 2.6.39

This update was a “boring” update – nothing broke AFAIK ;), so I hope it’s a solid version. Users will benefit from the new features in it. 2.6.39 is the first kernel without the Big Kernel Lock at all!

Packaging Changes

Besides new software, also new ways of handling it get introduced. The following catched my eyes:

Rpmlint update

Ludwig Nussel updated rpmlint to version 1.2 and explained the new warnings about packaging of rpm packages – and what to do about them.

Changing the process of Factory submissions with the Open Build Service

Now with every submission to Factory scripts are run automatically that do two different reviews before the package goes to human check-in review:

  • The “legal-auto” review checks the updated package for changes in licenses.
  • The “factory-auto” review checks that the updated package builds actually in the devel project – and if not, rejects it.

The “legal-auto” review has quite a long backlog at the moment and Jürgen is working on moving some of the checks to rpmlint or osc checks – so that the packager notices and fixes them before submission to Factory.

Also, you can now submit packages to Factory even if you are not the maintainer of the package but in this case the maintainer (packager) gets a review request to review that the package really can go to factory and thus a plea to packagers to handle their review requests.

openSUSE Conference

The openSUSE Conference is this year co-located with the SUSE Labs conference. Join us to present and discuss also Factory related topics. The Call for papers is open now!

I’m interested on feedback on this article – should I start a series?

Kraft 0.43 Release

May 26th, 2011 by

Kraft helps in the officeYesterday I did a new release of Kraft, the KDE application to create and manage business documents in the small enterprise. It is version 0.43, the former one was 0.42, release in april 2011. Both releases, where the latter is a kind of maintenance release of the first are the result of a comparable high development effort of the underlying code in catalog handling and document lists in Kraft.

The document lists consisting of a latest, complete and time sorted view are now fully based on one Qt interview model feeding the views. That was a step because the original code was based on Qt3’s treewidget code. The result is convincing: the time needed to build up all views with a couple of thousand documents went down from around 20 seconds with the old implementation (which of course was not optimized) to almost nothing now. A nice result.

The catalog management got also a fundamental change, it can handle an arbitrary depth of catalog chapters now instead of only one. That makes a catalog chapter hirarchie in which templates can be moved around by drag and drop. Complete sub chapters can now be moved now from the catalog to the document quickly to speed up the assembly of documents covering standard workflows. Moreover this change in the underlying catalog data structure was an important prerequisite to implement reading of standard catalog formats such as DATANORM in later releases.

Krafts development is still going slowly, but steadily. There are quite some ideas on how to move on with Kraft:

  • Kraft Mobile – spin off a mobile app working on the new form factors providing useful functionality
  • support for DATANORM and friends, which would allow reading standard template catalogs provided by suppliers.
  • Alkimia support which would head into accounting functionality together with the other KDE financial applications
  • continue on shared Kraft, which utilizes the Owncloud project as a document and catalog sharing platform
  • support sub documents and more structured documents in Kraft
  • more project management capabilities in Kraft

All of these ideas are interesting and quite some work. I haven’t decided yet. If you think you want to influence Krafts future, let me know your arguments, most preferably on the Kraft mailinglist. If you even feel like you want to work on an interesting KDE application, please let me know, I’d be happy to share everything :)

LibreOffice and European Portuguese!

May 25th, 2011 by

For you, proud European Portuguese speaker that is looking for an Orthographic corrector to use with your flavored Office Suite (Libre Office)! Shed no more tears… Here you can find them… One for pre-Orthographic Treaty and as alternative the one which follows the Orthographic Treaty…

<irony>
Even though:

* … the Portuguese speaking market is the 6th biggest in the world;
* … the Portuguese language is the 5th most used in the Internet (yes, ahead o Arabic and French);

We are not visible enough for LibreOffice to include the required stuff for our language… Lets do this before Ubuntu… bnc#688200.

</irony>

GSoC – new osc user interface proposal

May 23rd, 2011 by

Hi,

as a part of our Google Summer of Code Project to cleanup osc our
first task was to define a new commandline user interface for osc.
The current user interface is quite “inconsistent” (with regard to
the expected arguments for different commands) and has some other
“flaws”.
Here are some examples to show some flaws of the current user
interface:

* inconsistent ui:
– osc results project package –repo repo –arch arch
– osc rebuild project package repo arch
– osc build repo arch
– osc ls project package repo arch -b
– osc ls project package -r repo -a arch -b
– osc undelete project package_1 … package_N
– osc rdelete project package_1

* counterintuitive commands:
– osc abortbuild project package
– osc abortbuild project package repo arch
– osc abortbuild (in a package working copy)
– osc abortbuild –repo repo –arch arch (in a package working copy)
– osc abortbuild repo arch (in a package working copy)
=> treats “repo” “arch” as “project” “package”

* “duplicated” commands:
– diff, rdiff
– buildlog, remotebuildlog, localbuildlog
– delete, rdelete, rremove

Additionally we support lots of commands and the output of
“osc –help”is quite long. In order to tackle this problem we decided
to introduce “groups” with subcommands, for instance:
attribute list
attribute create…
attribute set…

As a result we get rid of “god commands” (commands which supported
lots of different options for different things (like osc meta)) and
the new commands are easier to use because they support less arguments
and/or options (note: this doesn’t mean we lose functionality – the
functionality is just moved to another command/command group).

The attached table is just a _proposal_ for a new commandline user
interface.

Some additional explanations:

The biggest change with regard to our current user interface is the
introduction of an url-like syntax:
For example:
osc ls api://project/package
instead of
osc ls project package

In this case “api” means that the request is issued to the default
apiurl (in most cases https://api.opensuse.org) which can be
configured in the ~/.oscrc.
To issue the “list” request to a different obs instance one can use:
osc ls https://api.somehost/project/package
or
osc ls alias://project/package
“alias” is an alias for this apiurl which can be configured in the
~/.oscrc.

If you see this url-like syntax for the first time you might think
that it makes things much more complicated (and even more to type)
but it is advantageous:

– in most cases it is obvious if a command is a remote command or
local working copy command
– this way we get rid of ambiguities:
Suppose we support the following command (“<foo>” indicate that
“foo” is an optional argument):
binaries get api://project/package <repo/arch>
binaries get <repo/arch>
(if $PWD is a package working copy
the project and package arguments will be read from it)

Possible invocations are:
osc binaries get api://foo/bar standard/i586 # get all binaries
for this repo and arch
osc binaries get api://foo/bar # get all binaries for all repos
and all arches

# now suppose $PWD is a package working copy:
osc binaries get standard/i586 # get all binaries for this repo
and arch (project and package are read from the working copy)

osc binaries get api://foo/bar # gets all binaries for all repos
and all arches (project is “foo” and package is “bar”)

In the latter invocation we’re still in a package working copy
but ignore it and use the project and package arguments which
were specified.

Note: in this case a special (like the url-like) syntax is required
otherwise osc is unable to distinguish between a project/package and
repo/arch argument.

Once again this is just a _proposal_ – feedback is very welcome!
(please send the feedback to the opensuse-buildservice@opensuse.org mailinglist – thread)

Marcus

init, list, meta, attribute, request, submitrequest, review, link, copy, maintenance, branch, delete, undelete, diff, checkout, status, add, addremove, commit, update, resolved, distributions, results, buildlog, buildmeta, build, chroot, log, service, abortbuild, rebuild, binaries, search, my,
importsrcpkg, person, cat, less, repair, pull, signkey, vc, mv, config, revert, api, aggregate, mkpac, setlinkrev, linktobranch, detachbranch

setlinkrev, linktobranch and detachbranch might be grouped into group “other”.
Deleted commands:

cmd replacement reason
deleterequest args request create –delete args
reqeuestmaintainership args request create –role maintainer args
changedevelrequest args request create –changedevel args
request approvenew project <package> request –interactive-review could be used (but it’s no real replacement)
request log id request show id –log
linkpac link
copypac copy
releaserequest maintenance releaserequest
createincident maintenance createincident
maintenancerequest maintenance request
mbranch maintenance branch
getpac use branch
rdelete delete
updatepacmetafromspec
rdiff diff
linkdiff no replacement atm (current implementation partly broken); diff could support it
repourls isn’t needed IMHO
prjresults results
remotebuildlog buildlog
localbuildlog buildlog –local
buildinfo buildmeta info
buildconfig buildmeta config
triggerreason buildmeta triggerreason
dependson buildmeta dependson
buildhistory buildmeta history
jobhistory buildmeta jobhistory
info not needed anymore
getbinaries binaries get
wipebinaries binaries wipe
list –binaries binaries list
search –binary binaries search
bugowner no real replacement use person maintainer -b (if we support this)
maintainer person maintainer
maintainer project –add user –role role person add api://project role user
maintainer project –delete user person delete api://project user
whois person meta
meta user person meta
cat/less http://api/source/project/package/file not needed (IMHO)
repairlink repair link
repairwc repair wc
signkey signkey it’s not context-sensitive anymore
rremove do we really need this?
aggregatepac aggregate
develproject meta meta should display the xml in a nice way so that it’s easy to see whether a develprj is defined or not
repositories meta meta should display the xml in a nice way so that all repos are displayed

new commandline user interface

init

cmd subcmd prj wc pkg wc params/opts note
init api://project
init api://project/package

list

cmd subcmd prj wc pkg wc params/opts note
ls x list all remote packages for the wc project
ls x list all remote files for the wc package
ls api://
ls api://project
ls api://project/package
ls api://project/package/file just for backward compatibility

meta

cmd subcmd prj wc pkg wc params/opts note
meta x shows/edits project meta
meta x shows/edits package meta
meta api://project
meta api://project/package
meta api://project/_prjconf

attribute

cmd subcmd prj wc pkg wc params/opts note
attribute is not context sensitive
attribute list api://project show all attributes
attribute list api://project attribute show specific attribute
attribute set api://project attribute newval set attribute to newval
attribute create api://project attribute create new attribute
attribute delete api://project attribute delete attribute
attribute list api://project/package show all attributes
attribute list api://project/package/binary show all attributes – /binary works for all commands below, too
attribute list api://project/package attribute show specific attribute
attribute set api://project/package attribute newval set attribute to newval
attribute create api://project/package attribute create new attribute
attribute delete api://project/package attribute delete attribute

request

cmd subcmd prj wc pkg wc params/opts note
request is not context sensitive
request create –submit api://project/package api://tgt_projet/<package>
request create –submit api://project/package api://tgt_projet/<package>
request create –changedevel api://project/package api://tgt_projet/<package>
request create –role role user api://project/<package>
request create –grouprole role group api://project/<package>
request create –bugowner user api://project/<package> alternatively we treat bugowner as a “role” and use –role bugowner…
request create –delete api://project/<package>
request list api://<project>/<package> list all/project/package requests
in the following we support both: “api://id” and “id” (if the latter format is specified the default apiurl is used – regardless if the cmd is executed in a wc)
request show api://id apart from –brief also support –log which just shows the statehistory + current state
request supersede api://id api://supersede_id
request accept api://id
request decline api://id
request revoke api://id
request reopen api://id
request wipe api://id
request checkout (x) api://id if the package’s package belongs to the wc’s project the package will be added to this project (if it already exists an error will be printed)

submitrequest

cmd subcmd prj wc pkg wc params/opts note
submitrequest x semantic change: creates a sr for all local packages (instead of all remote)
submitrequest x wc has to be a source link
submitrequest x api://tgt_project/<tgt_package>
submitrequest api://project/package api://tgt_project/<tgt_package>

review

cmd subcmd prj wc pkg wc params/opts note
review accept api://id
review decline api://id
review reopen api://id
review susersede api://id api://supsersede_id
review add api://id –user user –group group –package package –project project at least one option is required
review list api://<project>/<package> just for convenience; “request list –state review” should lead to the same result

link

cmd subcmd prj wc pkg wc params/opts note
link api://link_project api://project
link api://link_project/link_package api://project/&tl;package>

copy

cmd subcmd prj wc pkg wc params/opts note
copy api://copy_project api://project could be supported
copy api://copy_project/copy_package api://project/&tl;package>

maintenance

cmd subcmd prj wc pkg wc params/opts note
maintenance releaserequest x
maintenance releaserequest api://project
maintenance createincident <api://project>
maintenance request api://project <api://tgt_project>
maintenance branch package <tgt_project> XXX: this voilates the url schema

branch

cmd subcmd prj wc pkg wc params/opts note
branch api://project/package <api://tgt_project/tgt_package>

undelete

cmd subcmd prj wc pkg wc params/opts note
undelete api://project/<package>

delete

cmd subcmd prj wc pkg wc params/opts note
delete api://project/<package> multiple arguments can be specified
delete /path/to/package
delete /path/to/file

diff

cmd subcmd prj wc pkg wc params/opts note
diff x
diff x
diff /path/to/file multiple args are supported
diff /path/to/package
diff /path/to/project
diff api://project/package
diff api://project/package api://original_project/original_package

checkout

cmd subcmd prj wc pkg wc params/opts note
checkout api://project/<package> checking out a file is not supported anymore
checkout x package adds the package to the wc
checkout x package adds the package to the wc

status

cmd subcmd prj wc pkg wc params/opts note
status x
status x
status /path/to/project_or_package_or_file multiple arguments are supported

add

cmd subcmd prj wc pkg wc params/opts note
add /path/to/dir_or_file multiple arguments are supported
add URL create a _service file

addremove

cmd subcmd prj wc pkg wc params/opts note
addremove x
addremove x
addremove /path/to/package multiple arguments are supported

commit

cmd subcmd prj wc pkg wc params/opts note
commit x
commit x
commit /path/to/project_or_package_or_file multiple arguments are supported

update

cmd subcmd prj wc pkg wc params/opts note
update x
update x
update /path/to/project_or_package multiple arguments are supported

resolved

cmd subcmd prj wc pkg wc params/opts note
resolved /path/to/file multiple arguments are supported

distributions

cmd subcmd prj wc pkg wc params/opts note
distributions api://

results

cmd subcmd prj wc pkg wc params/opts note
results x
results x
results api://project/<package>

buildlog
if repo/arch is not specified the config values will be used (default_repo, default_arch)

cmd subcmd prj wc pkg wc params/opts note
buildlog x <repo/arch>
buildlog x <repo/arch> –local
buildlog api://project/package <repo/arch>

buildmeta
if repo/arch is not specified the config values will be used (default_repo, default_arch)

cmd subcmd prj wc pkg wc params/opts note
buildmeta info x <repo/arch> <build_descr> distingiush between repo/arch build_descr, /arch build_descr via the file extension of build_descr
buildmeta info api://project/package <repo/arch> <build_descr> distingiush between repo/arch build_descr, /arch build_descr via the file extension of build_descr
buildmeta config x <repo/arch> <build_descr>
buildmeta config api://project/package <repo>
buildmeta triggerreason x <repo/arch>
buildmeta triggerreason api://project/package <repo/arch>
buildmeta dependson x <repo/arch>
buildmeta dependson api://project/package <repo/arch>
buildmeta log x <repo/arch> same as buildlog (just for consistency)
buildmeta log x <repo/arch> –local same as buildlog (just for consistency)
buildmeta log api://project/package <repo/arch> same as buildlog (just for consistency)
buildmeta history x <repo/arch>
buildmeta history api://project/package <repo/arch>
buildmeta jobhistory x <repo/arch>
buildmeta jobhistory x <repo/arch>
buildmeta jobhistory api://project/<package> <repo/arch>

build
if repo/arch is not specified the config values will be used (default_repo, default_arch)

cmd subcmd prj wc pkg wc params/opts note
build x <repo/arch> <build_descr>

chroot
if repo/arch is not specified the config values will be used (default_repo, default_arch)

cmd subcmd prj wc pkg wc params/opts note
chroot x <repo/arch> <build_descr> build_descr is not needed for the command itself

log

cmd subcmd prj wc pkg wc params/opts note
log x
log x
log api://project/<package>

service

cmd subcmd prj wc pkg wc params/opts note
service run x <service_name>
service disabledrun x
service remoterun api://project/package

abortbuild
if repo/arch is not specified the config values will be used (default_repo, default_arch)

cmd subcmd prj wc pkg wc params/opts note
abortbuild x <repo/arch> to abort all builds specifiy –all
abortbuild x <repo/arch> to abort all builds specifiy –all
abortbuild api://project/<package> <repo/arch> to abort all builds specifiy –all

rebuild
if repo/arch is not specified the config values will be used (default_repo, default_arch)

cmd subcmd prj wc pkg wc params/opts note
rebuild x <repo/arch> to rebuild all packages specifiy –all
rebuild x <repo/arch> to rebuild all packages specifiy –all
rebuild api://project/<package> <repo/arch> to rebuild all packages specifiy –all

rebuild
if repo/arch is not specified the config values will be used (default_repo, default_arch)

cmd subcmd prj wc pkg wc params/opts note
binaries get x <repo/arch> to get all binaries specifiy –all
binaries get x <repo/arch> to get all binaries specifiy –all
binaries get api://project/<package> <repo/arch> to get all binaries specifiy –all
binaries list x <repo/arch> to list all binaries specifiy –all
binaries list x <repo/arch> to list all binaries specifiy –all
binaries list api://project/<package> <repo/arch> to list all binaries specifiy –all
binaries wipe x <repo/arch> to wipe all binaries specifiy –all
binaries search api://<project> search_term
binaries wipe api://project/<package> <repo/arch> to wipe all binaries specifiy –all

my

cmd subcmd prj wc pkg wc params/opts note
my requests
my submitrequests
my projects
my packages

search

cmd subcmd prj wc pkg wc params/opts note
search search_term

importsrcpkg

cmd subcmd prj wc pkg wc params/opts note
importsrcpkg x /path/to/srpm

person
For groups we can add a new “group” command

cmd subcmd prj wc pkg wc params/opts note
person meta api://username <–edit>
person maintainer api://project/<package> show maintainer of the project/package
person maintainer api://project/<package> show maintainer of the project/package
person add api://project/<package> user role
person delete api://project/<package> user <role>

cat

cmd subcmd prj wc pkg wc params/opts note
cat api://project/package/file

less

cmd subcmd prj wc pkg wc params/opts note
cat api://project/package/file

repair

cmd subcmd prj wc pkg wc params/opts note
repair link x
repair link api://project/package <api://into_project/<into_package>>
repair wc x
repair wc x

pull

cmd subcmd prj wc pkg wc params/opts note
pull x

signkey

cmd subcmd prj wc pkg wc params/opts note
signkey api://project

vc

cmd subcmd prj wc pkg wc params/opts note
vc

mv

cmd subcmd prj wc pkg wc params/opts note
mv x filename new_filename should we support this for packages, too?

config

cmd subcmd prj wc pkg wc params/opts note
config section option
config section option value

revert

cmd subcmd prj wc pkg wc params/opts note
revert x
revert /path/to/file multiple arguments are supported

api

cmd subcmd prj wc pkg wc params/opts note
api api://path/to/something

aggregate

cmd subcmd prj wc pkg wc params/opts note
aggregate api://project/package api://tgt_project/<tgt_packge>

mkpac

cmd subcmd prj wc pkg wc params/opts note
mkpac x package_name

setlinkrev

cmd subcmd prj wc pkg wc params/opts note
setlinkrev x
setlinkrev api://project/<package>

linktobranch

cmd subcmd prj wc pkg wc params/opts note
linktobranch x
linktobranch api://project/package

detachbranch

cmd subcmd prj wc pkg wc params/opts note
detachbranch x
detachbranch api://project/package

(please send the feedback to the opensuse-buildservice@opensuse.org mailinglist – thread)

Unity 2D to enter GNOME:Ayatana soon…

May 19th, 2011 by

In the past days I’ve been packaging and fixing some issues on Unity 2D for inclusion on the GNOME:Ayatana repository in the openSUSE Build Service.

This gave me an excellent opportunity to test a few components share by both, Unity and Unity 2D, which is the case of ‘unity-place-applications’ and ‘unity-place-files’, both using Zeitgeist which is already in Factory for the upcoming openSUSE 12.1. We thank the integration of this packages to Federico Quintero. Thanks Fred.

A few more additional packages need some care and once they get updated and tested they will be uploaded to GNOME:Ayatana, at which time I will provide an installer (1-Click) for those willing to test Unity-2D. Unity 2D will be the first application to use the indicators I have prepared in the past which all all found working, except 1, the AppMenu (strangely it works on GNOME2 panel without issues).

This is how Unity 2D looks like. There are transparencies because I enabled ‘composite’ on metacity, which works very nicely. As far as I could understand, the developers of Unity 2D are also looking into implementing Compiz with Unity 2D, which would be sweet.

Unity introduces the ‘dash’ which is pretty much the following screen. Transparencies are enabled (though metacity composite) and the notification bubble belongs to NotifyOSD (already present in openSUSE 11.4 as optional). This is one of the three issues I have to fix, the icons displayed on the dash should have text underneath, it’s not showing. The top icons are quick links to Program Categories and the ones bellow are the default applications which are setup in GNOME.

The launcher panel on the side auto-hides, and seems to be working. The three icons displayed in last are respectively: Workspace selector, applications menu and files. Everything seems to be working with them, and the 2 last are components shared with Unity, and they both rely on Zeitgeist. Here’s a few captures of what they do…

There’s also a feature from Unity which is cute… The title artifact of the decorator window (metacity, which required a few patches) is removed and implemented on the top bar when the window is maximized. Sadly for me the AppMenu (menu proxy) isn’t working properly, this is another thing that needs fixing…

This should cover pretty much the functionality that is available currently. There’s a few issues still remaining before I can push this to GNOME:Ayatana:

- I tried not to have the need to patch gnome-session, but since Unity relies on the Session Indicator to have this functionality, gnome-session will need to be patched (should be ok, because it also requires the backport patch for  defining –sessions for openSUSE 11.4).

- Unity 2D itself relies on a few gconf hacks that should be on a schema file. I’ve talked to upstream and this is planned already, so once it’s release, that’s when it will be published.

- There’s one issue also with backgrounds and workspace switcher… unfortunatly the workspace switcher only renders wallpapers if they are in image format (no .xml stuff), so this can turn some wallpapers not to render, which eventually ends up in the background of the switcher being the one defined in GNOME as solid color.

So the order of TODO’s for GNOME:Ayatana is pretty much this one:

1. Implement dependencies and then Unity 2D;
2. Make sure Compiz is well implemented, because Unity will require Compiz at it’s best shape;
3. Make sure nux and other twisted dependencies are properly implemented;
4. Implement Unity itself;

This are the latest news for GNOME:Ayatana…

A few improvements…

May 18th, 2011 by

A lot more to fix...

Advancing with GNOME:Ayatana repository

May 17th, 2011 by

Last week I’ve received an email from Bruce Byfield asking a few questions about this project. I’ve replied honestly as I would to anyone, I’ve faced several issues, and it sounded wise to me to hold a bit this. Since the Beta release of Natty that I’m following a technology forum in Portugal (over 150.000 users) and making a few notes on what peoples perceptions are about Unity and Natty.

From what I see amongst this segment of the Linux users in my country, it’s interesting… While legacy users are moving away from Ubuntu to other alternatives seeking GNOME3 (no one seems to be moving from GNOME/Unity to KDE), others are satisfied with Unity. The biggest problem with Natty users so far comes regarding Networking issues and hardware compatibility… and once more Ubuntu’s kernels seem to be driving some people to desperation with the classical MCE’s.

A few days (4 days ago), Compiz 0.9.5 has been released. I’ve taken a look on the Ubuntu package and the patch level has dropped substantially, which points that upstream has absorbed most of them. Dominique already has 0.9.5 prepared on X11:Compiz (though the version needs a bump on the spec) and I’m going to test them out and start branching them over to GNOME:Ayatana during the next days and depending on the availability of reviews. This should be peaceful.

For this repository I’m going to enable a small pattern to provide a simple 1-Click Installer for Compiz alone, this means that people will be able to test the patched version of Compiz in which Unity will be build upon in the future.

After Compiz is established on GNOME:Ayatana, I’m going to get back to Unity and prepare Unity2D for deployment (being Unity a task for the future).

Now if some people wonder why all of this innactivity? The answer is simple… GNOME3 was being prepared and launched, and it deserved all the spotlights! Now that GNOME3 has proudly established itself on it’s segment and despite the press attacks, the communities I keep tracking, I see what seems to be a substantial increase of interest on GNOME3. I would personally consider GNOME3 launch a success.

openSUSE on the Linuxtag 2011

May 16th, 2011 by

around thirty members of the openSUSE project are just back from a fife days visit of Linuxtag in Berlin, the largest Linux specific event in Europe. We were crowding the openSUSE booth and were giving fourteen talks, took part on a key note like panel discussion, the usual distro battle and delivered the well known Booster workshops on the booth. Here is a little very personal log.

A SUSE grafity bag made on LinuxTag 2011We had a very nice booth, large and at a nice place. We had the chance to tell lots of people about openSUSE and where it is heading to. I heard much good feedback, about the distribution on the one hand, but also for the project and how it evolves. Slowly we seem to get a good message out and users and peers from the FOSS community get and appreciate it. Very good to experience that.

Of course we also had good fun at the booth andgave some interesting workshops in pipe cleaner arts and grafity for example.

Some other specific things that stick to my mind:

I went to a talk about Icinga, a system for open source monitoring. A very good talk about an obviously great system with a very awake community. Good to see the hands on approach of them. Interestingly enough, after the talk somebody asked why they did choose PHP as programming language instead of something cool like rails. I could not resist to tell about that at least I often thought about if it hadn’t been better to do the OBS in PHP instead of Rails simply because more people know it. Not appreciated ;-)

Another talk I liked was the fly over Qt and its recent past and future, delivered by Daniel Molkentin. Thoughts about Qt 5 were published a few weeks ago and Danimo outlined these again, also showing some nice demos of the upcoming Qt Quick and more.

From Vincent I saw a very good talk about collaboration between distros where he came up with an impressive list of activities where we’re already collaborate and proposals for more. Sad to see only few people in the audience. I missed Vincents other one about GNOME 3, but there is a nice Interview with him done at LT about that topic.

Apart from talks I saw KDE Active the first time real on a kind of Weetab on the KDE booth. Definetely cool, hopefully applications will catch up and being ported to this kind of platform. I am sure users will seek out for more than weather forecast apps sooner or later.

On saturday a collegue from the Gentoo Project approached me and told me that his team is actively working on a Smolt feature to also track the list of installed software of a system. We also use Smolt in openSUSE and we also have Feature #305877 asking for that kind of functionality, so I think we should jump on that train to support that effort. Nice idea, volunteers welcome!

Yes, and there also was some sports on Linuxtag: The Sportsfreunde der Sperrtechnik had a booth and were giving workshops on lock picking. I attended, but was not successful so far, need more practising ;-)

Apart from that I have to say that I was a bit disappointed by this years LinuxTag. I had the feeling that the number of visitors did not meet the expectations of the most exibitors and presenters. The hallways were really relaxed most of the time. Furthermore, the number of not so impressive talks I saw was comparably high. The official numbers however do not support my feeling, so maybe I am wrong.

Anyway it was big fun again. I like to thank you all for your share which made Linuxtag 2011 a great success for openSUSE.