Some musing on XMMS + Audacious + lulz

May 5th, 2008

Recently, we’ve been getting a lot of the following on our IRC channel:

<intangir> well xmms could do it

<intangir> and now xmms is no longer being updated

<intangir> its just been taking out of new debian and ubuntu repos ;(

<intangir> so audacious is the only thing that is close

<intangir> it must fill the void!

This is incorrect for a number of reasons, I am sorry if your distribution or the internet has made you believe that we are some magical successor to XMMS. This is not the case. Furthermore, calling us a “disgrace to open source” because we have no interest in being like XMMS (even the winamp2 skins are due to be leaving at some point), does not make us want to help you.

Now, why do people think Audacious is not acceptable replacement to XMMS? Well, not all people do, it’s more of the 5% of people who have specific use cases not covered in Audacious. Clearly if Audacious was not suitable, a lot of people would be blogging about it. Instead, we only see a few people blogging about it.

However, that said, I think Audacious’s focus is probably not the right focus for an “XMMS replacement” solution, and I have a plan for that (although once I finish writing it, someone else will likely be maintaining it, as I don’t really care enough). More on that later.

Yay! Ubuntu patches my code horribly wrong!

May 5th, 2008

ss=”entry”>

Ubuntu’s audio team has patched my code using a “new approach” to make audacious use Pulse by default! Great right

Well, not really, because the way they do it is wrong and won’t work and is prone to breakage with future releases.

Here’s the patch:

@DPATCH@
diff -urNad audacious-1.5.0~/src/audacious/main.c audacious-1.5.0/src/audacious/main.c
--- audacious-1.5.0~/src/audacious/main.c       2008-03-13 17:19:27.000000000 -0500
+++ audacious-1.5.0/src/audacious/main.c        2008-03-14 12:38:13.000000000 -0500
@@ -174,7 +174,7 @@
{0.0, 0.0, 0.0, 0.0, 0.0,             /* equalizer bands */
0.0, 0.0, 0.0, 0.0, 0.0},
1.2,                        /* GUI scale factor, hardcoded for testing purposes --majeru */
"/usr/share/audacious/Skins/Classic1.3",                       /* skin */
-    NULL,                       /* output plugin */
+    "/usr/lib/audacious/Output/pulse_audio.so (#0)",                       /* output plugin */
NULL,                       /* file selector path */
NULL,                       /* playlist path */

As you can see, this patch is wrong. Why? Because:

  • It uses an absolute path, and an absolute plugin UUID.
  • The value will probably be ignored on first run for most people anyway, resulting in it using ALSA.
  • Obviously we can’t support this change upstream, where all of the Ubuntu users come to ask everything anyway.

I like that, as usual, upstream was not consulted or asked in any way about how to go about making it do what they want. While my first try was wrong, it’s actually wrong due to a bug in audacious; that is the way they should patch it, and they should switch back to my patch in 1.5.1, as the weighted plugin detection is fixed there*.

*On my branch only. Which i will be pushing to proposed/audacious-1.5 soon enough.

Update: apparently some people took this the wrong way and assumed I was flaming Ubuntu here. Why would I? No, I was ranting about the fact that this guy changed a bug and within minutes uploaded this hideous patch. There wasn’t even realistically time to reply to the bug, nor was the patch posted for any sort of public review before hand. Anyone familiar with audacious’s internals would have immediately recognized that the patch is bogus.

How NOT to switch from x86 to amd64 Debian

April 16th, 2008

The following script, or any script like it will not work. Do not waste your time and end up hosing your box like I did today:

#!/bin/bash

echo "==> installing cdebootstrap"
apt-get install cdebootstrap

echo "==> reticulating splines"
dpkg -l | cut -f3 -d' ' >> /tmp/packages.installed
pkg=`cat /tmp/packages.installed | xargs`
pkg=`echo $pkg | sed -e 's#bunch of crap elided here##g'`

echo "==> installing libc6-amd64"
apt-get install libc6-amd64

echo "==> installing base system"
cdebootstrap -a amd64 lenny /

for pkg in $pkg; do
echo "==> reinstalling $pkg"
apt-get install --reinstall --force-yes $pkg
done

Don’t let this happen to you. I had the pleasure of discovering that Bacula was not properly backing up my MySQL databases. What an excellent way of finding out.

Thoughts on srcinst

February 8th, 2008

As eddyp wrote on Planet Debian, there is indeed a tool to roll custom builds of source packages. However, as he also mentioned, it’s written in Haskell, and may be unmaintained.

One of the most commonly heard complaints I have received about Debian (and Ubuntu) is that it does not allow for easily rebuilding source packages. So, I’m going to start writing a new debian package builder for this purpose soon. It’ll probably be a package similar to pbuilder, except aimed at end users instead of developers. Here’s my plan of action:

Phase 1:

  • Interface similar to apt. Creates a build lab based on the current operating system (using lsb_release or similar) using debootstrap if one does not exist, then caches that build lab. A weekly cronjob will be added to make sure the build lab is kept up-to-date. (This would be provided by ’srctool bootstrap’.)
  • Installing and building packages; dependencies will be resolved using gdebi. (This is provided by the ’srctool install package’.)
  • A configuration file allowing you to specify DEB_BUILD_OPTIONS and other parameters to influence the build.

Phase 2:

  • Some sort of policy proposal to add a common debian/rules option for declaring features. So that users can easily rebuild without LDAP support if they don’t want it.
  • General hook to note that a package was built with custom CFLAGS etc for reportbug.

Thoughts:

  • Is this harmful to Debian? I don’t think it is. Here’s why: most end-users will continue to use aptitude/apt-get and binary packages because they don’t care about building it. The key point here is, most Debian users just want their computer to work. As such, they won’t use srctool.
  • The main point for srctool is to allow for easily slipstreaming in patches and custom build options in an easy way. (Also maybe in the future, local bumps if they want newer upstream version than what Debian provides them.)

Anyway, that’s just a project I have planned on the side over the next few months.

Introducing dsyslog

February 6th, 2008

I’ve been writing my own syslog daemon for the last couple of weeks because the other daemons are not sufficient for my needs or require you to sign obnoxious CLAs in order to contribute.

I made a page about it on nenolod.net here. You can check out the repository using:

$ hg clone http://hg.atheme.org/dsyslog

Hopefully some of my blog readers might write some patches!

More proof that infosec people are just parasitic jerks…

February 1st, 2008

Today I was directed to a post written by at Errata Security concerning the lovely OLPC project. For those of you who don’t know what the OLPC guys are doing, e.g. you’ve been sleeping under a rock for the last four or five years, the OLPC guys are building a cheap laptop for kids to use, and it’s targeted at enabling thirdworld countries which do not have computing in their schools. Anyway, you can check out the wonderful example of trolling here, in a post titled “Why the OLPC promotes terrorism”. It ends with a nice picture of an XO running Metasploit, I guess this is intended to scare people into having an irrational fear of the OLPC project.

A fair warning before: I don’t own an OLPC XO, but I think that Sugar is a major innovation in human-computer interaction, and is certaintly welcome in the open source world, additionally, not all Infosec people are like this, just a large amount of them. (By large, I mean, it would easily overflow a “long long” value if you counted the amount.)

Right, well anyway, I’ve had it with this nonsense, and I intend to counter his argument in a few ways. I’ll start out by pointing out that:

Errata Security and it’s employees are parasitic of the work made by other people. These people work on projects that Errata Security (and other infosec people) blog about and discover vulnerabilities in. This in itself is OK, as long as you don’t slag the work done by the people you make your money from exploiting. As long as they stick to that guideline, people will view them as symbiotic, but when you write a blog post, or make a public comment, slagging a project, you do more than just anger that individual project. Theo de Raadt once said that “to stay open, you must stay vocal”. As such, when you slag a project, you harm your own reputation.

Metasploit will run at least equally well on the Intel PC as it does on the XO. Seriously, I don’t see how this is a flaw in the OLPC XO. When you own a computer, it is up to you if you use it for productive means or not. Also, lets consider that perhaps the fact that OLPC can run Metasploit means that it may teach proper security procedures to users of computers in developing countries. Oh. Wait. That might harm your business model, we can’t have that! Now I see why you want to attack people. It’s all about protecting your company from a new generation of clueful computer users. Brilliant.

Many infosec researchers release PoC code which is not defanged. This is arguably more harmful to America’s IT infrastructure than the OLPC XO is. To those people who release such PoCs, I will simply say that you are the most parasitic of all. I do not know if Errata Security has ever released such a PoC, I hope not for their sake, as I will point it out if I ever discover they do, they have annoyed me this much. Hopefully they have more sense than to put a live piece of shellcode into the hands of america’s script kiddies, giving them yet another worm for DroneBL to track.

Programming languages are not sentient beings, and therefore cannot be left or right wing, communist or capitalist. What utter tripe. Stop smoking crack before you further harm your company’s reputation. Maybe the creator of Python, Guido van Rossum, is left-wing, but that doesn’t mean Python itself is. Also, how the hell is C++ capitalist?

Is Open Source software in general communist? I invite Robert to comment on this. I really really do. Of course, I imagine that instead of commenting, or even better, apologizing to the open source world, he will probably blog about me, or post some nasty PoC about my software to bugtraq now. I’m sorry in advance for any damage he may do.

In closing, we have yet another infosec person making an arse of himself. I hope for his own sake that he reconsiders whether or not that was a wise move. Also, apologies to any legitimate infosec people who do what they do because they feel it’s important, trust me, this wasn’t about you.

Update: I just noticed that these Errata Security guys may be pro-Windows. So I guess that answers my question on whether or not this guy thinks Open Source software in general is communism.

Update 2: Craig Edwards noticed that Errata Security has instructions on how to run Metasploit on an Nokia N800 cellphone. Does this mean that cellphones are now a communist plot too?

nenolod’s 10 minute hax presents: cxxdemangle

January 23rd, 2008
nenolod@petrie:~/dev-src/cxxdemangle$ ./demangle _ZN10CSoundFile12InitializeEQEb
'_ZN10CSoundFile12InitializeEQEb' => 'CSoundFile::InitializeEQ(bool)'

Now you too can know what those weird C++ symbol names mean. Download now. Use make to build. You don’t even have to install it.

How not to write a preferences system

January 1st, 2008

In conspire, we have gotten to a point, where we need to rewrite the preferences system. I’ll go over how the current one works, though, in this blog post, as advice on how NOT to do it. Well, actually, there are many things about xchat’s preferences engine which are good, it’s just that there’s also many things which are not. ;)

