Bug#475279: Fwd: Bug#475279: mediatomb-common: Don't embedd prototype.js
Hi, On Wed, Feb 03, 2010 at 10:12:08PM +0100, Mehdi wrote: I'm not sure if Leo already told you this, but here's a bug asking for mediatomb not to use an embedded prototype.js. I've already tried using the prototype.js delivered in Debian (version 1.6.0.2). It's giving me problems with the web UI where I can't click over to Filesystem to browse my computer. The prototype.js embedded in mediatomb is version 1.5.1.1. I've just test mediatomb with debian-shipped prototype 1.6.1 but got no issues. The UI is working fine, and I'm able to click over Filesystem to browse my computer. Do you think that 1.6.1 fixed the problems encoutered while using 1.6.0? we have prototype 1.6.1 in SVN now and the web UI works fine with it. We are still embedding it, because prototype updates can break functionality, at least it did happen in the past a couple of times. You could patch it out in the .deb package so that the system wide prototype is used, however care should be takaen when it is being updated, i.e. it will need testing to be sure that a newer prototype version does not break the UI. Kind regards, Jin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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: FTBFS: configure: error: unable to configure inotify support
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: FTBFS: configure: error: unable to configure inotify support
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465177: FTBFS: configure: error: unable to configure inotify support
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
