Planet Debian

Syndicate content
Planet Debian - http://planet.debian.org/
Updated: 23 hours 39 min ago

Ian Campbell: Debian Installer ARM64 Dailies

Tue, 2014-07-29 15:36

It's taken a while but all of the pieces are finally in place to run successfully through Debian Installer on ARM64 using the Debian ARM64 port.

So I'm now running nightly builds locally and uploading them to http://www.hellion.org.uk/debian/didaily/arm64/.

If you have CACert in your CA roots then you might prefer the slightly more secure version.

Hopefully before too long I can arrange to have them building on one of the project machines and uploaded to somewhere a little more formal like people.d.o or even the regular Debian Installer dailies site. This will have to do for now though.

Warning

The arm64 port is currently hosted on Debian Ports which only supports the unstable "sid" distribution. This means that installation can be a bit of a moving target and sometimes fails to download various installer components or installation packages. Mostly it's just a case of waiting for the buildd and/or archive to catch up. You have been warned!

Installing in a Xen guest

If you are lucky enough to have access to some 64-bit ARM hardware (such as the APM X-Gene, see wiki.xen.org for setup instructions) then installing Debian as a guest is pretty straightforward.

I suppose if you had lots of time (and I do mean lots) you could also install under Xen running on the Foundation or Fast Model. I wouldn't recommend it though.

First download the installer kernel and ramdisk onto your dom0 filesystem (e.g. to /root/didaily/arm64).

Second create a suitable guest config file such as:

name = "debian-installer" disk = ["phy:/dev/LVM/debian,xvda,rw"] vif = [ '' ] memory = 512 kernel = "/root/didaily/arm64/vmlinuz" ramdisk= "/root/didaily/arm64/initrd.gz" extra = "console=hvc0 -- "

In this example I'm installing to a raw logical volume /dev/LVM/debian. You might also want to use randmac to generate a permanent MAC address for the Ethernet device (specified as vif = ['mac=xx:xx:xx:xx:xx:xx']).

Once that is done you can start the guest with:

xl create -c cfg

From here you'll be in the installer and things carry on as usual. You'll need to manually point it to ftp.debian-ports.org as the mirror, or you can preseed by appending to the extra line in the cfg like so:

mirror/country=manual mirror/http/hostname=ftp.debian-ports.org mirror/http/directory=/debian

Apart from that there will be a warning about not knowing how to setup the bootloader but that is normal for now.

Installing in Qemu

To do this you will need a version of http://www.qemu.org which supports qemu-system-aarch64. The latest release doesn't yet so I've been using v2.1.0-rc3 (it seems upstream are now up to -rc5). Once qemu is built and installed and the installer kernel and ramdisk have been downloaded to $DI you can start with:

qemu-system-aarch64 -M virt -cpu cortex-a57 \ -kernel $DI/vmlinuz -initrd $DI/initrd.gz \ -append "console=ttyAMA0 -- " \ -serial stdio -nographic --monitor none \ -drive file=rootfs.qcow2,if=none,id=blk,format=qcow2 -device virtio-blk-device,drive=blk \ -net user,vlan=0 -device virtio-net-device,vlan=0

That's using a qcow2 image for the rootfs, I think I created it with something like:

qemu-img create -f qcow2 rootfs.qcow2 4G

Once started installation proceeds much like normal. As with Xen you will need to either point it at the debian-ports archive by hand or preseed by adding to the -append line and the warning about no bootloader configuration is expected.

Installing on real hardware

Someone should probably try this ;-).

Categories: FLOSS Project Planets

Daniel Pocock: Pruning Syslog entries from MongoDB

Tue, 2014-07-29 14:27

I previously announced the availability of rsyslog+MongoDB+LogAnalyzer in Debian wheezy-backports. This latest rsyslog with MongoDB storage support is also available for Ubuntu and Fedora users in one way or another.

Just one thing was missing: a flexible way to prune the database. LogAnalyzer provides a very basic pruning script that simply purges all records over a certain age. The script hasn't been adapted to work within the package layout. It is written in PHP, which may not be ideal for people who don't actually want LogAnalyzer on their Syslog/MongoDB host.

Now there is a convenient solution: I've just contributed a very trivial Python script for selectively pruning the records.

Thanks to Python syntax and the PyMongo client, it is extremely concise: in fact, here is the full script:

#!/usr/bin/python import syslog import datetime from pymongo import Connection # It assumes we use the default database name 'logs' and collection 'syslog' # in the rsyslog configuration. with Connection() as client: db = client.logs table = db.syslog #print "Initial count: %d" % table.count() today = datetime.datetime.today() # remove ANY record older than 5 weeks except mail.info t = today - datetime.timedelta(weeks=5) table.remove({"time":{ "$lt": t }, "syslog_fac": { "$ne" : syslog.LOG_MAIL }}) # remove any debug record older than 7 days t = today - datetime.timedelta(days=7) table.remove({"time":{ "$lt": t }, "syslog_sever": syslog.LOG_DEBUG}) #print "Final count: %d" % table.count()

Just put it in /usr/local/bin and run it daily from cron.

Customization

Just adapt the table.remove statements as required. See the PyMongo tutorial for a very basic introduction to the query syntax and full details in the MongoDB query operator reference for creating more elaborate pruning rules.

Potential improvements
  • Indexing the columns used in the queries
  • Logging progress and stats to Syslog


LogAnalyzer using a database backend such as MongoDB is very easy to set up and much faster than working with text-based log files

Categories: FLOSS Project Planets

Gunnar Wolf: Editorial process starting in 3... 2... 1...

Tue, 2014-07-29 14:09

Yay!

Today I finally submitted our book, Fundamentos de Sistemas Operativos, for the Editorial Department of our institute. Of course, I'm not naïve enough to assume there won't be a heavy editorial phase, but I'm more than eager to dive into it... And have the book printed in maybe two months time!

Of course, this book is to be published under a free license (CC-BY-SA). And I'm talking with the coauthors, we are about to push the Git repository to a public location, as we believe the source for the text and figures can also be of interest to others.

