Feed aggregator

Drupal core announcements: Drupal 7 core release on Wednesday, January 1 (or Thursday, January 2)

Planet Drupal - Tue, 31/12/2013 - 04:51
Start:  2014-01-01 (All day) - 2014-01-02 (All day) America/New_York Sprint Organizers:  David_Rothstein

The monthly Drupal core bug fix release window is this Wednesday, and since it has been a while since the last one, I plan to release Drupal 7.25 on that date. However, in practice the release might not happen until Thursday, due to the holiday and to give people a bit more time to test the latest code. Per our release policy, this will be a bug fix release only (no security fixes).

The final patches for 7.25 have been committed and the code is frozen (excluding documentation fixes and fixes for any regressions that may be found in the next couple days). So, now is a wonderful time to update your development/staging servers to the latest 7.x code and help us catch any regressions in advance.

The relevant change records for Drupal 7.25 are listed below. This is not the full list of changes, rather only a list of notable API additions and data structure changes that might affect a number of other modules, so it's a good place to start looking for any problems:

You might also be interested in the tentative CHANGELOG.txt for Drupal 7.25 and the corresponding list of important issues that will be highlighted in the Drupal 7.25 release notes.

If you do find any regressions, please report them in the issue queue. Thanks!

Upcoming release windows after this week include:

  • Wednesday, January 15 (security release window)
  • Wednesday, February 5 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Elsewhere

Configuration Management Initiative: Upcoming CMI Meetings

Planet Drupal - Tue, 31/12/2013 - 02:33

Contrary to popular belief, the Drupal 8 Configuration Management Initiative (CMI) is not done. In fact, there is still a fair amount of work remaining. To help get some momentum, we are going to start holding CMI IRC meetings in #drupal-cmi every other Monday at 20:00 UTC (3pm Eastern). Our next IRC meeting will be Monday, January 13 at 20:00 UTC. Additional meetings will be on January 27, February 10, 24, etc. All of the Drupal 8 initiative meetings, including the CMI meetings, are listed on the calendar on Drupal 8 Updates and How to Help.

Anyone who is interested in helping to get Drupal 8 closer to having a working configuration system is welcome to join the IRC meetings. That said, we have a lot of complex problems to solve. While it would certainly be helpful to check out the the issues listed under the tabs above (Focus Issues, Beta Blocker, Novice Issues, etc.) our most important issues at the moment are listed on the meta issue Making configuration synchronisation work.

Categories: Elsewhere

Russ Allbery: Init system evaluation thanks

Planet Debian - Tue, 31/12/2013 - 00:17

Most people who follow Debian are probably aware that we're currently in the middle of a major debate over the future of Debian's init system. Over the past month, and particularly over the past week, I undertook an evaluation of two of the options in that debate, using one of my packages as a test bed. I also did a lot of reading, filed a few bugs, and asked a bunch of questions. That's an extension of the questions I've been asking and discussions I've been participating in around init systems for the past year plus.

I have been keeping my opinions and writeups confined to the relevant Techncial Committee bug report so that they can be read in context with their rebuttals. There are a lot of thoughtful and well-informed opinions here, of which mine are only one, and several of my conclusions have been inaccurate or at least not complete, so the context is important. You can find the full traffic in the Technical Committee bug. Most of the discussion, in a threaded view, is in the Technical Committee archives for December.

However, in one of the messages I sent today, I tried to show my appreciation for the people who have assisted with this evaluation over the past week, month, and years, and I think that section deserves broader distribution outside of the ongoing discussion. It is therefore included below.

Throughout this evaluation process, my interactions with upstart and systemd upstream developers and Debian packagers have been uniformly excellent. Bug reports filed against both systemd and upstart have received excellent and timely response, and all involved have been quite willing to explain things I've misunderstood, correct my false starts, and discuss technical and practical aspects of their designs.

