You are viewing np237

15 February 2013 @ 05:11 pm

Following the DPL game call for players, here are my nominations for the fantastic four (in alphabetical order) :

  1. Luca Falavigna
  2. Tollef Fog Heen
  3. Yves-Alexis Perez
  4. Christian Perrier

These are four randomly selected people among those who share an understanding of the Debian community, a sense of leadership, and the ability to drive people forward with solutions.

07 February 2013 @ 12:33 pm
22 January 2013 @ 03:33 pm

GNOME 3.4 for Debian wheezy is shaping up quite well. A handful of bugs remain to be fixed, but we are now in a polishing phase, as expected given the freeze status.

With upstream introducing heavy changes in new versions, it is time to think of what will happen with GNOME when we introduce version 3.8 in unstable. Namely, there are two categories of changes that have a heavy impact on Debian:

  • several components now heavily relying on systemd for components that interact with low-level parts of the system,
  • the fallback code (a.k.a “GNOME Classic”) being removed, causing problems for people without 3D support – for x86 this shouldn’t be a problem thanks to llvmpipe, but i386 and amd64 are not the only architectures we want to support.

Upstream is not hostile to people working on making their modules compatible with these setups (non-3D, non-systemd). However, there is a limit to what the Debian GNOME team can do, and people have to make choices.

The consensus in the Debian GNOME team is to focus the extra amount of work we can provide to the fallback code. We are already in touch with other distributions and people who are interested in keeping the differences with upstream GNOME minimal. Our common goal is to be able to provide a GNOME installation for all Linux systems, with or without 3D.

However, none of us is willing to spend time on getting GNOME to work without systemd. We will not work actively against it either, but some components will certainly recommend systemd, and the functionality with other init systems will be degraded. So if people want to keep GNOME fully working on non-Linux systems, now is the time to start hacking on the missing pieces for this to work. For the time being, it does not look infeasible – although we don’t know what jessie will be made of.

30 November 2012 @ 12:48 pm

Have you ever wondered one of those?

  • How does this plumbing behind GNOME actually work?
  • What are all these processes on my system here for?
  • How can I manage user permissions for system actions?
  • How can I override or force user configurations?
  • How do I configure GDM?
  • What can I do with NetworkManager?

For those who weren’t at Mini-DebConf Paris 2012 last week, let me share here again the slides:

Large deployment of GNOME from the administrator’s perspective

These questions, and many others, will find the beginning of an answer here. At the very least, I hope to show people leads on where to find relevant information for their needs about administrating GNOME systems.

22 November 2012 @ 11:51 am

Today I tried to translate a German sentence posted by mistake on an English IRC channel.

For that, I used Google translation.

I think there is a message here about what country KDE comes from…


So, there is some history of organisations doing a poor job at managing security bugs.

We saw the “This is not really a security hole” jokes just to avoid having bad statistics in the front page. We saw the “OMFG you must update to the latest version RIGHT NOW and no I’m not telling why” panic.

We still frequently see security fixes hidden in unrelated public commits, just to make them harder to backport for distributors.

But really, there is absolutely no match for that. Kudos for setting a new standard in the worse way of dealing with security issues, guys.

Update: one of the developers has started insulting a pair of professional IT security experts who came and tried to educate him. Awesome reading, don’t forget the popcorn.

03 November 2011 @ 08:05 pm

When George Papandreou announced its will to submit the European “help“ program to the approbation of the Greek people, I don’t know whether he wanted to scare people, but man, he really achieved something. From Wall Street to the Bundestag, through the Élysée Palace, they are all in a state of advanced panic. There’s a joke that’s been circulating since: for next Hallowe’en, disguise yourself as a referendum.

Yes, these guys are afraid. Afraid of the people. They are afraid because it is now clear that their interests are not the same as the interests of the people. And what do you do when you are afraid? Well, you find yourself some way out, often by lying.

And indeed, Mrs Merkel and Mr Sarkozy have been repeating over and over something that has been then repeated over and over by most so-called journalists: that Greeks can only choose between two endings:

  1. they pay their debts to banks and rich people, and stay in the Euro zone;
  2. they don’t pay their debts to banks and rich people, and find themselves another currency.

That’s it: Mrs Merkel and Mr Sarkozy are outrageous liars.

There is another option for Greek people:

3. they don’t pay their debts to banks and rich people, and they stay in the Euro zone.
It’s as simple as that: nothing in European treaties can force a country to leave the Euro zone. And nothing in these treaties can force a country to honor their bonds. Greece is a sovereign state and, as such, can choose not to honor its sovereign debt. And choose to stay in the Euro zone: why would they want to go out? What does it have to do with the currency those bonds have been emitted in? If California were to cease payment of its public debt (something not likely to happen at all, hmm?), would it have to abandon the Dollar?

But here is a thing that has been forbidden for a long time in European treaties: for a country to help financially another one to pay its debts. This rule was introduced by Jacques Delors (a man who knows what being European means) precisely in order to avoid the contagion we are facing currently because of stupid “help” plans all across Europe. Yes: the whole idea of Merkozy’s grand plan to “save Euro” while “helping Greece” (a weird kind of help, starving people, really) is illegal. So in addition to being liars, Mrs Merkel and Mr Sarkozy are delinquents.

So let Greece cease payment of its debt. A few banks will sink: so what? This will create less unemployment than letting our whole economy sink. European States will guarantee citizens’ savings up to 30 k€, that’s one of the other clever European rules (some countries guarantee more). Other people, rich people only, will lose their savings. Will that prevent you from sleeping? Not me. But that could prevent from sleeping a number of friends of Mrs Merkel’s and Mr Sarkozy’s.

And wouldn’t that be a good reason for lying and violating European treaties?


So I just read that Google will only support “modern browsers” starting 2 months from now.

As of August 1st, we will discontinue support for the following browsers and their predecessors: Firefox 3.5, Internet Explorer 7, and Safari 3. In these older browsers you may have trouble using certain features in Gmail, Google Calendar, Google Talk, Google Docs and Google Sites, and eventually these apps may stop working entirely.

Given the importance of Google, the impact is huge. This company has acquired the power to basically dictate what browser you can provide to your users - otherwise they won’t be able to access what many of them now consider vital functionality.

Such a decision denotes a grave misunderstanding of the workstation ecosystem from the Google people. It means they consider their only target to be nerdy users with home computers they can (and want to) upgrade and break every 3 months with the latest version of Windows or Fedora. What about corporate computers? What about non-techy people who buy a computer and stick with the OS that was sold with it for 4 years? I’m afraid they are still the vast majority of web users. You can’t decide to deploy a new version of IE of Firefox on a large number of computers for next month. Sometimes, this is not even possible (hello Windows 2000/XP users).

For Debian squeeze, this means no more Firefox for you. Epiphany and Konqueror might still work, but Google loves sending JavaScript that make old versions of Webkit struggle. And anyway, this is just the beginning. In a few months they will tell us to upgrade again to Firefox 4.2 and IE 12. One week after their release, yeah!

Let’s quote a comment which should help understanding the reasoning behind such decisions.

Andy, while I understand staying on LTS, I think it's a little bit silly to use a mission critical machine for web browsing in that way. Also, there is no reason your browser has to be tied in lockstep to your OS.

Two simple solutions:
1. Don't use the built-in browser for your main web browsing. Install Chrome, for example. or,
2. Since LTS is designed for servers and other "can't have any chance of downtime" machines, quit using that machine as your web browsing box and use a personal laptop for such things, which you can keep up to date with the current OS release instead of waiting 2 years.

Belief #1: “the browser can (and should) be independent from the OS”. It’s interesting to note that the same people who say this are the ones who also jerk off at the idea of desktops and phones with tight web integration. This integration comes at a cost: this restricts your ability to change everything in the browser from one day to another.

Belief #2: “long-term OSes are for mission-critical servers only”. Yeah sure, that’s why Windows has a lifecycle of 3 years. Desktops are no different at all from servers on this matter. You don’t upgrade your desktop every 6 months when you do serious work with it; the cost and the risk are just too high. And anyway, this comes again from the same people who want to upgrade every single component of said mission-critical servers every 2 months to install the latest version of their preferred web framework.

Belief #3: “people can upgrade their browsers or OSes”. No really they can’t. Many people wouldn’t know how to do this, even with a step-by-step documentation. And in enterprise deployments, they are restricted from doing so.

Thanks for spreading the cliché that web developers are clueless, spotty nerds, incapable of understanding the needs of production environments. Apparently Google is not exempt from this disease.

03 May 2011 @ 01:12 pm

Since this has been a major request from users for a long time, I can only cool with the idea of seeing the Debian project support a rolling release. However I’m not pleased with the proposed ideas, since they don’t actually include any serious plan to make this happen. Sorry guys, but a big GR that says « We want a pony rolling release to happen » doesn’t achieve anything.

Let me elaborate. First of all, discussions have focused a lot on what to do when we’re in a freeze phase. Numerous cool ideas have been proposed, including PPAs (which again, won’t happen until someone implements them). This is all good, but this is only the tip of the iceberg. Above all, before wondering what can happen in a freeze that lasts 20% of the time, let’s wonder what can happen for the 80% remaining time. Once you have something that works in the regular development phase, you can tune it to make it happen, even if in a less optimal way, when the distribution is frozen. So let’s not put the cart before the horse.

There are three options if you want to make a rolling release happen.

  1. Make unstable usable. to make it happen, you have to prevent the disasters that rarely but unavoidably happen here. You don’t want to make all rolling systems unusable because someone broke grub or uploaded a new version of udev that doesn’t work with the kernel.
  2. Make testing usable. This sounds easy since RC-buggy packages are already prevented from migrating, but actually it is not. A large number of RC bugs are discovered at the time of testing migration, when some packages migrate and others don’t. Worst of all, they require several days to be fixed, and it is very often that they require several months, when one of the packages gets entangled in a transition.
  3. Create a new suite for rolling usage.

The proponents of the CUT project obviously believe in option 2. Unfortunately, I haven’t seen many things that could make it happen. A possible way to fix the situation would be to run large-scale regression testing on several upgrade paths. I don’t know if there are volunteers for this, but that won’t be me. That would also imply to make a lot of important bugs RC, since they could have a major effect on usability, but the release team will not be keen to make it happen.

