Elsewhere

Daniel Pocock: Welcoming libphonenumber to Debian and Ubuntu

Planet Debian - ven, 29/08/2014 - 10:02

Google's libphonenumber is a universal library for parsing, validating, identifying and formatting phone numbers. It works quite well for numbers from just about anywhere. Here is a Java code sample (C++ and JavaScript also supported) from their web site:


String swissNumberStr = "044 668 18 00";
PhoneNumberUtil phoneUtil = PhoneNumberUtil.getInstance();
try {
  PhoneNumber swissNumberProto = phoneUtil.parse(swissNumberStr, "CH");
} catch (NumberParseException e) {
  System.err.println("NumberParseException was thrown: " + e.toString());
}
boolean isValid = phoneUtil.isValidNumber(swissNumberProto); // returns true
// Produces "+41 44 668 18 00"
System.out.println(phoneUtil.format(swissNumberProto, PhoneNumberFormat.INTERNATIONAL));
// Produces "044 668 18 00"
System.out.println(phoneUtil.format(swissNumberProto, PhoneNumberFormat.NATIONAL));
// Produces "+41446681800"
System.out.println(phoneUtil.format(swissNumberProto, PhoneNumberFormat.E164));

This is particularly useful for anybody working with international phone numbers. This is a common requirement in the world of VoIP where people mix-and-match phones and hosted PBXes in different countries and all their numbers have to be normalized.

About the packages

The new libphonenumber package provides support for C++ and Java users. Upstream also supports JavaScript but that hasn't been packaged yet.

Using libphonenumber from Evolution and other software

Lumicall, the secure SIP/ZRTP client for Android, has had libphonenumber from the beginning. It is essential when converting dialed numbers into E.164 format to make ENUM queries and it is also helpful to normalize all the numbers before passing them to VoIP gateways.

Debian includes the GNOME Evolution suite and it will use libphonenumber to improve handling of phone numbers in contact records if enabled at compile time. Fredrik has submitted a patch for that in Debian.

Many more applications can potentially benefit from this too. libphonenumber is released under an Apache license so it is compatible with the Mozilla license and suitable for use in Thunderbird plugins.

Improving libphonenumber

It is hard to keep up with the changes in dialing codes around the world. Phone companies and sometimes even whole countries come and go from time to time. Numbering plans change to add extra digits. New prefixes are created for new mobile networks. libphonenumber contains metadata for all the countries and telephone numbers that the authors are aware of but they also welcome feedback through their mailing list for anything that is not quite right.

Now that libphonenumber is available as a package, it may be helpful for somebody to try and find a way to split the metadata from the code so that metadata changes could be distributed through the stable updates catalog along with other volatile packages such as anti-virus patterns.

Catégories: Elsewhere

Robert Collins: Test processes as servers

Planet Debian - ven, 29/08/2014 - 06:10

Since its very early days subunit has had a single model – you run a process, it outputs test results. This works great, except when it doesn’t.

On the up side, you have a one way pipeline – there’s no interactivity needed, which makes it very very easy to write a subunit backend that e.g. testr can use.

On the downside, there’s no interactivity, which means that anytime you want to do something with those tests, a new process is needed – and thats sometimes quite expensive – particularly in test suites with 10’s of thousands of tests.Now, for use in the development edit-execute loop, this is arguably ok, because one needs to load the new tests into memory anyway; but wouldn’t it be nice if tools like testr that run tests for you didn’t have to decide upfront exactly how they were going to run. If instead they could get things running straight away and then give progressively larger and larger units of work to be run, without forcing a new process (and thus new discovery directory walking and importing) ? Secondly, testr has an inconsistent interface – if testr is letting a user debug things to testr through to child workers in a chain, it needs to use something structured (e.g. subunit) and route stdin to the actual worker, but the final testr needs to unwrap everything – this is needlessly complex. Lastly, for some languages at least, its possibly to dynamically pick up new code at runtime – so a simple inotify loop and we could avoid new-process (and more importantly complete-enumeration) *entirely*, leading to very fast edit-test cycles.

So, in this blog post I’m really running this idea up the flagpole, and trying to sketch out the interface – and hopefully get feedback on it.

Taking subunit.run as an example process to do this to:

  1. There should be an option to change from one-shot to server mode
  2. In server mode, it will listen for commands somewhere (lets say stdin)
  3. On startup it might eager load the available tests
  4. One command would be list-tests – which would enumerate all the tests to its output channel (which is stdout today – so lets stay with that for now)
  5. Another would be run-tests, which would take a set of test ids, and then filter-and-run just those ids from the available tests, output, as it does today, going to stdout. Passing somewhat large sets of test ids in may be desirable, because some test runners perform fixture optimisations (e.g. bringing up DB servers or web servers) and test-at-a-time is pretty much worst case for that sort of environment.
  6. Another would be be std-in a command providing a packet of stdin – used for interacting with debuggers

So that seems pretty approachable to me – we don’t even need an async loop in there, as long as we’re willing to patch select etc (for the stdin handling in some environments like Twisted). If we don’t want to monkey patch like that, we’ll need to make stdin a socketpair, and have an event loop running to shepard bytes from the real stdin to the one we let the rest of Python have.

What about that nirvana above? If we assume inotify support, then list_tests (and run_tests) can just consult a changed-file list and reload those modules before continuing. Reloading them just-in-time would be likely to create havoc – I think reloading only when synchronised with test completion makes a great deal of sense.

Would such a test server make sense in other languages?  What about e.g. testtools.run vs subunit.run – such a server wouldn’t want to use subunit, but perhaps a regular CLI UI would be nice…


Catégories: Elsewhere

Russ Allbery: git-pbuilder 1.33

Planet Debian - ven, 29/08/2014 - 01:37

git-pbuilder is a script to integrate git-buildpackage with pbuilder or cowbuilder. My long-term hope is to rewrite it in Python and just incorporate it into git-buildpackage's source base directly, but in the meantime I've been maintaining it as a separate script.

This new release is a relatively minor bug fix. git-pbuilder has always removed the *_source.changes file built as part of the pbuilder process, since this file is normally useless. It's used to generate the source package to move into the chroot, but then the build in the chroot normally regenerates the Debian source package. The *_source.changes file hangs around with invalid checksums and just confuses matters, so git-pbuilder has always deleted it.

However, Debian is now increasing support for source-only uploads, which means that source-only builds might now be interesting. One can do a source-only build with gbp buildpackage -S. But that also generates a *_source.changes file, one that's actually useful, and git-pbuilder was deleting that as well. This release, thanks to work by Guido Günther, refrains from deleting this file when doing a source-only build.

You can get the latest release of git-pbuilder from my scripts distribution page.

Catégories: Elsewhere

Forum One: Introducing the Gesso Theme

Planet Drupal - jeu, 28/08/2014 - 21:31

For the past year Forum One has been using a Drupal starter theme created in-house to make theming more flexible, consistent, and easier to maintain. This theme is now available on drupal.org! Gesso (pronounced JEH-so) is an art term for the white paint mixture used to prepare a canvas or sculpture for painting. Likewise, the Gesso theme prepares Drupal’s markup and styles to give us a clean starting point.

Gesso is a responsive, Sass-based theme developed with accessible, standards-compliant HTML5 markup. It follows a mobile-first, future-friendly approach to coding responsive websites. Gesso also removes much of the cruft that we previously tended to override on each project and standardizes common components.

A word of caution: this theme is geared towards advanced themers. If you want to be able to manipulate the theme’s design, markup, or layout via a nice GUI, Gesso is not the theme for you. We built this theme to make it easy to customize within the Drupal theming layer, without getting in your way.

Gesso is not a stand-alone product. It depends on several Drupal modules and Sass tools: Magic, HTML5 Tools, Compass, Breakpoint, and Singularity.gs. It also integrates well with optional Drupal modules such as Display Suite, Panels, Blockify, Clean Markup, and Modernizr.

To be clear, Gesso wasn’t created in a vacuum. We got a ton of great ideas by diving deep into the code of other Drupal themes, such as:

If you want to develop a deeper understanding of Drupal theming, I encourage you to check out the code within these themes.

The biggest differentiator between Gesso and other themes is the altered Drupal markup, which makes it easier to follow the Drupal 8 CSS architecture guidelines. This theme leverages SMACSS with a modified BEM naming convention to organize styles. This encourages a component-based approach to theming through the creation of discrete, reusable UI elements.

In follow-up articles we’ll cover Gesso in more depth, including Sass organization, site building, and theme settings. Please join us in the issue queue if you have questions or ideas on how to improve it.

Catégories: Elsewhere

Bernhard R. Link: Where key expiry dates are useful and where they are not.

Planet Debian - jeu, 28/08/2014 - 20:57

Some recent blog (here and here) suggest short key expiry times.

Then also highlight some thing many people forget: The expiry time of a key can be changed every time with just a new self-signature. Especially that can be made retroactively (you cannot avoid that, if you allow changing it: Nothing would stop an attacker from just changing the clock of one of his computers).

(By the way: did you know you can also reduce the validity time of a key? If you look at the resulting packets in your key, this is simply a revocation packet of the previous self-signature followed by a new self-signature with a shorter expiration date.)

In my eyes that fact has a very simple consequence: An expiry date on your gpg main key is almost totally worthless.

If you for example lose your private key and have no revocation certificate for it, then a expiry time will not help at all: Once someone else got the private key (for example by brute forcing it, as computers got faster over the years or because they could brute-force the pass-phrase for your backup they got somehow), they can just extend the expiry date and make it look like it is still valid. (And if they do not have the private key, there is nothing they can do anyway).

There is one place where expiration dates make much more sense, though: subkeys.

As the expiration date of a subkey is part of the signature of that subkey with the main key, someone having access to only the subkey cannot change the date.

This also makes it feasible to use new subkeys over the time, as you can let the previous subkey expire and use a new one. And only someone having the private main key (hopefully you), can extend its validity (or sign a new one).

(I generally suggest to always have a signing subkey and never ever use the main key except off-line to sign subkeys or other keys. The fact that it can sign other keys just makes the main key just too precious to operate it on-line (even if it is on some smartcard the reader cannot show you what you just sign)).

Catégories: Elsewhere

LightSky: The Drupal Community

Planet Drupal - jeu, 28/08/2014 - 20:12
Download

In this episode of Time to Live we have Doug Vann as our guest.  Doug is the President of Synaptic Blue, a Drupal consulting firm, and is extremely active in the Drupal community.  We discuss a variety of aspects of the Drupal community and how it benefits individuals and companies to get involved in the community.

Participants

Michael Hodge Jr - President/Owner at LightSky - @m_hodge

Bruce Clingan - Director of Business Development at LightSky - @astrocling

Doug Vann - President of Synaptic Blue - @dougvann

Comments/Questions

We are doing this podcast for our visitors. If you have any ideas for how we can improve our podcasts, or ideas for future topics please let us know. You can either reach us via email, twitter or in the comments below.

Catégories: Elsewhere

Drupal Association News: Drupal.org team week notes #29

Planet Drupal - jeu, 28/08/2014 - 18:48

Better credit for organizations on Drupal.org

We added a feature to projects on Drupal.org to help highlight the contributions made by supporting organizations. Maintainers of distributions, modules, and themes can give credit to organizations that have materially contributed to projects on Drupal.org using the new “Supporting Organizations" field.

If you are a project maintainer, take a moment to give some credit to the organizations that have helped build the Drupal ecosystem.

Drupal Jobs launch

We’re proud to announce the launch of Drupal Jobs, a career site dedicated completely to Drupal. The Drupal job market is hot and we hope this new tool will help match the right talent with the right positions.

For job seekers, you can start searching for positions by location, position, skill level and more. You can create a profile with your job preferences and salary requirements, and even choose whether you wish to be contacted by employers and recruiters. All for free.

For employers and recruiters there are a variety of packages available, giving them the opportunity to highlight their company with a branded page and feature select postings in newsletters and social media. The great thing is that proceeds from postings are invested back into Drupal.org and its subsites (including Drupal Jobs) and community programs.

Upcoming deployments

We are slowly moving towards implementing the new layout for user profiles on Drupal.org. In the coming weeks we will be migrating profile fields to user fields bit by bit. Profile layout will be changing along the way and might look messy at times during migration.

