While ago new version 3.19 of UnReal World RPG was released. It was very smooth release in my part. Everything was working as expected. Packages were build to several platforms that were planned. Those platforms were Ubuntu 10.04, 12.04, 14.04 and openSUSE 12.2,12.3,13.1 all there packages build from openSUSE 13.1 base distribution. Nobody found nothing to complain about binary packages before someone launched them on Arch distribution. Read the rest of this entry »
Hello Beijing and lovely people of openSUSE, I will be reaching there tomorrow, will be at Green Tree Inn close to the summit venue, packing some “sightseeing” before the event, if you are also there early drop me a line . There is a short talk about openSUSE Education scheduled on 19th. Check out the summit website to find out what other interesting stuff is on offer.
See you soon…
As of October 11th, a bunch of new rpm for FGLRX has been released for openSUSE 11.4 to 13.1 including Tumbleweed.
a special patch has been added for supporting up to kernel 3.17
Installation / update
Please refer to the wiki page SDB:AMD_fgrlx_legacy
Notice radeon HD5xxx or above only
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.
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, especially for HD2xxx-HD4xxx range.
openSUSE Factory / 13.2
Dear fellow, unfortunately an still open bug at AMD is not yet resolved to make FGLRX working under newer xorg version.
There’s also a re-organization of how xorg files will be placed in the file system. Once both of them will be fixed Sebastian will produce a newer script.
If those appear soon we perhaps will see rpm fglrx for 13.2.
Release note about 14.9
The following section provides a summary of new features in this driver version.
AMD Radeon™ R9 285 Ubuntu 14.04 support RHEL 7.0 support Install improvements Package and distribution generation options; recommend options set by default Help user install generated distribution package once created Pop-up messages to help guide users through the install process Identifying and installation of pre-requisites
This section provides information on resolved known issues in this release of the AMD Catalyst Linux Software Suite.
Witcher 2 random lock-up seen when launching the application Screen corruption when connecting an external monitor to some PowerXpress AMD GPU + Intel CPU platforms Intermittent X crash when the user does a rotation with Tear Free Desktop enabled Failure on exit of OpenGL programs Error message being displayed when a user does run clinfo in console mode Blank screen when hot plugging an HDMI monitor from a MST hub System hang after resume from S3/S4 in High Performance mode on PowerXpress AMD GPU + Intel CPU platforms Corruption or artifacting on the bottom right corner of the screen before booting into login UI during restart Occasional segmentation fault when running ETQW xscreensavers test failing with multi-GPU Crossfire™ configurations Motion Builder severe flickering while toggling full screen Intermittent crashing and corruption observed while running X-Plane Some piglit and Khronos OpenGL conformance test failures Displays occasionally going black when startx is run on Ubuntu 14.04 after switching to integrated GPU on PowerXpress AMD GPU + Intel Haswell CPU system platforms A connected external display getting disabled when unplugging AC power from laptop platforms An auto log out when double clicking the picture under desktop server times on PowerXpress AMD GPU + Intel CPU platforms
The following section provides a summary of open issues that may be experienced with the AMD Catalyst Linux Software Suite.
: Horizontal flashing lines on second screen in a clone mode with V-Sync on using AMD Mobility Graphics with Switchable Intel Graphics : Display takes a long time to redraw the screen after an S4 cycle
This Catalyst fglrx version support openSUSE version from 11.4 to 13.1 plus Tumbleweed (thus covering kernel from 3.11 to 3.17 series).
A special thanks to Sebastian Siebert for his effort on making this driver working under openSUSE and latest kernel.
My motivation for writing this blog post is to have one simple place where I can point everybody using += in a loop. I will describe here why it can kill the performance of any application or library and will also show some measurement to demonstrate it. Read the rest of this entry »
To share a bit more about this long trip but worth to made it.
You can now enjoy the video clip made during this event.
Was a real pleasure to meet so numerous openSUSE users.
Running the rolling openSUSE Factory has been smooth so far, no problems since the last post.
I have been involved in submitting new packages (ftop, dstat, some perl modules), patching other’s existing packages (dnsmasq) and of course taking after packages that I maintain (btrfsprogs). With a very few exceptions I’ve got done everything I needed, the exceptions were my rather silly mistakes. The damage is only the first few seconds when one realizes that the submit request was ‘rejected’. Don’t get bored by it, grab a coffee or go fix it later. Need to say the rejects are backed by a reason or explanation what’s wrong and what should be fixed in the next attempt. Learn from that, take notes, read the docs again. Once this becomes common, the amount of basic mistakes is near to zero, the self-checks become a routine. This makes a happy contributor and the distro maintainers too.
I recommend to skim the factory snapshots announcements, look at the changes or scroll down to the newly added ones. One day you can see your contributions there, go for it.
Before something goes to the Factory distro, the packages are getting ready in the devel projects. I’ve asked for maintainership of filesystems and benchmark projects and did some fixing in packages I use or at least recognize. The state of the projects is not ‘all-green’, build failures exist, but without some motivation I’m not rushing to fix them.
If you are interested (as a user) in a package from those devel projects, feel free to bug me about it. I can help with fixing build failures or submitting to Factory.
All of the above is a routine. A routine of making the distro better on the core side. There’s never enough of it and it may become boring (oh it does) over time. Out of the many research projects and experimenting I do, I decided to focus on one that’s definetely related to openSUSE, is fun, is important, useful and is not there yet.
“No way, really? But there’s AppArmor and SElinux enabled and the compile-time hardening options.”
Yeah. I won’t repeat the arguments why AppArmor and SElinux are insufficient, functionally or usability-wise. So what’s left? Grsecurity, of course. Sadly openSUSE lacks even the unofficial grsecurity-patched kernels unlike Arch, Debian or Gentoo. Sadly2, the patched kernels are unofficial and will remain at that state until grsec is upstream. I don’t dare to predict if/when this will happen.
My hardening efforts got the codename openSUSE-gardening and are hosted in my github repository of the same name. The wiki contains more comprehensive information. It’s still work in progress and does not cover all topics in detail but should be enough to get started.
Quite unexpectedly, spender found the repo and gave it a bit of publicity on twitter. Thanks man
My plan was to update all relevant packages, test the kernels a bit, update the wiki and then post about that here. Nah, I got the right kick to do it now.
Quick start is really simple, a pattern that installs all necessary packages for a desktop use:
Note, you’ll probably need to run linux-pax-flags before the first reboot, it will apply PaX flag exceptions, some binaries may crash due to the protections (like window manager processes, browsers). Once the zypper plugin is properly installed, the flags get updated automatically.
Warning: the patched kernel has not been extensively tested, works for me, might not work for you.
To be continued …
If running a booth is, for sure, an investment of time, energy and money (even if TSP contribute to help you), We often forget to say
how much it’s important for our community and project.
Booths makes openSUSE alive in all open source events! and it’s a great experience to live, for any of us.
Feel the beat!
I strongly believe that openSUSE has be to visible on events like KDE Akademy, Scale, Fosdem, Guadec.
It’s not a question of "Bang for the buck", than a simple obviousness:
- Fosdem : the biggest open source event in Europe (perhaps in the world) with more than 5000 hackers visiting.
- Scale : biggest event in North America with more than 3000 attendees
- Guadec : The annual conference of Gnome Hackers with lot of worldwide attendees
- KDE Akademy : This year with around 150 active contributors coming from all over the world.
The obviousness is: if openSUSE has no booth there, you just see Ubuntu and Redhat, and let’s add Debian, Mageia etc for Fosdem or Scale.
You all know how much I like our Geeko community. And when Akademy staff proposed us to run a booth, I said yes, great I will be there!
After comparing ways to go to Brno, the Geeko’s car was the less expensive, and allow me to pick the demo touch screen at SUSE Headquarter.
So I took a full week off and drive 2000 kilometers to make it happens.
Have you ever dreamed making your own unique font set. You get on it and seek for decent cheap or open source alternatives for making Truetype fonts and probably you find at least Fontforge. You are very happy and make you mind I’ll do my fonts with Fontforge. After a while you realize Fontforge is a Swiss army knife for making fonts in open source but you just wanted to create TTF, EOT or SVG font set. Weep no more you can use Birdfont. Read the rest of this entry »
As it has taken an extra ordinary amount of time for LSB to move forward a predicament has developed for many distributions, including openSUSE. Many of the requirements for LSB 4.1 can no longer be met and thus while the lsb package still builds it is not installable, see . The technically correct solution would be to drop the lsb package from the distribution, Factory now and thus 13.2 when it is released) as we can no longer be LSB compliant. However, the negative side effect is that some applications we do not and cannot package will no longer install, probably most notably google-chrome. Thus, having no lsb package, or no package that provides “lsb”, is a problem and has negative effects on many users. Therefore, the only way forward is to have an “lsb” package which provides LSB on a best effort basis.
Since LSB 4.1 and previous releases is a monolithic requirement, i.e. if you depend on lsb you depend/get everything that is in the standard, whether you want it or not, it is very likely that many applications depend on lsb while needing only a subset of the features. Thus, while we do not know all of those applications and cannot provide a list of “this will work and that will not“, there is a good chance that many external packages depending on lsb will not only install, but the payload they deliver will work with an lsb best effort approach. For those applications that are broken there is pretty much nothing we can do, sorry.
At a meeting last week at LinuxCon NA the goal was set to have LSB 5.0 released by the end of October. LSB 5.0 is incompatible with LSB 4.1 and prior releases. Thus, even if we provide an lsb 5.0 compliant package in short order after LSB 5.0 is released we still have the same risk as we do with the best effort approach. Basically some application packages that depend on “lsb” will deliver a payload that is broken. Exactly the opposite of what the LSB is trying to achieve, but hey one cannot hang on to Qt3 forever. Therefore, our “lsb best effort” approach to cover the gap does not create any additional pain.
Moving forward the LSB working group decided that the current approach, while providing value, has significant drawbacks. Predominantly there are not enough fingers on the keyboard to continue releases of such extensive “accepted standard” documentation. This is what we presently experience with the non installable lsb package. A for the LSB is being worked out. As this next/new LSB develops we will have to see how application providers deal with this. Without a formal LSB specification in the future, this problem will recur in a few years if application packages depend on a package named “lsb” which at some point may need to seize to exist. We will see how this plays out as the world we create keeps evolving.
2 Weeks ago myself and Françoise had joined the [http://www.randa-meetings.ch/ Randa Meeting] in Switzerland.
This event is a full hack-week where between around fifty people, that help to change the world, met together and hack around [http://www.kde.org KDE Community] related stuff. More on
KDE sprint page
I’ve heard about Randa from years, and had seen numerous reports about how Randa hack-week has allowed lots of changes : Plasma, Software collection, etc…
This year, we decided not only to financially sponsor the event, but also be part of as simple helper, with the status of newcomers in the KDE community contributors. Just to check how it goes.
Mario Fux (the organizer) didn’t fake his involvement to make this week a success, in a full open source spirit.
We’re reporting below a number of blog post that have been made during the hackweek.
And as the icing on the cake, you could just watch the video realized during the week.