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

targitter project – about OBS, tars and git

October 5th, 2015 by

In OBS we use source tarballs everywhere to build rpms (and debs) from.

This has at least two major downsides:

  1. Storing all old tar files takes up a lot of disk space
  2. OBS workflows with .tar files and patches are rather different and somewhat disconnected from the git workflows we usually use everywhere else these days. E.g. for the SUSE OpenStack Cloud team we have a “trackupstream” jenkins job, that pulls the latest git version into a tarball once every day.

Fedora already keeps their metadata in git, but only a hash of the tarball.

So as one first step, I used two rather different projects to see how different the space usage would be. On the slow side I used 20 gtk2 tarballs from the last 5 years and on the fast side, I used 31 openstack-nova tarballs from Cloud:OpenStack:Master project from the last 5 months.
I used scripts that uncompressed each tarball, added it to a git repo and used git gc to trigger git’s compression.

Here are the resulting cumulative size graphs:

gtk2 size graph
nova size graph

The raw numbers after 20 tarballs: for nova the ratio is 89772:7344 = 12.2 and for gtk2 the ratio is 296836:53076 = 5.6

What do you think: would it be worth the effort to use more git in our OBS workflows?

Do we care about being able to reproduce the original tarballs? While this is possible, it has some challenges in differing file-ordering, timestamps, file-ownerships and compression levels.
Or would it be enough if OBS converted a tarball into a signed commit (so it cannot be forged without people being able to notice)?

Do you know of a tool that can uncompress tarballs in a way that allows to track the content as single files, and allows to later re-create the original verbatim tarball, such that upstream signatures would still match?

AMD Catalyst 15.9 for openSUSE – new makerpm-amd-script is available

September 27th, 2015 by

AMD has released the new AMD Catalyst 15.9. My script replaces the existing packaging script with an updated packaging script. It supports up to Kernel 4.2. (Official support up to Kernel 3.19)

Important note: The first beta version of openSUSE Leap (future openSUSE 42.1) was released a few days ago. However, the AMD driver has not been adapted yet to the new upcoming openSUSE version. In the next days I will working on this and release a new update for this script.

Important note 2: After some experimentation with the GNOME Desktopmanager, unfortunately it does not work with the driver. Because actually something seems to be amiss. To this end, I will contact the AMD developers. As a workaround, I recommend for GNOME another Desktopmanager such as lightdm until the issue is fixed.

Resolved Issues:

  • [425910] Driver installation sometimes fails on Ubuntu 14.04.3
  • [424450] Company of Heroes® 2 – Game crashes while running the performance test
  • [424794] Middle-earth™: Shadow of Mordor – Corruption observed in game
  • [424882] DIRT® Showdown – Corruption observed in game
  • [425234] DIRT® Showdown – Game crashes after the loading screen
  • [424802] DOTA™ 2 – Application hang observed while exiting the game
  • [424255] AMD Catalyst™ Installer removing EGL links resulting in Xserver/Xorg load failure
  • [423471] Unable to switch desktop mode after installing AMD Catalyst™ driver
  • [423735] Renaming Counter-Strike: GO and other Steam game binary improves performance

Known Issues:

  • [419960]: Vari-Bright on some configurations is not decreasing brightness as expected

Link: AMD Catalyst 15.9 Release Notes

Downloads:

Installation guide (English):
http://en.opensuse.org/SDB:AMD_fglrx#Building_the_rpm_yourself

Bruno Friedmann will build the new RPM packages in the fglrx repository. Stay tune!

If you find any issue with the driver. Don’t hesitate to contact me. I am in contact with AMD and can forward your issue to the right place. Feedback are welcome.

A report of your system is very helpful beside your feedback. You can generate it with the script:
su -c 'sh makerpm-amd-15.9.sh -ur'

Have a lot of fun!

Sebastian
openSUSE member / Official AMD Packaging Script Maintainer for openSUSE
German Blog: openSUSE – proprietären Grafik-Treiber AMD Catalyst 15.9 als RPM installieren

AMD Catalyst 15.7 for openSUSE – new makerpm-amd-script is available

July 12th, 2015 by

AMD has released the new AMD Catalyst 15.7. My script replaces the existing packaging script with an updated packaging script. It supports up to Kernel 4.1. (Official support up to Kernel 3.19)