Next week we are planning to deploy software and infrastructure changes to support the new Drupal.org Terms of Service and Privacy Policy. We are going to implement a checkbox on user profiles, so that users could accept the ToS and Privacy Policy, as well as a few other changes.

Previous deployments

Some of the deployments, which happened in the previous two weeks, include:

Thanks to Steven Jones, mallezie, LewisNyman, fizk and jhodgdon for working with us on the issues listed above and making those deployments possible.

Drupal.org infrastructure news

The load balancers are being rebuilt with a new operating system and configuration. These rebuilds bring decreased latency and increased security to our *.drupal.org sites. Since the beginning of August our average latency has decreased from ~1000ms to ~400ms.

More statistics are available from status.devdrupal.org.

Drupal.org web servers have also been upgraded to a 3.14 kernel with the latest grsecurity patch.

There has also been a review of cache values on drupal.org sites.

---
As always, we’d like to say thanks to all volunteers who are working with us and to the Drupal Association Supporters, who made it possible for us to work on these projects.

Cross-posting from g.d.o/drupalorg.

Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Personal blog tags: week notes
Catégories: Elsewhere

Gunnar Wolf: Ongoing crypto handling discussions

Planet Debian - jeu, 28/08/2014 - 17:04

I love to see there is a lot of crypto discussions going on at DebConf. Maybe I'm skewed by my role as keyring-maint, but I have been involved in more than one discussion every day on what do/should signatures mean, on best key handling practices, on some ideas to make key maintenance better, on how the OpenPGPv4 format lays out a key and its components on disk, all that. I enjoy some of those discussions pose questions that leave me thinking, as I am quite far from having all answers.

Discussions should be had face to face, but some start online and deserve to be answered online (and also pose opportunity to become documentation). Simon Josefsson blogs about The case for short OpenPGP key validity periods. This will be an important issue to tackle, as we will soon require keys in the Debian keyring to have a set expiration date (surprise surprise!) and I agree with Simon, setting an expiration date far in the future means very little.

There is a caveat with using, as he suggests, very short expiry periods: We have a human factor sitting in the middle. Keyring updates in Debian are done approximately once a month, and I do not see the period shortening. That means, only once a month we (currently Jonathan McDowell and myself, and we expect to add Daniel Kahn Gillmor soon) take the full changeset and compile a new keyring that replaces the active one in Debian.

This means that if you have, as Simon suggests, a 100-day validity key, you have to remember to update it at least every 70 days, or you might be locked out during the days it takes us to process it.

I set my expiration period to two years, although I might shorten it to only one. I expect to add checks+notifications before we enable this requirement project-wide (so that Debian servers will mail you when your key is close to expiry); I think that mail can be sent at approximately [expiry date - 90 days] to give you time both to you and to us to act. Probably the optimal expiration periods under such conditions would be between 180 and 365 days.

But, yes, this is by far not yet a ruling, but a point in the discussion. We still have some days of DebConf, and I'll enjoy revising this point. And Simon, even if we correct some bits for these details, I'd like to have your permission to use this fine blog post as part of our documentation!

(And on completely unrelated news: Congratulations to our dear and very much missed friend Bubulle for completely losing his sanity and running for 28 hours and a half straight! He briefly describes this adventure when it was about to start, and we all want him to tell us how it was. Mr. Running French Guy, you are amazing!)

Catégories: Elsewhere

Lior Kaplan: The importance of close integration between distribution and upstream

Planet Debian - jeu, 28/08/2014 - 16:22

Many package maintainers need to decide when to upload a new version to Debian. Should the upload be done only after the official release, or is there a place for uploads during the development process. In the latter case there’s a need to balance between the benefit of early testing and feedback with the stability and not completely breaking user’s environment (and package relationships) too often.

With the coming PHP 5.6.0 release, Debian kept being on the cutting edge. Thanks to Ondřej, the new version was available in experimental since alpha1 and in unstable/testing since beta3. Considering the timing of the PHP release related to the Debian freeze, I’m happy we started early, and did the transition to PHP 5.6 a few months ago.