I was particularly impressed by the clear effort that the systemd and upstart maintainers in Debian have put into fully integrating their init systems in such a way that makes them easy to test and use with existing Debian packages. This includes but is not limited to update-rc.d support, invoke-rc.d support, status synchronization with sysvinit, past Policy discussion, and attention to upgrade paths and init-switching use cases.

I also want to particularly thank the OpenRC upstream development team for their involvement in this process and their contributions to the discussion. I personally don't think that package is a good match for Debian's needs on Linux, but that's through no fault of the people involved, and I think they would be an excellent upstream if that package looked like a good fit for the needs of any of Debian's non-Linux ports.

I also want to thank Petter Reinholdtsen, Roger Leigh, and everyone else who has worked on the sysvinit package over the years, the insserv conversion to dependency-based boot, and the inclusion of LSB support. If it weren't for their hard work, we would be in a far worse position than we are today. It's often hard to see people discussing the inadequacies of something into which you put years of hard work. I want to call attention to their long-term contributions to the distribution, and to the number of Debian systems that have booted through their efforts over the years.

Categories: Elsewhere

Carl Chenet: Virtual environments with Python 3.3

Planet Debian - Mon, 30/12/2013 - 23:00

Follow me on Identi.ca  or Twitter 

One of the major features of Python 3.3 is the new venv module, allowing the creation of Python virtual environments on your system.

1. What is a virtual environment?

A virtual environment is a directory dedicated to the execution of your Python applications. Activating your virtual environment will force Python to execute in this directory as the top level of this directory was the root of your file system.

The virtual environments are interesting because of the independence they have toward the host they run on, especially when you want to install several versions of Python or if you want to install lots of dependencies without being the system administrator of the host.

If you are a Python developer, you must know virtualenv. This really nice application offers a nice way to create Python virtual environment. Moreover it comes with pip already installed in your virtual environment, in order to install other dependencies you need in a really convenience way.

Starting from Python 3.3, the module venv of the Python standard library offers the users to create virtual environments. This new feature will encourage all users to create virtual environments to develop their own Python applications, which is a good practice. Thanks to the experiences of several applications being used in the Python community, the module venv was written to be really efficient and widely available.

The Python Enhancement Proposal 405 (PEP405) offers a really interesting reading if you wish to find more information about this topic.

2. Creating a virtual environment with Python 3.3

With Python 3.3 comes pyvenv-3.3, allowing to create Python virtual environment:

$ pyvenv-3.3 myvirtualenv $ cd myvirtualenv/ $ tree . . ├── bin │   ├── activate │   ├── pydoc │   ├── python -> python3.3 │   ├── python3 -> python3.3 │   └── python3.3 -> /usr/bin/python3.3 ├── include ├── lib │   └── python3.3 │   └── site-packages └── pyvenv.cfg

As we can see, three directories were created.

  • bin/ offers the activate script and different links to the executable python3.3
  • lib/ offers a tree of directories where the libraries and packages you install in your virtual environment will be stored
  • include/ is by default empty
  • pyvenv.cfg offers different configuration options
$ cat pyvenv.cfg home = /usr/bin include-system-site-packages = false version = 3.3.2

Just before moving on, if you want to use the existing modules in your global site-packages directory on your system, the option –system-site-packages is available.

3. Activate the virtual environment

Lets activate our virtual environment. We need to use the bin/activate file in this environment:

$ source bin/activate  (myvirtualenv) $

A change in our prompt indicated the good activation of the virtual environment.

4. Installing applications in the virtual environment

But playing around with only the default Python interpreter is not really funny. Lets download pip, the Python installer, but before that we need a dependency setuptools:

(myvirtualenv) $ curl https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py -o ez_setup.py % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 11356 100 11356 0 0 18507 0 --:--:-- --:--:-- --:--:-- 18495 (myvirtualenv) $ curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py -o get-pip.py % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 543k 100 543k 0 0 685k 0 --:--:-- --:--:-- --:--:-- 685k

Now lets install Setuptools and Pip:

(myvirtualenv) $ python3.3 ez_setup.py Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-2.0.tar.gz Extracting in /tmp/tmpxlrv7q Now working in /tmp/tmpxlrv7q/setuptools-2.0 Installing Setuptools ... (lots of lines)... Installed /tmp/myvirtualenv/lib/python3.3/site-packages/setuptools-2.0-py3.3.egg Processing dependencies for setuptools==2.0 Finished processing dependencies for setuptools==2.0 (myvirtualenv) $ python3.3 get-pip.py Downloading/unpacking pip Downloading pip-1.4.1.tar.gz (445kB): 445kB downloaded Running setup.py egg_info for package pip ... (lots of lines)... Successfully installed pip Cleaning up...

Ok now we’re ready to use pip to install anything we need in our virtual environment. Lets think one more second about what we did: we install the Setuptools and the Pip application inside our virtual environment, with nothing written on our main system. Now lets try to install Brebis, the fully automated backup checker, and run it in this environment:

(myvirtualenv) $ pip-3.3 install brebis Downloading/unpacking brebis Downloading brebis-0.8.tar.gz Running setup.py egg_info for package brebis Installing collected packages: brebis Running setup.py install for brebis changing mode of build/scripts-3.3/brebis from 644 to 755 changing mode of /tmp/myvirtualenv/bin/brebis to 755 Successfully installed brebis Cleaning up...

We’re now ready to launch Brebis, executing in our virtual environment:

(myvirtualenv) $ brebis -h usage: brebis [-h] [-c DIR] [-C DIR] [-d DELIMITER] [-g] [-G] [-l FILE] [-L DIR] [-O DIR] [-v] Fully automated backup checker positional arguments: archives archives to check optional arguments: -h, --help show this help message and exit -c DIR, --configpath DIR the path to the configurations -C DIR, --output-conf-dir DIR the directory to store the configuration file -d DELIMITER, --delimiter DELIMITER delimiter of the fields for the list of files -g, --gen-list generate a list of files inside a backup -G, --gen-full generate the configuration file and the list of files for the backup -l FILE, --log FILE the log file -L DIR, --output-list-dir DIR the directory to store the list of files inside an archive or tree -O DIR, --output-list-and-conf-dir DIR the directory to store the configuration file and the list of files inside an archive or tree -v, --version print the version of this program and exit For more information: http://www.brebisproject.org

So we get an execution of the Brebis application inside our virtual environment, installed from our virtual environment with tools installed only in the virtual environment.

That’s a big step that such a feature is now included in the standard library. In the future, you will enjoy the possibility to create new virtual environments for each Python version right out of the box. Moreover, using the –upgrade option of the pyvenv command, you will upgrade, if needed, your virtual environment in a really easy and straightforward way, making environments adaptable in time.

What about you? What do you think about the Python 3 virtual environments and their features, given your own needs? Feel free to use the comments section of this post.

Categories: Elsewhere

Acquia: 2013 Greatest Hits – Gaelan Steele meets Dries

Planet Drupal - Mon, 30/12/2013 - 22:55

One of my favorite Drupal moments in 2013 was meeting Gaelan Steele in person at DrupalCon Portland. This was eclipsed very quickly by being present when Gaelan and Dries met for the first time - and having my podcast microphone on! This was probably also eclipsed by Gaelan schooling Dries on how he learned to use Drupal ... see his answer below and in the podcast.

Categories: Elsewhere

Lars Wirzenius: Thoughtful, inspiring words from Russ

Planet Debian - Mon, 30/12/2013 - 21:25

Russ Allbery has written up summaries of the research he's done in preparation of a Debian Technical Committee vote on default init system in Debian's next release. The mails are long, and well worth reading completely if the topic interests you at all, but I'd like to quote separately a few paragraphs that I found thoughtful, and inspiring, in the greater Debian context and not just for the init system discussion.

From "init system other points, and conclusion":

Here again, I think we have an opportunity for Debian to be more innovative and forward-looking in what we attempt to accomplish in the archive by adopting frameworks that let us incorporate the principles of least privilege and defense in depth into our standard daemon configurations.

And later, from the same mail:

I think we should make wise decisions about which areas we want to invest project effort. I dislike investing significant project effort in catch-up efforts that, when complete, merely get us back to where we would have been if we'd chosen a different solution. I don't think that's wise stewardship of project resources. I want to see Debian focus its efforts on places where we can make a real difference, where we can be leaders. That means adopting the best-of-breed existing solutions and building on top of them, not reinventing wheels and thereby starting from a trailing position.

From "loose ends for init system decision":

It is not, in general, necessary to justify what you want to do in Debian. It doesn't matter if it's going to be used by thousands of people or two people. If you can do your work to the standards that we expect to be maintained across the archive, and without negative impact on Debian's other contributors, you can work on whatever you love. And, furthermore, we all support each other in our passions. Debian is built on a culture of deference to other people's work, and reasonable accomodation to the projects that other people want to work on.

Now, there is a fine balance here. Deference to other people's work does not mean a requirement to join their work. Reasonable accomodation does not mean that every Debian developer is required to test their software on non-Linux ports. The goal is that all of us should be empowered to work on the things we are passionate about, which implicitly includes being empowered to not work on the things that are not of interest to us. Therefore, for some efforts, and specifically for the non-Linux port efforts, the work is mostly born by the porters. They're expected to test, diagnose problems, and submit patches. The deference and reasonable accomodation that we expect of Debian contributors is to merge those patches when they are reasonable, to not undermine the porting effort when there is a reasonable approach that preserves it, and to be aware of the implications of their packaging for those ports in the broad sense (such as qualifying build-dependencies with [linux-any] where appropriate).

We do not expect Debian contributors to reject significant new upstream versions or significant new integrations because they will affect the non-Linux ports, or, for that matter, other projects in Debian. We do expect those changes to follow the standards that we expect of Debian as a whole, and that porting efforts will be treated with deference and reasonable accomodation.

I won't offer a comment on these quotes—I prefer to let them speak for themselves—but I will say I find these to be among the wisest things said within Debian all year.

Categories: Elsewhere

Friendly Machine: Omega vs. Zen - Which Base Theme Should You Choose?

Planet Drupal - Mon, 30/12/2013 - 18:23

If you’ve been reading my posts for a while, you’ll know that I’m a fan of the Omega base theme and have used it in many of my projects. As I’ve gotten more familiar with it, I’ve noticed it bears a striking resemblance to the latest release of Zen.

For those of you not familiar with Drupal base themes, Zen has long been the most popular. I thought I’d take a look at the two of these themes and see how they really match up and which one might be the better choice for a given project.

Big Changes to Omega

First things first - Omega 4 bears only a passing resemblance to Omega 3. It’s essentially a complete re-write (see my overview) and the changes may be jarring for those who’ve become familiar with Omega 3’s UI layout tools.

Those tools are long gone. As I noted above, what you have with Omega 4 is something strikingly similar to Zen in almost every way. Much of this has to do with both maintainers adhering to emerging best practices in front end development, but it's also due to choice of tools.

Feature Comparison

Below is a table that shows some of the features of both Zen and Omega.

Feature Omega Zen  HTML5 Yes Yes  Sass + Compass Yes Yes  Swappable layouts Yes Yes  Default grids Susy Zen Grids  Drush support Yes Yes  IE conditional classes Yes Yes  Mobile first Yes Yes  HTML5 shiv, Respond.js Yes Yes

Quite a bit of overlap wouldn’t you say? Having worked with both themes, I can tell you it’s pretty easy jumping back and forth between them. Conceptually, they are essentially the same, with only minor differences in implementation.

One thing that sticks out to me is that both are very flexible. You can create an Omega sub-theme using Zen Grids, for example. Likewise you can create a Zen sub-theme using Omega’s default grid system, Susy.

