Home Home > Packaging
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for the ‘Packaging’ Category

Day: Saturday 28, 2009

March 28th, 2009 by

The Day:

* Updated lynis: Sourcecode 1.2.5
* Updated libatlas3: Added compiler_error_ger_SSE.patch
* Released Translators Version from openSUSE Weekly News Issue #65
* Fixed Section “New/updated Applications” in the Trabslators Version

python-TurboGears2 alive and kickin’ on the build service

March 6th, 2009 by
Screenshot of TurboGears 2

Screenshot of TurboGears 2

It’s been quite a while since I last posted an update on the state of python-turbogears in the openSUSE build service. The TurboGears project currently has three branches open (which seems to cause more confusion that actually help people) – the 1.0 branch, the 1.1 branch and the 2.0 branch. Whereas newcomers are advised to install from the 1.0 branch and to develop web applications based on that branch, the truth is that most of the active development goes on in the 2.0 branch. TurboGears 2.0 is at beta7 stage right now – features are frozen and a release data is in sight for the big 2.0.

Without getting into the major differences between 1.0 and 2.0, many people on the TurboGears Google Group have expressed the opinion that the 2.0 branch, despite its beta suffix, is exceptionally stable and well suited to production deployment. One of the major obstacles facing people was how to actually install it. Because it requires some cutting edge packages which might not be standard fare for many distributions, it is recommended to install TurboGears2 (beta) in a virtual python environment using the virtualenv package. Once the new virtual environment is ready and activated, a simple easy_install will automatically install the TurboGears2 package and its requirements. This is well documented.

I got a bit fed up with the virtual environment setup – it worked fairly well, but I was constantly having to set up completely new virtual environments just to install another TurboGears web application. There is an option when using virtualenv, to make the entire virtual environment “mobile” (meaning that you can pack virtual environment plus web app off to another computer easily), but it wasn’t working for me.

Enter python-TurboGears2 on the openSUSE build service. It took me a couple of days to get all the dependencies in the correct versions and installing properly, but it looks as if it works now. As TurboGears2 will be in a more or less constant state of flux until the final 2.0 release, there will probably be quite a lot of work to do to keep the packages up to date, but it’s worth it for the simple zypper in python-TurboGears2 🙂 What I want to do now is to try creating a SUSE Studio based virtual appliance – that way practically any web app could be created and setup easily – and with a bit of elbow grease you could probably use apparmor etc to make it rock solid.

PS: it would be well cool if people would test the package

New/Updated Applications @ home:saigkill

March 4th, 2009 by

Hello Folks,

now following an List from my last updated/worked Packages:

  1. boinc-client 6.4.5 (last stable and recommended Version)
  2. boinctray 2.3
  3. kde4-skrooge 0.2.4 (also published in openSUSE:Factory:contrib and KDE:KDE4:Community)
  4. libatlas3 3.8.2 (also published in Education)
  5. libdbus++ 0.6.0
  6. libtinyxml0 2.5.3 (also published in openSUSE:Factory:contrib)
  7. libtktray1 1.1
  8. lynis 1.2.3 (also published in openSUSE:Factory:contrib)
  9. mountmanager 0.2.6 (also published in openSUSE:Factory:contrib and KDE:KDE4:Community)
  10. necpp 1.2.6+cvs20070816
  11. python-iCalendar 1.2 (also published in openSUSE_Factory:contrib)
  12. qantenna 0.2.1
  13. rkhunter 1.3.4 (also published in openSUSE:Factory:contrib)

Have a lot of Fun 🙂

openSUSE-like update repositories for third party projects

February 22nd, 2009 by

Starting with 11.0, the openSUSE-Education project hosts it’s own, separate update repository. This is our solution for the strategic decision not to use the openSUSE Build Service as repository for endusers but for development only.

So for production purposes, we always recommend to use our frozen repositories on http://download.opensuse-education.org/. But as “frozen” implies, the repositories there are frozen at the time, the openSUSE-Education team declares them as “Goldmaster” (which is the case for all except the 11.1 repo at the moment) – and no package update or changes happens for this repositories.

