JIRA herp derp!

So you want to use jira, because it's fancy and great and awesome. Yes you are right, it is good (at least for sw development).
And you want to do it quickly; so you use a docker container?
And you want to use it safely; so you want HTTPS?
And you do NOT want to put it behind an apache reverse proxy?
Well, Tomcat supports https just well.
BUT! Keep in mind that the key store needs to be in JKS format,as the JVM is 1.8.xx. Yes, ladies & gents, in atlassian's docker container, the JVM is ancient.
I just spent three hours figuring out why "trustAnchor is empty". Herp derp

Let's do the time-warp again! Or, compile LLVM in SB2 on the SFOS sdk (x86 target)

Yes; this sounds like one of these epic challenges.
The stock browser of SFOS is pretty much abandoned to itself. It is gecko-based; gecko has been labeled as "deprecated" by Mozilla, then as "still supported", then got re-promoted to a (somewhat obscure) "we keep it until we can switch". The switch in question meaning to be the jump to servo, a rust-based web engine used in their latest quantum-based firefox. So the idea is to compile it on the x86 target to begin with.

Achieving this faces challenges.

In order to achieve this goal, we will need clang, which requires llvm and a decently recent (>=4.9.5) gcc compiler, as well a decently recent python 3 verison (>=3.5.0). On top of this, we have here:

a) the glibc in the mer toolchain (at the time of writing) is stone age (2.19)
b) the compiler in the mer toolchain (at the time of writing) is old (4.8)
c) the compilation environment, scratchbox2 (a legacy development chroot originally developed by Nokia), has aged a bit, but the taste has slightly bitterned, and might cause acidity of stomach to some newer software's.

The first two points affect mainly the correct functionality of llvm.
llvm as a compiler is a different type of beast. In that it reimplements some functionalities in it's own ways, to ensure portability across multiple platforms. For example, locks via symlinks (same as pthreads do for instance). This exact feature of llvm is the first hurdle to overcome in order to get a functional toolchain; it uncoveres a non-POSIX conformance issue in mer / scratchbox2 (on i486 architecture) related to symlinks path resolution (in the mapping logic).

scratchbox2 as a development tool is very powerful; it allows to build for multiple targets, by isolating each specialized environment, and allowing fine-grained customization for the developer; combined with easiness of switching between these. Needless to say, the flexibility of this tool is admirable. Packages can be installed in specific environments(so-called "targets"), multiple architectures are supported, targets can be exported/copied, you name it. All of this is possible thanks to an interception layer, provided via a customized pre-loader library, configured as default when entering the development MER chroot, and which takes care of mapping the active target to the "real" counterpars (in terms of files) by intercepting and managing the most well-known System calls / glibc api's (open, close, execvp and so on).
It needs to be also mentioned that nowadays (with MER merging int SFOS) the platformc chroot has been officially replaced by VM's, which ship scratchbox2 pre-installed.


The 'box2's interception layer's has limits, however, and they become visible on our journey to firefox. Take pthread, for an example; a library on it's own, but which (as an implementation) "lives" at glibc's home repository. This vicinity causes trouble for sb2, as the closeness gives way to  "priviledged" relationships (in terms of api's) between pthread and glibc; now before you scream in disgust, these types of "close" relationships are very much acceptable from a glibc's or pthread's perspective (coherence of api's), if not welcomed (performance), and make sense in glibc/pthread's universe (coherence). But for the outsider's ('box2) interception layer, as an alien, this is a major problem, an interaction which is totally invisible to the SFOS development environment, and hence causes lots of things to go havoc (for example multiprocessing module of python, which internally relies on system-V semaphores).

And unfortunately, there is more glibc features which rely on many private counterparts of public api's. Up to the point where common POSIX libraries become non-functional under scratchbox2 (we already mentioned these - systemV semaphores anyone?) on some targets (i486, for instance),  or exec's, which also fall into the set of functions utilized internally by glibc via a private api. Exec's are for example used by the posix_spawn api's, which in turn - you know where this is going - are used (if the spawn.h header is detected, and is the case as MER ships it) by llvm.