The SMACSS approach to modular CSS makes it a snap to move some of your boilerplate styles between themes. They’re both put together in a really smart way and offer big improvements over previous approaches to theme development.

And of course, both use Sass + Compass, which seems to be preferred over LESS among Drupal developers.

One Difference Between Zen and Omega

We see that the two of these base themes have a lot in common, but in what ways are they different? Well, one difference seems to stem from the choice of default grid system.

Omega 4 uses Susy, and from what I understand, it has frequent updates that may break backward compatibility. This means you’ll need to keep careful track of your Gem versions, particularly when working in a team, if you want your Sass to compile correctly. The maintainer of Omega has explained how to set things up in this comment.

I suppose it could be argued that what he’s describing is a best practice generally, but will most people go through all of that? My experience tells me no. It really seems like a potential trouble spot, but I’m not sure. Perhaps Omega 4 hasn’t been around long enough to hear of missing Gemfiles causing issues - maybe it won’t be a problem at all.

That said, the “ideal set up” is a point of difference. With Zen you can get started with less hassle. Does this mean Zen is better than Omega? I don’t think so. For some, this will fit right in with the way they are already working.

The Big Difference

The biggest difference between the two base themes is Omega’s inclusion of layouts. These are predefined, Panels-style layouts that can be used with the Context Omega module to apply layouts to specific pages, content types or whatever other condition you may require.

These layouts can also be used with Panels Everywhere. In fact, the Omega layouts will appear in Panels when you have both Omega and Panels installed. Keep in mind, however, you can’t use these with vanilla Panels - only with Panels Everywhere. This is because Omega 4 layouts are variations on page.tpl.php and therefore control the entire layout of the page rather than just the node.

Sebastian Siemsen, the co-maintainer of Omega, did a long screencast on how to use Omega 4, including strategies for use with Panels for those that are interested.

So Which Is Better?

Of course the answer here is, “it depends”. If you like building sites with Panels Everywhere, then Omega 4 might have the edge. If you don’t like the development set up of Omega 4, then Zen might be a better choice. Another thing in Zen's favor is far superior documentation.

However, I think the truth is that it hardly matters which of these two you choose. Personally, I use both and I think that’s rather a good thing. It allows me to easily switch between them depending on the requirements of a given project.

If you have any comments on this post, you may politely leave them below.

Categories: Elsewhere

Raphaël Hertzog: The Debian Wheezy Handbook is now available

Planet Debian - Mon, 30/12/2013 - 16:59

After multiple months of hard work, I’m pleased to announce that Roland and I finished updating the Debian Administrator’s Handbook for Debian Wheezy.

Grab it now!

By the way, as part of the launch of this updated edition, you can benefit from a 10% discount on any paperback copy ordered before January 9th 2014. Just click here and place your order.

We have put lots of hard work on this edition, doing quite some janitorial work. We didn’t cover as many new topics as I would have liked, but I’m still proud of the end result.

The book has a nice preface co-signed by the current and former Debian Project Leaders. Let me quote a short extract:

The book you have in your hands is different. It’s a free as in freedom book, a book which is up to Debian freedom standards for every aspects of your digital life. […] You can apt-get install this book, you can redistribute it, you can fork this book or, better, submit bug reports and patches for it, so that other in the future can benefit from your contributions. The “maintainers” of this book — who are also its authors — are longstanding members of the Debian Project, who grok the freedom ethos that permeates every aspect of Debian.

Enjoy it and share your comments! Even better if you write up a review that we can link from the website.

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

Categories: Elsewhere

TimOnWeb.com: Let's Drup Up The Week. Issue 13

Planet Drupal - Mon, 30/12/2013 - 13:44

This is the 13th issue of the weekly Drupal news round-up and the last one in the year 2013. The last week was pretty silent and it was hard to find something interesting, but in the end I've managed to dig some Drupal gold for you. Today will be no dessert, because of the sad events happening in my country of origin.

