Bug#765969: (no subject)
Hello, Le 2014-12-07 01:37, Francesco Muzio a écrit : The bug has been debated here https://trac.videolan.org/vlc/ticket/12622 And here seems to be found a possible patch, not yet applied https://trac.videolan.org/vlc/attachment/ticket/12622/vlc-2.2-greenline.patch That patch is incomplete and I suspect it will lead to crashes in some cases. I still consider this a bug in XVideo drivers, but there is a work-around in VLC now. Unfortunately, that means XVideo output will require memory copying. This is not avoidable without a fix for the XVideo drivers (which is unlikely to happen anytime soon). Probably this bug happen only with libav and not with ffmpeg So that sentence sounds a lot like trolling libav developers and the choice of libav by the Debian multimedia team. I don't know where you stand on libav vs ffmpeg, but the green line issue is solely between VLC and the XVideo drivers. VLC and at least some XVideo drivers disagree on how scaling cropped pictures should be achieved. -- Rémi Denis-Courmont ___ 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
Hola, Find inlined comments below. 2014-12-09 14:35 GMT+01:00 Patrick Häcker pa...@web.de: Even if it started, it wouldn't work, as it does not read the configuration file /etc/mediatomb/config.xml 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. /etc/default/mediatomb is a file for daemon configuration (network card to attach to, user/group to run under, location of config.xml, etc...)), while /etc/mediatomb/config.xml is for mediatomb configuration (see upstream documentation http://mediatomb.cc/pages/documentation#id2856319). Just for clarity for other readers, as I misunderstood this paragraph on first read: The documentation does not mention any separation of a daemon configuration from a mediatomb documentation. But it states, that all relevant network related options are optional in config.xml. Right. You are right and some optional values can be set at config.xml, but Debian mediatomb older releases have been configuring the daemon, even other distros, as Fedora, configure the daemon. It is not our fault the upstream provides two different ways to configure the daemon, via CLI or via config.xml. It's absolutely standard for a Unix daemon to be configurable via configuration file, environment variables and CLI options (with increasing priority in case an option is set multiple times). Nevertheless, I can't remember a daemon where the configuration file is not the reference for default daemon startup. /etc/default is normally only used with parameters, which are not part of the daemon's configuration file. Not sure I clearly understand you here. In older released mediatomb has always shipped /etc/default/mediatomb file. When adding systemd support, we updated variables to be more mediatomb specific, similar to what Fedora uses. http://anonscm.debian.org/cgit/pkg-multimedia/mediatomb.git/commit/?id=5acd74434fbe71aa638529720fc5f11d14a857db Some assumptions done by sysvinit script were moved into that same default file for systemd compatibility. Mediatomb had working systemd support before these changes had been applied. Sorry, there was no systemd unit file before, you might had been using the old init script which also sets up the daemon. Thanks for clarification. That's what I meant, but my statement has indeed been ambiguous. If you delete (or filter) systemd unit files it should fallback to use sysvinit script as you were doing previously. We picked to configure it via CLI with environment file, it has been that way for several releases now. Yes, but in the init-script, config.xml is used (line 80), while in the new systemd unit file, config.xml is not used. Or that's what I thought. According to the documentation, /etc/mediatomb/config.xml should not be used with the configuration used in /lib/systemd/system/mediatomb.service, but I just found out, that this is incorrect. The above config.xml file is read even if no -c option is given in the service file. This makes one problem less. Right, the config.xml file is still taken into account, if we look at unit file: http://anonscm.debian.org/cgit/pkg-multimedia/mediatomb.git/commit/?id=90f46857736afb6f49afe6c83dfc4d77fdb29613 ExecStart=/usr/bin/mediatomb -d -c /etc/mediatomb/config.xml -P /run/mediatomb.pid 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 where ## Location of the config file/database MT_HOME=/etc MT_CFGDIR=mediatomb that way it still finds and parses config.xml. Due to some other bug reports complaining that mediatomb exposed the whole rootfs structure via web interface, I decided to hardcode ethernet interface to loopback address and that needs to be changed by admins if they want it to work on their network. I do not think it's good idea to run the daemon as root, but instead use the mediatomb user/group. Yes, that was a dumb idea from me, thanks for paying attention. This was the minimal working configuration for me and should not be used in Jessie. Right, that's -u $MT_USER -g $MT_GROUP part Sorry, I disagree to do those changes at this stage in the release, we are frozen. Yes, we should aim for the least disruptive change which works for everyone. But please note, that the change in 0.12.1-7, uploaded directly before the freeze, was already a disruptive change, at least to me. My most sincere apologies, I am still concerned about your issue and trying to understand, was it disruptive because the $MT_ variable update? I cant think on anything else. Also you seem to drop network settings for UPnP to work properly on some systems, why is that? I dropped them as I didn't need them (for a minimal working example). What do they do? Are there
【每周 (12.15-19) 职位精选】互联网职位专辑 New Job Listings for Experienced Hires in China
Click here for the web version of this message 在3百万中外高校校友群中迅速招聘到有 实际工作经验的专业人士 China's First Recruiting Platform for Experienced Hires with Top University Alumni Networks 月薪 10万以上 Hadoop开发工程师 (数据挖掘工程师)北京市 岗位职责：1、使用缔元信数据计算平台整合、处理海量数据；2、参与缔元信DMP平台底层的开发；3、参与缔元信数据平台建设和研发工作。任职资格：1、熟悉hadoop、hive，对hadoop、hive源码有研究优先；2、精通JAVA，有并发应用或者分布式应用软件开发经验；3、熟练掌握Linux常规命令与... 职位链接：http://www.pinda360.com/52276337 查看详情 月薪 1-2万 百世经理人-储备网管经理上海市 岗位职责:1、1、负责本城市加盟商站点开发、甄选、考核、淘汰工作，对站点进行有效管理，完成业务指标。2、2、指导和监督本城市加盟商站点的运作及实施，对站点进行培训，定期对站点经营状况进行诊断并给出整改建议。3、3、协调本城市站点之间、分拨与站点间业务，及时解决实施过程中问题，提升客户满意度，确保收入...
Bug#773450: can't run laborejo-qt because of ImportError
Package: laborejo Version: 0.8~ds0-1 Severity: grave Justification: renders package unusable Running laborejo-qt fails, due to an ImportError: $ laborejo-qt Traceback (most recent call last): File /usr/bin/laborejo-qt, line 24, in module import laborejoqt File /usr/share/laborejo/laborejoqt/__init__.py, line 13, in module from PyQt4 import QtCore, QtGui ImportError: /usr/lib/python2.7/dist-packages/PyQt4/QtCore.so: undefined symbol: PyString_Type -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages laborejo depends on: ii fonts-freefont-ttf 20120503-4 ii fonts-oflb-euterpe 1.1-5 ii python3 3.4.2-2 ii python3-pyqt4 4.11.2+dfsg-1 Versions of packages laborejo recommends: pn jackd none ii lilypond 2.18.2-4 laborejo suggests no packages. -- no debconf information signature.asc Description: Digital signature ___ 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#773450: can't run laborejo-qt because of ImportError
severity 773450 important tags 773450 moreinfo thanks Hi, On Thu, Dec 18, 2014 at 2:03 PM, Félix Sipma felix+deb...@gueux.org wrote: ImportError: /usr/lib/python2.7/dist-packages/PyQt4/QtCore.so: undefined symbol: PyString_Type Sorry but I can't reproduce it here. Could you please show me the result fo the following command? head /usr/bin/laborejo-qt Would you please test running laborejo-qt as follows? python3 /usr/bin/laborejo-qt Thanks. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of opencollada_0.1.0~20140703.ddf8f47+dfsg1-1_amd64.changes
opencollada_0.1.0~20140703.ddf8f47+dfsg1-1_amd64.changes uploaded successfully to localhost along with the files: opencollada_0.1.0~20140703.ddf8f47+dfsg1-1.dsc opencollada_0.1.0~20140703.ddf8f47+dfsg1.orig.tar.xz opencollada_0.1.0~20140703.ddf8f47+dfsg1-1.debian.tar.xz opencollada-dev_0.1.0~20140703.ddf8f47+dfsg1-1_amd64.deb opencollada-tools_0.1.0~20140703.ddf8f47+dfsg1-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
opencollada_0.1.0~20140703.ddf8f47+dfsg1-1_amd64.changes is NEW
binary:opencollada-dev is NEW. binary:opencollada-tools is NEW. source:opencollada is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
synfigstudio 0.64.2-2 MIGRATED to testing
FYI: The status of the synfigstudio source package in Debian's testing distribution has changed. Previous version: 0.64.2-1 Current version: 0.64.2-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more 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
Bug#773450: can't run laborejo-qt because of ImportError
$ head /usr/bin/laborejo-qt
#! /usr/bin/python3
# -*- coding: utf-8 -*-
from time import sleep
from signal import SIGKILL
from os import getpid, kill
if __name__ == __main__:
import argparse, os
parser = argparse.ArgumentParser(description=Laborejo Qt)
parser.add_argument('infiles', help=One or more lbjs or lbj files to
load., nargs=*)
parser.add_argument(-n, --new, help=Start with an empty file
(additionally to loaded files), action=store_true)
$ python3 /usr/bin/laborejo-qt
Traceback (most recent call last):
File /usr/bin/laborejo-qt, line 24, in module
import laborejoqt
File /usr/share/laborejo/laborejoqt/__init__.py, line 13, in module
from PyQt4 import QtCore, QtGui
ImportError: /usr/lib/python2.7/dist-packages/PyQt4/QtCore.so: undefined
symbol: PyString_Type
But I just realized that I had the PYTHONPATH environment variable set (to
/home/user/lib/python2.7/site-packages). I unset it and now I can start
laborejo-qt.
I don't know if it's It's the first time I have a problem with this PYTHONPATH
but I guess it is probably a problem on my part. Anyway, the relation between
PYTHONPATH and the error message is not obvious...
On 18/12/2014 14:41, Alessio Treglia wrote:
severity 773450 important
tags 773450 moreinfo
thanks
Hi,
On Thu, Dec 18, 2014 at 2:03 PM, Félix Sipma felix+deb...@gueux.org wrote:
ImportError: /usr/lib/python2.7/dist-packages/PyQt4/QtCore.so: undefined
symbol: PyString_Type
Sorry but I can't reproduce it here.
Could you please show me the result fo the following command?
head /usr/bin/laborejo-qt
Would you please test running laborejo-qt as follows?
python3 /usr/bin/laborejo-qt
Thanks.
--
Félix
signature.asc
Description: Digital signature
___
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#765969: (no subject)
Le jeudi 18 décembre 2014, 22:30:19 Dirk Griesbach a écrit : Am Do, 18. Dez 2014 um 13:06:31 +0300 schrieb Rémi Denis-Courmont: I still consider this a bug in XVideo drivers, but there is a work-around in VLC now. Unfortunately, that means XVideo output will require memory copying. This is not avoidable without a fix for the XVideo drivers (which is unlikely to happen anytime soon). Stupid question of mine and regardless of where the bug actually originates: Why is this bug triggered with vlc 2.2.x but not with 2.1.x where apart from vlc's dependencies the rest of the system is not changed a bit? The bug does occur in VLC 2.1, just in fewer cases. -- Rémi Denis-Courmont http://www.remlab.net/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
