Category: PlanetUbuntu

Google Summer of Code’s real goals?

Posted on by lucas

There’s an interesting discussion about Google Summer of Code going on debian-devel@. The question can be summarized as “Should we allow current Debian contributors to be students in GSOC?“?

The GSOC FAQ says:

Google Summer of Code has several goals:

  • Get more open source code created and released for the benefit of all;
  • Inspire young developers to begin participating in open source development;
  • Help open source projects identify and bring in new developers and committers;
  • Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer (think “flip bits, not burgers”);
  • Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette).

The problem is that those goals are clearly conflicting:

  • If you think that “get useful code written” is more important than “get fresh blood in Debian”, it is stupid to choose students that are not existing contributors to Debian. It’s a much better idea to choose people that already know Debian very well, so they will be very efficient.
  • If you think that “get fresh blood in Debian” is more important than “get useful code written”, it is stupid to choose students that are already contributing to Debian. You should choose outsiders, of course.

Another problem is that in the past, some students that were also debian contributors had problems organizing themselves: they used some of their GSOC time to work on their usual Debian tasks, leading to results that were a bit disappointing. But it’s possible that this is mainly a management problem (however, mentoring people takes a lot of time, and only students are paid, not their mentors).

How do you deal with that in your project?

back from FOSDEM

Posted on by lucas

I was at FOSDEM last week-end. As usual there, I spent an excellent week-end. It was really nice to see all those friends again (and even meet some friends for the first time, hi gaston/carxwol/atmaniak!) Only problem is, FOSDEM is definitely too short ;-)

To make this post a bit more interesting, I did some homework. The opening talk about FreeBSD had those stats about developers’ age, so I made the same ones for Debian (using the birthDate LDAP field, which was filled in by 340 DDs). Here is the graph. It would be interesting to compare that with other communities, which are sometimes perceived as “younger”.

DD years of birth

dd + /dev/random fun

Posted on by lucas

From Adrien Lebre, who seems to be having fun working on kDFS:

$ dd if=/dev/random of=file bs=1024 count=2
0+2 records in
0+2 records out
256 bytes (256 B) copied, 0.000705717 s, 363 kB/s
$ ls -l file
-rw-r--r-- 1 lucas lucas 256 2008-02-08 17:53 file

Can be easily explained using strace:

open("/dev/random", O_RDONLY|O_LARGEFILE) = 0
[..]
open("file", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1
[..]
read(0, "p(\361\241,\360-\330~M\245y\10=\274U\201c\207\v\336a\273"..., 1024) = 128
write(1, "p(\361\241,\360-\330~M\245y\10=\274U\201c\207\v\336a\273"..., 128) = 128
read(0, "\362,LW5l.?\242\22\252\223\206\375\10\326\335\316\374\372"..., 1024) = 128
write(1, "\362,LW5l.?\242\22\252\223\206\375\10\326\335\316\374\372"..., 128) = 128
close(0)                                = 0
close(1)                                = 0

Re: a problem with tools

Posted on by lucas

Joey has a problem with tools used over dpkg-dev’s core tools to help maintainers maintain their debian packages.

I was wondering about the adoption of those tools, so I simply grepped the logs from my last rebuild for “^Setting up $TOOL “, which is more accurate than looking at build-deps, since someteam-pkg-tools could depend on cdbs, and hide cdbs usage.

Results, with lists of packages “affected”:

Tool Packages
debhelper 11434 (95.8%)
cdbs 2665 (22.3%)
dpatch 1714 (14.4%)
quilt 935 (7.8%)
dbs 57 (0.47%)
yada 32 (0.27%)
debmake 2 (0.017%)

(if you want me to check the logs for another tool, just tell me)

My personal opinion on this is that tools that make sense are slowly getting adopted (that probably includes debhelper, cdbs, dpatch and quilt). The main difference between debhelper and the other tools is that the other tools don’t try to solve a problem for everybody. cdbs perfectly makes sense for some packages: the simple ones, where you only have to modify 4-5 lines in the output from dh_make to build properly.

Patch systems are also a good way to track changes made to upstream source, and probably encourage giving back patches to upstream. Note that my stats don’t include packages using cdbs’ simple-patchsys, so there are probably really close to 1/4 or 1/3 of our packages using some sort of patch system. How course, having simple-patchsys, dpatch and quilt sounds a bit stupid. But last time I checked, nobody took the time to blog a comparison of those tools, saying why {quilt,dpatch} is better than {simple-patchsys,dpatch,quilt}. Also, simple-patchsys probably makes a good-enough job for its users, so they don’t see the point in changing.

Of course, it’s easier to bury your head in the sand, and ignore the fact that those tools solve real problems for so many people and packages, and make their lives easier. :-)

Fixing build failures with dash is cool.

Posted on by lucas

The bad thing with fixing build failures with dash is that there are still a lot of open bugs. (Remember, the 0-day NMU policy applies to those, so it’s a good opportunity to improve your NMU karma. And I will sponsor your NMUs if you can’t upload!).