Important note: This driver supports also X-Server 1.17 on Tumbleweed. GNOME Desktopmanager (gdm) is working partially, so you need a workaround. Who has activated the automatic user login in GNOME and want to make a user change, they get a black screen on TTY-console and the login manager seems to be crashed. This issue can be solved when the automatic user login is disabled in GNOME.

For GNOME user with gdm: Execute the following command as root after the installation of the AMD driver and before restart the machine:
sh makerpm-amd-15.7.sh --install-gdm-fix

To revert the changes:
sh makerpm-amd-15.7.sh --uninstall-gdm-fix

New Features:

  • AMD PowerXpress support for laptops equipped with Intel 6th generation (Skylake) CPUs
  • Linux Platform Atomics & SVM Fine Grain Buffer support for Carrizo APUs
  • Multi-Device support for OpenCL 2.0

Resolved Issues:

  • [421317] Segmentation fault observed while launching some OpenGL games in RHEL7.1
  • [419365] Error message observed during installation through rpm package in RHEL 6.5, 7.0
  • [419162] System hangs while running Dying Light
  • [421858] clinfo could not recognize up to four GPU devices

Known Issues:

  • [419960]: Vari-Bright on some configurations is not decreasing brightness as expected

Link: AMD Catalyst 15.7 Release Notes

Downloads:

Installation guide (English):
http://en.opensuse.org/SDB:AMD_fglrx#Building_the_rpm_yourself

Bruno Friedmann will build the new RPM packages in the fglrx repository. Stay tune!

If you find any issue with the driver. Don’t hesitate to contact me. I am in contact with AMD and can forward your issue to the right place. Feedback are welcome.

A report of your system is very helpful beside your feedback. You can generate it with the script:
su -c 'sh makerpm-amd-15.7.sh -ur'

Have a lot of fun!

Sebastian
openSUSE member / Official AMD Packaging Script Maintainer for openSUSE
German Blog: openSUSE – proprietären Grafik-Treiber AMD Catalyst 15.7 als RPM installieren

Digital game distribution

July 8th, 2015 by

UnReal World RPG have come long way how it have been distributed digitally since it started on 1992. First it was on multiple BBS as Shareware application and if you ordered then it was delivered by 4 disks by mail and you copied them to your hard disk. It was pure DOS application at that time. Game author Sami Maaranen have been always modern about this kind of things you could send order by email or normal mail on late ’90. After millennium real digital revolution started. (more…)

AMD Catalyst 15.5 for openSUSE – new makerpm-amd-script is available

June 15th, 2015 by

AMD has released the new AMD Catalyst 15.5. Unfortunately AMD has forgot to update the packaging script. The new feature (SLED 12) is currently broken by the original AMD Catalyst 15.5. My script corrects this mainly issue with an updated packaging script. It included the Kernel patches for 4.0 and 4.1.

Warning: This driver based on an old development fork and does not support X-Server 1.17 on Tumbleweed. GNOME Desktopmanager (gdm) is also broken for the moment. My suggestion for you, stay on the latest AMD Catalyst 15.3 Beta.

New Features:

  • Support for SUSE® Linux Enterprise Desktop 12

Resolved Issues:

  • [417630]: Fixes the issue of discrete GPU not being powered off in Power-Saving mode on some PowerXpress AMD GPU + AMD APU platforms
  • [416499]: Fixes minor screen corruption when resuming from S3 caused by display hot plugging

Known Issues:

  • [419960]: Vari-Bright on some configurations is not decreasing brightness as expected

Link: AMD Catalyst 15.5 Release Notes

Downloads:

Installation guide (English):
http://en.opensuse.org/SDB:AMD_fglrx#Building_the_rpm_yourself

Bruno Friedmann will build the new RPM packages in the fglrx repository. Stay tune!

If you find any issue with the driver. Don’t hesitate to contact me. I am in contact with AMD and can forward your issue to the right place. Feedback are welcome.

A report of your system is very helpful beside your feedback. You can generate it with the script:
su -c 'sh makerpm-amd-15.5.sh -ur'

Have a lot of fun!

Sebastian
openSUSE member / Official AMD Packaging Script Maintainer for openSUSE
German Blog: openSUSE – proprietären Grafik-Treiber AMD Catalyst 15.5 als RPM installieren

AMD Catalyst 15.3 Beta for openSUSE – new makerpm-amd-script is available

April 8th, 2015 by

AMD has released the new AMD Catalyst 15.3 Beta. They have not yet released a public beta driver for all other distributions. It is currently available for Ubuntu. *sigh* So, it is a bit hard work to implement this in the makerpm-amd-script to replace the latest AMD Catalyst 14.12 with AMD Catalyst 15.3 Beta. So do not confused if the script downloads the AMD Catalyst 14.12. 🙂

Unfortunately there is no release notes from AMD. This update can solve the issue with PowerXpress but I can not really verified this because lack of such hardware.

Another side note I have implemented a workaround in the script to get the driver works with the GNOME Displaymanager + GNOME. It is a little cruel hack but it works for the moment. Thanks to the user that they posted the article in my blog. 😉

For GNOME user with gdm: Execute the following command as root after the installation of the AMD driver and before restart the machine:
sh makerpm-amd-15.3-beta.sh --install-gdm-fix
If you update the AMD driver, so the workaround does not work anymore. It is important that you do not delete the file /amd_xversion and is needed for the workaround.

To revert the changes:
sh makerpm-amd-15.3-beta.sh --uninstall-gdm-fix

Before I forget it: All user from openSUSE Tumbleweed can also install the driver. But remember, Tumbleweed is under heavy development. I can not guarantee that the driver works in the future yet.

Downloads:

Installation guide (English):
http://en.opensuse.org/SDB:AMD_fglrx#Building_the_rpm_yourself

The above named installation guide is only for the stable driver but you can adapt it for the beta driver.

Bruno Friedmann will build the new RPM packages in the fglrx repository. Stay tune!

If you find any issue with the driver. Don’t hesitate to contact me. I am in contact with AMD and can forward your issue to the right place. Feedback are welcome.

A report of your system is very helpful beside your feedback. You can generate it with the script:
su -c 'sh makerpm-amd-15.3-beta.sh -ur'

Have a lot of fun!

Sebastian
openSUSE member / Official AMD Packaging Script Maintainer for openSUSE

German Blog: openSUSE – proprietären Grafik-Treiber AMD Catalyst 15.3 Beta als RPM installieren

New Proprietary AMD/ATI Catalyst omega fglrx 14.12 (14.501.1003-1) rpm released

December 13th, 2014 by

Hey Christmas time around! AMD give us a new version of fglrx, and Sebastian Siebert just release his script yesterday night.
So I’ve prepared the new version available for openSUSE 11.4, 12.1, 12.2, 12.3, 13.1, 13.2 and Tumbleweed.
Sebastian’s script contain a special patch for supporting kernel up to 3.17 and 3.18 version.
I should also share Sebastian’s surprize about the fact that this version didn’t got a beta/rc cycle….

I hope this release will give better results for all of you who own an apu (especially the recent one), and also fix a number of issue with the hybrid chipset intel cpu/amd gpu embedded.

See below how to report issue on Sebastian blog.

It will be the last build for all openSUSE version below 13.1 (except if patches are needed).
In January 12.3 support will definitively end. But I will let the drivers as is so you can still use them in case of.

Installation / update

Please refer to the wiki page SDB:AMD_fgrlx

New packaging schema

The driver is now splitted into different rpm that all need to be installed. Normally the necessary Require field is there and should happen automatically.

My advise is to check if you have them all installed.

for 32 bits

zypper install fglrx_xpic fglrx_core fglrx_graphics fglrx_amdcccle fglrx_opencl

for 64 bits

zypper install fglrx64_xpic fglrx64_core fglrx64_graphics fglrx64_amdcccle fglrx64_opencl

A notice for Tumbleweed users

The new release has now its package correctly named, previously they were called SUSEFACTORY, with the new version the package will contain SUSETUMBLEWEED in their name

UnReal World RPG and propiertary applications in linux ecosystem part SDL2

November 14th, 2014 by

So last time I was on top of Curl and what problems can come out when you are using it through out different distributions. After that struggle UnReal World RPG have been ported to SDL2. It’s used by Steam so it should we available every distribution you can dream of. How wrong I can be and how correct I am! (more…)

