XBMC 13.0 Gotham entered Debian

32 Replies
XBMC v13.0 Gotham

XBMC v13.0 Gotham

Thanks to the great work of the XBMC Team XBMC 13.0 Gotham has been released last Sunday and now “XBMC from Debian” can be downloaded from experimental to Jessie and Sid systems.

It will take some time to enter unstable since it is blocked by the Libav 10 transition, but that will happen, too, eventually.

I have also set up a separate repository at https://people.debian.org/~rbalint/ppa/xbmc-ffmpeg/ based on the Debian packages in main but using XBMC’s internal copy of FFmpeg because I received several request asking for this variant. The packages there can be used on Wheezy (stable), Jessie (testing) and Sid (unstable) but are not part of Debian.

Update 1: For the interested parties the XBMC 13 Libav compatibility patches are available from a git branch in the packaging repository.

Update 2: Gotham and compatible PVR addons have migrated to Jessie (testing) and have also been uploaded to wheezy-backports. This makes Frodo and compatible PVR addons not installable from the usual official Debian repositories but if you would like to still use Frodo you can install it from snapshot.debian.org. Just add the following lines to your sources.list:

deb     http://snapshot.debian.org/archive/debian/20140401T173926Z/ wheezy-backports main
deb-src http://snapshot.debian.org/archive/debian/20140401T173926Z/ wheezy-backports main

It may be necessary to ignore the Valid-Until header within Release files, in order to prevent apt from disregarding snapshot entries (“Release file expired”). Use aptitude -o Acquire::Check-Valid-Until=false update or apt-get -o Acquire::Check-Valid-Until=false update for this purpose. (from snapshot.debian.org)

Update 3: people.debian.org became available through HTTPS only thus sources.list have to be updated as well. You may need to install apt-transport-https package to access the repositories there.

Proposing amd64-hardened architecture for Debian

5 Replies

Facing last week’s Heartbleed bug the need for improving the security of our systems became more apparent than usually. In Debian there are widely used methods for Hardening packages at build time and guidelines for improving the default installations’ security.

Employing such methods usually come at an expense, for example slower code execution of binaries due to additional checks or additional configuration steps when setting up a system. Balancing between usability and security Debian chose an approach which would satisfy the most users by using C/C++ features which only slightly decrease execution speed of built binaries and by using reasonable defaults in package installations.

All the architectures supported by  Debian aims using the same methods for enhancing security but it does not have to stay the same way. Amd64 is the most widely used architecture of Debian according to popcon and amd64 hardware comes with powerful CPU-s. I think there would be a significant amount of people (being one of them :-)) who would happily use a version of Debian with more security features enabled by default sacrificing some CPU power and installing and setting up additional packages.

My proposal for serving those security-focused users is introducing a new architecture targeting amd64 hardware, but with more security related C/C++ features turned on for every package (currently hardening has to be enabled by the maintainers in some way) through compiler flags as a start.

Introducing the new architecture would also let package maintainers enabling additional dependencies and build rules selectively for the new architecture improving the security further. On the users’ side the advantage of having a separate security enhanced architecture instead of a Debian derivative is the potential of installing a set of security enhanced packages using multiarch. You could have a fast amd64 installation as a base and run Apache or any other sensitive server from the amd64-hardened packages!

I have sent the proposal for discussion to debian-dev, too. Please join the discussion there or leave a comment here.

Update: Many of you wondered if amd64-hardened could have prevented the exploitation of the Heartbleed vulnerability. I have posted a proof of concept to show that using -fsanitize=address and disabling custom freelist would have protected systems against stealing data using the exploits.

Disabling the custom freelist-like solutions and enabling-fsanitize=address would be part of amd64-hardened to make memory protection techniques work effectively thus I think if we had this architecture ready at the beginning of April, it would have been immune to Heartbleed.

Segíts barátaidnak XP-ről Linuxra váltani napok

1 Reply


Mától nem ad ki frissítéseket a Microsoft a Windows XP-hez, ezért meghirdetem a “Segíts barátaidnak XP-ről Linuxra váltani napokat”.

Ha ismerjük egymást és XP-d van bátran keress meg és valamikor felrakunk mellé egy Ubuntu-t, hogy tovább használhasd nyugodtan a gépedet.

Az Ubuntu egy könnyen használható Debian leszármazott Linux disztribúció.

Angol változat

Move friends from XP to Linux days

