Bug#820583: Another lengthy delay
Earlier, Jasper Wallace asked whether "this one of those situations where some unfortunate volunteer has ended up becoming critical security infrastructure?" The current flash security update (from 616 to 621) is now two weeks overdue from the upstream site, and the player has been blacklisted for several days from Iceweasel. Please, please, can we have discussions to bring additional people or automation into this security infrastructure? There were volunteers in other bug reports. Bart's work is most appreciated (I certainly appreciate it) but that shouldn't preclude other people helping to ensure timeliness.
Bug#820583: Bug 820583 flashplugin-nonfree
Today the missing signature file preventing update of the nonfree flash was added to https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/ enabling updates -- eight (8) days after the publication of a CVE and five (5) days after detection of an exploit in the wild. Could this be a learning opportunity? Bart is doing a yeoman's service in volunteering to provide a secure delivery mechanism for flash -- a non-free component none of us are happy with, but unfortunately one still requiring installation for many. I'd recommend some mechanism for automating the signature generation or the addition of co-maintainers or a specific mechanism for the security team (which understandably doesn't want to touch non-free software) to do NMU alterations, not to the package, but to the area where the signatures are kept. As always, thanks to DD Bart for his contributions to Debian.
Bug#784301: autofs: BROWSE_MODE in /etc/default/autofs no longer honored. nobrowse in auto.master is.
Package: autofs Version: 5.0.8-2 Severity: normal Dear Maintainer, As in title, the default setup for an NIS auto.master map is now browse, not nobrowse. Debian overrides the internal default with the ordinary system /etc/default/autofs BROWSE_MODE entry, which after an upgrade to jessie is no longer honored. However, the problem is not internal to autofs because placing the nobrowse option in auto.master corrects the problem: perhaps in the scripts which instantiate autofs? Perhaps systemd-transition related? -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages autofs depends on: ii libc6 2.19-18 ii libxml22.9.1+dfsg1-5 ii multiarch-support 2.19-18 ii ucf3.0030 Versions of packages autofs recommends: ii kmod 18-3 ii module-init-tools 18-3 ii nfs-common 1:1.2.8-9 autofs suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783573: python-astropy: Missing file prevents SAMP functionality in astropy from working
Package: python-astropy Version: 0.4.2-2 Severity: important Tags: newcomer The use of SAMP functionality to talk to virtual-observatory applications such as Aladin, Topcat, etc, is supported through the astropy.vo.samp part of astropy. However, instantiating a client or server, e.g. for the former: from astropy.vo.samp import SAMPIntegratedClient produces an exception because the file /usr/lib/python2.7/dist-packages/astropy/vo/samp/data/astropy_icon.png is not found. This is a packaging error. It also applies to the version in experimental (1.0-1~exp) and the python3-astropy modules. -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-astropy depends on: ii libc6 2.19-18 ii libcfitsio2 3.370-2 ii liberfa1 1.1.1-1 ii libexpat1 2.1.0-6+b3 ii libwcs4 4.24-1 ii python2.7.9-1 ii python-numpy [python-numpy-abi9] 1:1.8.2-2 pn python:any python-astropy recommends no packages. Versions of packages python-astropy suggests: ii libxml2-utils 2.9.1+dfsg1-5 pn python-astropy-doc pn python-h5py ii python-scipy0.14.0-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#617315: xml-core: prerm/postinst scripts modify /usr/local in violation of debian policy
Package: xml-core Version: 0.13 Severity: important Upgrade to Squeeze on systems with remote RO mounted /usr/local fail at xml- core upgrade because of prerm/postinst scripts noodling with /usr/local. -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xml-core depends on: ii sed 4.2.1-7The GNU sed stream editor ii sgml-base 1.26+nmu1 SGML infrastructure and SGML catal xml-core recommends no packages. Versions of packages xml-core suggests: ii debhelper 8.0.0 helper programs for debian/rules -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#418016: More software broken by libx11-6 (1.0.3-7) upgrade
Essentially every version (5.5, 5.6, 6.0, 6.1, 6.2) of the proprietary (sigh, I know) data analysis package IDL (rsinc.com) segfaults when trying to draw a simple bitmap (the IDL statement "tv,dist(5)" reproduces the bug). Considering that, e.g. IDL 5.5 has run on everything from RH7.3 forwards, this change seems to amount to, in practice, a significant ABI change. There is a *lot* of buggy software out there, not all of which can be patched. The X protocol is one of those things that has "simply worked" for binaries going back to the old times. Keeping odd bits of its past behavior would seem to be well advised. Making this sort of intrusive change in a core system library just before the Etch release is perhaps not the most advisable course of action. For now, I've backed our scientific data systems back to 1.0.3-6. (freenx on top of the nomachine libraries, by the way, also breaks at 1.0.3-7) Don Barry Cornell Astronomy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
