Planet Debian

Subscribe to Planet Debian feed
Planet Debian - http://planet.debian.org/
Updated: 2 hours 51 min ago

Ben Armstrong: Eleventh hour upload of tuxpaint

27 October, 2014 - 01:51

I have just made an eleventh hour upload of tuxpaint, tuxpaint-config and tuxpaint-stamps. With luck, this will make it in time for the Nov. 5 Jessie freeze deadline so it goes in as an unassisted migration. Coming soon to a mirror near you!

Miriam Ruiz: Video game players and Gamers are different things

26 October, 2014 - 03:41

Even though the Wikipedia defines “gamer” as “someone who partakes in interactive gaming, such as (predominantly) video games or board games”, this doesn’t really gets close to that term means socially at the moment. Going back to Wikipedia, we find that the video game subculture is “a form of new media subculture that has been influenced by video games”, so it might be quite accurate to define gamers as members of that subculture. You will find that most of the uses of the term “gamer” in the social networks and in the blogosphere refer to that. Please notice that, even though it is quite likely that most of the gamers play video games, the other way round does not need to be true and, in fact, it isn’t. Not everyone who plays video games belongs to the video game subculture, shares their point of view, their values and aesthetics, or even know about it. Kind of like what happens with the word “hacker”. Not everyone who hacks around with a computer belongs to the hacker subculture.

Mostly everyone who has access to the technology plays video games now. From babies and kids to grandparents. And people play them in every possible technological system around, not only on video game consoles or personal computers, but alse on mobile phones, tablets, web browsers. And many of those people who use different kind of technologies to play video games are not gamers. Not in the sense of belonging to the video game subculture. It is important to acknowledge that: that the video game subculture does not have the monopoly over video games or the video game developing industry anymore.

As you can imagine, all this rand doesn’t come from nowhere. During the last months, we have been witnessing a fight between some conservative core members of the video game subculture and people who want to bring some fresh air into the sociocultural elements of that subculture. Namely, that women shouldn’t be discriminated inside it. As every time that a women raises her voice to complain about anything in the Internet, they have been subjected to insults, attacks, rape and death threats, etc. I’m talking about something called #GamerGate, and even though I’m not going to get into it, I will provide some URLs in case someone might be interested. Please acknowledge that not all the points of view might be represented in this list (in fact, they are not, as I won’t be promoting in my blog things that I severely disagree with), so search the web for more information if you want to get that.

I’ve never been a gamer myself, meaning part of the subculture I mentioned. At some point I was probably closer tho the core values they had then than I am now. In any case, video games have already consolidated themselves as an important part of current culture, entertainment, education and socialization, and are definitely here to stay. That will probably mean that the percentage of gamers (members of the video game subculture) will become smaller. as the number of non-gamer video game players keeps raising.

Jaldhar Vyas: Sal Mubarak 2071

25 October, 2014 - 12:12

Wishing all of you a happy Gujarati New Year (Vikram Samvat 2071 called Parabhava.)

May Lakshmi Mata protect you and your loved ones from poverty, misfortune, and systemd in the upcoming year.

Bálint Réczey: XBMC (from Debian) running on MIPS CI20 dev board

25 October, 2014 - 08:37

Imagination Tech kindly offered many developers (including me) a CI20 development board which let me play with XBMC on it a bit and patching it alive. The OpenGL GUI works smoothly, but video can’t be played due to crashes in FFmpeg/Libav/libva (I’ll submit the bug reports soon.).
The patches needed  are sent to upstream and the latest Debian package already ships them.

Big part of the credits go to Cory Fields who created the first MIPS patches I found and updated for latest XBMC code. Thanks!

Daniel Pocock: Positive results from Outreach Program for Women

25 October, 2014 - 07:53

In 2013, Debian participated in both rounds of the GNOME Outreach Program for Women (OPW). The first round was run in conjunction with GSoC and the second round was a standalone program.

The publicity around these programs and the strength of the Google and Debian brands attracted a range of female candidates, many of whom were shortlisted by mentors after passing their coding tests and satisfying us that they had the capability to complete a project successfully. As there are only a limited number of places for GSoC and limited funding for OPW, only a subset of these capable candidates were actually selected. The second round of OPW, for example, was only able to select two women.

Google to the rescue

Many of the women applying for the second round of OPW in 2013 were also students eligible for GSoC 2014. Debian was lucky to have over twenty places funded for GSoC 2014 and those women who had started preparing project plans for OPW and getting to know the Debian community were in a strong position to be considered for GSoC.

Chandrika Parimoo, who applied to Debian for the first round of OPW in 2013, was selected by the Ganglia project for one of five GSoC slots. Chandrika made contributions to PyNag and the ganglia-nagios-bridge.

Juliana Louback, who applied to Debian during the second round of OPW in 2013, was selected for one of Debian's GSoC 2014 slots working on the Debian WebRTC portal. The portal is built using JSCommunicator, a generic HTML5 softphone designed to be integrated in other web sites, portal frameworks and CMS systems.

Juliana has been particularly enthusiastic with her work and after completing the core requirements of her project, I suggested she explore just what is involved in embedding JSCommunicator into another open source application. By co-incidence, the xTuple development team had decided to dedicate the month of August to open source engagement, running a program called haxTuple. Juliana had originally applied to OPW with an interest in financial software and so this appeared to be a great opportunity for her to broaden her experience and engagement with the open source community.

Despite having no prior experience with ERP/CRM software, Juliana set about developing a plugin/extension for the new xTuple web frontend. She has published the extension in Github and written a detailed blog about her experience with the xTuple extension API.

Participation in DebConf14

Juliana attended DebConf14 in Portland and gave a presentation of her work on the Debian RTC portal. Many more people were able to try the portal for the first time thanks to her participation in DebConf. The video of the GSoC students at DebConf14 is available here.

Continuing with open source beyond GSoC

