You’ve certainly noticed that I didn’t run for a second turn, after my first 2 years. This doesn’t mean the election time and the actual campaign are boring

If you are an openSUSE Member, we really want to have your vote, so go to Board Election Wiki and make your own opinion.

The ballot should open tomorrow.

Why not a second turn?

Being a board member (present at almost every conference call, reading the mailing lists and other task) consume free time. It has increased during the last semester too. And we’ve got some new business opportunities here at Ioda-Net Sàrl in 2015, and those need also my attention for the next year(s). I prefer to be a retired Board member, than not being able to handle my responsabilities.
But I’m not against the idea of a "I’ll be back" in a near future. Moreover with a bit more bandwidth in my free time, I will be able to continue my packaging stuff, and other contributions.

What a journey!

With the new campaign running, I found funny to bring back to light my 2013 platform written 2 years ago. And spent 5 minutes on checking the differences with today. I’m inviting you to discover the small interview between me and myself

1. Which sentences would you say again today?

I’m a "Fucking Green Dreamer" of a world of collaboration, which will one day offer Freedom for everyone.

Clearly still a day by day mantra and leitmotiv. But even if I’m dreaming, I never forget that
Freedom has a price : Freedom will only be what you do for it.

2. Which thing you would not say again, or differently ?

Well, as there’s no joker card, let’s start by this one:
"A Visible Active Board > A Visible Active Project." With the experience and time, and interaction, (the one who said fight, get out please :-)), I would said this is not as easy as it sound first.
I’m pretty sure, I was more quieter since I was on the board, than before. Because it’s too hard to make a clear distinction, when you just want to express something as "a simple contributor": you are on the board, and then whatever you can try to trick the fact: you’re still a board member.

So making the Board visible like a kind of communicant Alien, will certainly not improve that much our project.
It’s written everywhere, almost everybody agree, the board is not the lighthouse in the dark showing you the future.
Anyone, I repeat, anyone in this community is a potential vector of a future for openSUSE.

So in my past platform "Guardians of the past, Managers of the present, Creators of the future." I would replace Creators of the future by kinda "enabler"

3. In the last 2 years, where did openSUSE mostly evolve?

I think we moved from a traditional way of building distribution to some creative alternative, the rolling but tested Tumbleweed, and the hybrid Leap are really good things that happened.
I believe that if we have also some hard time on mailing list, which are exhausting, they also have a positive aspect (yeap:-)). If we fight, then it’s certainly because of our faith in something. Is this one defined? Not sure! But I’m pretty convinced that all members around have a good image of it.

4. What would be an advice to your successor (even if he doesn’t care about it)?

We are a tooling community, we love tools. Beware of one thing, if you get hurt by a tool, you can become the worst asshole you’ve never met. With tools, you can also hurt other people.

My advise, watch your step and keystroke!

5. Something more you would like to share?

I’ve invested time and energy during 2014 and beginning of 2015, to run booth, talks, represent openSUSE’s project all around. It was awesome to go to those events and meet people, involved or interested about openSUSE.

Perhaps some of you don’t know, but we have friends all around us, in many communities, and when the magic about working together appears, it just blast my heart.

Thanks for reading and for your support during this period

Truly green yours

So I didn’t get around to seriously (besides running a few examples) play with Keras (a powerful library for building fully-differentiable machine learning models aka neural networks) – until now. And I have been a bit surprised about how tricky it actually was for me to get a simple task running, despite (or maybe because of) all the docs available already.

The thing is, many of the “basic examples” gloss over exactly how the inputs and mainly outputs look like, and that’s important. Especially since for me, the archetypal simplest machine learning problem consists of binary classification, but in Keras the canonical task is categorical classification. Only after fumbling around for a few hours, I have realized this fundamental rift.

The examples (besides LSTM sequence classification) silently assume that you want to classify to categories (e.g. to predict words etc.), not do a binary 1/0 classification. The consequences are that if you naively copy the example MLP at first, before learning to think about it, your model will never learn anything and to add insult to injury, always show the accuracy as 1.0.

So, there are a few important things you need to do to perform binary classification:

• Pass output_dim=1 to your final Dense layer (this is the obvious one).
• Use sigmoid activation instead of softmax – obviously, softmax on single output will always normalize whatever comes in to 1.0.
• Pass class_mode='binary' to model.compile() (this fixes the accuracy display, possibly more; you want to pass show_accuracy=True to model.fit()).