But just following the development releases (betas ,RCs) isn’t enough. Both Ondřej and myself are part of the PHP community, and know the planned timelines, current status and what are the critical points. Such knowledge was very useful this week, when we new 5.6.0 was pending finale tagging before release (after RC4). This made take the report of Debian bug #759381: “php5: TLS connections broken in 5.6.0 RC4″ seriously and contact the release managers.

First it was a “heads up” and then a real problem. After a quick discussion (both private mails by me and on github by Ondřej), the relevant commit was reverted by the release managers (Julien Pauli & Ferenc Kovacs), and 5.6.0 was retagged. The issue will get more checks towards 5.6.1 without any time pressure.

Although 5.6.0 isn’t in production for anyone (yet), and like any major release can have issues, the close connectivity between everyone saved complaints from the PHP users and ecosystem. I don’t imagine the issue been sorted so quickly 16 hours later. This is also due to the bug been reported on difference between two close release (regression in RC4 comparing to RC3).

To close the loop, if we’ve uploaded 5.6.0 only after the release, the report would be regression between 5.5.x and 5.6.0, which is obviously much harder to pinpoint. So, I’m not sure I have a good answer for the question in the beginning of the post, but for this case our policy proved itself.


Filed under: Debian GNU/Linux, PHP
Catégories: Elsewhere

Tim Retout: Pump.io update 1

Planet Debian - jeu, 28/08/2014 - 15:59

[The story so far: I'm packaging pump.io for Debian.]

4 packages uploaded to NEW:
  • node-webfinger
  • validator.js
  • websocket-driver
  • node-openid
2 packages eliminated as not needed:
  • set-immediate - deprecated
  • crypto-cacerts - not needed on Debian
1 package in progress:
  • node-databank
Got my eye on:
  • oauth-evanp - this is a fork with two patches, so I need to investigate the status of those.
  • node-iconv-lite - needs files downloaded from the internet, so I'm considering how to add them to the source package
  • dateformat/moment - there's an open discussion about combining Node.js modules, and I'm wondering if these are affected.
Thoughts

Currently I'm averaging around one package upload a day, I think? Which would mean ~1 month to go? But there may be challenges around getting packages through the NEW queue in time to build-depend on them.

Someone has asked my temporary Twitter account whether I have a pump.io account. Technically, yes, I do - but I don't post anything on it, because I want to run my own server in the long term. As part of running my own server, I always find that easier if I'm installing software from Debian packages. Hence this work. Sledgehammer, meet nut.

Catégories: Elsewhere

DrupalCon Amsterdam: Get a status update on Drupal 8 Contribution Modules at DrupalCon Amsterdam

Planet Drupal - jeu, 28/08/2014 - 11:33

Drupal 8 is slowly approaching. As we all know, the real power in version upgrades lies in the contribution modules. Most of the maintainers are already working on their Drupal 8 ports, but what is their status?

While we would like to give every one of these maintainers their own full session to discuss their modules, they are unfortunately only so many slots available. Not to mention it would take a long time for you to attend all of these talks on top of the various other conference sessions!

Therefore, in order to update the community on the major modules, I have coordinated a double session where each maintainer will present their module’s status. The presentations will be short and focused, freeing you up to enjoy other great conference content.

We will hear about the following modules:

  • Webform (by quicksketch)
  • Rules (by dasjo)
  • Display Suite (by aspilicious)
  • Media (by daveried/slashrsm)
  • Search API (by drunken monkey)
  • Commerce (by bojanz)
  • Redirect, Global Redirect, Token, Pathauto (by berdir)
  • Panels (by populist)
  • Simplenews (by miro_dietiker/ifux)

The session will take place on Tuesday, September 30th from 14:15 - 16:45 (this is two session slots) in the Keynote Auditorium (Wunderkraut Room).

More information

Join us to learn directly from the maintainers what to expect of their Drupal 8 Modules!

--
Michael Schmid (Schnitzel)
DrupalCon Amsterdam Site Building Track Chair

Catégories: Elsewhere

LevelTen Interactive: Become a ColourLover

Planet Drupal - jeu, 28/08/2014 - 07:00

It’s easy to underestimate the impact of web design on business. The look and feel of a site not only communicates the personality of an organization, but it impacts the company’s perceived credibility. Great design provides the right visual experience for the target audience to meet goals and objectives.... Read more

Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur - Elsewhere