[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#470091: ltp package in Debian



On Mon, 20 Oct 2008 14:41:15 +0200, Riku Voipio <riku.voipio@iki.fi> wrote:

On Fri, Oct 10, 2008 at 12:41:57AM +0200, Jiří Paleček wrote:
just before you read the rest, I've uploaded a new version of ltp to
mentors, URL as usual.

http://mentors.debian.net/debian/pool/main/l/ltp

It is slightly less tested than the previous version, especially the new
tests (containers, connectors). If anybody feels s/he knows what these are
for and has a kernel that supports them, feel free to test.

The diff.gz delta compared to upstream is getting quite big, so
reviewing is getting a bit burdensom as well..

You can look into the repository, it should be easier (sorry I screwed up the last push that the heads were not updated, so the current version was only available under a tag).

However, before I got the
I got bombed out with a strange build error (using pdebuild) log
attached. I don't see where the a.out file suddenly appears from..

Seems to be a bug in the makefile. As to "where it comes from?", see

http://repo.or.cz/w/ltp-debian.git?a=blob;f=testcases/kernel/syscalls/eventfd/Makefile;h=da9faa0c20a875f2ad7881b86bbbe29058d131dc;hb=a641942ed5713f3041481096f2ceff5c264e9f19

about line 30.

Yes, I knew that. One thing that surprised me, was that different
architectures don't seem to agree on #defines in kernel headers (eg. look
at the strings in timerfd01 test). Is it possible that different
architectures' buildds have different kernel versions?

All archs in debian should use same kernel version (atleast as regarding
for kernel headers). However, some architectures implement various
kernel features slower than others.

Strange, because the timerfd01 test compilation should only depend on kernel #defines - yet the results are little haphazard (IIRC, amd64 - no, ia64 - yes, s390 - yes, ppc - no?)

Also, some architectures (like kfreebsd-*) fail due to lack of system
libraries (i.e. only libcap now, but will concern libaio too). What could
I do against it? Should I?

Does it really make any sense to run LTP (where L is for Linux) on other
OS's?

Well, not all tests are linux specific. Many tests for posix syscalls should be portable, ditto commands test which really test your favourite cron/syslog/mail/ftp etc. daemon and your ability to set it up correctly.

The tests are not even made for linux in many cases, they are just ported. For example, I have some plans with packaging ballista, I made it compile & run on my box, but the descriptions of the syscalls for ballista are from Digital UNIX (IIRC) and some don't compile on Linux.

The question is, should I ditch the support for those other arches/OSes because of new linux specific tests, even though the old LTP packages compiled on them and the new would probably compile too if there weren't those dependencies?

>Brtw, do you intend to apply for Debian Developer (
>https://nm.debian.org )
>or Debian Maintainer ( http://wiki.debian.org/Maintainers ) ? For both
>cases you need to get your key signed by a Debian Developer.

That's a tough question, but isn't it a little too early after a single
upload?

That was more a question of what your ambitions are, ie how
involved do you plan to get with debian.

No plans so far, sorry.

Regards
   Jiri Palecek



Reply to: