Home Home > 2014 > 01
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 January, 2014

spec-cleaner: hide all your precious cruft!

January 31st, 2014 by

As we stated in our communication over the time, our team’s main focus for foreseeable future is Factory and how to manage all those contributions. Goal is not to increase the number of SRs that is coming to Factory, but to make sure we can process more and to make sure we see even well hidden consequences to make sure that Factory is “stable” and “usable”.

sprayg

Not really part of our current sprints, but something that will hopefully help us is spec-cleaner that Tomáš Chvátal and Tomáš Čech were working on lately during their free time/hackweek. What is it trying to address? Currently, there are some packaging guidelines, but when you write a spec file for your software, you still have plenty of choices. How do you order all the information in the header? Do you use curly brackets around macros? Do you use macros? Which ones do you use and which not? Do you use binaries in dependencies? Package config? Perl symbols? Package names? There is format_spec_file obs service that tries to unify a little bit the coding style but leaves quite some of the stuff up to you. Not necessarily a bad thing, but if you have to compare changes and review packages that are using completely different coding styles the process becomes harder and slower.

spec-cleaner is format_spec_file taken to another level. It tries to unify coding style as much as it can. It uses consistent conventions, makes most of the decisions mentioned previously for you and if you already decided for one way in the past, it will try to convert your spec file to follow the conventions that it specifies. It’s not enforcing anything, it’s standalone script and therefore you don’t have to be worried that you spec file will be out of your control. You can run it, verify the result (actually, you should verify the results as there might still be some bugs) and commit it to OBS. If we all do it, our packages will all look more alike and it will be easier to read and review them.

How to try it? How to help? Well, code is on GitHub and packages are in OBS. You may have a version of it in your distribution, but that one is heavily outdated (even the 13.1 version), so add openSUSE:Tools repo and try the version from there.

zypper ar -f obs://openSUSE:Tools/openSUSE_13.1 openSUSE-Tools
zypper in spec-cleaner

You can then go to some local checkout and try what changes does it propose for your spec file. Easiest way is to just let it do stuff by calling it and taking a look at changes afterwards.

spec-cleaner -p -i *.spec
osc diff

If it works, great, we will have more unified spec files. If it doesn’t, file a bug 😉

Network boot live ISO

January 29th, 2014 by

The x86_64 edition of openSUSE Education’s Li-f-e live DVD supports PXE booting the iso over the network, here is how to do it:

* Install Li-f-e on a server from which other machines will PXE boot, make sure you have plenty of space assigned to / partition(about 20G)
* Set up LTSP by following this quick start guide
* Create /srv/nfs folder and copy Li-f-e iso there
* Run the following as root in terminal:

mount /srv/nfs/openSUSE-Edu-li-f-e.x86_64-42.1.1.iso /mnt
cp /mnt/boot/x86_64/loader/linux /srv/tftpboot/boot/linux-life64
cp /mnt/boot/x86_64/loader/initrd /srv/tftpboot/boot/initrd-life64
echo "/srv/nfs *(ro,no_root_squash,async,no_subtree_check)" >> /etc/exports
cat <<EOF>> /srv/tftpboot/pxelinux.cfg/default
LABEL Li-f-e
kernel boot/linux-life64
append initrd=boot/initrd-life64 isofrom_device=nfs:10.0.0.254:/srv/nfs/ isofrom_system=/openSUSE-Edu-li-f-e.x86_64-42.1.1.iso
IPAPPEND 2
EOF
chkconfig rpcbind on && service rpcbind restart
chkconfig nfsserver on && service nfsserver restart

Now you can PXE boot any machine over the network, select Li-f-e from the end of the boot menu to boot live DVD iso instead of normal LTSP session.

Use “yast2 live-installer” to install Li-f-e on the client machine.

Proprietary AMD/ATI Catalyst fglrx 13.12 (13.251-3) rpm get a new build release

January 27th, 2014 by

Just a small note about a new build (-3) of the 13.251 fglrx version.

Changelog

AMD has changed /etc/ati/amdpcsdb.default database in its tarball

The packages have just been published on geeko.ioda.net, so next time you zypper up the new build should appear as a proposed update

Notice

This release concern only owners of radeon HD5xxx or above.
For older gpu, the fglrx-legacy is still 13.1, and thus didn’t work with openSUSE 12.3 or above.
SDB:AMD_fgrlx_legacy
Beware of that, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.
For 12.3 and especially 13.1 the free radeon often offer a better experience than the old fglrx-legacy.

Have fun!

Beta Proprietary AMD/ATI fglrx 13.11 betaV9.95 Catalyst 13.25.18-3 rpm released

January 27th, 2014 by

Beta Proprietary AMD/ATI Catalyst fglrx 13.11 (13.25.18-3) rpm get a new release

Just a small note about a new build (-3) of the 13.251 fglrx version.

Changelog

On AMD website : Release note

Adds support for Steam OS

The packages will be published in a few minutes on geeko.ioda.net/mirror/amd-fglrx-beta, so next time you zypper up the new build should appear as a proposed update, if you use the beta repository (not recommended).

Notice

This release concern only owners of radeon HD5xxx or above. And is BETA.
For older gpu, the fglrx-legacy is still 13.1, and thus didn’t work with openSUSE 12.3 or above.
SDB:AMD_fgrlx_legacy
Beware of that, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.
For 12.3 and especially 13.1 the free radeon often offer a better experience than the old fglrx-legacy.

Have fun!

How to destroy your data from harddisk permamently?

January 24th, 2014 by

First warning and please read it: If you wipe your harddisk, USB-stick or Flash with any of these tips. Your data won’t magically come back! After correct ‘secure rm’ or ‘NWipe’ there way is no way to bring your valuable data back. Make backups and happy wiping!

Destroying data permanently from hard disk is not as easy as you think. Sometime hard disks just self destructs without notice but when there is police behind you door knocking and you have destroy as much data as you can it’s little bit trickier. Even normal cases when there ain’t police at door and you just want to make sure that your old hard disk is clean and it doesn’t contain your personal data it’s a bit of a problem. (more…)

openSUSE Education Li-f-e 13.1 x86_64 with UEFI boot support

January 21st, 2014 by

openSUSE Education Li-f-e 13.1 x86_64 with UEFI boot support is now here. Create bootable USB stick using dd_rescue, dd or Imagewriter GUI, select UEFI USB at boot device selection and make sure that GRUB2-EFI is selected under Bootloader in final installation summary screen. Select normal GRUB2 for legacy boot(machines without UEFI boot support).

Li-f-e x86_64 is mostly identical to i686 edition, selection of packages and versions will differ a bit.

Download

No forgotten patch to YaST anymore

January 17th, 2014 by

As I wrote in the last blog post, we try try to open YaST development as much as possible. When I thought what is the most annoying thing for me when contributing to an open source project, then it is when my contribution is ignored. So if I send a patch and do not get any response or I get response, but my patch is not merged without any reason, then I do not contribute again as I see it as a waste of time. To prevent such situation in YaST I’ve created an automatic reminder of pending pull requests for the YaST repos at GitHub.

How it is done? I want to have it transparent, reusable and automatic. The core component is a small ruby script I wrote to fetch pending requests for an organization on GitHub. It uses the GitHub API and tries to find any pull request without activity for three working days.

This script is handled by our public Jenkins server where it pulls the latest version of the script every working day and if there is any pending pull request it will send an email with its result to the YaST mailing list.

After a month of sending emails we have handled all longer running pull requests we have for YaST, so none of them have gone without activity longer than a month. I hope it encourages developers to create more pull requests as they will not be forgotten. We plan also to deploy such reminder for the libyui organization.

Unterstanding the nvidia driver process

January 15th, 2014 by

Nvidia pic from Muktware
The NVIDIA drivers for openSUSE 13.1 took a while to appear. Many users have asked why this was and we’d like to explain what happened and what we plan to do to prevent this in the future. This post was written with input from the openSUSE developers who maintain these drivers at SUSE and work with NVIDIA to make them available for our users.

How it should work

Legally, the Linux kernel GPLv2 license leaves proprietary binary drivers in a bit of a tangle. While some claim it should be OK, others say not – and that is what most distributions currently assume: one can not ship a Linux distribution with proprietary, binary drivers. NVIDIA has agreed that our users can grab their drivers from the official NVIDIA servers. They are packaged by SUSE engineers however. They take care of both SLE and openSUSE proprietary driver packaging for NVIDIA hardware, and have contacts at NVIDIA who get the drivers up on their ftp mirrors.
Nvidia-1click
The packages are build on a dedicated system, but the package spec (skeleton for building) is in OBS – for example, G03 is here. Anybody could use these to build the nvidia driver locally (the nvidia binary driver is grabbed from the nvidia driver during building). The command sequence for local building can be found in the README.

Once the packages are build, they are send to NVIDIA, which signs the packages with their key and generates and signs repositories, making them available to the public.

To note is the fact that this is all manual and takes a while on NVIDIA’s side (and ours). This of course is part of the reason why we don’t offer NVIDIA packages for Factory, our fast-rolling development repository.

What happened

What occurred for 13.1 is a typical case of “everything went wrong”.

Up until a few weeks before the release, the driver did not build against the Linux Kernel version 3.11. NVIDIA warned against the use of a patch for this problem created by third parties so the driver team did not have a running build. Due to a holiday, it took a while to get the packages build and pushed to NVIDIA. Unfortunately, by the time this was done, the holiday period at NVIDIA blocked progress for another week. Once the package was signed, it took the webteam at NVIDIA another week to get the repository published. It all added up to almost a month and brought quite some inconvenience for users eager to use their latest NVIDIA cards with the latest openSUSE.

About a week later, the openSUSE 13.1 NVIDIA drivers disappeared again from the nvidia servers for a day or so. We don’t know exactly what happened there, it might have simply been a server issue.

What we will do

The first and most obvious thing to change would be to improve coordination. The developers taking care of the NVIDIA packages should be made aware as early as possible about the release planning and a replacement in case for holidays should be available. We noted this in our 13.1 release report and will make sure that there will be a task in our task tracker for this for the next release. We also need to talk to NVIDIA about this to make sure that there, too, somebody can fill in for SUSE’s contacts.

But there are also thoughts on how to improve further. Some of the current ideas:

  • To get drivers for Factory the process needs more automation as the driver may break on kernel or X changes
  • We could try to open the process and work with community members to secure the process in case the SUSE folks are unavailalbe
  • It would be nice if we could make NVidia to see benefit of working more on the driver in openSUSE, e.g. by doing some testing
  • We could write some scripts that check regularly whether repo and packages are still available and in a valid state (meta data matches available RPMs)

We’ll have to see which of these we can implement, when and how. But rest assured that we will do what we can to prevent this in the future!

statistics with Geeko inside

And the stats!

After a bit of a hiatus, we’re back with the numbers. Development has slowed down around new year and isn’t back to speed yet so the 10th spot is shared by quite a big group of people…

Spot Name
1 Stephan Kulow
2 Denisart Benjamin
3 Tomáš Chvátal, Dirk Mueller, Michal Vyskocil
4 Hrvoje Senjan
5 Ciaran Farrell
6 Petr Gajdos
7 Lars Vogdt, Pascal Bleser
8 Jan Engelhardt, Charles Arnold
9 Andreas Stieger, Michal Marek, Niels Abspoel, Kyrill Detinov
10 Dinar Valeev, Bjørn Lie, Ulrich Weigand, Tobias Klausmann, Marcus Meissner, Alexander Graf, Robert Schweikert, Martin Vidner

mounting TrueCrypt volumes in GNU/Linux using cryptsetup

January 12th, 2014 by

cryptsetup as of 1.6, which shipped in openSUSE 13.1, is able to mount TrueCrypt volumes without the use of TrueCrypt code otherwise, which I previously noted is problematic due to it’s license, at least for inclusion in the openSUSE distribution.

Here, then, is how you mount it:

cryptsetup open --type tcrypt /var/run/media/username/volume_name encrypted_volume
mount /dev/mapper/encrypted_volume /mnt

For read only access, add --readonly and -o ro respectively. When done:

umount /mnt
cyrptsetup close encrypted_volume

See man 8 cryptsetup for all details and options.

openSUSE and GCC part 10: Distributing to other distributions than openSUSE with OBS

January 7th, 2014 by

Last time I talked about OBS and how to compile your application that you have developed with GCC. OBS is much more than just a tool for compiling openSUSE additional packages. You can also compile Debian, Ubuntu, Arch and Fedora (and couple more) but why on earth you want to do that? Short answer: because you can! Little bit longer answer: because you can and freedom is two way road. You can’t guess what Linux distribution or OS your user wants to use but you can make sure that you application is first class citizen in that Linux distribution. (more…)