Some words about hedging

The Bitcoin market is pretty fresh and unstable at the moment. It is greatly affected by any news on this market. We expect slow grow of exchange rates in the long-term. This assumptions is based on the following facts:

• The world requires anonymous currency. It is used not only for illegal transactions (like buying/selling drugs, weapons etc.), but also as a currency which is free from any political influence, not affiliated with any country, etc.
• Close-to-zero transaction fees. If an operation is made within the Bitcoin infrastructure you have no additional fees for running a bitcoin account
• Deflationary nature of bitcoin. The emission amount is fixed and could not be extended. Since (like any other currency) bitcoin's will be lost - the price of the rest should increase to compensate that

Unfortunately, all other *coins (Litecoin, Dogecoin, etc.) have close-to-zero influence on bitcoin exchange rates, while bitcoin exchange rates affects this currencies greatly. Detailed analytics of exchange rates dynamics on 3 different exchange markets revealed 0.00037% probability of getting profit by running exchange operations between different *coins (mostly due to exchange fees of sites)

Our opinion is that it is a nice time to start getting bitcoins :) It's exchange rates have still not recovered after the MtGOX failure, but recent research revealeds that MtGOX may have money on it's account, so we expect constant growing exchange rate of Bitcoin in next 3 months

What needs to be implemented?

This section describes a scope of the project. The main target of current project is to provide an easy way to perform easy transactions within system. So we need just three points of functionality:

• Adding money to amount (cash-in)
• Transferring money to other person's account
• Cash-out

Additionally to simplify people's life transferring money to other person's account should track "friends list" to simplify multiple transactions to other persons.

Since world is mobile now - all that operations should be available both from web-interface and mobile apps.

What will be great to have in future?

This section describes functionality outside initial project scope, but could be considered in future.

• "Send me money" button. When user click's it a popup appears on site where person could send money in one click
• QR-send. Using mobile you could scan a QR-code and confirm sending money in one click

What about security?

Security is a main concern of the project. Since we're building a system on top of bitcoin - there is no way to reverse any transaction.

So let's review possible approaches.

(rejected) Single bitcoin account managing all users accounts

We have just one bitcoin wallet, which contains all coins owned by our users. All in-system transactions are tracked by our system, same applies to account balances.

Pros: + Very easy to implement + Extremely fast (since there are no "real" transactions when we pass money from one person to other)

Cons: + extremely risky. Let's imagine situation when hacker was able to access account. He will be able to move all bitcoins to other address resulting in system crash

(rejected) Separate bitcoin wallet for each user

Each user has one bitcoin wallet. All transactions are performed by real bitcoin transactions

Pros: + Simplifies client logic. We do not need to "count" money - just retrieve them from bitcoin wallet and display to user + Way more secure - user have no real access to other uses wallet

Cons: + harder to implement + When we make transaction from one user to another we need to receive confirmation from bitcoin network which is not immediate. + risky. If hacker was able to compromise not account, but access to system same risks as previous options apply

Separate bitcoin wallet + cash-in-out wallet

The main problem of the previous approach is that a possible hacker has access to all bitcoins in the system, including bitcoins used by the cash-in and cash-out wallet. The solution is to run the system using 2 separate modules (ideally on two different network machines) - one for in-system transactions and one for cash-in/cash-out. The second one should accept just two operations "Give X BTC to user Y in system" or "Take X BTC from user Y". Since the code of second module will be simple and straightforward - it's easier to make it secure. Compromising client accounts will not compromise real money

How that will work?

AAA (Authorization, Authentication, Accounting) is always a compromise between usability and security. We suggest the following approach:

• User registers with his phone number. He may (or may not) enter recovery email address
• When user signs-in into the application two-factor auth is used by default - login, password + OTP (one-time-password) sent by SMS. Two-factor auth may be disabled in the settings by the user
• Each transaction higher than X$ is confirmed by OTP. If total sum of transactions within one hour exceeds X$ - each transaction is confirmed by OTP (that is done to prevent stealing money by millions of small transactions)
• Password recovery - user will have two options - send recovery info to email or to phone. If he selects phone - recovery information is sent within next 48 hours (but not earlier than 24 hours). That is done to ensure that if phone is stolen - user has enough time to block sim-card.

What is the status of development?

We're currently working on server-side stuff - bitcoin's transferring between two separates system. This part of system will be covered by unit tests to ensure security and reliability. Code should be ready soon if anyone is interested

