One of the perks of working at SUSE is hackweek, an entire week you can dedicate working on whatever project you want. Last week the 12th edition of hackweek took place. So I decided to spend it working on solving one of the problems many users have when running an on-premise instance of a Docker registry.

The Docker registry works like a charm, but it’s hard to have full control over the images you push to it. Also there’s no web interface that can provide a quick overview of registry’s contents.

So Artem, Federica and I created the Portus project (BTW “portus” is the Latin name for harbour).

Portus as an authorization service

The first goal of Portus is to allow users to have a better control over the contents of their private registries. It makes possible to write policies like:

• everybody can push and pull images to a certain namespace,
• everybody can pull images from a certain namespace but only certain users can push images to it,
• only certain users can pull and push to a certain namespace; making all the images inside of it invisible to unauthorzied users.

This is done implementing the token based authentication system supported by the latest version of the Docker registry.

Docker login and Portus authentication in action

Portus as a front-end for Docker registry

Portus listens to the notifications sent by the Docker registry and uses them to populate its own database.

Using this data Portus can be used to navigate through all the namespaces and the repositories that have been pushed to the registry.

We also worked on a client library that can be used to fetch extra information from the registry (i.e. repositories’ manifests) to extend Portus’ knowledge.

The current status of development

Right now Portus has just the concept of users. When you sign up into Portus a private namespace with your username will be created. You are the only one with push and pull rights over it; nobody else will be able to mess with it. Also pushing and pulling to the “global” namespace is currently not allowed.

The user interface is still a work in progress. Right now you can browse all the namespaces and the repositories available on your registry. However user’s permissions are not taken into account while doing that.

If you want to play with Portus you can use the development environment managed by Vagrant. In the near future we are going to publish a Portus appliance and obviously a Docker image.

Please keep in mind that Portus is just the result of one week of work. A lot of things are missing but the foundations are solid.

Portus can be found on this repository on GitHub. Contributions (not only code, also proposals, bugs,…) are welcome!

You probably saw this phoronix article which references the log of the #dri-devel channel on freenode. This was an attempt to trash my work on lima and tamil, using my inability to get much in the way of code done, and my unwillingness to throw hackish tamil code over the hedge, against me. Let me take some time to explain some of that from my point of view.

Yes, I have lost traction.

Yes, i am not too motivated to work on cleaning up code at this time. I haven't been too motivated for anything much since FOSDEM 2014. I still have my sunxi kms code to fix up/clean up, and the same is true for the lima driver for mesa. It is also pretty telling that i started to write this blog entry more than two months ago and only now managed to post it.

Under the circumstances, though, everyone else would've given up about 2 to 3 years ago.

Due to my usual combination of stubbornness and actually sitting down and doing the work, I have personally kickstarted the whole open ARM GPU movement. This is the third enormous paradigm shift in Linux graphics that i have caused these past almost 12 years (after modesetting, and pushing ATI to a point of no return with an open source driver). All open ARM GPU projects were at least inspired by this, some actually use some lima code, others would simply not have happened if I hadn't done Lima and/or had kept my mouth shut at important junctions. This was not without sacrifices. Quite the opposite.

From March 2011 on, I have spent an insane amount of time on this. Codethink paid, all-in-all, 6 weeks of my time when i was between customer projects. Some of the very early work was done on Nokia time, as, thanks to our good friend Stephen Elop, operations were winding down severely in late 2011 to the point where mostly constant availability was needed. However, I could've used that extra free time in many other useful ways. When I got a job offer at SuSE in november 2011 (basically getting my old job back due to Matthias Hopf taking up a professorship), I turned it down so I could work on the highly important Lima work instead.

When Codethink ran into a cashflow issue in Oktober 2012 (which apparently was resolved quite successfully, as codethink has grown a lot more since then), I was shown the door. This wasn't too unreasonable a decision given my increasing disappointment with how lima was being treated, the customer projects i was being sent on, and the assumption that a high profile developer like me would have an easy time getting another employer. During the phonecall announcing my dismissal, I did however get told that ARM had already been informed about my dismissal, so that business relations between ARM and codethink could be resumed. I rather doubt that that is standard procedure for dismissing people.

The time after this has been pretty meagre. If you expected at least one of linaro, canonical, mozilla or jolla to support lima, you'd be pretty wrong. Similarly, i have not seen any credible attempt to support lima driver development on a consulting basis. Then there is that fact that applying to companies which use mali and which have no interest in using an open source driver for mali is completely out, as that would mean working on the ARM binary driver, which in turn would mean that i would no longer be allowed to work on lima. All other companies have not gotten with the times with respect to hiring policies, this ranges from demanding that people relocate to interviewing solely about OpenGL spec corners for supposed driver development positions. There was one case in this whole time which had a proper first level interview, and where everything seemed to be working out, only to go dead without a proper explanation after a while. I have since learned from two independent sources that my hiring was stopped due to politics involving ARM. Lima has done wonders making me totally unhirable.