Other lessons learned:

• For some projects, my approach of first cobbling up an example from existing code and then thinking harder about it works great; for others, not so much…
• In IPython, do not forget to reinitialize model = Sequential() in some of your cells – a lot of confusion ensues otherwise.
• Keras is pretty awesome and powerful. Conceptually, I think I like NNBlocks‘ usage philosophy more (regarding how you build the model), but sadly that library is still very early in its inception (I have created a bunch of gh issues).

(Edit: After a few hours, I toned down this post a bit. It wasn’t meant at all to be an attack at Keras, though it might be perceived by someone as such. Just as a word of caution to fellow Keras newbies. And it shouldn’t take much to improve the Keras docs.)

After switchig to a notebook with higher resolution monitor, I noticed, that the FLTK based ICC Examin application looked way too small. Having worked in the last months much with pixel independent resolutions in QML, it was a pain to see the non adapted FLTK GUI. I had the impression, that despite of several years of a very appreciated advancement of monitor technology, some parts of graphics stacks did not move and take advantage. So I became curious on how to solve high DPI support the hard way.

First of all a bit of introduction to my environment, which is openSUSE Linux and KDE-5 with KF5 5.5.3. Xorg use many times a hardcoded default of 96 dpi, which is very unfortune or just a bug? Anyway, KDE follows X11. So the desktop on the high resolution monitor looks initially as bad as any application. All windows, icons and text are way too small to be useable. In KDE’s system settings, I had to set Force Font with DPI and doubled its size from 96 to 192. In the kscreen module I had to set scale 2.0 and then increased the KDE task bars width. Out of the box useability is bad with so many inconsistent manual user intervention. In comparision with the as well tested Unity DE, I had to set a single display scaling factor to 2.0 and everything worked fine and instantly, icons, fonts and window sizes. It would be cool if DE’s and Xorg understand screen resolution. In the tested OS X 10.10 even different screen resolutions of multiple monitors are scaled correctly, so moving a window from a high DPI monitor screen to a traditional low resolution external monitor gives reasonable physical GUI rendering. Apples OS X provides that good behaviour initially, without manual user intervention. It would be interessting how GNOME behaves with regards to display scaling.

Back to FLTK. As FLTK appears to define itself as pixel based, DPI detecion or settings have no effect in FLTK. As a app developer I want to improve user experience and modified first ICC Examin to initially render physically reasonably. First I looked at the FL::screen_dpi() function. It is only a helper for detecting DPI values. FL::screen_dpi() has has in FLTK-1.3.3 hardcoded values of 96DPI under Linux. I noticed XRandR provides correct milimeter based screen dimensions. Together with the XRandR provided screen resolution, it is easy to calculate the DPI values. ICC Examin renderd much better with that XRandR based DPI’s instead of FLTK’s 96DPI. But ICC Examin looked slightly too big. The 192DPI set in KDE are lower than the XRandR detected 227 DPI of my notebooks monitor. KDE provides its forced DPI setting to applications by setting Xft.dpi in XResources. That way all Xft based applications should have the same basic font scaling. KDE and Mozilla apps do use Xft. So add parsing of a Xlib XResources solved that for ICC Examin. The remainder of programing was to programatically scale FLTK’s default font size from 14 pixels with: FL_NORMAL_SIZE = scale(14) . Some more widget sizes, the FtGl font sizes for OpenGL, drawing line widths and graphics scaling where needed. After all those changes, ICC Examin takes now advantage of high resolution rendering inside KDE. Testing under Windows and OS X must follow.

The way to program high DPI support into a FLTK application was basically the same as in QML. However Qt’s QML takes off more tasks by providing a relative font unit, much like CSS em sizes. For FLTK, I would like to see some relative based API’s, in addition to the pixel based API’s. That would be helpful to write more elegant code and integrate with FLTK’s GUI layout program fluid. Computer times point more and more toward W3C technology. FLTK would be helpful to follow.

BITA IT Show, the biggest IT exhibition in western India is coming to town on 24-26 January, We will be there promoting Li-f-e. If you are in this part of the world, drop in to check it out.

Fosscomm is the annual conference of the Greek Free Software communities. This year the event took place on November 7 & 8 at the Technological Educational Institute(TEI) of Athens. This time around openSUSE had quite the strong presence in the conference with 3 talks and a booth.

openSUSE-el