Because of the testing situation, when someone asks me for a rolling release, I point her to unstable with apt-listbugs. As of today, this is the closest thing we have to a rolling release, so we should probably examine more deeply option 1. Is it that complicated to write a tool to prevent upgrades to broken packages? A 2-day delay in mirror propagation and a simple list of broken packages/versions (like the #debian-devel topic, would be enough. Add an overlay archive, that works like experimental, and you can now handle freezes smoothly. Wait… isn’t that aptosid? We would probably gain a lot of insight from the people who invented this, instead of trying to reinvent the wheel.

Finally, option 3 could open new horizons. There’s a risk that it might drive users away from the testing and unstable suites, and this makes us wonder how we could have proper testing for our packages. Still, build a process that would (and that’s really only an example) freeze unstable every month, give people 10 days to fix the most blatant issues, add a way to make security updates flow in from unstable, and you have a really nice rolling distribution.

So overall, it only requires people to make things happen. You want option 2 to happen? Instead of working on GR drafts, start working with maintainers and release managers on ways to avoid breakage in testing. You want option 3 to happen? Start it as a new service and see how it works. Personally, I’d be in favor of offering aptosid developers to become DDs and offer their solution as a Debian service. It would bring in new people rather than driving away existing developers from working on our releases.


Today we gathered the representatives of different distributions that are present at GNOME.Asia to discuss what GNOME could do to improve its support for distributions that distribute it, especially in matters of long-term support.

It is kind of sad that there weren’t any representatives from Canonical nor Red Hat, but the discussion turned out really interesting and we learned a lot about the packaging habits of each other. Furthermore, there were several concrete leads that were explored, which will lead to proposals from the GNOME foundation to all distributions.

Helping with long-term support

The most widespread GNOME version in the LTS releases that happened recently is 2.30, which is used by Debian squeeze, Ubuntu LTS 10.04, RHEL 6, and Solaris 11. It looks like an accident, but on the other hand:

  • GNOME 2.32 isn’t really suitable as is for an entreprise distribution;
  • Linux distributions agreed on a kernel version to support long-term, so this had an impact on their release schedules, and this might well happen again for the next release.
In the future, a decision to use a common GNOME release could, anyway, only come from the distributions themselves, not from GNOME.

A proposal that many people agreed upon was to give distribution maintainers commit access to old branches that GNOME module maintainers don’t touch anymore. This way they could share their patches more easily and make new releases of these old branches. This would imply, of course, setting up rules about what changes are allowed, that distributions would have to agree upon (how to treat feature additions for example).

Managing bugs

Currently it is hard to tell, for a distributor, whether other distributions are affected too and whether they have released a fix for that. It was agreed upon that Launchpad’s feature of linking bugs between distributions, including version tracking, would exactly fill that need.

One of the solutions would then be to add such a feature to Bugzilla, but it is a lot of work since currently it doesn’t have any kind of version tracking. Another proposal was to deploy a new Launchpad instance to do serve as a hub between downstream bug systems and the GNOME Bugzilla. The condition for this to work would be to make it extremely easy to clone bugs between it and Bugzilla, and also if possible from the downstream bug systems.

On the side-related topic of how not to crawl under bugs, it might be possible to get bugs forwarded with a single command from the Debian BTS to Bugzilla, using the XML-RPC interface. Upstream also considers that bugs sent to Debian are generally of higher quality than those from e.g. Ubuntu, and would be OK with us routing some of them directly to upstream (like we already do for Evolution).

Communicating about the availability of patches

Currently distributors are hardly ever informed that patches relevant for their distribution have been committed. They often learn of them by sheer luck while lurking on Bugzilla.

The distributors-list ML is clearly the relevant media for that purpose, but it is clearly not used enough. It would need to be advertised more among both GNOME module maintainers, and among downstream maintainers as well.

On this matter, the disappearance of the x.y.3 GNOME releases (starting with 2.28) was evoked. The problem was that most of those releases were about insufficient changes to justify e.g. stable updates in distributions. The proposed solution is to encourage maintainers of modules with bugs to fix to release new versions (through an annoucement on desktop-devel-announce), and to send a list of modules with new versions to downstream distributors so that they can integrate them. This avoids the GNOME release team the hassle of making a new release, while still giving distributions that use them some bugfixes.

Providing a new service to LTS distributions

The idea of having the GNOME foundation employ a person to gather, on the GNOME side, all changes that are relevant to older GNOME versions, and prepare new stable versions, was discussed. This would be a new service for which commercial distributions would need to pay a fee.

It’s not clear how this information would be privately disclosed and the impact on non-commercial distributions. But it doesn’t seem likely that e.g. Red Hat would be interested since they employ a lot of core GNOME hackers who are already doing this job.

I don’t know what impact these proposals can have on GNOME packaging in Debian, but apart from the last one that I find dubious, it seems that they could greatly improve our support of GNOME in stable Debian releases, be it by having more versions to upload during the freeze, or by having more stuff in point releases. Frédéric Muller promised to come back to us with more concrete stuff.