Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
Here's the specific patch as well.
--
Regards,
Andres
Patch that allows for inotify support to be checked at runtime.
===
--- mediatomb-0.10.0/src/config_manager.cc.bak 2008-02-19 13:44:03.0 -0500
+++ mediatomb-0.10.0/src/config_manager.cc 2008-02-19 13:53:04.0 -0500
@@ -44,6 +44,10 @@
#include "string_converter.h"
#include "metadata_handler.h"
+#ifdef HAVE_INOTIFY
+#include "mt_inotify.h"
+#endif
+
#if defined(HAVE_LANGINFO_H) && defined(HAVE_LOCALE_H)
#include
#include
@@ -839,19 +843,61 @@
_("from"), _("to")));
SET_DICT_OPTION(CFG_IMPORT_MAPPINGS_MIMETYPE_TO_UPNP_CLASS_LIST);
+temp = getOption(_("/import/autoscan/attribute::use-inotify"), _("auto"));
+if ((temp != "auto") && !validateYesNo(temp))
+throw _Exception(_("Error in config file: incorrect parameter for "
+ "\"
#include
#include
+#include
#include "mt_inotify.h"
@@ -73,10 +74,29 @@
close(inotify_fd);
}
+bool Inotify::supported()
+{
+int test_fd = inotify_init();
+if (test_fd < 0)
+return false;
+else
+{
+close(test_fd);
+return true;
+}
+}
int Inotify::addWatch(String path, int events)
{
-return inotify_add_watch(inotify_fd, path.c_str(), events);
+int wd = inotify_add_watch(inotify_fd, path.c_str(), events);
+if (wd < 0 && errno != ENOENT)
+{
+if (errno == ENOSPC)
+throw _Exception(_("The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource."));
+else
+throw _Exception(mt_strerror(errno));
+}
+return wd;
}
void Inotify::removeWatch(int wd)
--- mediatomb-0.10.0/src/content_manager.cc.bak 2008-02-19 13:56:13.0 -0500
+++ mediatomb-0.10.0/src/content_manager.cc 2008-02-19 14:15:55.0 -0500
@@ -87,6 +87,7 @@
ContentManager::ContentManager() : TimerSubscriberSingleton()
{
+int i;
cond = Ref(new Cond(mutex));
ignore_unknown_extensions = 0;
@@ -143,24 +144,31 @@
autoscan_timed = storage->getAutoscanList(TimedScanMode);
#ifdef HAVE_INOTIFY
-Ref config_inotify_list =
-cm->getAutoscanListOption(CFG_IMPORT_AUTOSCAN_INOTIFY_LIST);
-
-for (int i = 0; i < config_inotify_list->size(); i++)
+if (cm->getBoolOption(CFG_IMPORT_AUTOSCAN_USE_INOTIFY))
{
-Ref dir = config_inotify_list->get(i);
-if (dir != nil)
+Ref config_inotify_list =
+cm->getAutoscanListOption(CFG_IMPORT_AUTOSCAN_INOTIFY_LIST);
+
+for (i = 0; i < config_inotify_list->size(); i++)
{
-String path = dir->getLocation();
-if (check_path(path, true))
+Ref dir = config_inotify_list->get(i);
+if (dir != nil)
{
-dir->setObjectID(ensurePathExistence(path));
+String path = dir->getLocation();
+if (check_path(path, true))
+{
+dir->setObjectID(ensurePathExistence(path));
+}
}
}
-}
-storage->updateAutoscanPersistentList(InotifyScanMode, config_inotify_list);
-autoscan_inotify = storage->getAutoscanList(InotifyScanMode);
+storage->updateAutoscanPersistentList(InotifyScanMode,
+ config_inotify_list);
+autoscan_inotify = storage->getAutoscanList(InotifyScanMode);
+}
+else
+// make an empty list so we do not have to do extra checks on shutdown
+autoscan_inotify = Ref(new AutoscanList());
#endif
/* init filemagic */
#ifdef HAVE_MAGIC
@@ -233,15 +241,17 @@
autoscan_timed->notifyAll(AS_TIMER_SUBSCRIBER_SINGLETON(this));
#ifdef HAVE_INOTIFY
-inotify = Ref(new AutoscanInotify());
-/// \todo change this for 0.9.1 (we need a new autoscan architecture)
-for (int i = 0; i < autoscan_inotify->size(); i++)
+if (ConfigManager::getInstance()->getBoolOption(CFG_IMPORT_AUTOSCAN_USE_INOTIFY))
{
-Ref dir = autoscan_inotify->get(i);
-if (dir != nil)
-inotify->monitor(dir);
+inotify = Ref(new AutoscanInotify());
+/// \todo change this (we need a new autoscan architecture)
+for (int i = 0; i < autoscan_inotify->size(); i++)
+{
+Ref dir = autoscan_inotify->get(i);
+if (dir != nil)
+inotify->monitor(dir);
+}
}
-
#endif
}
@@ -1442,11 +1452,14 @@
Timer::getInstance()->removeTimerSubscriber(AS_TIMER_SUBSCRIBER_SINGLETON(this), rm_list->get(i)->getScanID(), true);
}
#ifdef HAVE_INOTIFY
-rm_list = autoscan_inotify->removeIfSubdir(path);
-for (i = 0; i < rm_list->size(); i++)
+if (ConfigManager::getInstance()->getBoolOptio
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
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
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
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
Bug#465177: Bug #465177: mediatomb: FTBFS: configure: error: unable to configure inotify support
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 [EMAIL PROTECTED] Thanks. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