The good thing is that you sometimes run into funny code, like:
clean:
    dh_testdir
    dh_testroot
    pushd docs ; $(MAKE) distclean || true ; popd

Since pushd/popd is a bashism, the Ubuntu patch changed this to:
clean:
    dh_testdir
    dh_testroot
    cd docs ; $(MAKE) distclean || true ; cd $(CURDIR)

Which works, but is … interesting? :-)

Help us get rid of dash build failures in Debian!

Posted on by lucas

Following my rebuild of all packages using /bin/dash as /bin/sh, we now have a nice list of bugs.

Those bugs are cool:

  • The relaxed NMU rules apply to them, since they are part of the dash release goal. Which means that they can all be fixed using 0-day NMUs.
  • Most of them are really easy to fix. (for many of them, a patch is already provided by Ubuntu)

So, if you want to get involved in Debian development, try to submit NMU patches for those bugs. If you want me to sponsor the upload, please Cc me when you submit the patch.

And even if you don’t care about Debian, but only about Ubuntu (which is fondamentally wrong, as everybody knows that Ubuntu is based on Debian), fixing these bugs also helps Ubuntu a lot: all those bugs hurt Ubuntu, since Ubuntu uses dash as /bin/sh by default, and, even if the packages in Ubuntu have been patched, it’s still causing additional work every time a new package is uploaded to Debian, and has to imported in Ubuntu.

If you have questions with the process, please ask them using the comments below.

Notes:
I use the following process on those bugs, and it’s probably a good idea that you do the same if you intent to submit patches:

  • build the package with a chroot using bash
  • build the package with a chroot using dash (you can just use a different pbuilder tarball for that). Check that the problem can be reproduced.
  • fix the package
  • build the new package with a chroot using bash
  • build the new package with a chroot using dash
  • compare the built packages using debdiff for old_package_using_bash, new_package_using_bash, and new_package_using_dash. If the content doesn’t match, we have a problem.

If you submit NMU patches, please also have a look at the other bugs in the package, or at the lintian output. I don’t mind sponsoring small fixes for non-cosmetic/non-wishlist stuff at the same time.

Rebuilding the archive with dash as /bin/sh

Posted on by lucas

I rebuilt all Debian packages twice. The first time with bash as /bin/sh, and the second time with dash as /bin/sh.

About 120 packages built fine with bash, but failed to build with dash. I filed all the bugs that weren’t filed already.

Then I debdiff’d the resulting binary packages, and found about 40 packages that built fine with bash and dash, but produced different binary packages (mostly files missing/being added)!

All the bugs (including those that were already filed) have been usertagged. Most of those bugs are quite easy to reproduce and fix, so, if you are bored, send patches!

I was a bit surprised by the high number of problems I found, since Ubuntu has been using dash as /bin/sh for more than a year, even on their buildds. Some packages have been fixed in Ubuntu, but the Debian maintainers didn’t include the fix. But many packages were simply broken in Ubuntu.

Now I’ll try to find time to work on the Build Daemon From Hell idea, and on rebuilds inside qemu.

Ubuntu giving back to Debian: facts and numbers!

Posted on by lucas

I’ve always been annoyed by the discussions about “is Ubuntu really giving back to Debian?”. Debian Developers usually don’t see a lot of “giving back”, and Ubuntu Developers complain about Debian Developers ignoring their bug reports and patches.

So, a few months ago, I proposed that Ubuntu developers use a usertag when they report bugs to the Debian BTS, so they can be tracked.

Results are available:

Comments:

  • It’s really good to see Ubuntu developers reporting bugs and contributing patches to Debian!
  • … But more bugs (and patches) would be better, of course. Let’s continue the good work!
  • Many patches are applied very fast in Debian (as usual), but in some cases, the patches are ignored (as usual, too). It would be great if Debian Developers could treat those bugs as higher priority, since it makes life easier on the Ubuntu side (less difference means less work)

If you are an Ubuntu Developer, read wiki.u.c/Bugs/Debian/Usertagging for the details on how to tag the bugs you file. Note that the submittodebian script in the ubuntu-dev-tools package already sets the usertags.

SC07, MIT Fab labs, and empowering people

Posted on by lucas

This morning’s SuperComputing’07 keynote was a talk by Neil Gershenfeld, director of the Center for Bits and Atoms at the MIT. He mentioned the MIT Fab Labs, a project to bring “Personal Fabrication” to people around the around.

At our own level, that’s something I find very exciting with Free Software: it empowers people to do things with their computers that they couldn’t do if they were using proprietary software, simply because proprietary software is built to fit most people’s needs, not very specific goals some people could have. (and this is similar to the Long Tail stuff, in some ways)

Also, if you are at SC07 and reading this, feel free to ping me! I haven’t seen a lot of Debian/Ubuntuers here, even if the Free/Proprietary software ratio is very high.