Although GSoC finished in August, xTuple invited Juliana and I to attend their annual xTupleCon in Norfolk, Virginia. Google went the extra mile and helped Juliana to get there and she gave a live demonstration of the xTuple extension she had created. This effort has simultaneously raised the profile of Debian, open source and open standards (SIP and WebRTC) in front of a wider audience of professional developers and business users.

It started with OPW

The key point to emphasize is that Juliana's work in GSoC was actually made possible by Debian's decision to participate in and promote Outreach Program for Women in 2013.

I've previously attended DebConf myself to help more developers become familiar with free and open RTC technology. I wasn't able to get there this year but thanks to the way GSoC and OPW are expanding our community, Juliana was there to help out.

Richard Hartmann: Release Critical Bug report for Week 43

25 October, 2014 - 03:52

Just a friendly reminder: If your package is not in unstable (and reasonably bug free) by Sunday, it's not in Jessie.

I am not doing full stats as I am unsure about the diff format at the moment, but in week 43, we had 284 bugs for Squeeze and 468 for Wheezy.

(282 + 468) / 2 = 376; so we are a bit better off than on average. Still, here's to hoping this freeze will be shorter.

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

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

Ingo Juergensmann: Bind9 vs. PowerDNS

25 October, 2014 - 03:20

Currently I'm playing around with DNSSEC. The handling of DNSSEC seems a little bit complex to me when looking at my current Bind9 setup. I was following the Debian Wiki page on DNSSEC and related links. The linked howto on HowToForge is a little bit outdated as it targeted to Squeeze. I've learned in the meanwhile that Bind9 can do key renewal on its own, but anyway, I did look around if there other nameservers that can handle DNSSEC and came across PowerDNS, which seems to power a large number of european DNSSEC zones.

Whereas Bind9 is well-known, well documented and serving my zones well for years. But I got the impression that DNSSEC is a more or less a mess with Bind9 as it was added on top of it without being well integrated. On the contrary, DNSSEC support is built into PowerDNS as if it was well integrated from scratch on a design level. But on the other hand there doesn't seem much ressources available on the net about PowerDNS. There's the official documentation, of course, but this is not as good as the Bind9 documentation. On the plus side you can operate PowerDNS in Bind mode, i.e. using the Bind9 configuration and zone files, even in hybrid-mode that enables you to additionally run a database-based setup.

So, I'm somewhat undecided about how to proceed. Either stay with Bind9 and DNSSEC, completely migrate to PowerDNS and a database setup or use PowerDNS with bind backend? Feel free to comment or respond by your own blog post about your experience. :-)

Kategorie: DebianTags: DNSDebianInternetSoftware 

Wouter Verhelst: Not using adirent

24 October, 2014 - 21:33

About a month ago, I received an upstream bugreport that the nbd-server wouldn't build on Solaris and its derivatives. This was because nbd-server uses the d_type field of struct dirent, which is widely implemented (in Linux and FreeBSD, at least), but not part of POSIX and therefore not implemented on Solaris (which tends to be more conservative about implementing new features).

The bug reporter pointed towards a blog post by a Solaris user who had written something he calls "adirent", meant to work around the issue by implementing something that would wrap readdir() so that it would inject a stat() call when needed. While that approach works, it seems a bit strange to add a function which wraps readdir to become portable. After all, readdir() does not always return the file type in d_type, not even on systems that do implement it. One example in which this is true is XFS; if one runs readdir() on a directory on an XFS filesystem, then everything will have DT_UNKNOWN as its filetype, indicating that you need to run stat() after all.

As such, I think a better approach is to use that fact so that things will just work on systems where d_type isn't available. The GNU autotools even have a test for it (AC_STRUCT_DIRENT_D_TYPE), which makes things easier. In the case of NBD, I've added that to configure.ac, and then added a touch of preprocessor magic to reuse the infrastructure for dealing with DT_UNKNOWN which is already there:

#ifdef HAVE_STRUCT_DIRENT_D_TYPE
#define NBD_D_TYPE de->d_type
#else
#define NBD_D_TYPE 0
#define DT_UKNOWN 0
#define DT_REG 1
#endif

(...opendir(), readdir(), ...)