The book itself (as I've already boasted about here :-} ) is available (somewhat as a preprint) for download.

[update] Talked it over with the coauthors, and we finally have a public repository! Clone it from:

https://github.com/gwolf/sistop.git

Or just browse it from Github's web interface.

Categories: FLOSS Project Planets

Christian Perrier: Developers per country (July 2014)

Tue, 2014-07-29 12:34
This is time again for my annual report about the number of developers per country.

This is now the sixth edition of this report. Former editions:

So, here we are with the July 2014 version, sorted by the ratio of *active* developers per million population for each country.

Act: number of active developers Dev: total number of developers A/M: number of active devels per million pop. D/M: number of devels per million pop. 2009: rank in 2009 2010: rank in 2010 2011: rank in 2011 (June) 2012: rank in 2012 (June) 2013: rank in 2012 (July) 2014: rank now Code Name Population Act Dev Dev Act/Million Dev/Million 2009 2010 June 2011 June 2012 July 2013 July 2014
fi Finland 5259250 19 31 3,61 5,89 1 1 1 1 1 1
ie Ireland 4670976 13 17 2,78 3,64 13 9 6 2 2 2
nz New Zealand 4331600 11 15 2,54 3,46 4 3 5 7 7 3 * mq Martinique 396404 1 1 2,52 2,52

3 4 4 4
se Sweden 9088728 22 37 2,42 4,07 3 6 7 5 5 5
ch Switzerland 7870134 19 29 2,41 3,68 2 2 2 3 3 6 * no Norway 4973029 11 14 2,21 2,82 5 4 4 6 6 7 * at Austria 8217280 18 29 2,19 3,53 6 8 10 10 10 8 * de Germany 81471834 164 235 2,01 2,88 7 7 9 9 8 9 * lu Luxemburg 503302 1 1 1,99 1,99 8 5 8 8 9 10 * fr France 65350000 101 131 1,55 2 12 12 11 11 11 11
au Australia 22607571 32 60 1,42 2,65 9 10 12 12 12 12
be Belgium 11071483 14 17 1,26 1,54 10 11 13 13 13 13
uk United-Kingdom 62698362 77 118 1,23 1,88 14 14 14 14 14 14
nl Netherlands 16728091 18 40 1,08 2,39 11 13 15 15 15 15
ca Canada 33476688 34 63 1,02 1,88 15 15 17 16 16 16
dk Denmark 5529888 5 10 0,9 1,81 17 17 16 17 17 17
es Spain 46754784 34 56 0,73 1,2 16 16 19 18 18 18
it Italy 59464644 36 52 0,61 0,87 23 22 22 19 19 19
hu Hungary 10076062 6 12 0,6 1,19 18 25 26 20 24 20 * cz Czech Rep 10190213 6 6 0,59 0,59 21 20 21 21 20 21 * us USA 313232044 175 382 0,56 1,22 19 21 25 24 22 22
il Israel 7740900 4 6 0,52 0,78 24 24 24 25 23 23
hr Croatia 4290612 2 2 0,47 0,47 20 18 18 26 25 24 * lv Latvia 2204708 1 1 0,45 0,45 26 26 27 27 26 25 * bg Bulgaria 7364570 3 3 0,41 0,41 25 23 23 23 27 26 * sg Singapore 5183700 2 2 0,39 0,39


33 33 27 * uy Uruguay 3477778 1 2 0,29 0,58 22 27 28 28 28 28
pl Poland 38441588 11 15 0,29 0,39 29 29 30 30 30 29 * jp Japan 127078679 36 52 0,28 0,41 30 28 29 29 29 30 * lt Lithuania 3535547 1 1 0,28 0,28 28 19 20 22 21 31 * gr Greece 10787690 3 4 0,28 0,37 33 38 34 35 35 32 * cr Costa Rica 4301712 1 1 0,23 0,23 31 30 31 31 31 33 * by Belarus 9577552 2 2 0,21 0,21 35 36 39 39 32 34 * ar Argentina 40677348 8 10 0,2 0,25 34 33 35 32 37 35 * pt Portugal 10561614 2 4 0,19 0,38 27 32 32 34 34 36 * sk Slovakia 5477038 1 1 0,18 0,18 32 31 33 36 36 37 * rs Serbia 7186862 1 1 0,14 0,14



38 38
tw Taiwan 23040040 3 3 0,13 0,13 37 34 37 37 39 39
br Brazil 192376496 18 21 0,09 0,11 36 35 38 38 40 40
cu Cuba 11241161 1 1 0,09 0,09
38 41 41 41 41
co Colombia 45566856 4 5 0,09 0,11 41 44 46 47 46 42 * kr South Korea 48754657 4 6 0,08 0,12 39 39 42 42 42 43 * gt Guatemala 13824463 1 1 0,07 0,07



43 44 * ec Ecuador 15007343 1 1 0,07 0,07
40 43 43 45 45
cl Chile 16746491 1 2 0,06 0,12 42 41 44 44 47 46 * za South Africa 50590000 3 10 0,06 0,2 38 48 48 48 48 47 * ru Russia 143030106 8 9 0,06 0,06 43 42 47 45 49 48 * mg Madagascar 21281844 1 1 0,05 0,05 44 37 40 40 50 49 * ro Romania 21904551 1 2 0,05 0,09 45 43 45 46 51 50 * ve Venezuela 28047938 1 1 0,04 0,04 40 45 50 49 44 51 * my Malaysia 28250000 1 1 0,04 0,04

49 50 52 52
pe Peru 29907003 1 1 0,03 0,03 46 46 51 51 53 53
tr Turkey 74724269 2 2 0,03 0,03 47 47 52 52 54 54
ua Ukraine 45134707 1 1 0,02 0,02 48 53 58 59 55 55
th Thailand 66720153 1 2 0,01 0,03 50 50 54 54 56 56
eg Egypt 80081093 1 3 0,01 0,04 51 51 55 55 57 57
mx Mexico 112336538 1 1 0,01 0,01 49 49 53 53 58 58
cn China 1344413526 10 14 0,01 0,01 53 53 57 56 59 59
in India 1210193422 8 9 0,01 0,01 52 52 56 57 60 60
sv El Salvador 7066403 0 1 0 0,14

36 58 61 61































969 1561 62,08%







A few interesting facts:
  • New Zealand bumps from rank 7 to rank 3, thanks to one new active developer
  • Switzerland loses one developer and goes donw to rank 6
  • Norway also slightly goes down by losing one developer
  • With two more developers, Austria climbs up to rank 8 and overtakes Germany...;-)
  • Hungary climbs a little bit by gaining one developer
  • Singapore doubles its number of developers from 1 to 2 and bumps from 33 to 27
  • One rank up too for Poland that gained one developer
  • Down to rank 31 for Lithuania by losing one developer
  • Up to rank 32 for Greece with 4 developers instead of 3
  • Argentina goes up by havign two more developers (it lost 2 last year)
  • Up from 46 to 42 for Colombia by winning one more developer
  • One more developer and Russia climps from 49 to 48
  • One less for Venezuela that has only one developer left...:-(
  • No new country this year. Less movement towards "the universal OS"?
  • We have 12 more active Debian developers and 26 more developers overall. Less progression than last year
  • The ratio of active developers increases is nearly stable though slightly decreasing
Categories: FLOSS Project Planets

Russell Coker: Android Screen Saving

Tue, 2014-07-29 08:28

Just over a year ago I bought a Samsung Galaxy Note 2 [1]. About 3 months ago I noticed that some of the Ingress menus had burned in to the screen. Back in ancient computer times there were “screen saver” programs that blanked the screen to avoid this, then the “screen saver” programs transitioned to displaying a variety of fancy graphics which didn’t really fulfill the purpose of saving the screen. With LCD screens I have the impression that screen burn wasn’t an issue, but now with modern phones we have LED displays which have the problem again.

Unfortunately there doesn’t seem to be a free screen-saver program for Android in the Google Play store. While I can turn the screen off entirely there are some apps such as Ingress that I’d like to keep running while the screen is off or greatly dimmed. Now I sometimes pull the notification menu down when I’m going to leave Ingress idle for a while, this doesn’t stop the screen burning but it does cause different parts to burn which alleviates the problem.

It would be nice if apps were designed to alleviate this. A long running app should have an option to change the color of it’s menus, it would be ideal to randomly change the color on startup. If the common menus such as the “COMM” menu would appear in either red, green, or blue (the 3 primary colors of light) in a ratio according to the tendency to burn (blue burns fastest so should display least) then it probably wouldn’t cause noticable screen burn after 9 months. The next thing that they could do is to slightly vary the position of the menus, instead of having a thin line that’s strongly burned into the screen there would be a fat line lightly burned in which should be easier to ignore.

It’s good when apps have an option of a “dark” theme, that involves less light coming from the screen that should reduce battery use and screen burn. A dark theme should be at least default and probably mandatory for long running apps, a dark theme is fortunately the only option for Ingress.

I am a little disappointed with my phone. I’m not the most intensive Ingress player so I think that the screen should have lasted for more than 9 months before being obviously burned.

Related posts:

  1. Maintaining Screen Output In my post about getting started with KVM I noted...
  2. Android Device Service Life In recent years Android devices have been the most expensive...
  3. Cheap Android Tablet from Aldi I’ve just bought a 7″ Onix tablet from Aldi....
Categories: FLOSS Project Planets

Russell Coker: Happiness and Lecture Questions

Tue, 2014-07-29 06:57

I just attended a lecture about happiness comparing Australia and India at the Australia India Institute [1]. The lecture was interesting but the “questions” were so bad that it makes a good case for entirely banning questions from public lectures. Based on this and other lectures I’ve attended I’ve written a document about how to recognise worthless questions and cut them off early [2].

As you might expect from a lecture on happiness there were plenty of stupid comments from the audience about depression, as if happiness is merely the absence of depression.

Then they got onto stupidity about suicide. One “question” claimed that Australia has a high suicide rate, Wikipedia however places Australia 49th out of 110 countries, that means Australia is slightly above the median for suicide rates per country. Given some of the dubious statistics in the list (for example the countries claiming to have no suicides and the low numbers reported by some countries with extreme religious policies) I don’t think we can be sure that Australia would be above the median if we had better statistics. Another “question” claimed that Sweden had the highest suicide rate in Europe, while Greenland, Belgium, Finland, Austria, France, Norway, Denmark, Iceland, and most of Eastern Europe are higher on the list.

But the bigger problem in regard to discussing suicide is that the suicide rate isn’t about happiness. When someone kills themself because they have a terminal illness that doesn’t mean that they were unhappy for the majority of their life and doesn’t mean that they were any unhappier than the terminally ill people who don’t do that. Some countries have a culture that is more positive towards suicide which would increase the incidence, Japan for example. While people who kill themselves in Japan are probably quite unhappy at the time I don’t think that there is any reason to believe that they are more unhappy than people in other countries who only keep living because suicide is considered to be wrong.

It seems to me that the best strategy when giving or MCing a lecture about a potentially contentious topic is to plan ahead for what not to discuss. For a lecture about happiness it would make sense to rule out all discussion of suicide, anti-depressants, and related issues as they aren’t relevant to the discussion and can’t be handled in an appropriate manner in question time.

Related posts:

  1. Length of Conference Questions After LCA last year I wrote about “speaking stacks” and...
  2. Questions During Lectures An issue that causes some discussion and debate is the...
  3. Ziggy’s Lecture about Nuclear Power The Event I just attended a lecture by Dr Ziggy...
Categories: FLOSS Project Planets

Johannes Schauer: bootstrap.debian.net temporarily not updated

Tue, 2014-07-29 04:46

I'll be moving places twice within the next month and as I'm hosting the machine that generates the data, I'll temporarily suspend the bootstrap.debian.net service until maybe around September. Until then, bootstrap.debian.net will not be updated and retain the status as of 2014-07-28. Sorry if that causes any inconvenience. You can write to me if you need help with manually generating the data bootstrap.debian.net provided.

Categories: FLOSS Project Planets

Ricardo Mones: Switching PGP keys

Tue, 2014-07-29 04:42
Finally I find the mood to do this, a process which started 5 years ago in DebConf 9 at Cáceres by following Ana's post, of course with my preferred options and my name, not like some other ;-).

Said that, dear reader, if you have signed my old key:

1024D/C9B55DAC 2005-01-19 [expires: 2015-10-01] Key fingerprint = CFB7 C779 6BAE E81C 3E05 7172 2C04 5542 C9B5 5DAC
And want to sign my "new" and stronger key:

4096R/DE5BCCA6 2009-07-29 Key fingerprint = 43BC 364B 16DF 0C20 5EBD 7592 1F0F 0A88 DE5B CCA6
You're welcome to do so :-)

The new key is signed with the old, and the old key is still valid, and will probably be until expiration date next year. Don't forget to gpg --recv-keys DE5BCCA6 to get the new key and gpg --refresh-keys C9B55DAC to refresh the old (otherwise it may look expired).

Debian's Keyring Team has already processed my request to add the new key, so all should keep working smoothly. Kudos to them!
Categories: FLOSS Project Planets

Christian Perrier: [life] Running update July 26th 2014

Tue, 2014-07-29 00:46
Dog, long time since I blogged about my running activities. Apparently, I didn't since.....I posted a summary for 2013.

So, well, that will be a long update as many things happened during the first half of 2014 when it comes at running, for me.

January: I was recovering from a fatigue fracture injury inherited from last races in 2013. As a consequence, I resumed running only on Jan 7th. Therefore I cancelled my participation to the "Semi Raid 28", an night orienteering raid of about 50-60km in southern neighbourhood of Paris. Instead, I actually offerred my help to organizers in collecting orienteering signs after the race (the longest one : 120km). So, I ended up spending over 24 hours running in woods and hunting down hidden signs with the same information than runners. My only advantage was that I was able to use my car to go from one point to another. Still, I ended up running over 70km in many small parts, often alone in the dark woods with my headlamp, on very muddy areas...and collecting nearly 80 huge signs.

February: Everything was going well and I for instance ran a great half-marathon in Bullion (south of Paris) in 1h3821" (great for a quite hilly race)....until I twisted my left ankle while running back from work. A quite severe twist, though no bone damage, thankfully. I had to stop running, again, for 3 years. Biking to/from work was the replacement activity....

March: I resumed running on March 10th, one week before a quite difficult trail race in my neighbourhood (30km "only" but up to 800 meters positive climb). That race was a preparation (and a test after the injury) for my 3rd participation to "Paris Ecotrail", a 80km trail race in woods of the South-West area of Paris, ending in the Eiffel Tower area. Indeed, both went very well, though I was very careful with my ankle. I finally broke my record at Ecotrail, finishing the race in 9h08 (to be compared to 9h36 last year and 11h15 the year before).

April: Paris marathon was scheduled one week after Ecotrail. Everybody will tell you that running a marathon one week after a 80km race is kinda crazy.....which is why I made it..:-). That was my 3rd Paris marathon and my 12th marathon overall. However, this year, no record in sight. The challenge was running the marathon....dressed as SpongeBob (you know me, right?). I actually had great fun doing that and was happy to get zillions of cheering all over the race, from the crowd. I finally completed the race in 4h30, which is, after all, not that far from the time of my very first marathon (4h12). The only drawback was that the succession of quite very long distance runs made my left knee suffer as it never happened before. As a consequence, I (again) had to stop running for nearly one month before we found that I was quite sensitive to pronation, which the succession of long and slow races made worse.

