news aggregator

Robie Basak: New in Ubuntu 14.04 LTS: PHP 5.5

Planet Ubuntu - Thu, 2014-05-08 14:11

Ubuntu 14.04 LTS ships with PHP 5.5, which is a significant upgrade over PHP 5.3 as found in 12.04.

PHP 5.5 actually first appeared in 13.10, though of course if you intend to do an LTS to LTS upgrade, you won't notice this until now.

PHP upstream introduced some incompabilities in this update, and recommend testing before upgrading production environments. For more details, see the PHP migration guide.

Getting PHP

PHP 5.5 is available in the main Ubuntu repository for Trusty, so apt-get install php5-cli (or libapache2-mod-php5, etc) will suffice. Ondřej Surý, the primary Debian PHP maintainer, also maintains a series of PPAs on Launchpad if you need a different version. Taking a quick look at Ondřej's Launchpad page, I see:

Thanks to Ondřej for kindly taking the time to maintain these PPAs for the community.

Help Wanted

Ondřej Surý, the Debian maintainer of PHP, posted a request for help with PHP Debian packaging. If you are an available Debian developer or maintainer, please join him. Helping with Debian PHP packaging also helps Ubuntu, since Ubuntu's PHP packages are heavily based on Debian's work.

Upstream dissonance

There are a few areas in which multiple distributions (at least the Fedora and Debian families) patch PHP, but these patches have not been taken upstream. Perhaps I'm mistaken, but I believe that most PHP users consume PHP through a distribution, so it does not seem ideal that multiple distributions carry these patches instead of their changes being adopted in upstream directly. I'd love to see better collaboration with upstream in these areas so that these particular distribution patches become unnecessary.

I mention some of these differences here since the differences appear to have affected some Ubuntu users.

JSON module

PHP upstream ship a JSON module whose licence is not considered acceptable to distributions. This was reported and accepted in Debian bug 692613, and Fedora also concurs.

As a workaround, Remi Collet from Fedora removed the JSON module, but arranged to ship a PECL module that builds JSON from an external, API compatible source that is not based on the upstream that is licensed dubiously. Debian fixed the licensing problem by doing the same thing.

Ubuntu follows the Debian lead by default, so Trusty also ships without the upstream core PHP module. Instead, since Trusty, the php5-json module is automatically brought in as a dependency. Users will still see an API-compatible JSON module available; it is just an alternative implementation that is more acceptable to Debian (and to Fedora).

Note that there is a claim in bug 1287726 that there exist edge cases where behaviour has changed. This bug is waiting on a volunteer to fix behaviour in the alternative JSON implementation. It sounds like this other upstream would be happy to take the change. This is an unfortunate consequence of the situation, but at least there are no fundamental disagreements on how to fix this. It is "just a bug" with a simple technical solution; we just need an expert in the area to take a look and fix it.

Some background: the Debian Free Software Guidelines (DFSG) ensures that Debian is free to install and use by everyone, without restriction. Ubuntu is primarily based on Debian, so inherits this status. Much of the hard work to make this reality has been done by the Debian FTP masters who have painstakingly reviewed every package in Debian (and consequently most of the packages in Ubuntu) to ensure that this is the case. So all software shipped by Debian must comply with the DFSG, and the PHP JSON module does not meet this requirement.

The other side of this argument is that the PHP JSON module is too important to compromise quality over a petty licensing issue. Why can't distributions just ignore the nonsensical clause?

This issue has brought out many angry people on both sides of the debate, and there have been some flames over this. I would like to remind readers of the Ubuntu Code of Conduct:

Disagreements, social and technical, are normal, but we do not allow them to persist and fester leaving others uncertain of the agreed direction.

We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction.

In Ubuntu, we make decisions based on consensus, or (rarely) through leadership when necessary. Right now, Ubuntu has not specifically made any decision on this point. We are simply following Debian by default, which is what we do unless we have particular reason to diverge.

Please be constructive about this issue. Remember: Ubuntu is a community project, and we have a well defined path for making decisions. The appropriate avenues to make a change in Ubuntu on this point is to first try to achieve consensus (eg. on mailing lists), and failing that, to take the matter to the Ubuntu Technical Board.

More discussion can be found in the upstream bug and reddit thread.

Timezone handling

In a distribution, users expect to set a system setting once, and to have all applications to pick up that setting automatically. This includes, for example, the system timezone setting.