First of all, all of the preferences are stored in a single struct. This is actually IMPORTANT for how the current XChat prefs system works (everything is an offset from the struct’s base. more on that later.):

 struct xchatprefs
{
        char nick1[NICKLEN];
        char nick2[NICKLEN];
        char nick3[NICKLEN];
        ...
};

Like that, above.

Now, about the offset stuff. This is just the most amazing pile of craq I have seen in a while (and I know craq, I forked XMMS/BMP classic after all). Here’s the code:

#define STRUCT_OFFSET_STR(type,field) \
( (unsigned int) (((char *) (&(((type *) NULL)->field)))- ((char *) NULL)) )
#define STRUCT_OFFSET_INT(type,field) \
( (unsigned int) (((int *) (&(((type *) NULL)->field)))- ((int *) NULL)) )

#define P_OFFSET(field) STRUCT_OFFSET_STR(struct xchatprefs, field),sizeof(prefs.field)
#define P_OFFSETNL(field) STRUCT_OFFSET_STR(struct xchatprefs, field)
#define P_OFFINT(field) STRUCT_OFFSET_INT(struct xchatprefs, field),0
#define P_OFFINTNL(field) STRUCT_OFFSET_INT(struct xchatprefs, field)

Ok, now, here’s what it does.

The macro STRUCT_OFFSET_STR(type, field) calculates the offset of a struct member from the struct’s base by defining a pointer to a structure of the same type at NULL, creating a reference to the struct member, and subtracting the base address from it.