Wish you all a Happy New Year! Be healthy and happy, the rest is not so important. Let's Drup Up The Week!

Read on about Let's Drup Up The Week. Issue 13
Categories: Elsewhere

Wunderkraut blog: Weldir, a Wunderkraut Flavoured theme for Ægir

Planet Drupal - Mon, 30/12/2013 - 13:26

We have created an Eldir sub-theme that adds a Wunderkraut flavour and some other tweaks which make the Ægir UI more friendly and tasty.

Here at Wunderkraut Benelux, we love Ægir. We use to manage some aspects of our development, staging and production environments.

Since we often provide access, documentation, etc to our internal and external clients, we have created an Eldir sub-theme that adds a Wunderkraut flavour and some other tweaks which make the Ægir UI more friendly and tasty.


Weldir, as we've named the theme, builds on the Eldir theme and adds a few things we felt that were missing; buttoned pagers, a better footer position, some breathing room, and so on. Since we also document stuff in Ægir, we've added styling which can be used on links to create in-content buttons - call-to-actions if you will, to spruce up content and draw attention where needed. Simply add the button class to your link.

Weldir is available on GitHub. We hope it provides you with an alternative theme for this great tool.

Categories: Elsewhere

Janez Urevc: HHVM and Drupal (i.e. Drupal drinks some RedBull)

Planet Drupal - Mon, 30/12/2013 - 12:27

I've been following HHVM (HipHop Virtual machine) for some time now. Project got a bit more of my attention about a year ago, after session at FOSDEM 2013 by Sara Golemon. PHP has been criticized for quite a lot of it's characteristics, performance definitely being one of those. HHVM seemed to be very promising about fixing it and that's why it got my attention in the first place. Immediately after last year's FOSDEM I tried it with Drupal, but my attempt unfortunately failed miserably. HHVM was simply not yet ready for that.

But first a bit of history...