This principle also applies to system timezone updates. When daylight savings time rules change in some country or other, users expect to have these picked up in a single system update, and for all applications to immediately use this new data.

PHP upstream disagree on this point. PHP as shipped by upstream requires the system timezone to be manually set in php.ini. PHP also uses its own inbuilt timezone rule database, so users do not receive rule updates without also bumping the PHP version with a new upstream tarball.

So Fedora, Debian, Ubuntu (and others?) all patch PHP to make it use the system timezone setting and the system timezone database.

More information is available in a comment in Debian bug 618462.

As upstream releases changed, we had a couple of regressions in the past in bug 1069529 and bug 1244343. I managed to sort these out (and submitted patches to Debian also), so I think we now have this functionality properly nailed in Trusty.

As all distributions are carrying this patch (written originally by Remi Collet of Fedora, I think), it would be nice if upstream PHP could take this patch too. But my understanding based on the Debian bug above is that they are reluctant.

libgd

PHP includes a GD module, which provides an API to various graphics operations. PHP upstream bundle this library. But distributions prefer to use a single version of a library shipped separately, rather than using the versions shipped bundled inside upstreams.

The reasons for this are well documented in Fedora's No Bundled Libraries Policy and in Debian's Upstream Guide, so I won't repeat their justifications here.

In PHP's case, they effectively forked GD by adding functions that were not available upstream, and then made these functions available in the PHP GD API. Since distributions used the upstream GD library, this meant that PHP programs written against this API failed to work on PHP as shipped by distributions, since they used missing functions that were not available.

Bug 74647 contains the details. I believe this is a mostly solved problem now, as PHP upstream did focus on trying to get all of the required functions accepted in GD upstream. There is one report that there is one remaining function (imagerotate) that is still not available upstream, and thus not in distributions that ship PHP.

I am pleased to note that it does appear that upstream are working on the problem, so I hope that this issue will completely go away in a future release.

Thanks

Thanks to Ondřej Surý for his relentless effort in keeping PHP maintained in Debian, for monitoring PHP bugs in Ubuntu, and for maintaining PPAs for PHP in Ubuntu.

Getting help

As always, see Ubuntu's main page on community support options. askubuntu.com, #ubuntu-server on IRC (Freenode) and the Ubuntu Server mailing list are appropriate venues.

Ubuntu GNOME: Planning for Ubuntu GNOME Utopic Unicorn

Planet Ubuntu - Thu, 2014-05-08 10:38

Hello everyone,

After a very successful and long 6 months with Trusty Tahr Cycle, here comes another cycle and another 6 months of fun, hard work and more great and successful achievements to accomplish.

As with any start of any cycle, there is a planning phase, then a brainstorming phase and then the implementation phase.

The Planning Phase of Ubuntu GNOME Utopic Unicorn
Blueprints are done and we have the main roadmap for Ubuntu GNOME Utopic Unicorn with 7 blueprints for each Sub-Team and more to come whenever needed.

Ubuntu GNOME Utopic Unicorn Roadmap

  1. Artwork Roadmap
  2. Brainstorming Roadmap
  3. Marketing and Communications Roadmap
  4. Packaging Roadmap
  5. QA Roadmap
  6. Translations Roadmap
  7. Wiki and Documentation Roadmap

Above are the main Blueprints for Ubuntu GNOME Utopic Unicorn Cycle. There is one main roadmap of course which is the umbrella of all the other 7 main blueprints for each sub-team.

More blueprints will be added whenever needed and will be linked to one of the 7 blueprints, depending on the area these new blueprints will be created under. Example: if the new created blueprint will be related to Ubuntu GNOME Slideshow, this will be under Artwork Sub-Team and therefore, will be linked to: Ubuntu GNOME Artwork Roadmap for Utopic Unicorn.

The Brainstorming Phase of Ubuntu GNOME Utopic Unicorn
Ubuntu GNOME Team will start many meetings, one for each Sub-Team, in order to discuss the blueprints. Once these blueprints are discussed and approved, we shall start then the Implementation Phase.

The Implementation Phase of Ubuntu GNOME Utopic Unicorn
This phase obviously will be longest which will start right after the discussion and brainstorming phase. Planning Phase is done. Brainstorming Phase will start very soon right after publishing this post. It might take 1-2 weeks Maximum and then we shall start the Implementation Phase.

