Since quilt 0.46-7 (see #527255) you can automatically apply/unapply a quilt patch serie with debhelper’s dh command. It’s very practical in tiny rules files:
%: dh --with quilt $@
There’s also dh_quilt_patch and dh_quilt_unpatch for those who don’t use tiny rules files.
Enjoy !
I have booked my flights for Debconf9 in July. I will arrive in Madrid on July 23th at 10:30 from Lyon Saint-Exupéry (LYS-MAD, flight AF5891) and I will leave on July 31th at 17:40 (MAD-LYS, flight AF5892). I plan to use the train to go to Cáceres but it’s too early to buy tickets on renfe.es. I also have no idea how far the train station is (from the airport) but it looks like I will have several hours transit time anyway. There aren’t so many trains for Cáceres. The train tickets will likely cost around 30 EUR each.
I’m glad that I can attend again this year. I’m sure it will be very productive. At least concerning dpkg it will be good to meet Guillem Jover IRL.
This is the worst vote that has come up since I’m part of Debian. And Manoj — the secretary — has refused to listen to the remarks of many developers about the misleading titles/summaries, about the unjustified 3:1 ratio, and worst of all, about the mixing of multiple questions in a single ballot.
I have ranked misleading options (“Reaffirm social contract“ at least) lowest and below “Further discussion“ and sorted all the other options according to my preference, and ranked some of them equally when the choices answer different questions (where I can not prioritize any preferred outcome). I’m not yet sure if I put “Further discussion“ first or not.
There’s some hope that the vote will be cancelled and redone with separate ballots but I’ve lost trust in Manoj’s abilities to do his job properly. I’m sure he’s convinced that he’s doing the right thing but that doesn’t help at all, on the contrary. It also means we probably should fix the constitution to make it crystal-clear how the secretary should decide whether 3:1 ratio is needed for a given resolution or not. Not really the kind of thing I enjoy within Debian, but that’s the price to pay if we want to continue to work together. On this and much more I agree with Russ Alberry.
Update: Manoj resigned as secretary. I want to thank him for having taken this hard decision. And I sincerely hope he doesn’t resign from Debian completely as our strength is also in our diversity of opinions.
So I replaced my Latitude D410 with a shiny new Latitude E4300 (Intel Core 2 Duo SP9400 2.4 Ghz with 4 Gb RAM). Here are some notes about this laptop that might be interesting for others.
I now use an SSD drive for my main disk (Dell Ultra Performance SSD, it’s the second generation of Samsung SSD) and I’m satisfied with that choice, I can boot (an unmodified Debian desktop install) from the SSD in less than 30 seconds while the same system booting from a traditional hard-disk takes more than 45 seconds.
The Intel GM45 graphic card is not auto-recognized by Xorg 7.3 (or rather by xserver-xorg-video-intel 2.3.2 which is in lenny) so you end up with the vesa driver by default. It’s possible to force the usage of the intel driver by adding a “Driver “intel”” line in the device section of xorg.conf but I have opted to use Xorg 7.4 (available in experimental). With this version, I can successfully use the DVI output in the associated dock and I have working suspend/resume. It does create some interesting problems however since that version of the xserver relies on HAL to detect the keyboard layout and doesn’t use the Keyboard section of xorg.conf. You have to create /etc/hal/fdi/policy/10-keymap.fdi by using /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi as template and reload HAL then restart X.
The Intel 5100 Wifi chipset requires Linux 2.6.27 at least for the new iwlagn driver. This driver also needs a new firmware (the iwlwifi-5000 one) that is not yet integrated in the non-free package firmware-iwlwifi (see #497717).
It works ok with alsa and the version integrated in linux 2.6.27 but it still has some rough edges when used in combination with the dock. Using the output jack connector on the dock doesn’t stop the output in the integrated loudspeakers and the volume on that connector is so low that you could think that it doesn’t work at all if you don’t pay attention. Using the microphone works fine.
For reference, if you play in the mixer, “Front mic” means the microphone connected on the dock while “Mic” means the one connected on the laptop. Each “Analog loopback X” option goes pairwise with the corresponding “Input source X” setting. In order for the recording to work, I have to set “Digital Input Source” to “Analog Input”, “Digital” must be activated and “Input source 1” defines the default input used for the recording.
Contrary to the previous laptop, Dell offered no choice on the bluetooth chipset, they only propose the “Dell 365 Bluetooth™ Card” so I took it but it doesn’t seem to work out of the box. In fact I can’t even see it with lspci or lsusb so I wonder if they did something wrong during the assembly. Googling on the topic didn’t gave me any good result, let me a comment if you know how to get this working.
Update: so apparently the bluetooth component is there (ID 0a5c:4500 Broadcom Corp.), it just appears as an USB hub so it’s somewhat difficult to guess that it’s effectively a bluetooth card.
I first installed the system in 64 bits mode (amd64 architecture) but I had very regular freezes of the system (I couldn’t finish a single kernel compilation for example). Since I switched to an i386 installation, the system is more stable but I still get an occasional freeze every other day. It might be that a more recent kernel fixes this or maybe it will be fixed with a future Dell Bios update… we’ll see, but it’s my biggest complaint with this laptop so far.
Lucas Nussbaum bought the same laptop, you might want to read his remarks as well.
Load the full article only if you want to see the lspci and lsusb output on this laptop.
Lire le reste de cet article »
Following Ganneff’s post to debian-devel-announce, several discussions have again started on the topic of Debian’s membership and several proposals have been made. Unfortunately none of these proposals try to resolve the underlying trust problem that has been growing over the years. Despite the NM process (or maybe due to it), we managed to give DD status to people who are motivated but whose technical skills are doubtful (at that point people ask for an example, and as much as I hate fingerpointing, here’s an example with #499201. The same maintainer created troubles with libpng during the etch release cycle and tried to take over a base package like mawk recently).
With our current model, all DD can sponsor, NMU, introduce/adopt/hijack packages without review. This is fine as long as we trust the body of DD to contain only skilled and reasonable people. I believe that premise to be somewhat broken since Debian has become too big for people to know everybody and since the NM process had no way to grant partial rights to volunteers who were motivated but that clearly had not shown their ability to handle more complex stuff than what they had packaged during their NM period (like some trivial perl modules for example).
Thus I strongly believe that any membership reform must provide a convincing answer to that trust problem before being implemented. I took several hours to draft a proposal last Friday and I’ve been somewhat disappointed that nobody commented on it. I hope to draw some attention on it with this blog post.
The proposal builds on the idea that we should not have “classes” of contributors but simply two: a short-term contributor and a long-term contributor (those are called Debian Developers and have the right to vote). But all contributors can be granted “privileges” as they need them for their work and each privilege requires the contributor to fulfill some conditions. The set of privileges and the conditions associated all need discussions (but I have personal opinions here, see below). There’s however one privilege that is somewhat particular: it’s the right to grant privileges to other contributors. Handling it as a privilege like another is on purpose: it makes it clear that anyone can try to get that privilege and the procedure is clear. In practice, imagine that set of people as a big team encompassing the responsibilities split over DAM/AM/FD/DM-team and where all members can do all the steps required to grant/retire a privilege provided that 2 or 3 members agrees and that nobody opposes (in case of opposition a specific procedure is probably needed). I called that set of people the Debian Community Managers. It should contain only skilled and dedicated developers.
One of their main duties would be to retain the trust that the project as a whole must have in all its members. They would have the powers to retire privileges if they discover someone that has not acted according to the (high) expectations of the project.
Among the privileges would be “limited upload rights” (like DM have currently), “full upload rights” (like DD have currently although it might be that we want to split that privilege further in right to sponsor, right to package new software, right to maintain a package of priority > standard, etc.) and “developer status” (email + right to vote, once you can prove 6 months of contribution).
There’s lots of stuff to discuss in such a proposal (like how to decide who gets what privileges among existing DD) but I think it’s a good basis and need some serious consideration by all the project members. The NM process is there only so that we can collectively trust that new members are as good as we expect them to be and trust can only be built over time so it’s good that we can grant privileges progressively.
Some people believe that I’m reinventing a new NM process that will end up to be very similar to the current one. My answer is that the conditions associated to each privilege should be based on the work done by the contributor and the advocations that he managed to collect. It should not be a questionnaire like “Task and Skills”. This, together with the distribution of the power/work on many people, would render this system very different from today’s NM process.
Some people believe that I’m copying Ubuntu when designing this since it’s somewhat similar to the process to become MOTU and/or get upload right to Ubuntu’s main component. Let me say that I’m not copying deliberately at least, I simply took the problem from the most important side. But remember that many aspects of Ubuntu have been designed by Debian developers that tried to avoid known pitfalls of Debian, and maybe they got some things right (or better at least) while doing this.
Dear Joey, we also had this problem for dpkg, that’s why I hacked the /usr/local/bin/git-commit-notice script that we’re using on Alioth to do something like this instead:
while read oldrev newrev refname; do branchname=${refname#refs/heads/} [ "$branchname" = "master" ] && branchname="" for merged in $(git rev-parse --not --branches | grep -v $(git rev-parse $refname) | git rev-list --reverse --stdin $oldrev..$newrev); do /usr/local/bin/git-ciabot.pl $merged $branchname done done
It will stop git rev-list each time that it encounters a commit that is available in any of the other branches present in the repository and thus when you merge a branch, you only see the merge commit in CIA.
You should also note that the script is smarter as it calls CIA only for branch updates, not for tag creation (and other kinds of updates) where it only leads to strange errors IIRC.
This year I have not given any vote recommendation because all candidates would be (IMO) good DPL. The participation stats are a bit strange however: when I got the second call for vote I noticed 176 votes in the first week compared to 135 last year. So I thought “good, participation is on the rise”. But then I got reminded that we have shortened the voting period of the DPL election to two weeks. So the comparison doesn’t hold.
The vote close in two days and we have so far only 283 votes, and last year we got 482 in the end. So we’re likely to have much less participation this year… even if you add a percentage for the people who wish to vote but cannot for various reasons (which proves once more how important it is that the next DPL be determined to fix those recurring problems), you won’t get the same numbers.
So my question is: do we have lower participation because all candidates are good and people do not care who gets elected? or do we have so many DD that follow Debian only every 2.5 weeks?
And if you haven’t voted yet, it’s time to do it. 
During the last weeks I’ve been busy working on adding support of new source package formats to dpkg-source (the wig&pen format, a wig&pen variant based on quilt, Joey’s git based format integrated by djpig, …). I just reached the state where I believe the code is mostly ready to be merged in the master branch. Thus I would like some external testing and feedback.
Grab and install the package here and try building packages with dpkg-source "--format=3.0 (quilt)" -b mypackage (or any other new format). You can find more infos in the call for test on debian-dpkg (here and here). If you find regressions, please report them.
If you want to grab the latest sources, use git clone git://git.debian.org/git/dpkg/dpkg.git dpkg; cd dpkg; git checkout -b sourcev3 origin/sourcev3.
As you know I implemented the support of symbols files in dpkg-shlibdeps/dpkg-gensymbols, and I would be very pleased if libc6 could start using it as most packages would then benefit from weaker dependencies on libc6 and be more easily installable on previous versions of the distribution (sid package directly installable on etch in some cases).
Some time ago I tried to get the ball rolling by providing a first patch in #462444. Unfortunately the glibc team has not been able to finish the work up to now and the base freeze is approaching… so it would be great if some people could jump in, make the required changes, test and propose a new (fully working) patch. I just sent a message to give some indications on how to get forward, hopefully that will help anyone who wants to tackle this.
Thank you for your help!
The topic of switching from CVS to something else regularly came forward but nobody did anything. The net result is that several documentation are now maintained outside of the debian-doc repository because their respective maintainers didn’t want to stay with CVS.
After noticing that the developers-reference also switched to SVN, I decided to convert the whole debian-doc CVS repository and import it in the new “ddp” SVN repository on Alioth. This is now done.
Hopefully, the Debian Documentation Project can now again become the central place for writing good documentation about Debian. New contributors can be easily added through the DDP Alioth project. Volunteers are welcome to review what’s in the SVN and move obsolete documentation aside. People who moved away are welcome back.
Another project that also suffers from its CVS usage is the website (and it desperately needs a better design). After yet another round of discussion on #debian-devel, we agreed that discussing endlessly was not an option and that someone had to try the conversion and prepare the scripts for SVN usage. So I proposed to handle the CVS to SVN conversion and ifvoid decided to try to update the scripts. And it looks like things are progressing quite well… we included the CVS revision -> SVN revision mapping in the conversion (option –cvs-revnums of cvs2svn) and this will enable us to script the update of all translations (they encode a CVS revision to know if they are out-of-date or not). Expect to hear from us soon on debian-www@lists.debian.org…