4 Replies


Today Microsoft ends support for Windows XP.

To keep my friends’ PC-s currently running XP secure I announce the the “Move friends from XP to Linux days”.

If you are my friend feel free to contact me and we find some time to install Ubuntu on your machine keeping your Windows installation bootable as long as you want. Ubuntu is a Debian derivative Linux distribution which is easy to use.

Hungarian version

XBMC 12.3 Frodo has arrived to Debian Wheezy, Jessie and Sid

8 Replies

Q: How to install latest XBMC on Debian?
A: Just run “apt-get install xbmc”

Well, it actually installs “XBMC from Debian” and to get the 12.3 you also have to enable backports on Wheezy, but I guess you can forgive me for those nuances. 🙂

Many thanks to the Debian Multimedia team, Modestas Vainius and Ron Lee who kindly backported XBMC’s dependencies and also many thanks to the XBMC Developers for XBMC itself!

The package is well tested on amd64, i386 and armhf, and it is now built on powerpc and armel, too. If you would like to see your favorite architecture running XBMC, please check the build logs and submit a patch fixing the build to the BTS.

Happy hacking!

update: XBMC 13 Gotham replaced Frodo in Debian, but you can still install it from snapshot.debian.org. For details see the post about Gotham.

Introducing “XBMC from Debian”

22 Replies

… available from unstable, and hopefully soon from testing, too!

The longer story:

The xbmc package has been uninstallable and unbuildable in Debian unstable for quite some time. Mainly due to differing preferences of the XBMC project and Debian.

Original XBMC source includes several embedded libraries, some patched to work with XBMC perfectly and to provide the best user experience the XBMC project prefers building XBMC with those libraries.

In Debian, on the other hand, the recommended practice is not embedding libraries, but using the packaged versions instead to reduce the amount of security updates in case a library needs a security related fix, to save space on mirrors and to avoid divergence between the embedded versions of the libraries.

One consequence of using externally packaged libraries is the need for making XMBC work with newer versions of the external libraries even when the embedded one would still work perfectly or (in some rare cases) there are even breakages due to changing APIs or new bugs in the library.

XBMC depends on many libraries and the changes to them in Debian used to break one or another XBMC use case. The XBMC project received many direct bug reports from users of the Debian-shipped XBMC package which were harder than necessary to handle due to the lack of clear differentiation from the .deb packages provided directly by
them and using the embedded libraries.

To help both users and developers the xbmc package starts using the “XBMC from Debian” name on the main screen and in the logs, the version number used inside the application is set to the Debian package’s version, and README.Debian directs users of the package to Debian’s BTS instead of XBMC’s forums.

The most notable difference between XBMC and “XBMC from Debian” is that XBMC uses
its embedded patched FFmpeg, while “XBMC from Debian” uses libav. If movies play too slow, too fast, without sound or too loud, you should definitely check BTS first. 😉

Happy Holidays and don’t stay too much in front of the screen if “XBMC from Debian” happens to work for hours without any crash! 🙂

update: (The crashing part is just a joke. “XBMC from Debian”  should work flawlessly. I use it every day without problems.)

update 2: If you prefer the internal FFmpeg over Libav for some reasons I have created a separate repository for the package using the internal FFmpeg library copy starting from Gotham.

Faketime gets nanosecond timestamps, speeds up games, testing

4 Replies

I was playing with faketime the last few days mainly to implement features needed by ReproducibleBuilds, which is an initiative in Debian for providing binary packages that can be regenerated with the exact same content. Some build steps place timestamps in the resulting binaries, thus we may have to make time perceived by the build process move at a deterministic rate starting from a predetermined point in time.
This is why faketime got support for advancing time with each time(), gettimeofday(), etc. call. Another approach would be recording timestamps perceived by the first build and replaying them in the same order to successive builds. If the build is deterministic apart from the timestamps, this should result in the same binary package for each build.
While playing with faketime I could not resist implementing a few things which may not have been absolutely important for reproducible builds, but were so much fun. The nanosecond resolution of timestamps made games playable at slower or faster speeds making very hard games easier or easy games harder. Jump’n’bump just became insanely funny at 200% speed:

jumpnbump-video-screen

faketime -f "+0 x2" jumpnbump

Speeding up sleep()-s can also be useful in daily work. If your application calls sleep() often it may significantly slow down testing, but faketime is now able to shorten sleeps, too, speeding up testing such applications!