In May 2013 i wrote another proposal to ARM for an open source strategy for Mali (the first was done in Q2 2011 as part of codethink), hoping that in the meantime sentiments had shifted enough and that the absence of an in-between company would make the difference this time round. It got the unofficial backing of some people inside ARM, but they just ended up getting their heads chewed off, and I hope that they didn't suffer too much for trying to do the right thing. The speed with which this proposal was rejected by Jem Davies (ARM MPD VP of Technology), and the undertone of the email reply he sent me, suggests that his mind was made up beforehand and that he wasn't too happy about my actions this time either. This is quite amazing, as one would expect anyone at the VP level of a major company to at least keep his options open. Between the way in which this proposal was rejected and the political pressure ARM seems to apply against Lima, Mr Davies his claims that ARM simply has no customer demand and no budget, and nothing more, are very hard to believe.

So after the polite applause at the end of my FOSDEM2014 talks, it hit me. That applause was the only support i was going to ever get for my work, and i was just going to continue to hit walls everywhere, both with lima and in life. And it would take another year until the next applause, if at all. To be absolutely honest, given the way the modesetting and ATI stories worked out, i should be used to that by now, however hard it still is. But this time round i had been (and of course still am) living with my fantastic and amazingly understanding girlfriend for several years, and she ended up supporting me through Q4 2013 and most of 2014 when my unemployment benefit ran out. This time round, my trailblazing wasn't backfiring on me alone, i was dragging someone else down with me, someone who deserves much better.

I ended up being barely able to write code throughout most of 2014, and focused entirely on linux-sunxi. The best way to block things out was rewriting the linux-sunxi wiki, and that wiki is now lightyears ahead of everything else out there, and an example for everyone else (like linux-exynos and linux-rockchip) for years to come. The few code changes i did make were always tiny and trivial. In august Siarhei Siamashka convinced me that a small display driver for sunxi for u-boot would be a good quick project, and i hoped that it would wet my appetite for proper code again. Sadly though, the fact that sunxi doesn't hide all chip details like the Raspberry Pi does (this was the target device for simplefb) meant that simplefb had to be (generically) extended, and this proved once and for all that simplefb is a total misnomer and that people had been kidding themselves all along (i seem to always run into things like this). The resulting showdown had about 1.5 times the number of emails as simplefb has lines of C code. Needless to say, this did not help my mood either.

In June 2014, a very good friend of mine, who has been a Qt consultant for ages, convinced me to try consulting again. It took until October before something suited came along. This project was pretty hopeless from the start, but it reinstated my faith in my problem solving skills and how valuable those really could be, both for a project, and, for a change, for myself. While i wasn't able to afford traveling to Bordeaux for XDC2014, i was able to afford FOSDEM2015 and I am paying for my own upkeep for the first time in a few years. Finally replacing my incredibly worn and battered probook is still out of the question though.

When i was putting together the FOSDEM Graphics DevRoom schedule around christmas, I noticed that there was a inexcuseably low amount of talks, and my fingers became itchy again. The consulting job had boosted morale sufficiently to do some code again and showing off some initial renders on Mali T series seemed doable within the 5 or so weeks left. It gave the FOSDEM graphics devroom another nice scoop, and filled in one of the many many gaps in the schedule. This time round i didn't kid myself that it would change the world or help boost my profile or anything. This time round, i was just going to prove to myself that i have learned a lot since doing Lima, and that i can do these sort of things still, with ease, while having fun doing so and not exerting myself too much. And that's exactly what I did, nothing more and nothing less.

The vultures are circling.

When Egbert Eich and I were brainstorming about freeing ATI back in April and May of 2007, I stated that I feared that certain "community" members would not accept me doing something this big, and I named 3 individuals by name. While I was initially alone with that view, we did decide that, in light of the shitthrowing contest around XGL and compiz, doing everything right for RadeonHD was absolutely paramount. This is why we did everything in the open, at least from the moment AMD allowed us to do so. Open docs, irc channel, public ml, as short a turn-around on patches as possible given our quality standards and the fact that ATI was not helping at all. I did have a really tough uphill battle convincing everyone that doing native C code was the only way, as, even with all the technical arguments for native code, I knew that my own reputation was at stake. I knew that if I had accepted AtomBIOS for basic modesetting, after only just having convinced the world that BIOS free modesetting was the only way forward, I would've personally been nailed to the cross by those same people.

From the start we knew that ATI was not going to go down without a fight on this one, and I feared that those "community" members would do many things to try to damage this project, but we did not anticipate AMD losing political control over ATI internally, nor did we anticipate the lack of scruples of those individuals. AMD needed this open source driver to be good, as the world hated fglrx to the extent that the ATI reputation was dragging AMDs chips and server market down, and AMD was initially very happy with our work on RadeonHD. Yet to our amazement, some ATI employees sided with those same "community" members, and together they worked on a fork of RadeonHD, but this time doing everything the ATI way, like fglrx.

The amount of misinformation and sometimes even downright slander in this whole story was amazing. Those individuals were actively working on remarketing RadeonHD as an evil Microsoft/Novell conspiracy and while the internet previously was shouting "death to fglrx", it ended up shouting "death to radeonhd". Everyone only seemed to want to join into the shouting, and nobody took a step back to analyze what was really going on. This was ATI & red hat vs AMD & SuSE, and it had absolutely nothing to do with creating the best possible open source driver for ATI hardware.