LXQT is ready for testing

May 15th, 2014 by

The stable branch of LXQT, the QT branch of LXDE is now available for openSUSE:13.1 and openSUSE:Factory.
Following are a few screenshots of lxqt, which will be quite familiar to any of you that dabbled with Razor-qt in the past.

Here is the Main Desktop (note, this is using the “flat” theme, and the default openbox windowmanager)
lxqt-main-desktop

LXQT can offer a fully composited desktop, through the compton compositor, and includes a GUI tool for configuring.
compton-conf

Resulting in a highly configurable composited desktop:
lxqt-qterm-dropdown

LXQT also provides a powerful configuration tool, which allows you to tweak things the way you like…
lxqt-config-center

So if you’re looking for something to try out, please, give it a shot.

Please keep in mind, we are considering this a “Beta” quality release, so there are still some rough edges.

Additionally, lxqt is currently un-branded for openSUSE, so I certainly wouldn’t turn down help from folks that are into helping out with that sort of thing.

Stable packages are available for openSUSE:13.1(i586, x86_64, armv6l and armv7l) and openSUSE:Factory (i586 and x86_64) at:
X11:lxde:lxqt

Unstable Packages (latest git pulls), are available for 13.1 and Factory, i586 at:
devel:cloverleaf:lxqt:UNSTABLE

And if you happen to be running Fedora, i586 and x86_64 packages are available at:
devel:cloverleaf:lxqt:fedora

Cloudy with a touch of Green

March 19th, 2014 by

Finally there is some news regarding our public cloud presence and openSUSE 13.1. We now have openSUSE 13.1 images published in Amazon EC2, Google Compute Engine, and Windows Azure.

Well, that’s the announcement, but would make for a rather short blog. Thus, let me talk a bit about how this all works and speculate a bit why we’ve not been all that good with getting stuff out into the public cloud.

Let me start with the speculation part, i.e. hindrances in getting openSUSE images published. In general to get anything into a public cloud one has to have an account. This implies that you hand over your credit card number to the cloud provider and they charge you for the resources you use. Resources in the public cloud are anything and everything that has something to do with data. Compute resources, i.e. the size of an instance w.r.t. memory and number of CPUs are priced differently. Sending data across the network to and from your instances incurs network charges and of course storing stuff in the cloud is not free either. Thus, while anyone can put an image into the cloud and publish it, this service costs the person money, granted not necessarily a lot, but it is a monthly recurring out of pocket expense.

Then there always appears to be the “official” apprehension, meaning if person X publishes an openSUSE image from her/his account what makes it “official”. Well first we have the problem that the “official” stamp is really just an imaginary hurdle. An image that gets published by me is no more or less “official” than any other images. I am after all not the release manager or have any of my fingers in the openSUSE release in any way. I do have access to the SUSE accounts and can publish from there and I guess that makes the images “official”. But please do not get any ideas about “official” images, they do not exist.

Last but not least there is a technical hurdle. Building images in OBS is not necessarily for the faint of heart. Additionally there is a bunch of other stuff that goes along with cloud images. Once you have one it still has to get into the cloud of choice, which requires tools etc.

That’s enough speculation as to why or why not it may have taken us a bit longer than others, and just for the record we did have openSUSE 12.1 and openSUSE 12.2 images in Amazon. With that lets talk about what is going on.

We have a project in OBS now, actually it has been there for a while, Cloud:Images that is intended to be used to build openSUSE cloud images. The GCE image that is public and the Amazon image that is public both came from this project. The Azure image that is currently public is one built with SUSE Studio but will at some point also stem from the Cloud:Images OBS project.

Each cloud framework has it’s own set of tools. The tools are separated into two categories, initialization tools and command line tools. The initialization tools are tools that reside inside the image and these are generally services that interact with the cloud framework. For example cloud-init is such an initialization tool and it is used in OpenStack images, Amazon images, and Windows Azure images. The command line tools let you interact with the cloud framework to start and stop instances for example. All these tools get built in the Cloud:Tools project in OBS. From there you can install the command line tools into your system and interact with the cloud framework they support. I am also trying to get all these tools into openSUSE:Factory to make things a bit easier for image building and cloud interaction come 13.2.

