Search Results: "rul"

6 February 2012

Cyril Brulebois: dpkg with multiarch, a new hope

dpkg was uploaded to experimental a few times lately, let s sum it up quickly:
  1. It started with my NMU on 2012-01-31, since I hadn t received any reasons not to upload (except NACK , which doesn t count as such in my book).
  2. It got reverted a few minutes after that.
  3. Since this was getting nowhere, the Debian Technical Committee finally got involved, and voted in a few days only (wow, thanks!) for an it s time to experiment decision.
  4. A new dpkg upload to experimental finally happened. One shall note the prominent This is a WIP release, command line interfaces will change. notice.
I ve updated my previous dpkg with multiarch page accordingly, only keeping the interesting bits. Playing around with grep-aptavail -F Multi-Arch $i -sPackage (with $i being same or foreign), I found some bugs: Also, some wishlist bugs (keeping the prominent notice in mind): Finally, one dpkg improvement and one possible dpkg bug:

4 February 2012

Petter Reinholdtsen: Third beta version of Debian Edu / Skolelinux based on Squeeze

I am happy to announce that finally we managed today to wrap up and publish the third beta version of Debian Edu / Skolelinux based on Squeeze. If you want to test a LDAP backed Kerberos server with out of the box PXE configuration for running diskless machines and installing new machines, check it out. If you need a software solution for your school, check it out too. The full announcement is available on the project announcement list. I am very happy to report these changes and improvements since beta2 (there are more, see announcement for full list): The new main server seem to work so well that I am testing it as my private DNS/LDAP/Kerberos/PXE/LTSP server at home. I will use it look for issues we could fix to polish Debian Edu even further before the final Squeeze release is published. Next weekend the project organise a developer gathering in Oslo. We will continue the work on the Squeeze version, and start initial planning for the Wheezy version. Perhaps I will see you there?

1 February 2012

Raphaël Hertzog: My Debian Activities in January 2012

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (213.68 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg The biggest change I made is a small patch that brings to an end years and years of recurring discussions about the build-arch and build-indep targets of debian/rules (see #229357). Last year the technical committee took this issue in its hands (see #629385) but it failed to take any resolution. Fortunately thanks to this we got some concrete numbers on the colateral damages inflicted on the archive for each possible approach. In the end, Guillem and I managed to agree on the way forward. The remaining of what I did as dpkg maintainer has not much to do with coding. I reviewed the work of Gianluca Ciccarelli on dpkg-maintscript-helper who is trying to provide helper functions to handle migration between directories and symlinks. I also reviewed a 2000-lines patch from Patrick Schoenfeld who s trying to provide a perl API to parse dpkg log files and extract meaningful data out of them. I updated the dpkg-architecture manual page to document the Makefile snippet /usr/share/dpkg/architecture.mk and to drop information that s no longer releveant nowadays. I reviewed a huge patch prepared by Russ Alberry to update the Debian policy and document the usage of symbols files for libraries. As the author of dpkg-gensymbols, I was keen to see it properly documented at the policy level. I brought up for discussion a detail that was annoying me for quite some time: some copyright notices were embedded in translatable strings and updating them resulted in useless work for translators. In the end we decided to drop those notices and to keep them only at the source level. I updated my multiarch branch on top of Guillem s branch several times, all the fixes that were in my branch have been integrated (often in a modified form). Unfortunately even if the code works quite well, Guillem doesn t want to release anything to Debian until he has finished to review everything and many people are annoyed by the unreasonable delay that it imposes. Cyril Brulebois tried to release a snapshot of the current multiarch branch to experimental but Guillem has been prompt to revert this upload. I m somewhat at a loss in this situation. I offered my help to Guillem multiple times but he keeps doing his work in private, he doesn t share many details of his review except some comments in commit logs or when it affects the public interface. I complained once more of this sad situation. Debian Package Maintenance Hub That s the codename I use for a new infrastructure that I would like to develop to replace the Package Tracking System and the DDPO and several other services. I started to draft a Debian Enhancement Proposal (DEP), see DEP-2, and requested some comments within the QA team. For now, it looks like that nobody had major objections on the driving idea behind this project. Those who commented were rather enthusiastic. I will continue to improve this DEP within the QA team and at some point I will bring the discussion to a larger audience like debian-devel@lists.debian.org. Package Tracking System Even if I started to design its replacement, the PTS will still be used for quite some time so I implemented two new features that I deemed important: displaying a TODO notice when there is (at least) one open bug related to a release goal, displaying a notice when the package is involved in an ongoing or upcoming transition. Misc packaging tasks I created and uploaded the dh-linktree package which is a debhelper addon to create symlink trees (useful to replace embedded copies of PHP/JavaScript libraries by symlinks to packaged copies of those files). I packaged quilt 0.50. I helped the upstream authors to merge a Debian patch that had been forwarded by Martin Quinson (a quilt s co-maintainer). I packaged a security release of WordPress (3.3.1) and a new upstream release of feed2omb and gnome-shell-timer. I prepared a new Debian release of python-django with a patch cherry-picked from the upstream SVN repository to fix the RC bug #655666. Book update We re again making decent progress in the translation of the Debian Administrator s Handbook, about 12 chapters are already translated. The liberation campaign is also (slowly) going forward. We re at 72% now (thanks to 63 new supporters!) while we were only at 67% at the start of January. Thanks See you next month for a new summary of my activities.

5 comments Liked this article? Click here. My blog is Flattr-enabled.

Michal Čihař: How not to ask questions

First of all, take this blog post as a rant from developer. I don't expect that this will change anything in how people ask me questions. Anyway before you write me email with some questions, please check following easy bits:
  1. Have you tried to write your question into Google?
  2. Most projects have documentation, have you looked at it?
  3. There are mailing lists or discussion forums, do you really need to write directly to me?
  4. Writing subject like "!important" or ALL IN CAPS will work other way than you probably expect.
  5. Yes I have more email addresses, that does not mean you should write to all of them.
If you do follow these basic rules, you might get more help than usual. If you are interested in knowing more, there is famous How To Ask Questions The Smart Way which will tell you more information than I did in this rant.

Filed under: English Gammu Phpmyadmin 0 comments Flattr this!

Cyril Brulebois: dpkg with multiarch

(This page was edited a few times, details are available.) Grab it while it s hot! Thanks to the hard work of dpkg developers and many (generations of) developers, multiarch is becoming a reality. If you want to give it a try, install dpkg from experimental, add a foreign architecture, and start trying to install packages. Example on amd64:
# dpkg --add-architecture i386
# dpkg --print-foreign-architectures
i386
# apt-get update
[ lots of amd64 and i386 Packages files get downloaded ]
# apt-get install mksh:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  ed:i386
The following NEW packages will be installed:
  mksh:i386
0 upgraded, 1 newly installed, 0 to remove and 9 not upgraded.
Need to get 414 kB of archives.
After this operation, 707 kB of additional disk space will be used.
Get:1 http://ftp.fr.debian.org/debian/ sid/main mksh i386 40.4-2 [414 kB]
Fetched 414 kB in 0s (664 kB/s)
Selecting previously unselected package mksh.
(Reading database ... 171933 files and directories currently installed.)
Unpacking mksh (from .../archives/mksh_40.4-2_i386.deb) ...
Processing triggers for menu ...
Processing triggers for man-db ...
Setting up mksh (40.4-2) ...
update-alternatives: using /bin/mksh to provide /bin/ksh (ksh) in auto mode.
Processing triggers for menu ...
# mksh
$ ldd $(which mksh)
linux-gate.so.1 =>  (0xf779c000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf75d6000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf75b9000)
/lib/ld-linux.so.2 (0xf779d000)
Of course, installing an i386 mksh package isn t exactly what multiarch is about. Dozens of packages have been patched already to add Multi-Arch fields, but until their (recursive) dependencies have been multiarch-ified, foreign packages can be uninstallable, as can be seen below, with the usual why is it uninstallable? hunt (shortened output):
# apt-get install psutils:i386
The following packages have unmet dependencies:
 psutils:i386 : Depends: libpaper1:i386 but it is not going to be installed
# apt-get install libpaper1:i386
The following packages have unmet dependencies:
 libpaper1:i386 : Depends: ucf:i386 (>= 0.28) but it is not installable
                  Recommends: libpaper-utils:i386 but it is not going to be installed
# apt-get install ucf:i386
E: Package 'ucf:i386' has no installation candidate
Another example, successful handling of the installation of a foreign package, while it s already installed with the host architecture:
# apt-get install xz-utils:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  liblzma5:i386
Suggested packages:
  xz-lzma:i386
The following packages will be REMOVED:
  xz-utils
The following NEW packages will be installed:
  liblzma5:i386 xz-utils:i386
0 upgraded, 2 newly installed, 1 to remove and 9 not upgraded.
Need to get 440 kB of archives.
After this operation, 410 kB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp.fr.debian.org/debian/ sid/main liblzma5 i386 5.1.1alpha+20110809-3 [205 kB]
Get:2 http://ftp.fr.debian.org/debian/ sid/main xz-utils i386 5.1.1alpha+20110809-3 [235 kB]
Fetched 440 kB in 0s (478 kB/s)
dpkg: xz-utils: dependency problems, but removing anyway as you requested:
 dpkg depends on xz-utils.
 xz-lzma depends on xz-utils.
 dpkg-dev depends on xz-utils.
(Reading database ... 171952 files and directories currently installed.)
Removing xz-utils ...
Processing triggers for man-db ...
Selecting previously unselected package liblzma5:i386.
(Reading database ... 171908 files and directories currently installed.)
Unpacking liblzma5:i386 (from .../liblzma5_5.1.1alpha+20110809-3_i386.deb) ...
Selecting previously unselected package xz-utils.
Unpacking xz-utils (from .../xz-utils_5.1.1alpha+20110809-3_i386.deb) ...
Processing triggers for man-db ...
Setting up liblzma5:i386 (5.1.1alpha+20110809-3) ...
Setting up xz-utils (5.1.1alpha+20110809-3) ...
# dpkg -l xz-utils xz-utils:i386 'liblzma*:*'
[   ]
un  xz-utils            <none>
ii  xz-utils            5.1.1alpha+20110809-3
ii  liblzma5:amd64      5.1.1alpha+20110809-3
ii  liblzma5:i386       5.1.1alpha+20110809-3
# ldd $(which xz)
    linux-gate.so.1 =>  (0xf776b000)
    liblzma.so.5 => /usr/lib/i386-linux-gnu/liblzma.so.5 (0xf7724000)
    librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf771b000)
    libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf7701000)
    libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf75a4000)
    /lib/ld-linux.so.2 (0xf776c000)
