/usr/share/battery-stats/battery-stats-graph /var/log/battery-stats.csv

/usr/share/battery-stats/battery-stats-graph-flow

#!/usr/bin/python3
import sys
years = int(sys.argv[1])
# How many 18 months intervals we spent
count = 0
# How many original-computation-time-months we compute each 18 months interval
step = 18
# How many original-computation-time-months we computed so far
total = 0
# How many original-computation-time-months we need
target = years * 12
# Iterate each 18 months interval
while True:
    count += 1
    total += step
    if total > target: break
    step *= 2
print(" :.2f  years needed".format(count / 12 * 18))

$ ./actual_years 15200
9.33 years needed

$ ./actual_years 15200
21.00 years needed

There are two cars (remember phisics in primary school?). They both have the same speed V0. It is going to take "54.697 centuries" for car A to travel the desired distance at constant speed. Car B is accelerating, its speed is 2^(t/18m)*V0 (18 [m]onths). s = V0 * T (car A, T is 54.697 centuries) s = 2^(t/18)*V0 dt (car B, we're looking for t) It's been some time but as far as I can tell it is s = V0 * 2^(t/18) * 1/((1/18) * ln 2) 2^(t/18) * 1/((1/18) * ln 2) = 54.697 * 100 * 12 [months] 2^(t/18) = 2527.54 t = 18*log2(2527.54) t = 16.96 years (still reasonable strength).

• Two nodes (node1-1 and node1-2)
• Active/Passive setup
• Shared IP (here: 123.123.123.123/24)
• Internal network on eth1 (here: 192.168.99.0/24)
• DRBD shared storage
• LVM on top of DRBD
• Multiple services, depending also on the DRBD/LVM storage

apt-get install -t jessie-backports libqb0 fence-agents pacemaker corosync pacemaker-cli-utils crmsh drbd-utils

totem
version: 2
token: 3000
token_retransmits_before_loss_const: 10
clear_node_high_bit: yes
crypto_cipher: none
crypto_hash: none
transport: udpu
interface
ringnumber: 0
bindnetaddr: 192.168.99.0

logging
to_logfile: yes
logfile: /var/log/corosync/corosync.log
debug: off
timestamp: on
logger_subsys
subsys: QUORUM
debug: off

quorum
provider: corosync_votequorum
two_node: 1
wait_for_all: 1
nodelist
node
ring0_addr: node1-1

node
ring0_addr: node1-2

property stonith-enabled=no
property no-quorum-policy=ignore
property default-resource-stickiness=100 primitive DRBD_r0 ocf:linbit:drbd params drbd_resource= r0 op start interval= 0 timeout= 240 \
op stop interval= 0 timeout= 100 \
op monitor role=Master interval=59s timeout=30s \
op monitor role=Slave interval=60s timeout=30s
primitive LVM_r0 ocf:heartbeat:LVM params volgrpname= data1 op monitor interval= 30s
primitive SRV_MOUNT_1 ocf:heartbeat:Filesystem params device= /dev/mapper/data1-lv1 directory= /srv/storage fstype= ext4 options= noatime,nodiratime,nobarrier op monitor interval= 40s primitive IP-rsc ocf:heartbeat:IPaddr2 params ip= 123.123.123.123 nic= eth0 cidr_netmask= 24 meta migration-threshold=2 op monitor interval=20 timeout=60 on-fail=restart
primitive IPInt-rsc ocf:heartbeat:IPaddr2 params ip= 192.168.99.4 nic= eth1 cidr_netmask= 24 meta migration-threshold=2 op monitor interval=20 timeout=60 on-fail=restart primitive MariaDB-rsc lsb:mysql meta migration-threshold=2 op monitor interval=20 timeout=60 on-fail=restart
primitive Redis-rsc lsb:redis-server meta migration-threshold=2 op monitor interval=20 timeout=60 on-fail=restart
primitive Memcached-rsc lsb:memcached meta migration-threshold=2 op monitor interval=20 timeout=60 on-fail=restart
primitive PHPFPM-rsc lsb:php5-fpm meta migration-threshold=2 op monitor interval=20 timeout=60 on-fail=restart
primitive Apache2-rsc lsb:apache2 meta migration-threshold=2 op monitor interval=20 timeout=60 on-fail=restart
primitive Nginx-rsc lsb:nginx meta migration-threshold=2 op monitor interval=20 timeout=60 on-fail=restart group APCLUSTER LVM_r0 SRV_MOUNT_1 IP-rsc IPInt-rsc MariaDB-rsc Redis-rsc Memcached-rsc PHPFPM-rsc Apache2-rsc Nginx-rsc
ms ms_DRBD_APCLUSTER DRBD_r0 meta master-max= 1 master-node-max= 1 clone-max= 2 clone-node-max= 1 notify= true colocation APCLUSTER_on_DRBD_r0 inf: APCLUSTER ms_DRBD_APCLUSTER:Master
order APCLUSTER_after_DRBD_r0 inf: ms_DRBD_APCLUSTER:promote APCLUSTER:start commit

Packages fixed The following packages have become reproducible due to changes in their build dependencies: dfc, gap-openmath, gnubik, gplanarity, iirish, iitalian, monajat, openimageio, plexus-digest, ruby-fssm, vdr-plugin-dvd, vdr-plugin-spider. The following packages became reproducible after getting fixed:

• adduser/3.114 by Niels Thykier.
• bsdmainutils/9.0.7 by Michael Meskes.
• criu/2.0-1 by Salvatore Bonaccorso.
• genometools/1.5.8+ds-2 by Sascha Steinbiss.
• gfs2-utils/3.1.8-1 uploaded by Bastian Blank, fix by Christoph Berg.
• gmerlin/1.2.0~dfsg+1-5 by IOhannes m zm lnig.
• heroes/0.21-14 by Stephen Kitt.
• kmc/2.3+dfsg-3 by Sascha Steinbiss.
• polyml/5.6-3 by James Clarke.
• sed/4.2.2-7.1 by Niels Thykier.
• snpomatic/1.0-3 by Sascha Steinbiss.
• tantan/13-4 by Sascha Steinbiss.

Some uploads fixed some reproducibility issues, but not all of them:

• apg/2.2.3.dfsg.1-3 uploaded by Marc Haber, original patch by Chris Lamb.
• elastix/4.8-4 uploaded by Gert Wollny, reported by akira.

Patches submitted which have not made their way to the archive yet:

• #817979 on modernizr by Sascha Steinbiss: sort list of files included in feature-detects.js.
• #818027 on snapper by Sascha Steinbiss: always use /bin/sh as shell.

tests.reproducible-builds.org Always use all cores on armhf builders. (h01ger) Improve the look of Debian dashboard. (h01ger)

Package reviews 118 reviews have been removed, 114 added and 15 updated in the previous week. 15 FTBFS have been filled by Chris Lamb. New issues: xmlto_txt_output_locale_specific.

Misc. Lunar seeks new maintainers for diffoscope, several mailing lists, and these very weekly reports.

1. take the liner out of the boot,
2. pull on the liner,
3. step into the outer shell.

The requirement I have been following the development of fascinating tools from the Development seed people, now seemingly all focused on the Mapbox brand. They created what seemed to me a revolutionary desktop tool called Tilemill. Tilemill allowed you to create custom map stylesheets on your desktop to outline specific areas or patterns or "things". My interest was to create outdoor maps - OSM has pretty good biking maps, but no generic outdoor tiles out there (I need stuff for skiing, canoeing, biking)... Mapbox has Mapbox outdoors but that's a paid plan as well. Oh and there's a place to download Garmin data files especially made for outdoors as well, and that could be loaded in Qmapshack, but they don't have coverage in Canada at all. Besides, I would like to print maps, I know, crazy... So I have been looking forward to seeing Tilemill packaged in Debian given how annoying it is to maintain Node apps (period). Unfortunately, by the time Debian people figured out all the Node dependencies, the Tilemill project stopped and has been stalled since 2012. It seems the Mapbox people have now been working on other products, and in the meantime, the community, scratching their heads, just switched to other projects.

Overview of alternatives I wrote this long post to the Debian bugtrackers to try to untangle all of this, but figured this would be interesting to a wider community than the narrow group of people working on Javascript packages, so I figured I would send this on Debian planet. So Here's a summary of what happened so far, after Tilemill development stopped. Hang on to your tiles boys and girls, there's a lot going on!

Mapbox Studio classic Mapbox people have released a new product in September 2014 named Mapbox studio classic. The code is still freely available and seems to be a fork of tilemill. Mapbox classic still has releases on github, last one is from November 2015. It looks like Mapbox studio classic has some sort of Mapbox.com lock-in, and there are certainly new copyright issues, if only with the bundled fonts, but it could probably be packaged after addressing those issues. There is an ITP for Mapbox Studio classic as well.

Mapbox Studio Then there's Mapbox Studio, which is a full rewrite of Mapbox Studio classic. You need to "signup" somehow to get access, even though parts of the code are free, namely the Mapbox GL studio project. It is an interesting project because it aims to make all this stuff happen in a web browser, which means it "should" work everywhere. Unfortunately for us, it means it doesn't work anywhere without a signup form, so that's out for me at least. There is an [ITP for Mapbox-studio][] yet it is unclear to me what that one means because the source code to Mapbox-studio doesn't seem to be available, as far as i can tell (and the ITP doesn't say either). That is actually the ITP for Mapbox studio classic.

Kosmtik The Openstreetmap-carto developers have mostly switched to kosmtik instead of Mapbox. Kosmtik is another Node desktop app that seems fairly lightweight and mostly based on plugins. Ross has an ITP for kosmtik. The package is waiting on other node dependencies to be uploaded (yes, again).

The future of Tilemill And there's still this RFP for tilemill, which should probably be closed now because the project seems dead and plenty of alternatives exist. I wonder if node some dependencies that were packaged for Tilemill actually now need to be removed from Debian, because they have become useless leaf packages... I am leaving the Tilemill RFP open for someone to clean that up.

CartoCSS Oh, and finally one could mention another Mapbox project, Carto, a command line CSS tools that implements some sort of standard CSS language that all those tools end up using to talk to Mapnik, more or less. There are no RFPs for that.

• Inspire, motivate, and enable the Debian community to make Debian better: to be the grease that makes the machinery run smoother. It is not important that the DPL do things, except to make sure other people can do.
• Delegate what work can be delegated. The DPL is only one person, and should not be a bottleneck. Anything that can reasonably be delegated should be delegated.
• Deal with mundane management tasks. This includes spending Debian money when it makes things easier, such as by funding sprints.
• Represent the project in public, or find people to do that in specific cases.
• Help resolve conflicts within the project.

1. Keep Debian running. Debian can run for a long time effectively on autopilot, even if the DPL vanishes, but not indefinitely. At minimum, the DPL should delegate the secretary and technical committee members, and decide on how money should be spent. I will make sure this minimum level is achieved.
2. While I have no technical goals to set for the project, I have an organisational one. I believe it is time for the project to form a social committee whose mandate is to step in and help resolve conflicts in their early stages, before they grow big enough that the DPL, the tech-ctte, listmasters, or the DAM needs to involved. See below for more details on this. If I am elected, I will do my best to get a social committee started, and I will assume that any vote for me is also a vote for a social committee.

• is reasonably small, like the technical committee
• attempts to resolve conflicts at an early stage
• is delegated by the DPL to have authority to do this
• doesn't necessarily have direct authority to remove people from mailing lists, IRC channels, or expel them from the project, but has authority suggest such measures to the appropriate team
• may do other things, such as educate people on how to resolve conflicts constructively themselves, or deal with chronic conflicts in addition to acute flare-ups

cat hello.c
#include <stdio.h>
int main(void)  
    printf("Hello World!\n");
    return 0;
 

./hello
bash: ./hello: No such file or directory

strace ./hello
execve("./hello", ["./hello"], [/* 14 vars */]) = -1 ENOENT (No such file or directory)

./hello: cannot execute binary file: Exec format error

dpkg --add-architecture <target architecture>
apt update
apt install libc6:<target architecture>

• Antoine Beaupr did 8h.
• Ben Hutchings did 14 hours (out of 11.25 hours allocated + 10 extra hours remaining, meaning that he still has 7.25 extra hours to do over March).
• Brian May did 10 hours.
• Chris Lamb did 18 hours (instead of the 11.25 hours he was allocated, he will work less in March).
• Damyan Ivanov did 4 hours (out of 11.25 hours allocated, leaving 7.25 extra hours for March).
• Guido G nther did 7 hours (out of 11.25 hours allocated, leaving 4.25 extra hours for March).
• Markus Koschany did 11.25 hours.
• Mike Gabriel did 8 hours.
• Santiago Ruano Rinc n did 12 hours (out of 11h allocated + 2.50 remaining, thus keeping 1.50 extra hours for March).
• Scott Kitterman did 8 hours.
• Thorsten Alteholz did 11.25 hours.

• Platinum sponsors:
• TOSHIBA (for 5 months)
• Gold sponsors:
• The Positive Internet (for 21 months)
• Blablacar (for 20 months)
• Linode LLC (for 10 months)
• Silver sponsors:
• Domeneshop AS (for 20 months)
• Universit Lille 3 (for 20 months)
• Trollweb Solutions (for 18 months)
• Nantes M tropole (for 14 months)
• University of Luxembourg (for 12 months)
• Dalenys (for 10 months)
• Univention GmbH (for 6 months)
• Universit Jean Monnet de St Etienne (for 6 months)
• Bronze sponsors:
• David Ayers IntarS Austria (for 21 months)
• Offensive Security (for 21 months)
• Seznam.cz, a.s. (for 21 months)
• Evolix (for 20 months)
• Freeside Internet Service (for 20 months)
• MyTux (for 20 months)
• Linuxhotel GmbH (for 18 months)
• Intevation GmbH (for 17 months)
• Daevel SARL (for 16 months)
• Bitfolk LTD (for 15 months)
• Megaspace Internet Services GmbH (for 15 months)
• Greenbone Networks GmbH (for 14 months)
• NUMLOG (for 14 months)
• WinGo AG (for 13 months)
• Ecole Centrale de Nantes LHEEA (for 9 months)
• Sig-I/O (for 7 months)
• Entr ouvert (for 5 months)
• Adfinis SyGroup AG

No comment Liked this article? Click here. My blog is Flattr-enabled.

The elite alpha problem My first problem with Keybase was of course that I wasn't in the elite club of invited people. Somehow, I finally got in but the problem remains for the everyone else. In my case, it was the Keybase filesystem announcement that brought my attention back to the project, although I have yet to test that itself - yet another invite-only problem (need to email chris@keybase.io to get access, I guess). Still, 10GB of storage might be interesting for some people, but considering the number of hurdles or "friction", as they say, that needs to be jumped over to get access, I am not sure how much traction this will get for now. The project has been in alpha for a while now (more than a year) with no announced public beta just yet, which is way slower than similarly challenging projects with less capital. Let's encrypt, as a comparison, was publicly announced in 2014 and by the end of 2015, the public beta was opened.

Private key leakage My second major concern is that Keybase does worrisome things to private key material. If you tell it to import your regular GPG keys, it will copy them into the keybase keyring, which is already a problem: now you have two places where you store sensitive secrets. But worse, Keybase offers you to upload your private key material on the server, without clearly and explicitely exposing the potential risks that means to the user. The key, presumably, is encrypted (at least that is what I can parse from the Keybase privacy policy). Yet this is still a concern: a determined attacker (e.g. the government or another malicious entity) could force Keybase to give up the encrypted private key material and install sniffers that would reveal the passphrase that would allow decryption and impersonation of the related identity. That is a huge deal. This is what caused Hushmail's demise in 2007: they had similar promises about how they had a "secure" email (in this case) service based on OpenPGP, but since they key was stored on the server, they only had to serve a malicious applet to victims and were able to give cleartext data to the US government (12 CDs!) under a Mutual Legal Assistance Treaty with Canada. In Keybase, When I generate a new key, it asks me if I want to upload the key to their servers, and "Yes" is chosen as a default, so it is clearly a policy that is encouraged. This is presumably to enable browser-based crypto, yet this could be done by storing keys within the browser, not on the server. The mere possibility that the client can meddle with secret key material in such a way is a problem. Even if uploading secret keys to the server is optional, the fact that it is a possibility widens the attack surface on the client significantly. GPG has been working on isolating private key operations to a different process (gpg-agent) or smart cards, SSH has privilege seperation. The idea of uploading secret key material online is so beyond current practices that it should bring the project to a full stop already. My private key material is pretty sensitive. I am a Debian developer: if someone gets access to that key, they can upload arbitrary code for thousands of packages, affecting thousands if not millions of users. That is a huge deal, and I am not ready to give that power to an arbitrary third party that I know little about.

Privacy policy issues Furthermore, the Keybase privacy policy explicitely states that "Logs of this information may persist for an indefinite period", which include, and I quote:

• Your computer s IP address
• Your preferences and settings (time zone, language, privacy preferences, application preferences, etc.)
• The URL of the site that referred you to the Service
• The buttons and controls you clicked on (if any) within the Service
• How long you used the Service and which parts and features you used
• Session times and lengths

For a company working to improve user's privacy, this is a pretty bad policy. It exposes Keybase users to undue surveillance, on a lot of private information that is not necessary to operate the service. I haven't actually read the remaining of the policy, as I was already scared as hell and figure I would just log off for now and try not to add any extra personal information in that already growing pile. Let's mention, while I'm here, that the keybase commandline client has this odd way of working that it forks a daemon in the background all the time, even to run just keybase status. One has to wonder if this thing is included in the surveillance data above, which would make the keybase client an amazing surveillance device in itself. To stop all this, you need:

keybase logout
keybase ctl stop

Not quite obvious...

Usability issues Which brings me to a series of usability issues I have found while working with Keybase. Having worked on usability myself in the Monkeysphere project, I understand how hard those problems can be. But right now, the fact is that keybase is only a commandline client, with some web-based sugar sprinkled on top. I recognize the huge efforts that have been done to make the user experience (UX) as easy as possible through the commandline, but this is definitely not "grand public" material yet. Even as a OpenPGP hacker, Keybase can get confusing. Since it has its own separate keyring from GPG, things that used to be obvious before are suddenly new things to learn. For example, I originally generated a key for anarcat@debian.org in keybase, thinking it would be a separate thing from my current GPG identity. Well, that ended up creating a new key in my GPG keyring, duplicating my existing identity, with no way for me to tell this was a Keybase copy. This could have ended up on the keyservers and confuse anyone looking for my PGP key.

Revoking keys So I revoked that key, which, in itself, is not such an obvious process either. I first had to "drop" the key:

keybase pgp drop '010143572d4e438f457a7447c9758804cc7be44c1ee2b7915c3904567d0a3fb5cf590a'

To find that magic number, I had to go on the website and click through the PGP key to end up on the revoke link which told me which magic string to put. The web UI was telling me I could use keybase status to get that information, but I couldn't find that in the output here:

$ keybase status
Username:      anarcat
Logged in:     no
Device:
    name:      angela
    ID:        070f6a13f2a66afbb463f49dadfd4518
    status:    active
Keybase keys:  unlocked
Session:       anarcat [salt only]
KBFS:
    status:    not running
    version:
    log:       /home/anarcat/.cache/keybase/keybase.kbfs.log
Service:
    status:    running
    version:   1.0.14-1
    log:       /home/anarcat/.cache/keybase/keybase.service.log
Platform Information:
    OS:        linux
    Runtime:   go1.5.3
    Arch:      amd64
Client:
    version:   1.0.14-1
Desktop app:
    status:    not running
    version:
    log:       /home/anarcat/.cache/keybase/Keybase.app.log
Config path:   /home/anarcat/.config/keybase/config.json
Default user:  anarcat
Other users:
command-line client:
    keybase status [pid: 14562, version: 1.0.14-1]

So keybase drop "deletes" the key from the keybase client (and presumably the server). One problem here is that we have three different verbs to mean the same thing: in some places, the website says "deleted" (in the web graph), the commandline client uses "drop" and everyone else using PGP in the world uses "revoke". So what is it? Also note that just dropping that key is not enough to eradicate that key: you still need to generate and import a revocation certificate on GPG's side as well, for that key. This makes sense, because you may have imported that key and you may not want to destroy it when you remove it from keybase, but there could be a little better guessing and UX here as well.

Password usage Then another problem is that, when you signup on the commandline, it asks you to choose a passphrase. It's not clear at all from the UI what that passphrase is for. Is it to protect the private key material? To login the website? Both? It turns out it is actually to login to the website and the Keybase API. It could also be the key to the private key material, but I haven't quite figured that out yet. Similarly, the "paper devices" are a little confusing to me as well. The registration process is fairly insistent that I need to write a series of secret words down on a piece of paper and put it my wallet. This is based on the idea that you can use that key to recover your account and setup new devices. However, it is not made clear at all how those credentials should be protected or used. What if I lose my wallet? What do I do then? Is it okay if i write it on the back of my laptop instead? I know it sounds like stupid questions to crypto geek, but it's definitely stuff people will do, and education, at all levels, is necessary here.

The existing web of trust Finally, I found it surprisingly counter-intuitive to sign keys with keybase. I was assuming the whole point of the thing was to expand the web of trust, but it seems their mission lies somewhere else: there is no facility to sign keys directly in keybase. You sign statements on various social sites (Github, Twitter, Reddit...) but doing traditional key exchanges seems to be off limits. My obvious use case was to sign my existing key material with my newly generated anarcat@keybase.io key, so that keybase would become another way of verifying my identity. Well, this is not possible with keybase directly - you still have to go through the regular:

gpg --sign-key DEADBEEF

Which is really unfortunate, because some craaaazy people like me insist on doing in person, actually secure key exchanges sometimes, and the tools to do this right now (mainly gpg, caff and monkeysign) really need a lot of love and help. Keybase could have helped a lot in pushing those initiatives forward and bring new ways of doing secure key exchanges, instead of only lowering the standards on cryptographic identity.

Usual proprietary startup rant I can't help but finish by noticing that the whole basic problem with Keybase is more fundamental than a few usability issues, which can all be fixed fairly easily. Keybase.IO is a web-based service that is entirely proprietary. The client is freely downloadable and free software - but the server side is not. This makes us rely on a central point of failure and the goodwill of those operators to not only keep the service running (for free?) indefinitely, but to protect us against all attackers, state-run or otherwise. This is definitely against basic free software principles and the open architecture of the internet federation, well embodied in the Franklin street statement. Online services should be decentralized and open like the OpenPGP keyservers have always been, period.

Conclusion I am curious to see where Keybase brings us, as a community. So far, I am concerned about centralization and devaluation of the web of trust as cryptographic system. I do not believe that trusting multiple corporate social networking sites bring much benefit to our security, although it does improve usability significantly and is certainly better than TOFU, so that part of the project is definitely interesting, especially since it allows leveraging classical internet protocols like DNS and HTTPS. Key exchange is a critical problem that still hasn't properly been resolved in the cryptographic community. Most efforts at building communication tools (say like Signal or Telegram) mostly ignore the problem and expect people to read up strings of numbers or rely on synchronous communications (see the Axolotl rachet for Signal's take on it). Keybase's attempts at fixing this are great, but needs much more work to actually resolve the PKI issues in a significant way. More fundamentally, the practice of storing keys on the servers should just stop: it is a definite no go for me, and a classic crypto mistake that has bitten way too many people. In my mind, it discredits the whole project. The point of OpenPGP is end to end encryption across devices: storing the keys on a server breaks that apart, and doesn't improve much on the existing HTTPS security systems already in place on the web. It is especially a problem given the new waves of attacks on cryptography from western governments, from the UK to California... Until those issues are resolved, I can't get myself to recommend Keybase to anyone just yet.

Post-scriptum Note to Keybase developers: I have considered filing issues regarding the above, but unfortunately, I was unable to filter through the gigantic github issues list for duplicates, and didn't have time to file detailed reports for everything. I apologize for bypassing those usual conventions. If you want to try out Keybase to make your own opinion, I do have 4 invites I can give away, but I will do so only if you need to test specific issues. Otherwise, I note that there is a Request For Package for the Debian package to become official, that Debian developers (or Keybase developers!) may be interested in completing.

• Fixed automatic translation for project owners.
• Improved performance of commit and push operations.
• New management command to add suggestions from command line.
• Added support for merging comments on file upload.
• Added support for some GNU extensions to C printf format.
• Documentation improvements.
• Added support for generating translator credits.
• Added support for generating contributor stats.
• Site wide search can search only in one language.
• Improve quality checks for Armenian.
• Support for starting translation components without existing translations.
• Support for adding new transations in Qt TS.
• Improved support for translating PHP files.
• Performance improvements for quality checks.
• Fixed sitewide search for failing checks.
• Added option to specify source language.
• Improved support for XLIFF files.
• Extended list of options for import_project.
• Improved targeting for whiteboard messages.
• Support for automatic translation across projects.
• Optimized fulltext search index.
• Added management command for auto translation.
• Added placeables highlighting.
• Added keyboard shortcuts for placeables, checks and machine translations.
• Improved translation locking.
• Added quality check for AngularJS interpolation.
• Added extensive group based ACLs.
• Clarified terminology on strings needing review (formerly fuzzy).
• Clarified terminology on strings needing action and not translated strings.
• Support for Python 3.
• Dropped support for Django 1.7.
• Dropped dependency on msginit for creating new Gettext po files.
• Added configurable dashboard views.
• Improved notifications on parse erorrs.
• Added option to import components with duplicate name to import_project.
• Improved support for translating PHP files
• Added XLIFF export for dictionary.
• Added XLIFF and Gettext PO export for all translations.
• Documentation improvements.
• Added support for configurable automatic group assignments.
• Improved adding of new translations.

Filed under: English Weblate 0 comments

library(gtrendsR)
dp <- gtrends("Donald Drumpf", res="7d")
plot(dp) + ggplot2::ggtitle("The Drumpf") + ggplot2::theme(legend.position="none")

gtrendsR 1.3.3

• A ggplot2 object can now be returned for further customization. plot(gtrends("NHL")) + ggtitle("NHL trend") + theme(legend.position="none")
• Support for hourly and daily data (#67). For example, it is now possible to have hourly data for the last seven days with gtrends("nhl", geo = "CA", res = "7d"). Use ?gtrends for more information about the time resolution supported by the package.
• Support for categorties (#46). Ex.: gtrends("NHL", geo = "US", cat = "0-20") will search only in the sport category.
• Some countries (ex: Hong Kong) were missing from the list (#69).
• Various typos and documentation work.

gtrendsR 1.3.2

• Added support for sub-countries (#25). Ex.: gtrends("NHL", geo = "CA-QC") will return trends data for Qu bec province in Canada. The list of supported sub-countries can be obtained via data(countries).
• Data parsing should work for any data returned by Google Trends (i.e. countries independent).
• Better support for queries using keywords in different languages (#50, #57). Ex.: gtrends(" ", geo = "TW")
• Now able to specify up to five countries (#53) via gtrends("NHL", geo = c("CA", "US"))
• Fixing issue #51 allowing UK-based queries via geo = "GB"

gtrendsR 1.3.1

• Fixing issue #34 where connection verification was not done properly.
• Now able to use more latin character in query. For example: gtrends("montr al").
• Can now deal with data returned other than in English language.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Edited 2016-03-08: Corrected code snipped and one grammar instance

• #12067 Adding "JSON" option to dropdown
• #12047 Filtering databases on databases listing
• #12052 Filtering databases on databases listing, Issue #12047
• #12063 duplicate a table occur an error,for uft-8?
• #12064 Cross-site scripting (XSS) vulnerability in phpMyAdmin Version 4.5.4.1
• #11776 SQL Linter Problems
• #12025 Import reports false SQL error with MariaDB
• #12045 unrecognized keyword left in where clause #11975 (REMAINS UNSOLVED)
• #12041 Missing indexes and constratins in export
• #12028 "ALL" keyword not recognized
• #12054 MySQLDump .sql import in v4.5.5 fails becuase of escaped characters
• #12053 upload-release error
• #12055 Parse eror with 4.6.0-rc1 and master
• #12056 Invalid data stored in $_SESSION[' PMA_token '] if openssl_random_pseudo_bytes() fails
• #12015 create-release errors
• #12048 SQL parser doesn't honor vendor config
• #12024 Better icon for table hiding
• #12032 Icons added and code changed to display icons #12024
• #12037 Fix parse git data without gz support (bug 12030)
• #12030 Do not try to parse git data without gz support
• #12044 Fix example in test/README.rst
• #10 1.1 XSS in Static analysis of SQL query [PMASA-2016-10]
• #11 1.2 XSS in "Edit inline" of SQL query [PMASA-2016-11]
• #16 1.6 XSS Via HOST header [PMASA-2016-11]
• #17 1.7 XSS in file_echo.php by mime sniffing text/plain (only in old IE <= 8 & old Safari on windows) [PMASA-2016-11]
• #19 2. insecure CURL SSL Settings [PMASA-2016-13]
• #37 Fix DROP VIEW statement is not constructed properly by the parser, Issue #36
• #39 Fails to parser CREATE TABLE
• #36 DROP VIEW statement is not constructed properly by the parser
• #38 Recognize ALL when used with WHERE clause

Filed under: Debian English phpMyAdmin 0 comments

• Triage of 17 CVEs for squeeze-lts. I misread the calendar and thought I was on front-desk duty for a couple of days. Fortunately no duplicate work was done.
• Prepared and released DLA-427-1 for nss fixing CVE-2016-1938 after checking that nss is not affected by CVE-2015-7575 since MD5 signatures never got disabled - another good reason why we should have the same nss in all suites.

• I prepared patches for CVE-2015-8036 and CVE-2015-5291 for polarssl for jessie including some autpkgtests (wheezy already happened in January) resulting in DSA-3468-1.
• Prepared patches for CVE-2015-1323 affecting apt-daemon (789162) for jessie and wheezy waiting for a review.

• Uploaded libvirt-python 1.3.1 to unstable.
• Uploaded virt-manager 1.3.2 to experimental.
• Uploaded libvirt 1.3.2-2 to unstable dropping the libvirt-bin transitional package after NMUing gnome-boxes and virt-goodies to remove the dependency.
• Uploaded whatmaps to experimental switching to Python3