we have a dust problem!

Just found out that one of our (slind) recent night builds failed to the point of destroying the repository on the main server (that is, rsyncing up an empty repository). Which in itself is not much of a problem, but still sets it several days back and not to mention the bandwidth. This, however is not why we're here.

Investigation of the problem that caused said failure was much shorter than I dreaded and the problem itself turned out to be pretty simple. Each time the build starts, one of the scripts involved downloads a database file, which is most important for the build infrastructure. It used to do so by issuing 'curl $URL'. Pretty simple, but not safe against network and/or server failures. Then, one of our engineers decided to make it safer by patching it like this (these snippets are simplified, see below for original code):

- curl $URL
+ curl $URL || die "Failed to download a very important file!"

...which is a nice try, except that curl will always exit with 0 code regardless of HTTP response code, unless given -f/--fail option. IOW, we still have incorrect code, but this one gives us false sense of security.
And of course, if -f was there the night before, the repository wouldn't have been destroyed at all.

P.S. And the commit in question is here.

It turns out so that in OSS projects of small to medium size (in terms of contributors involved), a developer working alone in a certain area might feel abandoned and lonely and sometimes might even resort to using bugzilla to attract others' attention.
Slind bug #62. Note the 'reporter', 'assignee' and me in carbon list.

is absolutely awesome

A colleague of mine just made up
arp who-cares (request).

Democracy means that anyone can grow up to be president, and anyone who doesn't grow up can be vice president.
© Johnny Carson

Brand new IT position: Projector Manager.
Inspired by sigabrt siglost running in circles in search for a projector.

via sloganizer.net