Bug#769213: clam: FTBFS in jessie: Checking that libogg sample program links...no
Source: clam Version: 1.4.0-5.2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-2014-11-11 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): make[1]: Entering directory '/«PKGBUILDDIR»' mkdir -p /«PKGBUILDDIR»/debian/tmp/usr scons -c scons: Reading SConscript files ... Version: 1.4.0 Package version: 1.4.0 Configure phase... ### CLAM GLOBAL DEPENDENCIES CHECKING### Checking for pkg-config... yes COMPILING IN DEBUG MODE Checking for C header file pthread.h... yes Checking for pthread_join() in C library pthread... yes Checking that pthread sample program compiles...yes Checking that pthread sample program links...yes Checking that pthread sample program runs... yes # ### CLAM CORE DEPENDENCIES CHECKING ### # Checking for C++ header file xercesc/util/PlatformUtils.hpp... yes path of app: /«PKGBUILDDIR»/bin:/«PKGBUILDDIR»/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games Checking that xerces-c sample program compiles...yes Checking that xerces-c sample program links...yes Checking that xerces-c sample program runs... yes Checking for C header file ladspa.h... yes Checking that ladspa sample program compiles...yes Checking that ladspa sample program links...yes Checking that ladspa sample program runs... yes ### ### CLAM PROCESSING DEPENDENCIES CHECKING ### ### Checking for fftw3 pkg-config file... yes ### CLAM AUDIOIO DEPENDENCIES CHECKING ### Checking for C header file sndfile.h... yes Checking for sf_open_fd() in C library sndfile... yes Checking that libsndfile sample program compiles...yes Checking that libsndfile sample program links...yes Checking that libsndfile sample program runs... yes Checking for vorbisfile vorbisenc pkg-config file... yes Checking that libogg sample program compiles...yes Checking that libogg sample program links...no make[1]: *** [override_dh_auto_clean] Error 1 The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2014-11-11/clam_1.4.0-5.2_jessie.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#747568: rtkit-daemon.service:32] Unknown lvalue 'ControlGroup'
Am Mittwoch, den 12.11.2014, 01:56 -0300 schrieb Felipe Sateler: It appears that one needs to write to a file cgroup/cpu.rt_runtime_us (and all the way up the cgroup tree). However that requires a CONFIG_RT_GROUP_SCHED enabled kernel, which debian doesn't have. Is this option available in the Vanilla kernel or only in the realtime/preempt-patch set? Not sure how to move on... Wishlist bug against linux source package? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#747568: rtkit-daemon.service:32] Unknown lvalue 'ControlGroup'
On Wed, Nov 12, 2014 at 5:19 AM, Fabian Greffrath fab...@greffrath.com wrote: Am Mittwoch, den 12.11.2014, 01:56 -0300 schrieb Felipe Sateler: It appears that one needs to write to a file cgroup/cpu.rt_runtime_us (and all the way up the cgroup tree). However that requires a CONFIG_RT_GROUP_SCHED enabled kernel, which debian doesn't have. Is this option available in the Vanilla kernel or only in the realtime/preempt-patch set? Our kernel seems to have it, just disabled. Not sure how to move on... Wishlist bug against linux source package? Hmm, I wish I better understood all this. According to [1] that I just found, without CONFIG_RT_GROUP_SCHED we should not have the rtkit problem. However the rtkit-test program still reports failure. Adding a few printfs shows that the rtkit-test failure may be due to an unlimited RTTIME rlimit. Will investigate this further later. [1]https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284731 -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#769325: mediatomb: Mediatomb does not work with systemd
Package: mediatomb Version: 0.12.1-7 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, version 0.12.1-7 does not start when using systemd without a useable error message: Process: 2788 ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -e $MT_INTERFACE (code=exited, status=0/SUCCESS) Process: 2785 ExecStartPre=/sbin/ifconfig $MT_INTERFACE allmulti (code=exited, status=0/SUCCESS) Process: 2782 ExecStartPre=/sbin/route add -net 239.0.0.0 netmask 255.0.0.0 $MT_INTERFACE (code=exited, status=0/SUCCESS) Process: 2779 ExecStartPre=/bin/grep -q MT_USER /etc/default/mediatomb (code=exited, status=0/SUCCESS) Main PID: 2789 (code=exited, status=1/FAILURE) Even if it started, it wouldn't work, as it does not read the configuration file /etc/mediatomb/config.xml, which can be seen in /lib/systemd/system/mediatomb.service: ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -e $MT_INTERFACE Additionally, it does not seem to make sense to have /etc/default/mediatomb, as nearly all options are duplicates of options in /etc/mediatomb/config.xml. It is completely unclear to a normal user which value is used, if the values of both files differ. Mediatomb had working systemd support before these changes had been applied. These changes should thus probably be reverted. Alternatively, /etc/default/mediatomb should be deleted and /lib/systemd/system/mediatomb.service should be changed into [Unit] Description=UPnP MediaServer After=NetworkManager-wait-online.service network.target [Service] Type=forking PIDFile=/run/mediatomb.pid ExecStart=/usr/bin/mediatomb -d -c /etc/mediatomb/config.xml -P /run/mediatomb.pid [Install] WantedBy=multi-user.target Kind regards Patrick -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mediatomb depends on: ii chromium [www-browser] 38.0.2125.101-3 ii iceweasel [www-browser] 31.2.0esr-3 ii konqueror [www-browser] 4:4.14.2-1 ii mediatomb-daemon 0.12.1-7 ii rekonq [www-browser] 2.4.2-0ubuntu2 ii w3m [www-browser]0.5.3-19 mediatomb recommends no packages. mediatomb suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