The Booth itself always had at least 3 persons busy answering questions with old time and some new contributors to the project and local community handling the organization and distribution of the swag in the booth and explaining the merits of our current structure, projects and releases.

Enlightening Lizards

Although i haven’t had time to really contribute to this project in a while, it’s still one i really hold dear/close to heart so made sure to do this presentation again this year but with updated stats to spread the word about this awesome window manager and its foundation libraries and the stellar packaging work done by simon lees.

Automated Testing With openQA

My second and I believe most important presentation, this year, was about the excellent QA tool actually used to build our distro, “openQA”. As said by it’s motto, “Life is too short for manual testing!”, thus openQA is used to automate testing of the whole distribution (either as a collection or in individual package basis). You can see some test case examples on it’s homepage, you can also fetch the presentation from my github repo (FOSSCOMM_2015 directory) linked in the blog sidebar.

Leaping Ahead

Alex Vennos another community member had a presentation about the latest stable release “Leap 42.1”, unfortunately i couldn’t attend it but heard that it was well received even though people showed some confusion about the sudden “Leap” to a version like 42.1 from the previous 13.2

The rest

I spent the rest of the conference at our booth helping people, answering questions and generally socializing and talking with old & new friends.

Congratulations to the people from the TEI of Athens for the organization! :)

Update minor (mostly grammar/typo fixes)

Earlier tool live-fat-stick uses syslinux to create multiboot USB stick/hdd on a vfat parition without having to format the stick preserving existing data and copying whole ISO so the same stick can serve as demo as well as to copy ISOs for distributing. However the disadvantages are all of them that comes from using vfat.

Grub2 has come a long way and almost all major distributions now support booting from the iso image via loopback. So here is live-grub-stick script that uses grub in place of syslinux bringing in all the advantages of using grub2.

Currently live images of openSUSE, Ubuntu, Fedora and all their clones are supported. Go ahead and fork it if you would like to add support for your distribution.

The best Linux distribution for education got a whole lot better, your Li-f-e(Linux for Education) takes a “Leap” to 42.1. openSUSE Education community is proud to present this latest edition based on openSUSE 42.1 with all the features, updates and bug fixes available on it till date. This effectively makes it the only enterprise grade long term supported(LTS) distribution for Education.

As with previous releases we have bundled a ton of softwares on this live DVD/USB specially packaged for education, along with the Plasma, GNOME and Mate Desktop Environments, full multimedia experience is also provided out of the box thanks to the Packman repositories. Only x86_64 architecture is supported, if you have a lot of machines that only support x86 then read on to find out how you can extend their Li-f-e.

You can of course very easily turn Li-f-e to full-fledged LTSP server to PXE boot machines in your local network. Booting both i686 and x86_64 architectures is supported. In case you need to PXE boot machines below i686 then you would have to install this package.

Happy holidays!

Get Li-f-e from here: Direct Download | md5sum | Alternate download and mirrors

SUSE's semi-annual Hackweek was last week and I decided to work on implementing docker rebase, mainly to learn about the internal image format of Docker and see whether it was possible to improve how the updating of Docker images works in practice (either rebuilding or zypper-docker).

Update: the MFC-7460DN printer is now supported via the brlaser open source printer driver by Peter De Wachter. See this post for a much simpler way to configure this printer on Fedora (and other Linux distributions).

I’ve always been a fan of Brother, as their devices usually come with decent support for the Linux OS (at least initially). I have an MFC-7460DN Laser Printer / Scanner in my home office, that worked fine with Ubuntu Linux for the past few years. It’s hooked up to my DSL router’s ethernet switch and acts like a network printer for all of our devices.

Just to keep my mind flexible and to take a look at another Linux distribution for a change, I recently started using Fedora Workstation 23 on my Laptop (a company-issued Lenovo ThinkPad T440s). While the OS installation was painless and all main components like Video, Audio, Networking were detected and configured correctly out of the box, the post-installation of some tools and services required some more effort.

This time, the printing part of the MFC-7460DN took me quite some time to figure out. While Brother provides RPM packages of the drivers, they are 32-bit only, and the instructions hadn’t been updated since Fedora 12. The first thing I had to do was to download two driver RPM packages. I initially started with the newer versions of the drivers, brgenml1cupswrapper-3.1.0 and brgenml1lpr-3.1.0, but somehow did not get them to work at all. I then tried the older packages, mfc7460dnlpr-2.1.0 and cupswrapperMFC7460DN-2.0.4. These installed flawlessly, and a new printer was added to the CUPS configuration automatically.

