Bug#846051: swig build-depends on php5-cgi and php5-dev
Source: swig Version: 3.0.10-1 Severity: serious swig build-depends on php5-cgi and php5-dev Only PHP 7 will be in stretch.
Bug#844574: RFA: hexchat -- IRC client for X based on X-Chat 2
Control: owner -1 ! Control: retitle -1 ITA: hexchat -- IRC client for X based on X-Chat 2 On Wed, Nov 16, 2016 at 05:51:03PM -0700, Jesse Rhodes wrote: > I request an adopter for the hexchat package. I'm up for adopting it. > My life situation is very different than it was when I first started > maintaining hexchat. Despite a few efforts to keep it going anyway, I have > determined that I don't have enough time to devote to this and do it > properly. Thanks for doing it properly and not let the package rot! Be happy with whatever life brought to you! Also, be aware that I'll always be happy to land it over to you again if you'll ever come back! :) > Thanks. This is a good program with a pretty wide userbase and it should > stay in the archive. Definitely. I use it. A lot. I want it to stay in the archive, and stay well ^^ -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201
Hello, intrigeri: > Gabriel Filion: > >> […] and found out that xserver-xorg-core version 1.18.3-2 was >> introducing this issue. Downgrading to 1.18.3-1 makes the visual flashes and >> hard crashes go away. > > /usr/share/doc/xserver-xorg-core/NEWS.Debian.gz reads: > > xorg-server (2:1.18.3-2) unstable; urgency=medium > > X now defaults to using built-in modesetting video driver on Intel > hardware which is "4th gen GMA" and newer, so roughly speaking on hardware > from 2007 and up. If this triggers new bugs on your hw, please file them > against the xserver. > > Continuing to use the -intel driver is possible by dropping the template > xorg.conf to /etc/X11: > > # cp /usr/share/doc/xserver-xorg-video-intel/xorg.conf /etc/X11 > > -- Timo Aaltonen Tue, 19 Jul 2016 04:28:05 +0300 > > So perhaps the modesetting video driver breaks things on your system. > Can you please try switching back to the -intel driver with 2:1.18.3-2 > or newer? I'm sorry for this big delay, but I've finally taken the time to test this out. I can confirm that the visual glitches and crashes are still present in the latest version of the package, 2:1.19.0-2. Also, when using the above-mentioned technique for forcing the driver to "intel" (I've confirmed that it loaded by looking at ~/.local/share/xorg/Xorg.log.0), I don't see visual flashes anymore. signature.asc Description: OpenPGP digital signature
Bug#841500: gcc-6: Unable to compile upstream kernel with previous .config
On Mon, 31 Oct 2016 07:19:56 +0100 Klaus Ethgen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Do den 27. Okt 2016 um 9:20 schrieb Eric Valette: > I have reverted to 6.2.0-6 anyway using testing as a source for the gcc > package. But that will work as long as the "broken for kernel" gcc does not > enter testing. So please find a way to prevent this compiler entering > testing until this is resolved. Too late. It went already to testing as inbetween the severity was set to normal and now we have the broken package in testing. Regards Klaus - -- Klaus Ethgen It is fixed for vanilla kernel.org kernel as of 4.8.11, builds on Sid without modification. External modules I could test build fine too (including Nvidia via dkms). Do not apply any previously suggested workarounds on top or the resulting kernel will not boot. Cheers.
Bug#845536: [PATCH] gbp clone: configure user.email from DEBEMAIL
Hi Michael, thanks for working on this. On Sat, Nov 26, 2016 at 07:17:59PM +0100, Michael Stapelberg wrote: > On Fri, Nov 25, 2016 at 2:08 PM, Guido Günther wrote: > > > control: forecmerge 679121 -1 > > > > This should have read “forcemerge”, I assume. I’ll let you correct that and > just reply to this bug for now. No worries, the bts told me too so it's merged already. > > control: tags 679121 -patch > > > > Hi Michael, > > thanks for the patch! I think we're heading in the right direction. > > > > On Thu, Nov 24, 2016 at 12:26:19PM +0100, Michael Stapelberg wrote: > > > Package: git-buildpackage > > > Version: 0.8.6 > > > Severity: wishlist > > > Tags: patch > > > > > > I realize that https://bugs.debian.org/679121 is similar. In case you > > > prefer to close this issue in favor of #679121, please update #679121 > > > with a clear decision as to how honouring DEBFULLNAME and DEBEMAIL in > > > git-buildpackage should be implemented, and I’ll be happy to follow up. > > > > > > Until that’s worked out, I’d like to propose a slightly different > > > approach which I have been using for years: at clone-time, I set > > > user.email to my debian email address. > > > > The main reason 679121 is still open is that it wasn't clear to me where > > exactly gbp should use DEBEMAIL/DEBFULLNAME and where not but what you > > propose makes sense: use it everywhere gbp creates repos to set up sane > > defaults: > > > > * gbp clone > > * gbp import-dsc > > * gbp ipmort-srpm > > > > But we need to make it configurable and add a test to make sure we don't > > break it in the future (e.g. in tests/component/deb/test_clone.py). > > > > Makes sense to me. > > I’ve updated the patch (see attachment) to cover gbp clone, gbp import-dsc > and gbp import-srpm. I have also added a test in test_clone.py, as you > suggested. > > With regards to configuration, could you please tell me how you’d like the > option to be called? You’re more familiar with git-buildpackage and hence > can give a recommendation for a consistent option name :). I don't have a great suggestion for that one but given that we might have several ways to init the _user_ for the new _repo_ in the future something like: --repo-user=DEBIAN : use debemail --repo-user=GIT: let git figure out what to do make sense to me. That would allow for other setup modes like--repo-user=rpm or --repo-user=matching (DEB* for the debian tools and something else for the rpm tools) in the future. The uppercase allows to distinguish this from --repo-user="Foobar" easily in case we want to allow to set an explicit user name in the future. S.th. like parser.add_config_file_option(…, choices=['DEBIAN', 'GIT']) Does this make sense? > Let me know if anything else should be changed in the patch, or feel free > to apply it and change it yourself as you see fit. Pleae see below. > > > > Cheers, > > -- Guido > > > > > > > > Please consider merging the attached patch. Thank you! > > > > > > -- System Information: > > > Debian Release: stretch/sid > > > APT prefers testing > > > APT policy: (990, 'testing'), (500, 'unstable') > > > Architecture: amd64 (x86_64) > > > Foreign Architectures: i386, armel, mipsel > > > > > > Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores) > > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > > > Shell: /bin/sh linked to /bin/dash > > > Init: systemd (via /run/systemd/system) > > > > > > Versions of packages git-buildpackage depends on: > > > ii devscripts2.16.7 > > > ii git 1:2.9.3-1 > > > ii man-db2.7.5-1 > > > ii python-dateutil 2.4.2-1 > > > ii python-pkg-resources 25.2.0-1 > > > ii python-six1.10.0-3 > > > pn python:any > > > > > > Versions of packages git-buildpackage recommends: > > > ii cowbuilder 0.80 > > > ii pbuilder 0.225.2 > > > ii pristine-tar 1.34 > > > ii python-requests 2.10.0-2 > > > ii sbuild 0.71.0-2 > > > > > > Versions of packages git-buildpackage suggests: > > > pn python-notify > > > ii sudo 1.8.17p1-2 > > > ii unzip 6.0-20 > > > > > > -- no debconf information > > > > > >From 9d4f3ae0b3a783e8c96f1e83c9c2192c4fe0b56c Mon Sep 17 00:00:00 2001 > > > From: Michael Stapelberg > > > Date: Thu, 24 Nov 2016 12:17:50 +0100 > > > Subject: [PATCH] gbp clone: configure user.email from DEBEMAIL > > > > > > --- > > > gbp/git/repository.py | 10 ++ > > > gbp/scripts/clone.py | 3 +++ > > > 2 files changed, 13 insertions(+) > > > > > > diff --git a/gbp/git/repository.py b/gbp/git/repository.py > > > index 2f1b71b..d30ec07 100644 > > > --- a/gbp/git/repository.py > > > +++ b/gbp/git/repository.py > > > @@ -1063,6 +1063,16 @@ class GitRepository(object): > > > raise KeyError > > > return value[0][:-1] # first line with \n ending removed > > > > > > +def set_user_email(self, email): > > > +""" > > > +Set
Bug#846049: Acknowledgement (icedove: SIGSEGV in JSObject2WrappedJSMap::UpdateWeakPointersAfterGC)
Maybe this is related: https://bugzilla.mozilla.org/show_bug.cgi?id=1223078 Did the problems with Thunderbird / Icedove start after November 2015 with that code change? Stefan
Bug#846025: firebird3.0: FTBFS (segfaults during build)
Control: tags -1 confirmed -=| Santiago Vila, 27.11.2016 23:02:25 +0100 |=- > Package: src:firebird3.0 > Version: 3.0.1.32609.ds4-10 > Severity: serious > > Dear maintainer: > > I tried to build this package in stretch with "dpkg-buildpackage -A" > (which is what the "Arch: all" autobuilder would do to build it) > but it failed: > > tables=$( echo "show tables;" | FIREBIRD_BOOT_BUILD=true > FIREBIRD=debian/firebird-image > LD_LIBRARY_PATH=debian/firebird-image/lib > FIREBIRD_MSG=debian/firebird-image debian/firebird-image/bin/isql > -user SYSDBA debian/firebird-image/examples/empbuild/employee.fdb > ) && \ > for table in $tables; do \ > echo "select * from $table;" | FIREBIRD_BOOT_BUILD=true > FIREBIRD=debian/firebird-image LD_LIBRARY_PATH=debian/firebird-image/lib > FIREBIRD_MSG=debian/firebird-image debian/firebird-image/bin/isql -user > SYSDBA -e debian/firebird-image/examples/empbuild/employee.fdb ; \ > done > Segmentation fault > debian/rules:166: recipe for target 'build-firebird-stamp' failed Thanks. I am able to reproduce this in a stretch virtual machine. Building in stretch chroot on sid machine passes (as well as on sid chroot with sid kernel -- that explains the all-green autobuilders in sid), so I guess the kernel version is involved in the breakage. Next thing to try is building with upgraded build-deps from sid hoping that a simple bump of the build-dep will solve this. Fiddling with compiler flags will follow. -- Damyan signature.asc Description: Digital signature
Bug#846050: libvirt-daemon-system: Cannot create VM - cannot load AppArmor profile
Package: libvirt-daemon-system
Version: 2.4.0-1+b1
Severity: normal
Dear Maintainer,
Trying to create a virtual machine using Virt-Manager interface OR import any
existing using "virsh define *.xml" result in:
Unable to complete install: 'internal error: cannot load AppArmor profile
'libvirt-xxx--'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/create.py", line 2288, in
_do_async_install
guest.start_install(meter=meter)
File "/usr/share/virt-manager/virtinst/guest.py", line 461, in start_install
doboot, transient)
File "/usr/share/virt-manager/virtinst/guest.py", line 396, in _create_guest
self.domain = self.conn.createXML(install_xml or final_xml, 0)
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3773, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error: cannot load AppArmor profile 'libvirt-xxx-
-'
It is brand new fresh Stretch install with apparmor enabled following Wiki.
there are no files created under /etc/apparmor.d/libvirt or any log errors
different from the above.
Cannot create any new VMs. This Debian Stretch brand new install fully updated
(stretch only, sid is pinned at -10).
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libvirt-daemon-system depends on:
ii adduser 3.115
ii gettext-base 0.19.8.1-1
ii init-system-helpers 1.46
ii libapparmor1 2.10.95-6
ii libaudit11:2.6.7-1
ii libblkid12.29-1
ii libc62.24-5
ii libcap-ng0 0.7.7-3
ii libdbus-1-3 1.10.12-1
ii libdevmapper1.02.1 2:1.02.136-1
ii libnl-3-200 3.2.27-1
ii libnl-route-3-2003.2.27-1
ii libnuma1 2.0.11-2
ii librados20.80.11-1.1
ii librbd1 0.80.11-1.1
ii libselinux1 2.6-3
ii libvirt-clients 2.4.0-1+b1
ii libvirt-daemon 2.4.0-1+b1
ii libvirt0 2.4.0-1+b1
ii libxml2 2.9.4+dfsg1-2.1
ii libyajl2 2.1.0-2
ii logrotate3.8.7-2
ii policykit-1 0.105-17
Versions of packages libvirt-daemon-system recommends:
ii bridge-utils 1.5-10
ii dmidecode 3.0-4
ii dnsmasq-base 2.76-4
ii ebtables 2.0.10.4-3.5
ii iproute2 4.8.0-1
ii iptables 1.6.0-4
ii parted3.2-16+b1
Versions of packages libvirt-daemon-system suggests:
ii apparmor2.10.95-6
ii auditd 1:2.6.7-1
ii nfs-common 1:1.2.8-9.2
pn pm-utils
pn radvd
ii systemd 232-6
pn systemtap
pn zfsutils
-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/allow-arp.xml'
/etc/libvirt/nwfilter/allow-dhcp-server.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/allow-dhcp-server.xml'
/etc/libvirt/nwfilter/allow-dhcp.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/allow-dhcp.xml'
/etc/libvirt/nwfilter/allow-incoming-ipv4.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/allow-incoming-ipv4.xml'
/etc/libvirt/nwfilter/allow-ipv4.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/allow-ipv4.xml'
/etc/libvirt/nwfilter/clean-traffic.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/clean-traffic.xml'
/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-spoofing.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/no-arp-spoofing.xml'
/etc/libvirt/nwfilter/no-ip-multicast.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/no-ip-multicast.xml'
/etc/libvirt/nwfilter/no-ip-spoofing.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/no-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-mac-broadcast.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/no-mac-broadcast.xml'
/etc/libvirt/nwfilter/no-mac-spoofing.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/no-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-other-l2-traffic.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/no-other-l2-traffic.xml'
/etc/libvirt/nwfilter/no-other-rarp-traffic.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/no-other-rarp-traffic.xml'
/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml [Errno 13] Permission denied:
u'/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml'
/etc/libvirt/nwfilter/qemu-announc
Bug#845997: mate-session-manager: should use alternatives priority 40 for /usr/bin/mate-session
Hi Wolfgang, hi all, On So 27 Nov 2016 16:52:38 CET, Wolfgang Schweer wrote: Source: mate-session-manager Version: 1.16.0-1 Severity: important User: debian-...@lists.debian.org Usertag: debian-edu Hi, sitting here in Oslo testing Debian Edu stretch, we noticed that an installation with 'desktop=mate' ended up in a system with Plasma as default session. One reason seems to be the wrong priority for /usr/bin/mate-session (value 30). Plasma is the winner in automatic mode cause /usr/bin/startkde has the value 40. So please use priority 40 to make automatic mode working correctly with update-alternatives. Wolfgang When looking at this: 0/usr/bin/razor-session50auto mode * 1/usr/bin/impressive-display 20manual mode 2/usr/bin/internet-kiosk-browser 20manual mode 3/usr/bin/lxsession49manual mode 4/usr/bin/mate-session 30manual mode 5/usr/bin/openbox-session 40manual mode 6/usr/bin/razor-session50manual mode 7/usr/bin/startkde 40manual mode 8/usr/bin/startlxde50manual mode 9/usr/bin/startxfce4 50manual mode 10 /usr/bin/xfce4-session40manual mode (taken from a Debian jessie system)... I'd say we set prio to 50 rather than 40. Comments? Feedback? Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgp6JWcuJUjZJ.pgp Description: Digitale PGP-Signatur
Bug#846048: RFS: yasnippet/0.11.0-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for an ITA of yasnippet. * Package name: yasnippet Version : 0.11.0-1 Upstream Author : João Távora * URL : https://github.com/joaotavora/yasnippet * License : GPL-3+ Section : lisp Download with dget: dget -x https://mentors.debian.net/debian/pool/main/y/yasnippet/yasnippet_0.11.0-1.dsc Or from git: gbp clone --pristine-tar https://anonscm.debian.org/git/pkg-emacsen/pkg/yasnippet.git cd yasnippet git checkout c111fef485242fb85387ffbd503d466bd90c8516 gbp buildpackage Changes since the last upload: [ Sean Whitton ] * New upstream release (Closes: #845061). * Adopt package on behalf of pkg-emacsen team. This has been approved by the de facto maintainer, Barak A. Pearlmutter. - Replace Julián Hernández Gómez with pkg-emacsen team as Maintainer. - Add myself as an uploader. - Add myself to d/copyright file for debian/. - Update copyright years for Barak A. Pearlmutter. * Convert package to use dh_elpa (Closes: #671584, #818440). - Build 'elpa-yasnippet' binary package. - 'yasnippet' now a transition binary package. - Rewrite d/rules. - Add d/elpa-yasnippet.elpa & d/elpa-test control files. - Replace build dependency on Emacs with build dependency on dh-elpa. - Add build dependency on yasnippet-snippets for test suite. - Drop debian/emacsen-*. - Update doc-base registration. * Add 0003-Debian-yas-installed-snippets-dir.patch (Closes: #818699). * Add missing build dependency on emacs-goodies-el. The documentation build process can optionally use htmlize.el. The version of htmlize.el present in emacs-goodies-el is currently too old for this to work, but adding the build dependency now will make this work as soon as emacs-goodies-el is updated. * Bump debhelper compat & dependency to 10. * Update homepage field. * Add Testsuite: field. * Fix typo in package description. * Add debian/clean. * Bump standards version to 3.9.8 (no changes required). * Run wrap-and-sort -abst. [ Barak A. Pearlmutter ] * Drop 0001-Deal-with-the-invalid-function-quote-error-when-gene.patch Merged upstream. * Refresh 0002-Avoiding-having-git-as-a-building-dependency.patch * Add 0001-typos-and-grammar.patch Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#825487: Another situation where this change would help
Hello, I observed today that `dpkg -i` can fail to install a new binary package and its transitional dummy package, whereas `apt-get install ./foo.deb ./bar.deb` succeeds. -- Sean Whitton signature.asc Description: PGP signature
Bug#845061: yasnippet: Broken with emacs25
Hello Alberto, On Tue, Nov 22, 2016 at 07:32:50AM -0700, Sean Whitton wrote: > dh_elpa definitely installs the package and creates the symbolic links. > The only issue is the startup file, 50yasnippet.el. I'm talking to the > original author of dh_elpa about that (join us in #debian-emacs if you > can). This is now resolved in git. > I'm wondering whether we should have a separate package, yasnippet-doc, > containing the HTML documentation. What do you think? I no longer this this is a good idea -- the installed documentation is tiny. -- Sean Whitton signature.asc Description: PGP signature
Bug#771891: Removing the cache not a good workaround
I disagree that this issue is not serious since there is a workaround. If the cache needs to be deleted every time you want to access your email, it basically makes the program unusable as an IMAP client. Also, sometimes certain emails do not appear in the inbox even after deleting the cache. They are just silently discarded, and the user might be totally unaware of the messages unless he accesses the IMAP account with some other MUA such as mutt. Any ideas how to help debug this further?
Bug#846045: python-pytest-benchmark: fixture is not detected by pytest
Package: python-pytest-benchmark Version: 3.0.0-1 Severity: serious Hello, I am trying to run build-time tests for one of my packages where upstream just switched to pytest. The benchmark module does not get loaded (as verified by running `python2 -m pytest --traceconfig` after installing python-pytest-benchmark), so the tests fail with the error "fixture 'benchmark' not found". I see that the plugin for Python 3 does get detected, so the problem is strangely specific to just the Python 2 version of the package (which is what this bug report is for). I tested another packaged pytest module on Python 2, python-pytest-django, and I see that it's detected properly. The problem does not therefore seem to be with the Python 2 version of pytest. Many thanks and regards Afif
Bug#846044: apt: Don't display all solutions for apt-cache rdepends
Package: apt Version: 1.4~beta1 Severity: minor Dear Maintainer, I think it would make more sense not to print other packages that provide the given packages when doing rdepends. This happens in apt-private/private-depends.cc on lines 111-127. I was checking what depended on notification-daemon, which is a package, but also other packages provide it. The command `apt-cache rdepends --installed notification-daemon` repeatedly lists the packages that provide notification-daemon (dunst, ..., xfce4-notifyd) with only a few actual reverse dependencies throughout. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "i386"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^linux-headers-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^gnumach-image-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^.*-modules-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^.*-kernel-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.8\.0-1-686-pae$"; APT::NeverAutoRemove:: "^linux-tools-4\.8\.0-1-686-pae$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Architectures ""; APT::Architectures:: "i386"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--format=lzma"; APT::Compressor::lzma::UncompressArg:: "-d"; Dir "/"; Dir::State "var/lib/apt"; Dir::State::lists "lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::mirrors "mirrors/"; Dir::State::extended_states "extended_states"; Dir::State::status "/var/lib/dp
Bug#846043: mutt: new neomutt release 2016-11-26 (1.7.1)
Package: mutt Version: 1.7.1-3 Severity: wishlist Dear Maintainer, Could you update mutt to the newest neomutt release? I would like to see whether it fixes the pager crash on arrival of new mail (#838720). Thanks, Peter
Bug#846040: virtual/meta package for vtk
Package: vtk6 Version: 6.3.0 This is not a bug but a wishlist item for this package. It would be nice to have a virtual/meta package that automatically links to the latest version of the package. Having a package named vtk which links to vtk6 now and vtk7 in the future will make transitions easier. Below is the link to a package that already implements this. https://packages.debian.org/stretch/petsc-dev Thanks
Bug#846042: virtual/meta package for python-vtk
Package: python-vtk6 Version: 6.3.0 This is not a bug but a wishlist item for this package. It would be nice to have a virtual/meta package that automatically links to the latest version of the package. Having a package named python-vtk which links to python-vtk6 now and python-vtk7 in the future will make transitions easier. Below is the link to a package that already implements this. https://packages.debian.org/stretch/petsc-dev Thanks
Bug#846041: virtual/meta package for libvtk-dev
Package: libvtk6-dev Version: 6.3.0 This is not a bug but a wishlist item for this package. It would be nice to have a virtual/meta package that automatically links to the latest version of the package. Having a package named libvtk-dev which links to libvtk6-dev now and libvtk7-dev in the future will make transitions easier. Below is the link to a package that already implements this. https://packages.debian.org/stretch/petsc-dev Thanks
Bug#845749: libwebp FTBFS on armhf: inlining failed in call to always_inline 'vtrnq_s32': target specific option mismatch
Ubuntu may have the patch for this. If so, okay to NMU. https://patches.ubuntu.com/libw/libwebp/libwebp_0.5.1-2ubuntu1.patch
Bug#846039: ITP: ruby-secure-headers --Security related headers all in one gem
Package: wnpp Severity: wishlist Owner: Abhijith PA X-Debbugs-CC: debian-de...@lists.debian.org * Package name: ruby-secure-headers Version : 3.5.0 Upstream Author : Neil Matatall * URL : https://github.com/twitter/secureheaders/ * License : Apache 2.0 Programming Lang: Ruby Description : Security related headers all in one gem Add easily configured security headers to responses -- Abhijith PA abhij...@openmailbox.org Debian Maintainer 4096R/ED9C28EF:EF13 EA26 A698 FF35 FD7C 902E 863D 4DF2 ED9C 28EF signature.asc Description: OpenPGP digital signature
Bug#845696: cython: FTBFS on all 32 bit architectures
Hi Tobias, Thank you! I will take care about it! On Sun, 27 Nov 2016, Tobias Hansen wrote: > Control: tags -1 + patch > Here is a patch that contains the two upstream commits that fix the > issue. I tested it on i386. Yaroslav, do you mind if I upload the fix or > do you want? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#846038: wesnoth: Setting fullscreen crashes game
Package: wesnoth Version: 1:1.12.6-1 Severity: important Tags: upstream Hello! As the title says whenever I select "fullscreen" the game simply dies on me. The following is output to the console: setting mode to 1024x768x32 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 152 (XFree86-VidModeExtension) Minor opcode of failed request: 10 (XF86VidModeSwitchToMode) Value in failed request: 0x49e Serial number of failed request: 196 Current serial number in output stream: 198 I am using KDE5 and I believe that Debian is using Wayland on top of X.org or something like that. I'm setting this as important because I imagine most people like to play games fullscreen but it is a matter of opinion really. If you think this should prevent the game from reaching stable I believe you'd have to change it to a higher severity. Thanks for maintaning this great open-source game on Debian! -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/8 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 wesnoth depends on: ii wesnoth-1.12 1:1.12.6-1 ii wesnoth-1.12-data 1:1.12.6-1 wesnoth recommends no packages. wesnoth suggests no packages. -- no debconf information
Bug#845495: src:python-tz: Non-maintainer upload of python-tz/2016.7-0.1 to DELAYED/5
Hilko Bengen writes: >> Unless I'm mistaken, as you have not specified that pytest should be >> used (by adding 'export PYBUILD_TEST_PYTEST=1' to debian/rules), it is >> still not used and no test is ran: > > I have just re-run the source package I uploaded in an unstable-amd64 > sbuild environment. The tests were executed. After checking /usr/share/perl5/Debian/Debhelper/Buildsystem/pybuild.pm, it seems that --test-pytest argument is automatically passed to pybuild if python(3)-pytest is in Build-Depends. Sorry for the noise. Thanks for the upload. Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#846037: rclone: FTBFS: cannot find "golang.org/x/oauth2/google"
Source: rclone Version: 1.34-1 Severity: serious Justification: fails to build from source Builds of rclone in minimal environments (as on the autobuilders) have been failing with errors along the lines of src/github.com/ncw/rclone/drive/drive.go:25:2: cannot find package "golang.org/x/oauth2/google" in any of: /usr/lib/go-1.7/src/golang.org/x/oauth2/google (from $GOROOT) /«PKGBUILDDIR»/obj-aarch64-linux-gnu/src/golang.org/x/oauth2/google (from $GOPATH) Please adjust the build dependency on golang-golang-x-oauth2-dev to golang-golang-x-oauth2-google-dev and confirm with pbuilder or the like that you haven't missed anything else. Please also ensure that golang-github-ncw-rclone-dev's runtime dependencies are complete. Thanks! Please note that I classified this bug as a regression even though rclone is new to Debian because the bug would affect binNMUs. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#846036: xul-ext-mozvoikko: please package new upstream 2.2
Package: xul-ext-mozvoikko Version: 2.0.1-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 In the process of overhauling the packaging of mozvoikko, I found out that the upstream source has migrated to a new host and that a new version has been released. My proposed changes to the packaging are filed as a seperate bug report. The new location for all voikko packages (including this XUL extension) is: http://voikko.puimula.org/sources.html - -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (, 'testing'), (1011, 'stable') Architecture: i386 (i586) Kernel: Linux 3.16.0-4-586 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-mozvoikko depends on: ii iceweasel 45.5.0esr-1 ii libvoikko1 4.0.2-2 ii voikko-fi 2.1-1 xul-ext-mozvoikko recommends no packages. xul-ext-mozvoikko suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAlg7h9oACgkQrh+Cd8S0 17ZjTw/9G6zw7iaSszEkVNnc9iOXb37uOGr49rSM6GoC0mRvHGlalCB58aUEPaKm Mle5IVkDCQeOPHAtHsQLTVMAumfE5Zif/1/NDEXBNGGHLarisIrjwqm0twh7ftKN DDyJhRiQ/yBge4rSramHT10hMlEGt2DZXIPwBuE1zEKzDeI/rNEGz2plGK2Pbbjt jWGxMIfSUQaf4I7vp0ub3g+KHqSOda3KK4ZJ+XBY3MiUi7EyUSBHuWPg6OFwB2Rh haF/VhShaKzgDoSWuzsTSXmBChKRjGe7M6Asd6SI0jmUAGgxQ+OlYv5SpdXxlpSV tKx206IIQPZLOa00SiRpnUIjK5joWbxeRnIzkbOJm5vAOp4KWD7gOfaY9Lqf+f3F j4ZnhDiPQGoQ0Iu6gHazchr37R5BRvJKoMcGyms4A6J6aw/VztBJBF2LpaC8HEYq ViSUahSGd0z1HyI57QMc7RDpyLE5oXvZs7IwdXSEI6yskKhVStE2FETcp1m2+51z yS5UJcLWKIHVHnGnxoEdAdKv/j5Z+jqFebp1KE+m/orELnjNkiY0u8K5tWvnQBz4 QjTJRSqmBb19Y64BQLPblRE2eUfqFFdeLa9O6DDcDm0JZxzfsukGDOL26Uyi0+KS SmzqUPVCKRmYw5KqbX51nLdx1WUupwn2Cqq+G5uxzk0n/nlYa+Q= =qdSu -END PGP SIGNATURE-
Bug#846035: eagle: Eagle needs updated to a newer version: 7.7 is current: https://cadsoft.io/
Package: eagle Version: 6.6.0-2 Severity: wishlist Dear Maintainer, Eagle needs updated to a newer version: 7.7 is current. https://cadsoft.io/ -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/8 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)
Bug#835940: nvidia-cuda-toolkit: non-standard gcc/g++ used for build (gcc-5)
Hello guys, I successfully compiled caffe with CUDA_8.0.44-2 and clang-3.8 (the current default clang). Maybe we can replace GCC-5 with Clang-3.8 to solve this problem. That means Stretch still has chance to ship CUDA8, and users are expected to compile with Clang/LLVM instead of GCC-6, as long as the CUDA rDepends compile with clang. I only tested caffe-contrib.
Bug#846034: torbrowser-launcher: add an option to download debug symbols for when Tor Browser crashes
Package: torbrowser-launcher Severity: wishlist For those rare situations where the Tor Browser crashes it would be nice to have a way for the torbrowser-launcher to download, verify and install debug symbols so I can get a gdb backtrace from the core dump. https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#DebuggingtheTorBrowser -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#846033: aptitude: include source packages with Build-Depends/Build-Conflicts (and variants) in "Packages which depend on ..."
Package: aptitude Severity: wishlist It would be nice if aptitude would include source packages with Build-Depends, Build-Conflicts and variants of those in the section called "Packages which depend on ...". This could be useful for figuring out why manually installed packages were installed. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#841090: Why not just set signal handlers?
Ian Jackson writes ("Re: Bug#841090: Why not just set signal handlers?"):
> It's certainly not just my opinion. This bug was fixed in Python and
> GHC and xfce4-terminal already. The bug I filed against lightdm has
> been fixed.
>
> https://ghc.haskell.org/trac/ghc/ticket/4274
> https://twistedmatrix.com/trac/ticket/4199
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733722
Also,
libguestfs
https://www.redhat.com/archives/libguestfs/2011-April/msg6.html
launchpad
https://code.launchpad.net/~jelmer/launchpad/637507-subprocess-sigpipe/+merge/37940
Written in Python but the Python fix would have been backwards-
incompatible so often applications need patching. This one is
notable because launchpad wants to run dpkg-source -x and motivation
in the bug report suggests that dpkg-source -x can break sometimes
with SIGPIPE ignored.
pyanaconda
https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-September/013489.html
(another Python one)
chromium
https://chromium.googlesource.com/native_client/src/native_client/+/master/tools/test_lib.py
(another Python one)
ubuntutools
https://lists.ubuntu.com/archives/universe-bugs/2011-June/197570.html
(another Python one)
dak
https://lists.debian.org/debian-dak/2013/10/msg9.html
(having this bug in the Python standard library just keeps giving)
I also found this
http://www.pixelbeat.org/programming/sigpipe_handling.html
I hope that's enough to convince you...
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#378462: dput: change default to run Lintian check
Control: retitle -1 dput: change default to run Lintian check Control: found -1 dput/0.11.0 Control: forcemerge -1 812772 On 16-Jul-2006, Thijs Kinkhorst wrote: > dput by default has in its config file: > run_lintian = 0 > > I propose to change that to 1. I'm merging a later request for the same change into this report. -- \ “It's up to the masses to distribute [music] however they want | `\… The laws don't matter at that point. People sharing music in | _o__)their bedrooms is the new radio.” —Neil Young, 2008-05-06 | Ben Finney signature.asc Description: PGP signature
Bug#428437: dput: add command-line option to disable Lintian
Control: retitle -1 dput: add command-line option to disable Lintian Control: found -1 dput/0.9.6.4 Control: found -1 dput/0.11.0 Control: block 827879 by -1 Control: forcemerge -1 840249 On 11-Jun-2007, Andreas Beckmann wrote: > Having to edit .dput.cf in order to disable lintian adds the risk of > forgetting to enable it again. There are other contexts where editing the dput configuration is not even reasonable. For example, the use case reported in bug#840249. This feature would be needed to resolve, for instance, Debian bug#827879. I'm updating this bug report accordingly. -- \ “Better not take a dog on the space shuttle, because if he | `\ sticks his head out when you're coming home his face might burn | _o__)up.” —Jack Handey | Ben Finney signature.asc Description: PGP signature
Bug#841090: Why not just set signal handlers?
Dmitry Bogatov writes ("Re: Bug#841090: Why not just set signal handlers?"):
> [2016-11-26 17:22] Ian Jackson
> > Any program with sufficiently careful error handling will break when
> > SIGPIPE is ignored.
>
> If it is careful enough, it can setup all handlers by itself.
Yes, but programs don't (eg, ls, interactive shells, etc., see below)
and are not required to.
> > Interactive shells with SIGPIPE ignored are a latent bug which I want
> > to flush out.
>
> Can you elaborate?
Just to give an example:
zealot:~> yes | true
zealot:~> echo "${PIPESTATUS[@]}"
141 0
zealot:~> debian_chroot='(nosigpipe)' perl -e '$SIG{PIPE}=IGNORE; exec @ARGV'
bash
(nosigpipe)zealot:~> yes | true
yes: standard output: Broken pipe
(nosigpipe)zealot:~> echo "${PIPESTATUS[@]}"
1 0
(nosigpipe)zealot:~>
Observe that in the 2nd case:
* a spurious message is produced on stderr
* `yes' calls exit(1) rather than dying due to a fatal SIGPIPE
> > > I just took time to explore dgit and discovered, that it does not work
> > > under dvtm or dtach (did not tested screen or tmux).
> >
> > Please file bugs against those programs.
>
> I am debian maintainer of dvtm, but I am not convinced yet that removing
> signal(SIGPIPE, SIG_IGN) would do more good then evil. Link to something
> like 'signal(SIGPIPE, SIG_IGN) considered harmful'?
I did look in SUSv3 (POSIX) for something that categorically states
that executing nonconsenting programs with SIGPIPE ignored is
forbidden. Unfortunately the language in SUSv3 is distressingly
vague. I would argue that the fact that
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_01
describes SIG_DFL as "Signal-specific default action" means that this
is what an application is allowed to expect from the operating system.
(If as one application, you run another, you obviously need to play
the role of the operating system in that interface.)
> So far, it looks to me that you are artificially pushing your opinion on
> what other programs should or should not do. No offense.
It's certainly not just my opinion. This bug was fixed in Python and
GHC and xfce4-terminal already. The bug I filed against lightdm has
been fixed.
https://ghc.haskell.org/trac/ghc/ticket/4274
https://twistedmatrix.com/trac/ticket/4199
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733722
Here's a blog post from Colin Watson on the subject:
http://www.chiark.greenend.org.uk/~cjwatson/blog/python-sigpipe.html
Note that there is nothing wrong with setting SIGPIPE to SIG_IGN,
within your own program, or when executing programs that expect to be
run that way. It is often very convenient to do so, because in many
(particularly, concurrent) programs SIGPIPE is quite a nuisance.
The bug is in not resetting it after fork and before exec.
> Sure, I was able to find workarounds, but like when things just work,
> don't we?
Well certainly if this kind of thing is going to be common I should
probably make dgit print a warning and reset SIGPIPE itself.
Or maybe I'll write a patch for bash to print the same warning.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#668238: terminator: Doesn't close unlinked files
Oh, wait... The fact that these file descriptors remain open _even after you close the corresponding terminal_ is still present (in Terminator-1.90) and is an actual valid issue. Hang on, I'll investigate. e.
Bug#258096: New Purchase Order
Good Day, Kindly requested to quote your rock bottom price with your best delivery time as per the attached inquiry ref. XYZtrade/RFQ#21112016 dated 28/11/2016 at your earliest. thanks. Best Regards. PO #6765 asia 11272016_.pdf Description: Binary data
Bug#846032: yaboot: Power Mac G5 ofboot.b not configured correctly for second disk
Package: yaboot Version: 1.3.16-4 Severity: important Dear Maintainer, Fresh installation of 8.6.0 on a Power Mac G5 (2005) onto the second SATA disk. The installation proceeded without errors, but it was not possible to boot into Linux afterwards. Booting the DVD in rescue mode showed the second disk was partitioned correctly and the bootstrap and root partitions were present. Installation onto the first SATA disk produced a working boot configuration. Mounting the bootstrap partition and correcting ofboot.b with the following diff produces a working boot of the second stage yaboot program on the second SATA disk. 10c10 < : bootyaboot " Loading second stage bootstrap..." .printf 100 ms load-base release-load-area " /ht@0,f200/pci@9/k2-sata-root@c/@/@0:2,\\yaboot" $boot ; --- > : bootyaboot " Loading second stage bootstrap..." .printf 100 ms load-base > release-load-area " > /ht@0,f200/pci@9/k2-sata-root@c/k2-sata@1/@0:2,\\yaboot" $boot ; -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Kernel: Linux 3.16.0-4-powerpc64 (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/dash Init: systemd (via /run/systemd/system) Versions of packages yaboot depends on: ii libc6 2.19-18+deb8u6 Versions of packages yaboot recommends: ii hfsutils 3.2.6-13 ii powerpc-utils 1.1.3-25 yaboot suggests no packages. -- no debconf information
Bug#846031: jessie-pu: package tre/0.8.0-4+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Managers:
Salvatore told me that this does not warrant a DSA. so I've prepared
this upload for jessie-proposed-updates, to be considered for stable.
It fixes CVE-2016-8859.
Debdiff is attached.
Thanks.diff -Nru tre-0.8.0/debian/changelog tre-0.8.0/debian/changelog
--- tre-0.8.0/debian/changelog 2014-04-30 00:38:40.0 +0200
+++ tre-0.8.0/debian/changelog 2016-11-28 00:31:36.0 +0100
@@ -1,3 +1,12 @@
+tre (0.8.0-4+deb8u1) jessie; urgency=medium
+
+ * Add debian/patches/03-cve-2016-8859 to fix CVE-2016-8859.
+Patch borrowed from wheezy LTS. Closes: #842169.
+ * Add locales-all to Build-Depends, required to run the test suite.
+ * Add debian/clean with files generated/modified during the build.
+
+ -- Santiago Vila Mon, 28 Nov 2016 00:31:36 +0100
+
tre (0.8.0-4) unstable; urgency=medium
* I'm having a déjà vu.
diff -Nru tre-0.8.0/debian/clean tre-0.8.0/debian/clean
--- tre-0.8.0/debian/clean 1970-01-01 01:00:00.0 +0100
+++ tre-0.8.0/debian/clean 2016-11-27 23:00:00.0 +0100
@@ -0,0 +1,4 @@
+tests/agrep/basic.in
+tests/agrep/delimiters.in
+tests/agrep/exitstatus.in
+tests/agrep/records.in
diff -Nru tre-0.8.0/debian/control tre-0.8.0/debian/control
--- tre-0.8.0/debian/control2014-04-29 12:00:00.0 +0200
+++ tre-0.8.0/debian/control2016-11-27 23:00:00.0 +0100
@@ -4,7 +4,7 @@
Maintainer: Santiago Vila
Uploaders: Milan Zamazal
Standards-Version: 3.9.5
-Build-Depends: gettext (>= 0.18.1.1-8), debhelper (>= 9)
+Build-Depends: gettext (>= 0.18.1.1-8), debhelper (>= 9), locales-all
Package: libtre5
Architecture: any
diff -Nru tre-0.8.0/debian/patches/03-cve-2016-8859
tre-0.8.0/debian/patches/03-cve-2016-8859
--- tre-0.8.0/debian/patches/03-cve-2016-8859 1970-01-01 01:00:00.0
+0100
+++ tre-0.8.0/debian/patches/03-cve-2016-8859 2016-11-27 23:03:00.0
+0100
@@ -0,0 +1,73 @@
+From c3edc06d1e1360f3570db9155d6b318ae0d0f0f7 Mon Sep 17 00:00:00 2001
+From: Rich Felker
+Date: Thu, 6 Oct 2016 18:34:58 -0400
+Subject: fix missing integer overflow checks in regexec buffer size
+ computations
+
+most of the possible overflows were already ruled out in practice by
+regcomp having already succeeded performing larger allocations.
+however at least the num_states*num_tags multiplication can clearly
+overflow in practice. for safety, check them all, and use the proper
+type, size_t, rather than int.
+
+also improve comments, use calloc in place of malloc+memset, and
+remove bogus casts.
+---
+ src/regex/regexec.c | 23 ++-
+ 1 file changed, 18 insertions(+), 5 deletions(-)
+
+Note: patch was modified to apply to tre, parts were taken from
+https://github.com/laurikari/tre/issues/37
+
+--- a/lib/tre-match-parallel.c
b/lib/tre-match-parallel.c
+@@ -59,6 +59,7 @@
+ #ifdef HAVE_MALLOC_H
+ #include
+ #endif /* HAVE_MALLOC_H */
++#include
+
+ #include "tre-internal.h"
+ #include "tre-match-utils.h"
+@@ -150,11 +151,24 @@
+
+ /* Allocate memory for temporary data required for matching.This
needs to
+ be done for every matching operation to be thread safe. This allocates
+- everything in a single large block from the stack frame using alloca()
+- or with malloc() if alloca is unavailable. */
++ everything in a single large block with calloc(). */
+ {
+-int tbytes, rbytes, pbytes, xbytes, total_bytes;
++size_t tbytes, rbytes, pbytes, xbytes, total_bytes;
+ char *tmp_buf;
++
++/* Ensure that tbytes and xbytes*num_states cannot overflow, and that
++ * they don't contribute more than 1/8 of SIZE_MAX to total_bytes. */
++if (num_tags > SIZE_MAX/(8 * sizeof(int) * tnfa->num_states))
++ return REG_BADPAT;
++
++/* Likewise check rbytes. */
++if (tnfa->num_states+1 > SIZE_MAX/(8 * sizeof(*reach_next)))
++ return REG_BADPAT;
++
++/* Likewise check pbytes. */
++if (tnfa->num_states > SIZE_MAX/(8 * sizeof(*reach_pos)))
++ return REG_BADPAT;
++
+ /* Compute the length of the block we need. */
+ tbytes = sizeof(*tmp_tags) * num_tags;
+ rbytes = sizeof(*reach_next) * (tnfa->num_states + 1);
+@@ -168,11 +182,11 @@
+ #ifdef TRE_USE_ALLOCA
+ buf = alloca(total_bytes);
+ #else /* !TRE_USE_ALLOCA */
+-buf = xmalloc((unsigned)total_bytes);
++buf = xmalloc(total_bytes);
+ #endif /* !TRE_USE_ALLOCA */
+ if (buf == NULL)
+ return REG_ESPACE;
+-memset(buf, 0, (size_t)total_bytes);
++memset(buf, 0, total_bytes);
+
+ /* Get the various pointers within tmp_buf (properly aligned). */
+ tmp_tags = (void *)buf;
diff -Nru tre-0.8.0/debian/patches/series tre-0.8.0/debian/patches/series
--- tre-0.8.0/debian/patches/series 2014-04-29 12:00:00.0 +0200
+++ tre-0.8.0/debian/patches/series 2016-11-27 23:00:00.0 +0100
@@ -1,3 +1,4 @@
01-agrep-is-called-tr
Bug#623062: terminator: High memory usage
Hi, FYI: Approximate memory usage (RSS) for me right after starting up the apps is: gnome-terminal, xfce4-terminal, mate-terminal: 35 MB terminator: 55 MB terminix: 60 MB I'm on Ubuntu Yakkety, some of these apps are from Zesty beta or manually compiled, all of them using Gtk+-3 and corresponding libvte-2.91. (In the original report, and probably in the followup comments too they were probably based on Gtk+-2 and libvte9.) I don't know where these large numbers come from, but I can easily imagine Gtk+ itself (with all the things it's doing under the hood, e.g. I guess it caches the font, etc.) bringing in perhaps a good 30 or so megs (hey, an empty gedit consumes 44 MB for me), and perpahs the Python overhead (including its automatic deferred GC) is yet another 20 M. Dunno. VTE is expected to consume somewhere around up to maybe 0.5 MB - 1 MB per widget once you actually start using it (that is, once you produce a nice amount of output, not just the initial shell prompt and a few lines). That is, it's negligible here. cheers, egmont
Bug#825975: sysvinit: Add missing poweroff on hurd-i386
Hello, Samuel Thibault, on Wed 01 Jun 2016 02:24:44 +0200, wrote: > The sysvinit-core package currently doesn't ship a /sbin/poweroff for > hurd-i386 with proper alternative configuration. The attached patch > fixes that, could you please apply it? Ping? Samuel --- debian/rules.original 2016-06-01 02:18:40.089432414 +0200 +++ debian/rules2016-06-01 02:20:45.288372651 +0200 @@ -117,9 +117,13 @@ mv $(sysvtmp)/usr/share/man/man8/halt.8.gz $(sysvtmp)/usr/share/man/man8/halt-sysv.8.gz rm $(sysvtmp)/usr/share/man/man8/reboot.8.gz ln -s halt-sysv.8.gz $(sysvtmp)/usr/share/man/man8/reboot-sysv.8.gz + rm $(sysvtmp)/usr/share/man/man8/poweroff.8.gz + ln -s halt-sysv.8.gz $(sysvtmp)/usr/share/man/man8/poweroff-sysv.8.gz mv $(sysvtmp)/sbin/halt $(sysvtmp)/sbin/halt-sysv rm $(sysvtmp)/sbin/reboot ln -s halt-sysv $(sysvtmp)/sbin/reboot-sysv + rm $(sysvtmp)/sbin/poweroff + ln -s halt-sysv $(sysvtmp)/sbin/poweroff-sysv # Add runsystem to conffiles, suppress lintian error echo /etc/hurd/runsystem.sysv >> $(inittmp)/DEBIAN/conffiles else --- debian/initscripts.postinst.original2016-06-01 02:15:47.811043361 +0200 +++ debian/initscripts.postinst 2016-06-01 02:17:13.920199428 +0200 @@ -237,6 +237,7 @@ --install /etc/hurd/runsystem runsystem \ /etc/hurd/runsystem.sysv 10 \ --slave /sbin/halt halt /sbin/halt-sysv \ + --slave /sbin/poweroff poweroff /sbin/poweroff-sysv \ --slave /sbin/reboot reboot /sbin/reboot-sysv new="$(get_runsystem)"
Bug#843890: Monitoring child processes
My pleasure, I'm happy Debian users continue to file bugs, it benefits everyone in the long run.
Bug#846030: xserver-xorg-video-nvidia: Cannot be co-installed with unstable 1.19 (xserver-xorg-core (<< 2:1.18.99))
Package: xserver-xorg-video-nvidia Version: 375.20-1 Severity: important I did put xserver-xorg-core on hold because the nvidia driver was not ready. Now the driver is ready, but the Depends line forbids to co-install with unstable version. -- Package-specific info: uname -a: Linux tri-yann4 4.4.33 #38 SMP PREEMPT Sat Nov 19 17:54:40 CET 2016 x86_64 GNU/Linux /proc/version: Linux version 4.4.33 (valette@tri-yann4) (gcc version 6.2.1 20161118 (Debian 6.2.1-3) ) #38 SMP PREEMPT Sat Nov 19 17:54:40 CET 2016 /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 370.28 Thu Sep 1 19:45:04 PDT 2016 GCC version: gcc version 6.2.1 20161118 (Debian 6.2.1-3) lspci 'VGA compatible controller [0300]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 670] [10de:1189] (rev a1) (prog-if 00 [VGA controller]) Subsystem: CardExpert Technology GK104 [GeForce GTX 670] [10b0:1189] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia_current_drm, nvidia_current dmesg: [0.00] Console: colour VGA+ 80x25 [0.266309] vgaarb: setting as boot device: PCI::01:00.0 [0.266310] vgaarb: device added: PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none [0.266315] vgaarb: loaded [0.266316] vgaarb: bridge control possible :01:00.0 [0.359878] Linux agpgart interface v0.103 [1.048686] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input3 [1.048890] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input4 [1.049041] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input5 [1.049163] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input6 [2.424642] nvidia: module license 'NVIDIA' taints kernel. [2.443322] vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem [2.443414] nvidia-nvlink: Nvlink Core is being initialized, major device number 247 [2.443444] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 370.28 Thu Sep 1 19:45:04 PDT 2016 [2.450374] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 370.28 Thu Sep 1 19:18:48 PDT 2016 [2.451517] [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver [ 20.146415] nvidia-modeset: Allocated GPU:0 (GPU-3ae49403-ead2-114d-863b-ff3072d039b6) @ PCI::01:00.0 Device node permissions: crw-rw+ 1 root video 226, 0 Nov 27 18:58 /dev/dri/card0 crw-rw+ 1 root video 226, 128 Nov 27 18:58 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 Nov 27 18:58 /dev/nvidia-modeset crw-rw-rw- 1 root root 195, 0 Nov 27 18:58 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Nov 27 18:58 /dev/nvidiactl video:x:44:valette,vdr,hts,sddm OpenGL and NVIDIA library files installed: -rw-r--r-- 1 valette valette 1722 Aug 20 2014 /etc/X11/xorg.conf lrwxrwxrwx 1 rootroot 15 Nov 28 00:11 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 rootroot 49 Mar 30 2016 /etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so lrwxrwxrwx 1 rootroot 44 Nov 28 00:11 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 rootroot 48 Mar 30 2016 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 rootroot 48 Mar 30 2016 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 rootroot 43 Nov 28 00:11 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 rootroot 43 Nov 28 00:11 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 rootroot 50 Nov 28 00:11 /etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1 lrwxrwxrwx 1 rootroot 50 Nov 28 00:11 /etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1 lrwxrwxrwx 1 rootroot 47 Nov 28 00:11 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2 lrwxrwxrwx 1 rootroot 47 Nov 28 00:11 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2 lrwxrwxrwx 1 rootroot 51 Nov 28 00:11 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu
Bug#845986: pkg_resources: ‘load_entry_point’ crashes without Setuptools
Control: reassign -1 python-pkg-resources Control: retitle -1 pkg_resources: ‘load_entry_point’ crashes without Setuptools Control: found -1 python-pkg-resources/28.7.1-1 Control: merge 836710 -1 On 27-Nov-2016, Heinrich Schuchardt wrote: > pkg_resources.DistributionNotFound: > The 'setuptools' distribution was not found and is required by dput Thanks for the report. This is a bug in ‘python-pkg-resources’, already reported in bug#836710. -- \ “When I get real bored, I like to drive downtown and get a | `\ great parking spot, then sit in my car and count how many | _o__)people ask me if I'm leaving.” —Steven Wright | Ben Finney signature.asc Description: PGP signature
Bug#842177: transition: hdf5
On 27/11/16 23:21, Gilles Filippini wrote: > Hi, > > Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 : Yes, this is looking very good, so I'm acking it. But please don't upload just yet, I'll give you the go in a few days when things are a bit calmer (there are just too many transitions at the moment). > > Any news on this side? I'm waiting after the transition to upload a new > release of the package which will have to go through the NEW queue > because of new binary packages for the java bindings. Go ahead. Cheers, Emilio
Bug#846029: request-tracker4: uses deprecated gpg1
Source: request-tracker4 Version: 4.2.13-4 Severity: normal Since #845534 was fixed RT now uses gpg1, which is deprecated, or at least its uses discouraged, in Debian. Fixing this is blocked by #845781. Dominic.
Bug#822450: [terminator] Separator size doesn't work
Hi, I think this is fixed in the brand new 1.90 version; could you please confirm it? cheers, egmont
Bug#846028: jquery-tmpl is deprecated
Package: ikiwiki Version: 3.20160905 Severity: normal Its author recommends JsRender instead. I assume, that it would be good to migrate. libjs-jsrender is in Debian.
Bug#845281: mediawiki: backport version does not play well with extensions
Hi, On 11/23/2016 11:11 PM, Marc Dequènes (duck) wrote: > Quack, > > On 2016-11-24 14:41, Kunal Mehta wrote: > >> This is somewhat intentional as the new package only contains some of >> those packages (those that are shipped by upstream as part of the >> tarball), while the mediawiki-extensions-base package was a somewhat >> arbitrary list of extensions. > > I understand, but when I saw the APT proposal, I quickly said NO to > avoid breakage, but still had no clue what to do. Okay, the next version of the package will have a NEWS file (#838965), and but I think apt will still show the removal proposal first? I'll do some testing on that. >> The package already has provides for those three packages (base, geshi, >> and confirmedit), but I think it will still need to break >> mediawiki-extensions since none of the extensions in that package are >> compatible with the newer version and not all of them are provided by >> the new package. I also have no plans on updating the >> mediawiki-extensions-* packages. So I'm not sure really what other steps >> can be taken... > > Which package has these provides? mediawiki does not, > mediawiki-extensions does not either, I just checked again. Sorry, I was looking at something else and confused myself. I'll add those Provides for the next version. > IMHO, removing the mediawiki-extensions package & co in unstable, with a > NEWS.Debian explaining the situation in the mediawiki package, is fine > for the next release. The user can review its extensions, packaged or > not; it is part of the machine's planned upgrade to switch release, so > no big issue here. Ack. > As for bpo, this is much different. bpo are here to provide a > convenience upgrade for some specific package, but is not meant to be a > major disruption. If you leave the users without any upgrade path, then > this is not nice. As you do not plan to support packaged extensions, > then probably you should not have proposed a backport in the first > place. In this case, to avoid surprise, I think using debconf and > cancelling install in preinst would be better. I understand where you're coming from, but from my point of view, the mediawiki package was removed from jessie because it was so old, and wasn't receiving security support so backporting the 1.27 package provided people a modern version with security support. You're of course totally free not to use the backported version if it will cause trouble for your setup. -- Kunal signature.asc Description: OpenPGP digital signature
Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later
On Sun, 2016-11-27 at 15:42 +0800, Paul Wise wrote: > On Sun, 2016-11-27 at 08:27 +0100, Salvatore Bonaccorso wrote: > > > This was an intentional change in 4.8.4-1~exp1 afaict, from the > > changelog entry: > > I wonder if this should be promoted to a NEWS.Debian entry? So far as I know, nothing will display the NEWS.Debian file in a newly installed binary packge. That's why I already documented this in NEWS in the linux-image meta-packages. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Bug#842177: transition: hdf5
Hi, Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 : >>> Yes, this is looking very good, so I'm acking it. But please don't upload >>> just >>> yet, I'll give you the go in a few days when things are a bit calmer (there >>> are >>> just too many transitions at the moment). Any news on this side? I'm waiting after the transition to upload a new release of the package which will have to go through the NEW queue because of new binary packages for the java bindings. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#831032: pptp-linux: Please update patches and packaging
On Sat, Nov 26, 2016 at 02:51:44PM +0100, Christoph Biedl wrote: > * Convince upstream to remove pptpsetup.8 in the clean target Taken, pushed as 0080ac8. I'll take a look at the other patches. -- James Cameron http://quozl.netrek.org/
Bug#846024: libneon27*-dev wrongly marked Multi-Arch: foreign
Control: tags -1 +pending On Sun, Nov 27, 2016 at 10:52 PM, Helmut Grohne wrote: > libneon27-dev and libneon27-gnutls-dev are wrongly marked Multi-Arch: > foreign. E.g. libneon27-dev:amd64 contains the following architecture > dependent files: > > /usr/lib/x86_64-linux-gnu/libneon.a > /usr/lib/x86_64-linux-gnu/libneon.so > /usr/lib/x86_64-linux-gnu/pkgconfig/neon.pc My bad, will fix it in the coming day or so with removing the 'Multi-Arch' field. Thanks for the heads-up, Laszlo/GCS
Bug#839907: marked as done (jessie-pu: package metar/20061030.1-2+b3)
Control: reopen -1 Control: tags -1 + pending On Sun, 2016-11-27 at 21:51 +, Debian Bug Tracking System wrote: >* Import patch for new METAR URL from Kees Leune (Closes: #839907) Unfortunately no-one spotted it beforehand, but the upload shouldn't close the release.debian.org bug - that happens once the point release is out. Regards, Adam signature.asc Description: This is a digitally signed message part
Bug#846024: libneon27*-dev wrongly marked Multi-Arch: foreign
Package: libneon27-dev,libneon27-gnutls-dev Version: 0.30.2-1 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch libneon27-dev and libneon27-gnutls-dev are wrongly marked Multi-Arch: foreign. E.g. libneon27-dev:amd64 contains the following architecture dependent files: /usr/lib/x86_64-linux-gnu/libneon.a /usr/lib/x86_64-linux-gnu/libneon.so /usr/lib/x86_64-linux-gnu/pkgconfig/neon.pc None of them poses an architecture-independent interface. Thus marking these packages Multi-Arch: foreign is wrong. The current marking breaks cross compilation of any reverse dependency of these libraries as it causes a build architecture development package to be used when a host architecture development package was expected. These development packages simply should not have a Multi-Arch header as long as they contain neon-config. See #643341 for a similar issue and elaborate rationale. Helmut
Bug#813249: libupnp6: vlc fails to playback upnp provided content since upgrade to 1:1.6.19+git20160116-1
On Sun, Nov 27, 2016 at 10:37:36PM +0100, Uwe Kleine-König wrote:
> Control: tag 813249 + ipv6
>
> Hello,
>
> On Sun, Jan 31, 2016 at 02:44:51AM +0100, Uwe Kleine-König wrote:
> > On 01/30/2016 11:05 PM, Uwe Kleine-König wrote:
> > > Package: libupnp6
> > > Version: 1:1.6.19+git20160116-1
> > > Severity: normal
> > >
> > > Hello,
> > >
> > > vlc stopped showing my dlna provider, when downgrading libupnp6 to
> > > 1:1.6.19+git20141001-1 it works fine again.
> > >
> > > With libupnp6 1:1.6.19+git20141001-1 the (I think) relevant part obtained
> > > from strace is:
> > >
> > > 10317 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 18
> > > 10317 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 19
> > > 10317 setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
> > > 10317 bind(18, {sa_family=AF_INET, sin_port=htons(49152),
> > > sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> > > 10317 bind(19, {sa_family=AF_INET6, sin6_port=htons(49152),
> > > inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> > > 28) = 0
> > > 10317 listen(18, 128) = 0
> > > 10317 getsockname(18, {sa_family=AF_INET, sin_port=htons(49152),
> > > sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
> > > 10317 listen(19, 128) = 0
> > > 10317 getsockname(19, {sa_family=AF_INET6, sin6_port=htons(49152),
> > > inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> > > [28]) = 0
> > >
> > > while with 1:1.6.19+git20160116-1 I get:
> > >
> > > 10997 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 18
> > > 10997 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 19
> > > 10997 setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
> > > 10997 bind(18, {sa_family=AF_INET, sin_port=htons(49152),
> > > sin_addr=inet_addr("192.168.77.157")}, 16) = 0
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49152),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49153),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49154),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49155),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49156),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > ...
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65531),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65532),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65533),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65534),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65535),
> > > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > > 10997 close(18) = 0
> > > 10997 close(19) = 0
> > >
> > > The obvious difference is that the newer libupnp uses an explicit
> > > address for binding the port, but I don't see this as an excuse for bind
> > > to fail. And in fact the same difference exists for ipv4 where there
> > > doesn't seem to be a problem.
> > >
> > > btw, netcat-openbsd has the same problem:
> > >
> > > nc fe80::2ac6:8eff:fe36:df57 22
> > >
> > > fails with:
> > >
> > > connect(3, {sa_family=AF_INET6, sin6_port=htons(22),
> > > inet_pton(AF_INET6, "fe80::2ac6:8eff:fe36:df57", &sin6_addr),
> > > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > >
> > > while it works fine when using the ipv4 or a global ipv6 of the same
> > > machine.
>
> btw, this works:
>
> nc fe80::2ac6:8eff:fe36:df57%eth0 22
>
> to specify the device. strace output changes to:
>
> ... sin6_scope_id=if_nametoindex("eth0")
>
> > > So it seems to be a bad idea to use the li
Bug#846023: hdevtools hangs indefinitely
Package: hdevtools Version: 0.1.4.1-1 Severity: important Dear Maintainer, I tried using hdevtools as usual but running: ``` console $ echo 'main = putStrLn "hello"' > test.hs $ hdevtools check test.hs Run from outside a project, using implicit global project config ``` hdevtools hangs… Last time I ran it successfully, I think I was using GHC 7.10. Is it incompatible with GHC 8? Best regards -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hdevtools depends on: ii ghc 8.0.1-14 ii libc6 2.24-7 ii libffi6 3.2.1-6 ii libgmp10 2:6.1.1+dfsg-1 hdevtools recommends no packages. hdevtools suggests no packages. -- no debconf information
Bug#846022: nmu: mozvoikko_2.0.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 nmu mozvoikko_2.0.1-1 . ANY . stretch . -m "Rebuild to drop iceweasel Depends and migrate to firefox-esr (Closes: #819457)." - -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (, 'testing'), (1011, 'stable') Architecture: i386 (i586) Kernel: Linux 3.16.0-4-586 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iHgEARECADgWIQQ0UNMMeTbhfuC5+Dp5evnrHgy5zQUCWDtSChocbWFydGluLWVy aWMucmFjaW5lQGlraS5maQAKCRB5evnrHgy5zeJNAJ43qIdxdtYb7OAaUo3YjnKt 6JNwsQCgmGdNBonsLY5IByNAZfSRhLSi+cs= =LOxH -END PGP SIGNATURE-
Bug#839907: Minimal diff
Control: tags -1 + pending
On Sun, 2016-11-20 at 18:25 +, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
>
> On Wed, Oct 19, 2016 at 07:21:55PM +0200, Daniel Lange wrote:
> > Attached is a minimal diff that will - of course - not make a current
> > build tool chain happy ("dh_builddeb: This package will soon FTBFS; time
> > to fix it!").
>
> This looks better. The only tool chain which matters is Jessie's, so those
> warnings can be ignored.
>
> Your changelog has a couple of issues:
> - target distribution should be 'jessie'
> - version is a duplicate; does not follow the convention +debNuN,
>you probably want 20061030.1-2+deb8u1
>
> With those changes please go ahead, ensuring the package has been built in
> a 'jessie' environment only.
Uploaded and flagged for acceptance.
Regards,
Adam
Bug#845925: autopkgtest customize script for vmdebootstrap is unable to resolve httpredir.debian.org
Control: tag -1 unreproducible Johannes Schauer [2016-11-27 1:28 +0100]: > $ AUTOPKGTEST_APT_PROXY=http://127.0.0.1:3142 sudo vmdebootstrap --verbose > --serial-console --distribution=sid > --customize=/usr/share/autopkgtest/setup-commands/setup-testbed > --user=test/test --size=10 --grub --image=autopkgtest-sid.raw > Err:1 http://httpredir.debian.org/debian sid/main amd64 libdbus-1-3 amd64 > 1.10.12-1 > Temporary failure resolving 'httpredir.debian.org' I ran exactly the same command successfully on my box, with the same vmdebootstrap version, and http://httpredir.debian.org/debian works fine inside the VM. Was that perhaps a temporary network glitch? (Deutsche Telekom has failed DNS resolution today..) Do you get it without the $AUTOPKGTEST_APT_PROXY too? (I tried with an invalid one and the error looks different). Does httpredir.d.o work on your host? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#845443: jessie-pu: package nss-pam-ldapd/0.9.4-3+deb8u2
Control: tags -1 + pending On Thu, 2016-11-24 at 21:19 +0100, Salvatore Bonaccorso wrote: > Hi, > > On Thu, Nov 24, 2016 at 07:59:26PM +0100, Julien Cristau wrote: > > On Wed, Nov 23, 2016 at 14:19:24 +0100, Salvatore Bonaccorso wrote: > > > > > +nss-pam-ldapd (0.9.4-3+deb8u2) stable; urgency=medium > > > + > > > + * Non-maintainer upload. > > > + * have init script stop action only return when nslcd has actually > > > stopped > > > +(Closes: #814881) > > > + > > > + -- Salvatore Bonaccorso Wed, 09 Nov 2016 13:48:14 > > > +0100 > > > > > > and attached is the propsed debdiff. > > > > > > Would it be acceptable to include in for the next jessie point > > > release? > > > > > Yes please! > > Interpreted this as "Yes please, and upload", so I did :-). Flagged for acceptance; thanks. Regards, Adam
Bug#846021: ruby-webmock: FTBFS randomly (failing tests)
Package: src:ruby-webmock
Version: 1.22.6-1
Severity: serious
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:
[...]
debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
dh: Compatibility levels before 9 are deprecated (level 7 in use)
dh_testdir -i -O--buildsystem=ruby
dh_update_autotools_config -i -O--buildsystem=ruby
dh_auto_configure -i -O--buildsystem=ruby
dh_auto_configure: Compatibility levels before 9 are deprecated (level 7 in use)
dh_ruby --configure
dh_auto_build -i -O--buildsystem=ruby
dh_auto_build: Compatibility levels before 9 are deprecated (level 7 in use)
dh_ruby --build
dh_ruby --build
dh_auto_test -i -O--buildsystem=ruby
[... snipped ...]
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
â Run tests for ruby2.3 from debian/ruby-tests.rake
â
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
RUBYLIB=/<>/debian/ruby-webmock/usr/lib/ruby/vendor_ruby:.
GEM_PATH=debian/ruby-webmock/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
ruby2.3 -S rake -f debian/ruby-tests.rake
/usr/bin/ruby2.3 /usr/bin/rspec spec/acceptance/curb/curb_spec.rb
spec/acceptance/em_http_request/em_http_request_spec.rb
spec/acceptance/excon/excon_spec.rb spec/acceptance/http_rb/http_rb_spec.rb
spec/acceptance/httpclient/httpclient_spec.rb
spec/acceptance/manticore/manticore_spec.rb
spec/acceptance/net_http/net_http_spec.rb
spec/acceptance/net_http/real_net_http_spec.rb
spec/acceptance/typhoeus/typhoeus_hydra_spec.rb spec/unit/api_spec.rb
spec/unit/errors_spec.rb
spec/unit/http_lib_adapters/http_lib_adapter_registry_spec.rb
spec/unit/http_lib_adapters/http_lib_adapter_spec.rb
spec/unit/matchers/hash_including_matcher_spec.rb
spec/unit/rack_response_spec.rb spec/unit/request_body_diff_spec.rb
spec/unit/request_execution_verifier_spec.rb spec/unit/request_pattern_spec.rb
spec/unit/request_registry_spec.rb spec/unit/request_signature_snippet_spec.rb
spec/unit/request_signature_spec.rb spec/unit/request_stub_spec.rb
spec/unit/response_spec.rb spec/unit/stub_registry_spec.rb spec/unit
/stub_request_snippet_spec.rb spec/unit/util/hash_counter_spec.rb
spec/unit/util/hash_keys_stringifier_spec.rb spec/unit/util/headers_spec.rb
spec/unit/util/json_spec.rb spec/unit/util/query_mapper_spec.rb
spec/unit/util/uri_spec.rb spec/unit/util/version_checker_spec.rb
spec/unit/webmock_spec.rb -c -f progress -r ./spec/spec_helper.rb
[31mYou are using Curb 0.9.3. WebMock is known to work with Curb >= 0.7.16, <
0.9. It may not work with this version.[0m
No network connectivity. Only examples which do not make real network
connections will run.
Run options:
include {:focus=>true}
exclude {:without_webmock=>true, :net_connect=>true}
All examples were filtered out; ignoring {:focus=>true}
..
...
Bug#838780: jessie-pu: package irssi/0.8.17-1+deb8u1
Control: tags -1 + pending On Sat, 2016-10-01 at 18:24 +0100, Adam D. Barratt wrote: > Control: tags -1 -moreinfo +confirmed > > On Sun, 2016-09-25 at 11:44 +0200, Rhonda D'Vine wrote: > > Hi, > > > > * Adam D. Barratt [2016-09-24 21:24:18 CEST]: > > > On Sat, 2016-09-24 at 21:18 +0200, Rhonda D'Vine wrote: > > > > The patch that upstream provides is this: > > > > https://github.com/irssi/scripts.irssi.org/commit/f1b1eb154baa684fad5d65bf4dff79c8ded8b65a > > > > > > > > I uploaded it to unstable already and would like to push it to stable, > > > > too. > > > > > > That looks okay, but please could we have a source debdiff for the > > > proposed upload, as built and hopefully tested on jessie. > > > > I commited it locally to my git, the attached diff is > > "git diff HEAD^.." which was the commit from the security update. > > Thanks. That's not actually a debdiff though - the reason we ask for a > debdiff specifically is that the build process often ends up introducing > artefacts that aren't visible from a VCS diff or patch; additionally, > maintainers sometimes make "harmless" changes before building, which we > would have likely declined if they'd been included in the submitted > diff. > > Assuming that the debdiff does match the git diff supplied, please go > ahead. (Finally) uploaded and flagged for acceptance. Regards, Adam
Bug#845387: jessie-pu: package glibc/2.19-18+deb8u7
Control: tags -1 + pending On Fri, 2016-11-25 at 13:01 +0100, Aurelien Jarno wrote: > On 2016-11-24 20:13, Julien Cristau wrote: > > Control: tag -1 confirmed > > > > On Wed, Nov 23, 2016 at 00:07:31 +0100, Aurelien Jarno wrote: > > > > > I would like to upload a new glibc package for the next jessie release. > > > > Thanks for the detailed explanation. Looks fine to me. > > > > Thanks for the review, I have just uploaded the package. Flagged for acceptance; thanks. Regards, Adam
Bug#819457: xul-ext-mozvoikko: Please add firefox(-esr) as alternative dependencies
Package: xul-ext-mozvoikko Version: 2.0.1-1 Followup-For: Bug #819457 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Looking at the Debian source, all this needs to get fixed is a bin-NMU. The source Build-Depends on mozilla-devscripts which provides an extension that is called in [debian/rules] as 'dh --with xul-ext' so the Depends of the binary target will be automatically updated upon rebuild. - -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (, 'testing'), (1011, 'stable') Architecture: i386 (i586) Kernel: Linux 3.16.0-4-586 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-mozvoikko depends on: ii iceweasel 45.5.0esr-1 ii libvoikko1 4.0.2-2 ii voikko-fi 2.1-1 xul-ext-mozvoikko recommends no packages. xul-ext-mozvoikko suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHgEARECADgWIQQ0UNMMeTbhfuC5+Dp5evnrHgy5zQUCWDtQzxocbWFydGluLWVy aWMucmFjaW5lQGlraS5maQAKCRB5evnrHgy5zUrjAJ9VjWV9WJWj5N6PlLt0l3o9 76GkrwCeJnJbj7GfHs9uBMTjN3S4m6H5ETQ= =feFC -END PGP SIGNATURE-
Bug#845570: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2016j
Control: tags -1 + pending On Thu, 2016-11-24 at 19:52 +0100, gregor herrmann wrote: > On Thu, 24 Nov 2016 18:48:04 +, Adam D. Barratt wrote: > > > On Thu, 2016-11-24 at 19:31 +0100, gregor herrmann wrote: > > > I've prepared an update of libdatetime-timezone-perl for jessie. > > > The new version (manually stripped down debdiff attached) contains > > > the update to the Olson DB 2016j, as a quilt patch which only changes > > > the date files. > > > > Hurrah! Please go ahead. > > :) > Thanks; uploaded. Flagged for acceptance; thanks. Regards, Adam
Bug#846020: ruby-clockwork: FTBFS (Clockwork::DatabaseEvents::SyncPerformer::setup::when fails)
Package: src:ruby-clockwork Version: 1.2.0-3 Severity: serious Dear maintainer: I tried to build this package in stretch with "dpkg-buildpackage -A" (which is what the "Arch: all" autobuilder would do to build it) but it failed: [...] debian/rules build-indep dh build-indep --buildsystem=ruby --with ruby dh_testdir -i -O--buildsystem=ruby dh_update_autotools_config -i -O--buildsystem=ruby dh_auto_configure -i -O--buildsystem=ruby dh_ruby --configure dh_auto_build -i -O--buildsystem=ruby dh_ruby --build dh_ruby --build dh_auto_test -i -O--buildsystem=ruby dh_ruby --test fakeroot debian/rules binary-indep dh binary-indep --buildsystem=ruby --with ruby [... snipped ...] Clockwork::Event::#thread?::manager config thread option set to true#test_0001_is true = 0.00 s = . Clockwork::Manager::max_threads#test_0001_should warn when an event tries to generate threads more than max_threads = 0.00 s = . Clockwork::Manager::max_threads#test_0002_should not warn when thread is managed by others = 0.00 s = . Clockwork::DatabaseEvents::SyncPerformer::setup::arguments#test_0001_raises argument error if model is not set = 0.00 s = . Clockwork::DatabaseEvents::SyncPerformer::setup::arguments#test_0002_raises argument error if every is not set = 0.00 s = . Clockwork#test_0003_should pass event without modification to handler = 0.00 s = . Clockwork#test_0005_should pass all arguments to every = 0.00 s = . Clockwork#test_0004_should not run anything after reset = 0.00 s = . Clockwork#test_0002_should log event correctly = 0.00 s = . Clockwork#test_0006_support module re-open style = 0.00 s = . Clockwork#test_0001_should run events with configured logger = 0.00 s = . Clockwork::Manager::callbacks#test_0005_should run even jobs only = 0.00 s = . Clockwork::Manager::callbacks#test_0001_should not accept unknown callback name = 0.00 s = . Clockwork::Manager::callbacks#test_0004_should run before_run twice if two events are registered = 0.00 s = . Clockwork::Manager::callbacks#test_0002_should run before_tick callback once on tick = 0.00 s = . Clockwork::Manager::callbacks#test_0003_should not run events if before_tick returns false = 0.00 s = . Clockwork::Manager::callbacks#test_0006_should run after_run callback for each event = 0.00 s = . Clockwork::Manager::callbacks#test_0007_should run after_tick callback once = 0.00 s = . Clockwork::Manager:::if option#test_0002_:if false then never run = 0.00 s = . Clockwork::Manager:::if option#test_0001_:if true then always run = 0.00 s = . Clockwork::Manager:::if option#test_0003_:if the first day of month = 0.00 s = . Clockwork::Manager:::if option#test_0005_:if is not callable then raise ArgumentError = 0.00 s = . Clockwork::Manager:::if option#test_0004_:if it is compared to a time with zone = 0.01 s = . Clockwork::Manager:::tz option#test_0005_should be able to override a default timezone in an event = 0.01 s = . Clockwork::Manager:::tz option#test_0002_should be able to specify a different timezone than local = 0.00 s = . Clockwork::Manager:::tz option#test_0004_should be able to configure a default timezone to use for all events = 0.00 s = . Clockwork::Manager:::tz option#test_0001_time zone is not set by default = 0.00 s = . Clockwork::Manager:::tz option#test_0003_should be able to specify a different timezone than local for multiple times = 0.00 s = . Finished in 0.909811s, 93.4260 runs/s, 165.9686 assertions/s. 1) Failure: Clockwork::DatabaseEvents::SyncPerformer::setup::when database reload frequency is greater than model frequency period#test_0010_updates event at with new at [/<>/test/database_events/sync_performer_test.rb:161]: Expected: 1 Actual: 0 85 runs, 151 assertions, 1 failures, 0 errors, 0 skips rake aborted! Command failed with status (1): [ruby -I"test" "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/at_test.rb" "test/clockwork_test.rb" "test/database_events/sync_performer_test.rb" "test/event_test.rb" "test/manager_test.rb" "test/database_events/test_helpers.rb" -v] Tasks: TOP => default (See full trace by running task with --trace) ERROR: Test "ruby2.3" failed. Exiting. dh_auto_install: dh_ruby --install /<>/debian/ruby-clockwork returned exit code 1 debian/rules:6: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit status 2 The failure happens randomly. Sometimes it fails, sometimes it does not. It does happen, in fact, with a very low probability, but it also happened at least once in the reproducible builds autobuilder: https://tests.reproducible-builds.org/debian/logs/testing/amd64/ruby-clockwork_1.2.0-3.build2.log.gz The test seems to measure that a certain process takes a certain amount of time (reload
Bug#846019: pgadmin3: SIGABRT after fatal error complaint regarding libwxgtx ABI mismatch
Package: pgadmin3 Version: 1.22.2-1 Severity: grave Justification: renders package unusable Fatal Error: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8), and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8). Avbruten (SIGABRT) Perhaps related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844486. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pgadmin3 depends on: ii libc6 2.24-5 ii libgcc1 1:6.2.0-13 ii libpq59.6.0-1 ii libssl1.0.2 1.0.2j-1 ii libstdc++66.2.0-13 ii libwxbase3.0-0v5 3.0.2+dfsg-2 ii libwxgtk3.0-0v5 3.0.2+dfsg-2 ii libxml2 2.9.4+dfsg1-2.1 ii libxslt1.11.1.29-2 ii pgadmin3-data 1.22.2-1 ii zlib1g1:1.2.8.dfsg-2+b3 Versions of packages pgadmin3 recommends: ii pgagent3.4.1-3 ii postgresql-client 9.6+177 ii postgresql-client-9.6 [postgresql-client] 9.6.0-1 Versions of packages pgadmin3 suggests: pn postgresql-contrib -- no debconf information
Bug#813249: libupnp6: vlc fails to playback upnp provided content since upgrade to 1:1.6.19+git20160116-1
Control: tag 813249 + ipv6
Hello,
On Sun, Jan 31, 2016 at 02:44:51AM +0100, Uwe Kleine-König wrote:
> On 01/30/2016 11:05 PM, Uwe Kleine-König wrote:
> > Package: libupnp6
> > Version: 1:1.6.19+git20160116-1
> > Severity: normal
> >
> > Hello,
> >
> > vlc stopped showing my dlna provider, when downgrading libupnp6 to
> > 1:1.6.19+git20141001-1 it works fine again.
> >
> > With libupnp6 1:1.6.19+git20141001-1 the (I think) relevant part obtained
> > from strace is:
> >
> > 10317 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 18
> > 10317 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 19
> > 10317 setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
> > 10317 bind(18, {sa_family=AF_INET, sin_port=htons(49152),
> > sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> > 10317 bind(19, {sa_family=AF_INET6, sin6_port=htons(49152),
> > inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> > 28) = 0
> > 10317 listen(18, 128) = 0
> > 10317 getsockname(18, {sa_family=AF_INET, sin_port=htons(49152),
> > sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
> > 10317 listen(19, 128) = 0
> > 10317 getsockname(19, {sa_family=AF_INET6, sin6_port=htons(49152),
> > inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> > [28]) = 0
> >
> > while with 1:1.6.19+git20160116-1 I get:
> >
> > 10997 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 18
> > 10997 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 19
> > 10997 setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
> > 10997 bind(18, {sa_family=AF_INET, sin_port=htons(49152),
> > sin_addr=inet_addr("192.168.77.157")}, 16) = 0
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49152),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49153),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49154),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49155),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49156),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > ...
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65531),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65532),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65533),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65534),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > 10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65535),
> > inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> > 10997 close(18) = 0
> > 10997 close(19) = 0
> >
> > The obvious difference is that the newer libupnp uses an explicit
> > address for binding the port, but I don't see this as an excuse for bind
> > to fail. And in fact the same difference exists for ipv4 where there
> > doesn't seem to be a problem.
> >
> > btw, netcat-openbsd has the same problem:
> >
> > nc fe80::2ac6:8eff:fe36:df57 22
> >
> > fails with:
> >
> > connect(3, {sa_family=AF_INET6, sin6_port=htons(22),
> > inet_pton(AF_INET6, "fe80::2ac6:8eff:fe36:df57", &sin6_addr),
> > sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
> >
> > while it works fine when using the ipv4 or a global ipv6 of the same
> > machine.
btw, this works:
nc fe80::2ac6:8eff:fe36:df57%eth0 22
to specify the device. strace output changes to:
... sin6_scope_id=if_nametoindex("eth0")
> > So it seems to be a bad idea to use the link local ipv6. Without
> > checking the source code, for machines with >1 network device using the
> > wildcard address seems to be easier. Also it would be nice if libupnp
> > fell back to ipv4 only if it fail
Bug#844858: oggvideotools: FTBFS: decoderTest.cpp:19:41: error: 'memset' was not declared in this scope
On 11/19/2016 08:48 AM, Petter Reinholdtsen wrote: > [Lucas Nussbaum] >> During a rebuild of all packages in sid, your package failed to build on >> amd64. > > Thanks for noticing. Look like the compiler changed the system header > in some way. memset() is found in , according to its manual > page. > src/base/test/decoderTest.cpp does not import string.h. looks like the build works if you add #include to src/base/test/decoderTest.cpp. --- oggvideotools-0.9.1.orig/src/base/test/decoderTest.cpp +++ oggvideotools-0.9.1/src/base/test/decoderTest.cpp @@ -4,6 +4,7 @@ · #include "oggDecoder.h" #include +#include #include · int main(int argc, char* argv[])
Bug#845488: ITP: linux-firmware-raspi3 -- Raspberry Pi 3 GPU firmware and bootloaders
Given that the package has cleared the NEW queue by now, I’ve just done the rename and uploaded the new package. Will file a request for removal for the old one once the new one is in. On Fri, Nov 25, 2016 at 8:39 AM, Michael Stapelberg wrote: > Thanks for the hint, I did not realize that Ubuntu’s linux-firmware-* > hierarchy is actually firmware-* on Debian. > > What’s the best way to rename this package, given that it already sits in > the NEW queue? Do I need to talk to an ftp-master to remove it from there > and then do another upload? > > On Fri, Nov 25, 2016 at 1:34 AM, Ben Hutchings > wrote: > >> On Wed, 2016-11-23 at 22:37 +0100, Michael Stapelberg wrote: >> > Package: wnpp >> > Severity: wishlist >> > Owner: Michael Stapelberg >> > >> > * Package name: linux-firmware-raspi3 >> >> Is this really Linux-specific? If not, please consider dropping the >> 'linux-' part. >> >> Ben. >> >> > Version : 1.20161123 >> > Upstream Author : Raspberry Pi Foundation >> > * URL : https://github.com/raspberrypi/firmware >> > * License : Proprietary >> > Description : Raspberry Pi 3 GPU firmware and bootloaders >> > >> > This package contains all the proprietary files necessary to boot a >> > Raspberry Pi 3 board. >> > . >> > Raspberry Pi is a trademark of the Raspberry Pi Foundation. >> > >> > This package will be maintained by the newly created pkg-raspi team, and >> > is one of the last few pieces of the puzzle to create Debian images for >> > the Raspberry Pi 3. The package is based on the linux-firmware-raspi2 >> > package from Ubuntu. >> > >> -- >> Ben Hutchings >> [W]e found...that it wasn't as easy to get programs right as we had >> thought. >> ... I realized that a large part of my life from then on was going to >> be spent >> in finding mistakes in my own programs. - Maurice Wilkes, 1949 >> >> > > > -- > Best regards, > Michael > -- Best regards, Michael
Bug#844403: src:nfft: FTBFS on ppc64el
On Thu, 24 Nov 2016 18:49:29 -0200 Breno Leitao wrote: I am looking at this issue, and the first test set is checkall. If I run it inside dpkg-buildpackage, it fails as in the log, but, if I run it isolated, I see no errors, as showed: $ ./checkall 2>&1 | grep -i fail $ Looking all tests I see "-> OK". Anyway, I am continue to debug what is the problem here. It could be a lucky shot. Have you tried running them multiple times? If you look carefully at the log you will find that some tests have an unrealistically low tolerance value (in the order of 1E-322), which make them succeed when the difference is exactly 0 and fail otherwise. The other tests have an adequate tolerance value set (1E-16). I don't know enough about the codebase to tell you why these tolerances are different, but that's probably where the issue is. I would expect all tolerances to be in the same order (1E-16). Cheers, Ghis
Bug#845647: Missing file /usr/share/javascript/jquery-ui/ui/i18n/jquery-ui-i18n.js
Control: tags -1 -patch Hi, On 26-11-16 12:12, Paul Gevers wrote: > I'll check if the upstream build tar has these files and I'll check if > using grunt works now. If the file is there in either case, I'll ship > it, otherwise I'll dig deeper. It seems this file is not shipped upstream (at least, I can't locate it). And most dependencies to built jquery-ui with grunt aren't available in Debian yet. However, there seems to be an grunt target to build the global file, so I wonder what the intentions are upstream. I'll see how far I can get with catting and sedding the files. Paul signature.asc Description: OpenPGP digital signature
Bug#845990: simple-scan falls after three images scaning
Hello Alex, thank you for spending your time helping to make Debian better with this bug report. Oldstable has only support for security updates. I don't see any security at your bugreport. So I close this bug. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser Threema: SYR8SJXB IRC: j_...@freenode.net j_...@oftc.net My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#822793: closed by to...@debian.org (Dr. Tobias Quathamer) (Bug#822793: fixed in rclone 1.34-1)
Thanks for this. -- Sean Whitton signature.asc Description: PGP signature
Bug#844601: python-spyder: "from spyder.plugins.editor import Editor" hangs the machine
And qt also does not produces exceptions, and that's by design. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#845664: closed by Bastian Blank (Re: [Pkg-xen-devel] Bug#845663: xen: CVE-2016-9386: x86 null segments not always treated as unusable)
Hi Bastian, > Hi Salvatore > > On Fri, Nov 25, 2016 at 07:35:18PM +0100, Salvatore Bonaccorso wrote: > > Source: xen > > Version: 4.4.1-9 > > Security bugs in stable are handled by the security team. There is no > need to write bugs. I'm closing them. Well, no the bugs affect as well src:xen as in unstable and to be included in stretch. Please open them appropriately. I took the work to report them according to the respective XSAs which is not only for stable/jessie. It is not really nice to get bugs closed with above explanation :-( Regards, Salvatore
Bug#846017: jessie-pu: package ieee-data/20150531.1~deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu Hi there, I would like to remove the cron job in ieee-data (closes: #826104) since we are DDoS IEEE servers every month. I was hopping that the amount of stable installations were gentle with their servers, but I underestimate the amount of Debian installations (and overestimated the IEEE servers). Anyway, I still getting reports from people that we are getting fetching problems. So, here is the patch. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru ieee-data-20150531.1~deb8u1/debian/changelog ieee-data-20150531.1~deb8u2/debian/changelog --- ieee-data-20150531.1~deb8u1/debian/changelog 2015-12-20 09:58:11.0 -0500 +++ ieee-data-20150531.1~deb8u2/debian/changelog 2016-11-27 14:21:34.0 -0500 @@ -1,3 +1,9 @@ +ieee-data (20150531.1~deb8u2) stable; urgency=high + + * Crontab update disable. Closes: #826104 + + -- Luciano Bello Sun, 27 Nov 2016 14:21:34 -0500 + ieee-data (20150531.1~deb8u1) stable; urgency=medium * New iab.txt url updated. diff -Nru ieee-data-20150531.1~deb8u1/debian/ieee-data.cron.monthly ieee-data-20150531.1~deb8u2/debian/ieee-data.cron.monthly --- ieee-data-20150531.1~deb8u1/debian/ieee-data.cron.monthly 2014-10-19 14:20:43.0 -0400 +++ ieee-data-20150531.1~deb8u2/debian/ieee-data.cron.monthly 1969-12-31 19:00:00.0 -0500 @@ -1,3 +0,0 @@ -#!/bin/sh -test -x /usr/bin/update-oui || exit 0 -BASEDIR=/var/lib/ieee-data/ /usr/bin/update-oui -f -q
Bug#846016: devscripts: debuild clean fails with bad invocation of dpkg-buildpackage
Package: devscripts Version: 2.16.10 Severity: important Hi, dpkg-buildpackage -rfakeroot -us -uc --hook-check=cd ..; clean --check-command=lintian dpkg-buildpackage: error: unknown option or argument clean Use --help for program usage information. debuild: fatal error at line 1100: dpkg-buildpackage -rfakeroot -us -uc --hook-check=cd ..; clean --check-command=lintian failed Regards, Jérémy -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- Not present -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-rc5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages devscripts depends on: ii dpkg-dev 1.18.15 ii libc62.24-7 ii perl 5.24.1~rc4-1 pn python3:any Versions of packages devscripts recommends: ii apt 1.4~beta1 ii at 3.1.20-1 ii curl7.51.0-1 ii dctrl-tools 2.24-2 ii debian-keyring 2016.09.04 ii dput-ng [dput] 1.10 ii dupload 2.7.0 ii equivs 2.0.9+nmu1 ii fakeroot1.21-2 ii file1:5.29-1 ii gnupg 2.1.16-2 ii gnupg2 2.1.16-2 pn libdistro-info-perl ii libencode-locale-perl 1.05-1 ii liblwp-protocol-https-perl 6.06-2 ii libsoap-lite-perl 1.20-1 ii liburi-perl 1.71-1 ii libwww-perl 6.15-1 ii licensecheck3.0.28-1 ii lintian 2.5.49 ii man-db 2.7.5-2 ii patch 2.7.5-1 ii patchutils 0.3.4-2 ii python3-debian 0.1.29 ii python3-magic 1:5.29-1 ii sensible-utils 0.0.9 ii strace 4.13-0.1 ii unzip 6.0-20 ii wdiff 1.2.2-1+b1 ii wget1.18-4 ii xz-utils5.2.2-1.2 Versions of packages devscripts suggests: ii adequate 0.15.1 ii autopkgtest 4.2.1 pn bls-standalone ii bsd-mailx [mailx]8.1.2-0.20160123cvs-3 ii build-essential 12.2 pn check-all-the-things pn cvs-buildpackage pn devscripts-el ii diffoscope 62 pn disorderfs pn dose-extra pn duck pn faketime ii gnuplot 5.0.5+dfsg1-4 ii gpgv 2.1.16-2 ii how-can-i-help 14 ii libauthen-sasl-perl 2.1600-1 ii libfile-desktopentry-perl0.22-1 pn libnet-smtps-perl ii libterm-size-perl0.207-1+b4 ii libtimedate-perl 2.3000-2 pn libyaml-syck-perl pn mozilla-devscripts pn mutt ii openssh-client [ssh-client] 1:7.3p1-3+b1 pn piuparts pn ratt pn reprotest pn svn-buildpackage ii w3m 0.5.3-33 -- no debconf information
Bug#845941: [Pkg-dns-devel] Bug#845941: unbound FTCBFS: uninstallable python Build-Depends, configures for the build architecture
Helmut Grohne wrote: > Can you apply the attached patch? Hi, Helmut: Applied and uploaded. Thanks again! -- Robert Edmonds edmo...@debian.org
Bug#812219: Bug#812237: pkg-perl-autopkgtest: provide a way to override the default list of smoke tests
Version: 0.29 On Thu, Jan 21, 2016 at 10:21:23PM +0200, Niko Tyni wrote: > > Unfortunately debian/tests/pkg-perl/smoke-files doesn't currently > > support wildcards. It should probably be enhanced to do so. I don't > > see other clean fixes for this as we don't want to hardcode the > > list of tests. > > Hm, smoke-files doesn't really cut it anyway, we'll need something like > smoke-tests that defaults to t/*.t and/or test.pl. Not quite sure how > it should work together with smoke-skip... This seems to have been fixed by Axel (thanks!): pkg-perl-tools (0.29) unstable; urgency=medium * pkg-perl-autopkgtest/build-deps.d/smoke now also supports debian/tests/pkg-perl/smoke-tests to list which tests should be run by prove instead of the default "t/*.t". -- Axel Beckert Fri, 22 Apr 2016 00:14:47 +0200 So closing (but notifying #812219 in libimager-perl). -- Niko
Bug#845194: amd64-microcode: please make the early initramfs image reproducible
On Sun, 27 Nov 2016, Chris Lamb wrote: > Henrique de Moraes Holschuh wrote: > > Please test the attached patch. Does it pass all the reproducibility > > testing? > > Not quite; I needed to make the following change to your patch: > > - CHANGELOG_TS :=$(shell date +%s > + CHANGELOG_TS :=$(shell date --utc +%s > > .. then it was reproducible. :) Ah, ok. Thanks for the review! > FYI to check this yourself you will need to: > > a) Apply my patch in #845034 against initramfs-tools. > > b) Use cpio 2.12 or later, which is not in sid. However, I have backported > the parts required in #804063. > > c) Export SOURCE_DATE_EPOCH to update-initramfs Good point. Thanks! -- Henrique Holschuh
Bug#837574: Patch for the qemu PIE FTBFS
On Fri, Nov 04, 2016 at 10:17:01AM +, Riku Voipio wrote: >... > Adrian, can you submit this to qemu-devel mailing list > for upstream with your Signed-off-by? >... Apologies for the delay, it's now submitted: http://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04835.html > Riku cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#828603: Building with OpenSSL 1.0.2 is sufficient for stretch
Control: tags -1 patch Not a perfect solution but sufficient for stretch is the patch below to use OpenSSL 1.0.2 The "| libssl-dev (<< 1.1.0~)" is added for backports. --- debian/control.old 2016-11-27 19:37:52.0 + +++ debian/control 2016-11-27 19:37:56.0 + @@ -7,7 +7,7 @@ autotools-dev, libdb-dev, libpam0g-dev, - libssl-dev, + libssl1.0-dev | libssl-dev (<< 1.1.0~), libxplc0.3.13-dev, libpopt-dev, zlib1g-dev, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#839383: RFS: php-net-idna2/0.1.1-1 [ITP]
> Hi, > > thanks for the answer! I sponsored it. > Hi Gianfranco Costamagna, Thank you very much for your help. :) Regards Rajasekhar Ponakala
Bug#843890: Monitoring child processes
On Sat, 19 Nov 2016 19:12:43 -0400, Jesse Smith wrote: > While I'm still in the early testing stages of this and working to make > the code cross-platform, you can test it now if you like by downloading > the development snapshot here: > http://resonatingmedia.com/cpulimit/cpulimit-2.4.tar.gz [..] > Again, this is a testing snapshot. It seems to be working okay for me on > Debian, but I still need to make sure the code compiles and works on > other platforms. If I don't get any bug reports, I'm finish my tweaks > and then publish the new 2.4 version on the LimitCPU website. Thanks for publishing the 2.4 release now. Uploaded to Debian/unstable right now. And thanks again for picking up feature requests from Debian users! Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Stan Getz: Take Five signature.asc Description: Digital Signature
Bug#845932: Please enable FriendlyARM NanoPi NEO
On 2016-11-27, Paul Tagliamonte wrote: > Awesome. I preformed these steps, but I haven't attached a Serial > device to it yet. > > I'll continue testing further after I hook this up to serial Looks like you may also have to borrow a .dtb from linux 4.9.x: https://packages.debian.org/search?suite=experimental§ion=all&arch=armhf&searchon=contents&keywords=sun8i-h3-nanopi-neo.dtb Just copy that onto the debian-installer media in the dtbs directory. Not sure if it'll work, but if it does, you might want to request a backport of it to the linux kernel packages. Happy testing! live well, vagrant > On Sun, Nov 27, 2016 at 3:25 AM, Vagrant Cascadian > wrote: >> On 2016-11-26, Paul Tagliamonte wrote: >>> Please enable FriendlyARM NanoPi NEO >> >> Thanks for taking a stab at it! >> >> >> Built a test package for you, should be available here: >> >> deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main >> >> Install u-boot-sunxi:armhf from there, which has nanopi_neo included (in >> fact, all other builds are disabled). >> >> >> To test, you could use debian-installer's daily images: >> >> https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ >> >> Download firmware.none.img.gz and partition.img.gz, and then something >> like (just like it says in the README*): >> >> zcat firmware.none.img.gz partition.img.gz | dd of=/dev/mmcblk0 >> >> >> Then, reading /usr/share/doc/u-boot-sunxi/README.Debian, you can install >> the nanopi_neo u-boot image: >> >> dd if=/usr/lib/u-boot/nanopi_neo/u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 >> bs=1024 seek=8 >> >> >> Then you ought to be able to see u-boot load on the serial console, and >> if you're lucky, boot into debian-installer. You may need a USB network >> adapter to get very far... >> >> >> If the u-boot bits at least work, I'll be happy to add it to the >> package, and add you to our list of testers. A rough guide to testing is >> available here: >> >> https://wiki.debian.org/U-boot >> >> >> Hmmm, now that I've written this email, some of it would be generally >> useful to add to the wiki page... >> >> >> live well, >> vagrant > > > > -- > :wq signature.asc Description: PGP signature
Bug#845030: Using OpenSSL 1.0.2 is an option for stretch
Not a perfect solution but sufficient for stretch is the patch below to use OpenSSL 1.0.2 The "| libssl-dev (<< 1.1.0~)" is added for backports. --- debian/control.old 2016-11-27 19:00:22.0 + +++ debian/control 2016-11-27 19:00:30.0 + @@ -20,7 +20,7 @@ libxinerama-dev, dctrl-tools, libarchive-dev, - libssl-dev, + libssl1.0-dev | libssl-dev (<< 1.1.0~), zlib1g-dev, libunwind8-dev [amd64 armel armhf i386 mips powerpc ppc64], dh-autoreconf (>= 6~), cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#846015: chromium 54.0.2840.101-1 crashes on gmail.com
Package: chromium Version: 54.0.2840.101-1 Severity: grave Justification: renders package unusable Dear maintainers, same here, updating to 54.0.2840.101-1 makes chromium crash on the website gmail.com, with "Aw snap" message; please find below the message found when launching chromium from command line. Reverting to testing version 53.0.2785.143-1 solves the issue. I suspect the problem is coming from hi-resolution (my screen is HD 3200x1800) ; indeed: - with 53.0.2785.143-1 i have to start chromium with the command chromium --force-device-scale-factor=1.8 otherwise scaling is wrong (fonts too small). - a previous 53 version on unstable was also crashing on gmail.com with "Aw snap" - for the version 54.0.2840.101-1, starting either from 'chromium' command or 'chromium --force-device-scale-factor=1.8' gives the same correct scaling Best, Ara --- Trace message : --- libpng warning: iCCP: known incorrect sRGB profile Received signal 11 SEGV_MAPERR 0028 #0 0x55cb7377bd0e #1 0x55cb7377c0c9 #2 0x7f5008a42100 #3 0x55cb7607b4e5 #4 0x55cb760f3c6c #5 0x55cb76279935 #6 0x55cb7627a88e #7 0x55cb7627a591 #8 0x55cb7627a591 #9 0x55cb7627a971 #10 0x55cb760fb1b9 #11 0x55cb760fc67e #12 0x55cb760fc8bc #13 0x55cb75dc50e9 #14 0x55cb75f1bbdd #15 0x55cb754f265c #16 0x55cb743e7dda #17 0x55cb743f1643 #18 0x55cb737fe550 #19 0x55cb754ae0af #20 0x55cb754ae6f5 #21 0x55cb737fe550 #22 0x55cb7379afca #23 0x55cb7379c77d #24 0x55cb7379cc20 #25 0x55cb7379d879 #26 0x55cb737ba25a #27 0x55cb76b24af2 #28 0x55cb73396b94 #29 0x55cb7339710f #30 0x55cb73395321 #31 0x55cb71e8fffa ChromeMain #32 0x7f4ffe92f2b1 __libc_start_main #33 0x55cb71e8feaa _start r8: 0640 r9: r10: r11: r12: 0d30b3a8d9f8 r13: 0001 r14: r15: 7ffcd7bc2e20 di: si: 2fbd33620bf0 bp: bx: dx: 0001 ax: 2fbd3360e7d8 cx: 0327 sp: 7ffcd7bc2ae8 ip: 55cb7607b4e5 efl: 00010283 cgf: 002b0033 erf: 0004 trp: 000e msk: cr2: 0028 [end of stack trace] -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/8 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 chromium depends on: ii libasound2 1.1.2-1 ii libatk1.0-0 2.22.0-1 ii libavcodec57 10:3.0-dmo4 ii libavformat5710:3.0-dmo4 ii libavutil55 10:3.0-dmo4 ii libc62.24-7 ii libcairo21.14.6-1.1 ii libcups2 2.2.1-2 ii libdbus-1-3 1.10.12-1 ii libevent-2.0-5 2.0.21-stable-2.1 ii libexpat12.2.0-1 ii libflac8 1.3.1-4 ii libfontconfig1 2.11.0-6.7 ii libfreetype6 2.6.3-3+b1 ii libgcc1 1:6.2.1-5 ii libgdk-pixbuf2.0-0 2.36.0-1 ii libglib2.0-0 2.50.2-2 ii libgtk2.0-0 2.24.31-1 ii libharfbuzz0b1.2.7-1+b1 ii libjpeg62-turbo 1:1.5.1-2 pn libminizip1 ii libnettle6 3.3-1 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1 ii libpango-1.0-0 1.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libpng16-16 1.6.26-2 ii libpulse09.0-5 pn libre2-3 ii libsnappy1v5 1.1.3-3 ii libstdc++6 6.2.1-5 ii libvpx4 1.6.0-3 ii libwebp6 0.5.1-3 ii libwebpdemux20.5.1-3 ii libx11-6 2:1.6.3-1 ii libxcomposite1 1:0.4.4-1 ii libxcursor1 1:1.1.14-1+b1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes3 1:5.0.2-1 ii libxi6 2:1.7.6-1.1 ii libxml2 2.9.4+dfsg1-2.1 ii libxrandr2 2:1.5.0-1 ii libxrender1 1:0.9.9-2 ii libxslt1.1 1.1.29-2 ii libxss1 1:1.2.2-1 ii libxtst6 2:1.2.2-1+b1 ii x11-utils7.7+3 ii xdg-utils1.1.1-1 ii zlib1g 1:1.2.8.dfsg-2+b3 Versions of packages chromium recommends: ii fonts-liberation 1:1.07.4-2 Versions of packages chromium suggests: ii chromium-l10n 54.0.2840.101-1 -- no debconf information
Bug#804063: cpio: New upstream release 2.12 available
retitle 804063 cpio: New upstream release 2.12 available thanks > There is a new vesion available including some improvements > which would be nice to get into Debian Anibal, would you be against my uploading 2.12 to experimental? :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#845977: [PATCH] debian/extra/kernel-install.d/85-initrd.install: Remove an unnecessary variable.
Control: tag -1 pending Hello Alexander, Alexander Kurtz [2016-11-27 13:49 +0100]: > The attached patch fixes a bug which causes "kernel-install remove" to > fail; please review. Makes complete sense, thanks for spotting this! Applied. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Bug#838249: RM: python-pypdf -- ROM; It was replaced by python-pypdf2
On Friday, 14 October 2016 08:47:13 EST Scott Kitterman wrote: > There is also rst2pdf (it's a reverse build-depends). Please remove the > moreinfo tag once it's fixed. Done. See #840801 Thanks! /luciano
Bug#844601: python-spyder: "from spyder.plugins.editor import Editor" hangs the machine
On Sun, Nov 27, 2016 at 06:22:52PM +, PICCA Frederic-Emmanuel wrote: > > In other words: if you want to use Qt you *need* a QApplication instance. > > That's Qt basics. Not using it is a bug. > > I understand, > > Nervertheless I think that the python binding should fail gracefully with > an exception instead of segfaulting... PyQt is just a binding, handling segfaults in underlying code is not its responsibility. Moreover, it cannot distinguish segfaults because of missing QApplication from other kinds of segfaults. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#846014: gnuplot-doc: gnuplot-doc has invalid info-dir-entry
Package: gnuplot-doc Version: 5.0.5+dfsg1-4 Severity: normal Hi, Current info for gnuplot-doc is "gnuplot.info.gz". But info-dir-entry of "gnuplot.info.gz" has, START-INFO-DIR-ENTRY * GNUPLOT5: (gnuplot5). An Interactive Plotting Program END-INFO-DIR-ENTRY So, by mismatch of "(gnuplot5)" vs "gnuplot.info.gz", the info browser finds "gnuplot5.info.gz", instead of "gnuplot.info.gz". E.g. $ info gnuplot5 [info says "Unable to find node referenced by 'GNUPLOT5' in '(dir)Top'."] -- System Information: Debian Release: stretch/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.10 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) -- OGAWA Hirofumi
Bug#846013: gthumb: recommends on gstreamer0.10-gnomevfs, which is no longer in unstable/testing
Package: gthumb Version: 3:3.4.4.1-2 Severity: important This recommends the no-longer-present package gstreamer0.10-gnomevfs. This should be fixed before stretch is released. Best wishes, Julian -- System Information: Debian Release: stretch/sid APT prefers jessie APT policy: (500, 'jessie'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gthumb depends on: ii gsettings-desktop-schemas 3.22.0-1 ii gthumb-data 3:3.4.4.1-2 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-5 ii libcairo-gobject2 1.14.6-1.1 ii libcairo2 1.14.6-1.1 ii libclutter-1.0-01.26.0+dfsg-1 ii libclutter-gtk-1.0-01.8.2-1 ii libcogl-pango20 1.22.2-2 ii libcogl-path20 1.22.2-2 ii libcogl20 1.22.2-2 ii libdrm2 2.4.73-1 ii libegl1-mesa [libegl1-x11] 12.0.4-2 ii libexiv2-14 0.25-3 ii libgbm1 12.0.4-2 ii libgcc1 1:6.2.0-13 ii libgdk-pixbuf2.0-0 2.36.0-1 ii libglib2.0-02.50.2-1 ii libgstreamer-plugins-base1.0-0 1.10.1-1 ii libgstreamer1.0-0 1.10.1-1 ii libgtk-3-0 3.22.3-2 ii libjavascriptcoregtk-4.0-18 2.14.2-1 ii libjpeg62-turbo 1:1.5.1-2 ii libjson-glib-1.0-0 1.2.2-1 ii liblcms2-2 2.7-1 ii libpango-1.0-0 1.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libpng16-16 1.6.26-2 ii libraw150.17.2-6 ii librsvg2-2 2.40.16-1 ii libsecret-1-0 0.18.5-2 ii libsoup2.4-12.56.0-1 ii libstdc++6 6.2.0-13 ii libtiff54.0.7-1 ii libwayland-client0 1.11.0-2 ii libwayland-cursor0 1.11.0-2 ii libwayland-egl1-mesa [libwayland-egl1] 12.0.4-2 ii libwayland-server0 1.11.0-2 ii libwebkit2gtk-4.0-372.14.2-1 ii libwebp60.5.1-2 ii libx11-62:1.6.3-1 ii libxcomposite1 1:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext62:1.3.3-1 ii libxfixes3 1:5.0.2-1 ii libxi6 2:1.7.6-1.1 ii libxkbcommon0 0.6.1-1 ii libxrandr2 2:1.5.0-1 ii zlib1g 1:1.2.8.dfsg-2+b3 Versions of packages gthumb recommends: ii bison 2:3.0.4.dfsg-1 ii flex2.6.1-1+b1 pn gstreamer0.10-gnomevfs ii gvfs-bin1.30.2-2 ii libgphoto2-62.5.10-3 ii libgphoto2-port12 2.5.10-3 gthumb suggests no packages. -- no debconf information
Bug#844601: python-spyder: "from spyder.plugins.editor import Editor" hangs the machine
> In other words: if you want to use Qt you *need* a QApplication instance. > That's Qt basics. Not using it is a bug. I understand, Nervertheless I think that the python binding should fail gracefully with an exception instead of segfaulting... Cheers
Bug#844601: python-spyder: "from spyder.plugins.editor import Editor" hangs the machine
In other words: if you want to use Qt you *need* a QApplication instance. That's Qt basics. Not using it is a bug. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#845989: [Pkg-privacy-maintainers] Bug#845989: marked as done (browser can't be downloaded because of invalid SSL certificate)
Hello, look like the problem is caused by missing "DigiCert SHA2 High Assurance Server CA" certificate on my debian testing system. (I check the same on other computer with debian stable and it was OK). Look below and pay attention to messages: 1) unable to get local issuer certificate 2) Verify return code: 20 (unable to get local issuer certificate) This results in failing of python OpenSSL library and finished by "You may be under attack" message during initial installation of torbrowser. kl@flywind:~$ openssl s_client -connect dist.torproject.org:443 CONNECTED(0003) depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA verify error:num=20:unable to get local issuer certificate --- Certificate chain 0 s:/C=US/ST=Massachusetts/L=Cambridge/O=The Tor Project, Inc./ CN=*.torproject.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/ CN=DigiCert SHA2 High Assurance Server CA 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/ CN=DigiCert SHA2 High Assurance Server CA i:/C=US/O=DigiCert Inc/OU=www.digicert.com/ CN=DigiCert High Assurance EV Root CA --- Server certificate -BEGIN CERTIFICATE- MIIFaTCCBFGgAwIBAgIQDGnVmapHXfa3m9oYQq3WQTANBgkqhkiG9w0BAQsFADBw MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz dXJhbmNlIFNlcnZlciBDQTAeFw0xNjA0MTUwMDAwMDBaFw0xOTA1MjkxMjAwMDBa MHQxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRIwEAYDVQQH EwlDYW1icmlkZ2UxHjAcBgNVBAoTFVRoZSBUb3IgUHJvamVjdCwgSW5jLjEZMBcG A1UEAwwQKi50b3Jwcm9qZWN0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALcjOe3IaIUn5YEOnAAM+uIlKm0HyHUaR6rwU0m5YhdSV8DRGUB80Q67 zkIbutTMbEla8KpPSqsK/FShSXhLWB6Hv5UV2jR6/Pzxi8QaLMMAuLT5oHCkR6Jn LFZrUtPq50RmhYfg15kwosmEzPqLa3NDcK5tpTX5F48DvBT+0aCZQLndKGzVhiJI pEJdfTc69b1i4xGyhzp4ChUFDtmK9MRZFRvDFl4ZaVBe2haw/+1kemGwh5UuaD+P DqTJl+xwQdUCrKWBgwnOVLJKqrp2/Yc0mkkTFXqdUD1BS+wgvCDi64f7ndyyTQgb 8IWoWEeF6KHbiFZLVR/puH64cbyRF8cCAwEAAaOCAfkwggH1MB8GA1UdIwQYMBaA FFFo/5CvAgd1PMzZZWRiohK4WXI7MB0GA1UdDgQWBBSCJgjxEylVNBS0j4Adcbhg 2ktBzDArBgNVHREEJDAighAqLnRvcnByb2plY3Qub3Jngg50b3Jwcm9qZWN0Lm9y ZzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC MHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zaGEy LWhhLXNlcnZlci1nNS5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv bS9zaGEyLWhhLXNlcnZlci1nNS5jcmwwTAYDVR0gBEUwQzA3BglghkgBhv1sAQEw KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAIBgZn gQwBAgIwgYMGCCsGAQUFBwEBBHcwdTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au ZGlnaWNlcnQuY29tME0GCCsGAQUFBzAChkFodHRwOi8vY2FjZXJ0cy5kaWdpY2Vy dC5jb20vRGlnaUNlcnRTSEEySGlnaEFzc3VyYW5jZVNlcnZlckNBLmNydDAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQCwURSDN25h03L4cN8+FFi6ZbzP OxIh8GgLKljF2nO/qW8gjKIOUgNizf99lsnn7YaYPCr8W9IZQBp64aWsWwuWZ3w8 bRhklFCmgHhDFeLCqmScYwxYlCmSL2qRe8Dus4t8Axse7LEni6KcOFA3Dtssc3MA jv30cEvGJru0mcogoMh8O04hmWZfC1EiyBLDDb5mBhijtMN+SbNQSr53mZWTgMXh luVXp48Z8RTrOdLJ03ArAh2gfpOLUz3eGmynpTFPz+l3V3yRHyoeWFiZUbm0ePnx 1HyeNR3onMNJC/tbYIBNoz/tIEPpFqJ1P3AT8q+uy/OQR4DEoG3f3Syq1pBG -END CERTIFICATE- subject=/C=US/ST=Massachusetts/L=Cambridge/O=The Tor Project, Inc./ CN=*.torproject.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/ CN=DigiCert SHA2 High Assurance Server CA --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3283 bytes and written 302 bytes Verification error: unable to get local issuer certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 610A3292E75EEFA38CA322D9C34ECA27C18D2E02E8200DD9DA8009BB4E99B654 Session-ID-ctx: Master-Key: F285EAAFB2AAE5CA3E495A1C8FE7D216CA9CADD366212077D823940DF9B4831C6E967B0C4989E75FBEE35877ADE5F015 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: - 3f d5 f2 67 6e 36 33 ab-8d 21 f1 68 0a cd 70 73 ?..gn63..!.h..ps 0010 - 5b 59 e8 6d 55 ec 18 71-fa 58 0f 19 3f b6 0f d8 [Y.mU..q.X..?... 0020 - af b1 95 57 8d fb b6 bc-49 09 7a 4b 7e 11 b0 96 ...WI.zK~... 0030 - 8c f3 6f 7e cd db 2e 40-2c 59 d7 5c 60 85 fa 78 ..o~...@,Y.\`..x 0040 - 93 2b 5c a1 63 e2 3e 28-e8 e1 7a 09 c7 34 ed 09 .+\.c.>(..z..4.. 0050 - 4e d0 54 82 ab cd 7e 35-e1 ee 3b 34 40 b1 e8 2e N.T...~5..;4@... 0060 - 19 2b 5b 3f b6 ca 36 8f-a1 e7 fe fa ff 99 db ff .+[?..6. 0070 - 3f 2b bb 59 bc 91 d0 0d-2e a9 3b 86 e8 6e 05 11 ?+.Y..;..n.. 0080 - f6 fc 5b c3 af 75 16 1f-f7 00 63 ab c3 97 6f 89 ..[..uc...o. 0090 - f8 bb be 16 f2 13 d9 5c-4d 62 23 4f c3 3c c1 b0 ...\Mb#O.<.. 00a0 - 70 c2 ad cc 54 e9 3e 81-de
Bug#842862: virtualbox-qt: Crashes if screen reader enabled
Control: reassign -1 libqt5widgets5
Control: affects -1 virtualbox-qt
Hello,
Samuel Thibault, on Sun 27 Nov 2016 18:29:07 +0100, wrote:
> > On a Debian testing with upstream repo's package:
> >
> > 1.Install qt-at-spi
> > 2.Enable accessibility in the Desktop.
> > 3.Run VirtualBox.
> > 4.Arrow keys, opening dialogs, crash the graphical interface.
> > 5. Run without Orca running.
> > 6.Arrow keys work. Run again screen reader, it crashes as soon as you
> > press an arrow key..
>
> More precisely, I had to enter File->Preferences a couple of times to
> get the segfault.
Here is the corresponding backtrace. This is running version
5.7.1~20161021-dfsg-6 of qtbase.
The segfault is on the callq assembly instruction:
0x7f8317db0bf1 <+65>: callq *0x18(%r8)
(gdb) p/x ($r8+0x18)
0x20002c003e0085
(gdb) p/x *(unsigned long*)($r8+0x18)
Cannot access memory at address 0x20002c003e0085
(gdb) p index
(gdb) p role
11
(gdb) up
(gdb) p/x m_index
{r = 0xd, c = 0, i = 0x556f56c43340, m = 0x556f56c2c770}
(gdb) p/x *((QTreeWidgetItem*) (m_index->i))
{_vptr.QTreeWidgetItem = 0x20002c003e006d, rtti = 0x61004d, values = {d =
0x20006f006c0065}, view = 0x6c0065006f0043,
d = 0x3c0020006f0068, par = 0x6300720061006d, children =
{> = {}, {
p = {static shared_null = {ref = {atomic = {_q_value =
{> = {static _S_alignment = 0x4,
_M_i = 0x}, }}}, alloc = 0x0, begin =
0x0, end = 0x0, array = {0x0}},
d = 0x63006f006c0065}, d = 0x63006f006c0065}}, itemFlags = {i =
0x65006f}}
that looks a very bogus object to me indeed. From the backtrace, it
looks like it was obtained in AtSpiAdaptor::handleMessage by calling
AtSpiAdaptor::interfaceFromPath, i.e. using
QAccessible::accessibleInterface, i.e. using
QAccessibleCache::interfaceForId, i.e. using the
QAccessibleCache::idToInterface hashtable.
It should be noted that virtualbox uses threads. It could be that there
is a race in qaccessiblecache.cpp between a thread that is trying to
remove a widget, and a thread which is trying to access it as requested
by the screen reader. Is that handled somehow in the accessibility layer
of Qt5?
Samuel
(gdb) bt
#0 0x7f8317db0bf1 in QTreeModel::data (this=, index=...,
role=11) at itemviews/qtreewidget.cpp:371
#1 0x7f8317d2e235 in QAccessibleTableCell::text (this=0x556f56c6e370,
t=)
at accessible/itemviews.cpp:1078
#2 0x7f8314b05bcb in AtSpiAdaptor::accessibleInterface
(this=this@entry=0x556f56913c50, interface=interface@entry=
0x556f56c6e370, function=..., message=..., connection=...) at
linuxaccessibility/atspiadaptor.cpp:1414
#3 0x7f8314b06919 in AtSpiAdaptor::accessibleInterface
(this=0x556f56913c50, interface=0x556f56c6e370, function=...,
message=..., connection=...) at linuxaccessibility/atspiadaptor.cpp:1368
#4 0x7f8314b0ad2c in AtSpiAdaptor::handleMessage (this=0x556f56913c50,
message=..., connection=...)
at linuxaccessibility/atspiadaptor.cpp:1282
#5 0x7f831c07be88 in QDBusConnectionPrivate::activateObject
(this=0x7f82f800fc20, node=..., msg=..., pathStartPos=27)
at qdbusintegrator.cpp:1449
#6 0x7f831c07e8ee in QDBusActivateObjectEvent::placeMetaCall
(this=0x7f82f80139c0) at qdbusintegrator.cpp:1608
#7 0x7f831cba1b39 in QObject::event (this=0x556f56913c50, e=) at kernel/qobject.cpp:1263
#8 0x7f8317af6b2c in QApplicationPrivate::notify_helper (this=, receiver=0x556f56913c50,
e=0x7f82f80139c0) at kernel/qapplication.cpp:3799
#9 0x7f8317afe2e1 in QApplication::notify (this=0x7ffedd52b320,
receiver=0x556f56913c50, e=0x7f82f80139c0)
at kernel/qapplication.cpp:3556
#10 0x7f831cb75090 in QCoreApplication::notifyInternal2
(receiver=0x556f56913c50, event=event@entry=0x7f82f80139c0)
at kernel/qcoreapplication.cpp:988
#11 0x7f831cb7781d in QCoreApplication::sendEvent (event=0x7f82f80139c0,
receiver=)
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
#12 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0,
event_type=event_type@entry=0,
data=0x556f564f0640) at kernel/qcoreapplication.cpp:1649
#13 0x7f831cb77c88 in QCoreApplication::sendPostedEvents
(receiver=receiver@entry=0x0, event_type=event_type@entry=0)
at kernel/qcoreapplication.cpp:1503
#14 0x7f831cbc92d3 in postEventSourceDispatch (s=0x556f565b1ef0) at
kernel/qeventdispatcher_glib.cpp:276
#15 0x7f83157bc7f7 in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x7f83157bca60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x7f83157bcb0c in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x7f831cbc96df in QEventDispatcherGlib::processEvents
(this=0x556f565b1e20, flags=...)
at kernel/qeventdispatcher_glib.cpp:423
#19 0x7f831cb7307a in QEventLoop::exec (this=this@entry=0x7ffedd52a6e0,
flags=..., flags@entry=...)
at kernel/qeventloop.cpp:212
#20 0x7f831e0102c7 in QI
Bug#839818: NMU of gnome-packagekit
2016-11-26 18:16 GMT+01:00 Dr. Tobias Quathamer : > Dear Matthias, > > as the freeze is approaching and the fix for this bug is so simple, I took > the liberty to prepare an NMU for gnome-packagekit and upload it to > DELAYED/5. > > Please find my changes attached to this mail, they are based against your > git repo on Alioth and could be applied with "git am". Hey, sorry for taking so long with this. I had an upload planned for this weekend, including this change - should be on its way to the archive now. Thanks for caring about this! I just now noticed that there is a NMU (post-upload), otherwise I would have included it's changes directly... Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Bug#845304: transition: libxtables12
Hi! On Tue, 2016-11-22 at 10:49:11 +0100, Arturo Borrero Gonzalez wrote: > On 22 November 2016 at 10:39, Emilio Pozuelo Monfort wrote: > > To the maintainer: Why bump to a snapshot at this point in the cycle? Have > > the > > rdeps been build-tested against the new libxtables? Are you aware we are in > > the > > transition freeze and this is a transition? > I bumped to a snapshot release because several people asked me to do so. I was one of those. The changes in the snapshot are requiered for the various translation tools, to convert from the legacy iptables to nftables command-line syntax, or to be able to inject rules into the nftables using iptables commands and syntax, otherwise the tools do not see each others rulesets. I'm sorry this has caused grief for Arturo and the Release Team. :( We had an in-person chat several days ago with the principal iptables/nftables developer and we mentioned that having an actual release would be helpful, and he said that he might be doing that soonish? I can understand why you'd prefer a revert at this point in time, although I think it's worth considering that given that this transition has already been started (even though, unfortunately, via an accident), that it involves very few packages, that it will have a positive effect on people wanting to migrate to use nftables in Stretch, that the upload was done in good faith, and reverting might be messy as well, perhaps it actually it's worth letting it in? OTOH, the conversion is usually a one-off thing, so I guess this could be handled via backports or on another system with more up-to-date userland. On Tue, 2016-11-22 at 12:05:35 +, Simon McVittie wrote: > On Tue, 22 Nov 2016 at 10:49:11 +0100, Arturo Borrero Gonzalez wrote: > > I missed the point that libxtables (which is in src:iptables) added a > > few new symbols that triggers transitions. > > Wait, *added* a few new symbols? It also changes the «struct xtables_match», which is passed and returned as part of the public API. So the SOVERSION bump seems warranted to me (upstream commit 7a0992da44cfb6cab0ccd1beadcf326df8773552). Thanks, Guillem