HipHop was initially developed by Facebook (and they are still it's main contributor). Facebook was looking for something that would make their PHP code base perform faster while still retaining benefits that PHP brings (primarily ease of use for developers). Initially they created a compiler (HPHPc) that transformed a PHP script into a C++ program, which was then compiled into a binary. This approach showed dramatic increase in performance, but also had some problems. HPHPc did not fully support PHP language and was not a simple drop-in replacement for "standard" (Zend) PHP.

Facebook decided to deprecate HPHPc, start working on a bit different approach and HHVM was born. HHVM is a Just-in-time compiler (JIT) for PHP. It behaves very similar to standard interpreter when observed from the outside (which means it can be a drop-in replacement for it), but it works quite different internally. It will run a program as an interpreter at the beginning of execution, collect some statistics for optimization and eventually compile it to byte code on the fly. Compiled program will then run much faster than it's interpreted version. It is quite obvious that we get true performance gains with applications that run for a longer period of time (because of initial interpretation phase and on-the-fly compilation). A standard web (Drupal) application, which is deployed to production servers from time to time, is exactly what we're looking for.

Categories: Elsewhere

Christian Perrier: [running] New about my injury

Planet Debian - Mon, 30/12/2013 - 06:30
Latest news about my recent injury after last race: the fatigue fracture wasreally a small oneandis notvisible on radiography, even after 3 weeks.

I'm waiting for the sports doctor advice next week before resuming running...or still wait for a few weeks and still stick to mountain biking. I can tell that not running for more than a few days is really frustrating, particularly when visiting my relatives in St-Etienne, where there are moutains and great trails.

Categories: Elsewhere

Olivier Berger: Touchpad side scrolling enabling in gnome flashback

Planet Debian - Sun, 29/12/2013 - 22:10

For whatever reason, the touchpad right edge would no longer allow me to do scrolling (like the usual middle wheel on the mouse) under the gnome flashback session in Debian testing.

Here's a way to make it work : http://askubuntu.com/questions/248290/enable-both-edge-scrolling-and-two-finger-scrolling-for-touchpad/373134#373134 .

This post provides a more elaborate script : http://who-t.blogspot.fr/2011/03/custom-input-device-configuration-in.html reusing an example script (in Debian, in /usr/share/doc/gnome-settings-daemon/examples/input-device-example.sh), but attention: it may be invoked twice, if like on my system, once for an "AlpsPS/2 ALPS GlidePoint" and then for a "PS/2 Mouse", but resetting the VertEdgeScroll to 0 in between.

So the script looks like that on my system, now :

... if [ "$device" = "AlpsPS/2 ALPS GlidePoint" -o "$device" = "PS/2 Mouse" ]; then synclient VertEdgeScroll=1 fi

I guess there's some kind of a bug here... but the gnome session is a hell when needing to spot the culprit package to report to, so for once, I'll let reportbug quiet.

Hope this helps

Categories: Elsewhere

Joachim Breitner: Sim Serim as a browser game

Planet Debian - Sun, 29/12/2013 - 22:08

Recently, I gave the very elegant board game “Sim Serim” away as a present, without actually playing it, leaving me curious about the game. One can easily play it on paper (you just need a paper, and 4 tokens like coins for each player, BoardGameGeek has English rules the of game), but I took this as an opportunity to learn more about HTML5 canvas and nodejs, and so I created the browser game “Sum Serum”, implementing the game mechanics of “Sim Serim”. You can play it locally with two people, or over the network. Contributions are welcome! Especially slicker graphics...

In other news, given that in recent years I became one, I’m on BoardGameGeek myself now, see my profile there.

Categories: Elsewhere

Cheppers blog: Global Sprint Weekend January 25 and 26 2014

Planet Drupal - Sun, 29/12/2013 - 18:40

Global Sprint Weekend is a worldwide event you can participate in. Small local sprints in lots of locations, over the same time period: Saturday and Sunday January 25 and 26, 2014. These sprints will usually be 2-15 people in one location, together, working to make Drupal better.

You can make your own locations if no location is near you! Currently people have announced locations in Sevilla Spain; Berlin, Mannheim and Schwerin Germany; Ghent Belgium; Budapest Hungary (hosted at Cheppers and led by Gábor Hojtsy); Manchester UK; Vancouver, London (Ontario) and Montréal Canada; Oak Park, Chicago, Milwaukee, Boston, Minneapolis and Austin USA.

Categories: Elsewhere

Hideki Yamane: creating Ubuntu chroot becomes easier - ubuntu-archive-keyring package in Debian

Planet Debian - Sun, 29/12/2013 - 17:24
Hi, I've just uploaded ubuntu-keyring source package to Debian (its RFP was posted in 26th Dec 2007 - wow 6 years ago) and it was accepted quickly (thanks to ftpmasters :-)

If you're using Debian as primary environment and need to rebuild package for Ubuntu, you'd create Ubuntu pbuilder/cowbuilder/chroot environment on your box. But you'll get an error as below.
henrich@hp:~ $ sudo cowbuilder --create --distribution saucy --mirror http://archive.ubuntu.com/ubuntu --basepath /var/cache/pbuilder/saucy
 -> Invoking pbuilder
  forking: pbuilder create --buildplace /var/cache/pbuilder/saucy --mirror http://archive.ubuntu.com/ubuntu --distribution saucy --no-targz --extrapackages cowdancer
I: Running in no-targz mode
I: Distribution is saucy.
I: Current time: Mon Dec 30 01:00:05 JST 2013
I: pbuilder-time-stamp: 1388332805
I: Building the build environment
I: running debootstrap
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
E: Release signed by unknown key (key id 3B4FE6ACC0B21F32)
E: debootstrap failed
W: Aborting with an error
pbuilder create failed
  forking: rm -rf /var/cache/pbuilder/saucy 
"E: Release signed by unknown key (key id 3B4FE6ACC0B21F32)", because your system doesn't know about Ubuntu release key. Okay, then "$ sudo apt-get install ubuntu-archive-keyring" and add "--debootstrapopts "--keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg"" option to cowbuilder.
henrich@hp:~ $ sudo cowbuilder --create --distribution saucy --mirror http://archive.ubuntu.com/ubuntu --basepath /var/cache/pbuilder/saucy --debootstrapopts "--keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg"
 -> Invoking pbuilder
  forking: pbuilder create --debootstrapopts --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg --buildplace /var/cache/pbuilder/saucy --mirror http://archive.ubuntu.com/ubuntu --distribution saucy --no-targz --extrapackages cowdancer
I: Running in no-targz mode
I: Distribution is saucy.
I: Current time: Mon Dec 30 01:06:30 JST 2013
I: pbuilder-time-stamp: 1388333190
I: Building the build environment
I: running debootstrap
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 790BC7277767219C42C86F933B4FE6ACC0B21F32)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://archive.ubuntu.com/ubuntu...
I: Retrieving apt
I: Validating apt
I: Retrieving base-files 6.12ubuntu4
(snip)Good :)