switch(NBD_D_TYPE) {
    case DT_UNKNOWN:

(...call stat(), figure out if it is a file...)

    case DT_REG:

(...we know it is a file...)

    default:

(...we know it is not a file...)

this seems cleaner to me than using a wrapper, and has the additional advantage that the DT_UNKNOWN code path could receive some more testing.

Stefano Zacchiroli: Italy puts Free Software first in public sector

24 October, 2014 - 20:20
Debian participation in Italy's CAD68 committee

(The initial policy change discussed in this document is a couple of years old now, but it took about the same time to be fully implemented, and AFAIK the role Debian played by Debian in it has not been documented yet.)

In October 2012 the Italian government, led at the time by Mario Monti, did something rather innovative, at least for a country that is not usually ahead of its time in the area of information technology legislation. They decided to change the main law (the "CAD", for Codice dell'Amministrazione Digitale) that regulates the acquisition of software at all levels of the public administration (PA), giving an explicit preference to the acquisition of Free Software.

The new formulation of article 68 of the CAD first lists some macro criteria (e.g., TCO, adherence to open standards, security support, etc.) that public administrations in Italy shall use as ranking criteria in software-related calls for tenders. Then, and this is the most important part, the article affirms that the acquisition of proprietary software solutions is permitted only if it is impossible to choose Free Software solutions instead; or, alternatively, to choose software solutions that have already being acquired (and paid for) by the PA in the past, reusing preexisting software. The combined effect of these two provisions is that all new software acquisitions by PAs in Italy will be Free Software, unless it is motivated—in writing, challengable by a judge—that it was impossible to do otherwise. Isn't it great?

It is, except that such a law is not necessarily easy to adhere to in practice, especially for small public administrations (e.g., municipalities of a few hundred people, not uncommon in Italy) which might have very little clue about software in general, and even less so about Free Software. This is why the government also tasked the relevant Italian agency to provide guidelines on how to choose software in a way that conforms with the new formulation of article 68. The agency decided to form a committee to work on the guidelines (because you always need a committee, right? ).

To my surprise, the call for participation to be part of the committee explicitly listed representatives of Free Software communities as privileged software stakeholders that they wanted to have on the committee—kudos to the agency for that. (The Italian wording on the call was: Costituirà titolo di preferenza rivestire un ruolo di […] referenti di community del software a codice sorgente aperto.) Therefore, after various prods by fellow European Free Software activists that were aware of the ongoing change in legislation, I applied to be a volunteer CAD68 committee member, got selected, and ended up working over a period of about 6 months (March-September 2013) to help the agency writing the new software acquisition guidelines.

Logistically, it hasn't been entirely trivial, as the default meeting place was in Rome, I live in Paris, and the agency didn't really have a travel budget for committee members. That's why I've sought sponsorship from Debian, offering to represent Debian views within the committee; Lucas kindly agreed to my request. So what did I do on behalf of Debian as a committee member during those months?

Most of my job has been some sort of consulting on how community-driven Free Software projects—like Debian—work, on how the software they produce can be relied upon and contributed to, and more generally on how the PA can productively interact with such projects. In particular, I've been happy to work on the related work section of the guidelines, ensuring they point to relevant documents such as the French government guidelines on how to adopt Free Software (AKA circulaire Ayrault). I've also drafted the guidelines section on Free Software directories, ensuring that important resources such as FSF's Free Software Directory are listed as starting points for PAs that looking for software solutions for specific needs.

Another part of my job has been ensuring that the guidelines do not end up betraying the principle of Free Software preference that is embodied in article 68. A majority of committee members came from a Free Software background, so that might not seem a difficult goal to accomplish. But it is important to notice that: (a) the final editor of the guidelines is the agency itself, not the committee, so having a "pro-Free Software" majority within the committee doesn't mean much per se; and (b) lobbying from the "pro-proprietary software" camp did happen, as it is entirely natural in these cases. In this respect I'm happy with the result: I do believe that the software selection process recommended by the guidelines, finally published in January 2014, upholds the Free Software preference principle of article 68. I credit both the agency and the non-ambiguity of the law (on this specific point) for that result.

All in all, this has been a positive experience for me. It has reaffirmed my belief that Debian is a respected, non-partisan political actor of the wider software/ICT ecosystem. This experience has also given me a chance to be part of country-level policy-making, which has been very instructive on how and why good ideas might take a while to come into effect and influence citizen lives. Speaking of which, I'm now looking forward to the first alleged violations of article 68 in Italy, and how they will be dealt with.

Abundant popcorn will certainly be needed.

Links & press

If you want to know more about this topic, I've collected below links to resources that have documented, in various languages, the publication of the CAD68 guidelines.

Enrico Zini: systemd-cryptsetup-password

24 October, 2014 - 16:20
cryptsetup password and parallel boot

Since parallel boot happened, during boot the cryptsetup password prompt in my system gets flooded with other boot messages.

I fixed it, as suggested in #764555, installing plymouth, then editing /etc/default/grub to add splash to GRUB_CMDLINE_LINUX_DEFAULT:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Besides showing pretty pictures (and most importantly, getting them out of my way if I press ESC), plymouth also provides a user prompt that works with parallel boot which sounds like what I needed.

Petter Reinholdtsen: I spent last weekend recording MakerCon Nordic

24 October, 2014 - 05:00

I spent last weekend at Makercon Nordic, a great conference and workshop for makers in Norway and the surrounding countries. I had volunteered on behalf of the Norwegian Unix Users Group (NUUG) to video record the talks, and we had a great and exhausting time recording the entire day, two days in a row. There were only two of us, Hans-Petter and me, and we used the regular video equipment for NUUG, with a dvswitch, a camera and a VGA to DV convert box, and mixed video and slides live.

Hans-Petter did the post-processing, consisting of uploading the around 180 GiB of raw video to Youtube, and the result is now becoming public on the MakerConNordic account. The videos have the license NUUG always use on our recordings, which is Creative Commons Navngivelse-Del på samme vilkår 3.0 Norge. Many great talks available. Check it out! :)

Enrico Zini: systemd-default-rescue

24 October, 2014 - 04:06
Alternate rescue boot entry with systemd

Since systemd version 215, adding systemd.debug-shell to the kernel command line activates the debug shell on tty9 alongside the normal boot. I like the idea of that, and I'd like to have it in my standard 'rescue' entry in my grub menu.

Unfortunately, by default update-grub does not allow to customize the rescue menu entry options. I have just filed #766530 hoping for that to change.

After testing the patch I proposed for /etc/grub.d/10_linux, I now have this in my /etc/default/grub, with some satisfaction:

GRUB_CMDLINE_LINUX_RECOVERY="systemd.log_target=kmsg systemd.log_level=debug systemd.debug-shell"

Further information:

Thanks to sjoerd and uau on #debian-systemd for their help.

Gunnar Wolf: Listadmin — *YES*

24 October, 2014 - 02:05

Petter posted yesterday about Listadmin, the quick way to moderate mailman lists.

Petter: THANKS.

I am a fan of automatization. But, yes, I had never thouguht of doing this. Why? Don't know. But this is way easier than using the Web interface for Mailman:

$ listadmin 
fetching data for conoc_des@my.example.org ... nothing in queue
fetching data for des_polit_pub@my.example.org ... nothing in queue
fetching data for econ_apl@my.example.org ... nothing in queue
fetching data for educ_ciencia_tec@my.example.org ... nothing in queue
fetching data for est_hacend_sec_pub@my.example.org ... 

[1/1] ============== est_hacend_sec_pub@my.example.org ======
From:     sender@example.org                                            
Subject:  Invitación al Taller Insumo Producto                          
Reason:   El cuerpo del mensaje es demasiado grande: 777499    Spam? 0  
Approve/Reject/Discard/Skip/view Body/Full/jump #/Undo/Help/Quit ? a
Submit changes? [yes] 

fetching data for fiscal_fin@my.example.org ... nothing in queue
fetching data for historia@my.example.org ... nothing in queue
fetching data for industrial@my.example.org ... nothing in queue
fetching data for medio_amb@my.example.org ... nothing in queue
fetching data for mundial@my.example.org ... nothing in queue
fetching data for pol_des@my.example.org ... nothing in queue
fetching data for sec_ener@my.example.org ... nothing in queue
fetching data for sec_prim@my.example.org ... nothing in queue
fetching data for trab_tec@my.example.org ... nothing in queue
fetching data for urb_reg@my.example.org ... nothing in queue
fetching data for global@my.example.org ... nothing in queue

I don't know how in many years of managing several mailing lists I never thought about this! I'm echoing this, as I know several of my readers run mailman as well, and might not be following Planet Debian.

Dirk Eddelbuettel: Introducing Rocker: Docker for R

24 October, 2014 - 00:39

You only know two things about Docker. First, it uses Linux
containers. Second, the Internet won't shut up about it.

-- attributed to Solomon Hykes, Docker CEO

So what is Docker?

Docker is a relatively new open source application and service, which is seeing interest across a number of areas. It uses recent Linux kernel features (containers, namespaces) to shield processes. While its use (superficially) resembles that of virtual machines, it is much more lightweight as it operates at the level of a single process (rather than an emulation of an entire OS layer). This also allows it to start almost instantly, require very little resources and hence permits an order of magnitude more deployments per host than a virtual machine.

Docker offers a standard interface to creation, distribution and deployment. The shipping container analogy is apt: just how shipping containers (via their standard size and "interface") allow global trade to prosper, Docker is aiming for nothing less for deployment. A Dockerfile provides a concise, extensible, and executable description of the computational environment. Docker software then builds a Docker image from the Dockerfile. Docker images are analogous to virtual machine images, but smaller and built in discrete, extensible and reuseable layers. Images can be distributed and run on any machine that has Docker software installed---including Windows, OS X and of course Linux. Running instances are called Docker containers. A single machine can run hundreds of such containers, including multiple containers running the same image.

There are many good tutorials and introductory materials on Docker on the web. The official online tutorial is a good place to start; this post can not go into more detail in order to remain short and introductory.

So what is Rocker?

At its core, Rocker is a project for running R using Docker containers. We provide a collection of Dockerfiles and pre-built Docker images that can be used and extended for many purposes.

Rocker is the the name of our GitHub repository contained with the Rocker-Org GitHub organization.

Rocker is also the name the account under which the automated builds at Docker provide containers ready for download.

Current Rocker Status Core Rocker Containers

The Rocker project develops the following containers in the core Rocker repository

  • r-base provides a base R container to build from
  • r-devel provides the basic R container, as well as a complete R-devel build based on current SVN sources of R
  • rstudio provides the base R container as well an RStudio Server instance

We have settled on these three core images after earlier work in repositories such as docker-debian-r and docker-ubuntu-r.

Rocker Use Case Containers

Within the Rocker-org organization on GitHub, we are also working on

  • Hadleyverse which extends the rstudio container with a number of Hadley packages
  • rOpenSci which extends hadleyverse with a number of rOpenSci packages
  • r-devel-san provides an R-devel build for "Sanitizer" run-time diagnostics via a properly instrumented version of R-devel via a recent compiler build
  • rocker-versioned aims to provided containers with 'versioned' previous R releases and matching packages

Other repositories will probably be added as new needs and opportunities are identified.

Deprecation

The Rocker effort supersedes and replaces earlier work by Dirk (in the docker-debian-r and docker-ubuntu-r GitHub repositories) and Carl. Please use the Rocker GitHub repo and Rocker Containers from Docker.com going forward.

Next Steps

We intend to follow-up with more posts detailing usage of both the source Dockerfiles and binary containers on different platforms.

Rocker containers are fully functional. We invite you to take them for a spin. Bug reports, comments, and suggestions are welcome; we suggest you use the GitHub issue tracker.

Acknowledgments

We are very appreciative of all comments received by early adopters and testers. We also would like to thank RStudio for allowing us the redistribution of their RStudio Server binary.

Published concurrently at rOpenSci blog and Dirk's blog.

Authors

Dirk Eddelbuettel and Carl Boettiger

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

Alessio Treglia: Bits from the Debian Multimedia Maintainers

23 October, 2014 - 19:30

This brief announcement was released yesterday to the debian-devel-announce mailing list.

 

Ciao!

The Debian Multimedia Maintainers have been quite active since the Wheezy release, and have some interesting news to share for the Jessie release. Here we give you a brief update on what work has been done and work that is still ongoing.

Let’s see what’s cooking for Jessie then.

 

Frameworks and libraries Support for many new media formats and codecs.

The codec library libavcodec, which is used by popular media playback applications including vlc, mpv, totem (using gstreamer1.0-libav), xine, and many more, has been updated to the latest upstream release version 11 provided by Libav. This provides Debian users with HEVC playback, a native Opus decoder, Matroska 3D support, Apple ProRes, and much more. Please see libav’s changelog for a full list of functionality additions and updates.

libebur128

libebur128 is a free implementation of the European Broadcasting Union Loudness Recommendation (EBU R128), which is essentially an alternative to ReplayGain. The library can be used to analyze audio perceived loudness and subsequentially normalize the volume during playback.

libltc

libltc provides functionalities to encode and decode Linear (or Longitudinal) Timecode (LTC) from/to SMPTE data timecode.

libva

libva and the driver for Intel GPUs has been updated to the 1.4.0 release. Support for new GPUs has been added. libva now also supports Wayland.

Pure Data

A number of new additional libraries (externals) will appear in Jessie, including (among others) Eric Lyon’s fftease and lyonpotpourrie, Thomas Musil’s iemlib, the pdstring library for string manipulation and pd-lua that allows to write Pd-objects in the popular lua scripting language.

 

JACK and LADI

LASH Audio Session Handler was abandoned upstream a long time ago in favor of the new session management system, called ladish (LADI Session Handler). ladish allows users to run many JACK applications at once and save/restore their configuration with few mouse clicks.

The current status of the integration between the session handler and JACK may be summarized as follows:

  • ladish provides the backend;
  • laditools contains a number of useful graphical tools to tune the session management system’s whole configuration (including JACK);
  • gladish provides a easy-to-use graphical interface for the session handler.

Note that ladish uses the D-Bus interface to the jack daemon, therefore only Jessie’s jackd2 provides support for and also cooperates fine with it.

 

Plugins: LV2 and LADSPA

Debian Jessie will bring the newest 1.10.0 version of the LV2 technology. Most changes affect the packaging of new plugins and extensions, a brief list of packaging guidelines is now available.
A number of new plugins and development tools too have been made available during the Jessie development cycle:

LV2 Toolkit

LVTK provides libraries that wrap the LV2 C API and extensions into easy to use C++ classes. The original work for this was mostly done by Lars Luthman in lv2-c++-tools.

Vee One Suite

The whole suite by Rui Nuno Capela is now available in Jessie, and consists of three components:

  • drumkv1: old-school drum-kit sampler synthesizer
  • samplv1: polyphonic sampler
  • synthv1: analog-style 4-oscillator substractive synthesizer

All three are provided in both forms of LV2 plugins and stand-alone JACK client. JACK session, JACK MIDI, and ALSA MIDI are supported too.

x42-plugins and zam-plugins

LV2 bundles containing many audio plugins for high quality processing.

Fomp

Fomp is an LV2 port of the MCP, VCO, FIL, and WAH plugins by Fons Adriaensen.

Some other components have been upgraded to more recent upstream versions:

  • ab2gate: 1.1.7
  • calf: 0.0.19+git20140915+5de5da28
  • eq10q: 2.0~beta5.1
  • NASPRO: 0.5.1

We’ve packaged ste-plugins, Fons Adriaensen’s new stereo LADSPA plugins bundle.

A major upgrade of frei0r, namely the standard collection for the minimalistic plugin API for video effects, will be available in Jessie.

 

New multimedia applications Advene

Advene (Annotate Digital Video, Exchange on the NEt) is a flexible video
annotation application.

Ardour3

The new generation of the popular digital audio workstation will make its very first appearance in Debian Jessie.

Cantata

Qt4 front-end for the MPD daemon.

Csound

Csound for jessie will feature the new major series 6, with the improved IDE CsoundQT. This new csound supports improved array data type handling, multi-core rendering and debugging features.

din

DIN Is Noise is a musical instrument and audio synthesizer that supports JACK audio output, MIDI, OSC, and IRC bot as input sources. It could be extended and customized with Tcl scripts too.

dvd-slideshow

dvd-slideshow consists of a suite of command line tools which come in handy to make slideshows from collections of pictures. Documentation is provided and available in `/usr/share/doc/dvd-slideshow/’.

dvdwizard

DVDwizard can fully automate the creation of DVD-Video filesystem. It supports graphical menus, chapters, multiple titlesets and multi-language streams. It supports both PAL and NTSC video modes too.

flowblade

Flowblade is a video editor – like the popular KDenlive based on the MLT engine, but more lightweight and with some difference in editing concepts.

forked-daapd

Forked-daapd switched to a new, active upstream again dropping Grand Central Dispatch in favor of libevent. The switch fixed several bugs and made forked-daapd available on all release architectures instead of shipping only on amd64 and i386. Now nothing prevents you from setting up a music streaming (DAAP/DACP) server on your favorite home server no matter if it is based on mips, arm or x86!

harvid

HTTP Ardour Video Daemon decodes still images from movie files and serves them via HTTP. It provides frame-accurate decoding and is main use-case is to act as backend and second level cache for rendering the
videotimeline in Ardour.

Groove Basin

Groove Basin is a music player server with a web-based user interface inspired by Amarok 1.4. It runs on a server optionally connected to speakers. Guests can control the music player by connecting with a laptop, tablet, or smart phone. Further, users can stream their music libraries remotely.
It comes with a fast, responsive web interface that supports keyboard shortcuts and drag drop. It also provides the ability to upload songs, download songs, and import songs by URL, including YouTube URLs. Groove Basin supports Dynamic Mode which automatically queues random songs, favoring songs that have not been queued recently.
It automatically performs ReplayGain scanning on every song using the EBU R128 loudness standard, and automatically switches between track and album mode. Groove Basin supports the MPD protocol, which means it is compatible with MPD clients. There is also a more powerful Groove Basin protocol which you can use if the MPD protocol does not meet your needs.

HandBrake

HandBrake, a versatile video transcoder, is now available for Jessie. It could convert video from nearly any format to a wide range of commonly supported codecs.

jack-midi-clock

New jackd midiclock utility made by Robin Gareus.

laborejo

Laborejo, Esperanto for “Workshop”, is used to craft music through notation. It is a LilyPond GUI frontend, a MIDI creator and a tool collection to inspire and help music composers.

mpv

mpv is a movie player based on MPlayer and mplayer2. It supports a wide variety of video file formats, audio and video codecs, and subtitle types. The project focuses mainly on modern systems and encourages developer activity. As such, large portions of outdated code originating from MPlayer have been removed, and many new features and improvements have been added. Note that, although there are still some similarities to its predecessors, mpv should be considered a completely different program (e.g. lacking compatibility with both mplayer and mplayer2 in terms of command-line arguments and configuration).

smtube

SMTube is a stand-alone graphical video browser and player, which makes YouTube’s videos browsing, playing, and download such a piece of cake.
It has so many features that, we are sure, will make YouTube lovers very, very happy.

sonic-visualiser

Sonic Visualiser Application for viewing and analysing the contents of music audio files.

SoundScapeRenderer

SoundScapeRenderer (aka SSR) is a (rather) easy to use render engine for spatial audio, that provides a number of different rendering algorithms, ranging from binaural (headphone) playback via wave field synthesis to higher-order ambisonics.

Videotrans

videotrans is a set of scripts that allow its user to reformat existing movies into the VOB format that is used on DVDs.

XBMC

XBMC has been partially rebranded as XBMC from Debian to make it clear that it is changed to conform to Debian’s Policy. The latest stable release, 13.2 Gotham will be part of Jessie making Debian a good choice for HTPC-s.

zita-bls1

Binaural stereo signals converter made by Fons Adriaensen

zita-mu1

Stereo monitoring organiser for jackd made by Fons Adriaensen

zita-njbridge

Jack clients to transmit multichannel audio over a local IP network made by Fons Adriaensen

radium-compressor

Radium Compressor is the system compressor of the Radium suite. It is provided in the form of stand-alone JACK application.

 

Multimedia Tasks

With Jessie we are shipping a set of multimedia related tasks.
They include package lists for doing several multimedia related tasks. If you are interested in defining new tasks, or tweaking the current, existing ones, we are very much interested in hearing from you.

 

Upgraded applications and libraries
  • Aeolus: 0.9.0
  • Aliki: 0.3.0
  • Ams: 2.1.1
  • amsynth: 1.4.2
  • Audacious: 3.5.2
  • Audacity: 2.0.5
  • Audio File Library: 0.3.6
  • Blender: 2.72b
  • Bristol: 0.60.11f
  • C* Audio Plugin Suite: 0.9.23
  • Cecilia: 5.0.9
  • cmus: 2.5.0
  • DeVeDe: 3.23.0-13-gbfd73f3
  • DRC: 3.2.1
  • EasyTag: 2.2.2
  • ebumeter: 0.2.0
  • faustworks: 0.5
  • ffDiaporama: 1.5
  • ffms: 2.20
  • gmusicbrowser: 1.1.13
  • Hydrogen: 0.9.6.1
  • IDJC: 0.8.14
  • jack-tools: 20131226
  • LiVES: 2.2.6
  • mhWaveEdit: 1.4.23
  • Mixxx: 1.11.0
  • mp3fs: 0.91
  • MusE: 2.1.2
  • Petri-Foo: 0.1.87
  • PHASEX: 0.14.97
  • QjackCtl: 0.3.12
  • Qtractor: 0.6.3
  • rtaudio: 4.1.1
  • Rosegarden: 14.02
  • rtmidi: 2.1.0
  • SoundTouch: 1.8.0
  • stk: 4.4.4
  • streamtuner2: 2.1.3
  • SuperCollider: 3.6.6
  • Synfig Studio: 0.64.1
  • TerminatorX: 3.90
  • tsdecrypt: 10.0
  • Vamp Plugins SDK: 2.5
  • VLC: Jessie will release with the 2.2.x series of VLC
  • XCFA: 4.3.8
  • xwax: 1.5
  • xjadeo: 0.8.0
  • x264: 0.142.2431+gita5831aa
  • zynaddsubfx: 2.4.3

 

What’s not going to be in Jessie

With the aim to improve the overall quality of the multimedia software available in Debian, we have dropped a number of packages which were abandoned upstream:

  • beast
  • flumotion
  • jack-rack
  • jokosher
  • lv2fil (suggested replacement for users is eq10q or calf eq)
  • phat
  • plotmm
  • specimen (suggested replacement for users is petri-foo – fork of specimen)
  • zynjacku (suggested replacement for users is jalv)

We’ve also dropped mplayer, presently nobody seems interested in maintaining it.
The suggested replacements for users are mplayer2 or mpv. Whilst the former is mostly compatible with mplayer in terms of command-line arguments and configuration (and adds a few new features too), the latter adds a lot of new features and improvements, and it is actively maintained upstream.

Please note that although the mencoder package is no longer available anymore, avconv and mpv do provide encoding functionality. For more information see avconv’s manual page and documentation, and mpv’s encoding documentation.

 

Broken functionalities

rtkit under systemd is broken at the moment.

 

Activity statistics

More information about team’s activity are available.

 

Where to reach us

The Debian Multimedia Maintainers can be reached at pkg-multimedia-maintainers AT lists.alioth.debian.org for packaging related topics, or at debian-multimedia AT lists.debian.org for user and more general discussion.
We would like to invite everyone interested in multimedia to join us there. Some of the team members are also in the #debian-multimedia channel on OFTC.

Cheers!

Alessio Treglia
on behalf of the Debian Multimedia Maintainers

 

Erich Schubert: Clustering 23 mio Tweet locations

23 October, 2014 - 17:01
To test scalability of ELKI, I've clustered 23 million Tweet locations from the Twitter Statuses Sample API obtained over 8.5 months (due to licensing restrictions by Twitter, I cannot make this data available to you, sorry. 23 million points is a challenge for advanced algorithms. It's quite feasible by k-means; in particular if you choose a small k and limit the number of iterations. But k-means does not make a whole lot of sense on this data set - it is a forced quantization algorithm, but does not discover actual hotspots. Density-based clustering such as DBSCAN and OPTICS are much more appropriate. DBSCAN is a bit tricky to parameterize - you need to find the right combination of radius and density for the whole world. Given that Twitter adoption and usage is quite different it is very likely that you won't find a single parameter that is appropriate everywhere. OPTICS is much nicer here. We only need to specify a minimum object count - I chose 1000, as this is a fairly large data set. For performance reasons (and this is where ELKI really shines) I chose a bulk-loaded R*-tree index for acceleration. To benefit from the index, the epsilon radius of OPTICS was set to 5000m. Also, ELKI allows using geodetic distance, so I can specify this value in meters and do not get much artifacts from coordinate projection. To extract clusters from OPTICS, I used the Xi method, with xi set to 0.01 - a rather low value, also due to the fact of having a large data set. The results are pretty neat - here is a screenshot (using KDE Marble and OpenStreetMap data, since Google Earth segfaults for me right now):
Some observations: unsurprisingly, many cities turn up as clusters. Also regional differences are apparent as seen in the screenshot: plenty of Twitter clusters in England, and low acceptance rate in Germany (Germans do seem to have objections about using Twitter; maybe they still prefer texting, which was quite big in Germany - France and Spain uses Twitter a lot more than Germany). Spam - some of the high usage in Turkey and Indonesia may be due to spammers using a lot of bots there. There also is a spam cluster in the ocean south of Lagos - some spammer uses random coordinates [0;1]; there are 36000 tweets there, so this is a valid cluster... A benefit of OPTICS and DBSCAN is that they do not cluster every object - low density areas are considered as noise. Also, they support clusters of different shape (which may be lost in this visualiation, which uses convex hulls!) and different size. OPTICS can also produce a hierarchical result. Note that for these experiments, the actual Tweet text was not used. This has a rough correspondence to Twitter popularity "heatmaps", except that the clustering algorithms will actually provide a formalized data representation of activity hotspots, not only a visualization. You can also explore the clustering result in your browser - the Google Drive visualization functionality seems to work much better than Google Earth... but unfortunately, you cannot see details on the clusters (such as the number of Tweets) there. If you go to Istanbul or Los Angeles, you will see some artifacts - odd shaped clusters with a clearly visible spike. This is caused by the Xi extraction of clusters, which is far from perfect. At the end of a valley in the OPTICS plot, it is hard to decide whether a point should be included or not. These errors are usually the last element in such a valley, and should be removed via postprocessing. But our OpticsXi implementation is meant to be as close as possible to the published method, so we do not intend to "fix" this. Certain areas - such as Washington, DC, New York City, and the silicon valley - do not show up as clusters. The reason is probably again the Xi extraction - these region do not exhibit the steep density increase expected by Xi, but are too blurred in their surroundings to be a cluster. Hierarchical results can be found e.g. in Brasilia and Los Angeles. If you want to reproduce these results, you need to get the upcoming ELKI version (0.6.5~201410xx - the output of cluster convex hulls was just recently added to the default codebase), and of course data. The settings I used are:
-dbc.in coords.tsv.gz
-db.index tree.spatial.rstarvariants.rstar.RStarTreeFactory
-pagefile.pagesize 500
-spatial.bulkstrategy SortTileRecursiveBulkSplit
-time
-algorithm clustering.optics.OPTICSXi
-opticsxi.xi 0.01
-algorithm.distancefunction geo.LngLatDistanceFunction
-optics.epsilon 5000.0 -optics.minpts 1000
-resulthandler KMLOutputHandler -out /tmp/out.kmz
and the total runtime for 23 million points on a single core was about 29 hours. The indexes helped a lot: less than 10000 distances were computed per point, instead of 23 million - the expected speedup over a non-indexed approach is 2400. Don't try this with R or Matlab. Your average R clustering algorithm will try to build a full distance matrix, and you probably don't have an exabyte of memory to store this matrix. Maybe start with a smaller data set first, then see how long you can afford to increase the data size.

Matthew Garrett: Linux Container Security

23 October, 2014 - 15:47
First, read these slides. Done? Good.

Hypervisors present a smaller attack surface than containers. This is somewhat mitigated in containers by using seccomp, selinux and restricting capabilities in order to reduce the number of kernel entry points that untrusted code can touch, but even so there is simply a greater quantity of privileged code available to untrusted apps in a container environment when compared to a hypervisor environment[1].

Does this mean containers provide reduced security? That's an arguable point. In the event of a new kernel vulnerability, container-based deployments merely need to upgrade the kernel on the host and restart all the containers. Full VMs need to upgrade the kernel in each individual image, which takes longer and may be delayed due to the additional disruption. In the event of a flaw in some remotely accessible code running in your image, an attacker's ability to cause further damage may be restricted by the existing seccomp and capabilities configuration in a container. They may be able to escalate to a more privileged user in a full VM.

I'm not really compelled by either of these arguments. Both argue that the security of your container is improved, but in almost all cases exploiting these vulnerabilities would require that an attacker already be able to run arbitrary code in your container. Many container deployments are task-specific rather than running a full system, and in that case your attacker is already able to compromise pretty much everything within the container. The argument's stronger in the Virtual Private Server case, but there you're trading that off against losing some other security features - sure, you're deploying seccomp, but you can't use selinux inside your container, because the policy isn't per-namespace[2].

So that seems like kind of a wash - there's maybe marginal increases in practical security for certain kinds of deployment, and perhaps marginal decreases for others. We end up coming back to the attack surface, and it seems inevitable that that's always going to be larger in container environments. The question is, does it matter? If the larger attack surface still only results in one more vulnerability per thousand years, you probably don't care. The aim isn't to get containers to the same level of security as hypervisors, it's to get them close enough that the difference doesn't matter.

I don't think we're there yet. Searching the kernel for bugs triggered by Trinity shows plenty of cases where the kernel screws up from unprivileged input[3]. A sufficiently strong seccomp policy plus tight restrictions on the ability of a container to touch /proc, /sys and /dev helps a lot here, but it's not full coverage. The presentation I linked to at the top of this post suggests using the grsec patches - these will tend to mitigate several (but not all) kernel vulnerabilities, but there's tradeoffs in (a) ease of management (having to build your own kernels) and (b) performance (several of the grsec options reduce performance).

But this isn't intended as a complaint. Or, rather, it is, just not about security. I suspect containers can be made sufficiently secure that the attack surface size doesn't matter. But who's going to do that work? As mentioned, modern container deployment tools make use of a number of kernel security features. But there's been something of a dearth of contributions from the companies who sell container-based services. Meaningful work here would include things like:

  • Strong auditing and aggressive fuzzing of containers under realistic configurations
  • Support for meaningful nesting of Linux Security Modules in namespaces
  • Introspection of container state and (more difficult) the host OS itself in order to identify compromises

These aren't easy jobs, but they're important, and I'm hoping that the lack of obvious development in areas like this is merely a symptom of the youth of the technology rather than a lack of meaningful desire to make things better. But until things improve, it's going to be far too easy to write containers off as a "convenient, cheap, secure: choose two" tradeoff. That's not a winning strategy.

[1] Companies using hypervisors! Audit your qemu setup to ensure that you're not providing more emulated hardware than necessary to your guests. If you're using KVM, ensure that you're using sVirt (either selinux or apparmor backed) in order to restrict qemu's privileges.
[2] There's apparently some support for loading per-namespace Apparmor policies, but that means that the process is no longer confined by the sVirt policy
[3] To be fair, last time I ran Trinity under Docker under a VM, it ended up killing my host. Glass houses, etc.

comments

Sylvain Le Gall: Release of OASIS 0.4.5

23 October, 2014 - 06:42

On behalf of Jacques-Pascal Deplaix

I am happy to announce the release of OASIS v0.4.5.

OASIS is a tool to help OCaml developers to integrate configure, build and install systems in their projects. It should help to create standard entry points in the source code build system, allowing external tools to analyse projects easily.

This tool is freely inspired by Cabal which is the same kind of tool for Haskell.

You can find the new release here and the changelog here. More information about OASIS in general on the OASIS website.

Here is a quick summary of the important changes:

  • Build and install annotation files.
  • Use builtin bin_annot and annot tags.
  • Tag .mly files on the same basis as .ml and .mli files (required by menhir).
  • Remove 'program' constraint from C-dependencies. Currently, when a library has C-sources and e.g. an executable depends on that library, then changing the C-sources and running '-build' does not yield a rebuild of the library. By adding these dependencies (rather removing the constraint), it seems to work fine.
  • Some bug fixes

Features:

  • no_automatic_syntax (alpha): Disable the automatic inclusion of -syntax camlp4o for packages that matches the internal heuristic (if a dependency ends with a .syntax or is a well known syntax).
  • compiled_setup_ml (alpha): Fix a bug using multiple arguments to the configure script.

This new version is a small release to catch up with all the fixes/pull requests present in the VCS that have not yet been published. This should made the life of my dear contributors easier -- thanks again for being patient.

I would like to thanks again the contributor for this release: Christopher Zimmermann, Jerome Vouillon, Tomohiro Matsuyama and Christoph Höger. Their help is greatly appreciated.

Petter Reinholdtsen: listadmin, the quick way to moderate mailman lists - nice free software

23 October, 2014 - 02:00

If you ever had to moderate a mailman list, like the ones on alioth.debian.org, you know the web interface is fairly slow to operate. First you visit one web page, enter the moderation password and get a new page shown with a list of all the messages to moderate and various options for each email address. This take a while for every list you moderate, and you need to do it regularly to do a good job as a list moderator. But there is a quick alternative, the listadmin program. It allow you to check lists for new messages to moderate in a fraction of a second. Here is a test run on two lists I recently took over:

% time listadmin xiph
fetching data for pkg-xiph-commits@lists.alioth.debian.org ... nothing in queue
fetching data for pkg-xiph-maint@lists.alioth.debian.org ... nothing in queue

real    0m1.709s
user    0m0.232s
sys     0m0.012s
%

In 1.7 seconds I had checked two mailing lists and confirmed that there are no message in the moderation queue. Every morning I currently moderate 68 mailman lists, and it normally take around two minutes. When I took over the two pkg-xiph lists above a few days ago, there were 400 emails waiting in the moderator queue. It took me less than 15 minutes to process them all using the listadmin program.

If you install the listadmin package from Debian and create a file ~/.listadmin.ini with content like this, the moderation task is a breeze:

username@example.org
spamlevel 23
default discard
discard_if_reason "Posting restricted to members only. Remove us from your mail list."

password secret
adminurl https://{domain}/mailman/admindb/{list}
mailman-list@lists.example.com

password hidden
other-list@otherserver.example.org

There are other options to set as well. Check the manual page to learn the details.

If you are forced to moderate lists on a mailman installation where the SSL certificate is self signed or not properly signed by a generally accepted signing authority, you can set a environment variable when calling listadmin to disable SSL verification:

PERL_LWP_SSL_VERIFY_HOSTNAME=0 listadmin

If you want to moderate a subset of the lists you take care of, you can provide an argument to the listadmin script like I do in the initial screen dump (the xiph argument). Using an argument, only lists matching the argument string will be processed. This make it quick to accept messages if you notice the moderation request in your email.

Without the listadmin program, I would never be the moderator of 68 mailing lists, as I simply do not have time to spend on that if the process was any slower. The listadmin program have saved me hours of time I could spend elsewhere over the years. It truly is nice free software.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Konstantinos Margaritis: Eigen NEON port extended to ARMv8!

22 October, 2014 - 18:44

Soon after the VSX port, and as promised I have completed the ARMv8 NEON (a.k.a. Advanced SIMD) port. Basically this extends support to 64-bit doubles and also provides faster alternatives to division as ARMv8 has builtin instructions for division both for 32-bit floats and 64-bit doubles. Preliminary benchmarks (bench_gemm):

Pages

Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้