May: so finally afterthese (very) long weeks, I could gradually resume running, which finally culminated in mid-May with the 50km race "trail des Cerfs", in the Rambouillet Forest, closed to our place. This quite long but not too difficult trail race ("only" 800 meters positive climb overall) was completed in 5h16, which was completely unexpected, given the low training during the previous weeks.

June: no race during that month. The entire month was focused on preparing the Montagn'hard race of July 5th: so several training sessions with a lot of climbing either by running or by fast walking (nordic style) as well as downhill run training (always important for moutain trail).

July: the second "big peak" of my 2014 season was scheduled for July 5th: "La Montagn'hard", a moutain trail race close to Les Contamines in the neighbourhood of Chamonix, the french moutaineering Mekkah. "Only" 60 kilometers....but close to 5000 meters positive climb. Montagn'hard is among the thoughest moutain trail races in France and therefore a "must do" for trail runners. This race week-end includes also a 105km ultra-race, which is often said to be as hard, even maybe harder, than the very famous "Ultra Trail du Mont-Blanc" trail in Chamonix. Still, for my second only season in moutain trail running, I decided to be "wise" and stick with the "medium" version (after all, my experience, as of now with moutain trails were only two quite "short" ones). Needless to say, it has indeed been a GREAT race. The environment is wonderful ("Miage" side of the Mont-Blanc range), the race goes through great place (Col de Tricot, noticeably) and I made a great result by finishing80th out of 325+ runners, in 12h18, while my target time was around 13 hours.

This is where I am now. Nearly one month after Montagn'hard, I'm deeply training for my next Big Goal: The "Sur la Trace des Ducs de Savoie" or "TDS", one of the 4 races of the Ultra Trail du Mont-Blanc week, in end August (during DebConf): 120km, nearly 7500m positive climp, between Courmayeur and Chamonix, through several passes, up to 2600m height. Yet another challenge: my first "over 24h" race, with a full night out in the moutains.