Nevertheless, with these issues out of the way, you should be able to reliably compile the llvm. So now to the funny part, the compilation. Did I mention MER has an ancient glibc? (e)glibc 2.19 , as used (at the time of writing) by MER, lacks certain floating point operations (sse3 & more recent), which llvm relies on. Though these are not critical per se, they might turn up iffy warnings during compilation (if not bugs at runtime), hence relative build.rs files which include them in the compilation need to be patched to exclude them.

Once done so, you should have a clean LLVM implementation running on SFOS. Enjoy!

Of Mountains, Tablets, and fishes - A story of porting SFOS to Teclast x89 tablet

In Raethoromanian(Ladin)/Dolomites mythology, mountains have always played a big role.

A legend tells the story of a girl from the (Dolomites) mountains, accidently noticed by a Prince hunting in the area, and of the two subsequently falling deeply in love with each other.
Soon realizing the fact, and realizing her son is reluctant to back out of the relationship, the Queen forces him to move the girl into their home, the castle of the Realm, so that they could get properly married, and live together.
It so happens that the people from the castle did not approve of the relationship, and foremost did not accept the girl, even before her entrance  to the castle; they envy her, hate her, and shame her on her first public appearance, at which, out of shame and shyness, she turns into a small mountain furret (montagnóla).
The guests appear shocked, and consider killing the animal, but suddently the unexpected : a fire-like halo shines in strongly from the windows.
The guests, scared by the unusual event, curiously glare outside, wondering if the town is on fire; only to notice a once-gray mountain turned glooming fire-red! The ground creepily starts shaking, the castle slowly collapsing on itself, into the ground. The girl and Prince barely escape to safety; they are destined to become King and Queen of what is the biggest Ladin myth of the Dolomites, the Reign of the Fanís.
The mountain has been fire-red ever since, as of to reminding humans to their humbleness, and can be admired even today, in the Dolomites area of Sennes.

What does this have to do with tablets, and more to with fishes?
Quite few, if nothing at all, of course!
Or, perhaps the effort required to seize the top of a mountain, is comparable to the amount of work required to port SF OS to a new tablet HW?

In the spirit of "if the mountain does not come to I, I will go to the mountain" (see, mountains again!); if Jolla did not (manage to) make a tablet for me, well I'll be damned if I can't make one for me. It's a challenge to myself.

This series of posts are supposed to give an insight in the deep works of kernel porting, modules compiling, booting, involved when porting SFOS to new Hardware. I hope people will find it inspiring, and start experimenting on their own. Sailfish is a great OS, and most of all, a great idea (even tho still lacking in terms of full freedom). This, coupled with the amount of things I will (need to) learn on the way to it, is reason enough for me to try. And most importantly, I want to have FUN doing it.

The chosen hardware for this effort, is the Teclast x89, featuring a cheap Intel Bay Bridge SoC, 2 GB of RAM, 32 GB of flash, sd-card slot, dual boot Android / Windows 10 out of the box, and (luckily) unlocked bootload.
All in all, a decent Hardware replacement for the official Jolla tablet.

But first, some considerations:
DISCLAIMER : ANY OUTCOME OF THESE ACTIONS ARE THE RESULT OF YOUR OWN RESPONSIBILITY; I AM NOT RESPONSIBLE FOR DAMAGED HARDWARE / SERVICES / EQUIPMENTS. This is advanced hard work; if you are not ready to risk your hardware, or do not have a ginuea-pig hw, DO NOT START.

Still interested? Stay tuned for the next posts!

Virtualbox and Win7 issues

If VirtualBox does not start on Win7;
uninstall it, install it without USB emulation (add it afterwards).

XDG VS SailfishOS

During development of Quickbar, I happened to stumble upon a small issue related to XDG and mime types. This same issue has been raised over at tjc forums lately, so I got inspired and restarted digging.

The problem : lookup of mime types seem to fail relentlessy; opening files with xdg-open as of now (release 1.1.9.28) opens Documents application, no matter which file is actually opened. "So what", you might ask, "where's the problem, apps on SailfishOS rely on QT. We can open anything we want with QDesktopServices::openUrl". Unfortunately, qt internally (and QDesktopServices::openUrl more specifically) relies on xdg-open. So to investigate this, I followed the xdg-mime trace given in the comments of the tjc post.