The macro STRUCT_OFFSET_INT(type, field) calculates the offset of a struct member from the struct’s base by defining a pointer to a structure of the same type at NULL, creating a reference to the struct member, and subtracting the base address from it.

The macro P_OFFSET(field) calculates the offset of a member from the preferences struct’s base by using STRUCT_OFFSET_STR(type, field). It additionally defines the size of the field’s type.

The macro P_OFFSETNL(field) calculates the offset of a member from the preferences struct’s base by using STRUCT_OFFSET_STR(type, field).

The macro P_OFFINT(field) calculates the offset of a member from the preferences struct’s base by using STRUCT_OFFSET_INT(type, field). It additionally defines the size of the field’s type.

The macro P_OFFINTNL(field) calculates the offset of a member from the preferences struct’s base by using STRUCT_OFFSET_INT(type, field).

In reality, there are no differences between P_OFFSET and P_OFFINT. These values are used to populate an array of this struct type:

struct prefs
{
        char *name;
        unsigned short offset;
        unsigned short len;
        unsigned short type;
};

These structs form a table which contains all of the preferences which are stored in the configuration file and settable via the /set command. There are three types:

#define TYPE_STR 0
#define TYPE_INT 1
#define TYPE_BOOL 2

These types indicate how they should be saved, etcetera.

Now how does the GUI frontend manipulate these settings? Great question! By using the P_OFFSETNL and P_OFFINTNL macros.

The rewrite of this will be discussed in a later blog entry.

libmowgli 0.6.0 out

December 27th, 2007

Great news!

We have released libmowgli 0.6.0. You can get it from distfiles.atheme.org. Amongst other interesting features includes a new magazine-based heap allocator written by Jilles, which replaces the algorithm initially inherited from claro-base.

Also, we plan on releasing conspire 0.10 sometime in January.

Fun with Mercurial!

September 10th, 2007

Right, so I have a setup with paludis (the only package manager which makes Gentoo usable), and some ebuilds which use inherit mercurial in combination with my local mercurial repositories to build from them.

This works most of the time, except when big merges happen. I think it’s a bug in Mercurial, but it could be caused by a sandbox issue instead.

Sometimes this is what happens:

pulling from /home/nenolod/dev-src/audacious-plugins
searching for changes
adding changesets
adding manifests
adding file changes
abort: unknown parent af8c5f5e284c!
transaction abort!
rollback completed

When I blow away the repo made by the mercurial eclass (e.g. rm -rf /var/paludis/repositories/gentoo/distfiles/hg-src/audacious-plugins), it works fine.

Go figure.