Entries by Harald Sitter

Note to me, myself and I: FAQs should be listed somewhere to save me the daily headache....

Is amarok-nightly for openSUSE published yet?
No, I'll try to get a repository outside of my personal home one and build for openSUSE 11.0, after a couple of tests amarok-nightly for openSUSE can go live.

Why is there no amarok-nightly for openSUSE 11.0 to be tested?
Because I am preparing for exams, so I have no time for build-dependency magic, and because I will only build for openSUSE 11.0 once the above stated reason is sorted out. However, apparently the 10.3 packages work just fine on 11.0 as well (hooray for good packagin

Why is amarok-nightly for openSUSE not built nightly?
No neon package gets built nightly as long as it is being tested. Nightly builds will start once openSUSE packages are published in an own repository.

Does kde-nightly for Kubuntu include debug symbols?
No, neither does amarok-nightly. The packages are built with debugging enabled, a packaging script however strips them for some reason I forgot. In fact I tried adding -dbg packages earlier on, but that didn't work for some strange reason. The good news however is: I will digg into this soonish. After all a good description on how to reproduce is almost as good as a good backtrace

Can we get a foobar package for kde-nightly?
Feel free to drop ideas at the mailing list, but keep in mind that the build resources on Launchpad are pretty limited, so kdepim or koffice are probably not going to get in... at least for now. In general the current amount of packages is not going to grow a lot - I might only add kdeplasmoids some time soon, but that's about it.

Do you plan to integrate more applications into kde-nightly?
See above.

How do I compile stuff against kde-nightly?
This is a bit tricky - you can take a look at the neonmake script in amarok-nightly-tools to get an idea. I will include some proper buildscripts later on for use with kde-nightly and amarok-nightly.

Why is there no kde-nightly for openSUSE?
The openSUSE KDE guys do a great job on maintaining their own KDE snapshot packages. So launching a kde-nightly stack would be rather pointless, right? Duplicated effort and all..

..it's that time again, when I announce something new, which isn't new at all due to testing

Since amarok-nightly is a huge success ....

Project Neon now also includes kde-nightly builds for Kubuntu!

Currently available are kdebase, kdemultimedia, kdegraphics, kdenetwork and kdesdk

Now my dear Kubuntu users, you can: develop, debug, fix, test, promote and break your system
Have fun, and in case something goes wrong: blame KRF in #amarok.neon.

Misc:

• Thanks to everyone who helped testing kde-nightly!
  
• As seen above, Neon now has a shiny IRC channel - YAY \o/
  
• amarok-nightly for openSUSE is undergoing testing, if you want to join the fun -> #amarok.neon
  
• I am now member in the elite Oxygen Club -> Video
• Because I got loads of stuff to do this post is quite short
  

THANK YOU!

Back at home (finally). I had to spend 7 hours at the Airport in Salzburg (that city with Mozart and classical music entertainment stuff) because I was far too drunk to drive home. Of course I didn't just drink coffee and hack on neon+kde... because one doesn't get much sleep @ LinuxTag, I decided to catch up on that: after sleeping on the table and in a bathtub, I ended LinuxTag 2008 with a quite long nap at the Airport, in the parking garage, in my car

Anyway. It was an awesome event, again!

In more interesting news ;-):

• Neon KDE nightly packages for Kubuntu are building right now (i.e. heading fast towards publishing)
• I hacked a bit on the openSUSE Build Service integration which is next on the todo
• Apparently I became MOTU Mentor (I really have no clue how this happened)
• Amarok 2 is pretty much like Nokia - connecting people
• Karaoke is fun
  

....sitting in front of my laptop, looking at launchpad because I was waiting for builds to finish.

Compile clusters are so much nicer -.-

I love LinuxTag!