0 0

26 Mar 2014 9:10pm GMT

Meeting held on FreeNode, channel #maemo-meeting (logs)

Attending: Joerg Reisenweber (DocScrutinizer05), Ruediger Schiller (chem|st), Gido Griese (Win7Mac), Niel Nielsen (nieldk), Robert Schiller (lowkyalyr), kerio, Titilambert, Paul Healy (sixwheeledbeast), Martin Kolman (M4rtinK), Falk Stern (warfare), Aaron McEwan (chainsawbike), Jussi Ohenoja (juiceme).

Absent:

Summary of topics (ordered by discussion):
- Kickoff meeting for Meamo Community e.V.

Topic (Kickoff meeting for Meamo Community e.V.):

• There was discussion about the voting engine used to prepare/handle/tally the votes in Maemo community matters. As it happens woody is the only one who knows how the system operates, so in the future woody needs to either continue to maintain it or pass the knowledge of it to other people capable of using it.
• This time the Maemo Council meeting was held with a differnt topic as usual, so the rest ot the meeting was conducted as formal Kickoff/Inaugural meeting of the new Maemo Community e.V.
• Win7Mac had prepared the following meeting agenda, which was presented to the attendeeds:
  • 1.)Commentary and vote on the Statutes and General rules
  • 2.) Election of the board of directors and acceptance of the internal board regulations
  • 3.)Election of the council
  • 4.)Agreement about member-fees
  • 5.)Organizational enactments
  • 6.)Miscellaneous
• chem|st opened the meeting on March 18 2014 20:32 UTC and welcomed the participants.
• Meeting attendees introduced themselves by stating their real names for record.
• chem|st was appointed the Chair of the meeting, and juiceme was appointed the Secretaty.
• The assembly accepted articles of incorporation and the association rules unanimously. Thus Maemo Community Association is founded by the present company, and all present are named active members of the community.
• juiceme, nieldk and chem|st were nominated for directors of the association. All accepted the nomaination and were voted unanimously for the position.
• The directors accepted Board's Internal Regulations unanimously
• chem|st was nominated as board's Chairman, juiceme was nominated for Secretary and nieldk was nominated for for Treasurer. All accepted the position and were voted for unanimously.
• The current Maemo Council, consisting of DocScrutinizer05, chem|st and juiceme was nominated for the Council of Maemo Community Association. The vote for council was unanimous.
• juiceme was nominated as Chairman of the Council. He was voted for it unanimously and accepted the nomination.
• It was decreed that with reference to the Statutes and Association Rules passive membership generally is free of any charges. Any payment of fees for active or honoured members is suspended for the time being.
• The board of directors was assigned to do all nescessary steps to register the association at the district court.
• The chairman thanked all assembled and closed the meeting at 21:27 UTC

0 0

24 Mar 2014 7:30am GMT

1 0

19 Mar 2014 8:17pm GMT

Meeting held on FreeNode, channel #maemo-meeting (logs)

Attending: Joerg Reisenweber (DocScrutinizer51), Ruediger Schiller (chem|st), Gido Griese (Win7Mac), Paul Healy (sixwheeledbeast), Jussi Ohenoja (juiceme).

Absent:

Summary of topics (ordered by discussion):
- Discussion on moving Hildon Foundation to a german e.V.

Topic (Discussion on moving Hildon Foundation to a german e.V.):

• DocScrutinizer announced that it is no longer possible to donate to Maemo through his PayPal account, so there needs to be found another way for people to support running the Memo infra.
• juiceme was under the mistaken impression that this MC meeting would also serve as Maemo E.v. founding/kickoff meeting. However as there are not yet enough founders the kickoff meeting needs to be postponed.
• There was a lot of general discussion on the form of the E.v., as it was questioned that the suggestion for the new council would be 5 people, and current Maemo Council stands a 3 people. It was noted that actually the numver 5 is not a strict requirement, and the E.v. rules could be modified so thet number of council would be 3 and the current council could become the new Maemo E.v. council, provided that current Maemo Council rules are exactly same as in the new council.

0 0

16 Mar 2014 3:41pm GMT

Probably everyone has encountered a package in Ubuntu which was not the newest released version while one for some reason needed the newest one. The first step is to search for a PPA with the desired version. But what if there is no such PPA or you want to build the version yourself? This is where this guide comes in. Note however that this is not aimed at ordinary users - you need some experience with programming/ compiling to successfully build a package.