# zgrep -a '_("Activities")' gnome-shell-3.2.2.1.tar.xz
        this._label = new St.Label(  text: _("Activities")  );
zgrep is a shell script, but it calls xz, which is from the i386 package, and everything runs just fine. Running it through strace -f -e '', I discovered those messages, which I had never seen before:
[ Process PID=8900 runs in 32 bit mode. ]
[ Process PID=8899 runs in 64 bit mode. ]
[ Process PID=8900 runs in 32 bit mode. ]
[ Process PID=8899 runs in 64 bit mode. ]
 
What s next? We re late! It s time to check what happens with that dpkg package, report bugs, and convert more libraries! Please think of the kittens, and coordinate with the release team to make sure you don t delay a transition when uploading a shiny, multiarch-ified package. In a nutshell, if you received a patch from Steve Langasek or Riku Voipio, it s a good indication your package will be helpful quickly when it s multiarchified. Since zlib is directly depended on by 2000+ packages, #569697 was pinged right after the dpkg upload; but many other packages will need patches and heavy testing. Hurry up, the freeze is coming, we need to shake it up as soon as possible!

31 January 2012

Andrea Veri: A few useful Puppet snippets

I ve been playing with Puppet lately both on my home network and within the Fedora s Infrastructure team and I thought some of the work I did might be useful for anyone out there being stuck with a Puppet s manifest or an ERB template. Snippet #1: Make sure the user foo is alwais created with its own home directory, password, shell, and full name.
class users  
    users::add   "foo":
        username        => 'foo',
        comment         => 'Foo's Full Name',
        shell           => '/bin/bash',
        password_hash   => 'pwd_hash_as_you_can_see_in_/etc/shadow'
     
define users::add($username, $comment, $shell, $password_hash)  
    user   $username:
        ensure => 'present',
        home   => "/home/$ username ",
        comment => $comment,
        shell  => $shell,
        managehome => 'true',
        password => $password_hash,
     
   
 
Snippet #2: Make sure the user foo gets added into /etc/sudoers.
class sudoers  
file   "/etc/sudoers":
      owner   => "root",
      group   => "root",
      mode    => "440",
      
 
augeas   "addfootosudoers":
  context => "/files/etc/sudoers",
  changes => [
    "set spec[user = 'foo']/user foo",
    "set spec[user = 'foo']/host_group/host ALL",
    "set spec[user = 'foo']/host_group/command ALL",
    "set spec[user = 'foo']/host_group/command/runas_user ALL",
  ],
 
Snippet #3: Make sure that openssh-server is: installed, running on Port 222 and accepting RSA authentications only.
class openssh-server  
  package   "openssh-server":
      ensure => "installed",
   
    service   "ssh":
        ensure    => running,
        hasstatus => true,
        require   => Package["openssh-server"],
     
augeas   "sshd_config":
  context => "/files/etc/ssh/sshd_config",
    changes => [
    "set PermitRootLogin no",
    "set RSAAuthentication yes",
    "set PubkeyAuthentication yes",
    "set AuthorizedKeysFile	%h/.ssh/authorized_keys",
    "set PasswordAuthentication no",
    "set Port 222",
  ],
  
 
Snippet #4: Don t apply a specific IPTABLES rule if an host is tagged as staging in the relevant node file. On templates/iptables.erb:
<% if environment == "production" %>
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
<% unless defined?(staging).nil? %>
-A INPUT -s X.X.X.X -j REJECT --reject-with icmp-host-prohibited
<% end -%>
# Allow unlimited traffic on eth0
-A INPUT -i eth0 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
# Allow unlimited traffic from trusted IP addresses
-A INPUT -s 192.168.1.1/24 -j ACCEPT
<% end -%>
On the manifest file:
class iptables  
    package   iptables:
        ensure => installed;
     
    service   "iptables":
        ensure    => running,
        hasstatus => true,
        require   => Package["iptables"],
     
    file   "/etc/sysconfig/iptables":
        owner   => "root",
        group   => "root",
        mode    => 644,
        content => template("iptables/iptables.erb"),
        notify  => Service["iptables"],
     
 
