New developer accounts have been created moments ago, “finally”.
Congratulations to all new DDs, with a special note for Aur lien G R ME (ag) and Cyril BRULEBOIS (KiBi).
All of this made possible by Sam, our best DPL to date.
Also, don’t listen to the fucktards going around telling “OMG DEBIAN IS DYING!!11!1!”. They’re just that, fucktards.
YAY! I'm now a Debian Developer.
I started celebrating by uploading an NMU for the oldest patch of a RC bug I had sitting in the BTS.
Thanks to Ari for advocating my membership, to Ari, Clint, Free, Piotr for sponsoring my uploads, and TomV. for managing my application. Also a special thanks to sam for making the last minute DAM appointments, which probably sped up my account creation, thus, finally 'making debian sexier' :).
A few months ago, I had shown a
chart with per-5k-segment paces
of my prior marathons runs (or at least those for which organisers had 5k splits). Since then, I ran two more:
New York in November and
London last Sunday. I have updated
the charts to show both of these:
A few things stand out:
It's time for me to stop complaining about the commercialisation of SourceForge and vote with my code. I'm leaving for brighter, bluer pastures at Alioth.
Allow archives to be passed in as string Currently, we only allow opened filehandles or filenames, but not strings. The internals would need some reworking to facilitate stringified archives.Fortunately, it does allow you to use a filehandle. I've previously mentioned about how useful the IO::Handle subsystem in perl is. And we should be able to use it in this case. The module we'll want is IO::String, which is a IO::Handle over a perl scalar. We can use it:
my $tar = new Archive::Tar(new IO::String($data));Unfortunately when we run this now we get:
Cannot read compressed format in tar-mode at Foo.pm line 41 No data could be read from file at Foo.pm line 41It turns out that this is because Archive::Tar uses IO::Zlib internally if the file isn't uncompressed, but this doesn't provide the ability to uncompress from a filehandle. The answer is to uncompress the data before passing it to Archive::Tar and the easiest way to do this is to use the IO::Uncompress::Gunzip module, so we can rewrite our code to:
my $tar = new Archive::Tar(new IO::Uncompress::Gunzip(new IO::String($data)));Now when you run the script, Archive::Tar has an uncompressed tar stream. Yet another situation where IO::Handles comes to the rescue.
A bug was reported on linux-parisc@ last week, that “ls -l” was whinging about “Operation not supported” once per file. Easy, I thought, I’ll just break out strace, figure out which syscall it is, and Bob’s your uncle, we’ll have it fixed.
Not so, unfortunately, as strace was bloody broken.
upeek: ptrace(PTRACE_PEEKUSER,2606,4294967292,0): Input/output error
Again, no big deal, some kernel change must have broken ptrace(2) on me. git logs didn’t shed any light on it, so I pulled an old strace binary out of an etch chroot and tried that, which failed as well. Wonderful. But… curious… it still works inside the chroot.
At this point I was a little bit beyond annoyed, but the fact that it worked in the chroot was a big clue. Anyway, long story short, strace decides to assume that you can have up to 32 possible syscall arguments (wtf?#1) which is all well and good and generally harmless. However, it also decides to yank MAX_ARGS of them out with ptrace(PEEK_USER, …) if strace is unaware of the syscall prototype. Again, this would be mostly harmless, on every other architecture.
On parisc though, argument registers count down from %r26 through %r20, which is the syscall number. Instrumenting the PEEK_USER path through sys_ptrace in the kernel made it pretty obvious when a consecutive request was suddenly 0xfffffffc (which is 0-4, especially suspicious given the previous values of 4, 8, 16…) that I needed to find a loop in ptrace. Searching through all the HPPA specific syscall code found it quickly,
for (i = 0; i < tcp->u_nargs; i++)
if (upeek(pid, PT_GR26-4*i, &tcp->u_arg[i]) < 0)
return -1;
where “i” is 0 .. u_nargs, which is set to either the known number of syscall args, or MAX_ARGS (which, remember, was 32.)
There, the culprit found, and with a simple one line fix, strace works again. In case you’re curious, the reason things worked inside the chroot, is because the syscall being strace’d was dependant on libselinux being loaded.
syscall_298(0x400e0fbc, 0x58, 0xfb444310, 0, 0x409878ac, 0x409878ac) = -1 (errno 2)
Which is statfs64.
The moral of the story here? strace is out of date and doesn’t yet support recently added syscalls. Also, the code quality is pretty atrocious.
Oh, and the problems with ls? getxattr was returning -EOPNOTSUP because the filesystem doesn’t support
It's stories like the following that make you realise just how puny your
talents are...
(Reposted from a place not to be named, by the legendary Al Viro)
Give them what I got yesterday. As in, box that got
a) Linux kernel running.
b) init and bash running.
c) serial and floppy - built as modules. And not loaded.
d) no sash.
e) no ethernet.
f) bloody large number-crunching that Should Not Be Aborted(tm).
g) libc and ld-linux.so - unlinked (self-LART by owner).
Now, I could tell the guy to piss off, but... WTF? He had decent beer and
was properly scared. Oh, well... So we have no exec() for anything
dynamically
linked. And we have no chance to access any external stuff - insmod is
linked
dynamically, so no insmod floppy for you. Shutting the system down was not
an
option due to (f) (aside of dealing with fsck later - umount(8) is
dynamically
linked too). Now, I knew that both /lib/libc.so-2.1.2 and
/lib/ld-linux.so-2.1.2 were still alive - mmaped by init, for one. And
/proc/1/maps would even contain their inumbers. So the plan of attack was
to create a file in root and then cannibalize the entry (change inumber in
the directory). Alas - not enough. In-core inode got zero i_nlink and
if I would just create a link by hands it would not become positive. I.e.
still remove-upon-close. But. But if we will manage to call link() on the
hand-made link we will get i_nlink raised to 1 - iget() will find the same
in-core inode, so we are OK. We'll have to revert the phony link to avoid
PO'd fsck, but that's not a problem...
So there we go: assuming that we got static ln
echo >foo
ln foo bar
flip inumber in foo entry to point to libc
ln foo /lib/libc.so-2.1.2
flip inumber.......................... bar
repeat for ld-linux.so
rm foo bar
begin recovering other damage (self-LART was a bit larger).
But... we don't have this flip stuff and we don't have (aaarrgh)
static
ln. Oh, shit... OK, but all we really need is a couple of syscalls, right?
There we go:
eax=__NR_link;
ebx=s1;
ecx=s2;
int 0x80;
eax=__NR_exit;
ebx=0;
int 0x80;
s1: "foo"
s2: "bar"
The next step was getting the syscall numbers. grep? We don't need no
stinkin'
grep.
# while read i; do case $i in *__NR_link*) echo $i;; esac;
done </usr/include/asm/unistd.h
#define __NR_link 9
# while read i; do case $i in *__NR_exit*) echo $i;; esac;
done </usr/include/asm/unistd.h
#define __NR_exit 1
#define __NR__exit __NR_exit
Now, scratching the head and recalling intel code...
start: b8 09 00 00 00
bb (address of s1)
b9 (address of s2)
cd 80
b8 01 00 00 00
bb 00 00 00 00
cd 80
s1: 66 6f 6f 00
s2: 62 61 72 00
Fine, but... a.out support is compiled... you guessed it, as module and not
currently loaded. So we are in for crufting up an ELF binary. OK, we don't
actually need 100%-correct ELF, just something that will pass for the
exec(). Now, we don't have shell scripts, but . will work. So the next
step was rolling more(1) in shell and reading through the relevant code
(surprisingly small - binfmt_elf.c and two headers). After much swearing
the following abortion was created:
7f 45 4c 46 00 00 00 00 00 00 00 00 00 00 00 00
02 00 03 00 01 00 00 00 start______ 34 00 00 00
00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00
00 00 00 00 01 00 00 00 00 00 00 00 base_______
base_______ size_______ size_______ 05 00 00 00
00 10 00 00
start:
b8 09 00 00 00 bb start+1d___ b9 start+21___ cd
80 b8 01 00 00 00 bb 00 00 00 00 cd 80 66 6f 6f
00 62 61 72 00
OK, set base to something page-aligned, start=base+54, size=79. There we go:
7f 45 4c 46 00 00 00 00 00 00 00 00 00 00 00 00
02 00 03 00 01 00 00 00 54 00 00 80 34 00 00 00
00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00
00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 80
00 00 00 80 79 00 00 00 79 00 00 00 05 00 00 00
00 10 00 00 b8 09 00 00 00 bb 71 00 00 80 b9 75
00 00 80 cd 80 b8 01 00 00 00 bb 00 00 00 00 cd
80 66 6f 6f 00 62 61 72 00
well, while read l; do for i in echo $l ; do echo -ne "\\$i"; done; done
made for oct2bin, overwriting /usr/bin/emacs with the output of that gave
us static equivalent of ln foo bar. And it worked. The rest was essentially
the same - the only tricky part was to find the location of directory entry.
Which was done with (lseek, read byte, exit(said_byte)) and shell wrapper
around that. So we had a way to read a block and dump it on the console.
The rest was obvious - start from relevant block in inode table and walk
through the references... Once we got that, it was an easy ride - trick
with inumber flipping brought libc and dynamic linker back and after that
we had 99% of system back into the working state. Amazing how little you
actually need to bring the system back to life...
Hot damn that's some deep hackery...