During all of this I was being internally reminded that SuSE is the good guy and that it doesn't stoop down to the level of the shitthrowers. Being who I am, I didn't always manage to restrain myself, but even today I feel that if I had been more vocal, i could've warded off some of the most inane nonsense that was spewed. When Novell clipped SuSEs wings even further after FOSDEM2009, i was up for the chop too, and I was relieved as i finally could get some distance between myself and this clusterfuck (that once was a free software dream). I also knew that my reputation was in tatters, and that if i had been more at liberty to debunk things, the damage there could've been limited.

The vultures had won, and no-one had called them out for their insidious and shameless behaviour. In fact, they felt empowered, free to use whatever nasty and underhand tactics against anything that doesn't suit them for political or egotistical reasons. This is why the hacking of the RadeonHD repository occured, and why the reaction of the X.org community was aimed against the messenger and victim, and not against the evil-doers (I was pretty certain before I sent that emial that it was either one or the other, i hadn't forseen that it would be both though).

So when the idea of Lima formed in March 2011, I no longer just feared that these people would react. I knew for a fact that they would be there, ready to pounce on the first misstep made. This fed my frustration with how Lima was being treated by Codethink, as I knew that, in the end, I would be the one paying the price again. Similarly, if my code was not good enough, these individuals would think nothing of it to step in, rewrite history, and then trash me for not having done corner X or Y, as that was part of their modus operandi when they destroyed RadeonHD.

So these last few years, i have been caught in a catch-22 situation. ARM GPUs are becoming free, and I have clearly achieved what i set out to achieve. The fact that I so badly misjudged both ARM and the level of support i would get should not take away from the fundamental changes that came from my labour. Logically and pragmatically, it should be pretty hard to fault me in this whole story, but this is not how this game works. No matter what fundamental difference I could've made with lima, no matter how large and clear my contributions and sacrifices would be, these people would still try to distort history and try their utmost best to defame me. And now that moment has come.

But there are a few fundamental differences this time round: I am able to respond as i see fit as there is no corporate structure to shut me up, and I truly have nothing left to lose.

What started this?

To put it short:

12:59 #dri-devel: < Jasper> the alternative is fund an open-source replacement, but touching
                  lima is not an option

Jasper St. Pierre is very vocal on #dri-devel, constantly coming up with questions and asking for help or guidance. But he and his employer Endless Mobile seem to have their mind set on using the ARM Mali DDK, ARMs binary driver. He is working on integrating the Mali DDK with things like wayland, and he is very active in getting help on doing so. He has been doing so for several months now.

The above irc quote is not what i initially responded to though, the following is however:

13:01 #dri-devel: < Jasper> lima is tainted
13:01 #dri-devel: < Jasper> there's still code somewhere on a certain person's hard disk he
                  won't release because he's mad about things and the other project contributors
                  all quit
13:01 #dri-devel: < Jasper> you know that
13:02 #dri-devel: < Jasper> i'm not touching lima with a ten foot pole.

This is pure unadulterated slander.

Lima is not in any way tainted. It is freshly written MIT code and I was never exposed to original ARM code. This statement is an outrageous lie, and it is amazing that anyone in the open source world would lie like that and expect to get away with it.

Secondly, I am not "mad about things". I am severely de-motivated, which is quite different. But even then, apart from me not producing much code, there had been no real indication to Jasper St Pierre until that point that this were the case. Also, "all" the contributors to Lima did not quit. I am still there, albeit not able to produce much in the way of code atm. Connor is in college now and just spent the summer interning for Intel writing a new IR for mesa (and was involved with Khronos SPIR-V). Ben Brewer only worked on Lima on codethink's time, and that was stopped halfway 2012. Those were the only major contributors to Lima. The second line Jasper said there was another baseless lie.

Here is another highly questionable statement from Mr. St Pierre:

13:05 #dri-devel: < Jasper> robclark, i think it's too late tbh -- any money we throw at lima
                  would be tainted i think

What Jasper probably meant is that HE is the one who is tainted by having worked with the ARM Mali DDK directly. But his quick fire statements at 13:01 definitely could've fooled anyone into something entirely different. Anyone who reads that sees "Lima is tainted because libv is a total asshole". This is how things worked during RadeonHD as well. Throw some halftruths out together, and let the internet noise machine do the rest.

Here is an example of what happens then:

13:11 #dri-devel: < EdB> Jasper: what about the open source driver that try to support the next
                  generation (I don't remember the name). Is it also tainted ?
13:19 #dri-devel: < EdB> I never heard of that lima tainted things before and I was surprised

Notice that Jasper made absolutely no effort to properly clarify his statements afterwards. This is where i came in to at least try to defuse this baseless shitthrowing.

When Jasper was confronted, his statements became even more, let's call it, varied. Suddenly, the reason for not using lima is stated here:

13:53 #dri-devel: < Jasper> Lima wasn't good enough in a performance evaluation and since it
                  showed no activity for a few years, we decided to pay for a DDK in order to 
                  ship a product instead of working on Lima instead.

To me, that sounds like a pretty complete reason as to why Endless Mobile chose not to use Lima at the time. It does however not exclude trying to help further Lima at the same time, or later on, like now. But then the following statements came out of Jasper...

13:56 #dri-devel: < Jasper> libv, if we want to contribute to Lima, how can we do so?
13:57 #dri-devel: < Jasper> We'd obviously love an active open-source driver for Mali.
...
13:58 #dri-devel: < Jasper> I didn't see any way to contribute money through http://limadriver.org/
13:58 #dri-devel: < Jasper> Or have consulting done

Good to know... But then...

13:58 #dri-devel: < libv> Jasper: you or your company could've asked.
13:59 #dri-devel: < Jasper> My understanding was that we did.
13:59 #dri-devel: < Jasper> But that happened before I arrived.
13:59 #dri-devel: < libv> definitely not true.
13:59 #dri-devel: < Jasper> I was told we tried to reach out to the Lima project with no response.
                  I don't know how or what happened.
14:00 #dri-devel: < libv> i would remember such an extremely rare event

The supposed reaching out from EndlessM to lima seems pretty weird when taking the earlier statements into account, like at 13:53 and especially at 13:01. Why would anyone make those statements and then turn around and offer to help. What is Jasper hiding?

After that I couldn't keep my mouth shut and voiced my own frustration with how demotivated i am on doing the cleanup and release, and whined about some possible reasons as to why that is so. And then, suddenly...

14:52 #dri-devel: < Jasper> libv, so the reason we didn't contribute to Lima was because we didn't
                  imagine anything would come of it.
14:53 #dri-devel: < Jasper> It seems we were correct.

It seems that now Jasper his memory was refreshed, again, and that EndlessM never did reach out for another reason altogether...

A bit further down, Jasper lets the following slip:

14:57 #dri-devel: < Jasper> libv, I know about the radeonhd story. jrb has told me quite a lot.
14:58 #dri-devel: < Jasper> Jonathan Blandford. My boss at Endless, and my former boss at Red Hat.

And suddenly the whole thing becomes clear. In the private conversation that ensued Jasper explained that he is good friends with exactly the 3 persons named before, and that those 3 persons told him all he wanted to know about the RadeonHD project. It also seems that Jonathan Blandford was, in some way, involved with Red Hats decision to sign a pact with the ATI devil to produce a fork of a proper open source driver for AMD. These people simply never will go near anything I do, and would rather spend their time slandering yours truly than to actually contribute or provide support, and this is exactly what has been happening here too.

This brings us straight back to what was stated before anything else i quoted so far:

12:57 #dri-devel: < EdB> Jasper: I guess lima is to be avoided
...
12:58 #dri-devel: < Jasper> EdB, yeah, but that's not for legal reasons

Not for legal reasons indeed.

But the lies didn't end there. Next to coming up with more reasons to not contribute to lima, in that same private conversation Jasper "kindly" suggested that he'd continue Lima if only i throw my code over the wall. Didn't he state previously that Lima was tainted, with which i think he meant that he was tainted and couldn't work on lima?

Why?

At the time, i knew i was being played and bullshitted, but I couldn't make it stick on a single statement alone in the maelstrom that is IRC. It is only after rereading the irc log and putting Jaspers statements next to eachother that the real story becomes clear. You might feel that i am reading too much into this, and that i have deliberately taken Jaspers statements out of context to make him look bad. But I implore you to verify the above with the irc log, and you will see that i have left very little necessary context out. The above is Jaspers statements, with my commentary, put closely together, removing the noise (which is a really bad description for the rest of the irc discussion that went on at that time) and boosting the signal. Jasper statements are highly erratic, they make no sense when they are considered collectively as truths, and some are plain lies when considered individually.

Jasper has been spending a lot of time asking for help for supporting a binary driver. Nobody in the business does that. I guess that (former) red hat people are special. I still have not understood why it is that Red Hat is able to get away with so much while companies like canonical and SuSE get trashed so easily. But that is besides the point here; no-one questioned why Jasper is wasting so much time of open source developers on a binary driver. Jasper was indirectly asked why he was not using Lima, nothing more.

If Jasper had just stated that Endless Mobile decided to not use Lima because Endless Mobile thought Lima was not far enough along yet, and that Endless Mobile did not have the resources to do or fund all the necessary work still, then i think that that would've been an acceptable answer for EdB. It's not something i like hearing, but i am quite used to this by now. Crucially though, i would not have been in a position to complain.

Jasper instead went straight to trashing me and my work, with statements that can only be described as slander. When questioned, he then gave a series of mutually exclusive statements, which can only be explained as "making things up as he goes along", working very hard to mask the original reasons for not supporting Lima at all.

This is more than just "Lima is not ready", otherwise Jasper would have been comfortable sticking to that story. Jasper, his boss and Endless Mobile did not decide against Lima on any technical or logistical basis. This whole story never was about code at all. These people simply would do anything but support something that involves me, no matter how groundbreaking, necessary or worthy my work is. They would much rather trash and re-invent, and then trash some more...

It of course did not take long for the other vultures to join the frenzy... When the discussion on irc was long over, Daniel Stone made one attempt to revive it, to no avail. Then, a day later, someone anonymously informed phoronix, and Dave Airlie could then clearly be seen to try to stoke the fire, again, with limited success. I guess the fact that most of the phoronix users still only care about desktop hardware played to my advantage here (for once). It does very clearly show how these people work though, and I know that they will continue to try to play this card, trying hard to trigger another misstep from me or a cause a proper shitstorm on the web.

So what now.

Now I have a choice. I can wait until i am in the mood to clean up this code and produce something useful for public consumption, and in the meantime see my name and my work slandered. Or... If i throw my (nasty) code over the wall, someone will rename/rewrite it, mess up a lot of things, and trash me for not having done corner X or Y, so essentially slander me and my work and probably even erase my achievements from history, by using more of my work against me... And in the latter case i give people like Jasper and companies like Endless Mobile what they want, in spite of their contemptible actions and statements. Logically, there is only one conclusion possible in that constellation.

At the end of the day, i am still the author of this code and it was my time that I burned on it, my life that i wasted on it. I have no obligations to anyone, and am free to do with my code what i want. I cannot be forced into anything. I will therefor release my work, under my own terms, when i want to and when i feel ok doing so.

This whole incident did not exactly motivate me to spend time on cleaning code up and releasing it. At best, it confirmed my views on open source software and certain parts of the X.org community.

This game never was about code or about doing The Right Thing, and never will be.

I might be the first one that started using ownCloud in Greece. Don't remember the version (I think it was version 4.x.x back in 2011-2012). My main contributions to the project are translation and promotion. For the past years I made many presentations around Greece. You can see my blog is full of tutorials. I also wrote documentation for openSUSE. Finally, I made a huge (in my opinion) contribution to Greek translation.

The past few presentations and all the help I got from the community, I managed to engage more people to contribute to our community. I went to continue translation and I saw that it was 100%.


Although I'm not the coordinator of translations, I would like to thank everyone who helped. Now it's the hard part to check for the quality of the translations and also keep the 100%. ownCloud community is pretty active and they change strings almost everyday.

My new favorite corporate email solution is davmail + geary + california in gnome-shell.

Geary is still a little buggy (version 0.8.3), but I love how light weight it is, while still doing (most of) what I need it to. It really needs html signature support, but that’s the only thing missing that I really use.

Davmail appears to be very stable. I run it in server mode on startup with an init script.

Now all I need is a decent calendar solution. The new gnome app California appears to be the best bet. It’s very buggy in version 0.2. My biggest issue is that overlapping events aren’t handled well. I’m hoping they’ve got that worked out in 0.4.

It feels more fluid using native gnome-shell apps for my corporate email and calendar. Thanks Yorba and davmail!

I often see people asking how to contribute to an open source project on GitHub. Some are new programmers, some may be new to open source, others aren’t programmers but want to make improvements to documentation or other parts of a project they use everyday.

Using GitHub means you’ll need to use Git, and that means using the command-line. This post gives a gentle introduction using the git command-line tool and a companion tool for GitHub called hub.

Workflow

The basic workflow for contributing to a project on GitHub is:

1. Clone the project you want to work on
2. Fork the project you want to work on
3. Create a feature branch to do your own work in
4. Commit your changes to your feature branch
5. Push your feature branch to your fork on GitHub
6. Send a pull request for your branch on your fork

Clone the project you want to work on

$ hub clone pydata/pandas

(Equivalent to git clone https://github.com/pydata/pandas.git)

This clones the project from the server onto your local machine. When working in git you make changes to your local copy of the repository. Git has a concept of remotes which are, well, remote copies of the repository. When you clone a new project, a remote called origin is automatically created that points to the repository you provide in the command line above. In this case, pydata/pandas on GitHub.

To upload your changes back to the main repository, you push to the remote. Between when you cloned and now changes may have been made to upstream remote repository. To get those changes, you pull from the remote.

At this point you will have a pandas directory on your machine. All of the remaining steps take place inside it, so change into it now:

$ cd pandas

Fork the project you want to work on

The easiest way to do this is with hub.

$ hub fork

This does a couple of things. It creates a fork of pandas in your GitHub account. It establishes a new remote in your local repository with the name of your github username. In my case I now have two remotes: origin, which points to the main upstream repository; and joeshaw, which points to my forked repository. We’ll be pushing to my fork.

Create a feature branch to do your own work in

This creates a place to do your work in that is separate from the main code.

$ git checkout -b doc-work

doc-work is what I’m choosing to name this branch. You can name it whatever you like. Hyphens are idiomatic.

Now make whatever changes you want for this project.

Commit your changes to your feature branch

If you are creating new files, you will need to explicitly add them to the to-be-commited list (also called the index, or staging area):

$ git add file1.md file2.md etc

If you are just editing existing files, you can add them all in one batch:

$ git add -u

Next you need to commit the changes.

$ git commit

This will bring up an editor where you type in your commit message. The convention is usually to type a short summary in the first line (50-60 characters max), then a blank line, then additional details if necessary.

Push your feature branch to your fork in GitHub

Ok, remember that your fork is a remote named after your github username. In my case, joeshaw.

$ git push joeshaw doc-work

This pushes to the joeshaw remote only the doc-work branch. Now your work is publicly visible to anyone on your fork.

Send a pull request for your branch on your fork

You can do this either on the web site or using the hub tool.

$ hub pull-request

This will open your editor again. If you only had one commit on your branch, the message for the pull request will be the same as the commit. This might be good enough, but you might want to elaborate on the purpose of the pull request. Like commits, the first line is a summary of the pull request and the other lines are the body of the PR.

In general you will be requesting a pull from your current branch (in this case doc-work) into the master branch of the origin remote.

If your pull request is accepted as-is, the maintainer will merge it into the official upstream sources. Congratulations! You’ve just made your first open source contribution on GitHub.

(This was adapted from a post I made to the Central Ohio Python User Group mailing list.)

Last week was SUSE's Hackweek 12.
Hackweeks are special weeks at SUSE where all of SUSE Engineering get to work on whatever they'd like, to try cool things and learn new stuff.

This Hackweek was my first at SUSE's Nuremberg office, and it was quite an experience. The whole place had a 'buzz' about it all week. Every day the company sponsored Lunch or Breakfast, which got everyone together and triggered many interesting conversations. Some times we were serenaded by the 'SUSE Band' who were working on their musical abilities and technology for hackweek.

I had lots of conversations about the upcoming openSUSE conference, some of SUSE's planned projects around openSUSE, and of course openQA, which was a big part of lots of peoples Hackweek.

Bernhard Wiedemann worked on adding subtitles to openQA's video recordings so users can see what openQA is doing when it produces the recorded screen output.

Max Lin worked on a chrome extension to provide live status monitoring of an openQA instance and its workers.

Bernhard, Stephan Kulow, and Klaus Kämpf looked at getting openQA to test bare metal hardware.
While openQA already has support for IPMI for bare metal testing of servers, pushing the already established limits is exactly the spirit of Hackweek :)
Bernhard started experimenting with the idea of using ARM development boards to emulate a keyboard and relay openQAs keyboard commands. Next Hackweek he hopes to have a HDMI grabber so it will be able to see the video output also.
Klaus and Coolo were successful in getting openQA to control hardware with Intel vPro/AMT (as found in Thinkpads and other common laptop/desktop hardware). This demonstration video shows it working on my very own X220 Thinkpad.

And Xudong Zhang from Beijing and myself worked on testing openQA by using openQA

Testing openQA on openQA, are you crazy?

Actually, only a little crazy.
We made life easy for ourselves by creating two disk images (one for SLES 12 and another for openSUSE 13.2) to represent the same production environments we have for http://openqa.opensuse.org and the internal SUSE openQA instance.

These images were created following the regular openQA Documentation and setup to test a 'known good' Distribution with a static set of tests (openSUSE 13.2 with the tests and needles from our GitHub project)

We then configured openQA to treat this disk image as a different 'distribution', and we wrote new tests for testing openQA (See the source code HERE)

A little bit of 'needling' later (Capturing the reference screenshots and defining the areas of interest to openQA, which can be found HERE) we had a working test run which was able to test openQA running on openSUSE 13.2

and also for testing openQA on SLES 12

These tests successfully test all the core functionality of openQA, including Upgrading from the official OBS repository, Confirming the Worker is running, Scheduling an openQA job from the shell, Confirming a Job is running from the shell, and checking the functionality of each of the UI Screens by loading up Firefox and clicking on all of the links just like a user would.

With this development, we now have a way of confirming that new builds of openQA are safe for deployment in production, which should help us be a little more fearless and rapid updating the openQA versions in use for testing openSUSE and SUSE Linux Enterprise, even when during heavy testing periods.

Expect to see these tests running on the public http://openqa.opensuse.org soon.. I just need to figure out an elegant way of triggering them automatically as soon as OBS has new RPMs for testing.

Thanks to all who made this Hackweek awesome!

This week is Hackweek 12 at SUSE

My hackweek project is improving GNOME password management, by investigating password manager integration in GNOME.

Currently, I'm using LastPass which is a cloud-based password management system.

It has a lot of very nice features, such as:

• 2 factor authentication
• Firefox and Chrome integration
• Linux support
• JS web client with no install required, when logging from a unknown system (I never needed it myself)
• Android integration (including automatic password selection for applications)
• cli open-source client (lastpass-cli), allowing to extract account specific information
• encrypted data (nothing is stored unencrypted server side)
• strong-password generator
• support encrypted notes (not only password)
• server based (clients sync) with offline operations supported
   

However, it also has several drawbacks:

• closed-source
• subscription based (required for Android support)
• can't be hosted on my own server
• doesn't integrate at all with GNOME desktop

I don't want to reinvent the wheel (unless it is really needed), which is why I spend my first day at searching the various password managers available on Linux and compare their features (and test them a bit).

So far, I found the following programs:

• KeePass (GPL):
• version 1.x written in Java, still supported, not actively developed
• version 2.x written in C# (Windows oriented), works with Mono under Linux
• UI feels really Windows-like
• DB format change between v1 and v2
• supports encrypted notes
• password generator
• supports plugins ( a lot are available)
• support OTP (keeotp plugin, provide 2factor auth through TOTP, HTOP built-in)
• shared db editing
• support yubikey (static or hotp)
• 2 Firefox extension available(keefox, passifox)
• 3 android applications available (one application KeePass2Android supports alternative keyboard, KeepShare supports alternative keyboard + a11y framework to fill android application forms, like LastPass)
• Chrome extension available
• JS application available
• CLI available
• big ecosystem of plugins and other applications able to process file format


• KeePassX (GPL)
• Qt4 "port" of KeePass (feels more a Linux application than KeePass)
• alpha version for DB v2 support
• missing support for OTP
• missing support for keypasshttp (required by firefox extensions to discuss with main application), support is being done in a separate branch by a contributor, not merged
• release are very scarse (latest release is April 2014, despite commits on git, very few people are contributing, according to git)
• libsecret dbus support is being started by a contributor


• Mitro:
• company developped it was bought by Twitter last year, project released under GPL, no development since January.


• Password Safe (Artistic license):
• initially written by Bruce Schneier 
• beta version available on Linux
• written in wxWidgets 3.0 / C++
• yubikey supported
• android application available, no keyboard nor a11y framework usage, only use copy/paste (but allows sync of db with owncloud and other cloud platforms)
• CLI available
• 3 different DB formats (pre-2.0, 2.0, 3.0)
• password history
• no firefox extension and the "auto-type" built-in function is all but intuitive
• support merge of various db


• Encrypt:
• same 0 knowledge framework as SpiderOak
• node-js based


• Pass:
• simple script on top of text files / gnupg and optionnally git (used for history and can also be used to manage hosting the file)
• not easy learning curve (CLI mostly), need gnupg to be setup before usage
• one file per password entry, should make 
• very basic Qt GUI available
• basic FF extension available
• basic android application available

Unfortunately, none of those applications properly integrates (yet) in GNOME (master password prompt, locking keyring when desktop is locked, etc..).

I've also looked at gnome-keyring integration with the various browsers:

• Several extensions already exist, one is fully written in Javascript and is working nicely (port to libsecret is being investigated)
• Chrome has already gnome-keyring and libsecret integration
• Epiphany already works nicely with gnome-keyring
• No password generator is available in Firefox / Chrome / Epiphany (nor GTK+ on a more generic basis)

Unfortunately, each browser is storing metadata in gnome-keyring for password entries in a slightly different format (fields name), causing password entries duplication and not allowing sharing keyring data across browsers.

Conclusions for this first day of hackweek:

• Keepass file format seems to be the format of choice for password manager (a lot of applications written around it)
• Password manager which would fit my requirement is KeePass but is written in Mono (I don't want Mono stack to come back on my desktops) and too Windows oriented, so not an option.
• KeePassX seems to be the way to go (even if it is Qt based) but it lacks a lot of features and I'm not sure if it worth spending effort in adding those missing features there.
• Pass is extremely simple (which would make hacking around it pretty straightforward) but requires a lot of work around it (android, GUI) to make it nicely integrated in GNOME.

I haven't yet made up my mind which solution is the best, but I'll probably spend the following days hacking around KeePassX (or a new program to wrap KP db into libsecret) and Firefox gnome-keyring integration.

Comments welcome, of course.

So, I just reinstalled openSUSE (because the new DEFAULT btrfs borked my system, wont go into that today), and my wifi isn’t working.

Sounds similar to issues described here:
https://forums.opensuse.org/showthread.php/471983-Unable-to-get-wireless-Broadcom-BCM4313-up-and-running
http://lists.opensuse.org/opensuse/2014-12/msg00124.html

Just thought I’d share how I got things up and running.

First off, here were the symptoms:
1. Gnome network manager indicated that the firmware was not installed (even though this is supposed to be included with the kernel now).
2. # dmesg | grep firmware
[ 19.764863] ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw
3. l /lib/firmware/ # (the brcm directory is completely MISSING)
total 28
drwxr-xr-x 6 root root 4096 Apr 7 09:54 ./
drwxr-xr-x 13 root root 4096 Apr 7 09:53 ../
drwxr-xr-x 31 root root 4096 Apr 6 16:52 3.16.6-2-desktop/
drwxr-xr-x 31 root root 4096 Apr 7 09:54 3.16.7-7-desktop/
-rw-r–r– 1 root root 53 Sep 25 2014 E-CARD.cis
drwxr-xr-x 2 root root 4096 Apr 7 09:52 amd-ucode/
drwxr-xr-x 2 root root 4096 Apr 7 09:53 intel-ucode/

To get it working…
1. Download the kernel-firmware package:
http://download.opensuse.org/repositories/openSUSE:/13.2:/Update/standard/noarch/kernel-firmware-20141122git-5.1.noarch.rpm
2. Extract the firmware (installing the package would probably work too).
3. cp -r /home/dmulder/Downloads/kernel-firmware-20141122git-5.1.noarch/lib/firmware/brcm /lib/firmware/
4. modprobe bcma

Now that I stop and think about it…
sudo zypper in kernel-firmware
probably would have fixed it.

The local open source community is bigger now and the next step for you is to organize (or join) global conferences. One part of the organization is the promotion of the conference. You want to have as many visitors as you can.

I will try to write down what I did during openSUSE global conferences and some local events.

BEFORE THE EVENT
0. Web page

There MUST be a web page and a system that accepts registration, paper submission, information etc. Write everything that visitors should know about the conference.
We use OSEM in openSUSE. Check out https://events.opensuse.org

1. Blog blog blog.

You'll have some announcements for the conference. Dates, the place, new website, call for papers announcement, hotels that visitors can stay, schedule, keynote speakers etc. Usually, every open source project has a central blog or news site. You can write the articles there. Try to make fuzz by publishing your articles often.
Global communities can translate the announcements to their language and promote the conference locally.

Local communities are formed by members with blogs who publish on different planet sites. You can make a schedule so everyone can publish the announcement every other day. More eyes will see the announcement and will apply either as speaker or visitor.

Two things you want to have are contributors+visitors and sponsors. If your project is famous, then it's easy. If not, then you better publish the initial announcement to magazines, newspapers, technical blogs-sites. If you don't have access, then you better send it by e-mail or fax and then call them and ask them if they got the text. If they publish it, you're lucky.

Translate those announcements and publish them, so the local population will see that there's a conference coming.


2. Promote to other FOSS conferences

There are plenty of FOSS conferences around the world.
* Community (local or global) has to apply for a booth and/or, if it's possible, present why someone should attend.
* At the booth, you should have promo materials for your conference and give them away to local LUGs or hackerspaces to hang posters at their places.
* Another cool thing is to have free coupons for beer at the conference. If beer isn't the solution, then find another thing that can be found only at your conference and give free coupons.
* Wear special T-Shirts with the logo or #oSC or "Ask me for the conference". You show people that you're organizing something and can ask you questions.
* Finally, go to the other project's booth and invite them. You can ask them if they want to have a booth at your conference or apply for a presentation.


3. Messages to post

Create a list of messages you'll post to social media.
First of all, you should post the announcements.
Then create a list of general messages that you should post before the conference. Content will be related to the subject of the conference or the country etc.
When you have the schedule ready, create a post with the name of the person (mention him/her on social media), the title of the presentation (mention if it's a famous project).
The messages can be 2-3 per day but not at the same time. Try to have a 4-5 hours time delay between tweets.


4. Twitter

Create a twitter account that will be used for the conference. Everyone can use it as a hashtag (#) and also can communicate with you before and during the conference. For openSUSE, we had #opensuseconf as a hashtag. The account was @opensuseconf
The same account can create the Lanyard event (you'll see next).

5. Facebook event page

Create a Facebook event page under the official account of the project. Post the tweets here as well. Post the messages (no 2). If you have some cool documentation of the subject that will be presented, just post it.

Since the address will be difficult to remember, create a subdomain under your project's name (eg facebook.conference.opensuse.org) that will forward it to the event page.

6. Google Plus event page

Do the same as facebook. Some people hate to use facebook, so google plus is the solution. Do the same also with the URL.
Google Plus event notifies to e-mail every user about changes. So if you post, they'll get a notification.

7. Lanyard event page

This isn't very famous but it's very cool. It uses twitter accounts. You setup the event and when you have the schedule, you can add the subject and mention the speaker. You can also use it to post announcements.
Here is the lanyard of openSUSE conference 2014

8. Meetup.com event

If money is not an issue for your project, you can create an event at http://www.meetup.com

9. IRC, mailing lists, forums

You have to create an IRC channel where you reply to all possible questions. There's also a mailing list for that.
To promote the conference, you should post the announcement to mailing lists, forum of all possible projects (eg if we're openSUSE, then post to GNOME, KDE, ownCloud etc). And try to inform the posts with the new announcements.


10. Flickr

Create a group where people can upload their pictures, so everyone who blogs can use those pictures. You can create it before the event starts and post pictures from the venue before you set it up.


DURING THE EVENT
1. Messages to post

Create a document with messages to post with all the presentations. The message has to be:

Presentation title (with mention) @ #Room_name. Not @ #oSC15 #openSUSE? Live @ Stream_URL

Create a table. Columns will be the rooms, rows will be the timetable. So you'll check the time and post the right one.

WARNING: Check with the program team if there was a daily change of the program. Also, check the right Stream URL.


2. Twitter

Here you start posting the messages per time. Don't forget the mentions to people, projects, and the #. Here you mention someone by using @username.


3. Facebook event page

Same as Twitter, don't forget to mention. Here mention is with @Project name. Here you can use more characters than twitter. So here you can also add the hashtag of your project (eg #opensuse, #opensuseconf)
Ask people to upload pictures here. Also ask people to post their reports.


4. Google plus event page

Same as Twitter, don't forget to mention. Here mention is with +Project name. Here you can use more characters than twitter. So here you can also add the hashtag of your project (eg #opensuse, #opensuseconf).
Again, ask people to upload pictures here. Also ask people to post their reports.


5. IRC

You can post here as well. Some people didn't join you or they just see live streaming and use IRC to ask the speaker. So it'll be nice if there’s a program of what's in every room with the streaming URL.


6. Streaming

The social media guy is responsible to handle all the above. He checks if the streaming is working and if not, then warns the video team. It's good for him because he can see all presentations but it's kind of "I'm locked somewhere and I don't mingle with people".
Users who didn't make it can see the conference over the Internet.


7. Flickr

Try to gather all pictures and upload them in the afternoon, so everyone who wants to blog can use the pictures from there (there are Google Plus and Facebook events as alternatives). It's very cool if the pictures are up very soon, so everyone can view them.