FLOSS Project Planets

The DOM and your wish-list

Planet KDE - Tue, 2014-08-05 07:28

This week is the last of the “active coding” period of the Google Summer of Code. On Monday 11, students should stop implementing features and start documenting things, fixing the remaining bugs and ensure that everything is working.

I don’t have a huge list of new features to present this week because I had to fight a very nasty bug (and it is still not entirely resolved), but here is nevertheless an addition to the QML/Javascript language support plugin for KDevelop that may be quite useful to a lot of people: support for the Javascript DOM.

The Document Object Model

Last week, I added support for Node.js modules. I did that because several users of the QML/JS plugin told me that they regularly work on Node.js code. This week, despite a bug that makes the unit tests fail (but not the real-world KDevelop), I decided to add support for the Document Object Model of Javascript, so that web developers have their scripts fully supported by KDevelop. As libraries like jQuery also rely on the DOM, having it supported is a good thing.

The DOM is really huge and contains hundreds (if not thousands) of classes. Each HTML element or CSS property has its own class, and there are even classes for things like cookie handling, message passing between web pages, XmlHttpRequest, etc.

I was not very fond of the idea of writing Javascript description files for all these classes. Luckily, I received an unexpected help here: Webkit (the web engine) also has to support these classes, and instead of implementing them directly in Javascript on C++, it ships files having a .idl extension. These files describe the API of the different classes and look like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15module window { interface [ ...ignored... ] DOMWindow { attribute [Replaceable] BarInfo locationbar; attribute [Replaceable] BarInfo menubar; attribute [Replaceable] BarInfo personalbar; attribute [Replaceable] BarInfo scrollbars; attribute [Replaceable] BarInfo statusbar; DOMSelection getSelection(); [Custom] DOMWindow open(in DOMString url, in DOMString name, in [Optional] DOMString options); } }

The statements between brackets are hints for the Javascript binding generator and can be ignored. What is interesting in those files is that the attributes, methods and arguments are all named and typed. This means that no information is missing! I just had to write a Python script that parses one of these files and produces a .js equivalent, and I was able to add support for all the DOM.

This morning, I’ve pushed a big commit to the kde:kdev-qmljs repository. It adds more than 10000 lines of .idl and .js files (I ship the IDL files so that looking at them and possibly modifying them is easier, but their real origin is Webkit). The Javascript file describing the DOM is approximately 4000 lines long and takes a bit more than two seconds to parse. In order to keep it to a reasonable size, I skipped the Canvas classes, the HTML classes (having Element is enough, no need to have HTMLLink, HTMLParagraph, HTMLSpan, etc), the File classes (web storage), the XML parser classes and several other ones. They are rarely used and would have made the description file far too big and too slow to parse. I can still add these classes if many users need them, though.

Here are now some screenshots:

Creating a DOM element.

Code-completion for DOM classes.

Code-completion for global variables and functions (that are in fact members of “window”, yes, “window.alert()” works in JS).

Finishing touches and wish-lists

The DOM was the last big feature planned for the QML/JS plugin. In fact, I’m very happy to have been able to go this far in the project. My original GSoC proposal was entirely oriented towards QML, with only basic support for Javascript (just enough for Javascript snippets to be usable in QML files).

I’ve still some bugs to fight and some things to improve. For instance, having “class HTMLElement inherit Element” displayed in the navigation widget instead of “function HTMLElement()” could be a nice addition. Allowing the user to add include paths (for Node.js and QML modules) could also be great, because some QML modules are not installed at the same place as the others.

But what I would really like to do is to implement what daily QML developers may want. I have posted a message on the plasma-devel mailing list asking which features Plasma developers (regular QML users) may want. I’ve already got some hints, but don’t hesitate to tell me what you would like to have implemented in kdev-qmljs. I will also be in Randa, and while most of my time will be dedicated to porting the QML/JS plugin to KF5, I will also try to listen to the wishes of everyone present.

Categories: FLOSS Project Planets

Simon Josefsson: Replicant 4.2 0002 and NFC on I9300

Planet Debian - Tue, 2014-08-05 07:20

I’m using Replicant on my Samsung SIII (i9300) phone (see my earlier posts). During my vacation the Replicant project released version 4.2-0002 as a minor update to their initial 4.2 release. I didn’t anticipate any significant differences, so I followed the installation instructions but instead of “wipe data/factory reset” I chose “wipe cache partition” and rebooted. Everything appeared to work fine, but I soon discovered that NFC was not working. Using adb logcat I could get some error messages:

E/NFC-HCI ( 7022): HCI Timeout - Exception raised - Force restart of NFC service F/libc ( 7022): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 7046 (message) I/DEBUG ( 1900): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 1900): Build fingerprint: 'samsung/m0xx/m0:4.1.1/JRO03C/I9300XXDLIB:user/release-keys' I/DEBUG ( 1900): Revision: '12' I/DEBUG ( 1900): pid: 7022, tid: 7046, name: message >>> com.android.nfc <<<

The phone would loop trying to start NFC and having the NFC sub-system die over and over. Talking on #replicant channel, paulk quickly realized and fixed the bug. I had to rebuild the images to get things to work, so I took the time to create a new virtual machine based on Debian 7.5 for building Replicant on. As a side note, the only thing not covered by Replicant build dependency documentation was that I needed the Debian xmllint package to avoid a build failure and the Debian xsltproc package to avoid a error message being printed in the beginning of every build. Soon I had my own fresh images and installed them and NFC was working again, after installing the non-free libpn544_fw.so file.

During this, I noticed that there are multiple libpn544_fw.so files floating around. I have the following files:

version string source libpn544_fw_C3_1_26_SP.so internet libpn544_fw_C3_1_34_SP.so stock ROM on S3 bought in Sweden during 2013 and 2014 (two phones) libpn544_fw_C3_1_39_SP.so internet

(For reference the md5sum's of these files are 682e50666effa919d557688c276edc48, b9364ba59de1947d4588f588229bae20 and 18b4e634d357849edbe139b04c939593 respectively.)

If you do not have any of these files available as /vendor/firmware/libpn544_fw.so you will get the following error message:

I/NfcService( 2488): Enabling NFC D/NFCJNI ( 2488): Start Initialization E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so E/NFCJNI ( 2488): phLibNfc_Mgt_Initialize() returned 0x00ff[NFCSTATUS_FAILED] E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so W/NFCJNI ( 2488): Firmware update FAILED E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so W/NFCJNI ( 2488): Firmware update FAILED E/NFC-HCI ( 2488): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so W/NFCJNI ( 2488): Firmware update FAILED E/NFCJNI ( 2488): Unable to update firmware, giving up D/NFCJNI ( 2488): phLibNfc_Mgt_UnConfigureDriver() returned 0x0000[NFCSTATUS_SUCCESS] D/NFCJNI ( 2488): Terminating client thread... W/NfcService( 2488): Error enabling NFC

Using the first (26) file or the last (39) file does not appear to be working on my phone, I get the following error messages. Note that the line starting with 'NFC capabilities' has 'Rev = 34' in it, possibly indicating that I need the version 34 file.

I/NfcService( 5735): Enabling NFC D/NFCJNI ( 5735): Start Initialization D/NFCJNI ( 5735): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 8 D/NFCJNI ( 5735): Download new Firmware W/NFCJNI ( 5735): Firmware update FAILED D/NFCJNI ( 5735): Download new Firmware W/NFCJNI ( 5735): Firmware update FAILED D/NFCJNI ( 5735): Download new Firmware W/NFCJNI ( 5735): Firmware update FAILED E/NFCJNI ( 5735): Unable to update firmware, giving up D/NFCJNI ( 5735): phLibNfc_Mgt_UnConfigureDriver() returned 0x0000[NFCSTATUS_SUCCESS] D/NFCJNI ( 5735): Terminating client thread... W/NfcService( 5735): Error enabling NFC

Loading the 34 works fine.

I/NfcService( 2501): Enabling NFC D/NFCJNI ( 2501): Start Initialization D/NFCJNI ( 2501): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0 D/NFCJNI ( 2501): phLibNfc_SE_GetSecureElementList() D/NFCJNI ( 2501): D/NFCJNI ( 2501): > Number of Secure Element(s) : 1 D/NFCJNI ( 2501): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef D/NFCJNI ( 2501): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING] I/NFCJNI ( 2501): NFC Initialized D/NdefPushServer( 2501): start, thread = null D/NdefPushServer( 2501): starting new server thread D/NdefPushServer( 2501): about create LLCP service socket D/NdefPushServer( 2501): created LLCP service socket D/NdefPushServer( 2501): about to accept D/NfcService( 2501): NFC-EE OFF D/NfcService( 2501): NFC-C ON

What is interesting is, that my other S3 running CyanogenMod does not have the libpn544_fw.so file but still NFC works. The messages are:

I/NfcService( 2619): Enabling NFC D/NFCJNI ( 2619): Start Initialization E/NFC-HCI ( 2619): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so W/NFC ( 2619): Firmware image not available: this device might be running old NFC firmware! D/NFCJNI ( 2619): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0 D/NFCJNI ( 2619): phLibNfc_SE_GetSecureElementList() D/NFCJNI ( 2619): D/NFCJNI ( 2619): > Number of Secure Element(s) : 1 D/NFCJNI ( 2619): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef D/NFCJNI ( 2619): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING] I/NFCJNI ( 2619): NFC Initialized D/NdefPushServer( 2619): start, thread = null D/NdefPushServer( 2619): starting new server thread D/NdefPushServer( 2619): about create LLCP service socket D/NdefPushServer( 2619): created LLCP service socket D/NdefPushServer( 2619): about to accept D/NfcService( 2619): NFC-EE OFF D/NfcService( 2619): NFC-C ON

Diffing the two NFC-relevant repositories between Replicant (external_libnfc-nxp and packages_apps_nfc) and CyanogenMod (android_external_libnfc-nxp and android_packages_apps_Nfc) I found a commit in Replicant that changes a soft-fail on missing firmware to a hard-fail. I manually reverted that patch in my build tree, and rebuilt and booted a new image. Enabling NFC now prints this on my Replicant phone:

I/NfcService( 2508): Enabling NFC D/NFCJNI ( 2508): Start Initialization E/NFC-HCI ( 2508): Could not open /system/vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so W/NFC ( 2508): Firmware image not available: this device might be running old NFC firmware! D/NFCJNI ( 2508): NFC capabilities: HAL = 8150100, FW = b10122, HW = 620003, Model = 12, HCI = 1, Full_FW = 1, Rev = 34, FW Update Info = 0 D/NFCJNI ( 2508): phLibNfc_SE_GetSecureElementList() D/NFCJNI ( 2508): D/NFCJNI ( 2508): > Number of Secure Element(s) : 1 D/NFCJNI ( 2508): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef D/NFCJNI ( 2508): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING] I/NFCJNI ( 2508): NFC Initialized D/NdefPushServer( 2508): start, thread = null D/NdefPushServer( 2508): starting new server thread D/NdefPushServer( 2508): about create LLCP service socket D/NdefPushServer( 2508): created LLCP service socket D/NdefPushServer( 2508): about to accept D/NfcService( 2508): NFC-EE OFF D/NfcService( 2508): NFC-C ON

And NFC works! At least YubiKey NEO with the Yubico Authenticator app. One less non-free blob on my phone.

I have double-checked that power-cycling the phone (even removing battery for a while) does not affect anything, so it seems the NFC chip has firmware loaded from the factory.

Question remains why that commit was added. Is it necessary on some other phone? I have no idea, other than if the patch is reverted, S3 owners will have NFC working with Replicant without non-free software added. Alternatively, make the patch apply only on the platform where it was needed, or even to all non-S3 builds.

Categories: FLOSS Project Planets

Francesco Chicchiricco: Getting started with Apache Syncope on Debian

Planet Apache - Tue, 2014-08-05 07:14
The upcoming new stable version 1.2.0 brings - among a whole lot of new features - the availability of .deb packages for getting started with Apache Syncope on Debian or Ubuntu.
Categories: FLOSS Project Planets

PyCon Australia: Initial Video releases

Planet Python - Tue, 2014-08-05 06:35

In partnership with out video sponsor New Relic, PyCon Australia 2014 is proud to release our first two videos, our keynote presentations:

Over the coming days we'll release the rest of our videos at www.youtube.com/PyConAU.

Categories: FLOSS Project Planets

ownCloud numbers

Planet KDE - Tue, 2014-08-05 06:30
Last week, we went over some numbers related to ownCloud. Things like the number of people who contributed in the last 12 months or the speed of code flowing in on average. The numbers are impressive and you can read about them in this press release.

AnalysisNumbers can tell you a lot. One thing is of course particularly cool: the numbers are big. Really big. ownCloud has had almost 300 people contribute code to it in the last 12 months. That is a lot. Some perspective: wordpress has had 52 contributors over its lifetime! Drupal: 149. phpbb: 190. Mediawiki: 534. Joomla: 483. VLC media player: 662. ownCloud has had 566 contributors over its lifetime. This is just one metric out of many, and the comparisons are between often wildly different projects so take it with some salt.

