Debian Bug report logs - #465177
FTBFS: configure: error: unable to configure inotify support

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: submit@bugs.debian.org

Subject: FTBFS: configure: error: unable to configure inotify support

Date: Sun, 10 Feb 2008 23:43:19 -0500

Source: mediatomb
Version: 0.10.0.dfsg1-1
Severity: serious

Mediatomb is failing to build on some architectures with these last entries. 
The architectures it's failing to build on is powerpc and ia64.

checking sys/inotify.h usability... yes
checking sys/inotify.h presence... yes
checking for sys/inotify.h... yes
checking whether sys/inotify.h works... no, using own inotify headers
checking whether inotify-nosys.h works... no, disabling inotify support
configure: error: unable to configure inotify support
make: *** [configure-stamp] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

For the powerpc, powerpc packages have been created before 
(http://mediatomb.cc/pages/download#debian_ubuntu). The link to the powerpc 
packages is dead however.

-- 
Regards,
Andres

Message #10 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Sergey 'Jin' Bostandzhyan <jin@mediatomb.cc>

To: 465177@bugs.debian.org

Subject: FTBFS: configure: error: unable to configure inotify support

Date: Mon, 11 Feb 2008 12:14:31 +0100

Hi,

I'm one of the authors of MediaTomb, here is some info on this:

do not pass the --enable-inotify parameter to the configure script; presence
of inotify will be detected automatically, if not available it will be disabled
on the fly. However, when the --enable-inotify parameter is passed by the
user, configure will abort with the error that you are seeing if inotify
checks fail.

What I still need to do is, to adapt the inotify check for cross compiling,
right now it will always fail when cross compiled.

I hope that info helps.

Kind regards,
Jin

Message #15 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: Sergey 'Jin' Bostandzhyan <jin@mediatomb.cc>, 465177@bugs.debian.org

Subject: Re: Bug#465177: FTBFS: configure: error: unable to configure inotify support

Date: Mon, 11 Feb 2008 13:41:03 -0500

On Monday 11 February 2008 6:14:31 am Sergey 'Jin' Bostandzhyan wrote:
> Hi,
>
> I'm one of the authors of MediaTomb, here is some info on this:
>
> do not pass the --enable-inotify parameter to the configure script;
> presence of inotify will be detected automatically, if not available it
> will be disabled on the fly. However, when the --enable-inotify parameter
> is passed by the user, configure will abort with the error that you are
> seeing if inotify checks fail.

This is done on purpose so that no package on a different architecture/kernel 
builds packages sucessfully with a different set of options enabled, else I'm 
sure there would be a different set of bugs sooner or later. The inotify 
option is not enabled for any non-linux kernel using machine.

The parameters passed to the configure script can be manually overridden by a 
user, but they won't be for the buildd machines.

> What I still need to do is, to adapt the inotify check for cross compiling,
> right now it will always fail when cross compiled.

Actually, no cross compiling is done. The powerpc buildd machine is a powerpc 
machine. The same goes for the other buildd machines.

> I hope that info helps.
>
> Kind regards,
> Jin



-- 
Regards,
Andres

Message #20 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Sergey Jin' Bostandzhyan <jin@mediatomb.cc>

To: Andres Mejia <mcitadel@gmail.com>

Cc: 465177@bugs.debian.org

Subject: Re: Bug#465177: FTBFS: configure: error: unable to configure inotify support

Date: Mon, 11 Feb 2008 21:13:56 +0100

On Mon, Feb 11, 2008 at 01:41:03PM -0500, Andres Mejia wrote:
> > do not pass the --enable-inotify parameter to the configure script;
> > presence of inotify will be detected automatically, if not available it
> > will be disabled on the fly. However, when the --enable-inotify parameter
> > is passed by the user, configure will abort with the error that you are
> > seeing if inotify checks fail.
> 
> This is done on purpose so that no package on a different architecture/kernel 
> builds packages sucessfully with a different set of options enabled, else I'm 
> sure there would be a different set of bugs sooner or later. The inotify 
> option is not enabled for any non-linux kernel using machine.
> 
> The parameters passed to the configure script can be manually overridden by a 
> user, but they won't be for the buildd machines.

Well, if you are sure that the target machines *do have inotify support*
the only thing that could help is the config.log output of the failed 
configure process.

> > What I still need to do is, to adapt the inotify check for cross compiling,
> > right now it will always fail when cross compiled.
> 
> Actually, no cross compiling is done. The powerpc buildd machine is a powerpc 
> machine. The same goes for the other buildd machines.

Then it should work; we do check the headers and then we run some small test
code which is calling inotify_init(). If the inotify_init() function returns 
-1 (error) we will compile without inotify support; however - if 
the --enable-inotify parameter was specified configure will abort because it 
can not do what the user wanted.

So the question: is inotify really working on those systems?

Kind regards,
Jin

Message #25 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: Sergey Jin' Bostandzhyan <jin@mediatomb.cc>

Cc: 465177@bugs.debian.org

Subject: Re: Bug#465177: FTBFS: configure: error: unable to configure inotify support

Date: Mon, 11 Feb 2008 18:54:10 -0500

On Monday 11 February 2008 3:13:56 pm Sergey Jin' Bostandzhyan wrote:
> On Mon, Feb 11, 2008 at 01:41:03PM -0500, Andres Mejia wrote:
> > > do not pass the --enable-inotify parameter to the configure script;
> > > presence of inotify will be detected automatically, if not available it
> > > will be disabled on the fly. However, when the --enable-inotify
> > > parameter is passed by the user, configure will abort with the error
> > > that you are seeing if inotify checks fail.
> >
> > This is done on purpose so that no package on a different
> > architecture/kernel builds packages sucessfully with a different set of
> > options enabled, else I'm sure there would be a different set of bugs
> > sooner or later. The inotify option is not enabled for any non-linux
> > kernel using machine.
> >
> > The parameters passed to the configure script can be manually overridden
> > by a user, but they won't be for the buildd machines.
>
> Well, if you are sure that the target machines *do have inotify support*
> the only thing that could help is the config.log output of the failed
> configure process.

The best thing toward logs are located at 
http://buildd.debian.org/pkg.cgi?pkg=mediatomb .

> > > What I still need to do is, to adapt the inotify check for cross
> > > compiling, right now it will always fail when cross compiled.
> >
> > Actually, no cross compiling is done. The powerpc buildd machine is a
> > powerpc machine. The same goes for the other buildd machines.
>
> Then it should work; we do check the headers and then we run some small
> test code which is calling inotify_init(). If the inotify_init() function
> returns -1 (error) we will compile without inotify support; however - if
> the --enable-inotify parameter was specified configure will abort because
> it can not do what the user wanted.
>
> So the question: is inotify really working on those systems?
>
> Kind regards,
> Jin

I'm finding this behavior strange. Ubuntu accepted mediatomb into their 
archive, yet now the powerpc architecture goes past the inotify check just 
fine, but the i386 and amd64 architectures do not. Take a look at 
https://launchpad.net/ubuntu/+source/mediatomb/0.10.0.dfsg1-1/

I know for the case of the i386, I've been able to successfully build packages 
using pbuilder.

Also, it looks like the Ubuntu buildd machines are giving a different error, 
for architectures that run the inotify check sucessfully.

-- 
Regards,
Andres

Message #30 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Sergey Jin' Bostandzhyan <jin@mediatomb.cc>

To: Andres Mejia <mcitadel@gmail.com>

Cc: 465177@bugs.debian.org, leo@mediatomb.cc

Subject: Re: Bug#465177: FTBFS: configure: error: unable to configure inotify support

Date: Tue, 12 Feb 2008 01:59:40 +0100

Hi,

On Mon, Feb 11, 2008 at 06:54:10PM -0500, Andres Mejia wrote:
> > Well, if you are sure that the target machines *do have inotify support*
> > the only thing that could help is the config.log output of the failed
> > configure process.
> 
> The best thing toward logs are located at 
> http://buildd.debian.org/pkg.cgi?pkg=mediatomb .

That's the stdout of configure, what I am looking for is the config.log
file that is created by configure during the process, but this is not there
because everything is purged after the build. Any idea if we can get it?
 
> > Then it should work; we do check the headers and then we run some small
> > test code which is calling inotify_init(). If the inotify_init() function
> > returns -1 (error) we will compile without inotify support; however - if
> > the --enable-inotify parameter was specified configure will abort because
> > it can not do what the user wanted.
> >
> > So the question: is inotify really working on those systems?
> 
> I'm finding this behavior strange. Ubuntu accepted mediatomb into their 
> archive, yet now the powerpc architecture goes past the inotify check just 
> fine, but the i386 and amd64 architectures do not. Take a look at 
> https://launchpad.net/ubuntu/+source/mediatomb/0.10.0.dfsg1-1/

This is indeed very strange, it must be somehow related to the setup of
the particular machine. What I see is that the default inotify header is
not working, then we are retrying with our own and then it is failing.

However, without seeing the config.log file I can not say anything...

> I know for the case of the i386, I've been able to successfully build packages 
> using pbuilder.

Yes, I know, Leo has also been using pbuilder to create our custom .deb 
packages and we did not have any problems with inotify.

Is the exact environment that those machines are using available somewhere?
Can we reproduce the problem somehow?

> Also, it looks like the Ubuntu buildd machines are giving a different error, 
> for architectures that run the inotify check sucessfully.

Indeed, it seems that the build runs through but there is something wrong
with the package, can't say much there either - I have no experience with 
.deb packages.

Kind regards,
Jin

Message #35 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: Sven Mueller <sven@debian.org>

Cc: 465177@bugs.debian.org, "Sergey Jin' Bostandzhyan" <jin@mediatomb.cc>

Subject: Fwd: Re: Bug#465177: FTBFS: configure: error: unable to configure inotify support

Date: Mon, 11 Feb 2008 21:21:40 -0500

Hello Sven,

I don't know if you were tracking this, but there's this bug where certain 
architectures are failing to build mediatomb.

Now as I understand it, the buildd machines builds packages in a chroot 
environment, with all packages found under unstable (the kernel, gcc, etc.). 
Isn't this correct?

Here I'm forwarding a mail to you from one of the developers of Mediatomb. Can 
you help with this?


----------  Forwarded Message  ----------

Subject: Re: Bug#465177: FTBFS: configure: error: unable to configure inotify 
support
Date: Monday 11 February 2008
From: Sergey Jin' Bostandzhyan <jin@mediatomb.cc>
To: Andres Mejia <mcitadel@gmail.com>

Hi,

On Mon, Feb 11, 2008 at 06:54:10PM -0500, Andres Mejia wrote:
> > Well, if you are sure that the target machines *do have inotify support*
> > the only thing that could help is the config.log output of the failed
> > configure process.
> 
> The best thing toward logs are located at 
> http://buildd.debian.org/pkg.cgi?pkg=mediatomb .

That's the stdout of configure, what I am looking for is the config.log
file that is created by configure during the process, but this is not there
because everything is purged after the build. Any idea if we can get it?
 
> > Then it should work; we do check the headers and then we run some small
> > test code which is calling inotify_init(). If the inotify_init() function
> > returns -1 (error) we will compile without inotify support; however - if
> > the --enable-inotify parameter was specified configure will abort because
> > it can not do what the user wanted.
> >
> > So the question: is inotify really working on those systems?
> 
> I'm finding this behavior strange. Ubuntu accepted mediatomb into their 
> archive, yet now the powerpc architecture goes past the inotify check just 
> fine, but the i386 and amd64 architectures do not. Take a look at 
> https://launchpad.net/ubuntu/+source/mediatomb/0.10.0.dfsg1-1/

This is indeed very strange, it must be somehow related to the setup of
the particular machine. What I see is that the default inotify header is
not working, then we are retrying with our own and then it is failing.

However, without seeing the config.log file I can not say anything...

> I know for the case of the i386, I've been able to successfully build 
packages 
> using pbuilder.

Yes, I know, Leo has also been using pbuilder to create our custom .deb 
packages and we did not have any problems with inotify.

Is the exact environment that those machines are using available somewhere?
Can we reproduce the problem somehow?

> Also, it looks like the Ubuntu buildd machines are giving a different error, 
> for architectures that run the inotify check sucessfully.

Indeed, it seems that the build runs through but there is something wrong
with the package, can't say much there either - I have no experience with 
.deb packages.

Kind regards,
Jin


-------------------------------------------------------

-- 
Regards,
Andres

Message #42 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: Sergey Jin' Bostandzhyan <jin@mediatomb.cc>, 465177@bugs.debian.org, Leonhard Wimmer <leo@mediatomb.cc>, Sven Mueller <sven@debian.org>

Subject: Re: Bug#465177: FTBFS: configure: error: unable to configure inotify support

Date: Mon, 11 Feb 2008 23:45:37 -0500

On Monday 11 February 2008 7:59:40 pm Sergey Jin' Bostandzhyan wrote:
> Hi,
>
> On Mon, Feb 11, 2008 at 06:54:10PM -0500, Andres Mejia wrote:
> > > Well, if you are sure that the target machines *do have inotify
> > > support* the only thing that could help is the config.log output of the
> > > failed configure process.
> >
> > The best thing toward logs are located at
> > http://buildd.debian.org/pkg.cgi?pkg=mediatomb .
>
> That's the stdout of configure, what I am looking for is the config.log
> file that is created by configure during the process, but this is not there
> because everything is purged after the build. Any idea if we can get it?
>
> > > Then it should work; we do check the headers and then we run some small
> > > test code which is calling inotify_init(). If the inotify_init()
> > > function returns -1 (error) we will compile without inotify support;
> > > however - if the --enable-inotify parameter was specified configure
> > > will abort because it can not do what the user wanted.
> > >
> > > So the question: is inotify really working on those systems?
> >
> > I'm finding this behavior strange. Ubuntu accepted mediatomb into their
> > archive, yet now the powerpc architecture goes past the inotify check
> > just fine, but the i386 and amd64 architectures do not. Take a look at
> > https://launchpad.net/ubuntu/+source/mediatomb/0.10.0.dfsg1-1/
>
> This is indeed very strange, it must be somehow related to the setup of
> the particular machine. What I see is that the default inotify header is
> not working, then we are retrying with our own and then it is failing.
>
> However, without seeing the config.log file I can not say anything...
>
> > I know for the case of the i386, I've been able to successfully build
> > packages using pbuilder.
>
> Yes, I know, Leo has also been using pbuilder to create our custom .deb
> packages and we did not have any problems with inotify.
>
> Is the exact environment that those machines are using available somewhere?
> Can we reproduce the problem somehow?
>
> > Also, it looks like the Ubuntu buildd machines are giving a different
> > error, for architectures that run the inotify check sucessfully.
>
> Indeed, it seems that the build runs through but there is something wrong
> with the package, can't say much there either - I have no experience with
> .deb packages.
>
> Kind regards,
> Jin

I've investigated this some more and found that the inotify-tools package 
fails the test to see if sys/inotify.h actually works for the powerpc and 
ia64 architectures as well, yet the build continues for that package, unlike 
in mediatomb. Here's the difference between the two packages' configure.ac

*****mediatomb's configure.ac*****
dnl The check below was inspired by configure.ac from the inotify tools
dnl package, see the "Acknowledgements" section in our README file for more 
dnl information.
    CXXFLAGS="$CXXFLAGS $INOTIFY_CXXFLAGS"
    AC_MSG_CHECKING([whether sys/inotify.h works])
    AC_RUN_IFELSE(
        AC_LANG_PROGRAM([[#include <sys/inotify.h>]],
                         [[return (-1 == inotify_init());]]
                       ),
                [
                    AC_MSG_RESULT([yes]); 
                    AC_DEFINE([SYS_INOTIFY_H_OK],[1],[sys/inotify.h exists and 
works correctly])],
                [
                    AC_MSG_RESULT([no, using own inotify headers])
                    AC_MSG_CHECKING([whether inotify-nosys.h works])
                    AC_RUN_IFELSE(
                        AC_LANG_PROGRAM([[#include "src/inotify-nosys.h"]],
                         [[return (-1 == inotify_init());]]
                        ),
                        [
                            AC_MSG_RESULT([yes]);
                            INOTIFY_OK=yes
                        ],
                        [
                            AC_MSG_RESULT([no, disabling inotify support])
                            INOTIFY_OK=missing
                        ])

                ])
fi

*****inotify-tools configure.ac*****
# Checks for header files.
AC_CHECK_HEADERS([sys/inotify.h mcheck.h])
AC_LANG(C)
AC_MSG_CHECKING([whether sys/inotify.h actually works])
AC_RUN_IFELSE(
  AC_LANG_PROGRAM([[#include <sys/inotify.h>]],
                  [[return (-1 == inotify_init());]]
  ),
  [AC_MSG_RESULT([yup]); AC_DEFINE([SYS_INOTIFY_H_EXISTS_AND_WORKS],[1],
[sys/inotify.h exists and works correctly])],
  [AC_MSG_RESULT([nope, using own inotify headers])]
)

Perhaps I'm wrong about what kernel each buildd machine is using. This would 
explain why this check fails on these architectures, but I can't find a 
straight answer. Sven, do you know the answer to this?

The buildd machines use sbuild, which uses debootstrap for creating the chroot 
environment, so I'm sure at least the latest version of linux-libc-dev is 
installed. In case some buildd machines don't support inotify, the check to 
see if inotify works should be left out.

-- 
Regards,
Andres

Message #47 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Sven Mueller <sven@debian.org>

To: Andres Mejia <mcitadel@gmail.com>

Cc: Sergey Jin' Bostandzhyan <jin@mediatomb.cc>, 465177@bugs.debian.org, Leonhard Wimmer <leo@mediatomb.cc>

Subject: Re: Bug#465177: FTBFS: configuRe: error: unable to configure inotify support

Date: Tue, 12 Feb 2008 12:19:22 +0100

[Message part 1 (text/plain, inline)]

Andres Mejia wrote on 12/02/2008 05:45:
> I've investigated this some more and found that the inotify-tools package 
> fails the test to see if sys/inotify.h actually works for the powerpc and 
> ia64 architectures as well, yet the build continues for that package, unlike 
> in mediatomb. Here's the difference between the two packages' configure.ac
[...]
> Perhaps I'm wrong about what kernel each buildd machine is using. This would 
> explain why this check fails on these architectures, but I can't find a 
> straight answer. Sven, do you know the answer to this?

No, sorry. Best bet IMHO is to contact the porters for the given 
architectures and ask for their help:

debian-ia64@lists.debian.org
debian-powerpc@lists.debian.org

And the buildd admins for those architectures (if the porters can't help):

ia64@buildd.debian.org
powerpc@buildd.debian.org

> The buildd machines use sbuild, which uses debootstrap for creating the chroot 
> environment, so I'm sure at least the latest version of linux-libc-dev is 
> installed. In case some buildd machines don't support inotify, the check to 
> see if inotify works should be left out.

Probably. Though the buildds should support the latest _stable_ kernel 
with the latest _unstable_ chroot environment. And since 2.6.18 supports 
inotify, I fail to see why this doesn't work on the architectures named. 
But I'm unsure wether inotify is supported on all Linux architectures 
(though I'm 90% certain it is, I don't see anything hardware specific in 
there).

cu,
Sven

[signature.asc (application/pgp-signature, attachment)]

Message #52 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: debian-powerpc@lists.debian.org

Cc: 465177@bugs.debian.org, "Sergey Jin' Bostandzhyan" <jin@mediatomb.cc>, Leonhard Wimmer <leo@mediatomb.cc>, Sven Mueller <sven@debian.org>

Subject: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support

Date: Tue, 12 Feb 2008 19:02:02 -0500

Hi,

There's this issue where mediatomb fails to build on the powerpc. The bug is 
http://bugs.debian.org/465177. Does anyone here know if inotify is supported 
on the powerpc?

Also, does anyone know what kernel version the powerpc buildd machines are 
using?

Please respond to me and 465177@bugs.debian.org. Thanks.

-- 
Regards,
Andres

Message #57 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Michel Dänzer <daenzer@debian.org>

To: Andres Mejia <mcitadel@gmail.com>

Cc: debian-powerpc@lists.debian.org, 465177@bugs.debian.org, Sergey Jin' Bostandzhyan <jin@mediatomb.cc>, Leonhard Wimmer <leo@mediatomb.cc>, Sven Mueller <sven@debian.org>

Subject: Re: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support

Date: Wed, 13 Feb 2008 00:09:49 +0000

On Tue, 2008-02-12 at 19:02 -0500, Andres Mejia wrote:
> 
> There's this issue where mediatomb fails to build on the powerpc. The bug is 
> http://bugs.debian.org/465177. Does anyone here know if inotify is supported 
> on the powerpc?

It is.

> Also, does anyone know what kernel version the powerpc buildd machines are 
> using?

Possibly an oldish one, but it shouldn't matter. Whether the kernel
supports inotify should be checked at runtime, not build time.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

Message #62 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: 465177@bugs.debian.org, Sergey Jin' Bostandzhyan <jin@mediatomb.cc>, Leonhard Wimmer <leo@mediatomb.cc>, Sven Mueller <sven@debian.org>

Subject: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support

Date: Tue, 12 Feb 2008 22:40:20 -0500

On Tuesday 12 February 2008 7:09:49 pm Michel Dänzer wrote:
> On Tue, 2008-02-12 at 19:02 -0500, Andres Mejia wrote:
> > There's this issue where mediatomb fails to build on the powerpc. The bug
> > is http://bugs.debian.org/465177. Does anyone here know if inotify is
> > supported on the powerpc?
>
> It is.
>
> > Also, does anyone know what kernel version the powerpc buildd machines
> > are using?
>
> Possibly an oldish one, but it shouldn't matter. Whether the kernel
> supports inotify should be checked at runtime, not build time.

Well, this makes sense. I could fix this for the build time. Does mediatomb 
already check for inotify during runtime?

As far as fixing this for build time, I'm guessing the inotify-tools has this 
check only to serve the purpose of seeing if the linux inotify headers work, 
and if not, just drop back to it's own implementation. For mediatomb, we 
should just be worried about the presence and usability of sys/inotify.h. If 
it turns out there's a problem with the inotify headers, then it should be 
reported against the linux packages.

-- 
Regards,
Andres

Message #67 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Sergey Jin' Bostandzhyan <jin@mediatomb.cc>

To: Andres Mejia <mcitadel@gmail.com>

Cc: 465177@bugs.debian.org, Leonhard Wimmer <leo@mediatomb.cc>, Sven Mueller <sven@debian.org>

Subject: Re: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support

Date: Thu, 14 Feb 2008 11:26:14 +0100

On Tue, Feb 12, 2008 at 10:40:20PM -0500, Andres Mejia wrote:
> > Possibly an oldish one, but it shouldn't matter. Whether the kernel
> > supports inotify should be checked at runtime, not build time.
> 
> Well, this makes sense. I could fix this for the build time. Does mediatomb 
> already check for inotify during runtime?
> 
> As far as fixing this for build time, I'm guessing the inotify-tools has this 
> check only to serve the purpose of seeing if the linux inotify headers work, 
> and if not, just drop back to it's own implementation. For mediatomb, we 
> should just be worried about the presence and usability of sys/inotify.h. If 
> it turns out there's a problem with the inotify headers, then it should be 
> reported against the linux packages.

We do the same fallback thing and use the same header as inotify tools, we do
have a runtime check, but I have to see what exactly it is doing (i.e., possible
that it will complain at startup and exit)

So indeed, we should add an option which would allow compiling with inotify
support even if inotify is not present on the build system and do a smarter
runtime check.

I'll see that we get this fixed for the upcoming release which should not take
long anymore.

Thanks for the hints.

Kind regards,
Jin

Message #72 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: Sergey Jin' Bostandzhyan <jin@mediatomb.cc>, 465177@bugs.debian.org

Cc: Leonhard Wimmer <leo@mediatomb.cc>

Subject: Re: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support

Date: Tue, 19 Feb 2008 14:33:56 -0500

On Thursday 14 February 2008 5:26:14 am Sergey Jin' Bostandzhyan wrote:
> On Tue, Feb 12, 2008 at 10:40:20PM -0500, Andres Mejia wrote:
> > > Possibly an oldish one, but it shouldn't matter. Whether the kernel
> > > supports inotify should be checked at runtime, not build time.
> >
> > Well, this makes sense. I could fix this for the build time. Does
> > mediatomb already check for inotify during runtime?
> >
> > As far as fixing this for build time, I'm guessing the inotify-tools has
> > this check only to serve the purpose of seeing if the linux inotify
> > headers work, and if not, just drop back to it's own implementation. For
> > mediatomb, we should just be worried about the presence and usability of
> > sys/inotify.h. If it turns out there's a problem with the inotify
> > headers, then it should be reported against the linux packages.
>
> We do the same fallback thing and use the same header as inotify tools, we
> do have a runtime check, but I have to see what exactly it is doing (i.e.,
> possible that it will complain at startup and exit)
>
> So indeed, we should add an option which would allow compiling with inotify
> support even if inotify is not present on the build system and do a smarter
> runtime check.
>
> I'll see that we get this fixed for the upcoming release which should not
> take long anymore.
>
> Thanks for the hints.
>
> Kind regards,
> Jin

I see that this has been worked on in SVN. I'll test the new changes with the 
current package in Debian.

-- 
Regards,
Andres

Message #77 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: Sergey Jin' Bostandzhyan <jin@mediatomb.cc>, 465177@bugs.debian.org, Leonhard Wimmer <leo@mediatomb.cc>

Subject: Re: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support

Date: Tue, 19 Feb 2008 23:29:37 -0500

Hello,

I included the changes for the inotify runtime support found in the upstream 
SVN. The packaging can now be found under:
Vcs-git: git://git.debian.org/git/collab-maint/mediatomb.git
Vcs-Browser: http://git.debian.org/?p=collab-maint/mediatomb.git

Sven, would you mind reveiwing the package direct from the git repository? I 
could still upload a package to mentors.d.n if you want me to.

I switched to git since I thought it would be a good idea to allow a 
distributed control system for mediatomb.

The SVN repository is still up. If nobody has any objections, I'll remove the 
SVN repository.

-- 
Regards,
Andres

Message #82 received at 465177@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: 465177@bugs.debian.org, "Sergey Jin' Bostandzhyan" <jin@mediatomb.cc>, Leonhard Wimmer <leo@mediatomb.cc>

Subject: Re: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support

Date: Tue, 19 Feb 2008 23:38:04 -0500

[Message part 1 (text/plain, inline)]

Here's the specific patch as well.

-- 
Regards,
Andres

[inotify_fix.patch (text/x-diff, attachment)]

Message #91 received at 465177-close@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: 465177-close@bugs.debian.org

Subject: Bug#465177: fixed in mediatomb 0.10.0.dfsg1-2

Date: Wed, 20 Feb 2008 16:17:16 +0000

Source: mediatomb
Source-Version: 0.10.0.dfsg1-2

We believe that the bug you reported is fixed in the latest version of
mediatomb, which is due to be installed in the Debian FTP archive:

mediatomb-common_0.10.0.dfsg1-2_i386.deb
  to pool/main/m/mediatomb/mediatomb-common_0.10.0.dfsg1-2_i386.deb
mediatomb-daemon_0.10.0.dfsg1-2_all.deb
  to pool/main/m/mediatomb/mediatomb-daemon_0.10.0.dfsg1-2_all.deb
mediatomb_0.10.0.dfsg1-2.diff.gz
  to pool/main/m/mediatomb/mediatomb_0.10.0.dfsg1-2.diff.gz
mediatomb_0.10.0.dfsg1-2.dsc
  to pool/main/m/mediatomb/mediatomb_0.10.0.dfsg1-2.dsc
mediatomb_0.10.0.dfsg1-2_all.deb
  to pool/main/m/mediatomb/mediatomb_0.10.0.dfsg1-2_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 465177@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andres Mejia <mcitadel@gmail.com> (supplier of updated mediatomb package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 19 Feb 2008 22:27:26 -0500
Source: mediatomb
Binary: mediatomb-common mediatomb-daemon mediatomb
Architecture: source all i386
Version: 0.10.0.dfsg1-2
Distribution: unstable
Urgency: low
Maintainer: Andres Mejia <mcitadel@gmail.com>
Changed-By: Andres Mejia <mcitadel@gmail.com>
Description: 
 mediatomb  - UPnP MediaServer (main package)
 mediatomb-common - UPnP MediaServer (base package)
 mediatomb-daemon - UPnP MediaServer (daemon package)
Closes: 465177
Changes: 
 mediatomb (0.10.0.dfsg1-2) unstable; urgency=low
 .
   * Moved Debian packaging from svn to git.
     + Updated Vcs entries in debian/control.
   * Fixing inotify build problems. An inotify check will be supported for
     runtime. Closes: #465177
   * Removing .pc directory when unpatching.
   * Allowing options used in running configure to be overriden.
   * Writing external script to generate orig source tarball and have
     get-orig-source target in debian/rules call external script.
   * Update copyright to mention two files that are removed from upstream.
   * Add TODO about changing from using PNG Behavior fix from WebFX to using IE
     PNG Fix delivered by TwinHelix.
   * Adding TODO about ensuring that the WebUI works under any Mozilla based
     browser.
     + There's a known problem with the WebUI under Konqueror.
Files: 
 6faef1f790b8f3678853e4b667d60c0e 978 net optional mediatomb_0.10.0.dfsg1-2.dsc
 cd8c5c447b7d2db37444f25f6884507b 27567 net optional mediatomb_0.10.0.dfsg1-2.diff.gz
 7c2d927ef7cb2e6982688d67ba0ce172 17518 net optional mediatomb-daemon_0.10.0.dfsg1-2_all.deb
 4e8a3fd23a648bccea7302377f1c4f8e 16716 net optional mediatomb_0.10.0.dfsg1-2_all.deb
 74cd0aa28757930bc91aab6d1f6391c0 656714 net optional mediatomb-common_0.10.0.dfsg1-2_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHvFDhDcs5RBTUBgsRAjgNAKCxrVmm2qbCwDNMHbWsISKEjnPK2QCfcm8x
D5lt8ezruB7HUCpvqvhEb+I=
=4CBa
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.