You'll certainly hear again from me about that...:-)

Categories: FLOSS Project Planets

Chris Lamb: start-stop-daemon: --exec vs --startas

Mon, 2014-07-28 09:15

start-stop-daemon is the classic tool on Debian and derived distributions to manage system background processes. A typical invokation from an initscript is as follows:

start-stop-daemon \ --quiet \ --oknodo \ --start \ --pidfile /var/run/daemon.pid \ --exec /usr/sbin/daemon \ -- -c /etc/daemon.cfg -p /var/run/daemon.pid

The basic operation is that it will first check whether /usr/sbin/daemon is not running and, if not, execute /usr/sbin/daemon -c /etc/daemon.cfg -p /var/run/daemon.pid. This process then has the responsibility to daemonise itself and write the resulting process ID to /var/run/daemon.pid.

start-stop-daemon then waits until /var/run/daemon.pid has been created as the test of whether the service has actually started, raising an error if that doesn't happen.

(In practice, the locations of all these files are parameterised to prevent DRY violations.)

Idempotency

By idempotence we are mostly concerned with repeated calls to /etc/init.d/daemon start not starting multiple versions of our daemon.

This might not seem to be particularly big issue at first but the increased adoption of stateless configuration management tools such as Ansible (which should be completely free to call start to ensure a started state) mean that one should be particularly careful of this apparent corner case.

In its usual operation, start-stop-daemon ensures only one instance of the daemon is running with the --exec parameter: if the specified pidfile exists and the PID it refers to is an "instance" of that executable, then it is assumed that the daemon is already running and another copy is not started. This is handled in the pid_is_exec method (source) - the /proc/$PID/exe symlink is resolved and checked against the value of --exec.

Interpreted scripts

However, one case where this doesn't work is interpreted scripts. Lets look at what happens if /usr/sbin/daemon is such a script, eg. a file that starts:

#!/usr/bin/env python # [..]

The problem this introduces is that /proc/$PID/exe now points to the interpreter instead, often with an essentially non-deterministic version suffix:

$ ls -l /proc/14494/exe lrwxrwxrwx 1 www-data www-data 0 Jul 25 15:18 /proc/14494/exe -> /usr/bin/python2.7

When this process is examined using the --exec mechanism outlined above it will be rejected as an instance of /usr/sbin/daemon and therefore another instance of that daemon will be incorrectly started.

--startas

The solution is to use the --startas parameter instead. This omits the /proc/$PID/exe check and merely tests whether a PID with that number is running:

start-stop-daemon \ --quiet \ --oknodo \ --start \ --pidfile /var/run/daemon.pid \ --startas /usr/sbin/daemon \ -- -c /etc/daemon.cfg -p /var/run/daemon.pid

Whilst it is therefore less reliable (in that the PID found in the pidfile could actually be an entirely different process altogether) it's probably an acceptable trade-off against the case of running multiple instances of that daemon.

This danger can be ameliorated by using some of start-stop-daemon's other matching tests, such as --user or even --name.

Categories: FLOSS Project Planets

Daniel Pocock: Secure that Dictaphone

Mon, 2014-07-28 01:35

2014 has been a big year for dictaphones so far.

First, it was France and the secret recordings made by Patrick Buisson during the reign of President Sarkozy.

Then, a US court ordered the release of the confidential Boston College tapes, part of an oral history project. Originally, each participant had agreed their recording would only be released after their death. Sinn Fein leader Gerry Adams was arrested and questioned over a period of 100 hours and released without charge.

Now Australia is taking its turn. In #dictagate down under, a senior political correspondent from a respected newspaper recorded (most likely with consent) some off-the-record comments of former conservative leader Ted Baillieu. Unfortunately, this journalist misplaced the dictaphone at the state conference of Baillieu's arch-rivals, the ALP. A scandal quickly errupted.

Secure recording technology

There is no question that electronic voice recordings can be helpful for people, including journalists, researchers, call centers and many other purposes. However, the ease with which they can now be distributed is only dawning on people.

Twenty years ago, you would need to get the assistance of a radio or TV producer to disseminate such recordings so widely. Today there is email and social media. The Baillieu tapes were emailed directly to 400 people in a matter of minutes.

Just as technology brings new problems, it also brings solutions. Encryption is one of them.

Is encryption worthwhile?

Coverage of the Snowden revelations has revealed that many popular security technologies are not one hundred percent safe. In each of these dictaphone cases, however, NSA-level expertise was not a factor. Even the most simplistic encryption would have caused endless frustration to the offenders who distributed the Baillieu tape.

How can anybody be sure encryption is reliable?

Part of the problem is education. Everybody using the technology needs to be aware of the basic concepts, for example, public key cryptography.

Another big question mark is back doors. There is ongoing criticism of Apple iPhone/iPod devices and the many ways that their encryption can be easily disabled by Apple engineers and presumably many former staff, security personnel and others. The message is clear: proprietary, closed-source solutions should be avoided. Free and open source technologies are the alternative. If a company does not give you the source code, how can anybody independently audit their code for security? With encryption software, what use is it if nobody has verified it?

What are the options?

However, given that the majority of people don't have a PhD in computer science or mathematics, are there convenient ways to get started with encryption?