Before you start

Before you start make sure that you have source packages enabled in your software sources.
Next you obviously need the upstream source tar-ball of the new program which should look something like <packagename>-<version>.tar.gz.
Download this tar-ball to a new directory <somedir> and extract it there.

Updating Package info

For the following commands I assume you are in the previously created directory <somedir>.

First we need to get the old version of the source package

apt-get source <packagename>

This will download and extract the old source package into <packagename>-<oldversion>.

Now we need some helper scripts to perform the upgrading as well as the build-time dependencies of the package

sudo apt-get install dpkg-dev devscripts fakeroot
sudo apt-get build-dep <packagename>

Next change into the extracted sources of the old package and update the packaging

cd <packagename>-<oldversion>
uupdate -v <newversion> ../<packagename>-<newversion>.tar.gz

# change into the extracted new package
cd ../<packagename>-<newversion>

# update version info
dch -l ~ppa -D $(lsb_release -sc)

For more information see the Debian New Maintainers Guide.

Building the program

To trigger a rebuild of the program simply execute

dpkg-buildpackage

Uploading your version to a PPA

To upload a package to a PPA you first need to sign it to prove that you are the author. To do this you have to execute the following in the <packagename>-<newversion> directory

debuild -S

Furthermore you need the upload tool dput to actually perform the uploading

sudo apt-get install dput

Now change to <somedir> and execute

dput ppa:<your_username>/<repository> <source.changes>

You can find more information at Launchpad.

1 0

15 Mar 2014 12:03pm GMT

While we're supplying N9 users with fresh releases of gPodder 3 regularly (the latest version, 3.6.1, has been released last week, and the update is available on gpodder.org/downloads), of course we've also been busy working on a newer, Qt 5 and PyOtherSide-based version of gPodder. After weeks of testing, I think it's good enough for a first release now, so let's warmly welcome gPodder 4.0.0 to the world of Sailfish apps. You can download it and its dependencies from the gPodder downloads page.