However, it was configured as a local printer, so I first had to change the existing configuration to talk to the remote LPD port instead. While the printer configuration looked correct and no errors showed up, all print jobs simply disappeared into the bit bucket, without any visible error on the application side. Unfortunately the web-based CUPS administration tool was not much helpful, either – the button View Error Log simply returned a “Not found” error. There was no error log file in /var/log/cups, so I queried the status of the CUPS service via systemd next.

The command systemctl status -l cups then gave me a first hint:

sh: /opt/brother/Printers/BrGenML1//lpd/rawtobr3: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

Since this is a 32-bit binary, it might help to actually install a 32-bit version of the GNU C library! I simply forgot this step, even though it’s documented in the installation instructions. A simple dnf install glibc.i686 got me over this hurdle.

Unfortunately the print jobs still did not reach the printer and disappeared in the void! Checking the CUPS error log again, I now saw this:

/usr/local/Brother/Printer/MFC7460DN/lpd/filterMFC7460DN: line 131: 11660 Done                    eval cat $INPUT_TEMP
11661 Broken pipe             | $PSCONV $PSCONV_OP
11662 Segmentation fault      | $BRCONV $BRCONV_OP
PID 11602 (/usr/lib/cups/filter/brlpdwrapperMFC7460DN) exited with no errors.
PID 11603 (/usr/lib/cups/backend/lpd) exited with no errors.

Hilarious. Oh well, maybe the 32-bit binary is simply too old and crashes in the new environment? Let’s take a look at the full systemd journal with journalctl! This gave me further clues:

cupsd[10951]: /usr/local/Brother/Printer/MFC7460DN/lpd/filterMFC7460DN: line 131: 11660 Done                    eval cat $INPUT_TEMP
cupsd[10951]: 11661 Broken pipe             | $PSCONV $PSCONV_OP
cupsd[10951]: 11662 Segmentation fault      | $BRCONV $BRCONV_OP
cupsd[10951]: PID 11602 (/usr/lib/cups/filter/brlpdwrapperMFC7460DN) exited with no errors.
cupsd[10951]: PID 11603 (/usr/lib/cups/backend/lpd) exited with no errors.
cupsd[10951]: time-at-completed=1449759139
cupsd[10951]: Job completed.
cupsd[10951]: Removing document files.
dbus[1190]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
setroubleshoot[11624]: SELinux is preventing brprintconflsr3 from using the execmem access on a process. For complete SELinux messages. run sealert -l 5d873063-1d87-4e82-b
python3[11624]: SELinux is preventing brprintconflsr3 from using the execmem access on a process.
                                                
                                *****  Plugin catchall_boolean (89.3 confidence) suggests   ******************
                           
                                If you want to allow cups to execmem
                                Then you must tell SELinux about this by enabling the 'cups_execmem' boolean.
                                                
                                Do
                                setsebool -P cups_execmem 1
                                                
                                *****  Plugin catchall (11.6 confidence) suggests   **************************
                                                
                                If you believe that brprintconflsr3 should be allowed execmem access on processes labeled cupsd_t by default.
                                Then you should report this as a bug.
                                You can generate a local policy module to allow this access.
                                Do
                                allow this access for now by executing:
                                # grep brprintconflsr3 /var/log/audit/audit.log | audit2allow -M mypol
                                # semodule -i mypol.pp

OK, so SELinux seems to be getting in the way here. I did as suggested and ran the following commands:

# setsebool -P cups_execmem 1
# grep brprintconflsr3 /var/log/audit/audit.log | audit2allow -M brothermfc7460dn
# semodule -i brothermfc7460dn.pp

An lo and behold, the printer started printing! Let’s hope it still does when I reboot the system…

Things I learned and that surprised me:

• The error handling in CUPS completely failed here. There was not a single end-user accessible hint that something went wrong, the print jobs just disappeared in the void.
• The move to systemd still has some ripple effects, e.g. the “Not found” error for the missing CUPS error log in the web UI.
• Analyzing log files with journalctl is actually quite convenient. Instead of grepping and tailing multiple logs under /var/log/, these tasks can now be performed using a single tool.
• SELinux is still a bitch, even though the hints provided by setroubleshootd were quite useful to resolve the issues at hand.