One thing I think you can safely conclude: ownCloud is certainly in the big leagues. Looking at our competition, the ownCloud Client team alone (59 contributors over its life time) is bigger than any other open source file sync and share technology.

Why numbersWe primarily want to keep an eye on numbers to see if we are doing well or not. Anecdotal evidence is important (I really like to read all the positive feedback on the #ownCloud7 release) but hard numbers are very important too. For example, if we see fewer new people join ownCloud, we can see if we can improve developer documentation or have to offer better help for new developers on IRC.

We have good reasons to keep an eye on that. Open Source projects typically have a huge turnover (60%/year is normal), requiring us to keep attracting new contributors. Not only that, ownCloud Inc. has hired many community members and, through its marketing and sales machine, is increasing the number of ownCloud users enormously. We do numbers on our user base internally, and the number we make public (about 1.7 million at the moment) is a rather conservative estimate. And growing quickly: Germany's upcoming largest-ever cloud deployment will bring ownCloud to half a million users!

What effect does that have? For one, paid developers can create a 'freight train' effect, accelerating development to a point where it is hard for volunteers to catch up. This is a reason why it is good to split up the apps from the core and to improve the API offered by ownCloud. This makes it easier to keep changes more localized and easier to follow. Another effect is that the growing popularity of ownCloud brings more people to our mailing lists and forums, asking questions. That is a tough issue. Improvements in documentation can help here, but we can also think about other tools and ways to answer questions.
ConclusionsWe can't stare ourselves blind on numbers, and we won't. Real life matters more: that is why we are working hard on preparing the ownCloud Contributor Conference later this month! But it is cool to see confirmed what we already thought: ownCloud is a very significant Free Software community. Not just its size, but also in what we are doing and how we do it!

There still is plenty of work to be done so come help out and liberate more data!
Categories: FLOSS Project Planets

FSF Events: Richard Stallman - "Should We Have More Surveillance Than the USSR?" (Athens, GA)

GNU Planet! - Tue, 2014-08-05 05:30

The speech by Richard Stallman will be nontechnical, admission will be free of charge, and the public is encouraged to attend.

Please fill out our contact form, so that we can contact you about future events in and around Georgia.

Categories: FLOSS Project Planets

Janez Urevc: Progress of Entity embed module in GSoC 2014

Planet Drupal - Tue, 2014-08-05 05:20

If you want to try the module and/or contribute please visit the project page. You are also invited to check original post on groups.drupal.org.

Categories: FLOSS Project Planets

Steve Kemp: Free (orange) SMS alerts

Planet Debian - Tue, 2014-08-05 04:56

In the past I used to pay for an email->SMS gateway, which was used to alert me about some urgent things. That was nice because it was bi-directional, and at one point I could restart particular services via sending SMS messages.

These days I get it for free, and for my own reference here is how you get to receive free SMS alerts via Orange, which is my mobile phone company. If you don't use Orange/EE this will probably not help you.

The first step is to register an Orange email-account, which can be done here:

Once you've done that you'll have an email address of the form example@orange.net, which is kinda-sorta linked to your mobile number. You'll sign in and be shown something that looks like webmail from the early 90s.

The thing that makes this interesting is that you can look in the left-hand menu and see a link called "SMS Alerts". Visit it. That will let you do things like set the number of SMSs you wish to receive a month (I chose "1000"), and the hours during which delivery will be made (I chose "All the time").

Anyway if you go through this dance you'll end up with an email address example@orange.net, and when an email arrives at that destination an SMS will be sent to your phone.

The content of the SMS will be the subject of the mail, truncated if necessary, so you can send a hello message to yourself like this:

echo "nop" | mail -s "Hello, urgent message is present" username@orange.net

Delivery seems pretty reliable, and I've scheduled the mailbox to be purged every week, to avoid it getting full:

Hostnamepop.orange.net UsernameYour mobile number PasswordYour password

If you wished to send mail from this you can use smtp.orange.net, but I pity the fool who used their mobile phone company for their primary email address.

Categories: FLOSS Project Planets

Cheppers blog: 7 +1 steps to plan a successful Drupal website

Planet Drupal - Tue, 2014-08-05 04:00

According to our experience the most usual approach for clients with web development needs is to contact multiple agencies with more or less vague ideas - asking for quotes, and then selecting a choice based on price. This approach is doomed to fail for two reasons:

  • Without a precise specification of requirements, agencies will have to base their quotes entirely on guesses.
  • The client is missing out on the value that the agency could have added if they were involved in the discovery and planning as well.
Categories: FLOSS Project Planets
Syndicate content