On SailfishOS xdg tools refer to mimeapps.list for storing mime type associations; xdg scripts come from the package xdg-utils (in case of mer 1.1.0-rc3, keep in mind this version number cause it's the cause of all evil). This is a weird part, but everything is still correct here; this was quite misleading for a long time, as I believed the problem to be mimeapps.list being used as DEFAULT even outside KDE envs; that held until I stumbled on this post in the freedesktop mailing list, which claims that defaults.list has been declared deprecated and superseded by mimeapps.list. In fact, the specification does not happen mention defaults.list at all anymore. The same issue is raised in different environments as well, for example on  this post of the lxde group
 From the same LXDE group post, it seems  the latest and greatest (yet unreleased) version of xdg on the master contains a fix for this. issue.

The 4 rules of coding - or, of coding-applied strategic thinking.

Coding is not an easy job. From the perspective of the programmer, Coding is a war. I'll tell you why.
You need to do it right; which means; you need to do it clean; you need to do it FAST; and you - potentially, well, pretty much all the time - absolutely NEED to get it right the first time. There is no second chance. You have time to think on how to do it, sure, perhaps weeks, months, YEARS; but you will get that time only ONCE.

One shot. Perfection.

It's not an easy life being a coder. If you like to write; if you like to think; if you like to plan; you are not good enough. You need to like to write AND to think AND to plan. You need a STRATEGY.

Remember, practice makes the master. FOUR simple "riddles" govern the practice of coding, each of them require solving for the specific problem they are being applied on. The four riddles of coding, for properly solving a given problem, are for you find out:

1. WHAT needs to be done
2. HOW to achieve that (functionality-wise)
3. WHY it needs to be done like this (in a structural context)
4. HOW IT CAN BE USED

Point 1. Is pretty straightforward, and stems off from the requirements.
Point 2. is purely logic; and means collecting the idea of how to do things (i.e. opening files, writing to them vs opening pipes and/or writing to a REST Api etcetcetc). This is the threshold of AVERAGE programmers. They will write average code. This is just a fact. It is not BAD code per se; as it will do what it is meant to do. Only; people working with that code will make the coder's ear ring with F*U's for the rest of his life.
Point 3. Adds perspective in the mix. You might say, "of course I know WHY it needs to be done like this; to fulfill the requirements". That's only half the coin, man! This WHY is waay more subtle and entwingled into the deeper meaning / structure and is meant to get you to think of the solution you are applying (to the problem given by the requirements) in a broader spectrum; or, how more "advanced" programmers like to put it, in terms of "architecture", and in a wholistic view. In short, this point opens up for future usability of your code (funcionality-wise). Things like code structure, Functionality-grouping, application of patterns fall into this area. You can discern Good coders from the rest by the fact that they make use of these tools or not.
Point 4. is the hardest one, and usually only Great coders make it all the way up to this point. This is strategy to it's finest. Point 3 at the n'th potential. Code that is written needs to be USED. Needs to be relied on. If code cannot be used, it is useless, rusty, unreliable. If your code is not "level 4" code, it won't survive a new generation of programmers in your team. "The old code is shit, let's rewrite it", they will say. NIH sindrome.

Raspberry Pi 2 rocks! mount.cifs not so much..

I got this new toy yesterday and i L-O-V-E it!

One problem tho.
I also have a B+ model, which I used to run owncloud server (plus other sensors servers).
Having collected a decent ammount of data from my sensor network already, I wanted to keep it.
So i upgraded from RPi B+ to RPi2 following instructions on the RPi website.
This went fine & smooth, altho the owncloud server could not anymore connect to the backend NAS (which is used to store all the data).
Symptom of the failure was error -13 upon mounting. Which I figured should translate "in password being wrong" (at least in my case). A few tries with different users (defined on the NAS) didnt give expected results, until I realized to check the version of cifs. Which on the RPi2 is 5.5, and on the nas is 5.1.
Well, it appears the reason for it is that the default security mode of cifs has changed. It used to be ntlm, but it is not anymore - although in the documentation it clearly states it:

 Â·   ntlm Use NTLM password hashing (default)

The above is what comes out of the mount.cifs man page.
Forcing the sec to ntlm in the samba options of the mount solves the issue.