Bug#852135: debdelta: installation leaves gpg-agent process running
Il 07/02/2017 02:36, Paul Wise ha scritto: > I noticed this is fixed in experimental (but there was a typo in the > changelog), do you intend to get this fixed in stretch too? yes , see 854456 a. signature.asc Description: OpenPGP digital signature
Bug#834162: freevo: obsolete
Package: freevo Severity: grave Justification: renders package unusable Dear everybody, 'freevo' is in "dormant state" since Feb 2014 [1] ; there are some patches around to revive it [2] and a github branch that had some activity [3], but in truth there was no activity in some years. In the meantime Debian progresses; so now this freevo package cannot be installed and used in Debian Jessie; there are many problems, including: -) its init scripts are not compatible with systemd, and -) its Python code is not compatible with latest 'twisted' I gave it a look: fixing 'freevo' is more work than I can dedicate now. Moreover 'kodi' is now in Debian, so fixing 'freevo' probably does not make much sense. So I am opening this 'grave' bug; I am perfectly OK if someone wishes to fix 'freevo' ; but I would rather not see 'freevo' (as it is now) being part of the next major Debian release. Best regards, a. [1] http://freevo.org/ [2] https://sourceforge.net/p/freevo/mailman/freevo-devel/?viewmonth=201510 [3] https://github.com/kovalvalerii/freevo1.git signature.asc Description: Digital signature
Bug#760765: intel-microcode: breaks initrd for newer kernels
Package: intel-microcode Version: 2.20140624.1 Severity: critical Justification: breaks the whole system hi I have installed a small wheezy system, and then promptly upgraded it to jessie. This system has rootfs crypted with cryptsetup (altogh I am not sure this is relevant). I have two kernel currently in /boot, 3.14-2-amd64 and 3.2.0-4-amd64, I can boot the system with the latter, but not with the former. When I try to boot using 3.14-2-amd64 , the scripts in initrd complain that it cannot find the rootfs. I tried to investigate the problem, and found this startling fact. Usually initrd.img is a CPIO archive, compressed with GZIP. Instead, initrd.img-3.14-2-amd64 is a CPIO file but not compressed, and it seems to contain only this file $ cpio -t < /boot/initrd.img-3.14-2-amd64 kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/GenuineIntel.bin (even if initrd.img-3.14-2-amd64 is itself quite large, roughly 14MB). After some fiddling, I noted that if I delete the file /usr/share/initramfs-tools/hooks/intel_microcode and regenerate initrd.img-3.14-2-amd64 then it is fine. Unfortunately I cannot understand why it is broken. You may find the broken initrd in http://mennucc1.debian.net/tmp/initrd.img-3.14-2-amd64 I attach 3 files, that are the output of $ update-initramfs -v -u -k 3.14-2-amd64 3.14~no~microcode : the output when /usr/share/initramfs-tools/hooks/intel_microcode is deleted 3.14~with~microcode : the output when /usr/share/initramfs-tools/hooks/intel_microcode is present 3.14~with~microcode~xz : the output when I add 'set -zx' to /usr/share/initramfs-tools/hooks/intel_microcode a. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages intel-microcode depends on: ii iucode-tool 1.0.3-1 Versions of packages intel-microcode recommends: ii initramfs-tools 0.116 intel-microcode suggests no packages. -- no debconf information -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) 3.14~no~microcode.gz Description: application/gzip 3.14~with~microcode.gz Description: application/gzip 3.14~with~microcode~xz.gz Description: application/gzip signature.asc Description: Digital signature
Bug#737001: debdelta partial fixes
hi, I partially fixed the problem. New dpkg-deb has changed the way it compresses the data in deb packages, I have added some logic to detect it. a. signature.asc Description: OpenPGP digital signature
Bug#713525: dvbstreamer: diff for NMU version 2.1.0-2.4
On Fri, Jul 05, 2013 at 02:15:19PM +0200, gregor herrmann wrote: > Dear maintainer, > > I've prepared an NMU for dvbstreamer (versioned as 2.1.0-2.4) and > uploaded it to DELAYED/2. thanks a lot. a. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614498: svn 90
hi I tried guppy SVN 90. It works with python 2.7 in Debian wheezy. a. -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) signature.asc Description: Digital signature
Bug#643967: debdelta as well is affected
hi, 'debdelta-upgrade' uses 'prelink -u' in ssytems where prelink is used, to recover the original version of the file; so this bug is affecting it as well; please give it a look a. -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618786: dvbstreamer: FTBFS everywhere: configure: error: libev not found
let me just say that I am quite puzzled... I compiled it using pbuilder before uploading... a. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#607921: [Pkg-freevo-maint] Bug#607921: freevo: (unowned) files in /home (after purge (policy 6.8))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 607921 +wontfix thanks Dear Holger, here is the situation. When you install the package 'freevo' it sets up your PC to be a PVR. It sets some services to be automatically started at boot, such as the TV recorder and the main GUI. All services are ran as user 'freevo'. It sets up a space where video and music can be stored, and TV programs recorded, as user 'freevo'. Then users (*) can indeed record TV shows in the directory /home/freevo/recordings . So I do not find it reasonable to delete these directories when the 'freevo' package is purged. Now, I have one PC that is dedicated to be freevo PVR. The directories you list below contain ~470GB of audio/video I have patiently recorded in over 5 years from TV and my camera/videocamera and other sources. - From time to time, I do prepare new 'freevo' packages, and then I either try to upgrade my freevo box from old version, or purge the old version and then install the new. If 'freevo' would delete these directories when I purge it, then I would be very unhappy by now. If another user is using freevo as I do, and he would for any reason decide to purge 'freevo' and it would delete these directories then the user would come to my place with a very large and spiky clue-bat. Do you agree with the above? As per the choice of directories... does it make any major difference whether they are under /home or under /var or anywhere alse ? Also do not forget that these can be changed by the debconf interface . Anyway if you really do not like /home and have very good reasons to think they should by default stay elsewhere I can change the default. BTW, what 'freevo' is doing is similar to what mysql does: by default, mysql-server-5.0 will not delete the databases on package purge (unless the user uses debconf to set the key postrm_remove_databases to true) a. ps (*) currently TV recording need some manual config tweaking; but as TV are going digital, I hope we will make freevo autodetect the needed configurations, so that users will be able to record TV as soon as they install 'freevo' and plug in a TV digital receiver (there is already a lot of progress in this respect) Il 24/12/2010 12:46, Holger Levsen ha scritto: > Package: freevo > Version: 1.9.0-7 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts piuparts.d.o > > Hi, > > during a test with piuparts I noticed your package left unowned files on the > system after purge, which is a violation of policy 6.8: > > http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails > > From the attached log (scroll to the bottom...): > > 1m15.3s ERROR: FAIL: Package purging left files on system: > /home/freevo not owned > /home/freevo/audio not owned > /home/freevo/audio/.placeholder not owned > /home/freevo/cache not owned > /home/freevo/cache/.placeholder not owned > /home/freevo/image not owned > /home/freevo/image/.placeholder not owned > /home/freevo/log not owned > /home/freevo/log/.placeholdernot owned > /home/freevo/recordings not owned > /home/freevo/recordings/.placeholder not owned > /home/freevo/static not owned > /home/freevo/static/.placeholder not owned > /home/freevo/video not owned > /home/freevo/video/.placeholder not owned > > If your package had only left files in /var/log after purge, I would have > filed this as important. But as your package creates /home/freevo (WTF?!), > I'm filing this as it is. > > See http://www.pathname.com/fhs/pub/fhs-2.3.html#HOMEUSERHOMEDIRECTORIES > "/home is a fairly standard concept, but it is clearly a site-specific > filesystem. The setup will differ from host to host. Therefore, no program > should rely on this location." > > > cheers, > Holger > > > > ___ > Pkg-freevo-maint mailing list > pkg-freevo-ma...@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/pkg-freevo-maint -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0U/ygACgkQ9B/tjjP8QKRC6wCcCFu8ueZ0uqb1AbH6Ca+yStAy c28An0662w7BsGd26nQXy55Jyb+GpcAJ =Qjex -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567582: me too
hi, I was biten by this bug here are some info, hoping they help I have two hard disks /dev/sda /dev/sdb, each 500GB , each with 4 primary partitions (I created an identical layout in them two), the first partition /dev/sda1 is a standard ext3 containing /boot ; the last one is a RAID1 partition, so that /dev/sda4 /dev/sdb4 -> /dev/md0 and inside /dev/md0 I have LVM2, and inside LVM2 I have all other partitions, including / After I update grub-pc 1.98~20100115-1 -> 1.98-1 the bug appeared debconf info # debconf-show grub-pc grub2/kfreebsd_cmdline: grub-pc/linux_cmdline: fillme * grub2/linux_cmdline: * grub-pc/chainload_from_menu.lst: false grub-pc/kopt_extracted: true * grub-pc/install_devices: /dev/sda grub-pc/postrm_purge_boot_grub: false grub2/kfreebsd_cmdline_default: quiet * grub2/linux_cmdline_default: quiet Let me also report how I solved the problem, so as to help people who may be Googling around I booted with an Ubuntu-live CD 9.10, I opened a terminal, I became root using $ sudo bash -l then $ apt-get install mdadm then $ mdadm --assemble --scan at this point Ubuntu finds out about the new device and automatically scans it using LVM (all new devices LVM magically appear in the "My Computer" window) then I mounted my root and boot in right order under /mnt $ mount /dev/myraidlvm/root /mnt/ $ mount /dev/sda1 /mnt/boot/ then $ grub-install --root-directory=/mnt /dev/sda then shutdown, and now it is booting again. a. -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573176: linux-headers-2.6.33-2-686: cannot be installed
On Tue, Mar 09, 2010 at 07:13:08PM +, Ben Hutchings wrote: > On Tue, Mar 09, 2010 at 04:29:55PM +0100, A Mennucc wrote: > > Package: linux-headers-2.6.33-2-686 > > Version: 2.6.33-1~experimental.2 > > Severity: grave > > Justification: renders package unusable > > Please don't make such a fuss about experimental. I do not intend to make a fuss. When I invoked reportbug, I carefully looked into the description of severities, and the description for "grave" is grave : makes the package in question unusable by most or all users and moreover reportbug clarifies that the justification to choose is renders package unusable : renders the package unusable, [...] ; or renders package uninstallable [...] and this is exactly the case. If you do not like the severity descriptions, then you should complain to people who are in charge of them. > > this package depends on linux-kbuild-2.6.33 that though does not exist > > > > (this is problematic for me, since my video card is not supported > > by nv, so I have to compile the nvidia module) > > Why aren't you using nouveau? FYI, because my chipset is 9400M, and nouveau is not supporting it yet. 9400M is the chipset used in Apple MacBooks; so this is a high priority bug at http://bugs.freedesktop.org/show_bug.cgi?id=18638 but it is also 2 years old and unfixed. And, BTW, the vesa X driver presents a blurred screen that really sucks, texts are hardly readable. a. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573176: linux-headers-2.6.33-2-686: cannot be installed
Package: linux-headers-2.6.33-2-686 Version: 2.6.33-1~experimental.2 Severity: grave Justification: renders package unusable hi, this package depends on linux-kbuild-2.6.33 that though does not exist (this is problematic for me, since my video card is not supported by nv, so I have to compile the nvidia module) a. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (450, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567527: nvidia-libvdpau* cannot be installed
Package: nvidia-libvdpau1 Version: 190.53-1 Severity: grave Justification: renders package unusable hi the package nvidia-libvdpau-dev depends on nvidia-libvdpau1 (>= 190.53) the package nvidia-libvdpau1 depends on nvidia-libvdpau1-driver (>= 190.53) but conflicts nvidia-libvdpau now, AFAICT, the package nvidia-libvdpau1-driver is to be substituted by nvidia-vdpau-driver but the package nvidia-vdpau-driver provides vdpau-driver instead of nvidia-vdpau-driver a. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nvidia-libvdpau-dev depends on: pn nvidia-libvdpau1 (no description available) nvidia-libvdpau-dev recommends no packages. nvidia-libvdpau-dev suggests no packages. -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) signature.asc Description: Digital signature
Bug#566902: [Pkg-freevo-maint] Bug#566902: src:kaa-base: Hardcodes (wrong) libc versions
Cyril Brulebois ha scritto: Package: src:kaa-base Version: 0.6.0-2 Severity: serious Justification: Breaks on several release archs (just for the record , according to http://release.debian.org/squeeze/arch_qualify.html kfreebsd-* may be part of the next release, but is at risk, while hurd is not even considered. So much for "several release archs".) I /think/ the 002_ia64_libc.patch patch is a bit braindead. It doesn't even do the job given there are more than just libc6 and libc6.1. As of this writing, we have: libc6 libc6.1 on alpha & ia64 libc0.3 on hurd-i386 libc0.1 on kfreebsd-*. Please unfuck this. Feel free to send a better patch anytime. a. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563590: Fails to upgrade/install
Package: console-tools Version: 1:0.2.3dbs-67 Severity: normal The problem is in the line readlink /proc/self/fd/0 | grep -q -e /dev/vc -e '/dev/tty[^p]' -e /dev/console if 'grep' does not match, it will fail, and since 'set -e', then the script will fail. This patch fixes the problem. --- /etc/init.d/console-screen.sh~ 2009-12-19 20:27:27.0 +0100 +++ /etc/init.d/console-screen.sh 2010-01-09 12:41:53.0 +0100 @@ -82,8 +82,7 @@ CONSOLE_TYPE=`fgconsole 2>/dev/null` || return 0 if [ ! $CONSOLE_TYPE = "serial" ] ; then - readlink /proc/self/fd/0 | grep -q -e /dev/vc -e '/dev/tty[^p]' -e /dev/console - if [ $? -eq 0 ] ; then + if readlink /proc/self/fd/0 | grep -q -e /dev/vc -e '/dev/tty[^p]' -e /dev/console ; then VT="yes" reset_vga_palette fi a. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages console-tools depends on: ii debconf [debconf-2.0] 1.5.28Debian configuration management sy ii libc6 2.10.2-4 Embedded GNU C Library: Shared lib ii libconsole 1:0.2.3dbs-67 Shared libraries for Linux console ii lsb-base 3.2-23Linux Standard Base 3.2 init scrip Versions of packages console-tools recommends: ii console-common0.7.85 basic infrastructure for text cons ii console-data 2:1.10-2 keymaps, fonts, charset maps, fall Versions of packages console-tools suggests: pn kbd-compat (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563325: spamassassin: since 1 Jan 2010, FH_DATE_PAST_20XX is triggering on all emails
On Fri, Jan 01, 2010 at 06:59:44PM -0500, Noah Meyerhans wrote: > This was fixed for both unstable, volatile, and stable (via > stable-proposed-updates) earlier today. thanks a lot! a. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563325: spamassassin: since 1 Jan 2010, FH_DATE_PAST_20XX is triggering on all emails
Package: spamassassin Version: 3.2.5-2+lenny1 Severity: critical Justification: causes serious data loss hi since 1st Jan, the rule FH_DATE_PAST_20XX is triggering on all emails, adding 3.2 to the spam score. Following the example in /usr/share/doc/spamassassin/examples/procmailrc.example I had setup procmail to trow into /dev/null all email that was exceeding a certain level of spamminess. Since midnight today, the above rule has so deleted a lot of legitimate email. This problem has been reported upstream https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 a. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-openvz-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages spamassassin depends on: ii libdigest-sha1-perl 2.11-2+b1 NIST SHA-1 message digest algorith ii libhtml-parser-perl 3.56-1+lenny1 A collection of modules that parse ii libnet-dns-perl 0.63-2 Perform DNS queries from a Perl sc ii libsocket6-perl 0.20-1 Perl extensions for IPv6 ii libsys-hostname-long-per 1.4-2 Figure out the long (fully-qualifi ii libwww-perl 5.813-1 WWW client/server library for Perl ii perl 5.10.0-19lenny2 Larry Wall's Practical Extraction ii perl-modules [libarchive 5.10.0-19lenny2 Core Perl modules Versions of packages spamassassin recommends: ii gcc 4:4.3.2-2 The GNU C compiler ii gnupg 1.4.9-3+lenny1 GNU privacy guard - a free PGP rep ii libc6-dev 2.7-18 GNU C Library: Development Librari ii libio-socket-inet6-perl 2.54-1 Object interface for AF_INET6 doma ii libmail-spf-perl 2.005-1Perl implementation of Sender Poli ii libsys-syslog-perl0.26-1 Perl interface to the UNIX syslog( ii make 3.81-5 The GNU version of the "make" util ii re2c 0.13.5-1 tool for generating fast C-based r ii spamc 3.2.5-2+lenny1 Client for SpamAssassin spam filte Versions of packages spamassassin suggests: ii libcompress-zlib-perl 2.012-1 Perl module for creation and manip ii libdbi-perl1.605-1 Perl5 database interface by Tim Bu ii libio-socket-ssl-perl 1.16-1+lenny1 Perl module implementing object or pn libmail-dkim-perl (no description available) pn libnet-ident-perl (no description available) pn pyzor (no description available) pn razor (no description available) -- no debconf information -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561563: backport: Bug#561563:
hi, I compiled vzctl 3.0.23-8 (using pbuilder, for lenny amd64) and installed, it works fine; if anybody is bitten by this bug, the backported package is in http://tonelli.sns.it/pub/mennucc1/vz (and is signed with my key) a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#561563: vzctl: Unable to set capability: Operation not permitted
Package: vzctl Version: 3.0.22-14 Severity: grave Justification: renders package unusable hi, it seems that bug 513310 is back with kernel 2.6.26-2 on amd64 I cannot start a VZ ; see attachment, where I create one from scratch and it fails to start; I also attach the strace of 'vzctl start' a. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-openvz-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vzctl depends on: ii iproute 20080725-2 networking and traffic control too ii libc6 2.7-18 GNU C Library: Shared libraries ii vzquota 3.0.11-1 server virtualization solution - q Versions of packages vzctl recommends: ii rsync 3.0.3-2fast remote file copy program (lik Versions of packages vzctl suggests: pn linux-patch-openvz (no description available) -- no debconf information -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 Script started on ven 18 dic 2009 09:56:50 CET r...@tonelli:~# debootstrap --arch amd64 sid /var/lib/vz/private/110 http://ftp .it.debian.org/debian I: Retrieving Release I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional required dependencies: dash insserv libdb4.7 I: Found additional base dependencies: libapr1 libaprutil1 libboost-iostreams1.40.0 libdb4.8 libexpat1 liblog4cxx10 libsqlite3-0 libudev0 I: Checking component main on http://ftp.it.debian.org/debian... I: Retrieving libacl1 I: Validating libacl1 I: Retrieving adduser I: Validating adduser I: Retrieving libaprutil1 I: Validating libaprutil1 I: Retrieving libapr1 I: Validating libapr1 I: Retrieving apt-utils I: Validating apt-utils I: Retrieving apt I: Validating apt I: Retrieving aptitude I: Validating aptitude I: Retrieving libattr1 I: Validating libattr1 I: Retrieving base-files I: Validating base-files I: Retrieving base-passwd I: Validating base-passwd I: Retrieving bash I: Validating bash I: Retrieving libboost-iostreams1.40.0 I: Validating libboost-iostreams1.40.0 I: Retrieving bsdmainutils I: Validating bsdmainutils I: Retrieving libbz2-1.0 I: Validating libbz2-1.0 I: Retrieving coreutils I: Validating coreutils I: Retrieving cpio I: Validating cpio I: Retrieving cron I: Validating cron I: Retrieving libcwidget3 I: Validating libcwidget3 I: Retrieving dash I: Validating dash I: Retrieving libdb4.8 I: Validating libdb4.8 I: Retrieving libdb4.7 I: Validating libdb4.7 I: Retrieving debconf-i18n I: Validating debconf-i18n I: Retrieving debconf I: Validating debconf I: Retrieving debian-archive-keyring I: Validating debian-archive-keyring I: Retrieving debianutils I: Validating debianutils I: Retrieving dhcp3-client I: Validating dhcp3-client I: Retrieving dhcp3-common I: Validating dhcp3-common I: Retrieving diffutils I: Validating diffutils I: Retrieving dmidecode I: Validating dmidecode I: Retrieving dpkg I: Validating dpkg I: Retrieving e2fslibs I: Validating e2fslibs I: Retrieving e2fsprogs I: Validating e2fsprogs I: Retrieving libcomerr2 I: Validating libcomerr2 I: Retrieving libss2 I: Validating libss2 I: Retrieving ed I: Validating ed I: Retrieving libc-bin I: Validating libc-bin I: Retrieving libc6 I: Validating libc6 I: Retrieving libexpat1 I: Validating libexpat1 I: Retrieving findutils I: Validating findutils I: Retrieving gcc-4.3-base I: Validating gcc-4.3-base I: Retrieving gcc-4.4-base I: Validating gcc-4.4-base I: Retrieving libgcc1 I: Validating libgcc1 I: Retrieving libstdc++6 I: Validating libstdc++6 I: Retrieving libgdbm3 I: Validating libgdbm3 I: Retrieving gnupg I: Validating gnupg I: Retrieving gpgv I: Validating gpgv I: Retrieving grep I: Validating grep I: Retrieving groff-base I: Validating groff-base I: Retrieving gzip I: Validating gzip I: Retrieving hostname I: Validating hostname I: Retrieving ifupdown I: Validating ifupdown I: Retrieving insserv I: Validating insserv I: Retrieving iproute I: Validating iproute I: Retrieving iptables I: Validating iptables I: Retrieving iputils-ping I: Validating iputils-ping I: Retrieving liblog4cxx10 I: Validating liblog4cxx10 I: Retrieving logrotate I: Validating logrotate I: Retrieving lsb-base I: Validating lsb-base I: Retrieving libdevmapper1.02.1 I: Validating libdevmapper1.02.1 I: Retrieving lzma I: Validating lzma I: Retrieving libept0 I: Validating libept0 I: Retrieving liblocale-gettext-perl I: Validating liblocale-gettext-perl I: Retrieving libselinux1 I: Validating libselinux1 I: Retrieving libsepol1 I:
Bug#560013: nvidia-glx-legacy-96xx: conflicts with xserver
Package: nvidia-glx-legacy-96xx Version: 96.43.13+1-1 Severity: grave Justification: renders package unusable hi, this package provides xserver-xorg-video-2 but xserver-xorg-core conflicts with xserver-xorg-video-2 the net result is as follows: v # apt-get install nvidia-glx-legacy-96xx Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-kbd xserver-xorg-input-mouse xserver-xorg-input-synaptics xserver-xorg-input-wacom xserver-xorg-video-nv The following NEW packages will be installed: nvidia-glx-legacy-96xx ^^ I tried to force install, just to see if it may work nonetheless, but it does not : when loading the 'nvidia kernel module' the kernel log reports v [55703.629627] Xorg:15448 conflicting memory types e800-e888 uncached-minus<->write-combining [55703.629639] reserve_memtype failed 0xe800-0xe888, track uncached-minus, req write-combining [55703.630180] Xorg:15448 conflicting memory types e800-e888 uncached-minus<->write-combining [55703.630186] reserve_memtype failed 0xe800-0xe888, track uncached-minus, req write-combining ^^^ When starting X, it crashes saying Backtrace: 0: X(xorg_backtrace+0x3b) [0x81314cb] 1: X(xf86SigHandler+0x51) [0x80c1df1] 2: [0xb7fdc400] So this package is unusable in sid/squeeze a. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545228: reason, workaround
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, the problem is that module-assistant sets KSRC=/lib/modules/2.6.30-1-686/build and then debian/rules calls the nvidia makefile nv/Makefile.kbuild by $(MAKE) SYSSRC=$(KSRC) but instead if you call the upstream makefile directly, it internally uses /lib/modules/2.6.30-1-686/source in some variables; and currently those are different, # ls -l /lib/modules/2.6.30-1-686 lrwxrwxrwx 1 root root 35 30 ago 19:39 build -> /usr/src/linux-headers-2.6.30-1-686 lrwxrwxrwx 1 root root 38 25 ago 19:13 source -> /usr/src/linux-headers-2.6.30-1-common The workaround is # cd /usr/src # tar xzf nvidia-kernel-legacy-96xx-source.tar.gz then edit debian/rules and delete all occurrences of SYSSRC=... eventually # m-a -t -O b-i nvidia-kernel-legacy-96xx this way, the NVidia nv/Makefile.kbuild will autodetect the kernel that is currently installed, and set the variables as it likes, and it will compile. (This also means that "m-a -l another-kernel" will not work) a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrIfoMACgkQ9B/tjjP8QKRE0ACfTPDYnsPW+uLmnm1rMFAOKenJ 1yUAoIeC7OJvByeUhznzqEBh7cj/Ax02 =dOaG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545228: log
This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.6.3.901 (1.6.4 RC 1) Release Date: 2009-8-25 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.30.6-dsa-ia32 i686 Debian Current Operating System: Linux frivolo 2.6.30-1-686 #1 SMP Sat Aug 15 19:11:58 UTC 2009 i686 Build Date: 14 September 2009 05:23:17PM xorg-server 2:1.6.3.901-1 (bui...@murphy.debian.org) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sun Oct 4 10:34:12 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) No Layout section. Using the first Screen section. (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Configured Monitor" (==) No device specified for screen "Default Screen". Using the first device section listed. (**) | |-->Device "Configured Video Device" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/Type1" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. Entry deleted from font path. (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/75dpi, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (II) Loader magic: 0xa40 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on linux (--) using VT number 7 (--) PCI:*(0:1:0:0) 10de:0171:: nVidia Corporation NV17 [GeForce4 MX 440] rev 163, Mem @ 0xdf00/16777216, 0xe800/134217728, 0xe780/524288, BIOS @ 0x/131072 (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) System resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x (0x1) IX[B] (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension (II) NVIDIA GLX Module 96.43.13 Thu Jun 25 18:56:56 PDT 2009 (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/lib/xo
Bug#545228: log
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I attach the X log , just in case I also reported this bug into http://www.nvnews.net/vbulletin/showthread.php?t=136680 a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrIZ5AACgkQ9B/tjjP8QKQmSQCeK2teSdvPNUgIxgVrXjTXoLgM tVkAoItBY3L6TdyF/2JapFg+r9Dp7q5U =LQEL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545228: Acknowledgement (nvidia-kernel-legacy-96xx-source: does not build with 2.6.30-1-686 )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, the upstream code (that is, ftp://download.nvidia.com/XFree86/Linux-x86/96.43.13/ ) compiles fine the difference is AFAICT that the upstream code also runs a file 'conftest.sh' that sets some macros ; while debian/rules doesn't the bad news is that the resulting code crashes :-( a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrIYQoACgkQ9B/tjjP8QKQ6qgCfRbCZqVDWiPl4QvCTWO7PRPsy AkcAn3kW9I/gK7ODpdidk0mwiSYcRfsg =BfFK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545982: closed by "Stefan Lippers-Hollmann" (Re: [Pkg-lirc-maint] Bug#545982: lirc-modules-source: does not compile with 2.6.30-1-686)
On Thu, Sep 10, 2009 at 02:06:11PM +, Debian Bug Tracking System wrote: > lirc-modules-source >= 0.8.3-4 (uploaded on the 7th of August 2009) > compiles and works well with kernel 2.6.26 - 2.6.31. It's available in sid > for all architectures != mipsel, which keeps it out of testing for now[1]. my fault, at first I thought that that box was on Debian/unstable, after a while I realized instead it is tracking 'squeeze' BTW in the meantime I tried to compile upstream '0.8.5' and it did work OK (with linux 2.6.30) a. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545982: lirc-modules-source: does not compile with 2.6.30-1-686
On Thu, Sep 10, 2009 at 02:41:48PM +0200, A Mennucc wrote: > the lirc module does not compile on the kernel 2.6.30-1-686 , > in a recent Debian/unstable install let me correct, that box is Debian/testing a. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545982: Acknowledgement (lirc-modules-source: does not compile with 2.6.30-1-686)
hi, I was looking into svn://svn.debian.org/svn/pkg-lirc/lirc/trunk/ I am puzzled I see that, you are not upgrading to the latest upstream (currently 0.8.5 , since May 2009 - but before that there was 0.8.4a in Oct 2008) ; but rather, whenever a new kernel has entered in Debian, you have backported many patches into 0.8.3 to try to support it. Why? I am asking, because IMHO opinion upgrading to 0.8.5 would be the simplest way of solving these issues; also there is a bug 517507 asking for 0.8.4a , to support some more hw. But since you went to great effort, maybe there are issues. If otherwise you just need some manpower, feel free to ask. a. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545982: lirc-modules-source: does not compile with 2.6.30-1-686
Package: lirc-modules-source
Version: 0.8.3-3
Severity: grave
Justification: renders package unusable
hi,
the lirc module does not compile on the kernel 2.6.30-1-686 ,
in a recent Debian/unstable install
a.
for templ in ; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/2.6.30-1-686/g'` ; \
done
for templ in `ls debian/*.modules.in` ; do \
test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in}
${templ%.modules.in}.backup 2>/dev/null || true; \
sed -e 's/##KVERS##/2.6.30-1-686/g ;s/#KVERS#/2.6.30-1-686/g ;
s/_KVERS_/2.6.30-1-686/g ; s/##KDREV##/2.6.30-6/g ; s/#KDREV#/2.6.30-6/g ;
s/_KDREV_/2.6.30-6/g ' < $templ > ${templ%.modules.in}; \
done
dh_clean
/usr/bin/make clean
make[1]: Entering directory `/usr/src/modules/lirc-modules'
rm -rf *.ko *.mod.* *.o .*.o.d .*.cmd .tmp_versions Module.symvers *.order
make[1]: Leaving directory `/usr/src/modules/lirc-modules'
/usr/bin/make -f debian/rules kdist_clean kdist_config binary-modules
make[1]: Entering directory `/usr/src/modules/lirc-modules'
for templ in ; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/2.6.30-1-686/g'` ; \
done
for templ in `ls debian/*.modules.in` ; do \
test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in}
${templ%.modules.in}.backup 2>/dev/null || true; \
sed -e 's/##KVERS##/2.6.30-1-686/g ;s/#KVERS#/2.6.30-1-686/g ;
s/_KVERS_/2.6.30-1-686/g ; s/##KDREV##/2.6.30-6/g ; s/#KDREV#/2.6.30-6/g ;
s/_KDREV_/2.6.30-6/g ' < $templ > ${templ%.modules.in}; \
done
dh_clean
/usr/bin/make clean
make[2]: Entering directory `/usr/src/modules/lirc-modules'
rm -rf *.ko *.mod.* *.o .*.o.d .*.cmd .tmp_versions Module.symvers *.order
make[2]: Leaving directory `/usr/src/modules/lirc-modules'
make[1]: Nothing to be done for `kdist_config'.
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs lib/modules/2.6.30-1-686/misc
# build module
/usr/bin/make -C /usr/src/modules/lirc-modules
KSRC=/lib/modules/2.6.30-1-686/build
make[2]: Entering directory `/usr/src/modules/lirc-modules'
/usr/bin/make -C /lib/modules/2.6.30-1-686/build
SUBDIRS=/usr/src/modules/lirc-modules modules
make[3]: Entering directory `/usr/src/linux-headers-2.6.30-1-686'
CC [M] /usr/src/modules/lirc-modules/lirc_dev.o
/usr/src/modules/lirc-modules/lirc_dev.c:52:27: error: asm/semaphore.h: No such
file or directory
/usr/src/modules/lirc-modules/lirc_dev.c: In function ‘lirc_register_plugin’:
/usr/src/modules/lirc-modules/lirc_dev.c:406: warning: passing argument 5 of
‘device_create’ makes pointer from integer without a cast
make[6]: *** [/usr/src/modules/lirc-modules/lirc_dev.o] Error 1
make[5]: *** [_module_/usr/src/modules/lirc-modules] Error 2
make[4]: *** [sub-make] Error 2
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-2.6.30-1-686'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/modules/lirc-modules'
make[1]: *** [binary-modules] Error 2
make[1]: Leaving directory `/usr/src/modules/lirc-modules'
make: *** [kdist_build] Error 2
Bug#545228: nvidia-kernel-legacy-96xx-source: does not build with 2.6.30-1-686
Package: nvidia-kernel-legacy-96xx-source Version: 96.43.13-0.1 Severity: grave Justification: renders package unusable hi, the source does not build with kernel 2.6.30-1-686 I attach a typescript of the command # m-a -t b-i nvidia-kernel-legacy-96xx the most relevant errors are: /usr/src/modules/nvidia-kernel-legacy-96xx/nv/nv-linux.h:534:2: error: #error "N /usr/src/modules/nvidia-kernel-legacy-96xx/nv/nv-linux.h:607:2: error: #error "N /usr/src/modules/nvidia-kernel-legacy-96xx/nv/nv-linux.h:627:2: error: #error "N I a. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) Script started on sab 05 set 2009 23:02:18 CEST Extracting the package tarball, /usr/src/nvidia-kernel-legacy-96xx-source.tar.gz, please wait... /usr/bin/make -f debian/rules clean make[1]: Entering directory `/usr/src/modules/nvidia-kernel-legacy-96xx' # select which makefile to use. rm -f /usr/src/modules/nvidia-kernel-legacy-96xx/nv/Makefile || true if [ 6 = 6 ]; then \ cd /usr/src/modules/nvidia-kernel-legacy-96xx/nv ; \ ln -s Makefile.kbuild Makefile ; \ cd .. ; \ if [ 0 = 1 ] ; then \ dpatch apply 04_minion ; \ fi ; \ if [ 0 = 1 ]; then \ dpatch apply 01_sysfs ; \ dpatch status 01_sysfs >patch-stamp ; \ dpatch apply 02_pcialias ; \ dpatch status 02_pcialias >>patch-stamp ; \ fi ; \ fi if [ 6 = 4 ]; then \ cd /usr/src/modules/nvidia-kernel-legacy-96xx/nv ; \ ln -s Makefile.nvidia Makefile ; \ cd .. ; \ fi if [ -e patch-stamp ]; then \ dpatch deapply-all ; \ rm -rf patch-stamp debian/patched ; \ fi if [ -f /usr/src/modules/nvidia-kernel-legacy-96xx/debian/control.template ]; then \ cp /usr/src/modules/nvidia-kernel-legacy-96xx/debian/control.template /usr/src/modules/nvidia-kernel-legacy-96xx/debian/control; \ fi dh_testroot rm -f build-stamp configure-stamp /usr/bin/make clean SYSSRC=/lib/modules/2.6.30-1-686/build -C /usr/src/modules/nvidia-kernel-legacy-96xx/nv -f Makefile make[2]: Entering directory `/usr/src/modules/nvidia-kernel-legacy-96xx/nv' make[2]: Leaving directory `/usr/src/modules/nvidia-kernel-legacy-96xx/nv' rm -f /usr/src/modules/nvidia-kernel-legacy-96xx/nv/Makefile || true; rm /usr/src/modules/nvidia-kernel-legacy-96xx/nv/gcc-check rm /usr/src/modules/nvidia-kernel-legacy-96xx/nv/cc-sanity-check dh_clean rm /usr/src/modules/nvidia-kernel-legacy-96xx/debian/control rm: rm /usr/src/modules/nvidia-kernel-legacy-96xx/debian/dirs impossibile rimuovere `/usr/src/modules/nvidia-kernel-legacy-96xx/debian/dirs': No such file or directory make[1]: [clean] Error 1 (ignored) rm: rm /usr/src/modules/nvidia-kernel-legacy-96xx/debian/override impossibile rimuovere `/usr/src/modules/nvidia-kernel-legacy-96xx/debian/override': No such file or directory make[1]: [clean] Error 1 (ignored) make[1]: Leaving directory `/usr/src/modules/nvidia-kernel-legacy-96xx' echo "ROOT_CMD = " ROOT_CMD = /usr/bin/make -f debian/rules binary_modules make[1]: Entering directory `/usr/src/modules/nvidia-kernel-legacy-96xx' # select which makefile to use. rm -f /usr/src/modules/nvidia-kernel-legacy-96xx/nv/Makefile || true if [ 6 = 6 ]; then \ cd /usr/src/modules/nvidia-kernel-legacy-96xx/nv ; \ ln -s Makefile.kbuild Makefile ; \ cd .. ; \ if [ 0 = 1 ] ; then \ dpatch apply 04_minion ; \ fi ; \ if [ 0 = 1 ]; then \ dpatch apply 01_sysfs ; \ dpatch status 01_sysfs >patch-stamp ; \ dpatch apply 02_pcialias ; \ dpatch status 02_pcialias >>patch-stamp ; \ fi ; \ fi if [ 6 = 4 ]; then \ cd /usr/src/modules/nvidia-kernel-legacy-96xx/nv ; \ ln -s Makefile.nvidia Makefile ; \ cd .. ; \ fi if ! gcc-4.3 -v 2> /dev/null ; then \ echo "Compiler gcc-4.3 does not exist on the system" ; \ exit 1; \ fi touch configure-stamp if [ -f /usr/src/modules/nvidia-kernel-legacy-96xx/debian/control.template ]; then \ cp /usr/src/modules/nvidia-kernel-legacy-96xx/debian/control.template /usr/src/modules/nvidia-kernel-legacy-96xx/debian/control; \ fi dh_testdir dh_testroot PATCHLEVEL = 6 Kernel compiler version : 4.3.4 Detected compiler version : 4.3.4 Using compiler gcc-4.3 version 4.3.4 touch /usr/src/modules/nvidia-kernel-legacy-96xx/nv/gcc-check touch /usr/src/mo
Bug#525414: closed by Daniel Baumann (reply to dan...@debian.org) (Re: nvidia-graphics-drivers: damages some Fujitsu notebook)
hi Daniel the original advisory says > Using earlier NVIDIA Linux drivers on the Celsius H270 notebook will > result in a corrupt EDID and > anyone repackaging a 180.xx NVIDIA Linux graphics driver upgrade to > 180.51 moreover what LWN says is > It fixes a problem with the 180.29 release (packaged by RPMFusion, at > least) it does not say that 180.29 is the only release being affected. So I would strongly suggest upgrading the driver (and reopening the bug so that people withthat notebook are advised not to use the older one) a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525414: nvidia-graphics-drivers: damages some Fujitsu notebook
Package: nvidia-graphics-drivers Version: 180.44-2 Severity: critical Justification: breaks the whole system hi, this advisory has appeared into http://www.nvnews.net/vbulletin/showthread.php?t=131849 > Please note that the NVIDIA 180.51 Linux graphics driver > fixed an interaction problem that resulted in corruption of the internal > flatpanel's EDID on the Fujitsu Technology Solutions Celsius H270 notebook. > > Using earlier NVIDIA Linux drivers on the Celsius H270 notebook will result > in a corrupt EDID, which will persist across reboots. If you encounter > this problem on a Celsius H270 notebook, please contact Fujitsu Technology > Solutions technical support to correct the EDID. > > NVIDIA and Fujitsu recommend that all Linux Celsius H270 notebook > users use NVIDIA Linux graphics drivers 180.51 or later, and > that anyone repackaging a 180.xx NVIDIA Linux graphics driver upgrade to > 180.51. > > This interaction problem is also resolved in the 185.19 beta release. > Thank you, > Andy Ritger > Manager, NVIDIA Linux Graphics Driver a. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520113: mplayer: FTBFS: non-dynamic relocations refer to dynamic symbol free@@GLIBC_2.0
On Wed, Mar 25, 2009 at 11:03:08AM +0100, Diego Biurrun wrote: > --enable-debug > > Why do you use this flag? I added it to ship symbols into mplayer-dbg > It could be the cause for this build failure. can you elaborate? a. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520113: mplayer: FTBFS: non-dynamic relocations refer to dynamic symbol free@@GLIBC_2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, I think I found where the bug is: reading http://sourceware.org/ml/binutils/2008-06/msg00280.html it seems that MIPS has problems linking together PIC and non-PIC code so we need to compile the whole of MPlayer with -fPIC I looked into FFMpeg buildlog, and ffplay.c is compiled with -fPIC https://buildd.debian.org/fetch.cgi?&pkg=ffmpeg-debian&ver=3%3A0.svn20090303-1&arch=mips&stamp=1236142779&file=log a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknAxCkACgkQ9B/tjjP8QKT1+gCeJI4g8eeeV0Z56DseP+yelBcB OvYAnRurwbN69WrXJndmBscM0Odavd8H =eASq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520113: mplayer: FTBFS: non-dynamic relocations refer to dynamic symbol free@@GLIBC_2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am puzzled... how come that this happens only on MIPS? a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknAF9MACgkQ9B/tjjP8QKSG0ACgjrJmJanbCaYkqwrMqF81mmjP bCsAnjcTdxbxoZne1lPTrcMnn/CTTflz =SB+S -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#474947: the state of Bug#474947
retitle 474947 "fix Dynamic MMaps error" severity 474947 important tag 474947 -unreproducible thanks hi bug, hi people, hi d-release I did some study on bug 474947, that is grave/RC, and is posted against APT. Since I was told that the APT team is understaffed, I decided to take action myself. --- First of all, I tried to focus the problem. In this same bug there were reported two different issues, a "Dynamic MMap error" and a segmentation fault; moreover some people were using APT in Etch, and some other in Lenny. Let's summarize it shortly. First poster is Elliot Mitchel, in Apr 08; he is using APT 0.6.46 inside Etch. He claims that he cannot work around a "Dynamic MMap" error; he then sets severity to grave. It turns out that he is using the wrong option, he is using '-o APT::Cache-File=2' instead of '-o APT::Cache-Limit=2' . (And that confuses "Joe Nahmias" and me as well - the mistake is noted by JackYF quite later). So the first report is flawed. jasen reports a similar problem, but I don't see enough details to comment. Then Elliott Mitchell again also posts a report about a segmentation fault. Some months go by; in Sept. JackYF offers to help fixing the problem by changing the code. (Unfortunately we are already in deep freeze, and I am afraid deep changes to APT would not be accepted by the release team.) I did some more research around, and tests, and this is what I found out. The default in APT (inside the code) for Cache-Limit in Lenny is 20MB , in Etch is 8MB . Note also that in the Lenny release notes http://svn.debian.org/viewsvn/ddp/manuals/branches/release-notes/lenny/en/upgrading.dbk it is suggested to set Cache-Limit to 1250 in case of Dynamic MMap error. I tested APT 0.6.46 in Etch. I tried with 3 different sources.list, see attachment. The "fat" list is the union of all lists of all reporters (minus obsolete and duplicates). The two smaller files work perfectly well; the "fat" sources file does trigger the DynamicMMap problem, that I can though work around by using 'apt-get -o APT::Cache-Limit=1 update' The only way to trigger a segmentation fault was instead to set Cache-Limit to a ridiculously low value. So my conclusion is that the forthcoming release notes do address the problem some people may encounter in upgrading from Etch to Lenny. I propose the attached patch, though, since it is funny to suggest a value of 1250 (bytes) when the internal value in Lenny is 20MB. I hope someone in the d-relase team can apply it. a. Index: manuals/branches/release-notes/lenny/en/upgrading.dbk === --- manuals/branches/release-notes/lenny/en/upgrading.dbk (revisione 5426) +++ manuals/branches/release-notes/lenny/en/upgrading.dbk (copia locale) @@ -957,10 +957,11 @@ to a value that should be sufficient for the upgrade: -# echo 'APT::Cache-Limit 1250;' >> /etc/apt/apt.conf +# echo 'APT::Cache-Limit 2100;' >> /etc/apt/apt.conf -This assumes that you do not yet have this variable set in that file. +This assumes that you do not yet have this variable set in that file; +otherwise you may manually edit the file to set the above variable. Sometimes it's necessary to enable the APT::Force-LoopBreak deb http://debian.oregonstate.edu/debian/ stable main contrib non-free deb http://security.debian.org stable/updates main contrib non-free deb http://www.debian-multimedia.org stable main deb http://volatile.debian.org/debian-volatile stable/volatile main contrib non-free deb http://debian.oregonstate.edu/debian/ testing main contrib non-free deb-src http://debian.oregonstate.edu/debian/ stable main contrib non-free deb-src http://security.debian.org stable/updates main contrib non-free deb-src http://www.debian-multimedia.org stable main deb-src http://volatile.debian.org/debian-volatile stable/volatile main contrib non-free deb-src http://debian.oregonstate.edu/debian/ testing main contrib non-free #- deb http://ftp.egr.msu.edu/debian/ unstable main contrib deb-src http://ftp.egr.msu.edu/debian/ unstable main contrib deb http://ftp.us.debian.org/debian/ unstable main contrib non-free deb-src http://ftp.us.debian.org/debian/ unstable main contrib non-free deb http://ftp.us.debian.org/debian/ etch main contrib non-free deb http://ftp.us.debian.org/debian/ lenny main contrib non-free deb-src http://mentors.debian.net/debian unstable main contrib # deb ftp://ftp.nz.debian.org/debian etch main non-free contrib deb-src http://ftp.nz.debian.org/debian stable main non-free contrib deb http://ftp.nz.debian.org/debian lenny main contrib non-free deb http://ftp.nz.debian.org/debian unstable main contrib deb http://www.debian-multimedia.org etch main deb ftp://ftp.au.debian.org/debian etch main non-free contrib deb-src http://ftp.au.debian.org/debian etch main non-free contrib deb-src http://ftp.nz.debian.org/debian testing main contrib
Bug#474947: Not reproducible?..
hi, On Mon, Oct 20, 2008 at 03:30:14PM +0300, Eugene V. Lyubimkin wrote: > P.S. No one answered on my investigation message before :( BTW, I am not part of the APT team. I tried to address this bug after I read http://lists.debian.org/debian-devel-announce/2008/10/msg0.html > Though, I think, severity of this bug can be downgraded (imho, to important) > if it show itself rarely. This is something that either the APT team or the d-release team should decide though. > Secondly, you have used wrong APT option. 'APT::Cache-Limit', not > 'APT::Cache-File' is actual option. Sorry. > I totally disagree with tag 'unreproducible'. I can reproduce it 100% on my > machine with small amount of apt cache. > Try to do any valuable (with updates) > update with '-o APT::Cache-Limit=2' and see "dynamic MMap ran out of > room...". I finally managed to trigger a bug. By changing /etc/apt/sources a lot of times, and by using apt-get -o APT::Cache-Limit=100 update I got a segfault. I then recompiled APT 0.7.14 using DEB_BUILD_OPTIONS=noopt,nostrip fakeroot debian/rules build and I run it as root as follows cd apt-0.7.14/build export LD_LIBRARY_PATH='./bin:/lib/' gdb --args apt-get -o 'APT::Cache-Limit=100' update so I could get this backtrace Program received signal SIGSEGV, Segmentation fault. 0x00370987d00b in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x00370987d00b in memcpy () from /lib/libc.so.6 #1 0x7fe5018a5d76 in pkgCacheGenerator (this=0x7fff09b220d0, pMap=0x23aee20, Prog=0x7fff09b22a90) at pkgcachegen.cc:60 #2 0x7fe5018a71b5 in pkgMakeStatusCache ([EMAIL PROTECTED], [EMAIL PROTECTED], OutMap=0x7fff09b22b60, AllowMem=false) at pkgcachegen.cc:872 #3 0x7fe50189b40e in pkgCacheFile::BuildCaches (this=0x7fff09b22b60, [EMAIL PROTECTED], WithLock=true) at cachefile.cc:68 #4 0x0040d745 in ?? () #5 0x7fe50185db15 in CommandLine::DispatchArg (this=0x7fff09b23340, Map=0x7fff09b23230, NoMatch=true) at contrib/cmndline.cc:337 #6 0x0040a5f5 in ?? () #7 0x00370981e1a6 in __libc_start_main () from /lib/libc.so.6 #8 0x00406289 in ?? () #9 0x7fff09b23458 in ?? () #10 0x001c in ?? () #11 0x0004 in ?? () #12 0x7fff09b23bac in ?? () #13 0x7fff09b23bbd in ?? () #14 0x7fff09b23bc0 in ?? () #15 0x7fff09b23bd5 in ?? () #16 0x in ?? () Note that, to trigger it, you have to force a rebuild of APT caches; to this end, I changed the mirrors in /etc/apt/sources list. (If I run 'apt-get update' succesfully once, then apt-get -o 'APT::Cache-Limit=100' update will not crash, unless I change /etc/apt/sources list again). I tried to give a look into the source code, but unfortunately I don't know it enough to understand what is going on. All this said, the bug I am triggering is somewhat artificial. If I run 'apt-get update' simply, it all works fine in my case. So please provide some more info. Do you have an example situation where /etc/apt/sources.list does not work with 'apt-get update' (with no options - and also please check what you have in /etc/apt/apt.conf ) ? a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474947: unreproducible APT bug
tag 474947 +unreproducible thanks hi, I tried this bug and I cannot reproduce it. I have copied all sources from this bug report into my /etc/apt/sources.list and removed duplicates, and deleted non-US entries (they are obsolete); the resulting file is attached. I then run apt-get update and also apt-get -o APT::Cache-File=2 update and it went smoothly. Maybe it was a transient bug (a corruption in a mirror? faulty HW ? an incompatible library and then APT was rebuilt by binNMU?) a. deb http://debian.oregonstate.edu/debian/ stable main contrib non-free deb http://security.debian.org stable/updates main contrib non-free deb http://www.debian-multimedia.org stable main deb http://volatile.debian.org/debian-volatile stable/volatile main contrib non-free deb http://debian.oregonstate.edu/debian/ testing main contrib non-free deb-src http://debian.oregonstate.edu/debian/ stable main contrib non-free deb-src http://security.debian.org stable/updates main contrib non-free deb-src http://www.debian-multimedia.org stable main deb-src http://volatile.debian.org/debian-volatile stable/volatile main contrib non-free deb-src http://debian.oregonstate.edu/debian/ testing main contrib non-free #- deb http://ftp.egr.msu.edu/debian/ unstable main contrib deb-src http://ftp.egr.msu.edu/debian/ unstable main contrib deb http://ftp.us.debian.org/debian/ unstable main contrib non-free deb-src http://ftp.us.debian.org/debian/ unstable main contrib non-free deb http://ftp.us.debian.org/debian/ etch main contrib non-free deb http://ftp.us.debian.org/debian/ lenny main contrib non-free deb-src http://mentors.debian.net/debian unstable main contrib # deb ftp://ftp.nz.debian.org/debian etch main non-free contrib deb-src http://ftp.nz.debian.org/debian stable main non-free contrib deb http://ftp.nz.debian.org/debian lenny main contrib non-free deb http://ftp.nz.debian.org/debian unstable main contrib deb http://www.debian-multimedia.org etch main deb ftp://ftp.au.debian.org/debian etch main non-free contrib deb-src http://ftp.au.debian.org/debian etch main non-free contrib deb-src http://ftp.nz.debian.org/debian testing main contrib non-free deb ftp://ftp.nerim.net/debian/ stable main contrib non-free signature.asc Description: Digital signature
Bug#500426: fuzzyocr: incompatible with current spamassassin
Package: fuzzyocr Version: 2.3b-2 Severity: grave Justification: renders package unusable It turns out that, when installed with spamassassin 3.2, fuzzyocr 2.3b-2 does absolutely nothing a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332782: Your contribution to the Debian release notes
On Thu, Sep 04, 2008 at 12:25:15PM +0200, W. Martin Borgert wrote: > "I allow that my contribution to the Debian GNU/Linux release > notes can be distributed under any DFSG-free license." fine for me a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488978: audacious: segfault at start
Package: audacious Version: 1.5.1-1 Severity: grave Justification: renders package unusable hi I cannot use audacious, it crashes at start (BTW, I deinstalled audacious-plugins-extra ) here is the backtrace [Switching to Thread 0xb7286720 (LWP 14654)] 0xb7602812 in strrchr () from /lib/i686/cmov/libc.so.6 (gdb) whe #0 0xb7602812 in strrchr () from /lib/i686/cmov/libc.so.6 #1 0xb7d3fdbe in g_basename () from /usr/lib/libglib-2.0.so.0 #2 0x08065065 in set_pvt_data (plugin=0xb6464f09, data=0xb648a848) at pluginenum.c:425 #3 0xb6464f20 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #4 0xb6464f09 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #5 0xb648a848 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #6 0xbf944b18 in ?? () #7 0xb6462782 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #8 0xb7f47668 in _r_debug () #9 0xb64843c3 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #10 0x040c in ?? () #11 0x080659f1 in plugin_set_current (plugin=0xb7f47668) at pluginenum.c:413 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) bt -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages audacious depends on: ii audacious-plugins 1.5.1-1Base plugins for audacious ii dbus 1.2.1-2simple interprocess messaging syst ii gtk2-engines-pixbuf 2.12.10-2 Pixbuf-based theme for GTK+ 2.x ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libaudclient1 1.5.1-1audacious D-Bus remote control lib ii libc6 2.7-12 GNU C Library: Shared libraries ii libcairo2 1.6.4-6The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.1-2simple interprocess messaging syst ii libdbus-glib-1-2 0.76-1 simple interprocess messaging syst ii libglib2.0-0 2.16.4-1 The GLib library of C routines ii libgtk2.0-0 2.12.10-2 The GTK+ graphical user interface ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libmcs1 0.7.1-1Abstraction library to store confi ii libmowgli10.6.1-1a high performance development fra ii libpango1.0-0 1.20.4-1 Layout and rendering of internatio ii libsamplerate00.1.3-1audio rate conversion library ii libsm62:1.0.3-2 X11 Session Management library ii libx11-6 2:1.1.4-2 X11 client-side library Versions of packages audacious recommends: pn audacious-plugins-extra(no description available) ii unzip 5.52-11De-archiver for .zip files -- no debconf information -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395252: mplayer+ffmpeg, and some progress, Re: Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 04:24:18PM +0200, Reinhard Tartler wrote: > Since mplayer includes an exact copy of ffmpeg by using an 'svn:external' > on the ffmpeg svn, it makes sense to build shared library packages out > of that source. hi Reinhard, I did build such a package ~1 month ago; the package source name is mplayer+ffmpeg , and it is a combination of mplayer.orig.tar.gz + ffmpeg-free.orig.tar.gz + all mplayer debian/ + all ffmpeg debian/ + extra quilt (it uses the latest features of dpkg-source (3.0 quilt) , it is quite neat). So this mplayer+ffmpeg package is a merge , containing both packages, in two separate subtrees. Since the subtrees are separate, this means that it is reasonably easy to transition for we mplayer&ffmpeg developers: to start with, each one of us can just work in the subtree where we know how stuff work; then we refine and polish to taste. Pros: the package mplayer+ffmpeg package compiles and builds all expected binaries. What it does: copy fffmpeg code into mplayer cd into ffmpeg subtree, apply ffmpeg quilt debian patches, compile ffmpeg-free binaries cd into mplayer subtree, apply mplayer debian patches, compile mplayer binary Cons: at that time, I did not find out a way to link mplayer to ffmpeg (but see next section). The reason why I was despairing, is that the following sequence failed to link. apply ffmpeg quilt debian patches into ffmpeg subtree copy fffmpeg code into mplayer cd into ffmpeg subtree, compile ffmpeg-free binaries cd into mplayer subtree, apply mplayer debian patches, compile mplayer binary So my best understanding was that, somehow, one of the ffmpeg quilt debian patches was changing some important code , and that rendered it incompatible with mplayer. But really I could not understand what was wrong. But I did a great progress. After I received the bad news, I went to the drawing table once again, started everything from scratch once again, and step by step I created a new set of patches, and this time I could link a version of mplayer to the ffmpeg libraries. This is very preliminary, I dont understand why it works now and it did not work before, I did not even have time to test if this mplayer can play most video and audio OK. If it works, I will also need to post some patches for ffmpeg-free : indeed , the ffmpeg *-dev files do not contain currently some .h and .c files that mplayer needs. I will post more info as I find some time to test the compiled binary and the resulting package. (sorry I have to be brief, I am busy with Real Life & Work & Moving to a New House (tm) in these days) -- My package mplayer+ffmpeg remains though an interesting object, that we may explore for lenny+1 ; now that I have also some new possibly working better patches, I will improve it, and I will upload it to experimental. a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 12:30:33PM +0100, Neil McGovern wrote: > I also find it fairly rich that you complain at a lack of answers, and > yet don't reply to pings to a BR asking for an update. The reason I did not reply is that I was working to find a solution to the bug, but I did not find it. > You seem to be confused, these aren't the same transition. The one > mentioned in 2007 transitioned on 2007-07-05, five days after the mail. > Perhaps the fact that the source package name has changed in the last > year is causing an issue for you? OK, I get the point. > > You do not see the weekends I spent in the last 3 months trying to > > link mplayer to ffmpeg-free in Debian. > > > > This is good, but should have happened sooner. This bug has been open > since Sarge was stable. ffmpeg-free 0.svn20080206-1 was uploaded in experimental in 2008-03-30. Before, AFAICR, a C structure in libavcoded was different, there was no hope of linking. > > I regularly upload new versions, and > > fix as many bugs as I can each time. > > But not enough to fix a RC bug that's been open since 2006. I fix all bugs that can reasonably be fixed. When ffmpeg in Debian was too obsolete to link to mplayer, there was nothing I could do. Since 2006, many things happened; for example, in http://bugs.debian.org/403330 I asked for a new version of ffmpeg, but 403330 was closed by the version 0.cvs20070307 that became rapidly obsolete wrt mplayer 1.0~rc2 a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 10:29:17AM +0100, Neil McGovern wrote: > Neither, it's the RC policy which carries more weight than a RG: > http://release.debian.org/lenny/rc_policy.txt > > 5a) Packages in the archive must not be so buggy or out of date that we > refuse to support them. > > The security team has confirmed multiple times that this is no longer > supportable. Your phrase "no longer" confirms that there is a fundamental misunderstanding in this point. The package 'mplayer' is not 'so buggy', it has 40 bugs, and that is average. The only RC bug that 'mplayer' has is 395252. This bug says "mplayer requires too much security maintainance work due to embedded ffmpeg copy". But this "too much security work" was claimed even before etch was released, and is a claim that had and still has no supporting facts. Indeed 'mplayer' had 3 security updates so far in Etch. No one of those security updates was fixed by patching code in the ffmpeg library. So this whole bug 395252 is based on an apriori assumption; moreover this assumption was proved wrong by facts. Summarizing, you are deciding that mplayer is too buggy to be supported because of a bug that claims that same argument. Don't you see how circular this whole reasoning is? Not to mention that, for reasons behond my comprehension, mplayer is the only package targetted by this reasoning. 1) As I said in the other email, the policy 3.8.0 now contains a paragraph [14.3] against embedded copies, that is though waived for Lenny. For some reasons, you do not accept that mplayer be given the same treatment. 2) Another point is that http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=file&rev=0&sc=0 lists many packages which ship embedded copies. One example is mozilla/iceweasel/iceape. Iceweasel had 9 security bugs in Etch. Iceweasel has ~500 bugs (!!). So iceweasel should be kept out of Lenny, since it contains embedded copies of code and is quite buggy. But no one is ever posting this RC bug. Why? Beats me. a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 10:29:17AM +0100, Neil McGovern wrote: > On Wed, Jun 18, 2008 at 11:10:21AM +0200, A Mennucc wrote: > And that was the case since 16 Dec 2006? yes. Read ahead. > Why was this not brought up > sooner, and why has there been zero effort made into resolving this > issue, as far as we can see? You don't see all that has happened. You do not see the many emails I sent to ffmpeg-free mantainers, almost all of them went unanswered (but for one). I can provide you a complete list, if you wish. The other thing you fail to see is that the "ffmpeg transition" was announced on d-devel-announce on 1st July 2007 (yes, that is not a typo!) and is still going on, according to http://packages.qa.debian.org/f/ffmpeg-free.html You do not see the weekends I spent in the last 3 months trying to link mplayer to ffmpeg-free in Debian. Another thing you fail to see is that, each time there was a security bug in MPlayer, I prepared a corrected source in a 48h time max, signed it, and sent an email to the security team telling them where to retrieve the new source. In some cases, I even prepared the correct source before a security alert was issued by CVE. In some cases, moreover, the security team took 1 month (!) to then forward my source into stable-security. Yet another thing you fail to see is that I care for my packages a lot: mplayer is 1191 in the popcon list, and yet I manage to keep its bug count at a reasonable ~40; I regularly upload new versions, and fix as many bugs as I can each time. If I had known in advance that all my time was lost for nothing, I would have gone collecting daises in sunlight instead. a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
hi On Tue, Jun 17, 2008 at 10:28:27PM +0100, Neil McGovern wrote: > I'm afraid I can't accede to your request. This bug has been open since > 25 Oct 2006. The etch-ignore tag was added 16 Dec 2006, where it was > explicitly stated that it's RC for lenny. I pinged the bug on 28 Mar > 2008, to again state that it's RC for lenny. May you please explain which part of the debian-policy, or which release goal, it is violating? > I'm concerned as to why there as been seemingly no progress in over a > year to resolving this issue. This is all explained in the long email I sent; anyway, let me summarize again. Up to a 2008-05-19 , the version of ffmpeg-free in unstable was totally incompatible with mplayer. The new version of ffmpeg-free is based on a compatible code, but the quilt patches disable a symbol that is needed to link to mplayer. a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
hi everybody I am requesting to the d-release team a lenny-ignore tag for bug 395252. There are multiple reasons for this request, please take some time to read ahead. --- Reason 1 : policy Recently, after a long discussion in bug 392362, a paragraph [4.13] was added to d-policy 3.8.0 stating (briefly) that: > Some software packages include in their distribution convenience > copies of code from other software packages [...] > Debian packages should not make use of these convenience copies unless > the included package is explicitly intended to be used in this way. This change was advertised in the email of early June by Russ Allbery to d-devel-announce, http://lists.debian.org/debian-devel-announce/2008/06/msg1.html The message starts by saying: > Please note that the Policy release cycle is not currently > well-synchronized with the release cycle, and adjusting to this version of > Policy is *not* a priority for the upcoming lenny release unless the > relevant provision has already separately been accepted as a release goal. I do not find [4.13] in http://release.debian.org/lenny/goals.txt , so I assume that "unless" part does not apply. So, the matter of bug 395252 (that was vehemently discussed there) is now settled once and for all in the debian policy. But there is an exception for lenny, and for this reason I am asking for a tag for this bug. [This also addresses a complaint of me and of Joey Hess, that is, why was mplayer singled out on this issue? Now no package is singled out, the bug is not RC for lenny, it will be RC for all packages after Lenny. I find this fair.] Reason 2: it does not work The other reason is that I did not find a way to comply to the request. There are two problems. ---2.1 missing headers and code in -dev files When 'mplayer' is compiled, it uses a lot of *.h files from its embedded ffmpeg; moreover, its 'configure' file scans some *.c files to get the up-to-date listing of supported codecs etc etc. Unfortunately, the -dev binary packages generated by "ffmpeg-free" contain only a small part of all the needed stuff. This said, I manually copied all needed stuff so as to compile all code, but... 2.2 the mplayer binary does not link with the "ffmpeg-free" libs. By reading and diffing, it would seem that the newer ffmpeg-free 0.svn20080206 source code seems compatible to the ffmpeg code shipped in mplayer... but unfortunately when I try to link, it fails. The error is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252#226 I think that the problem is that the 'ffmpeg-free' code in Debian does not contain all the upstream code; and then, to be able to compile, there are many quilt patches that affect the shipped code, and a restrictive 'configure' call. All this kills some symbols that 'mplayer' needs. Unfortunately I could not properly identify where and why this linking failure originates. This is why I add a 'help' tag to the bug. If there is some simple way out of this that I am overseeing, please tell. -- reason 3: ffmpeg is in transition One insight that I got from all the above is that , to link mplayer to ffmpeg-free generated libraries, there are possibly many changes to be made in ffmpeg-free. But this is not a good time to change those libraries, that are in a transition. a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: software embedding ffmpeg
hi, I have been trying to address this bug from time to time , but with no success so far ; up to some time ago, the version of ffmpeg-free in unstable was 0.cvs20070307 , and that had an difference in a fundamental C structure in a header, wrt mplayer. Joey Hess ha scritto: > So is there any reason why > mplayer should not statically link to the packaged version, as kino, > vlc, etc do? By looking at the code 0.svn20080206 (that was in experimental , and is in unstable since 19 may), it would seem that static linking would be possible; but when I try to link , I get these errors libavformat/libavformat.a(aviobuf.o): In function `ff_crc04C11DB7_update': /home/debian/mplayer/ffmpeg-merge/ffmpeg-itself/ffmpeg-free-0.svn20080206/libavformat/aviobuf.c:321: undefined reference to `av_crc_get_table' libavformat/libavformat.a(asfcrypt.o): In function `ff_asfcrypt_dec': /home/debian/mplayer/ffmpeg-merge/ffmpeg-itself/ffmpeg-free-0.svn20080206/libavformat/asfcrypt.c:152: undefined reference to `ff_rc4_enc' /home/debian/mplayer/ffmpeg-merge/ffmpeg-itself/ffmpeg-free-0.svn20080206/libavformat/asfcrypt.c:158: undefined reference to `ff_des_encdec' /home/debian/mplayer/ffmpeg-merge/ffmpeg-itself/ffmpeg-free-0.svn20080206/libavformat/asfcrypt.c:162: undefined reference to `ff_rc4_enc' libavformat/libavformat.a(mpegts.o): In function `write_section_data': /home/debian/mplayer/ffmpeg-merge/ffmpeg-itself/ffmpeg-free-0.svn20080206/libavformat/mpegts.c:264: undefined reference to `av_crc_get_table' libavformat/libavformat.a(mpegtsenc.o): In function `mpegts_write_section': /home/debian/mplayer/ffmpeg-merge/ffmpeg-itself/ffmpeg-free-0.svn20080206/libavformat/mpegtsenc.c:46: undefined reference to `av_crc_get_table' libavformat/libavformat.a(nut.o): In function `ff_nut_add_sp': /home/debian/mplayer/ffmpeg-merge/ffmpeg-itself/ffmpeg-free-0.svn20080206/libavformat/nut.c:52: undefined reference to `av_tree_node_size' collect2: ld returned 1 exit status Unfortunately, I do not yet understand why. a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480309: NMU of pygame 1.8
dear pygame mantainer, hi, bugs in pygame are keeping freevo out of testing ; for this reason, I will NMU pygame in some days, unless you tell me you have time to update pygame yourself a. signature.asc Description: Digital signature
Bug#481071: crashes freevo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi this bug crashes freevo on amd64 CPUs. This is why I added a "blocks" tag. a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIL+xU9B/tjjP8QKQRAtYQAJ49hTMh9YQUkBW2V/41cAbQWIhHtQCeKWfT rm2bYlqHst7/gkzmUAMmWDM= =XtET -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480309: [Pkg-freevo-maint] Bug#480309: freevo: Bug is in pygame
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 this bug was (indipendently) posted to python-pygame I added a "blocks" a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILzuU9B/tjjP8QKQRAsMtAJsHY7U1L7K5CgoqBf5KvbOgYz5CaQCcDTya YcGVUeIy3+vJb5fSYZk33kI= =hojp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481375: [mplayer] mplayer: symbol lookup error: mplayer: undefined symbol: XScreenSaverSuspend
On Thu, May 15, 2008 at 04:59:45PM +0100, Don Alexander wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Package: mplayer > Version: 1:1.0.rc2svn20080417-0.0 you are not using the version in Debian main, but the version packaged by C. Marillat a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480309: [Pkg-freevo-maint] Bug#480309: Crash at startup
On Fri, May 09, 2008 at 03:02:11PM +0200, Julien Danjou wrote: > I don't know why but here it just crashes: here instead it works... > error opening file /home/freevo/cache/vfs/home/freevo/cache/skin-111 please try moving away the whole of /home/freevo/cache with these steps $ su - freevo $ mv /home/freevo/cache /home/freevo/cache~damaged $ mkdir /home/freevo/cache then try running freevo again a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475973: mplayer: FTBFS: cabac.h:525: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
On Mon, Apr 14, 2008 at 04:38:47PM +0200, Lucas Nussbaum wrote: > Don't blame gcc 4.3. It built that code fine last week. Blame dpkg (see > my other mail) actually, I am happy to know that. Having one gcc bug that stops mplayer from transitioning from sid to lenny was already one gcc bug too many. a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475973: mplayer: FTBFS: cabac.h:525: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
On Mon, Apr 14, 2008 at 03:06:50PM +0200, Reimar Döffinger wrote: > > > > This might be caused by the default value of CFLAGS now set by > > dpkg-buildpackage. > > No, certainly not. well, looking at the original bug report, it really says "cc -g -O2" more details are in http://people.debian.org/~lucas/logs/2008/04/13/mplayer_1.0~rc2-10_sid32-gcc43.buildlog > Maybe this code doesn't build with -O2 ? This is exactly that. OK, thanks everyone, I think we found what is causing the build failure. In particular, thanks to lucas for telling me about this new "feature" of dpkg-buildpackage . I will study how to stop the dpkg-buildpackage CFLAGS from creeping down to the building of mplayer. a.
Bug#475973: mplayer: FTBFS: cabac.h:525: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
hi Read from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402950#44 on. As you see, that piece of code worked in the past, if enough optimization was allowed. The fact that it does not work anymore is quite surprising and I would consider this a regression in gcc 4.3 anyhow I will do some cross checks and see a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475973: mplayer: FTBFS: cabac.h:525: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
On Mon, Apr 14, 2008 at 12:48:56PM +0200, Lucas Nussbaum wrote: > Package: mplayer > Version: 1.0~rc2-10 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: qa-ftbfs-20080413 qa-ftbfs > Justification: FTBFS on i386 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on i386. > > This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is now > the default on most architectures (even if it's not the case on i386 yet). > Feel free to downgrade this bug to 'important' if your package is only built > on i386, and this bug is specific to gcc 4.3 (i.e the package builds fine with > gcc 4.2). hi I am not sure on what you mean by the above conditional ''your package is only built on i386'' AND ''this bug is specific to gcc 4.3'' What I am sure of is that mplayer builds fine with gcc 4.2, so I see this as a bug in gcc 4.3 , not a bug in mplayer. And this is the second bug with gcc 4.3 not being able to build mplayer, the other bug is 475153 Maybe gcc 4.3 is not yet mature enough? Maybe the decision to switch to gcc 4.3 was a bit too fast? a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473056: mplayer: CVE-2008-0073 remote code execution via crafted rtsp stream
Nico Golde ha scritto: > Package: mplayer > Severity: grave > Tags: security patch > > This also affects mplayer since it also uses this code. > A patch is available on: > http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=12cb075fba8ea09813fc35e0c731d2a64265b637;style=raw I saw a comment of Reimar (that I am CC-ing); he wrote in the mplayer dev list, saying that mplayer is not affected as badly as xine; anyway Reimar wrote a short patch, that I will apply tomorrow a. signature.asc Description: OpenPGP digital signature
Bug#472630: audacious-crossfade: audacious segfaults
Package: audacious-crossfade Version: 0.3.14-1 Severity: grave Justification: renders package unusable hi when I start audacious, it immediatly segfaults. I use 'gdb' to get this backtrace: [Switching to Thread 0xb7440720 (LWP 14979)] 0xb79a977c in g_type_check_instance_cast () from /usr/lib/libgobject-2.0.so.0 (gdb) whe #0 0xb79a977c in g_type_check_instance_cast () from /usr/lib/libgobject-2.0.so.0 #1 0x080586ca in ?? () #2 0xb674b039 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #3 0x081423f0 in ?? () #4 0xbfee34d8 in ?? () #5 0xb674b050 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #6 0xb674b039 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #7 0xb6770248 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #8 0xbfee3508 in ?? () #9 0xb6748872 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #10 0xb7f41668 in _r_debug () #11 0xb676a5f3 in ?? () from /usr/lib/audacious/Output/libcrossfade.so #12 0x040c in ?? () #13 0x08067491 in ?? () #14 0x in ?? () So I remove audacious-crossfade from my host, and now audacious works fine. a. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages audacious-crossfade depends on: ii audacious 1.5.0-1small and fast audio player which ii libc6 2.7-9 GNU C Library: Shared libraries ii libsamplerate00.1.2-5audio rate conversion library audacious-crossfade recommends no packages. -- no debconf information -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) signature.asc Description: Digital signature
Bug#445731: mplayer stops working after kernel update to 2.6.21
On Sat, Oct 13, 2007 at 03:25:06PM -0400, Sean Zimmermann wrote: > I tried playing the file with totem, and, though it begins to play > the file correctly, audio cuts out within the first few seconds, > though it continues to play the video. this IMHO means that ALSA is still broken overall this does not look like an mplayer bug, probably totem is sending data in a non-blocking fashion a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445731: mplayer stops working after kernel update to 2.6.21
hi when you boot with the new kernel, does audio work with other applications? If you use Gnome , can you play sounds in the gnome sound manager ? may you try with totem ? if the above works, may you please try again playing your files with mplayer , but using the option '-ao esd' ? thanks a. On Tue, Oct 09, 2007 at 12:42:30PM +0200, Reimar Döffinger wrote: > > There is no difference at all in the outputs. I suspect this is not an > > MPlayer problem. > > Actually there is, in the later one audio gets stuck at 0.0 seconds. > My guess is that ALSA broke... > > Greetings, > Reimar Döffinger > -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420
Bug#445731: mplayer stops working after kernel update to 2.6.21
hi please send us the output of 'mplayer -v -v -v file...' (with both kernels if possible) a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434877: copyright file doesn't say where to get the source from
hi On Fri, Jul 27, 2007 at 03:00:26PM +0200, Nico Golde wrote: > the copyright file of this package is totally broken, it > doesn't even name where to get the source code from > in the copyright file which is a policy violation. I guess that you are referring to this line in the policy: "In addition, the copyright file must say where the upstream sources *(if any)* were obtained. It should name the original authors of the package and the Debian maintainer(s) who were involved with its creation." I took the liberty to highlight the "(if any)" part well, it turns out that there is no upstream source to sql-editor: the code in Debian is the upstream code. You know why I know? 'Cos I am the upstream author as well. (and, btw, this is stated in the copyright file). So this bug is not a serious bug. a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434726: xdelta: update for glib transition
Package: xdelta Version: 1.1.3-7 Severity: grave Justification: renders package unusable hi libglib1.2 has been renamed to libglib1.2ldbl so currently xdelta is not installable in unstable a. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Versions of packages xdelta depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libglib1.2 1.2.10-17The GLib library of C routines ii libxdelta2 1.1.3-7 Xdelta runtime library ii zlib1g 1:1.2.3-13 compression library - runtime xdelta recommends no packages. -- no debconf information -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434726: Acknowledgement (xdelta: update for glib transition)
the bug was fixed by binNMU (on Sat 21) ; for some reasons, this binNMU has not yet entered into unstable a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432689: mplayer: Always crashes right after start
On Wed, Jul 11, 2007 at 01:46:30PM +0200, Rafal Krypa wrote: > MPlayer binary, even when run with empty config files and no command > line options, receives SIGSEGV before it is able to print or do anything > noticeable. try $ mplayer -v -v does it print absolutely nothing? > Backtrace: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208695088 (LWP 4127)] > 0x in ?? () > (gdb) backtrace > #0 0x in ?? () > #1 0x4954d7e5 in pthread_once () from /lib/i686/cmov/libpthread.so.0 > #2 0x49cf2ebe in glXChannelRectSyncSGIX () from /usr/lib/libGL.so.1 > #3 0x49d27818 in ?? () from /usr/lib/libGL.so.1 > #4 0x49cf3240 in _init () from /usr/lib/libGL.so.1 > #5 0xbffd6878 in ?? () > #6 0x in ?? () it seems that you have a problem with the GL library do you use compix? try disabling direct rendering a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429736: world readable passwords in /var/cache/debconf/config.dat
On Tue, Jun 19, 2007 at 09:28:05PM +0100, Stefano Zacchiroli wrote: > Package: zope-debhelper > Version: 0.3.9 > Severity: grave > Tags: security > > The maintainer scripts generated by zope-debhelper leave passwords in > /var/cache/debconf/config.dat. Passwords are therefor world readable by > any user of the system. Tagging this bug a security since this is a > local privilege escalation: users can access instances as the > administrator user. they should go in /var/cache/debconf/passwords.dat instead (and that is where zope-common did put them AFAICT) a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414072: Bug#414075: mplayer patch
hi you also need this patch -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 --- trunk/loader/dshow/DS_VideoDecoder.c 2007/01/26 09:21:22 22019 +++ trunk/loader/dshow/DS_VideoDecoder.c 2007/02/11 17:57:02 22205 @@ -114,6 +114,7 @@ this->iv.m_bh = malloc(bihs); memcpy(this->iv.m_bh, format, bihs); +this->iv.m_bh->biSize = bihs; this->iv.m_State = STOP; //this->iv.m_pFrame = 0; signature.asc Description: Digital signature
Bug#406455: [Debian-ia32-libs] Bug#406455: acroread on 64bit
On Fri, Jan 26, 2007 at 07:13:34AM +0100, Goswin von Brederlow wrote: > [EMAIL PROTECTED] (A Mennucc) writes: > > > hi > > > > I wanted to test running 'Acrobat Reader' on my amd64, so I installed > > ia32-libs-gtk ; but it failed, as reported in this long bug > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406455 > > > > Disclaimer: I did not have time to read bug 406455; > > but I hope I can add some useful infos, namely: > > > > 0 > > /usr/local/Adobe/Acrobat7.0/bin/acroread is a script; and it > > messes up with LD paths in many places; e.g. at ~ line 430, > > LD_LIBRARY_PATH="$LD_LIBRARY_PATH":/lib:/usr/lib > > > > 1 > > One peace of usefull information would be where you get your acroread > deb from. The rest is known. I downloaded the acroread installer from Adobe itself, and installed it in /usr/local/Adobe/Acrobat7.0 (that is the default it proposes) a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406455: acroread on 64bit
hi I wanted to test running 'Acrobat Reader' on my amd64, so I installed ia32-libs-gtk ; but it failed, as reported in this long bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406455 Disclaimer: I did not have time to read bug 406455; but I hope I can add some useful infos, namely: 0 /usr/local/Adobe/Acrobat7.0/bin/acroread is a script; and it messes up with LD paths in many places; e.g. at ~ line 430, LD_LIBRARY_PATH="$LD_LIBRARY_PATH":/lib:/usr/lib 1 there is no pangohack in the package: $ dpkg -L ia32-libs-gtk | grep pangohack (no result) $ find /usr/lib*/*pango* -name '*hack*' (no result) 2 unless (0) is at fault, it seems that pango is not the only component looking in the wrong place: (acroread:532): Gtk-WARNING **: /usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so: cannot open shared object file: No such file or directory (acroread:532): GdkPixbuf-WARNING **: Error loading XPM image loader: Impossibile aprire il modulo �/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so� per il caricamento delle immagini: /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: cannot open shared object file: No such file or directory a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420
Bug#406689: Acknowledgement (iceape-browser: iceape won't start)
> I will open a BR on dpkg bug #406715 a. signature.asc Description: OpenPGP digital signature
Bug#406689: Acknowledgement (iceape-browser: iceape won't start)
hi
summary:
if mozilla-imagezoom is installed before iceape,
then the installation of iceape fails to set a
symlink, and iceape will not work
I have another host, where I installed iceape-browser, and it works;
so I compared the two installations, and I found the problem. Lets call
DW the host where it does work
NW the host where it does not work
--- in NW:
NW# ls -l /usr/lib/iceape/defaults
drwxr-xr-x 2 root root 4096 2006-12-29 09:54 pref
NW# find /usr/lib/iceape/defaults -ls
2738394 drwxr-xr-x 3 root root 4096 dic 28 19:56
/usr/lib/iceape/defaults
2908104 drwxr-xr-x 2 root root 4096 dic 29 09:54
/usr/lib/iceape/defaults/pref
2908200 lrwxrwxrwx 1 root root 36 dic 29 09:54
/usr/lib/iceape/defaults/pref/imagezoom-defaults.js ->
/etc/mozilla-extensions/imagezoom.js
--- in DW
DW# ls -l /usr/lib/iceape/defaults
lrwxrwxrwx 1 root root 27 2007-01-08 09:44 /usr/lib/iceape/defaults ->
../../share/iceape/defaults
and /usr/share/iceape/defaults contains many files
--- in NW
I did
# mv /usr/{lib,share}/iceape/defaults/pref/imagezoom-defaults.js
# rmdir /usr/lib/iceape/defaults/pref/
# rmdir /usr/lib/iceape/defaults
# ln -s /usr/{share,lib}/iceape/defaults
and now iceape-browser works flawlessly here as well
---
and here is the culprit:
$ dpkg-deb -c mozilla-imagezoom_0.2.7-7_all.deb | grep usr/lib/iceape
drwxr-xr-x root/root 0 2006-12-28 05:55 ./usr/lib/iceape/
drwxr-xr-x root/root 0 2006-12-28 05:55 ./usr/lib/iceape/defaults/
drwxr-xr-x root/root 0 2006-12-28 05:55 ./usr/lib/iceape/defaults/pref/
lrwxrwxrwx root/root 0 2006-12-28 05:55
./usr/lib/iceape/defaults/pref/imagezoom-defaults.js ->
/etc/mozilla-extensions/imagezoom.js
if mozilla-imagezoom is installed before iceape (as in the DW host)
then usr/lib/iceape/defaults is a directory and not a symlink
---
I tried removing mozilla-imagezoom and iceape-browser, and reinstalling
in that order: the problem reappears. The funny point is that
dpkg does not warn in any way that it is failing to set the symlink
usr/lib/iceape/defaults ! I will open a BR on dpkg
a.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406689: iceape-browser: iceape won't start
Package: iceape-browser Version: 1.0.7-2 Severity: grave Justification: renders package unusable hi I just installed iceape in this Etch machine. More precisely, I installed: iceape-browser iceape-gnome-support iceape-mailnews iceape-calendar Unfortunately, iceape refuses to start: it just shows a dialog with title "configuration error" and content "Failed to read the configuration file. Please contact your system administrator." When I installed it the first time, my / partition ran out of disk space; so I deleted some old stuff, and 'dpkg --purge' all packages above, and reinstalled; but the problem is still there. I also tried moving away my .mozilla dir, but to no result. I then 'dpkg --purge' all packages but iceape-browser, and it still fails the same way. a. ps: I am sorry, I am not helping in any way, but I do not really understand why it is failing -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (900, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Versions of packages iceape-browser depends on: ii libatk1.0-0 1.12.4-1 The ATK accessibility toolkit ii libc6 2.3.6.ds1-9GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libfontconfig12.4.1-2generic font configuration library ii libgcc1 1:4.1.1-21 GCC support library ii libglib2.0-0 2.12.7-1 The GLib library of C routines ii libgtk2.0-0 2.8.20-3 The GTK+ graphical user interface ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libmyspell3c2 1:3.1-18 MySpell spellchecking library ii libpango1.0-0 1.14.8-4 Layout and rendering of internatio ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-4 X11 client-side library ii libxcursor1 1.1.7-4X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes31:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxft2 2.1.8.2-8 FreeType-based font drawing librar ii libxi61:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library ii libxrandr22:1.1.0.2-5X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii libxt61:1.0.2-2 X11 toolkit intrinsics library ii zlib1g1:1.2.3-13 compression library - runtime Versions of packages iceape-browser recommends: ii iceape-gnome-support 1.0.7-2Gnome support for the Iceape Inter -- no debconf information -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) signature.asc Description: Digital signature
Bug#402451: flpsed: diff for NMU version 0.3.7-1.1
Hi,
Attached is the diff for my flpsed 0.3.7-1.1 NMU.
--
Andrea Mennucc
"The EULA sounds like it was written by a team of lawyers who want to tell
me what I can't do, and the GPL sounds like it was written by a human
being who wants me to know what I can do."
Anonymous,http://www.securityfocus.com/columnists/420
diff -u flpsed-0.3.7/debian/changelog flpsed-0.3.7/debian/changelog
--- flpsed-0.3.7/debian/changelog
+++ flpsed-0.3.7/debian/changelog
@@ -1,3 +1,20 @@
+flpsed (0.3.7-1.1) unstable; urgency=high
+
+ * NMU, backported some changes from version 0.3.9
+ * debian/rules : use "make distclean" to delete .deps dirs and other cruft
+ * Add "Depends: gs-esp" and use gs-esp (Closes: #402451).
+The lack of dependency is a RC bug, hence the urgency.
+ * GsWidget::setProps() : call XSync()
+(this is done in 0.3.9 to use gs-gpl ; it does not solve bug 402451
+in Debian; but it makes sense nonetheless)
+ * Add Recommends: xpdf-utils | poppler-utils ; this fixes bug
+"pdftops needed for pdf import", thanks to Stephan Beyer (Closes: #388318).
+ * Bug fix: "flpsed generates postscript with references to an unknown
+font 'HelveticaNeue-Roman'", thanks to Jochen Eisinger (Closes: #398906)
+(this change is also part of the newer 0.3.9, so it is a backport)
+
+ -- A Mennucc1 <[EMAIL PROTECTED]> Fri, 12 Jan 2007 09:37:15 +0100
+
flpsed (0.3.7-1) unstable; urgency=low
* New upstream release. Closes: #357749.
diff -u flpsed-0.3.7/debian/control flpsed-0.3.7/debian/control
--- flpsed-0.3.7/debian/control
+++ flpsed-0.3.7/debian/control
@@ -7,7 +7,8 @@
Package: flpsed
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: gs-esp, ${shlibs:Depends}, ${misc:Depends}
+Recommends: xpdf-utils | poppler-utils
Description: a WYSIWYG pseudo PostScript editor
flpsed is a WYSIWYG pseudo PostScript editor. "Pseudo", because you can't
remove or modify existing elements of a document. But flpsed lets you add
diff -u flpsed-0.3.7/debian/rules flpsed-0.3.7/debian/rules
--- flpsed-0.3.7/debian/rules
+++ flpsed-0.3.7/debian/rules
@@ -29,7 +29,7 @@
dh_testroot
rm -f build-stamp flpsed.1
- -$(MAKE) clean
+ -$(MAKE) distclean
dh_clean
--- flpsed-0.3.7.orig/src/Postscript.cxx
+++ flpsed-0.3.7/src/Postscript.cxx
@@ -27,7 +27,7 @@
#define PS_POS_FORMAT "newpath %d %d moveto\n"
#define PS_TEXT_FORMAT "(%s) show\n"
-#define PS_SIZE_FORMAT "/HelveticaNeue-Roman findfont %d scalefont setfont\n"
+#define PS_SIZE_FORMAT "/Helvetica findfont %d scalefont setfont\n"
#define PS_COLOR_FORMAT "%lf %lf %lf setrgbcolor\n"
#define PS_GLYPH_FORMAT "/%s glyphshow\n"
#define PS_TAG_FORMAT ""
--- flpsed-0.3.7.orig/src/GsWidget.cxx
+++ flpsed-0.3.7/src/GsWidget.cxx
@@ -85,6 +85,8 @@
XChangeProperty(fl_display, xid, atoms[1],
XA_STRING, 8, PropModeReplace,
(unsigned char*) data, strlen(data));
+
+ XSync(fl_display, False);
}
void GsWidget::kill_gs() {
@@ -302,7 +304,7 @@
(int) fl_xid(window()), (int) offscreen);
putenv(gvenv);
- argv[0] = "gs";
+ argv[0] = "gs-esp";
argv[1] = "-dSAFER";
argv[2] = "-dQUIET";
argv[3] = "-sDEVICE=x11alpha";
signature.asc
Description: Digital signature
Bug#402451: flpsed really needs gs-esp
[forwarding this into the bug, so it is visible from the web page as well] I tried flpsed on a fresh install of etch and it fails as well: hence the "confirmed" tag. Since there is no dependency on gs, flpsed fails this requirement: Packages must include a "Depends:" line listing any other packages they require for operation, unless those packages are marked "Essential: yes". Packages must include a "Pre-Depends:" line listing any packages required by their preinst. http://release.debian.org/sarge_rc_policy.txt I already proposed a patch (1 month ago); If the mantainer does not upload a patched version, I will NMU tomorrow. a. signature.asc Description: OpenPGP digital signature
Bug#111342: xarchon: diff for NMU version 0.50-10.1
tags 111342 -woody
thanks
Hi,
Attached is the diff for my xarchon 0.50-10.1 NMU.
I changed it a little bit.
Basilarly,
-misc-fixed-medium-*-normal-*-15-0-*-*-*-*-iso8859-1
fails; while
-misc-fixed-medium-*-normal-*-15-*-*-*-*-*-iso8859-1
instead works.
I also fixed two lintian warnings:
- deleted a duplicate build-dep
- delete config.log on clean
a.
--
Andrea Mennucc
"E' un mondo difficile. Che vita intensa!" (Tonino Carotone)
diff -u xarchon-0.50/src/canvas.c xarchon-0.50/src/canvas.c
--- xarchon-0.50/src/canvas.c
+++ xarchon-0.50/src/canvas.c
@@ -288,11 +288,31 @@
XFontStruct *fs;
fs = XLoadQueryFont(display, name);
- if (fs == NULL) {
- fprintf(stderr, "canvas_font_load(): cannot load font `%s'\n", name);
- exit(EXIT_FAILURE);
+ if (fs != NULL)
+ return fs;
+
+ fs = XLoadQueryFont(display, "-misc-fixed-medium-*-normal-*-15-*-*-*-*-*-iso8859-1");
+ if (fs != NULL) {
+ fprintf(stderr, "canvas_font_load() warning: cannot load font `%s', using fallback.\n", name);
+ return fs;
+ }
+
+ fs = XLoadQueryFont(display, "-*-fixed-*-*-*-*-15-*-*-*-*-*-iso8859-1");
+ if (fs != NULL) {
+ fprintf(stderr, "canvas_font_load() warning: cannot load font `%s', using generic fallback.\n", name);
+ return fs;
}
- return fs;
+
+ fs = XLoadQueryFont(display, "fixed");
+ if (fs != NULL) {
+ fprintf(stderr, "canvas_font_load() warning: cannot load font `%s', using fallback `fixed'.\n", name);
+ return fs;
+ }
+
+ fprintf(stderr, "canvas_font_load(): cannot load neither font `%s' , nor any fallback: panic!\n",name);
+ exit(EXIT_FAILURE);
+
+ return NULL; /* not reached */
}
/*--*/
diff -u xarchon-0.50/debian/changelog xarchon-0.50/debian/changelog
--- xarchon-0.50/debian/changelog
+++ xarchon-0.50/debian/changelog
@@ -1,3 +1,9 @@
+xarchon (0.50-10.1) unstable; urgency=low
+
+ * NMU: Bug fix: "Missing font prevents starting new game" (Closes: #111342).
+
+ -- A Mennucc1 <[EMAIL PROTECTED]> Sun, 31 Dec 2006 18:01:46 +0100
+
xarchon (0.50-10) unstable; urgency=low
* Use debian/tmp as a staging directory and use dh_install to move files
diff -u xarchon-0.50/debian/rules xarchon-0.50/debian/rules
--- xarchon-0.50/debian/rules
+++ xarchon-0.50/debian/rules
@@ -26,7 +26,7 @@
-$(MAKE) clean
-$(MAKE) distclean
- rm -f build-stamp config.cache config.status
+ rm -f build-stamp config.cache config.status config.log
dh_clean
diff -u xarchon-0.50/debian/control xarchon-0.50/debian/control
--- xarchon-0.50/debian/control
+++ xarchon-0.50/debian/control
@@ -2,7 +2,7 @@
Section: games
Priority: optional
Maintainer: Daniel Burrows <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 4.0.0), libaudiofile-dev, libesd0-dev, libglib1.2-dev, libgtk1.2-dev, libxpm-dev, x-dev, libx11-dev, libxpm-dev, libxt-dev, libxext-dev, g++ (>= 3:3.2.2-0)
+Build-Depends: debhelper (>= 4.0.0), libaudiofile-dev, libesd0-dev, libglib1.2-dev, libgtk1.2-dev, x-dev, libx11-dev, libxpm-dev, libxt-dev, libxext-dev, g++ (>= 3:3.2.2-0)
Standards-Version: 3.6.1.1
Package: xarchon
signature.asc
Description: Digital signature
Bug#403379: mplayer: segfault while reading an mpeg file
severity 403379 important tag 403379 -security thanks while looking into the fix of the code, I came to the conclusion that this bug could not be exploited w.r.t. security a. signature.asc Description: OpenPGP digital signature
Bug#403398: Bug#402950: FTBFS not fixed
severity 403398 important set 403398 -security thanks Sam Hocevar ha scritto: > >I'm investigating #403398 hi I investigated this issue, and it is (quite likely) not a security one; the crash is of this form: when a I-frame, or an header, is damaged, then mplayer does not allocate memory for motion-compensation and other B-frame stuff, and so it crashes ; at the same time, though, mplayer/ffmpeg is careful that non allocated memory pointers are NULL, so it indeed crashes, but those are really not security problem I discussed (privately), with Moritz, who tonight said: > Ok, in that case they're not release-critical security bugs, but just > regular (severity normal) bugs. We wouldn't issue a DSA neither if Etch were > already released. > > (Feel free to quote me on that for the RMs, I'm away until thursday.) so, here we go anyway, I have patches for that ... you may want to use interdiff to highlight those a. signature.asc Description: OpenPGP digital signature
Bug#403379: strange hypotheses, Re: Bug#403379
I have two hypotheses in mind:
--- hypothesis 1
Aurelien Jarno ha scritto:
> mplayer segfaults on a file I have (probably badly) downloaded from the
> Internet. Note that other video applications in Debian (vlc, kaffeine)
> do not segfault. It is very likely a security problem.
> Sorry, but I don't have the URL anymore, if I remember correctly it was
> a russian site. The original name is d3efc17df8c6b.mpg. This video is
> supposed to show a L298 chip burning. This chip is supposed to be
> thermally protected, but I also burnt one :(
-- hypothesis 2
The file that you sent me is almost similar to the file that Pierre sent
me in bug 402922 : the two files have the same length, and moreover
$ cmp -l mplayer-{8,7}-crash.mpeg | wc -l
4365
a change of 4365 bytes on a total of 224Kb is quite low...
it is so low that it is virtually impossible that those two files are
found independently on the internet
so the second hypothesis is :
you downloaded Pierre example, altered some bytes out of it, until you
found a file that could crash mplayer (but not some other programs)
Even the two bug reports are s similar:
Pierre:
> xine and vlc that use debian libpmeg2 instead do not segfault.
> I'm not 100% sure it's a security problem, but it's very likely.
Aurelien:
> Note that other video applications in Debian (vlc, kaffeine)
> do not segfault. It is very likely a security problem.
--
unfortunately, you cannot find any more the original URL ... so we
cannot really disprove hypothesis 1
whereas, you see , hypothesis 2 is s plausible
a.
signature.asc
Description: OpenPGP digital signature
Bug#403379: closed by A Mennucc1 <[EMAIL PROTECTED]> (Bug#403379: fixed in mplayer 1.0~rc1-9)
Aurelien Jarno ha scritto: > reopen 403379 > thanks > Sorry, but I still have the same problem. Also a debdiff show no code > change between this version and the previous one. I forgot to copy the patch from my -debug tree to my -build tree before debuild (damn it) the patch is not on this PC, but I remember what it was about, so I just recreated the good point is that , on this amd64 box, I can debug also h264 code, so now I am adding some fixes to that too a. signature.asc Description: OpenPGP digital signature
Bug#403379: mplayer: segfault while reading an mpeg file
Aurelien Jarno ha scritto: > mplayer segfaults on a file I have (probably badly) downloaded from the > Internet. Note that other video applications in Debian (vlc, kaffeine) > do not segfault. It is very likely a security problem. > > The file is available here: http://temp.aurel32.net/mplayer.mpeg may you please tell me where you did find that file originally? also, what program did you use to download it? a. signature.asc Description: OpenPGP digital signature
Bug#403379: mplayer: segfault while reading an mpeg file
clone 403379 -1 retitle -1 libavcodec: segfault while reading an mpeg file reassign -1 libavcodec0d found -1 0.cvs20060823-4 thanks Aurelien Jarno wrote: > Package: mplayer > Version: 1.0~rc1-8 > Severity: grave > Tags: security > Justification: user security hole > > mplayer segfaults on a file I have (probably badly) downloaded from the > Internet. Note that other video applications in Debian (vlc, kaffeine) > do not segfault. It is very likely a security problem. > > The file is available here: http://temp.aurel32.net/mplayer.mpeg using gdb, I saw that this is a bug in code that is in libavcodec: 0x0830957d in mpeg_decode_mb (s=0x8765560, block=0x87865e0) at mpeg12.c:1466 1466 s->current_picture.mb_type[ s->mb_x + s->mb_y*s->mb_stride ]= b_type; Then I tried ffmpeg , and it crashes as well. $ ffmpeg -i mplayer.mpeg -target pal-vcd /tmp/vcd.mpg FFmpeg version SVN-rUNKNOWN, Copyright (c) 2000-2004 Fabrice Bellard configuration: --enable-gpl --enable-pp --enable-pthreads --enable-vorbis --enable-libogg --enable-a52 --enable-dts --enable-libgsm --enable-dc1394 --disable-debug --enable-shared --prefix=/usr libavutil version: 0d.49.0.0 libavcodec version: 0d.51.11.0 libavformat version: 0d.50.5.0 built on Sep 25 2006 15:25:04, gcc: 4.1.2 20060901 (prerelease) (Debian 4.1.1-13) Segmentation fault So I am cloning this bug to libavcodec0d a. signature.asc Description: OpenPGP digital signature
Bug#402922: segfault in mplayer own mpeg2 library
set severity normal tag -security tag +pending thanks this was not a security risk here is what I understand MPlayer uses "custom buffers" to drive libmpeg2 (it is a feature of libmpeg2); there is an array of pointers to buffers, called mpi->planes , allocated with calloc(), so they are all zeroed; then a callback is registered into libmpeg2, to allocate those buffers when needed but this stream is broken, there is no I frame, and the first frame is a B frame; when libmpeg2 tries to motion compensate, a buffer related to motion compensation is still not allocated my guess is that other programs do not use "custom buffers", and then they do not crash; still, I will pass my patch to the libmpeg2-4 team btw: AFAICT, MPlayer uses "custom buffers" to support hardware rendering a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402922: segfault in mplayer own mpeg2 library
Pierre Habouzit ha scritto: > xine and vlc that use debian libpmeg2 instead do not segfault. > just for the record: libxine1 ships its own internal version of libmpeg2 it is xineplug_decode_mpeg2.la a. signature.asc Description: OpenPGP digital signature
Bug#402922: segfault in mplayer own mpeg2 library
Pierre Habouzit ha scritto: > FYI, the patch to compile against debian's libmpeg2.a (yes using your > beloved static compiling) is ridiculously small (see attachment). it is also ridiculously useless the MPlayer version of libmpeg2 differs heavily from the one you propose for example, MPlayer adds some postprocessing capabilities; so in libmpeg2/mpeg2_internal.h , in the definition of the structures there are some additional fields; so your 2 line patch will never work you did not even try to diff the two libmpeg to see if there were relevant differences > it has the very very very bad idea to use mpeg2 internals and to deal > with mpeg2dec_t initialization by itself. ...unless this is done to enhance/add features for the code .. a. signature.asc Description: OpenPGP digital signature
Bug#402922: segfault in mplayer own mpeg2 library
On Wed, Dec 13, 2006 at 04:00:02PM +0100, Pierre Habouzit wrote: > Package: mplayer > Version: 1.0~rc1-2 > Severity: grave > Tags: security > Justification: user security hole > > While playing http://madism.org/~madcoder/pub/foobar.mpeg mplayer > segfaults, somewhere in mpeg2_idct_copy_mmx. > > xine and vlc that use debian libpmeg2 instead do not segfault. > > > I'm not 100% sure it's a security problem, but it's very likely. my opinion so far is that this is not a security problem this is my feeling: it may be that the mpeg stream does not contain proper motion-compensate data, or an I frame; libmpcodecs/vd_libmpeg2.c does not detect this, and tries to motion-compensate, and fails. This then would not be a possible path for attack: there is no memory or stack that may be overflown here (but rather there is allocated memory that is then not initialized) a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402922: segfault in mplayer own mpeg2 library
Pierre Habouzit ha scritto:
> On Wed, Dec 13, 2006 at 05:53:03PM +0100, A Mennucc wrote:
>> here is some more info:
>>
>> $ gdb ./mplayer
>> This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db
>> library "/lib/libthread_db.so.1".
>>
>> (gdb) run ~/mplayer/bench/foobar.mpeg
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 47190863550720 (LWP 1368)]
>> MC_put_o_16_mmxext (dest=0xcb5f00 "", ref=0x0, stride=304, height=16)
>> at motion_comp_mmx.c:546
>> 546 movq_m2r (*ref, mm0);
>> (gdb) li
>> 541
>> 542 static inline void MC_put1_16 (int height, uint8_t * dest, const
>> uint8_t * ref,
>> 543const int stride)
>> 544 {
>> 545 do {
>> 546 movq_m2r (*ref, mm0);
>> 547 movq_m2r (*(ref+8), mm1);
>> 548 ref += stride;
>> 549 movq_r2m (mm0, *dest);
>> 550 movq_r2m (mm1, *(dest+8));
>>
>> we should understand why ref==0
>>
>> anyway I will add an assert
>
> O_o *blink* *blink*
>
> do you know that assert is a macro that may be disabled if for some
> reason the build system defines NDEBUG ?!
you are criticizing my way of solving this bug *even before I sit down
and start writing the code*
even supposing that
- I would use assert(ref)
- the code is compiled with NDEBUG
did you consider the fact that I will check my patch against your
foobar.mpeg, in the end, to make sure that it will work?
congratulations! you really know how to go along and collaborate with
other people
(yes that is sarcasm)
a.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402920: mplayer FTBFS with DEB_BUILD_OPTS=debug
you may download the "debug" version of mplayer from http://tonelli.sns.it/pub/mplayer/debug a. signature.asc Description: OpenPGP digital signature
Bug#402922: segfault in mplayer own mpeg2 library
here is some more info:
$ gdb ./mplayer
This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) run ~/mplayer/bench/foobar.mpeg
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47190863550720 (LWP 1368)]
MC_put_o_16_mmxext (dest=0xcb5f00 "", ref=0x0, stride=304, height=16)
at motion_comp_mmx.c:546
546 movq_m2r (*ref, mm0);
(gdb) li
541
542 static inline void MC_put1_16 (int height, uint8_t * dest, const
uint8_t * ref,
543const int stride)
544 {
545 do {
546 movq_m2r (*ref, mm0);
547 movq_m2r (*(ref+8), mm1);
548 ref += stride;
549 movq_r2m (mm0, *dest);
550 movq_r2m (mm1, *(dest+8));
we should understand why ref==0
anyway I will add an assert
a.
signature.asc
Description: OpenPGP digital signature
Bug#402920: mplayer FTBFS with DEB_BUILD_OPTS=debug
severity 402920 normal tag 402920 unreproducible thanks Pierre Habouzit ha scritto: > Package: mplayer > Version: 1.0~rc1-2 your mplayer version is quite old; current one is 1.0~rc1-7 > Severity: serious why? I checked into debian-policy 10.1 : http://www.debian.org/doc/debian-policy/ch-files.html > For this reason, it is recommended to support the > standardized environment variable DEB_BUILD_OPTIONS. DEB_BUILD_OPTIONS is a recommendation of policy, not a requirement. I also found out that "debug" is not in the list of options. See http://bugs.debian.org/157131 I will update that to 'noopt' > > attach is the relevant build log part. > the build was done on an x86 box (not the one I report the bug from). > I cannot rerpoduce this (and I tried on AMD64) a. signature.asc Description: OpenPGP digital signature
Bug#395252: editorial change
Aurélien GÉRÔME ha scritto: > Sorry Andrea, this is really RC (as I always said), but this is also > RC for etch (as I was told on #debian-release). You (and others) say this bug is RC; I (and others) say it is not. It is time we settle this fact for good (etch is frozen). I asked the d-ctte to deliberate ; I opened bug 402772 and put a summary of my point of view ; you may want to write a summary of your p.o.v. a. signature.asc Description: OpenPGP digital signature
Bug#395252: some needed (and long due) clarifications, Re: Bug#395252
It is time to really delve into this. I do not think that this bug is "serious". (I have actually the feeling that the severity for this bug is "wishlist". ) Here are some reasonings: 1) It is true that the debian-policy asks for dynamic compilation, whenever possible; but the MPlayer team deprecate dynamic linking of ffmpeg: dynamic linking is an experimental feature, it breaks many postprocessing options; so it is not really supported. What you are asking for is not a feature currently sported by MPlayer; as such, your request is "severity:wishlist". If you want dynamic linking in MPlayer, you are free to work on it until it works flawlessly, and send me a patch. 2) Never AFAIK was there a "release goal" of "all packages must compile with external ffmpeg" 3) You never opened a serious bug against gst-ffmpeg although gst-ffmpeg is linked with an internal static ffmpeg. And I do not think that you are entitled to claim that severity is "serious". - You are not in the release team. The only person in the release team that ever expressed an opinion in this bug thread is Joey Hess http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=12 and he said that this bug should not be RC - You are not in the development team of MPlayer, and AFAIK you never tried to build/test/improve dynamical linked mplayer (for sure, you did not help me doing that) - You have never brought up a detailed explanation to your claims. Your original claim is "This is hindering the security team and the overall quality of Debian." This is a nice principle to state; but "nice principle" does not immediatly entail "RC" ; quite the opposite, according (1) (2) (3) Indeed, your principle may be applied to many packages and to many situations. For example, we have many web browser around, and there have been a lot of web-related security problems lately; but I did not hear you (or any other) go shouting "hey! we have too many web browser around! This is hindering the security team! Lets kick konqueror out of Debian!" --- Anyway, for sake of discussion, lets suppose that "static ffmpeg is hindering the security team". Suppose in 6months there will be a security problem in ffmpeg: then the MPlayer/FFmpeg team will provide a patch; then the security team will need to apply it. What package will provide the most troubles? Well, the package that is shipping the oldest and more ad-hoc-modified static ffmpeg ... and that is gst-ffmpeg (closely followed by the quite old ffmpeg in Debian ffmpeg). But you (and Muehlenhoff) do not consider that gst-ffmpeg "hinders the security team". Moritz Muehlenhoff writes in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=134 "gst-ffmpeg is indeed an exceptional case, which we'll support for Etch. (That's also why there is no RC bug on it)." (Also, go reread http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=139 it is quite surprising). According to your actions, it seems that the only ffmpeg-related package that "hinders the security team" is MPlayer ! This is nonsensical: of all packages in Debian in this very moment, MPlayer contains the most up-to-date ffmpeg (and then the lest prone to bugs) and the one who will get most help from the MPlayer/FFmpeg. Aurélien GÉRÔME wrote: > Sure, I got that. Fine, the shame on me is my punishment for having > wanted to get a compromise. :) Compromise? I am the guy that does try to find compromises. I am the guy who spent many years to find a compromise to let MPlayer into Debian - in the end, I even agreed to remove mencoder "for fear of patent problems", although most of the encoding stuff is in ffmpeg and that is already in Debian. When you posted this bug, I did not agree with you, but I proposed different options to address it; and discussed with the upstream team (that does not approve dynamical linking); and I prepared new packages for mplayer, xine, and ffmpeg; and I benchmarked it; and tested it on different codecs. All this, even if I do not agree with your definition of severity. That is my spirit of "compromise". Your behaviour is "heh, gst-ffmpeg is fine, but lets bug mplayer guy forever, regardless of any reasoning put forth by him, Joey Hess, MPlayer team, etc etc?". When did you ever tried to find a compromise? I tried to set "severity:important". But your idea of compromise between "severity:serious" and "severity:wishlist" is "severity:serious". Your (repeated) example of compromise is "echo severity serious | mail [EMAIL PROTECTED]". You call that a compromise? Aurélien GÉRÔME wrote: > Sorry Andrea, this is really RC (as I always said), but this is also > RC for etch (as I was told on #debian-release). Quite peculiar. Early in the discussion, Joey Hess reports in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=12 "How is mplayer different than the 200 or so other items listed in embedded-code-copies? Other than only gettin
Bug#395252: bug 395252 & freeze
severity 395252 important thanks hi I am downgrading severity of this bug, for the sake of including MPlayer in the Etch release. Before jumping on horses, please read the motivation. -- Some time ago, I proposed some options for solving this bug. First option [O]: compile MPlayer using FFmpeg as is currently shipped in Debian. I tried this, and it fails: FFmpeg has had much development , and this development is all used inside MPlayer; so compilation fails (in too many places to make this feasible ) . Second option [N]: prepare new FFmpeg Debian packages, and link MPlayer to that. Unfortunately, I tried to contact Sam many many times on this, but he was too busy. So eventually I actually did that myself (as reported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=152 ) At that time, I compiled libxine , and tested a dynamic version of MPlayer and totem-xine and xine-ui (all using this new FFmpeg 0.svn6767) on some files; it all worked surprisingly well. The problem is that, I could then not proceed further: - I did not want to upload into unstable, since we were near freeze , and the above is a major lib upgrade - I did not test it on all archs (I see from Sam's logs and patches that ffmpeg did fail on arm in the past ; but many of Sam's patch do not apply to the newer ffmpeg) - my idea was to upload my work in experimental, to see if it would be autobuilt correctly, and to ask for wider testing in d-devel; but Sam did not answer me when I asked permission I should also recall that dynamic linking of MPlayer to FFmpeg has currently some drawbacks: MPlayer is slower; and some features of MPlayer are disabled; so, a lot more work would be needed to really offer a full featured dynamically linked MPlayer. Now, freeze has come, so there is no more time to do any of the above. -- Please do not upgrade the severity of this bug again; you can see that I honestly tried to address it. Moreover, it took me almost 5 years to get MPlayer into Debian, I would really hate to see it out of Etch. thanks, a. signature.asc Description: OpenPGP digital signature
Bug#395252: new ffmpeg (& xine) & mplayer with shared linking
hi there since time is running, and the general freeze is coming, I have decided to do some work on this bug I have packaged a new version of ffmpeg 0.svn6767 ; I have then built a version of mplayer 1.0~rc1-5 that is dynamically linked to that; moreover I have built a version of libxine using the above ffmpeg. I installed all my creatures, and tried totem-xine and mplayer on a few files, and they seem to work. You find them programs at http://tonelli.sns.it/pub/mplayer/experimental-shared/ (compiled for amd64 ; I will add builds for i386 later) Caveats: 1) many patches from the old ffmpeg 0.cvs20060823-4 do not apply; a few I have corrected, but some I could not , so I have simply disabled them. I really need help from Sam on this issue (maybe some patches are useless with the newer code?) If Sam can review my work on ffmpeg, then we upload all the above stuff into the experimental repo and ask for help in testing it. 2) Diego told me that compiling MPlayer with a shared ffmpeg disables some parts of MPlayer , and makes it slower (we will work on this) a. signature.asc Description: OpenPGP digital signature
Bug#395252: embedded code copies are not RC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Tartler ha scritto: > xine is able to build against an out of tree ffmpeg. This is what the > current xine in etch is doing. (I was aware of this; I hope I made it clear in previous emails ) > So far, I'm not aware of any regressions > yet. I am aware that an updated ffmpeg could introduce regression. > Therefore I rely that Sam will bump the SONAME of the libraries when he > updates an incompatible version of ffmpeg in debian. (disclaimer: I am not expert of SONAME details, so please bear any error) there may be a misunderstanding here AFAIU the whole point that is asked by Aurélien GÉRÔME and Moritz Muehlenhoff is that there should be less copies of ffmpeg around I try to clarify things: currently $ objdump -p /usr/lib/libavcodec.so.0d.51.11.0 | grep SONAME SONAME libavcodec.so.0d Suppose Sam packs a new FFMpeg package from current SVN, and, since it is is incompatible with xine and other sw already using libavcodec0d , it puts it in binary libavcodec1d and gives it a SONAME of libavcodec.so.1d; then I may link MPlayer with that lib, with no fear of breakage. But this would not solve the original question of having one less copy of ffmpeg around, right? unless also all other sw would be modified to work with the new libavcodec.so.1d , and libavcodec0d is removed from etch. so again: > Therefore I rely that Sam will bump the SONAME of the libraries when > he updates an incompatible version of ffmpeg in debian. would you then update/patch xine to link with that ? how feasible is that ? (e.g. is there an upstream version of xine using a newer ffmpeg? ) a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFThnd9B/tjjP8QKQRAlecAJ9mD5qC4uuwEtfssELCPFC3QQES4gCcD+hX MGOdODaMxRutWdjzYaWg3Do= =K2WJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396646: mplayer: no permission to modify or redistribute mmx.h
severity 396646 normal retitle 396646 clarify and tidy up copyrights thanks ciao On Wed, Nov 01, 2006 at 11:23:43PM +0100, Francesco Poli wrote: > There seems to be still a licensing issue, though... :-( > According to its debian/copyright[1], mplayer includes a file named > mmx.h . > Where's the permission to redistribute (DFSG#1)? > Where's the permission to modify (DFSG#3)? that file is part of a library that was made public; unfortunately all the original web pages (as found by Google) http://min.ecn.purdue.edu/~rfisher/Career/vita.html http://shay.ecn.purdue.edu/~swar/libMMX/Index.html http://eetpc20.bd.psu.edu/~rfisher/ are currently unavailable; anyway you can get info from the Google cache. you may also download the library from http://fresh.t-systems-sfr.com/linux/src/libmmx-990416.tgz I read it all around: it is true that there is no place where the authors explicitely state "you can redistribute this code at wish"; but at the same time the authors -) put the .tar.gz in their web pages -) wrote a public-domain-like statement in the code -) wrote 'Copying-policy: PD' inside libmmx.lsm -) go to great length in explaining how to use their code in other applications I really do not think that they intended to give permission to use the code as public domain, but not permission to (re)distribute it. Moreover, according to http://www.google.com/codesearch?hl=en&lr=&q=Dietz+Fisher&btnG=Search code from that library is also part of xine, VLC, avidemux, mythtv, ffmpeg, gstreamer; since it is not considered a problem in any of those, then it must be OK in mplayer too. > BTW, there's another issue: the debian/copyright[1] file states: > > | Name: GSM 06.10 library . > The term "use" is vague and could be interpreted in a strict sense > as meaning only "to run" or "to execute" the library. > This license should be clarified: persuading upstream to change > the first line in > > ] Any reproduction and use of this software, with or without modification, > ] is permitted provided that this notice is > > would suffice to make it unambiguously DFSG-free. I will do that. a. ps: when I wrote debian/copyright, I was overzealous: I included copyright statement of any bit of code and header around; but I then found this reference http://games.slashdot.org/comments.pl?sid=199749&cid=16359141 that I summarize here as The GPL is only required (i.e., only applicable) when copyright is involved; i.e., making a derivative work. For there to be a derivative work, there has to be a copying within the ambit of the copyright act. If you look to the Altai test (adopted by pretty much every court), you'll see that code dictated by external requirements (i.e., pretty much every piece of software running on a UNIX/Linux system has to use malloc, etc., and thus must either call the system calls directly or via the C Library) is specifically filtered out of the copyright comparison. So any interface calls, even symbols brought in from include files, are [strongly] arguably not even copyrightable (a 'method of operation'; see, e.g., 17 U.S.C. 102, and Lotus v. Borland, 49 F.3d 807 (1st Cir. 1995)) and even if they are, would be stripped out of any comparison of code done in an infringement action. Absent an infringement, there's no need for GPL applicability... So it seems that small bits of header code is not copyrightable. (I do not know if this would apply to mmx.h , though : that contains some real function code) The Altai test is here: http://en.wikipedia.org/wiki/Computer_Associates_Int._Inc._v._Altai_Inc. a. -- Andrea Mennucc signature.asc Description: Digital signature
Bug#395252: embedded code copies are not RC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 BTW: I have been assuming that Moritz is reporting the consensus of the whole security team , and not only his personal opinion... is it so? whereas Joey reported the opinion of the release people (that was not opposite to [A]) I personally may embrace option [N] but I am not so happy about [O] ... and upstream is not either. Now I really need to hear the opinion of the xine and ffmpeg Debian people (and also of gstreamer and any other package using ffmpeg) about [N] a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFR9so9B/tjjP8QKQRAvFgAJ9G3aRwe9l8QlwKci3BunVug+O88wCgoeHg jPE/dMModloRZ8tLFcadg+Y= =DJYf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395252: embedded code copies are not RC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi I would like to add my 2¢ (although Dario's email pretty much says it all) Here are 3 possible scenarios: [N] The safest way to linking MPlayer with dynamical FFmpeg would be : each time there is a MPlayer release, Diego provides us with the correct SVN release number for FFmpeg, and both the proper mplayer and ffmpeg package are uploaded into Debian at the same time. [O] we forcibly link MPlayer to the older FFmpeg. To do this, we would need to extensively patch the version of MPlayer in Debian. In practice, we would break MPlayer, as people expect it to be: many features that are into 1.0rc1 are due to the new ffmpeg, and they would be lost. [A] We leave things as they are now. MPlayer links tonew FFmpeg inside it; ffmpeg outside is left unchanged (...we are near the freeze...). Some comments: Sam Hocevar (mantainer of ffmpeg) in March had expressed concerns similar to that in the bug; I have then contacted him to hear also his opinion about [N] (I did yet not receive a response). The problem of [N], as Diego was pointing, is that FFmpeg does not have a solid API yet. We cannot exclude that an update of FFmpeg may break Xine, or other packages. I checked that xine ships a old and patched FFmpeg library inside, but the Debian package is currently linked to the external FFmpeg ; whereas the version of FFmpeg that is inside MPlayer is even newer. I have contacted Siggi Langauf (mantainer of Xine) to hear his opinion as well (I did yet not receive a response). The overhead [O] may simply be not worth the (supposed) future benefit for security. Since the development of FFmpeg is done jointly with the development of MPlayer , then a security bug in FFmpeg will be fixed in upstream MPlayer before than in any other package using FFmpeg. In case [O] , applying the fix would require sorting also thru our patches (and we cannot even ask help upstream !). In case [N] , it may be the case that the fix is more easier to apply. In case [A] , we have double work to do (but I will take care of the fix for MPlayer, I promise :-) So I think that [O] is not worth the effort: we ruin MPlayer (for sure) for hope of a (not sure) benefit in security. (I really want to abide to (4): We will be guided by the needs of our users and the free software community. ) [N] is too far fetched So here is my proposal: let us stick with [A], and downgrade this bug for the time of the Etch release; in a year or so, it may be that FFmpeg will be stable enough that we really can try [N] for the next release. a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFR82c9B/tjjP8QKQRAkLqAJ9wY4dUjlKAWV19O9Z9kdFtoLAnswCfXK0i DhgvIpEc+oxgkV8rbYfoCRA= =xpc5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395152: NMU diff
thanks, go ahead a. On Fri, Oct 27, 2006 at 08:00:23PM +0100, Neil Williams wrote: > This is the NMUdiff that I propose to upload to fix the RC bug due to > the automake transition. > > -- > > Neil Williams > = > http://www.data-freedom.org/ > http://www.nosoftwarepatents.com/ > http://www.linux.codehelp.co.uk/ > > diff -u printtool-4.5/debian/changelog printtool-4.5/debian/changelog > --- printtool-4.5/debian/changelog > +++ printtool-4.5/debian/changelog > @@ -1,3 +1,10 @@ > +printtool (4.5-9.1) unstable; urgency=low > + > + * Non-maintainer upload. > + * FTBFS: Cannot satisfy Build-Depends on automake (Closes: #395152) > + > + -- Neil Williams <[EMAIL PROTECTED]> Fri, 27 Oct 2006 19:15:20 +0100 > + > printtool (4.5-9) unstable; urgency=low > >* re bug 186063 "Printtool hangs with tk8.4": I cannot reproduce this > diff -u printtool-4.5/debian/control printtool-4.5/debian/control > --- printtool-4.5/debian/control > +++ printtool-4.5/debian/control > @@ -1,7 +1,7 @@ > Source: printtool > Section: admin > Priority: extra > -Build-Depends-Indep: debhelper, automake > +Build-Depends-Indep: debhelper, automake1.4 > Maintainer: A Mennucc1 <[EMAIL PROTECTED]> > Standards-Version: 3.0.1 > > -- Andrea Mennucc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354650: new lightspeed
Hi the new lightspeed 1.2a-6 in unstable uses libgtkgl2.0-dev and GTK2 ; according to the bug submitter, the new lightspeed works fine. So this bug is not grave any more ( since 'grave' means 'renders package unusable', but the package 'lightspeed' is not affected by this bug anymore) a. signature.asc Description: Digital signature
Bug#354650: fixing bug 354650
hi everybody as a prospective Release Assistant, I am in charge of seeing that this bug 354650 be fixed somehow I see that this is now considered to be a bug in libgtk1.2 ... is it really worthy to spend a lot of time debugging it, since libgtk1.2 is obsolete and not mantained upstream? so here is a possible line of action: I can (probably) modify lightspeed to use libgtkgl2.0-dev and GTK2 ; after this, the bug 354650 severity may be set to "normal". What do you think? a. -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) signature.asc Description: Digital signature