The openSUSE-Education team has relatively long development and testing cycles – but as everywhere, shi* happens, and so it might be that some of the packages in the frozen repository are broken or need a security fix. For this, we have created update repositories (for at least 11.0 and the upcomming 11.1 Edu-Release) which are disabled per default, but added to the system during installation of the openSUSE-Education-release  package. (Reason behind this decision: if an administrator installs openSUSE-Education in a school, he wants to “mirror” the update repositories and not point every client to the official ones. All a user has to do is to enable this update repository via YaST or via “zypper mr -e ‘openSUSE-Education Updates'”.

We’re using the “updateinfo.xml” file formal described in the openSUSE-Wiki. Currently, we’ve 5 package updates/fixes for 11.0 in the update repository – and this might grow over the time. The updates are shown in the current online-update-applets as “normal” updates like the openSUSE ones. Interestingly, the user can’t see if an update is from the official openSUSE or the openSUSE-Education update repository – even if we use a different “from” tag. Perhaps we have to “play” with the “release” or other tags: testing is needed as it looks like nobody tries this before…

Writing wrapper packages for server applications or a generic YaST module?

January 27th, 2009 by

As we get more and more PHP-, Perl- and other applications like openSIS, Koha, Moodle, … in the Education repository, the question turns up, how to package those applications “the right way”.

A normal user, who wants to use one of these apps, might just choose to install the package and has the problem how to proceed afterwards. openSUSE sadly has no “post config” scripts like Debian based distributions – even the SuSEconfig scripts are deprecated. So all a packager can currently do is:

  1. write a README.SuSE (which is already the case for many packages) and place it in /usr/share/doc/packages/<packagename>/README.SuSE explaning how to proceed
  2. sugget what the user always wants to do and do it via %post-script after the installation of the RPM
  3. combine 1&2 and point the user to a script in the README.SuSE 🙂
  4. write a YaST module which can be started during installation or afterwards
  5. any other option I missed (please inform me!)

For the Education project, I’m currently thinking about two ways to make the life of the admins easier.

First: think about “wrapper packages” around the normal packages. I’ll take moodle as example. The normal moodle package installs the php-scripts, an apache configuration and some other config stuff – but will not setup the complete moodle instance. So the user has to install the mysql database himself. An additional wrapper package can do this for him. This package comes with a SQL-Dump of the current moodle version (therefore requires the exact moodle version), and uses a stored mysql-root password to create a new database and insert the database-dump. If needed (for example: the user enables the “user LDAP-Auth wherever possible” checkbox in a (to be written) yast-edu module), additional tasks can be triggered by the wrapper package.

We can also think about calling a “generic” YaST module after installation of such a “needs postconfiguring” package. If we define a place (say: /var/adm/YaST/postinstall/) where packages can place a file containing some important questions to configure the application, and someone writes a YaST module which can be started, this would perhaps be “very cool”. If the user has entered his values, the YaST module can start one or more scripts (coming with the package) and feeds it with the entered values. The biggest questions for this solution:

  1. When should this YaST module be started? IMO it could be enough to let the user start it manually and select the package he wants to configure. => No adaptions of the current workflows is needed. But perhaps there are other options (like calling it via “SuSEconfig”)?
  2. Who can write such a module?
  3. Who defines the config syntax?

Think about a file like this:

<package name=”moodle”>
<questionpack type=”string” action=”/usr/share/moodle/scripts/install_database”>
<question arg=”1″ type=”string”>What’s the database password?</question>
<question arg=”2″ type=”string”>What should be the name of the new database (suggest: moodle)?</question>
<question arg=”3″ type=”string”>What’s the username of the new database user?</question>
<question arg=”4″ type=”string”>What’s the password of the new database user?</question>
</questionpack>

<questionpack action=”/use/share/moodle/scripts/configure_auth_backend” type=”selectbox”>
<question arg=”1″>What auth-backend should be used?</question>
<answer value=”1″>ldap</answer>
<answer value=”2″>mail</answer>
<answer value=”3″>passwd</answer>
</questionpack>
</package>

I think, there’s room for many enhancements in this area – what do you think ?

Should/Could we produce something like a “Windows-Installer” for openSUSE? Or is it enough to provide special “wrapper packages”? Or is “what was hard to write, should be hard to install” still a valid answer?

Build maemo-apps with openSUSE BuildService ? – It works !

January 27th, 2009 by

build serviceThe openSUSE Build Service is an open and complete distribution development platform. It’s the infrastructure for a development of the openSUSE distributions. But this powerful tool can do much more! The upcoming version 1.5 will also have cross-build support and thus be able to build e.g. ARM packages on x86 hardware .

maemo.org loko Maemo is the platform for mobile devices like the N810 and has been developed by Nokia in collaboration with many open source projects such as the Linux kernel, GNOME and many more. (more…)

100 packages in Contrib

January 26th, 2009 by

Last month we started a new project called Contrib. It’s a shiny new community repository for openSUSE. In opposite of specialized repository (eg. Security:), Contrib is universal. It doesn’t matters if your package is a desktop application, or a network tool. Every type of package is welcome.

Today, we celebrated a package number 100 (gparted)! Thanks to all involved folks!

One hundred packages doesn’t look like a big repository, but consider we are active about a month and half and this is an important milestone for us. The bigger repository should be more attractive for end users, and a package maintainers too.

Users wanted
Contrib release cycle is same as Factory, but we want to help users to use it now. So Contrib is also available for 11.1. So just add the repository and start to use it! It help us!

zypper ar http://download.opensuse.org/repositories/openSUSE:/Factory:/Contrib/openSUSE_11.1/ openSUSE_Factory_Contrib

Package/rs wanted
If you maintain some interesting package in your home: project (or elsewhere), please follow instructions – New packages to Contrib and add your package to Contrib, so many users of openSUSE would use it!

RPMLINT Wiki Side overworked

January 8th, 2009 by

I’m an new Packager in OpenSUSE BuildService, and i like this work. But if i would like to package for Factory, RPMLINT gives me any Errors or warnings. But these things to fix, are very difficult. Our Wiki Side for RPMLINT doesn’t contain many Error or Warningcodes.

But yesterday i’ve found an Side, with other Errorcodes from RPMLINT. Today i imported these Codes to our Wikiside http://en.opensuse.org/Packaging/RpmLint. I think it is not possible to list all codes on the Side. But i wish, that the side includes more Codes in the future.

No i would like to make an Call for contribution. If every Packager insert the codes, that he knows, we have an good library soon.

And on this Moment i would like to make an request about helping- Thank you all for the hard Work.

New Releases for 11.1 in home:saigkill

January 7th, 2009 by

Hello Folks,

in the last week i’ve build my repository (home:saigkill) for 11,1. This are the Packages:

– BOINC 6.4.5
– Mount Manager 0.2.5
– libatlas 3 – 3.8.1
– libnecpp0-1.2.6
– libqt4-4.4.3
– necpp 1.2.6
– Lynis 1.2.1
– necpp 1.2.6
– python-iCalendar 1.2
– qantenna 0.2.1
– kde4-skrooge 0.1.0 (i586 only)

Have a lot of fun 🙂

Testing “Scratch” – the easy programming language

December 7th, 2008 by

Some german teacher point me to “Scratch” a few weeks ago. This week, I tried to create a package for openSUSE.

The good news: Ubuntu people already tried to package scratch for debian – but they use a perl script, which installs scratch for each user – again, and again, and again….

Well – as Scratch runs via “Squeak”, which is available for openSUSE since a long time now, it took me just a few minutes to create a simple wrapper script calling squeak and loading the scratch image. The only things left to do:

  • unpack the scratch image (I currently use the ubuntu file for this – otherwise I have to unzip the exe file, let’s look at this for the next version)
  • add a desktop icon
  • add a desktop entry
  • place everything in the filesystem

ready.

As result, every user on a system with the scratch RPM can now run scratch without any further actions. Sometimes packaging can be so easy 😉

But, yes: that’s only packaging a binary into a RPM – normally, we want to compile the source so we have full control over the binary. If someone has a problem with this package, I might not be able to help, because I haven’t seen the source and therefore have no chance to help. But perhaps, with requests from Ubuntu and openSUSE users, the developers of scratch open their sourcecode to the public.

So: have fun, playing around with Scratch