16:46 < epmf> tp-glib is made of magic—#telepathy, 2008-04-15
Rob pointed out today that I'd been promising to blog about telepathy-glib for several months and still haven't done so. I think there's too much to cover in one blog post, so I'll start with the oldest part - implementing a service (typically a Telepathy connection manager).
While telepathy-glib is (obviously) intended for Telepathy implementors, I think the ideas we've been implementing are likely to be useful for any D-Bus API, particularly flexible/complex APIs where an object implements many interfaces.
(credit: daf)
commit 355ef78d98d6fc65715845d56232199162cab12a
Author: Steve Frécinaux <steve istique net>
Date: Thu Aug 17 11:48:20 2006 +0200
Interface support for bindings.
Instead of running dbus-binding-tool or creating GObjects with D-Bus
interfaces, we put the entire Telepathy spec through
glib-ginterface-gen.py, a distant descendant of Gabble's gengobject.py.
For each interface in the spec, we generate a GInterface that mirrors the
D-Bus interface. Any GObject that implements the GInterface automatically
gets the D-Bus interface if it's exported onto D-Bus.
There are a few non-obvious refinements, though:
The signature of the method implementation is always in the mode that dbus-glib calls "asynchronous", where the method implementation can either send a reply message before or after it returns. For "slow" methods, this is the only thing you can do. For instance, many Telepathy D-Bus methods can't return anything until some TCP round-trips to the server have happened. This is also the only thing you can do if you want to extract extra information, like the sender's unique name, from the method-call message (dbus-glib's "synchronous" API doesn't allow this to be done). For "fast" methods, sending a reply message before returning is just as easy as using the "synchronous" API (it's just a difference of syntax), and has an API consistent with that of the "slow" methods, making it easier for service authors.
The layout of the GInterface vtable is private, and (auto-generated) accessor functions are used to fill in implementations. This means our ABI doesn't change just because we re-ordered functions in the spec.
If no implementation is provided for a method, we just raise an appropriate error (org.freedesktop.Telepathy.Errors.NotImplemented), rather than suffering an assertion failure. This means we can safely add methods to an interface.
While we're generating code anyway, we generate some static inline wrapper functions which wrap dbus_g_method_return(), to have type-safe method returns. You can easily check that a method replies with correct types, by checking that the implementation of Foo() replies by calling tp_svc_some_interface_return_from_foo().
Similarly, we generate wrapper functions to emit signals, to get type-safe signal emission.
The Culture and Politics of Computer Hacking. This course takes as its object computer hackers to interrogate not only the ethics and practices of hacking, but to examine more broadly how hackers and hacking have transformed the politics of computing and the Internet more generally. We will examine how hacker values are realized and constituted by different legal, technical, and ethical activities of computer hacking for example, free software production, cyberactivism and hactivism, cryptography, and the pranksih games of hacker underground. We will pay close attention to how ethical principles are variably represented and thought of by hackers, journalists, and academics and will use the example of hacking to address various topics on law, order, and politics on the Internet such as: free speech and censorship, computer gaming, privacy and security, and intellectual property. This will allow us to critically 1) problematize thinking on computer hackers as a socio-cultural group guided by a singular ethic and set of practices 2) examine the multiple ways hackers draw on and reconfigure dominant ideas of property, freedom, and privacy through their diverse moral codes and technical activities 3) broaden our understanding of politics of the Internet by evaluating the various political effects and ramifications of hacking.
Another
zero-day announcement of a Software in the Public Interest online meeting
has been posted.
The announcement mentions "one motion has been raised" but
the agenda
doesn't include any motions, so I'm not sure what.
Also, the agenda lists "Debian logo licence" as up for discussion but I thought
last month's meeting
resolved that.
I watch SPI fairly closely and I'm confused.
How about the rest of you?
SPI isn't alone in this: many software organisations seem
to suffer from similar problems. For example, I ranted
in passing about
Free Software Manchester
yesterday, who just posted
the notes from their own zero-day meeting
and I've suggested possible ways of reforming
debian's currently-stalled New Maintainer process
more than once.
Are free software users particularly bad at the basics
of running an interest society (like welcoming and
expiring members, calling meetings, publishing routine
communications, and so on), have I been spoiled
by cooperatives with
their friendly Member Services departments or secretariats,
or what?
Is this why so many free software orgs seem to include
self-perpetuating leadership groups?
Is this a serious problem if, as reported,
Software Development is a Team Sport [etbe]?
Are there fully-working free software mass participation
groups out there?
I feel a lot of these problems are caused by attempting
to order our inherently entropy-filled world completely
and insisting everything follows petty rules, such as refusing
to answer a question because the "wrong" member asked it.
The world will not become less random just because hackers
try to impose arbitrary rules. Sometimes it's good to
put down minimum standards (because calling zero-day meetings
is a mostly-avoidable way of excluding some members) but it
will always be a poor alternative to
trying to do the best you can for others.
How do we get past this? My
pro-cooperation-and-better-business platform for SPI board
went pretty badly and I've had some anti-cooperative flames
back from someone starting another free software group
this month, so I don't think I can fix these existing
organisations any time soon. About 1 in 6 people in the UK
are members of a cooperative, so even if that is reflected
among hackers (and I think it's lower), all of them
would not be enough to reform much.
One of the most common memes in free software is "show us
the code" and the few other free software cooperatives I've
seen have mostly failed, with a few surviving but hitting a size limit.
As a result, I'm currently negotiating the start of a new
free software cooperative. So far, I'm really happy
with how that's going. Many cooperators learn at the feet of
large consumer cooperatives like
the Cooperative Group
who run training courses for new members about putting
cooperative values and principles
into practice,
which we smaller groups couldn't run ourselves.
As a result, most cooperators already know how to work
well together.
Should large software societies like SPI try commissioning
similar courses?
Sunday was the 100th anniversary of the modern marathon: It was during the London
2008 Olympics that the marathon was run for the first time for the 26 miles
385 yard, or 42.185 km, distance. And it so happens that I was there to run
the 2008 edition of the London
Marathon.
Pretty nice weather at the start and finish: sunny, not too hot, occassional
clouds. But being London, we still managed to get drenched for about 30
minutes. Overall, the conditions were good -- or else Martin Lel would
have had a hard time for a
new course record.
The course is pretty nice, right from the start in Greenwhich all the way to
the spectacular finish in Westminster. Crowd support was good too, if only a
little uneven. But the second half of the race, and particularly the last
miles in the back from Canary Whard through the City to Westminster past
Parliament and Buckingham Palace were awesome. Lots of people, lots of noise.
Oh, and I even saw the leaders in a group of five, including Lel and Hall
as the course had parallel 'out' and 'back' tracks around miles 13 for me and
22 for them.
I had planned to take it easy and not try to run too hard, and aimed for a
time of around 3:25 and then finished at 3:24:41. A little less 'even' than
I had hoped, but still a very satisfying result. And for once the legs aren't
all that shot afterwards :)
And the whole weekend was nice as I got to stay with friends in the southwest
of London. Staying up late on both ends of the trip suppressed the jet lag
fairly well. At least that's what I keep telling myself.
We are at T-48h of fisl9.0, and everything starts to take form. I spent the whole afternoon getting our icecast infrastructure online. We ve got 6 servers, all with different bandwidth and not all with the same architecture The debian boxes were prevalent (4 of them 1 amd64 and 3 i386), all of them etch. We ll be able to follow the statistics at tvstats website (not all the servers are enlisted yet).
In this process I found an evil bug in debian s icecast package, I will have to debug to understand it better: when relaying from a master server (which is our set-up), if the source stops feeding the master, the relay segfaults. The strace shows it just segfaults while pooling I got no explanation for it and I ll have to dissect it if I want to build a proper bug report. In the meantime, I installed the sarge-backports version, and it worked so, the bug report will have to wait until after fisl :-)
I took some pictures to show how s everything being put together. Take a look:
And some of the infrastructure crew:
See you all there!
Next.