If you haven't read last year's article about Python and Qt 5, now might be a good time to do so. PyOtherSide is a much more minimalistic approach to Python bindings, and - in my obviously biased opinion - works better for gluing together a QML UI with a Python backend. In fact, it lends itself to clearly splitting the frontend from the backend, and with the "asynchronous by default" design, you have to work really hard to block your UI thread with long-running Python code (or multithreaded Python code that's waiting for the GIL to be released). PyOtherSide these days is also well-documented, and some early annoyances and bugs have been fixed with recent releases in February. In combination with Qt 5 and Python 3, it works well on OS X, Blackberry 10, Linux, Sailfish OS and Windows. With Qt 5.2 having official support for Android, and a Python 3 port being available, it's only a matter of time before PyOtherSide lands on Android.

For all Sailfish OS users out there: Until the next Sailfish OS update, you might have to install some dependencies before gPodder will correctly start up, these are:

1. libpython3 (the Python 3 interpreter)
2. python3-base (the Python 3 standard library)
3. pyotherside (the Qt 5-Python3 bindings)

As these links point to the current version in OBS, they will break once one of these packages is updated. In this case, just look into the home:thp:gpodder armv7hl repository for the latest versions of these packages. With the next Sailfish OS update, recent-enough packages of PyOtherSide should be in the repositories, so you don't need to install the dependencies manually.2 0

15 Mar 2014 11:07am GMT

Tomorrow (Monday the 3rd of March) at 5pm UTC I'll be giving a talk about QML and Box2D based game development for the Ubuntu App Developer Week, details of my talk can be found here: http://summit.ubuntu.com/appdevweek-1403/meeting/22144/game-development-with-qml-and-box2d/

In preparation for this I've put together a simple template for getting started with QML and Box2D development for both desktop Ubuntu and Ubuntu Touch. It's available in two flavours:

• Precompiled version - Includes QML Box2D already compiled for amd64 and armhf (when I have more time I'll add i386 to this as well).
• Source version - Makes it easy to compile everything yourself on whatever architecture you're interested in.

This means that if your game is going to be purely QML based you can just grab the precompiled version, and run "make click-packages" and have packages built for both desktop and mobile use at the same time.

The template comes populated with an example application (one of the standard QML Box2D demos), which is found in the "src/" directory; so you'll be able to see something running straight out of the box, then when you're ready you can just replace this with your own game.

In the future I also plan to extend these templates to provide example packaging for multiple different QML + Box2D compatible mobile platforms (Sailfish, MeeGo, Blackberry, Android, etc.)

If you're interested in seeing an example of the sort of thing you can achieve fairly easily with QML and Box2D I've also uploaded a video of one of my current work in progress projects:

1 0

02 Mar 2014 11:57pm GMT

Meeting held on FreeNode, channel #maemo-meeting (logs)

Attending: Joerg Reisenweber (DocScrutinizer05), Ruediger Schiller (chem|st), Gido Griese (Win7Mac), Paul Healy (sixwheeledbeast), Jussi Ohenoja (juiceme).

Absent:

Summary of topics (ordered by discussion):
- Discussion on moving Hildon Foundation to a german e.V.

Topic (Discussion on moving Hildon Foundation to a german e.V.):

• Win7Mac has consulted a lawyer on the responsibilities of directors of an E.v. and the extents of liability. It seems that directors are "only liable for damage by gross negligence and intent" so there propably is no need for an extra insurance for the directors. There was some general talk over liability, and juiceme asked if there is any possibility that in EU there could be similar threat of litigation that Woody was fearing could happen to HiFo in US. General consensus seems to be that it is not likely.
• chem|st asked if Win7Mac will take care of the "Nokia" statements all over the website, and check that there are no unappropriate binaries in repositories.
• Win7Mac presented the work-on-progress for the changing of names/terms in the legal documentation on the website:
  • Contribution Guidelines
  • Terms + Conditions
  • Privacy Policy

Win7Mac told that when the documenation has been finished it will be reviewed again by a lawyer, and should be finalized by friday this week.

1 0

28 Feb 2014 8:51pm GMT

While the Owncloud Manual suggests enabling SSL, it unfortunately does not go into detail how to get a secure setup. The core problem is that the default SSL settings of Apache are not sane as in they do not enforce strong encryption. Furthermore the used default certificate will not match your server name and produce errors in the browser.

In the following a short guide in how to set-up a secure Apache 2.4 server for Owncloud will be presented.

Generating a secure Certificate

A secure TLS connection starts with the Server authenticating itself to the client with the server certificate. Therefore we will start the setup of our server with generating that certificate.
The purpose of the certificate is to ensure that if you type in "your.website.net" you are indeed talking to your server and not to a man-in-the-middle who intercepted your connection. Therefore the certificate contains the server name and the public key of the server.

As mentioned above the default certificate will not match your server name and therefore you will have to generate a matching one.

Unfortunately following the apache SSL FAQ will results in a certificate using the possibly vulnerable SHA-1 hashing function. A better alternative is SHA-256, but it has to be explicitly requested during certificate creation. The according call to openssl for certificate creation is

openssl req -new -sha256 -x509 -nodes -days 365 -out your.website.net.pem -keyout your.website.net.key

The resulting certificate and private key have to be referenced in Apache as following

SSLCertificateFile    /path/to/your.website.net.pem
SSLCertificateKeyFile /path/to/your.website.net.key

Note that this results in a so called self-signed certificate. Usually certificates on the web are approved by a Certificate Authority (a digital notary) which confirms your identity. By trusting the CA you can also trust websites that are otherwise unknown to you, but which were approved by the CA.
While this makes sense for public websites, you probably already trust your own server, so there is no need for a CA signed certificate.
Just add your self-signed certificate to the trusted list of your browser on first visit.
If you fear a man-in-the-middle attack during the initial connection, you can also manually copy the generated pem file on a USB-drive and import it in the browser from there.

Using secure ciphers

Using the secure certificate we only know that we are indeed talking to the server we want to talk to. Next we actually want to start sending encrypted messages. In theory we could encrypt data with the public key of the server using asymmetric encryption like RSA. However asymmetric encryption is slow and therefore not suitable for large amounts of data. Furthermore our communication could be decrypted if somebody would record it and at some point in the future get access to the private key of the server. Therefore we want to use a one-time symmetric key. This way we achieve forward secrecy.The symmetric encryption should be also secure in a sense that even when large amounts of data is collected, it is must not be possible to reconstruct the key and decode the data.
Last but not least the chosen cipher should be supported by our clients. Surprisingly it is the Owncloud desktop client which does not support modern ciphers, while current browsers and even the android app does.

Instead of discussing all available ciphers in regard of the above requirements, I would rather refer to the excellent TLS server configuration guide by Mozilla.
Yet we can still improve the suggested configuration. Mozilla has to consider compability with old web-browsers which we do not have to. So without further ado this is the recommend cipher configuration

SSLProtocol all -SSLv2 -SSLv3
SSLCompression off
SSLHonorCipherOrder On
SSLCipherSuite EECDH+AESGCM:EECDH+AES:EDH+AES

The rationale behind this suggestion is

• Allow TLS 1.0 for compability with mobile apps
• Disable SSL compression to mitigate the CRIME attack
• always use Diffie Hellman(DH) key exchange(Kx) for forward secrecy
• prefer Elliptic Curve Diffie Hellman (ECDH) for performance
• always use AES for symmetric encryption
• prefer AES GCM mode for security and performance

Notes

Actually only the Owncloud desktop client forces us to enable ordinary DH key exchange. Besides being much slower than ECDH, a weak modulus is used for DH Kx up to (including) Apache 2.4.6. While there are no practical attacks exploiting this yet, we can only be completely on the safe side by updating to Apache 2.4.7 or fixing the root issue in the desktop client. (bug status)

Also we only allow TLSv1 for compability with the mobile apps as openssl in android does not yet support TLS1.1+. This circumstance is not really critical as BEAST is not applicable in the sync apps and browsers will connect to the server with TLS1.1+ or work around the vulnerability.

Enforcing HTTPS

At this point the secure connection to your server is ready, but we still have to ensure that it is the only way data is exchanged with the clients.
While you can only enable apache on port 443, you will always have to remember to type in https:// in the browser. A better way is to automatically redirect from port 80 to port 443 like

<VirtualHost *:80>
        ServerName your.website.net
        Redirect permanent / https://your.website.net/
</VirtualHost>

Note that you do not have to use mod_rewrite here as Owncloud sets the HSTS header, so browsers will automatically prefix all requests with https after the first visit.

But whatever you do, remember this

1 0

22 Feb 2014 10:53am GMT

Meeting held on FreeNode, channel #maemo-meeting (logs)

Attending: Joerg Reisenweber (DocScrutinizer05), Ruediger Schiller (chem|st), Gido Griese (Win7Mac), chainsawbike, Jussi Ohenoja (juiceme).

Absent:

2 0

18 Feb 2014 8:36am GMT

It was somewhere between 7th and 11th February 2004 when I got package with my first Linux/ARM device. It was Sharp Zaurus SL-5500 (also named "collie") and all started…

At that time I had Palm M105 (still own) and Sony CLIE SJ30 (both running PalmOS/m68k) but wanted hackable device. But I did not have idea what this device will do with my life.

Took me about three years to get to the point where I could abandon my daily work as PHP programmer and move to a bit risky business of embedded Linux consulting. But it was worth it. Not only from financial perspective (I paid more tax in first year then earned in previous) but also from my development. I met a lot of great hackers, people with knowledge which I did not have and I worked hard to be a part of that group.

I was a developer in multiple distributions: OpenZaurus, Poky Linux, Ångström, Debian, Maemo, Ubuntu. My patches landed also in many other embedded and "normal" ones. I patched uncountable amount of software packages to get them built and working. Sure, not all of those changes were sent upstream, some were just ugly hacks but this started to change one day.

Worked as distribution leader in OpenZaurus. My duties (still in free time only) were user support, maintaining repositories and images. I organized testing of pre-release images with over one hundred users - we had all supported devices covered. There was "updates" repository where we provided security fixes, kernel updates and other improvements. I also officially ended development of this distribution when we merged into Ångström.

I worked as one of main developers of Poky Linux which later became Yocto Linux. Learnt about build automation, QA control, build-after-commit workflow and many other things. During my work with OpenedHand I also spent some time on learning differences between British and American versions of English.

Worked with some companies based in USA. This allowed me to learn how to organize teamwork with people from quite far timezones (Vernier was based in Portland so 9 hours difference). It was useful then and still is as most of Red Hat ARM team is US based.

I remember moments when I had to explain what I am doing at work to some people (including my mom). For last 1.5 year I used to say "building software for computers which do not exist" but this is slowly changing as AArch64 hardware exists but is not on a mass market yet.

Now I got to a point when I am recognized at conferences by some random people when at FOSDEM 2007 I knew just few guys from OpenEmbedded (but connected many faces with names/nicknames there).

Played with more hardware then wanted. I still have some devices which I never booted (FRI2 for example). There are boards/devices which I would like to get rid of but most of them is so outdated that may go to electronic trash only.

But if I would have an option to move back that 10 years and think again about buying Sharp Zaurus SL-5500 I would not change it as it was one of the best things I did.

All rights reserved © Marcin Juszkiewicz
It is 10 years of Linux on ARM for me was originally posted on Marcin Juszkiewicz website

3 0

11 Feb 2014 9:19pm GMT

Meeting held on FreeNode, channel #maemo-meeting (logs)

Attending: Joerg Reisenweber (DocScrutinizer05), Ruediger Schiller (chem|st), Gido Griese (Win7Mac), chainsawbike, freemangordon, kerio, Jussi Ohenoja (juiceme).

Absent:

Summary of topics (ordered by discussion):
- Proposals for next contest
- Discussion on moving Hildon Foundation to a german e.V.

Topic (Proposals for next contest):

• No news, seems Jolla peole have been busy with FOSDEM.

Topic (Discussion on moving Hildon Foundation to a german e.V.):

• Win7Mac has drawn up nice proposals on the different possibilities to organize: first draft of various possibilities
• More refined models: KDE model and General Assembly centered model and final draft
• Discussion on whether there needs to be an annual support fee for community, pros: it would heighten the sense/value of community.
• Discussion on the actual method of the moving, do we need a general census/election for community to okay the move?

1 0

11 Feb 2014 5:20pm GMT

0 0

07 Feb 2014 1:11am GMT

The idea of Full-Stack Development is quite popular at the moment - building things that run both the browser and the server side of web development, usually utilizing similar languages and frameworks.

With Flow-Based Programming and the emerging Flowhub ecosystem, we can take this even further. Thanks to the FBP network protocol we can build and monitor graphs spanning multiple devices and flow-based environments.

Jon Nordby gave a Flow-Based Programming talk in FOSDEM Internet of Things track last weekend. His demo was running a FBP network comprising of three different environments that talk together. You can find the talk online.

Here are some screenshots of the different graphs.

MicroFlo running on an Arduino Microcontroller and monitoring a temperature sensor:

NoFlo running on Node.js and communicating with the Arduino over a serial port:

NoFlo running in browser and communicating with the Node.js process over WebSockets:

(click to see the full-size picture)

Taking this further

While this setup already works, as you can see the three graphs are still treated separately. The next obvious step will be to utilize the subgraph features of NoFlo UI and allow different nodes of a graph represent different runtime environments.

This way you could introspect the data passing through all the wires in a single UI window, and "zoom in" to see each individual part of the system.

The FBP ecosystem is growing all the time, with different runtimes popping up for different languages and use cases. While NoFlo's JavaScript focus makes it part of the Universal Runtime, there are many valid scenarios where other runtimes would be useful, especially on mobile, embedded, and desktop.

Work to be done

Interoperability between them is an area we should focus on. The network protocol needs more scrutiny to ensure all scenarios are covered, and more of the FBP/dataflow systems need to integrate it.

Some steps are already being taken in this direction. After Jon's session in FOSDEM we had a nice meetup discussing better integration between MicroFlo on microcontrollers, NoFlo on browser and server, and Lionel Landwerlin's work on porting NoFlo to the GNOME desktop.

If you're interested in collaborating, please get in touch!

Photo by Forrest Oliphant.

1 0

06 Feb 2014 8:00am GMT

Meeting held on FreeNode, channel #maemo-meeting (logs)

Attending: Joerg Reisenweber (DocScrutinizer05), Ruediger Schiller (chem|st), Paul Healy (sixwheeledbeast), freemangordon, kerio, Jussi Ohenoja (juiceme).

Absent:

Summary of topics (ordered by discussion):
- Proposals for next contest
- Discussion on the mailing list
- Things to be settled with Nokia

Topic (Proposals for next contest):

• No news, Chemist has contacted Cybette but no answer yet.

Topic (Discussion on the mailing lists):

• There was discussion on the technical merits of a majordomo based list vs. current mail forwarder based list.
• It was decided that for council matters forwarder is better, and it can be implemented using masked send addresses to avoid bouncing on strictly configured servers.

Topic (Things to be settled with Nokia):

• No progress currentl.y
• Discussion on alternatives if maemo.org cannot be used.

1 0

28 Jan 2014 6:08pm GMT

I will be doing a presentation about Tracker at FOSDEM this year.

1 0

24 Jan 2014 11:12am GMT