Stephan already blogged about how I was sleeping on the table.
So, here comes the background story:
After hours of hard work on Project Neon, an Amarok project to create nightly binaries of the latest Amarok version (I was sorting out some underlying issues in the base components in preperation for the openSUSE build service integration) , and as I was somewhat tired and it also was quite late in the night (or rather early in the morning) I choose to go to bed, though one shouldn't call that 'go', anyway, I didn't find one within the critical 10 seconds and chose the next best option: table + chair + me in between (I better don't tell you about the bathtub

My head is telling me that I got too much beer, so please excuse any spelling/grammar errors.
*looking for something to drink*

So...
First part of exams done! *yay*

But meanwhile Stephan invited kwwii for a bit of karaoke @ LinuxTag in Berlin. Kwwii of course agreed, which made Stephan wondering what will happen with records that go straight into my hands.

Well, first of all, I was practising karaoke yesterday (instead of learning for today's maths exam), so i am almost not the best karaoke singer ever

Anyway, the problem is, I have absolutely no sense of embarrassment so I will not only play eventual records on Radio Amarok, I will make them play 24/7 post them onthe 15 blogs I own and make them part of Project Neon.

That reminds me...
Neon is undergoing major refacturing, mainly in order to provide KDE nightly packages for Kubuntu (thanks to Kevin for pushing me so hard ) . Currently the source fetching component is work again (at least to the low profile testing I did) and the ubuntu component is close to be finished, so maybe apt-get soon tells us about kde-nightly

Just for the record, amarok-nightly will use a different package tree in order to preserve the current tree size.

Also new is the Phonon KCM bundling

For comments on comments from yesterday's post please read at the very bottom.

Let's get started with the technical details.


I am not at home right now, so I can't use my awesome paper+pencil-drawing(tm) for this explaination so bear with me in case some parts are a bit too complex (I actually created most code while operating on ballmer's peek, so it's as difficult for me to understand it as it might be for you

Anyway, the Neon framework, which is responsbile for the important parts of the nightly build process (I am considering building as not important here ) is written in Ruby (omg!).

http://websvn.kde.org/trunk/extragear/multimedia/amarok/supplementary_scripts/neon

Those of you who had a look at the upcoming Amarok release script will notice quite some similarities, most of them are caused by the fact that I absolutely hate scrolling in files so both source trees consist of some dirs and a couple of files named according to their use (surprise!).

Neon basically consist of 4 components which more or less rely on each other:

• neon.rb/libneon.rb as core component
• fetcher.rb is handling the collection of sources - more on that later
• publisher.rb is basically a wrapper for various ways of source distribution (e.g. tarball upload via FTP)
• distro.rb is a wrapper for distributions
  

neon.rb is responsible for very very very basic tasks, like setting necessary variables/constants, deciding which parts fetcher.rb actually has to fetch and how to publish the tarballs as well as which distribution processes to invoke (well, and cleanup work, but that might eventually get it's own file).

The first real work that is done, is checking which source trees need to be fetched (Qt gets built once a month - Strigi, TagLib, KDELibs and KDEBase are built once a week - and only Amarok is built once a day). Qt and KDELibs are actually just downloaded from the KDE snapshots on ftp.kde.org, the others get fetched directly from SVN (kdebase, or rather kdebaseruntime is a very cut down version which only ships with stuff that is necessary to run Amarok - the Xine Phonon backend for example).

In case all the SVN magic finished without problems the publishers would kick in and pull the newly created tarballs to some source distribution server (ftp/web server).

Then the distributions get their source packages. All distribution realted tasks are within special files located in neon/distros/ - the only working one is Kubuntu right now, but the processes are the same for most package types anyway.

First it pulls a copy of the source trees, and prepares everything as necessary for the package type/distribution, once that is done, it uploads to a remote build server (in case of Kubuntu this is done package by package to prevent complete meltdowns of the repository in case of an issue.

The most important part is that fetcher.rb created an array listing all fetched source trees (including their SVN revision number), so that all distributions can create an appropriate version string (Kubuntu is using DATE+svnREVISON-0amarok1).

There are a couple of guidelines all distribution packages should follow, for example they should require few to none maintenance. Ultimately the only reason one would have to edit the packaging, once everything works properly, is to make it work for new distribution releases.

Again Kubuntu as example: source packages are created according to the soure tarballs provided by fetcher.rb, they get thrown in a build deamon and run threw some automated cmake/kde build scripts and one gets _one resulting binary per source package.

Also, all packages should come with development headers and debugging symbols (I guess it's pretty obvious why that is

To sum that up: the most tricky part is probably to get the packaging right - general information for distributions are on the wiki page.

Everyone who is interessted in contribution, either contact me personally or use the Neon mailing list

------------------
Regarding Comments:

OpenSuse build service
Good thing, but it's really up to the maintainers where they want to build. For Kubuntu it makes most sense to use the Launchpad Personal Package Archive, for openSUSE however we will of course use the OSBS

Ubuntu -> Debian
Not much of a problem, with a bit of tuning they could actually rely on the same debian directories. The only tricky part is the remote build server, I guess using the openSUSE build service is a good idea?

-dev packages
The first public release of Neon had quite some dependencies on -dev packages, they are there because Neon is also meant to help developers join Amaork development. I removed them from the deps stack (strigi, taglib, kdelibs, kdebaseruntime, amarok) they should disappear from qt at some rebuild as well.
For the developers there will be a seperate package for all necessary -dev packages. Should be available soonish.

Missing Icons?
Should be fixed now.

Wrong Colouring!
I can't reproduce the issue, and actually thought it was fixed months ago. If anyone gets hold of information why this appears please leave a mail at the Neon mailing list

How seperate is it really?
Let's say it that way: the possability that Neon will cause issues with any existing KDE/Amarok/Qt configuration is close to not existing at all.
This also includes your collection.db

For comments on comments from yesterday's post please read at the very bottom.



Let's get started with the technical details.





I am not at home right now, so I can't use my awesome paper+pencil-drawing(tm) for this explaination so bear with me in case some parts are a bit too complex (I actually created most code while operating on ballmer's peek, so it's as difficult for me to understand it as it might be for you



Anyway, the Neon framework, which is responsbile for the important parts of the nightly build process (I am considering building as not important here ) is written in Ruby (omg!).



http://websvn.kde.org/trunk/extragear/multimedia/amarok/supplementary_scripts/neon



Those of you who had a look at the upcoming Amarok release script will notice quite some similarities, most of them are caused by the fact that I absolutely hate scrolling in files so both source trees consist of some dirs and a couple of files named according to their use (surprise!).



Neon basically consist of 4 components which more or less rely on each other:

• neon.rb/libneon.rb as core component
• fetcher.rb is handling the collection of sources - more on that later
• publisher.rb is basically a wrapper for various ways of source distribution (e.g. tarball upload via FTP)
• distro.rb is a wrapper for distributions
  
  

neon.rb is responsible for very very very basic tasks, like setting necessary variables/constants, deciding which parts fetcher.rb actually has to fetch and how to publish the tarballs as well as which distribution processes to invoke (well, and cleanup work, but that might eventually get it's own file).



The first real work that is done, is checking which source trees need to be fetched (Qt gets built once a month - Strigi, TagLib, KDELibs and KDEBase are built once a week - and only Amarok is built once a day). Qt and KDELibs are actually just downloaded from the KDE snapshots on ftp.kde.org, the others get fetched directly from SVN (kdebase, or rather kdebaseruntime is a very cut down version which only ships with stuff that is necessary to run Amarok - the Xine Phonon backend for example).



In case all the SVN magic finished without problems the publishers would kick in and pull the newly created tarballs to some source distribution server (ftp/web server).



Then the distributions get their source packages. All distribution realted tasks are within special files located in neon/distros/ - the only working one is Kubuntu right now, but the processes are the same for most package types anyway.



First it pulls a copy of the source trees, and prepares everything as necessary for the package type/distribution, once that is done, it uploads to a remote build server (in case of Kubuntu this is done package by package to prevent complete meltdowns of the repository in case of an issue.



The most important part is that fetcher.rb created an array listing all fetched source trees (including their SVN revision number), so that all distributions can create an appropriate version string (Kubuntu is using DATE+svnREVISON-0amarok1).



There are a couple of guidelines all distribution packages should follow, for example they should require few to none maintenance. Ultimately the only reason one would have to edit the packaging, once everything works properly, is to make it work for new distribution releases.



Again Kubuntu as example: source packages are created according to the soure tarballs provided by fetcher.rb, they get thrown in a build deamon and run threw some automated cmake/kde build scripts and one gets one resulting binary per source package.



Also, all packages should come with development headers and debugging symbols (I guess it's pretty obvious why that is



To sum that up: the most tricky part is probably to get the packaging right - general information for distributions are on the wiki page.



Everyone who is interessted in contribution, either contact me personally or use the Neon mailing list



------------------

Regarding Comments:



OpenSuse build service

Good thing, but it's really up to the maintainers where they want to build. For Kubuntu it makes most sense to use the Launchpad Personal Package Archive, for openSUSE however we will of course use the OSBS



Ubuntu -> Debian

Not much of a problem, with a bit of tuning they could actually rely on the same debian directories. The only tricky part is the remote build server, I guess using the openSUSE build service is a good idea?



-dev packages

The first public release of Neon had quite some dependencies on -dev packages, they are there because Neon is also meant to help developers join Amaork development. I removed them from the deps stack (strigi, taglib, kdelibs, kdebaseruntime, amarok) they should disappear from qt at some rebuild as well.

For the developers there will be a seperate package for all necessary -dev packages. Should be available soonish.



Missing Icons?

Should be fixed now.



Wrong Colouring!

I can't reproduce the issue, and actually thought it was fixed months ago. If anyone gets hold of information why this appears please leave a mail at the Neon mailing list



How seperate is it really?

Let's say it that way: the possability that Neon will cause issues with any existing KDE/Amarok/Qt configuration is close to not existing at all.

This also includes your collection.db

A least 5 people ask us every day when Amarok 2 will be ready and when it will be easy to install without compiling it - since yesterday we can tell them: there you go!

Project Neon makes it possible for YOU and me and everyone (kind of, at least

Neon is meant to provide nightly Amarok builds ....
which means that it generates new Amarok packages for various distributions (currently only Kubuntu, openSUSE is in the queue though) ever day so that everyone can install them for whatever reason (testing, checking out the latest development, ...).
... So the main aim of Neon is clearly to provide a way to install the latest Amarok development version.

After installing amarok-nightly you will find an entry in your application menu, I'd like to call that well integrated with the operating system ;-), but the nifty thing about it is, that amarok-nightly will run without problems along a production system, it is stored in a completely unrelated path and all configurations are (or rather should) be stored in it's own directory.

This makes it possible to check out Amarok 2 once a day while running Amarok 1 to get the usual music entertainment.

More information on Neon and how to use it are available on it's wiki page.

Later I will write a more technical post, explaining how it works and how to get other distributions supported.

Dear Tristan, I like further developed ideas, mostly, and I also like to develop ideas further.

...I just read such a further developed idea and since I like it a lot, I am goint to develop it further (normal process for me).

Tomorrow Amarok, Linux market leader in the Music Application segment, will announce something revolutionary.
We came to the decision that others know better and therefore we will sync our release schedule to Ubuntu, Linux market leader in the Home User Operating System segment. Our current model of partly time-based and partly feature-based release planing is apparently creating enormous inefficiency in the development of our high-quality software. Mainly because of this we will do 2 releases per year, each 2 days before Ubuntu releases a new version, so that the build servers have enough time to build the packages.
In order to join this with our very fast and feature rich development we will provide at least 25% new or changed code in a time-frame of one year (2 releases), we hope that by setting this minimal growth rate we are able to increase our userbase by 213% per year.
To support these alternations quality assurance will be reduced to a minimum as it can cause scaling issues in combination with this new concept.

This is however only the first step. In a long-term view we aim to breakup the underlying project of Amarok and become a 100% part of the Ubuntu project to share resources and create a strong leader in thew newly created market of Music Home User Appliaction Operating Systems. We also want to prevent our users from wasting half their life with compilation, so we will stop releaseing source tarballs but instead only offer Ubuntu DEB-files.

We will also suggest KDE and all the distributions, we have intensive collaboration with, to start a strong binding to the Ubuntu project as well, and possibly become part of it.

Watch out for the announcement and the moving of our structures from KDE/Amarok ones to Ubuntu/Launchpad.

A nice day wishes your soon-not-to-be-anymore-project-manager.

Dear Tristan, I like further developed ideas, mostly, and I also like to develop ideas further.



...I just read such a further developed idea and since I like it a lot, I am goint to develop it further (normal process for me).



Tomorrow Amarok, Linux market leader in the Music Application segment, will announce something revolutionary.

We came to the decision that others know better and therefore we will sync our release schedule to Ubuntu, Linux market leader in the Home User Operating System segment. Our current model of partly time-based and partly feature-based release planing is apparently creating enormous inefficiency in the development of our high-quality software. Mainly because of this we will do 2 releases per year, each 2 days before Ubuntu releases a new version, so that the build servers have enough time to build the packages.

In order to join this with our very fast and feature rich development we will provide at least 25% new or changed code in a time-frame of one year (2 releases), we hope that by setting this minimal growth rate we are able to increase our userbase by 213% per year.

To support these alternations quality assurance will be reduced to a minimum as it can cause scaling issues in combination with this new concept.



This is however only the first step. In a long-term view we aim to breakup the underlying project of Amarok and become a 100% part of the Ubuntu project to share resources and create a strong leader in thew newly created market of Music Home User Appliaction Operating Systems. We also want to prevent our users from wasting half their life with compilation, so we will stop releaseing source tarballs but instead only offer Ubuntu DEB-files.



We will also suggest KDE and all the distributions, we have intensive collaboration with, to start a strong binding to the Ubuntu project as well, and possibly become part of it.



Watch out for the announcement and the moving of our structures from KDE/Amarok ones to Ubuntu/Launchpad.



A nice day wishes your soon-not-to-be-anymore-project-manager.

It's that time of April again, Ubuntu/Kubuntu released the all new shiny versions of their distributions. This time the releaes is called Hardy Heron *woohooo*

So, what do we do when a new version is out?
Right, party!
Join the Halligalli Hummel Party(tm) in #kubuntu-devel and celebrate the latest Kubuntu release with us on 24-04-2008 @ 16UTC. Of course as party guest you should use the official party wallpaper -> this svg or png

Make sure not to miss the grand party kickoff!
We also have our own bar and a radio show, sponsored by Amarok, (maybe )

In case you just want to have some information about the release, head over to kubuntu.org

Finally: spread the word by bloging, twittering, talking, giving calls etc
GO GO GO!

It's that time of April again, Ubuntu/Kubuntu released the all new shiny versions of their distributions. This time the releaes is called Hardy Heron *woohooo*

So, what do we do when a new version is out?
Right, party!
Join the Halligalli Hummel Party(tm) in #kubuntu-devel and celebrate the latest Kubuntu release with us on 24-04-2008 @ 16UTC. Of course as party guest you should use the official party wallpaper -> this svg or png

Make sure not to miss the grand party kickoff!
We also have our own bar and a radio show, sponsored by Amarok, (maybe )

In case you just want to have some information about the release, head over to kubuntu.org

Finally: spread the word by bloging, twittering, talking, giving calls etc
GO GO GO!

http://daniel.holba.ch/5-a-day-stats/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Apparently kubuntu-de.org hit 1000 triaged bugs... as first team ever!!! jump party ... ah well, no time for partying, more bugs are waiting

Still it makes me proud to be part of such a wonderful community, not only Kubuntu-de.org but also Ubuntu as a whole, including all of *buntu.
Thanks to everyone who's showing that Kubuntu is a healthy part of the Ubuntu community!

...so much for the 'Kubuntu is a second class citizen' issue