Reading is a good start. The Code Book by Simon Singh (author of other popular science books like Fermat's Last Theorem) is very accessible, not classified and assumes no formal training in mathematics. Even for people who do know these topics inside out, it is a good book to share with friends and family.

The Guardian Project (no connection with Guardian Media of Edward Snowden fame) aims to provide a secure and easy to use selection of apps for pocket devices. This project has practical applications in business, journalism and politics alike.

How should a secure dictaphone app work?

Dictaphone users typically need to take their dictaphones in the field, so there is a risk of losing it or having it stolen. A strong security solution in this situation may involve creating an RSA key pair on a home/office computer, keeping the private key on the home computer and putting the public key on the dictaphone device. Configured this way, the dictaphone will not be able to play back any of the recordings itself - the user will always have to copy them to the computer for decryption.

Categories: FLOSS Project Planets

Russ Allbery: AFS::PAG 1.02

Sun, 2014-07-27 20:22

This is primarily a testing exercise. I moved my software release process and web page generation to a different host, and wanted to run through a release of a package to make sure that I got all the details right.

It's still a bit clunky, and I need to tweak the process, but it's close enough.

That said, there are a few minor changes in this module (which provides the minimum C glue required to do AFS operations from Perl — only the pieces that can't be duplicated by calling command-line programs). I'm improving the standardization of my Perl distributions, so I've moved NEWS to Changes and switched to the Lancaster Consensus environment variables for controlling testing. I also added some more pieces to the package metadata.

You can get the latest version from the AFS::PAG distribution page.

Categories: FLOSS Project Planets

Christian Perrier: Developers per country (July 2014)

Sun, 2014-07-27 03:37
This is time again for my annual report about the number of developers per country.

This is now the sixth edition of this report. Former editions:

So, here we are with the July 2014 version, sorted by the ratio of *active* developers per million population for each country.

Act: number of active developers Dev: total number of developers A/M: number of active devels per million pop. D/M: number of devels per million pop. 2009: rank in 2009 2010: rank in 2010 2011: rank in 2011 (June) 2012: rank in 2012 (June) 2013: rank in 2012 (July) 2014: rank now Code Name Population Act Dev Dev Act/Million Dev/Million 2009 2010 June 2011 June 2012 July 2013 July 2014
fi Finland 5259250 19 31 3,61 5,89 1 1 1 1 1 1
ie Ireland 4670976 13 17 2,78 3,64 13 9 6 2 2 2
nz New Zealand 4331600 11 15 2,54 3,46 4 3 5 7 7 3 * mq Martinique 396404 1 1 2,52 2,52

3 4 4 4
se Sweden 9088728 22 37 2,42 4,07 3 6 7 5 5 5
ch Switzerland 7870134 19 29 2,41 3,68 2 2 2 3 3 6 * no Norway 4973029 11 14 2,21 2,82 5 4 4 6 6 7 * at Austria 8217280 18 29 2,19 3,53 6 8 10 10 10 8 * de Germany 81471834 164 235 2,01 2,88 7 7 9 9 8 9 * lu Luxemburg 503302 1 1 1,99 1,99 8 5 8 8 9 10 * fr France 65350000 101 131 1,55 2 12 12 11 11 11 11
au Australia 22607571 32 60 1,42 2,65 9 10 12 12 12 12
be Belgium 11071483 14 17 1,26 1,54 10 11 13 13 13 13
uk United-Kingdom 62698362 77 118 1,23 1,88 14 14 14 14 14 14
nl Netherlands 16728091 18 40 1,08 2,39 11 13 15 15 15 15
ca Canada 33476688 34 63 1,02 1,88 15 15 17 16 16 16
dk Denmark 5529888 5 10 0,9 1,81 17 17 16 17 17 17
es Spain 46754784 34 56 0,73 1,2 16 16 19 18 18 18
it Italy 59464644 36 52 0,61 0,87 23 22 22 19 19 19
hu Hungary 10076062 6 12 0,6 1,19 18 25 26 20 24 20 * cz Czech Rep 10190213 6 6 0,59 0,59 21 20 21 21 20 21 * us USA 313232044 175 382 0,56 1,22 19 21 25 24 22 22
il Israel 7740900 4 6 0,52 0,78 24 24 24 25 23 23
hr Croatia 4290612 2 2 0,47 0,47 20 18 18 26 25 24 * lv Latvia 2204708 1 1 0,45 0,45 26 26 27 27 26 25 * bg Bulgaria 7364570 3 3 0,41 0,41 25 23 23 23 27 26 * sg Singapore 5183700 2 2 0,39 0,39


33 33 27 * uy Uruguay 3477778 1 2 0,29 0,58 22 27 28 28 28 28
pl Poland 38441588 11 15 0,29 0,39 29 29 30 30 30 29 * jp Japan 127078679 36 52 0,28 0,41 30 28 29 29 29 30 * lt Lithuania 3535547 1 1 0,28 0,28 28 19 20 22 21 31 * gr Greece 10787690 3 4 0,28 0,37 33 38 34 35 35 32 * cr Costa Rica 4301712 1 1 0,23 0,23 31 30 31 31 31 33 * by Belarus 9577552 2 2 0,21 0,21 35 36 39 39 32 34 * ar Argentina 40677348 8 10 0,2 0,25 34 33 35 32 37 35 * pt Portugal 10561614 2 4 0,19 0,38 27 32 32 34 34 36 * sk Slovakia 5477038 1 1 0,18 0,18 32 31 33 36 36 37 * rs Serbia 7186862 1 1 0,14 0,14



38 38
tw Taiwan 23040040 3 3 0,13 0,13 37 34 37 37 39 39
br Brazil 192376496 18 21 0,09 0,11 36 35 38 38 40 40
cu Cuba 11241161 1 1 0,09 0,09
38 41 41 41 41
co Colombia 45566856 4 5 0,09 0,11 41 44 46 47 46 42 * kr South Korea 48754657 4 6 0,08 0,12 39 39 42 42 42 43 * gt Guatemala 13824463 1 1 0,07 0,07



43 44 * ec Ecuador 15007343 1 1 0,07 0,07
40 43 43 45 45
cl Chile 16746491 1 2 0,06 0,12 42 41 44 44 47 46 * za South Africa 50590000 3 10 0,06 0,2 38 48 48 48 48 47 * ru Russia 143030106 8 9 0,06 0,06 43 42 47 45 49 48 * mg Madagascar 21281844 1 1 0,05 0,05 44 37 40 40 50 49 * ro Romania 21904551 1 2 0,05 0,09 45 43 45 46 51 50 * ve Venezuela 28047938 1 1 0,04 0,04 40 45 50 49 44 51 * my Malaysia 28250000 1 1 0,04 0,04

49 50 52 52
pe Peru 29907003 1 1 0,03 0,03 46 46 51 51 53 53
tr Turkey 74724269 2 2 0,03 0,03 47 47 52 52 54 54
ua Ukraine 45134707 1 1 0,02 0,02 48 53 58 59 55 55
th Thailand 66720153 1 2 0,01 0,03 50 50 54 54 56 56
eg Egypt 80081093 1 3 0,01 0,04 51 51 55 55 57 57
mx Mexico 112336538 1 1 0,01 0,01 49 49 53 53 58 58
cn China 1344413526 10 14 0,01 0,01 53 53 57 56 59 59
in India 1210193422 8 9 0,01 0,01 52 52 56 57 60 60
sv El Salvador 7066403 0 1 0 0,14

36 58 61 61































969 1561 62,08%







A few interesting facts:
  • New Zealand bumps from rank 7 to rank 3, thanks to one new active developer
  • Switzerland loses one developer and goes donw to rank 6
  • Norway also slightly goes down by losing one developer
  • With two more developers, Austria climbs up to rank 8 and overtakes Germany...;-)
  • Hungary climbs a little bit by gaining one developer
  • Singapore doubles its number of developers from 1 to 2 and bumps from 33 to 27
  • One rank up too for Poland that gained one developer
  • Down to rank 31 for Lithuania by losing one developer
  • Up to rank 32 for Greece with 4 developers instead of 3
  • Argentina goes up by havign two more developers (it lost 2 last year)
  • Up from 46 to 42 for Colombia by winning one more developer
  • One more developer and Russia climps from 49 to 48
  • One less for Venezuela that has only one developer left...:-(
  • No new country this year. Less movement towards "the universal OS"?
  • We have 12 more active Debian developers and 26 more developers overall. Less progression than last year
  • The ratio of active developers increases is nearly stable though slightly decreasing
Categories: FLOSS Project Planets

Holger Levsen: 20140726-the-future-is-now

Sat, 2014-07-26 08:08
Do you remember the future?

Unless you are over 60, you weren't promised flying cars. You were promised an oppressive cyberpunk dystopia. Here you go.

(Source: found in the soup)

Luckily the future today is still unwritten. Shape it well.

Categories: FLOSS Project Planets

Richard Hartmann: Release Critical Bug report for Week 30

Fri, 2014-07-25 17:58

I have been asked to publish bug stats from time to time. Not exactly sure about the schedule yet, but I will try and stick to Fridays, as in the past; this is for the obvious reason that it makes historical data easier to compare. "Last Friday of each month" may or may not be too much. Time will tell.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1511
    • Affecting Jessie: 431 That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 383 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 44 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 20 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
        • 319 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
      • Affecting Jessie only: 48 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 0 bugs are in packages that are unblocked by the release team.
        • 48 bugs are in packages that are not unblocked.

Graphical overview of bug stats thanks to azhag:

Categories: FLOSS Project Planets

Juliana Louback: Extending an xTuple Business Object

Fri, 2014-07-25 11:06

xTuple is in my opinion incredibly well designed; the code is clean and the architecture ahderent to a standardized structure. All this makes working with xTuple software quite a breeze.

I wanted to integrate JSCommunicator into the web-based xTuple version. JSCommunicator is a SIP communication tool, so my first step was to create an extension for the SIP account data. Luckily for me, the xTuple development team published an awesome tutorial for writing an xTuple extension.

xTuple cleverly uses model based business objects for the various features available. This makes customizing xTuple very straightforward. I used the tutorial mentioned above for writing my extension, but soon noticed my goals were a little different. A SIP account has 3 data fields, these being the SIP URI, the account password and an optional display name. xTuple currently has a business object in the core code for a User Account and it would make a lot more sense to simply add my 3 fields to this existing business object rather than create another business object. The tutorial very clearly shows how to extend a business object with another business object, but not how to extend a business object with only new fields (not a whole new object).

Now maybe I’m just a whole lot slower than most people, but I had a ridiculously had time figuring this out. Mind you, this is because I’m slow, because the xTuple documentation and code is understandable and as self-explanatory as it gets. I think it just takes a bit to get used to. Either way, I thought this just might be useful to others so here is how I went about it.

Setup

First you’ll have to set up your xTuple development environment and fork the xtuple and xtuple-extesions repositories as shown in this handy tutorial. A footnote I’d like to add is please verify that your version of Vagrant (and anything else you install) is the one listed in the tutorial. I think I spent like two entire days or more on a wild goose (bug) chase trying to set up my environment when the cause of all the errors was that I somehow installed an older version of Vagrant - 1.5.4 instead of 1.6.3. Please don’t make the same mistake I did. Actually if for some reason you get the following error when you try using node:

<<ERROR 2014-07-10T23:52:46.948Z>> Unrecoverable exception. Cannot call method 'extend' of undefined at /home/vagrant/dev/xtuple/lib/backbone-x/source/model.js:37:39 at Object.<anonymous> (/home/vagrant/dev/xtuple/lib/backbone-x/source/model.js:1364:3) ...

chances are, you have the wrong version. That’s what happened to me. The Vagrant Virtual Development Environment automatically installs and configures everything you need, it’s ready to go. So if you find yourself installing and updating and apt-gets and etc, you probably did something wrong.

Coding

So by now we should have the Vagrant Virtual Development Environment set up and the web app up and running and accessible at localhost:8443. So far so good.

Disclaimer: You will note that much of this is similar - or rather, nearly identical - to xTuple’s tutorial but there are some small but important differences and a few observations I think might be useful. Other Disclaimer: I’m describing how I did it, which may or may not be ‘up to snuff’. Works for me though.

Schema

First let’s make a schema for the table we will create with the new custom fields. Be sure to create the correct directory stucture, aka /path/to/xtuple-extensions/source/<YOUR EXTENSION NAME>/database/source or in my case /path/to/xtuple-extensions/source/sip_account/database/source, and create the file create_sa_schema.sql, ‘sa’ is the name of my schema. This file will contain the following lines:

do $$ /* Only create the schema if it hasn't been created already */ var res, sql = "select schema_name from information_schema.schemata where schema_name = 'sa'", res = plv8.execute(sql); if (!res.length) { sql = "create schema sa; grant all on schema sa to group xtrole;" plv8.execute(sql); } $$ language plv8;

Of course, feel free to replace ‘sa’ with your schema name of choice. All the code described here can be found in my xtuple-extensions fork, on the sip_ext branch.

Table

We’ll create a table containing your custom fields and a link to an existing table - the table for the existing business object you want to extend. If you’re wondering why make a whole new table for a few extra fields, here’s a good explanation, the case in question is adding fields to the Contact business object.

You need to first figure out what table you want to link to. This might not be uber easy. I think the best way to go about it is to look at the ORMs. The xTuple ORMs are a JSON mapping between the SQL tables and the object-oriented world above the database, they’re .json files found at path/to/xtuple/node_modules/xtuple/enyo-client/database/orm/models for the core business objects and at path/to/xtuplenyo-client/extensions/source/<EXTENSION NAME>/database/orm/models for exension business objects. I’ll give two examples. If you look at contact.json you will see that the Contact business object refers to the table “cntct”. Look for the “type”: “Contact” on the line above, so we know it’s the “Contact” business object. In my case, I wanted to extend the UserAccount and UserAccountRelation business objects, so check out user_account.json. The table listed for UserAccount is xt.usrinfo and the table listed for UserAccountRelation is xt.usrlite. A closer look at the sql files for these tables (usrinfo.sql and usrlite.sql) revealed that usrinfo is in fact a view and usrlite is ‘A light weight table of user information used to avoid punishingly heavy queries on the public usr view’. I chose to refer to xt.usrlite - that or I received error messages when trying the other table names.

Now I’ll make the file /path/to/xtuple-extensions/source/sip_account/database/source/usrlitesip.sql, to create a table with my custom fields plus the link to the urslite table. Don’t quote me on this, but I’m under the impression that this is the norm for naming the sql file joining tables: the name of the table you are referring to (‘usrlite’ in this case) and your extension’s name. Content of usrlitesip.sql:

select xt.create_table('usrlitesip', 'sa'); select xt.add_column('usrlitesip','usrlitesip_id', 'serial', 'primary key', 'sa'); select xt.add_column('usrlitesip','usrlitesip_usr_username', 'text', 'references xt.usrlite (usr_username)', 'sa'); select xt.add_column('usrlitesip','usrlitesip_uri', 'text', '', 'sa'); select xt.add_column('usrlitesip','usrlitesip_name', 'text', '', 'sa'); select xt.add_column('usrlitesip','usrlitesip_password', 'text', '', 'sa'); comment on table sa.usrlitesip is 'Joins User with SIP account';

Breaking it down, line 1 creates the table named ‘usrlitesip’ (no duh), line 2 is for the primary key (self-explanatory). You can then add any columns you like, just be sure to add one that references the table you want to link to. I checked usrlite.sql and saw the primary key is usr_username, be sure to use the primary key of the table you are referencing.

You can check what you made by executing the .sql files like so:

$ cd /path/to/xtuple-extensions/source/sip_account/database/source $ psql -U admin -d dev -f create_sa_schema.sql $ psql -U admin -d dev -f usrlitesip.sql

After which you will see the table with the columns you created if you enter:

$ psql -U admin -d dev -c "select * from sa.usrlitesip;"

Now create the file /path/to/xtuple-extensions/source/sip_account/database/source/manifest.js to put the files together and in the right order. It should contain:

{ "name": "sip_account", "version": "1.4.1", "comment": "Sip Account extension", "loadOrder": 999, "dependencies": ["crm"], "databaseScripts": [ "create_sa_schema.sql", "usrlitesip.sql", "register.sql" ] }

I think the “name” has to be the same you named your extension directory as in /path/to/xtuple-extensions/source/<YOUR EXTENSION NAME>. I think the “comment” can be anything you like and you want your “loadOrder” to be high so it’s the last thing installed (as it’s an add on.) So far we are doing exactly what’s instructed in the xTuple tutorial. It’s repetitive, but I think you can never have too many examples to compare to. In “databaseScripts” you will list the two .sql files you just created for the schema and the table, plus another file to be made in the same directory named register.sql.

I’m not sure why you have to make the register.sql or even if you indeed have to. If you leave the file empty, there will be a build error, so put a ‘;’ in the register.sql or remove the line “register.sql” from manifest.js as I think for now we are good without it.

Now let’s update the database with our new extension:

$ cd /path/to/xtuple $ ./scripts/build_app.js -d dev -e ../xtuple-extensions/source/sip_account $ psql -U admin -d dev -c "select * from xt.ext;"

That last command should display a table with a list of extensions; the ones already in xtuple like ‘crm’ and ‘billing’ and some others plus your new extension, in this case ‘sip_account’. When you run build_app.js you’ll probably see a message along the lines of “<Extension name> has no client code, not building client code” and that’s fine because yeah, we haven’t worked on the client code yet.

ORM

Here’s where things start getting different. So ORMs link your object to an SQL table. But we DON’T want to make a new business object, we want to extend an existing business object, so the ORM we will make will be a little different than the xTuple tutorial. Steve Hackbarth kindly explained this new business object/existing business object ORM concept here.

First we’ll create the directory /path/to/xtuple-extensions/source/sip_account/database/orm/ext, according to xTuple convention. ORMs for new business objects would be put in /path/to/xtuple-extensions/source/sip_account/database/orm/models. Now we’ll create the .json file /path/to/xtuple-extensions/source/sip_account/database/orm/ext/user_account.jscon for our ORM. Once again, don’t quote me on this, but I think the name of the file should be the name of the business object you are extending, as is done in the turorial example extending the Contact object. In our case, UserAccount is defined in user_account.json and that’s what I named my extension ORM too. Here’s what you should place in it:

1 [ 2 { 3 "context": "sip_account", 4 "nameSpace": "XM", 5 "type": "UserAccount", 6 "table": "sa.usrlitesip", 7 "isExtension": true, 8 "isChild": false, 9 "comment": "Extended by Sip", 10 "relations": [ 11 { 12 "column": "usrlitesip_usr_username", 13 "inverse": "username" 14 } 15 ], 16 "properties": [ 17 { 18 "name": "uri", 19 "attr": { 20 "type": "String", 21 "column": "usrlitesip_uri", 22 "isNaturalKey": true 23 } 24 }, 25 { 26 "name": "displayName", 27 "attr": { 28 "type": "String", 29 "column": "usrlitesip_name" 30 } 31 }, 32 { 33 "name": "sipPassword", 34 "attr": { 35 "type": "String", 36 "column": "usrlitesip_password" 37 } 38 } 39 ], 40 "isSystem": true 41 }, 42 { 43 "context": "sip_account", 44 "nameSpace": "XM", 45 "type": "UserAccountRelation", 46 "table": "sa.usrlitesip", 47 "isExtension": true, 48 "isChild": false, 49 "comment": "Extended by Sip", 50 "relations": [ 51 { 52 "column": "usrlitesip_usr_username", 53 "inverse": "username" 54 } 55 ], 56 "properties": [ 57 { 58 "name": "uri", 59 "attr": { 60 "type": "String", 61 "column": "usrlitesip_uri", 62 "isNaturalKey": true 63 } 64 }, 65 { 66 "name": "displayName", 67 "attr": { 68 "type": "String", 69 "column": "usrlitesip_name" 70 } 71 }, 72 { 73 "name": "sipPassword", 74 "attr": { 75 "type": "String", 76 "column": "usrlitesip_password" 77 } 78 } 79 ], 80 "isSystem": true 81 } 82 ]

Note the “context” is my extension name, because the context + nameSpace + type combo has to be unique. We already have a UserAccount and UserAccountRelation object in the “XM” namespace in the “xtuple” context in the original user_account.json, now we will have a UserAccount and UserAccountRelation object in the “XM” namespace in the “sip_account” conext. What else is important? Note that “isExtension” is true on lines 7 and 47 and the “relations” item contains the “column” of the foreign key we referenced.

This is something you might want to verify: “column” (lines 12 and 52) is the name of the attribute on your table. When we made a reference to the primary key usr_usrname from the xt.usrlite table we named that column usrlitesip_usr_usrname. But the “inverse” is the attribute name associated with the original sql column in the original ORM. Did I lose you? I had a lot of trouble with this silly thing. In the original ORM that created a new UserAccount business object, the primary key attribute is named “username”, as can be seen here. That is what should be used for the “inverse” value. Not the sql column name (usr_username) but the object attribute name (username). I’m emphasizing this because I made that mistake and if I can spare you the pain I will.

If we rebuild our extension everything should come along nicely, but you won’t see any changes just yet in the web app because we haven’t created the client code.

Client

Create the directory /path/to/xtuple-extensions/source/sip_account/client which is where we’ll keep all the client code.

Extend Workspace View I want the fields I added to show up on the form to create a new User Account, so I need to extend the view for the User Account workspace. I’ll start by creating a directory /path/to/xtuple-extensions/source/sip_account/client/views and in it creating a file named ‘workspace.js’ containing this code:

XT.extensions.sip_account.initWorkspace = function () { var extensions = [ {kind: "onyx.GroupboxHeader", container: "mainGroup", content: "_sipAccount".loc()}, {kind: "XV.InputWidget", container: "mainGroup", attr: "uri" }, {kind: "XV.InputWidget", container: "mainGroup", attr: "displayName" }, {kind: "XV.InputWidget", container: "mainGroup", type:"password", attr: "sipPassword" } ]; XV.appendExtension("XV.UserAccountWorkspace", extensions); };

So I’m initializing my workspace and creating an array of items to add (append) to view XV.UserAccountWorkspace. The first ‘item’ is this onyx.GroupboxHeader which is a pretty divider for my new form fields, the kind you find in the web app at Setup > User Accounts, like ‘Overview’. I have no idea what other options there are for container other than “mainGroup”, so let’s stick to that. I’ll explain content: “_sipAccount”.loc() in a bit. Next I created three input fields of the XV.InputWidget kind. This also confused me a bit as there are different kinds of input to be used, like dropdowns and checkboxes. The only advice I can give is snoop around the webapp, find an input you like and look up the corresponding workspace.js file to see what was used.

What we just did is (should be) enough for the new fields to show up on the User Account form. But before we see things change, we have to package the client. Create the file /path/to/xtuple-extensions/source/sip_account/client/views/package.js. This file is needed to ‘package’ groups of files and indicates the order the files should be loaded (for more on that, see this). For now, all the file will contain is:

enyo.depends( "workspace.js" );

You also need to package the ‘views’ directory containing workspace.js, so create the file Create the file /path/to/xtuple-extensions/source/sip_account/client/package.js and in it show that the directory ‘views’ and its contents must be part of the higher level package:

enyo.depends( "views" );

I like to think of it as a box full of smaller boxes.

This will sound terrible, but apparently you also need to create the file /path/to/xtuple-extensions/source/sip_account/client/core.js containing this line:

XT.extensions.icecream = {};

I don’t know why. As soon as I find out I’ll be sure to inform you.

As we’ve added a file to the client directory, be sure to update /path/to/xtuple-extensions/source/sip_account/client/package.js so it included the new file:

enyo.depends( "core.js", "views" );

Translations

Remember “_sipAccount”.loc()” in our workspace.js file? xTuple has great internationalization support and it’s easy to use. Just create the directory and file /path/to/xtuple-extensions/source/sip_account/client/en/strings.js and in it put key-value pairs for labels and their translation, like this:

(function () { "use strict"; var lang = XT.stringsFor("en_US", { "_sipAccount": "Sip Account", "_uri": "Sip URI", "_displayName": "Display Name", "_sipPassword": "Password" }); if (typeof exports !== 'undefined') { exports.language = lang; } }());

So far I included all the labels I used in my Sip Account form. If you write the wrong label (key) or forget to include a corresponding key-value pair in strings.js, xTuple will simply name your lable “_lableName”, underscore and all.

Now build your extension and start up the server:

$ cd /path/to/xtuple $ ./scripts/build_app.js -d dev -e ../xtuple-extensions/source/sip_account $ node node-datasource/main.js

If the server is already running, just stop it and restart it to reflect your changes.

Now if you go to Setup > User Accounts and click the “+” button, you should see a nice little addition to the form with a ‘Sip Account’ divider and three new fields. Nice, eh?

Extend Parameters

Currently you can search your User Accounts list using any of the User Account fields. It would be nice to be able to search with the Sip account fields we added as well. To do that, let’s create the directory /path/to/xtuple-extensions/source/sip_account/client/widgets and there create the file parameter.js to extend XV.UserAccountListParameters. One again, you’ll have to look this up. In the xTuple code you’ll find the application’s parameter.js in /path/to/xtuple/enyo-client/application/source/widgets. Search for the business object you are extending (for example, XV.UserAccount) and look for some combination of the business object name and ‘Parameters’. If there’s more than one, try different ones. Not a very refined method, but it worked for me. Here’s the content of our parameter.js:

XT.extensions.sip_account.initParameterWidget = function () { var extensions = [ {kind: "onyx.GroupboxHeader", content: "_sipAccount".loc()}, {name: "uri", label: "_uri".loc(), attr: "uri", defaultKind: "XV.InputWidget"}, {name: "displayName", label: "_displayName".loc(), attr: "displayName", defaultKind: "XV.InputWidget"} ]; XV.appendExtension("XV.UserAccountListParameters", extensions); };

Node that I didn’t include a search field for the password attribute for obvious reasons. Now once again, we package this new code addition by creating a /path/to/xtuple-extensions/source/sip_account/client/widgets/package.js file:

enyo.depends( "parameter.js" );

We also have to update /path/to/xtuple-extensions/source/sip_account/client/package.js:

enyo.depends( "core.js", "widgets" "views" );

Rebuild the extension (and restart the server) and go to Setup > User Accounts. Press the magnifying glass button on the upper left side of the screen and you’ll see many options for filtering the User Accounts, among them the SIP Uri and Display Name.

Extend List View

You might want your new fields to show up on the list of User Accounts. I figured out a way to do this that looks strange and kind of incorrect, but it’s apparently working.

Create the file /path/to/xtuple-extensions/source/sip_account/client/views/list.js and add the following:

enyo.kind({ name: "XV.UserAccountList", kind: "XV.List", label: "_userAccounts".loc(), collection: "XM.UserAccountRelationCollection", parameterWidget: "XV.UserAccountListParameters", query: {orderBy: [ {attribute: 'username'} ]}, components: [ {kind: "XV.ListItem", components: [ {kind: "FittableColumns", components: [ {kind: "XV.ListColumn", classes: "short", components: [ {kind: "XV.ListAttr", attr: "username", isKey: true} ]}, {kind: "XV.ListColumn", classes: "short", components: [ {kind: "XV.ListAttr", attr: "propername"} ]}, {kind: "XV.ListColumn", classes: "last", components: [ {kind: "XV.ListAttr", attr: "uri"} ]} ]} ]} ] }); XV.registerModelList("XM.UserAccountRelation", "XV.UserAccountList");

This is actually what’s in /path/to/xtuple/enyo-client/application/source/views/list.js – the entire highlighted part. All I did was add this to “components” after line 18:

{kind: "XV.ListColumn", classes: "last", components: [ {kind: "XV.ListAttr", attr: "uri"} ]}

I found this at random after a lot of trial and error. It’s strange because if you encapsulate that code with

XT.extensions.sip_account.initList = function () { //Code here };

as is done with parameter.js and workspace.js (and in the xTuple tutorial you are supposed to do that with a new business object), it doesn’t work. I have no idea why. This might be ‘wrong’ or against xTuple coding norms; I will find out and update this post ASAP. But it does work this way. * shrugs *

That said, as we’ve created the list.js file, we need to ad it to our package by editing /path/to/xtuple-extensions/source/sip_account/client/views/package.js:

enyo.depends( "list.js", "workspace.js" );

That’s all. Rebuild the app and restart your server and when you select Setup > User Accounts in the web app you should see the Sip URI displayed on the User Accounts that have the Sip Account data. Add a new User Account to try this out.

Categories: FLOSS Project Planets

Steve Kemp: The selfish programmer

Fri, 2014-07-25 09:16

Once upon a time I wrote a piece of software for scheduling the classes available to a college.

There was a bug in the scheduler: Students who happened to be named 'Steve Kemp' had a significantly higher chance (>=80% IIRC) of being placed in lessons where the class makeup was more than 50% female.

This bug was never fixed. Which was nice, because I spent several hours both implementing and disguising this feature.

I'm was a bad coder when I was a teenager.

These days I'm still a bad coder, but in different ways.

Categories: FLOSS Project Planets

Wouter Verhelst: Multiarchified eID libraries for Debian

Fri, 2014-07-25 07:44

A few weeks back, I learned that some government webinterfaces require users to download a PDF files, sign them with their eID, and upload the signed PDF document. On Linux, the only way to do this appeared to be to download Adobe Reader for Linux, install the eID middleware, make sure that the former would use the latter, and from there things would just work.

Except for the bit where Adobe Reader didn't exist in a 64-bit version. Since the eid middleware packages were not multiarch ready, that meant you couldn't use Adobe Reader to create signatures with your eID card on a 64-bit Linux distribution. Which is, pretty much, "just about everything out there".

For at least the Debian packages, that has been fixed now (I still need to handle the RPM side of things, but that's for later). When I wanted to test just now if everything would work right, however...

... I noticed that Adobe no longer provides any downloads of the Linux version of Adobe Reader. They're just gone. There is an ftp.adobe.com containing some old versions, but nothing more recent than a 5.x version.

Well, I suppose that settles that, then.

Regardless, the middleware package has been split up and multiarchified, and is ready for early adopters. If you want to try it out, you should:

  • run dpkg --add-architecture i386 if you haven't yet enabled multiarch
  • Install the eid-archive package, as usual
  • Edit /etc/apt/sources.list.d/eid.list, and enable the continuous repository (that is, remove the # at the beginning of the line)
  • run dpkg-reconfigure eid-archive, so that the key for the continuous repository is enabled
  • run apt-get update
  • run apt-get -t continuous install eid-mw to upgrade your middleware to the version in continuous
  • run apt-get -t continuous install libbeidpkcs11-0:i386 to install the 32-bit middleware version.
  • run your 32-bit application and sign things.

You should, however, note that the continuous repository is named so because it contains the results of our continuous integration system; that is, every time a commit is done to the middleware, packages in this repository are updated automatically. This means the software in the continuous repository might break. Or it might eat your firstborn. Or it might cause nasal daemons. As such, FedICT does not support these versions of the middleware. Don't try the above if you're not prepared to deal with that...

Categories: FLOSS Project Planets

Tim Retout: London.pm's July 2014 tech meeting

Fri, 2014-07-25 03:36

Last night, I went to the London.pm tech meeting, along with a couple of colleagues from CV-Library. The talks, combined with the unusually hot weather we're having in the UK at the moment, combined with my holiday all last week, make it feel like I'm at a software conference. :)

The highlight for me was Thomas Klausner's talk about OX (and AngularJS). We bought him a drink at the pub later to pump him for information about using Bread::Board, with some success. It was worth the long, late commute back to Southampton.

All very enjoyable, and I hope they have more technical meetings soon. I'm planning to attend the London Perl Workshop later in the year.

Categories: FLOSS Project Planets

Gunnar Wolf: Nice read: «The Fasinatng … Frustrating … Fascinating History of Autocorrect»

Thu, 2014-07-24 23:18

A long time ago, I did some (quite minor!) work on natural language parsing. Most of what I got was the very basic rudiments on what needs to be done to begin with. But I like reading some texts on the subject every now and then.

I am also a member of the ACM — Association for Computing Machinery. Most of you will be familiar with it, it's one of the main scholarly associations for the field of computing. One of the basic perks of being an ACM member is the subscription to a very nice magazine, Communications of the ACM. And, of course, although I enjoy the physical magazine, I like reading some columns and articles as they appear along the month using the RSS feeds. They also often contain pointers to interesting reads on other media — As happened today. I found quite a nice article, I think, worth sharing with whoever thinks I have interesting things to say.

They published a very short blurb titled The Fasinatng … Frustrating … Fascinating History of Autocorrect. I was somewhat skeptical reading it links to an identically named article, published in Wired. But gave it a shot, anyway...

The article follows a style that's often abused and not very amusing, but I think was quite well done: The commented interview. Rather than just drily following through an interview, the writer tells us a story about that interview. And this is the story of Gideon Lewis-Kraus interviewing Dean Hachamovitch, the creator of the much hated (but very much needed) autocorrect feature that appeared originally in Microsoft Word.

The story of Hachamovitch's work (and its derivations, to the much maligned phone input predictors) over the last twenty-something years is very light to read, very easy to enjoy. I hope you find it as interesting as I did.

Categories: FLOSS Project Planets