devork

E pur si muove

Ubuntu & reportbug

Sunday, September 17, 2006

Lately I only appear to be writing about things I'm unhappy with and general moaning. Sorry for that. But here's another one of them:

An important part of Debian is the BTS, it allows users to report bugs as most people will know is obviously very important. Quite a few essays have been written (for example the first hit for a search) about how to write good bugs and how that can be difficult. The point I'm getting to is that many people/organisations have discovered it's a lot better to hand-hold bug writers and help them as much as possible. Debian has done this in the excellent reportbug program. It will collect lots of information about the program you're having trouble with, will show you open bugs against it etc. Perhaps the most important part is that Debian has discovered that the quality of bug reports improve significantly when reportbug is improved.

As the title suggests this rant is about Ubuntu however. Being a Debian derivative I thought they would have learnt this lesson from Debian and support reportbug too. They do indeed, but the way they do isn't amazing. Here the problems:

  • You are not given a list of open bugs.
    This is rather disturbing. I had to launch my web browser and go to bugs.ubuntu.com, which redirects to Launchpad but that's fine with me, to see if the bug was reported already. I could not find the bugs ordered by package there, so I tried the very useful Debian shortcut: bugs.ubuntu.com/packagename but with no luck. The only way was to use their search facility. That actually lacks quite a bit, in fact I think every bug I ever reported in Ubuntu has always turned out to be a duplicate, in Debian this ratio has been a lot better.
  • The bugreport is sent to a members-only email list.
    That's right, I got a message back that my email was waiting for moderator approval. Eh? This does not appear to be the case when reporting bugs via launchpad (at least when I used that last, as you might guess I prefer reportbug), so why are reportbug users supposed to be inferior? In fact I don't see the point of this at all. Duplicates aren't filtered and it seems like someone else has to go through the trouble of filing the bug again (I suppose in launchpad). Not very efficient.

So why is this? Why doesn't Ubuntu integrate reportbug better? Why don't they use the Debian experience in this? Why create extra work load? Why can't reportbug use launchpad directly? Sorry, but but this just seems like counter productive

mawk considered harmful

Tuesday, September 12, 2006

Consider the following little awk script:

/^--- [-[:alnum:].\/]+$/ { if ($2 !~ /[-[:alnum:].]+\/debian\//) print $2 }

According the the O'Reilly's sed & awk book it is, as far as my knowledge goes, normal valid awk. It's intended to be used like such:

~$ zcat debian_package_version.diff.gz | awk -f script.awk

The purpose is to list any files that are in the diff which do not live in the package/debian/ path.

I quickly created and tested it, then took it into production in my chroot. Interestingly enough I was pretty sure I had just tested it on this very same file which I'm now using it on, only now it didn't output anything! Double check the code, it still looks all right. Hrm. Then try this:

(chroot)~$ ls -l /usr/bin/awk
lrwxrwxrwx 1 root root 21 Jan 11 2006 /usr/bin/awk -> /etc/alternatives/awk
(chroot)~$ ls -l /etc/alternatives/awk
lrwxrwxrwx 1 root root 13 Sep 12 00:49 /etc/alternatives/awk -> /usr/bin/gawk
(chroot)~$ exit
~$ ls -l /etc/alternatives/awk
lrwxrwxrwx 1 root root 13 Jun 1 16:47 /etc/alternatives/awk -> /usr/bin/gawk

Yes indeed, after installing gawk inside the chroot it worked as expected. I'm really concerned about mawk not doing what I expected as by default, on a Debian system, only mawk is installed (because it is a lot smaller, claims to be faster too). I can barely believe the script above is not portable but would love if someone could point out to me what I did wrong!

Update: Upon closer examination it seems mawk doesn't like the [:alnum:] bit. It claims to adhere to POSIX tho. It would also be nice if it failed somehow. As I understand it the last closing bracket of [[:alnum:]] should create an error if it doesn't understand POSIX character classes.


No awk implementations where hurt in the creation of this post.

site, eggs, etc.

Thursday, September 07, 2006

Before I complained about why .pth files are not processed in files on in your $PYTHONPATH. I got a few pointers in that regard, thanks for them. And now I know why it doesn't happen: you can import foo, bar; foo.do(); bar.harm() inside a .pth file. Since this happens also when system programs are executed a user can effectively do anything they want, just imagine a python script setuid root. One could argue a script like that should start using #!/usr/bin/env python -S but still.

So the solution is described in the easy_install documentation. Create a $PREFIX/lib/python2.X/site-packages/altinstall.py with the malicious import statement in forcing the user's path to be processed for .pth files. Ok, that introduces the above mentioned security hole. You can also do it entirely safe (and while only being a user) and create a virtual python in your home directory, which is as I understand it a symlink farm to the system python. A bit a crude hack I think but it works I guess.

Having that out of the way I experimented a bit with the setuptools themselves (while attempting to install TurboGears, which I eventually succeeded in). So here are my initial remarks about it:

  • What an idea to name the frontend easy_install! I didn't really find it too easy either... altho that may be related to the fact that I don't like magic unless I fully understand the said magic.
  • It's still very much in development, options change all the time and some eggs need more recent versions then what I have on my system.
  • Using the bootstrap module, as one egg claims my setuptools is too old, it starts to download a new Python! I've got that installed thanks. (oh yeah, it also failed trying to compile python, but that's almost understandable.)
  • My view is that distutils and setuptools try to replace make and autoconf/automake. So why not follow their lessons? Why do you need an explicit EGG-INFO available on the system? Can't you test it? That would be much more backwards compatible.
  • Also missing from make: uninstall. You can expect to be dropped in /usr/local or ~ so you need to make sure you can delete your own files there again.
  • There's no way, other then unzipping and checking EGG-INFO by hand, to figure out the dependencies.
  • Lastly my killer bug: we live in this modern day and age where we don't trust anyone, yet there's no integrated gpg signature checking! It just downloads stuff from PiPy (or wherever you've pointed -f at)! Yes, I know it only does this during usage of easy_install and not at normal runtime, but that's not an excuse!

I feel like I've ranted too much already and realise people have been working hard on this. While I'm not too enthusiastic I can see some of the merits. In a later post I hope to outline some ideas I've had to solve some of my problems. In an ideal world I'd do some coding too, but I know I don't have lots of time. From what I've been thinking up so far most is possible with the current setuptools infrastructure, which is good as they are being adapted by many people. Only gpg signing will need people to learn a new habit, ideally setup.py will ask for this at some time in the future.

Ubuntu & upstart

Friday, September 01, 2006

Upstart is a new sysvinit replacement that Ubuntu wants to use. Scott James Remnant explained before it is innovating in that it is events based. Now he writes more about it, and one quote is this:

So what are events and where do they come from? (Note that this part is under development, so may change in later releases).

What? So this is the fundamental basic idea where everything is build around and you're not yet sure how it works? Scary.

Not that I'm against it all (but I also don't think it'll be the best solution for everything), it fairly intresting and I'm sure there is lots to be learned before you get it perfected. But I find it a bit ambitious that they want to use it by default in Edgy, the next Ubuntu release.

Nuking your home directory

Friday, September 01, 2006
/path/to/some/weird/directory$ rm -rf ~

Yep, I've done that today. It sucks. 1.5 seconds after I did that I hit the power button in the hope the kernel wouldn't have flushed it's buffers yet (hm, that old trick might not work with journaling filesystems). Boot up in single user mode and see half of it is gone. Try using recover but for some bizare reason it can't find any inode within the specified time. I think it sucks and I think I should learn to use debugfs directly.

So syncing back from my other machine (.ssh was gone but I luckily still had .gnupg and a few of the other important ones) I try and recover as much as I can. 3 hours later My machine looks nearly the same again. Only major thing I I'm still suffering from for now is having lost is my .gnome directory, and that contains damn well a lot, but I'm sure more will surface. Most prominent currently are my bookmarks --for once that they where organised a little bit-- and my photo collection.

Originally I was going to write a bit more about the site module and about eggs & setuptools etc. However I've now spent all evening recovering and have also lost the notes about the post. Altho I admit it was 100% user error, I'm still going to blame easy_install for distracting me and giving me this unwanted directory named ~.

grrrr

Subscribe to: Posts (Atom)