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

[Michael Militzer]

Hi,

just a quick reply:

As far as I know the different IA64 optimizations had been developed in
small groups of students. So likely the authors of the other IA64 files are
unfortunately not the same as those in src/dct/ia64_asm/fdct_ia64.s

Regarding your 1.2.1 build problems: Have you checked the output of the
configure script on why asm optimizations got disabled? Note that you need
nasm for 1.2.1. Yasm won't do. Also you need a fairly recent nasm version
(>= 2.0).

Regards,
Michael


Quoting Loïc Martin <loic.martin3 at gmail.com>:

> 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
> http://www.xvid.org/Downloads.43.0.html.
>
> 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.
>
> Loïc
> _______________________________________________
> Xvid-devel mailing list
> Xvid-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>