That s all for now!

29 January 2012

Gregor Herrmann: RC bugs 2012/04

good news: from looking through RC bugs in the BTS, it seems that more & more people are starting to join the RCBW effort!

& here's my usual list for the past week:

28 January 2012

Russ Allbery: Summary of C++ symbols experience

This is a follow-up to my previous post about the way that Debian's library symbols analysis support interacts with C++ libraries, based on further debian-devel discussion. The primary outcome of that discussion was to point me at the pkg-kde-tools utilities for handling maintenance of these files, which solved a bunch of my problems. As before, this was also posted on debian-devel, which is where I expect most of the discussion to be. First of all, for those who haven't explored the pkg-kde-tools infrastructure for this, it looks like the effective process goes something like this:
  1. Do a local build of the package and then generate an initial symbols template for that architecture. So, for example, I did:
        fakeroot debian/rules build install
        pkgkde-gensymbols -plibxml-security-c16 -v1.6.1 -Osymbols.i386 \
            -edebian/libxml-security-c16/usr/lib/*/libxml-security-c.so.*.*
        pkgkde-symbolshelper create -o debian/libxml-security-c16.symbols \
            -v 1.6.1 symbols.i386
    
    This generates an initial symbols file that will work for i386.
  2. Build and upload this version of the package. Now wait for all the buildds to fail (because they will, on probably nearly every other architecture than your local one).
  3. Download all of the build logs and feed them back into pkgkde-symbolshelper so that it can adjust your symbols template for all of the architecture variations. So, for example, I did:
        pkgkde-getbuildlogs
        pkgkde-symbolshelper batchpatch -v 1.6.1 *_unstable_logs/*.build
    
    This will generate rather nice annotated symbols files with appropriate arch lists and using subst tags where appropriately (such as when an argument to a function is a size_t).
  4. Modify your package to use pkg-kde-tools during the build, because subst tags are a really nice way to handle a lot of C++ symbol patterns but #533916 against dpkg-dev is wontfix, so you need the pkg-kde-tools replacement for dpkg-gensymbols. I added a dependency on pkg-kde-tools and then added the (undocumented) pkgkde_symbolshelper add-on to my dh --with flag.
  5. Build and upload the package again. Now it will hopefully build on all architectures.
This is, as you might expect, a fair bit of work, but it does work, and what comes out the other end is a symbols file that works across the current buildd architectures and detects any mistakes by upstream that change the symbols exported. However, it does have some problems, some obvious, and some more subtle. Here's a list of the issues that I see:
  1. It feels like this symbols file is still likely to be fragile. While pkg-kde-tools detects a lot of template instances and marks them optional, I was still seeing a lot of "leaked" symbols from other C++ libraries that my package build-depends on, and which I suspect may also disappear. There's also the problem of optimizers eliminating some things that are inlined; for example, that appears to be the variation that my package sees on arm. And for a substantial C++ library, the symbols file is HUGE. Over 12,000 lines for one of my libraries. It's kind of scary to think of how many fragility landmines are buried under there.
  2. By the nature of this process, it's very sensitive to the current supported architectures. I expect any package with a symbols template built this way stands a good chance of FTBFS on a new architecture. For example, my symbols file has a lot of !armel !armhf patterns, which don't appear to be anything unique to arm except that the C++ compiler behaves slightly differently there due to inlining, and those are the only two architectures in the current set with that pattern.
  3. The lack of dpkg-gensymbols support for subst is very unfortunate, since it's used by the pkg-kde-tools utilities and it's the Right Thing To Do for symbols that take, for example, size_t as an argument. I would strongly encourage the dpkg maintainers to accept the work in #533916 except maybe for the vt work, since the alternative is to generate regexes that are significantly worse at capturing mistakes (since they're going to accept either int or long, rather than only whatever one corresponds to size_t, for example), or to embed a lot of specific architecture restrictions listing, for instance, all 64-bit architectures and guarantee FTBFS for every new architecture.
  4. It's a little hard on the infrastructure, since adding a symbols file requires uploading a package that's guaranteed to fail to build almost everywhere just so that you can get all the build logs to feed into the machinery. I always feel guilty about doing that.
  5. It's still not clear that the benefit is worth the amount of effort, since I expect most C++ libraries to require frequent SONAME changes anyway, which means that the long-term binary compatibility angle of symbols is probably futile. Mostly, all of this is to give you a tool to do ABI checking, which will catch some mistakes but not all of them. And I'm guessing it's going to be substantially more work than maintaining symbols for a C library if one actually does it properly and checks every missing symbol and change in new builds.
I'm going to try this for the Shibboleth packages for a while since I want to see what it's like across a new upstream release, but I'm still very much not convinced that this is a useful use of a packager's time.

27 January 2012

Rapha&#235;l Hertzog: People Behind Debian: Josselin Mouette, founder of the Debian GNOME team

Josselin Mouette is one the leaders of the pkg-gnome team, he takes sound technical decisions and doesn t fear writing code to work-around upstream issues. He deserves kudos for the work he has put into packaging GNOME over the years. He can also be very sarcastic (sometimes he even enjoys participating to flamewars on debian lists), and there are quite a few topics where we have long agreed to disagree. But this kind of diversity is also what makes Debian a so interesting place Read on to learn more about the pkg-gnome team, its plans for Wheezy, Josselin s opinion on the GNOME 3 switch, and much more. Raphael: Who are you? Josselin: I am a 31 years old Linux systems engineer. I started in life with physics, which I studied at the ENS Lyon. I started a thesis on experimental and numerical models for optoelectronics, but when it became clear that research was not for me, I abandoned it and accepted a job at the CEA, which holds the largest computing center in Europe. Working on these machines has been the most awesome job ever (except for it being near Paris). After that I worked a bit on system monitoring technologies. I am married, currently living in Lyon, and working for EDF (the French historical electricity company) on scientific workstations using Debian. EDF is using Debian on more than a thousand workstations and holds the fastest Debian supercomputer in the world (200 Tflops), which makes it another obvious place for Debian developers. Raphael: How did you start contributing to Debian? Josselin: I discovered Debian in 1999 while studying at the ENS, which is one of the biggest nests of Debian developers while being a small place, it is producing almost one Debian developer per year on average. After wondering for a while what it could be useful for, hacking on a slink snapshot made me think that it was for, well, everything except for gaming. Later, in 2002, when I was working on optoelectronics computing codes, I started to package them for Debian in order to make them easier to install, for us as well as other labs over the world. I started the NM process, and it was going smoothly but also going to take time. However, at that moment, the frozen-bubble game went out and made quite some buzz. Since I knew a guy who knew the game s developer, he asked me to package it. The package found 3 sponsors in a very short time and was fast-tracked into the archive at a speed that was unseen before. After which the NM process was completed very quickly. At that time, I was a heavy WindowMaker user, but I didn t like the direction the project was taking (actually, I wonder if there was one). GNOME was starting to become attractive, but its packaging in Debian was very ineffective, with many inconsistent packages maintained by people who didn t ever talk to each other some of them didn t speak English, and some of them didn t talk at all. Together with awesome people, among which Jordi Mallach, Gustavo Noronha Silva, JHM Dassen, Ross Burton and S bastien Bacher, we started the GNOME team in 2003, introducing consistent packaging practices, and initiating synchronized uploads. Releasing a completely integrated GNOME 2.8 in sarge was a considerable achievement; proving (together with the Perl team) that a team was the best way to maintain large package sets changed the way people work on Debian.
Proving [ ] that a team was the best way to maintain large package sets changed the way people work on Debian.
Raphael: You re one of the most active contributors of the team which is packaging GNOME for Debian. What would you suggest to a new contributor who would like to help the team? Josselin: There are several ways to contact the team, but the recommended one has always been IRC. We hang on #debian-gnome on the OFTC network, so just come around and ask for us. The real question is what you want to do in the team. Of course, most new volunteers want to help packaging the latest and greatest version of GNOME into unstable as soon as possible, but unless they already have Debian background, this is not the easiest task. Since there are already people working on this, the big packages are usually waiting on dependencies. I used to direct newcomers towards bug triage, but it is a tedious task and I m now convinced that our huge bug backlog will never be dealt with. The most useful thing to do for newcomers now is probably to find a GNOME or GNOME-related package that needs improvement or is lagging behind, and simply try to work on it. You can also come and fix the bugs you find annoying. Find a patch on the GNOME bugzilla, or cook it yourself, propose it, and if it s worthy enough you ll soon get commit access.
Our huge bug backlog will never be dealt with.
At this point I feel worth mentioning that if no one answers in 10 minutes, it doesn t mean that no one will answer in 2 hours, so please stay on the channel after asking. Raphael: There s been some controversy about GNOME 3 and the direction that the project is taking. What s your personal stance on GNOME 3? And what s the position of the pkg-gnome team? Josselin: The controversy is not new to GNOME 3, but the large-scale changes made with it have put it more prominently. The criticism usually boils down to a few categories:
  1. General lack of configurability
  2. Strange design decisions
  3. Red Hat centric development
  4. Hardware requirements
  5. Change resistance
The lack of configuration options has been an ongoing criticism since GNOME 2.0 has decided to rip off most of them. Of course, when the control center was redesigned again for 3.0, there was a surge of horrified exclamations from people who missed their favorite buttons. On this topic, I fully concur with GNOME developers. The configuration option that is useful for you is not necessarily useful for someone else. Of course, sometimes developers go a bit too far, but the general direction is right. At work, we found that only a minority of users actually configure anything on their desktops: they just want something that works to launch their applications. Apple and Google have sold millions of devices by making them the simplest possible and without any configuration. Design decisions are, on the contrary, individual decisions, and each of them, while having reasons behind it, can be questioned. I remember seeing a lot of complaints when the OK and Cancel buttons were reversed in dialog boxes, something that nobody questions anymore. GNOME Shell is full of such changes; some are easy to get accustomed with, some others just make eyebrows raise. The most obvious example is the user menu in GNOME 3.2, which contains an entry to configure your Google account, but no entry to shutdown the computer. Both decisions were taken independently, each of them with (good or bad) reasons, but the result is simply ridiculous. The default configuration in Debian will contain an extension to make it a bit better, but on the whole we don t intend to diverge from the upstream design, on which a lot of good work has been done.
On the whole we don t intend to diverge from the upstream design, on which a lot of good work has been done.
Point 3 is more complex. Red Hat being the company spending the most on GNOME, it is obvious that their employees work on making things work for their distribution. An example is the recurring discussions about relying on system services that are currently only implemented by systemd. Since there is a lot of (mostly unjustified) resistance against systemd in Debian, and since it won t work on kFreeBSD anyway, someone needs to develop an alternative implementation of these services for upstart and sysvinit. Everything is in place for someone else to do the job but it has to be done, and this can be frustrating. Especially since it can also be hard to integrate changes needed for other distributions . Hardware requirements are mostly a consequence of the previous criticism: there s hardware that most distributions just don t want to bother supporting. We ve seen it in squeeze with the introduction of a hard dependency on PulseAudio. The Debian GNOME team (together with the Gentoo maintainers) made this dependency optional, carrying heavy patches, in order to cover the cases where it does not work. Now that it has gained more maturity, making this effort obsolete, the new tendency is to require 3D acceleration. For various reasons, it is not available to everyone . On this matter, the position of the Debian GNOME team has always been to support as much different configurations as possible with reasonable effort. Thanks to efforts from the incredible Vincent Untz, upstream supports a so-called fallback mode , which is the GNOME panel from 2.x with a lot of its bugs fixed. We intend to support this mode for as long as reasonably possible in Debian, possibly even after upstream ends up dropping it. However, other applications are going to require 3D because GStreamer is moving to clutter too, affecting video playback performance on non-accelerated systems . For epiphany this is not a problem; only embedded video will be affected. But for totem, this is a major issue; because of that we will probably keep totem 3.0 in wheezy. Finally, there is a natural human tendency to dislike change (I have it too), and it applies a lot to desktop users habits. Needless to say a change of such a scale as introducing GNOME Shell can trigger reactions. However, I don t think it is reasonable, because of this resistance, to keep gnome-panel 2.x in Debian. This would be a lot of work on obsolete technology, and would prevent the upcoming removal of a lot of deprecated libraries. This time is much better spent improving gnome-panel 3.x in Debian and keeping the fallback mode great. One of the change that was made in Debian was to make it easier to find, being available as GNOME Classic directly from the login manager, instead of having to find it in an obscure configuration panel. In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it. I had never been accustomed to a new environment as quickly ever before.
In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it.
Having seen several of my GDM patches reverted without a warning, I know we are not finished with carrying patches in Debian packages.
Scientific workstations are a non-trivial example, since there is a measurable effect of using 3D in the window manager on heavy 3D applications.
On the other hand, on accelerated systems, this feature should end up improving performance a lot. Raphael: What are your plans for Debian Wheezy? Josselin: The first goal of the GNOME team is, of course, to provide again a great desktop environment to work on. For wheezy it will probably be based on GNOME 3.4. There also needs to be some work on package management interfaces. Upstream bases everything on PackageKit, but it is not as featureful as the aptdaemon Ubuntu technology. If I have time, I would also like to improve HTTP proxy support, since currently it is based on a stack of terrible hacks. Raphael: If you could spend all your time on Debian, what would you work on? Josselin: Obviously I would like to make GNOME in Debian even better. That would imply working on underneath dependencies (what we now like to call plumbing) to make sure everything is working great. This would also imply working more as GNOME upstream to make it more suitable for our needs. I would also work on large-scale improvements on the distribution, like conditional recommends which I d love to see implemented , or automatic build-dependency generation. I would also work on the installer to make it better for desktops machines. The idea is to automatically install language packs, or glues between two packages when both packages are installed. Raphael: What s the biggest problem of Debian? Josselin: The obvious answer is the same as the one most people you interviewed before gave: not enough members in core teams. A lot of developers join Debian to work on a small number of pet packages, and don t necessarily want to be involved with existing teams. It is probably still not obvious enough that the primary way to start contributing to Debian is to join an existing team. But if there is one thing that is preventing Debian from gaining more momentum now, it is a completely different one: the too short support timeframe. 3 years is really not enough for corporate users. One year to migrate from one version to another is too short, and it is not possible to skip a release. It is definitely possible to change that with reasonable effort: the long-term support after 3 years doesn t have to cover the same perimeter as the short-term one. For example, we could upgrade the kernel to the version in the current stable release, and stop fixing all non-remote security holes. The important thing is to cover the most basic needs: companies are ready to take the risk of having less support if it allows skipping a version, but not the risk of having no support at all. And even more important is to say that you do something. Red Hat says they support a release for 10 years, but of course after 5 years the supported perimeter is extremely small.
3 years [of support] is really not enough for corporate users.
Long-term support will not magically fix all problems in Debian, but it will bring more corporate users into the picture. And with corporate users come paid Debian developers, who can work on critical pieces of the system. Debian was built on the synergy between individuals and companies, and in recent years perhaps as a reaction against what happened with Ubuntu we ve kind of forgot the latter. A lot of individuals have joined the project, and they are actively working, for example, on shortening the release cycle, which goes against the interest of professionals. We should embrace again such users and developers, and that means adapting to the current needs of larger entities. Raphael: You re the maintainer of python-support, a packaging helper that was competing with python-central. Both helpers are now deprecated in favor of dh_python2. Does this mean that the situation of Python in Debian is now sane? Or are there remaining problems? Josselin: dh_python2 (and the Python3 version, dh_python3) has a sane enough design. It fixes a lot of issues in python-central and also python-support, at the expense of somehow reduced functionality for developers. However, just like the previous tools, it merely works around design mistakes in the Python interpreter. For example it is not possible to split binary modules, pure-Python modules and byte-compiled modules in different directory trees, like Perl does although PEP 3147 introduces a way to do so. There is still no sane and standardized way to deal with module versions. There is no difference made between the module (which is a part of language semantics) and the file containing it (an information which depends on the implementation). Developers heavily rely on introspection features and make assumptions based on the implementation, that make it impossible to work around problems with module files. Such problems are not restricted to Python. Those who fought against Ruby gems could tell even worse stories. While introducing GObject introspection packages in Debian (they can be used in JavaScript and Python to provide modules based on GObject libraries), I was pleased to see a clear distinction between file and module, but I was again struck by the fact you are not forced to declare API versions in your Python/JS code. In all cases, there is no reliable way to detect runtime dependencies in a given Python or JavaScript file, which leaves the maintainer to declare them by hand, and of course, often be wrong about them. Add to that the fact that most errors cannot be detected before runtime. For all these reasons, and while still being fond of Python for scripts and prototyping, I ve become really skeptical of using purely interpreted languages to write real applications. Some GNOME developers are moving away from Python and JavaScript, mostly towards Vala; I can only approve of that move and hope the same happens to other projects. Raphael: Is there someone in Debian that you admire for their contributions? Of course there is the never-sleeping, never-stopping, Michael Biebl who can upload a whole GNOME release in a single week-end. But there are a lot of awesome people who make Debian something that simply works. I could talk about Cyril Brulebois from the X strike force, Julien Cristau from the release team, Sjoerd Simons for his sound advice and work on plumbing, Luca Falavigna who is so fast at processing NEW, to quote only a few of those I work with frequently. And of course, Jordi and Sam for their humor.
Thank you to Josselin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook .

8 comments Liked this article? Click here. My blog is Flattr-enabled.

18 January 2012

John Sullivan: Sent to the ACLU today

I was on the brink of mindlessly clicking through the ACLU action center as usual to send an email opposing SOPA. But then I read their boilerplate text, and ended up cancelling the letter to my rep and instead sending this quick note to the ACLU:
Your SOPA suggested letter text supports current copyright law, and also backhandedly supports PIPA (the Senate version of the bill). This is far too weak of a position. As a donor, I ask you to take a stronger position that current copyright law unjustly restricts free speech, and that no further enforcement measures should be instituted until that fundamental problem is addressed. At least take on BOTH of these bills strongly. Most of the significant Internet is blacked out today to oppose both bills -- why would you cede so much ground to copyright maximalists? We have the support to oppose and defeat both bills.
For reference, here was their text:
While I believe it's important to protect copyrighted material online, the language of the Stop Online Piracy Act (SOPA) is flawed and will lead to the blocking of lawful content. Unlike the Senate version of the bill, SOPA eliminates the concept of sites 'dedicated to infringing activity' and enables law enforcement to target all sites that contain some infringing content -- no matter how trivial. The potential for impact on non-infringing content is much greater under SOPA than under other versions of this bill. Sites with user-generated content, like YouTube, Twitter, and Facebook, would be especially vulnerable, as one small piece of infringing content could lead to blocking the entire site. Even though proposed changes would narrow the amount of lawful content impacted, the changes don't go far enough. It is still likely that search engines will end up blocking access to perfectly legal online content. Congress should focus not just on the goal of protecting copyright owners, but also protecting the speech rights of consumers and providers who are reading and producing wholly non-infringing content. Congress must eliminate the collateral damage to protected non-infringing content. Only in that way will Congress truly achieve its goal of protecting authors while respecting the constitutional right to free speech.
Maybe I'm overreacting, but I dislike it when good organizations take weak positions unnecessarily. Usually this is not a problem with the ACLU, for me. It doesn't help that I keep seeing this meme everywhere in the anti-SOPA/PIPA conversation: "I agree we need to do something about piracy, but not this..." I don't think we need to do anything to fix violations of an extraordinarily unjust law until the law itself is fixed. I don't find that to be a very radical position.

16 January 2012

Yves-Alexis Perez: Advocating people for hardware sponsoring

Our Dear Project Leader, Stefano Zacchiroli, regularly mentions the fact that there's an amount of Debian money available for hardware sponsoring of Debian developers, but it seems that not much people benefit from it. Each time I saw one of this reminder, I wonder if I should apply, and the anser is usually no. The fact is that I don't think any new laptop or desktop to do my Debian stuff, and the last time I bought a box (my x201s last summer) it was not really specifically for Debian tasks so I didn't dare to ask (not to mention the fact I bought it because I did have the money to do so). And I think this is mostly the problem. I might be wrong, but I think that most people which could benefit from this just don't dare asking or don't estimate themselves eligible for it. When I saw Ben Hutchings post, where the first thing he says is about how hardware is expensive, I thought hey, he should get some Debian money for buying new hardware: building kernel is really time consuming and having multiple powerful cores, more ram and fast disks/SSDs really helps . Turns out that Ben just didn't really want to spend too much money there, but the case still stands. We also see from time to time people saying they'll be offline for a while because of broken laptop or something like that. Once again, maybe those people wouldn't mind some help from the Debian project, and maybe they just don't think about asking, or they don't dare. So thinking about it a bit more, I think I wouldn't dare asking money for myself, but maybe I could dare asking money for other people (this is a bit like the flattr posts by Rapha l Hertzog, where he incited people to give money to projects he liked). If I'm not alone in this case, maybe those Debian developers who think some of their peers would benefit some hardware could drop them a mail with leader@ on copy, to propose just that. No need for huge publicity on that (in order to not embarass people), though the transparency rules still apply when it comes to Debian money.
What do you think? It's not really a formal proposal (thus the post on my blog and not a mail to -project), but if that fits you, then nobody prevents you to start yourself. And if you consider it a bad idea, well, nothing forces you to do anything.

15 January 2012

Scott Kitterman: LEGO MINDSTORMS NXT 2.0 Support in Debian/Ubuntu

A LEGO MINDSTORMS NXT 2.0 recently arrived at our house. Of course it only comes with proprietary support for Windows/Mac, so I set out to see what FOSS support for the hardware I could find. I found nxt-python. It wasn t packaged, so I packaged it up and uploaded to Debian (from whence it came to Ubuntu). It s now in for the next release of both distributions (Wheezy/Precise). This is a bit different than the provided software (which compiles code, downloads it to the NXT, and then runs it untethered). For nxt-python the nxt needs to be connected to your computer via USB or bluetooth. It s a lot of fun and it s given me a chance to introduced our youngest child to the idea that there s more to computers than point and click. Currently user level access to the device doesn t work, it has to be accessed by root. Fixing that is on my TODO. I hope someone else out there has an NXT and enjoys this too. UPDATE: Added a udev rule and uploaded again, so anyone in plugdev can access the NXT brick.

14 January 2012

Lior Kaplan: Israel to recognize software patents

The Israeli patent registrar have reverted previous ruling regarding patents on software and published a draft for the procedures to accept such patents. The procedures are open to public comments for the next 30 days. Two years ago the patent registrar have started to consider revising the the issue and got many position papers (e.g. Hamakor s papter). At the end he decided not to accept patents on software. De facto, at least one such patent (US patent 7,596,609) was accepted to be valid in Israel after that ruling. Now that the rulings is reverted, I guess will see many more software patents granted here. I wonder about the implications on the local software market hopefully it won t stagnate due to patent wars such as the ones we see every now and then in the US.
Filed under: Software Patents

13 January 2012

Steve Kemp: Some misc. updates

Security
Today I made available a 3.2.0 kernel for my KVM guest which has a bastardised version of the PID hiding patch configured: So now on my guest, as myself, I can only see this:
steve@steve:~$ ls -l /proc/   egrep ' [0-9]+$'
dr-xr-xr-x  7 steve users          0 Jan 13 17:22 15150
dr-xr-xr-x  7 steve users          0 Jan 13 17:29 15739
dr-xr-xr-x  7 steve users          0 Jan 13 17:29 15740
lrwxrwxrwx  1 root  root          64 Jan 13 17:20 self -> 15739
Running as root I see the full tree:
steve:~#  ls -l /proc/   egrep ' [0-9]+$'
total 0
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1052
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1086
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1101
dr-xr-xr-x  7 root        root                 0 Jan 13 17:20 1104
dr-xr-xr-x  7 root        root                 0 Jan 13 17:21 1331
dr-xr-xr-x  7 pdnsd       proxy                0 Jan 13 17:21 14409
dr-xr-xr-x  7 root        root                 0 Jan 13 17:21 14519
..
This (obviously) affects output from top etc too. It is a neat feature which I think is worth having, but time will tell..
mod_ifier
A long time ago I put together an Apache module which allowed the evaluation of security rules against incoming HTTP requests. mod_ifier was largely ignored by the world. But this week it did receive a little attention. The recent rash of Hash Collision attacks inspired inspired a fork with parameter filtering. Neat.
Otherwise nothing too much to report - though I guess I didn't actually share the link to the RESTful file store I mentioned previously. Should you care you can find it here: ObQuote: "I saw a man, he danced with his wife" - Chicago, Frank Sinatra

C.J. Adams-Collier: The Very Model of a Poster to CLPM

So, in 2002 I attended my first SPUG meeting. Also in attendance were Randal, Tim, J.P. (I think) and quite a few of the other usual suspects. The guest speaker was the inestimable Dr. Damian Conway. This night might be the single most important event in my career as a builder of the internets. I was already set in my ways regarding my operating system, and I knew enough perl to get by, but I wasn t in touch with any users groups until then. The crown jewel of the night was Damian s recital in full of his poem, I Am The Very Model of A Poster To CLPM (sung to the tune of that song from Pirates of Penzance). I must admit that I d never heard of CLPM and that it all sounded like gobble-de-gook at the time. If I recall correctly, this happened just after he took about 10 minutes to teach us all to pronounce the name of then-Pumpking, Jarkko Hietaniemi. This was the same year that the following video was made <iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube.com/embed/XkU_GQVOCqo" width="420"></iframe> With that in mind, there s one more thing I need to share with you before disclosing the lyrics. This piece was developed during a time when it was common for members of the perl community to flame one another on news feeds, take their anger and frustration out on newbies and generally be the bane of most of the internet. I like to think that it helped to shape me into a kinder, gentler perl programmer, debian user and general netizen over the years. I would also like to think that it will do the same for future members of our communities. And so, without further ado, Damian Conway s
I Am The Very Model of a Poster to CLPM Now everything I need to know about the Perl community
I learned in kindergarten when I was a little lad of three
And in these next few minutes I ll relate those five apothegm
For I am the very model of a poster to c.l.p.m. The first truism I was ever taught upon my mother s knee
Was that our dad s a better dad than their s could ever hope to be.
His name is Larry Wall, and that s determinism nom native
Since of the mural attributes he demonstrates proof positive. He s eight feet tall and ten feet wide; of granite-like solidity.
He wards us from the serpent s tabs and coffee bean s stupidity.
He guards us from that Gallic tower s B&D urbanity,
And makes sure we don t see sharp code that might cut loose our sanity. He watches over each of us, like Odin of the Norse belief
The stern All-Father figure and, at times, the comical relief.
So, if you vaunt our patriarch s supreme linguistic acumen,
You are a model sychophantic poster to c.l.p.m. The second tenet that I learned concerns, of course, the fairer sex
And why they are in short supply, while geek-boy JAPHs are multiplex.
As every schoolboy knows each conversation has single aim:
To raise one s own significance, whilst razing others down in flame. And thus good men and true who hold this principle as sacrosanct
Will all pursue beligerence as though they were from Mars. Or tanked.
It is the tenor of your newgroup posts that she from Venus flies:
Because most threads devolve into comparisons of ..meanness, guys. When every post affronts their own collaborative sorority
It must exasperate them, for it renders the majority
Of female Perl geeks absent, till we re forced to rename blonde Dutch men
To act as female models of a poster to c.l.p.m. The third grand aphorism that was drummed into my youthful head
Was: if you can t say something nice about someone, you should instead
Say every nasty thing you can impart, imagine, or invent
In any public forum that it happens you should both frequent. This goes especially for the young, and new, and shy, and innocent.
To flame a newbie is a joy, t will make you feel omnipotent.
To watch them squirm and bleat and bleed and scurry back into their hole,
The surge of ecstasy it brings is worth the way it eats your soul. So never hesitate to turn the wrath of your vocabul ry
Upon the hapless supplicant for Perl epistomology
And if you flame each FAQ, and every question that s beneath you then
You ll be the very model of curmudg nly R.T.F.M. The next point I should like to make s the obverse of the previous
For while it s true that to be newbie is a sin most grieveous
It ain t as bad as being old and greyed and staid and tedious
And sitting at the keys all day dispensing thoughts invidious. What right have you to tell me not to ask about my CGI???
I thought that Perl was all about website development, and I
Expect that you d extend to me the simple human courtesy
Of dropping everything so you can do this homework now for me. The Internet exists so I need never read the manual
And so my inane questioning can form a stream continual
While pleading for an email since I never read this group, as well
As posting them in jeopardy, in caps, and in HTML. The rule I learned in kinder that explains where this approach springs from
Is fundamental to a certain class of Gen-X hackerdom
The single principle that guides their Internet activity
Is: me, me, me, me, me, me, me, me, me, me, me, me, me, me, ME! So if you are prepared to treat the Net as your god-given right
And suck the newsgroups dry like some goodwill-devouring parasite
And use them as a help-desk and a perldoc substitute, well then
You are the very model clueless poster to c.l.p.m. The final precept that my pre-school inculcated in my head
Is one I would commend as antithetical to all I ve said.
It is a noble concept that once used to garner more elan
The idea that, when I grow up ..I want to be a fireman. The fire-fighter s job s to help, despite the inconvenience
And spare the inexperienced the cost of their own ignorance
And put out fires when the flames ignite the common living space
And through it all maintain an air of competence and skill and grace. And this, my friends, I recommend to all of our community
That rather than a careless match or carefully lit incendiary
You spray out knowledge, patience, and a gentle stream of good advice
And save the newbies from themselves, and oldies from their prejudice. And be yea more as Larry is, a fire-Wall against the threat
Of ignorance and arrogance, with both of which we re still beset.
For if you choose to help your fellow JAPHs instead of scorching them,
You ll be the next burnt offering we spit-roast on c.l.p.m. ;-) [edit]

8 January 2012

Niels Thykier: Testing migration and package relations

While looking at the dpkg Breaks-field[0]
$ aptitude show dpkg
Package: dpkg
[...]
Version: 1.16.1.2
[...]
Breaks: apt (< 0.7.7), aptitude (< 0.4.7-1), dpkg-dev (< 1.15.8), libdpkg-perl (< 1.15.8), pinfo (< 0.6.9-3.1), tkinfo (< 2.8-3.1)
it occurred to me that most (all?) of these relations were irrelevant to Britney when she migrated dpkg 1.16.1.2 to testing. Right now, at least the APT relations are only relevant if you are doing something like a distribution upgrade from Lenny/Squeeze to Wheezy. Similarly, the version constraints in a lot of dependency relations (e.g. libc6 (>= 2.11) ) are satisfied in testing and unstable at the same time. Removing the version constrains on dependencies is a rather minor thing as it is basically just a minor constant time optimization on each dependency check. However, removing an entire clause slightly reduces the problem size a bit. Particularly, the Conflicts/Breaks relations tends to be expensive for us. The first task was to identify the relations that can (or cannot) be simplified. In a Britney run we at most 4 versions of the same package per architecture, though usually only 1 or 2[1]. I devised a small set of rules to simplify the relations. These rules are applied to each package in the relation (atomic proposition, if you will).
  1. If the relation is versioned and it involves a virtual package in any suite, then do not change the relation in any way. Rationale: A virtual package cannot satisfy any versioned relation (Policy Manual 7.5)
  2. If the relation is a dependency (i.e. Pre-Depends or Depends) and the package is not available in any suite, then do not change the relation in any way.
  3. If the relation is versioned and the relation is satisfied in all suites (where the relationed-on package is available), then remove the version constrain. Rationale: If all (present) versions satisfy the relation, then version constrain does not change the semantics.
  4. If the relation is a conflict (i.e. Conflicts or Breaks) and relation is unsatisfiable in all suites, then remove the relation. Rationale: If none of the (present) versions satisfy the conflict-relation, then there is no conflict[2].
The rules are rather conservative in some cases and there is room for improvements. However, one has to remember that removing too few relations costs a bit in runtime, removing too many breaks testing and possibly a lot. Obviously, I prefer the former to the latter (especially because I will be a part of the clean up -crew). I tested my implementation of those four rules above against the current master branch. In short, it produces the same result as the master branch in all the tests so far. In the hand-made test-suite, the tests generally do not have any superfluous relations. Thus, it is slightly slower, though usually within 0.1 seconds of the master branch. On the other hand, in the live-data samples I have collected so far it does vastly better. For the longest run (sample from 2011-12-13), it reduces the runtime with ~70 seconds (from ~215 to ~145 seconds). In the other runs, it reduces total runtime with ~35 and ~2 seconds, respectively. In these samples, only the amd64 and i386 packages are considered (and human hints are ignored). For those interested, the code is available in my branch. :) [0] There is perfectly valid reason for doing that. I might get back to that in a later post. [1] One in unstable, testing, testing-proposed-updates and proposed-updates. The latter may seem a bit weird, but [0] [2] This is the rule that prune relations like the one in the dpkg Breaks-field. Edit: 2011-01/09, clarified that we have at most 4 versions per architecture.

7 January 2012

Craig Small: rpath bites me again

Debian OpenLogo

Image via Wikipedia

It s funny, in bad way, when certain sorts of bugs come back to bite you. People may remember the fun debian had with rpath issues around in the late 90s where some binaries wanted to set the path of where their libraries were located. After much contraversy the consensus was at least in Debian (with some specific exceptions) RPATH is bad and don t use it. I lived through that fun and remember hacking libtool or autoconf or some such file. The horror of those times came back to haunt me today while working on procps 3.3.2 packages. lintian was suddenly complaining that binary-or-shlib-defines-rpath for all my binaries. I ve not seen rpath set for many years and as I m also part of the upstream and never saw it set there it took me a while to work out what was going on. Certainly, my binaries were setting the RPATH, it wasn t lintian getting the wrong idea. You can see this with objdump myfile grep RPATH. If you get a hit, you got RPATH set, an empty result means no RPATH. libtool was definitely setting the rpath, with
cc -Iproc -g -O2 -o \$progdir/\$file pmap.o  ./proc/.libs/libprocps.so \
 -Wl,-rpath -Wl,/home/csmall/debian/procps/procps/proc/.libs \
 -Wl,-rpath -Wl,//usr/lib/x86_64-linux-gnu
That s not one rpath setting but two, for double insult. Configure flags such as disable-rpath wouldn t work. I flicked back to a pure upstream archive and there was no rpath there in either the compile flags or objdump. There was obviously some sort of side-effect going on. The problem, after much testing, was in the debian/rules file:
        ./configure \
          --build=$(DEB_BUILD_GNU_TYPE) \
          --enable-watch8bit --enable-w-from \
          --prefix=/ \
          --mandir=\$$ prefix /usr/share/man  \
          --libdir=\$$ prefix /usr/lib/$(DEB_HOST_MULTIARCH)
The problem is above, and all it was was a / . libtool does some checking to see if the library directory exists and if it doesn t silently turns on rpath. It s not smart enough to know that //usr/lib/x86_64-linux-gnu is the same as /usr/lib/x86_64-linux-gnu and so it enables rpath. Removing the slash before the usr fixed the problem. I d say this is bad behavour on libtools part. It should know that / is // or all the other alternative ways of specifying paths. Hopefully this post will stop someone else wasting their time like I did.

4 January 2012

Kartik Mistry: Wikipedia takes Ahmedabad

* This post is almost translation of my this post on Gujarati blog (with some corrections and additions etc). If you re not interested in Wikipedia, move on. So, as I mentioned here and here, Wikipedians in Ahmedabad planned event: Wikipedia Takes Ahmedabad. We gathered at Gandhi Ashram. Met Noopur again and some volunteers were already there at 8 AM. I never been to Ashram since long time. This place has something, you know it, folks! People started coming around 8.30 and we quickly divided them based upon their interests on 4 routes we already decided. Most of people went to old city s route 1 and our route 2 had odd 6 (and 2 coordinaters) people only. Good. Less is always good. Noopur and Anirudh gave introduction to wikipedia, creative commons license and some basic rules and todo. We then left for Swaminarayan Temple at Sahibaug. We asked for permission to take photographs and we got it after meeting main swamiji there along with nice sweets and he promised to send professional picture for wikipedia to use. We then left for Delhi Darwaja. Ahmedabad has numbers of old fort gates. We covered some of them and moved to Kalupur Railway Station. Palak and Chirag were caught by traffic police and we should take care of following rules from next time. Point noted for next photowalk. We then left for Zulta Minar. This is well known for its carving and some myths associated with it. We discussed some points regarding uploading pictures, categories and left for Raipur Darwaja. This place is famous for Bhajiyas. We didn t taste it but had again fun taking pictures, talking to police and had smile before we leave for home. Only bad thing I ve got in this walk is that due to some or other reason my phone s touch screen seems stopped working :( That s another topic, but I couldn t call Noopur/Anirudh for lunch etc due to that :) You can view all uploaded pictures at: Categories: Ahmedabad 1 Most of Ahmedabad is covered due to event. Time to write articles?

3 January 2012

Rapha&#235;l Hertzog: My Debian Activities in December 2011

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (364.18 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg and Multiarch I had some hope to have a multiarch-enabled dpkg in sid for Christmas as Guillem told me that it was realistic. Alas Guillem got sick. We re in January and we re still not there. While some of Guillem s commits in December were related to multi-arch, the size of his pu/multiarch/master branch did not really shrink. We still have 36 commits to merge most of the work he did was refactoring some parts of the code that were already merged. And he initiated some discussion on interface changes. I participated to those discussions hoping to bring them to a quick resolution. I m still maintaining my own pu/multiarch/full branch, it is based on Guillem s branch but with further fixes that I developed and that he has not yet merged and with a change reverted (Guillem s branch allows crossgrading packages between different architectures while dpkg does not manage this correctly yet). I can only hope that January will be the last month of this never-ending saga. It s been one year since I started working on this project. :- Misc dpkg work I reviewed (and later merged) a patch of Kees Cook to enhance dpkg-buildflags so that it can report which hardening features are enabled. This feature might then be used by tools like lintian to detect missing hardening features. I mentored Gianluca Ciccarelli who is trying to enhance dpkg-maintscript-helper to take care of replacing a directory by a symlink and vice-versa. I took care of #651993 so that dpkg-mergechangelogs doesn t fail when it encounters an invalid version in the changelog, and of #652414 so that dpkg-source --commit accepts a relative filename when a patch file is explicitly given. Guillem also merged a fix I developed for LP#369898. Packaging work WordPress 3.3 came out so I immediately packaged it. Despite my upstream bug report, they did not update their GPL compliance page which offers the corresponding sources for what s bundled in the tarball. So I hunted for the required sources myself, and bundled them in the debian.tar.xz of the Debian source package. It s a rather crude solution but this allowed me to close the release critical bug #646729 and to reintroduce the Flash files that were dropped in the past which is great since the Flash-based file uploader is nicer than the one using the browser s file field. Quilt 0.50 came out after 2 years of (slow) development. The Debian package has many patches and several of them had to be updated to cope with the new upstream release. Fortunately some of them were also merged upstream. It still took an entire morning to complete this update. I also converted the packaging from CDBS to dh with a short rules file. Zim 0.54 came out and I immediately updated the package since it fixed a bug that was annoying me. Review of the ledgersmb packaging As the sql-ledger maintainer (and a user of this software for my accounting), I have been hoping to get ledgersmb packaged as a possible replacement for it. I have been following the various efforts initiated over time but none of them resulted in a real package in Debian. This is a real pity so I tried to fix this by offering to sponsor package uploads. That s why I did a first review of the packaging. It took several hours because you have to explain everything that s not good enough. I also filed a wishlist bug against lintian (#652963) to suggest that lintian should detect improper usage of dpkg-statoverride (this is a mistake that was present in the package that I reviewed). nautilus-dropbox work I wanted to polish the package in time for the Ubuntu LTS release and since Debian Import Freeze is in January, I implemented some of the important fixes that I wanted. The Debian package diverges from upstream in that the non-free binaries are installed in /var/lib/dropbox/ instead of $HOME.
Due to a bug, the files were not properly root-owned so I first fixed this (unpacking the tarball as root lead to reuse of the embedded user & group information, and those information changed recently on the Dropbox side apparently). Then we recently identified other problems related to proxy handling (see #651065). I fixed this too because it s relatively frequent that the initial download triggered during the package configuration fails and in that case it s the user that will re-trigger a package download after having given the appropriate credentials through PackageKit. Without my fix, usage of pkexec would imply the loss of the http_proxy environment variable and thus it would not be possible for a user to download through a proxy. Last but not least I reorganized the Debian specific patches to better separate what can and should be merged upstream, from the changes that upstream doesn t want. Unfortunately Dropbox insists on being able to auto-update their non-free binaries, they are, thus, against the installation under /var/lib/dropbox and the corresponding changes. Book update We re making decent progress in the translation of the Debian Administrator s Handbook, about 6 chapters are already translated (not yet reviewed though). The liberation campaign is also (slowly) going forward. We re at 67% now (thanks to 90 new supporters!) while we were only at 60% at the start of December. Thanks See you next month for a new summary of my activities.

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

1 January 2012

Cyril Brulebois: X server 1.12 RC1

It s this time of the year again: a new X release approaches. The upstream schedule has been delayed a tiny bit so that the multitouch changes could land in master during this merge window. Which is what happened, a few days before Christmas. The other components involved in XI2.2 (aka. multitouch ) were packaged in experimental while the server side was getting prepared: Given we reached the 1.12 RC1 stage, it s a good idea to start building drivers against the new server to make it possible for users to perform some tests. And as usual, a new server means bumped input and video ABI, meaning a rebuild for the drivers to pick new dependencies. Some of them also needed a few fixes to make them build against the new server. Nothing that can t be fixed with a few merges from upstream master branches. The usual set of major drivers was uploaded to experimental: Significant change on the intel side: a snapshot of the current master branch was created, and packaged with SNA support enabled. SandyBridge's New Acceleration has apparently reached a point where it can be published to the masses, so here we go. Some details about it can be found in the initial commit. Also, for those wondering about the xorg-server FTBFS on some architectures, fixes are pending. Happy new year.

Next.

Previous.