Each Sub-Team will have specific tasks to do. Our Team is more than ready to carry on with the great and amazing work we have always showed and we’re looking forward for yet another cycle of fun, team work, achievements and smiles on the faces of Ubuntu GNOME Users.

We promise that we shall never let you down. However, don’t expect to find/see ALL what you have in mind on Ubuntu GNOME 14.10 nothing is perfect as you know.. Yet, from your side, you can play a great role to help and support. That can be easily achieved and done by:

Joining Ubuntu GNOME and Getting Involved.

Thank you!

Ali/amjjawad
Head of Brainstorming and One of Ubuntu GNOME Leaders

Duncan McGreggor: LFE Design Summit

Planet Ubuntu - Wed, 2014-05-07 20:36
Well, maybe not summit, but certainly a meeting of minds :-)

The LFE Community is pleased to announce that we will be holding our first ever community design meeting in Stockholm, Sweden this June during the Erlang User Conference! We have set aside 1 hour for a kick-off discussion that we can continue in breakout sessions, hallways, meadhalls, in #erlang-lisp on Freenode, and on the LFE mail list

Our goals are to not only share plans, but to discover what you want in LFE, how you want to use it. This is an opportunity for us to work together, explore interesting problems to solve, build community awareness around language goals, and identify efforts around which each of us are interested in collaborating with others in the course of subsequent months.

We've opened up a Google Docs form so you can add your ideas for session topics. Here are some discussion topics that we've come up with so far:
  • LFE Standard Library 
  • Java Interop via Erjang 
  • State of LFE/LFE Roadmap 
  • Specs, Types, Debug Info and Dialyzer: Erlang Core AST in BEAM 
  • Refining LFE docs and guides, creating a CookBook, etc.
Add your favorites!
In the next couple weeks, we'll identify the top session topics the folks have proposed and attempt to cover these during the Erlang User Conference. Robert was able to get us some meeting space & time for this; he's hoping to have something viewable on the EUC site soon.
This is a fist step; let's see how this goes, and if people really enjoy it, we can have a real summit next time!


Daniel Pocock: A URI prefix for radio callsigns

Planet Ubuntu - Wed, 2014-05-07 20:16

I've had my amateur callsign far longer than I've had my email address or provider-indepent IP ranges.

While working with the tel: URI recently, I started thinking it would be useful to have a similar URI scheme for radio callsigns. After all, callsigns follow a well documented and globally unique pattern. Amateur operators are often mixing computing technology with radio. This could be a useful foundation for bigger things.

One possibility is in SIP. SIP already has the possibility to route messages using URIs other than sip:. For example, a SIP message can have a tel: URI in the request line. It could be equally feasible to do this for radio callsigns, especially for amateur radio.

Another possibility is placing call signs in HTML. Imagine if you could click M0GLR and some browser plugin looks up a directory to find out which frequencies or repeaters I've used recently.

From URI to URL

A URI typically identifies a resource. A URL helps locate the resource.

In radio, a URL would probably not be very similar to a HTTP scheme URL. A full URL for a radio contact might specify not just the callsign but also the desired frequency and transmission mode.

Instead of a directory path, it is likely you would need things like these as a bare minimum:

  • transmit frequency
  • receive frequence (or offset) if using a duplex mode
  • modulation (FM, SSB, etc)
  • bandwidth
  • mode: morse code, voice, video, packet data, etc

For a fixed station, especially a repeater, it may also be useful to encode the geographic location. For a station in orbit, however, it may be necessary to provide a completely different set of parameters describing the orbit or a pointer to where to find fresh parameters.

Please share your feedback

The idea is now actively under discussion on the IETF URI-review mailing list.

Kees Cook: Linux Security Summit 2014

Planet Ubuntu - Wed, 2014-05-07 18:31

The Linux Security Summit is happening in Chicago August 18th and 19th, just before LinuxCon. Send us some presentation and topic proposals, and join the conversation with other like-minded people. :)

I’d love to see what people have been working on, and what they’d like to work on. Our general topics will hopefully include:

  • System hardening
  • Access control
  • Cryptography
  • Integrity control
  • Hardware security
  • Networking
  • Storage
  • Virtualization
  • Desktop
  • Tools
  • Management
  • Case studies
  • Emerging technologies, threats & techniques

The Call For Participation closes June 6th, so you’ve got about a month, but earlier is better.

© 2014, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Pages

Subscribe to Free Software Magazine aggregator