With this lets take a brief closer look at each framework, in alphabetical order no favoritism here.

Amazon EC2

An openSUSE 13.1 image is available in all regions, the AMI (Amazon Machine Image) IDs are as follows:

sa-east-1 => ami-2101a23c
ap-northeast-1 => ami-bde999bc
ap-southeast-2 => ami-b165fc8b
ap-southeast-1 => ami-e2e7b6b0
eu-west-1 => ami-7110ec06
us-west-1 => ami-44ae9101
us-west-2 => ami-f0402ec0
us-east-1 => ami-ff0e0696

These images use cloud-init as opposed to the “suse-ami-tools” that has been used previously and is no longer available in OBS. The cloud-init package is developed in launchpad and was started by the Canonical folks. Unfortunately to contribute you have to sign the Canonical Contributor Agreement (CCA). If you do not want to sign it or cannot sign it for company reasons you can still send stuff to the package and I’ll try and get the stuff integrated upstream. For the interaction with Amazon we have the aws-cli package. The “aws” command line client supersedes all the ec2-*-tools and is an integrated package that can interact with all Amazon services, not just EC2. It is well documented fully open source and hosted on github. The aws-cli package replaces the previously maintained ec2-api-tools package which I have removed from OBS.

Google Compute Engine

In GCE things work by name and the openSUSE 13.1 image is named opensuse131-20140227 and is available in all regions. Google images use a number of tools for initialization, google-daemon and google-startup-scripts. All the Google specific tools are in the Cloud:Tools project. Interaction with GCE is handled with two commands, gcutil and gsutil, both provided by the google-cloud-sdk package. As the name suggests google-cloud-sdk has the goal to unify the various Google tools, same basic idea as aws-cli, and Google is working on the unification. Unfortunately they have decided to do this on their own and there is no public project for google-cloud-sdk which makes contributing a bit difficult to say the least. The gsutil code is hosted on github, thus at least contributing to gsutil is straight forward. Both utilities, gsutil for storage and gcutil for interacting with GCE are well documented.

In GCE we also were able to stand up openSUSE mirrors. These have been integrated into our mirrorbrain infrastructure and are already being used quite heavily. The infrastructure team is taking care of the monitoring and maintenance and that deserves a big THANK YOU from my side. The nice thing about hosting the mirrors in GCE is that when you run an openSUSE instance in GCE you will not have to pay for network charges to pull your updated packages and things are really fast as the update server is located in the same data center as your instance.

Windows Azure

As mentioned previously the current image we have in Azure is based on a build from SUSE Studio. It does not yet contain cloud-init and only has WALinuxAgent integrated. This implies that processing of user data is not possible in the image. User data processing requires cloud-init and I just put the finishing touches on cloud-init this week. Anyway, the image in Azure works just fine, and I have no time line when we might replace it with an image that contains cloud-init in addition to WALinuxAgent.

Interacting with Azure is a bit more cumbersome than with the other cloud frameworks. Well, let me qualify this with, if you want packages. The Azure command line tools are implemented using nodejs and are integrated into the npm nodejs package system. Thus, you can use npm to install everything you need. The nodejs implementation provides a bit of a problem in that we hardly have a nodejs infrastructure in the project. I have started packaging the dependencies, but there is a large number and thus this will take a while. Who would ever implement….. but that’s a different topic.

That’s where we are today. There is plenty of work left to do. For example we should unify the “generic” OpenStack image in Cloud:Images with the HP specific one, the HP cloud is based on OpenStack, and also get an openSUSE image published in the HP cloud. There’s tons of packaging left to do for nodejs modules to support the azure-cli tool. It would be great if we could have openSUSE mirrors in EC2 and Azure to avoid network charges for those using openSUSE images in those clouds. This requires discussions with Amazon and Microsoft, basically we need to be able to run those services for free, which implies that both would become sponsors of our project just like Google has become a sponsor of our project by letting us run the openSUSE mirrors in GCE.

So if you are interested in cloud and public cloud stuff get involved, there is plenty of work and lots of opportunities. If you just want to use the images in the public cloud go ahead, that’s why they are there. If you want to build on the images we have in OBS and customize them in your own project feel free and use them as you see fit.