note: Just add "--keyring" option (--keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg) doesn't work as expected, bug?

difference with ubuntu-keyring package in Ubuntu

  • Binary package name is "ubuntu-archive-keyring", not "ubuntu-keyring". It's better to use "foobar-archive-keyring" for packages, same as debian-archive-keyring.
  • No udebs. Probably we don't need it.

Categories: Elsewhere

Steve Kemp: A good week?

Planet Debian - Sun, 29/12/2013 - 15:59

This week my small collection of sysadmin tools received a lot of attention; I've no idea what triggered it, but it ended up on the front-page of github as a "trending repository".

Otherwise I've recently spent some time "playing about" with some security stuff. My first recent report wasn't deemed worthy of a security update, but it was still a fun one. From the package description rush is described as:

GNU Rush is a restricted shell designed for sites providing only limited access to resources for remote users. The main binary executable is configurable as a user login shell, intended for users that only are allowed remote login to the system at hand.

As the description says this is primarily intended for use by remote users, but if it is installed locally you can read "any file" on the local system.

How? Well the program is setuid(root) and allows you to specify an arbitrary configuration file as input. The very very first thing I tried to do with this program was feed it an invalid and unreadable-to-me configuration file.

Helpfully there is a debugging option you can add --lint to help you setup the software. Using it is as simple as:

shelob ~ $ rush --lint /etc/shadow rush: Info: /etc/shadow:1: unknown statement: root:$6$zwJQWKVo$ofoV2xwfsff...Mxo/:15884:0:99999:7::: rush: Info: /etc/shadow:2: unknown statement: daemon:*:15884:0:99999:7::: rush: Info: /etc/shadow:3: unknown statement: bin:*:15884:0:99999:7::: rush: Info: /etc/shadow:4: unknown statement: sys:*:15884:0:99999:7::: ..

How nice?

The only mitigating factor here is that only the first token on the line is reported - In this case we've exposed /etc/shadow which doesn't contain whitespace for the interesting users, so it's enough to start cracking those password hashes.

If you maintain a setuid binary you must be trying things like this.

If you maintain a setuid binary you must be confident in the codebase.

People will be happy to stress-test, audit, examine, and help you - just ask.

Simple security issues like this are frankly embarassing.

Anyway that's enough: #733505 / CVE-2013-6889.

Categories: Elsewhere

Hideki Yamane: kernel.org stops using bz2

Planet Debian - Sun, 29/12/2013 - 15:01
Many upstream provides their source as tar.xz format, and kernel.org also throw bz2 away - "Happy new year and good-bye bzip2".

Debian package (dpkg-deb) uses xz as default since 1.17.0 as I mentioned. If your package uses bz2, now it's a time to switch. And maybe it's good to ask upstream to switch from bzip2 to xz, too.
Categories: Elsewhere


Subscribe to jfhovinne aggregator