[XviD-devel] Packaging issues, copyright/license check and big drop in performance in 1.2.1 compared to 1.1.2 (amd64)

Loïc Martin loic.martin3 at gmail.com
Wed Feb 18 20:32:18 CET 2009

Michael Militzer wrote:
> Hi,
> I'm not really familiar with the task of packaging software and especially
> not with Ubuntu and its policies, so bear with me...
> To answer your questions:
> 1. Once we released a tarball without the debian directory the debian
> users were unhappy. So removing the debian dir might likely break the
> scripts of others. Same with the directory naming. It could certainly be
> changed but may come unexpected to others that rely on the current naming.
> And I'd be also reluctant to provide multiple variants of the tarballs...

As far as I understand, Ubuntu policies comes straight from Debian, and
Debian packagers need to repack the archive as much as we do (deleting
the debian directory).

A possible solution is to name the directory debian-upstream or
something like that, then simlink it to debian with a script for users
that want to build the packages for themselves.

There's no urgency to it, it's just a tradeoff (repack means we can't
preserve md5sum compatibility with the download from xvid.org). On the
maintainer side, patching is possible instead, but would make
maintenance painful.

For the naming of the xvidcore directory, most projects use foo-version
for the directory name. It's probably only my laziness (saves renaming
the folder manually).

> The page 'http://www.xvid.org/downloads.html' will always point to the
> current download page. This link is fix since years. The tarballs will also
> always be available at 'http://downloads.xvid.org/downloads/'. So it's
> rather safe to rely on that.

http://downloads.xvid.org/downloads doesn't have a html page associated
with it, I think that's what's giving trouble to uscan, and probably why
neither Ubuntu nor Debian has up-to-date packages (Ubuntu has 1.1.2,
Debian 1.1, see http://debian-unofficial.org/packages.html).
http://www.xvid.org/downloads.html redirects me to

Would it be possible to have directory indexing enabled in
http://downloads.xvid.org/downloads so it shows the files in the
directory? Our watch file problem is a troublesome issue, as it was only
mere chance I noticed our version was 2 years old.

Having outdated packages in Debian and Ubuntu might also be why people
need the debian folder in the tarballs...

> 2. The files you list lacking copyrights are almost all related to the IA64
> source code. The xvid IA64 port had been contributed under the GPL-2+ by
> students of university of Karlsruhe many years ago.
> The files fdct.c, idct.c had been taken from other GPL/LPGL licensed
> projects long ago (iirc libmpeg2 and ffmpeg) and are e.g. also part of
> current libavcodec. I consider the files to be distributable under GPL.

Thanks for the clarifications.

Indeed, the ia64_asm files all have "ia64p" as Author in the CVS (06-07
2002) which probably stands for "ia64 Project" or similar.

Do you think the header for header as in src/dct/ia64_asm/fdct_ia64.s
would work for those, and if so would you mind patching them with it if
I provide you with the .diff?

> 3. I think the performance drop is suspicious. Are you sure you have compiled
> with asm optimizations enabled? Did you have nasm present?
> The PPC asm code can be compiled with gcc and has no further dependencies.

I checked a bit, and I can build 1.1.2 packages with assembler code
enabled. However, 1.2.1 doesn't enable any assembly (f.e. I can pbuild
the 1.2.1 binary packages for i386 on an amd64 arch, which is impossible
for 1.1.2 as for any software that uses asm).

I checked the build directory, and configure has many changes, a lot of
those related to nasm and yasm.

However, I don't know enough to troubleshoot the issue in the code.

As far as I tried, with 1.2.1 neither nasm nor yasm work for i386 or
amd64 (our packaging uses yasm, the packaging you ship in the tarball
uses nasm). It's possible the problem only shows on a
Debian/Ubuntu/Other Debian derivatives, but I can't tell.

As for now, we're stuck with 1.1.2.


More information about the Xvid-devel mailing list