Bug#848309: RM: configshell -- ROM; superseded by configshell-fb, from new LIO-fb upstream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: ftp.debian.org Severity: normal The configshell upstream is not active to our expectations. Thus we switched the LIO stack from LIO to LIO-fb. https://tracker.debian.org/pkg/python-configshell-fb - -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhTng0ACgkQpjpYo/Lh dWlrvBAAq6hHktlS5SLtkJk/KVdlX9fF3si4Vrc7fmWBrx+iun4JLSnNF+nwPw9A iSdQR+OCf6vHe5C65SInlx/F2e2KHeCpGY+Jftv6wBEQSpKrFYw+h6+Vmc+dZMls SSuQXbnxsKrt59baL9nUTN/meuB8VBhYrGM0HkZYhiJ0TYJTshB0zB5kJk18xQzN 8fdhUhM5vYy7fCsl92kS+v3vQSJNsT1rxMYmw9ejw/hrg785MIrjU86Z7kjmQ0Xi c4/lPzuVHpnA012NJdnEH6HpCU7p/gHkRtRteTuZzqQ/xNZC4TVFL8jKMTtFjH4o UE1g5HwtC0GYInB64UhPu2/Jhr0dHiWS8gt59HMz+rvImi17vkEHz9LIrrit7eOO m9eyytojnS1g6MI2ksa8rsKuHx8h92EqPXJQ60rQvSQKhCizxnQTQvoIe7dogbfo wEzBm7146gpKJ71Bv5hm5jehWKK6FADQ2Ui++J4SMZzb+knT+GWCLgjpS7ZLJI2t tRINZ/jm6eDm3SvR1wEG1wQk0GJmKFbDWDQiyLgdQx+k4U8qLb4qculg4yPTKoUw lCAAGBFu+D2zJxJ85OqPtJt4vhtqSqDtijStKgclFU7tslez3Y4Z5yGA37+2yq4z ddHD2PIbHaZWzPh1H/Rj/nsOsLv74j2idltac8B4GcQglBOoj38= =PlO4 -END PGP SIGNATURE-
Bug#819314: procps: [sysctl] Missing dependency when used with systemd
On Fri, Dec 16, 2016 at 12:27:10AM +0100, Michael Biebl wrote: > It would be cleaner if that was shipped in ifupdown itself, but in > jessie, systemd also provides ifup@.service. Both were mistakes in > hindsight, which I'm not sure is worth fixing retroactively. > > Guus, do you have any preference here. Do you want to take over that > file from systemd and make a jessie stable upload? > If not, I'd add the After ordering to the jessie systemd package. If it's the same to you, I think it's safer to keep the ifup@.service in jessie's systemd package, and just add the After there. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#848310: RM: targetcli -- ROM; superseded by targetcli-fb, from new LIO-fb upstream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: ftp.debian.org Severity: normal The targetcli upstream is not active to our expectations. Thus we switched the LIO stack from LIO to LIO-fb. New, working and maintained packaging is at https://tracker.debian.org/pkg/targetcli-fb - -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhTnsEACgkQpjpYo/Lh dWnqnQ/+JRx+hHau8wj1+0pcoGjnk9ECsPQOr86zK8zMJt/IiG0JzCd0BLhPUbas ht2w0NNGa9P+w1pukMQKo5mYu7WbHU8eyYEkDwlBZtQwNgObh/VpUPebHJGe8MRJ mvoZ0DovYoCkLXg0Pc2dWnOfTJT6RKhtnn5OG4sXrFUFYuINP0RJBUHmk3o7C4X4 P5SYMa8IrqHQwcjWOnF+NaRa2afp4B0KvIxuiur97C3+rXnyLtr9SmIsPP7mQq+B 3Ns3gCs4CC1R40bochagl9HsllZSLkWx/2jXGkKDcOuc6OaDE5P2bG9nuvMqTTYk DWSi5tvaSDFN7hD6SCTeom1VITx65Gjr+95SztFuPivUIm8+/55mkRne73ai4g7E F9vdgX5vRpe9q8/5TAF3ZZa7ofnQXyLBKLxme4ZtQWMWTRpWpW9rf5IHeGC3so/c VBs9SRfBTdjep/5drgI4AwnmmUQzXThbkruTpTEStxneqq0IpwN109eeicin63hc SFfHHC1qwavNR1zqEsBp4ascUk+VFd0i85PlfTAEg9TyPSxzoMB+r+b7BXQrUpT+ 24muqhUhjbQZ0EDOnNguAfzhr6YFFk2TBRH5uJuqc69uLbdMRD5RJD/yj8Dke7wk FFphG75ArnP1wUnSCxhneBoa3PjVyOtR4cIvd2+emWYFKWgH7tw= =XC9a -END PGP SIGNATURE-
Bug#848298: mongodb: Build for s390x
On Fri, Dec 16, 2016 at 2:38 AM, Apollon Oikonomopoulos wrote: > Thanks for the heads-up. Although I'm not completely opposed to the > idea, there are at least two important reasons I think we should not do > this for 3.2 (and thus I'm marking it as wontfix, at least for now): I understand if you're hesitant to add the large patchset to the package you have to maintain for stretch. Hopefully, it will be a lot easier once 3.4 is packaged. Thanks, Jeremy Bicha
Bug#848311: new upstream (1.4.0)
Package: netdata Severity: important Hi, thanks for maintaining netdata. however, the 1.3.0 version has several limitations, e.g: - doesn't work at all on systems with many cpus (reproducible on an 88 core server here), it just fails to display anything at all - doesn't work inside containers where it also fails to display anything at all fortunatly, all of the above and much more is fixed in the current upstream version (1.4.0). Therefore, please upload 1.4.0. Regards, Daniel
Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57
Hi, >export DEB_BUILD_MAINT_OPTIONS=noopt > >to the top of d/rules and rebuilding should do it. it worked: DEB_BUILD_OPTIONS=noopt dpkg-buildpackage [...] dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libxerces-c-samples/usr/bin/SAXPrint debian/libxerces-c-samples/usr/bin/SEnumVal debian/libxerces-c-samples/usr/bin/SAX2Count debian/libxerces-c-samples/usr/bin/SAXCount debian/libxerces-c-samples/usr/bin/EnumVal debian/libxerces-c-samples/usr/bin/XInclude debian/libxerces-c-samples/usr/bin/PParse debian/libxerces-c-samples/usr/bin/StdInParse debian/libxerces-c-samples/usr/bin/SAX2Print debian/libxerces-c-samples/usr/bin/DOMPrint debian/libxerces-c-samples/usr/bin/DOMCount debian/libxerces-c-samples/usr/bin/PSVIWriter debian/libxerces-c-samples/usr/bin/Redirect debian/libxerces-c-samples/usr/bin/MemParse debian/libxerces-c-samples/usr/bin/SCMPrint debian/libxerces-c-samples/usr/bin/CreateDOMDocument were not linked against libicudata.so.57 (they use none of the library's symbols) dh_installdeb dh_gencontrol dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dh_md5sums dh_builddeb dpkg-deb: building package 'libxerces-c-dev' in '../libxerces-c-dev_3.1.4+debian-1_s390x.deb'. dpkg-deb: building package 'libxerces-c3.1-dbgsym' in '../libxerces-c3.1-dbgsym_3.1.4+debian-1_s390x.deb'. dpkg-deb: building package 'libxerces-c3.1' in '../libxerces-c3.1_3.1.4+debian-1_s390x.deb'. dpkg-deb: building package 'libxerces-c-doc' in '../libxerces-c-doc_3.1.4+debian-1_all.deb'. dpkg-deb: building package 'libxerces-c-samples-dbgsym' in '../libxerces-c-samples-dbgsym_3.1.4+debian-1_s390x.deb'. dpkg-deb: building package 'libxerces-c-samples' in '../libxerces-c-samples_3.1.4+debian-1_s390x.deb'. dpkg-genbuildinfo dpkg-genbuildinfo: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-genchanges >../xerces-c_3.1.4+debian-1_s390x.changes dpkg-genchanges: info: including full source code in upload dpkg-source --after-build xerces-c-3.1.4+debian dpkg-buildpackage: info: full upload (original source is included) G.
Bug#848274: Pending fixes for bugs in the libparse-debianchangelog-perl package
tag 848274 + pending thanks Some bugs in the libparse-debianchangelog-perl package are closed in revision b09039b1a184cd1b335f7fc10114b6796980beea in branch 'master' by Christoph Biedl The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libparse-debianchangelog-perl.git/commit/?id=b09039b Commit message: Fix errorneous escaping and formatting in Parse::DebianChangelog documentation. Closes: #848274
Bug#848247: [Pkg-libvirt-maintainers] Bug#848247: Collection of fixes for libvirt smoke tests
On Fri, Dec 16, 2016 at 08:03:09AM +0100, Christian Ehrhardt wrote: > On Thu, Dec 15, 2016 at 6:26 PM, Guido Günther wrote: > > > Thanks for these. I've pulled parts in but I thins some are not needed: > > > > Thanks for all the applied's removing those and continuing discussion on > the remaining ones. > > > > > > > > d/t/control, d/t/smoke-qemu-session, d/t/smoke-lxc: fix up smoke tests > > > > > > ERR: error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': > > No > > > such file or directory > > > FIX: install libvirt-daemon-system > > > > No, we run as non-root so (so we can use qemu:///session) > > > > Yeah - I think I'm good with that. > Initially when in the autopkgtest env I think I missed to export that > properly. > I later fixed it up for my tests on the lxc tests and things were ok. > > One thing I also found without "needs-root" was that the > `virt-host-validate qemu` failed on /dev/kvm being root/root and thereby > not accessible from non-root. > Is /dev/kvm set up differently by default on Debian so that it is > accessible to you? > > Other than the discussion I think I need adapt and rerun when I re-merge to > your next release with the other fixes accepted here in place. > I'd come back to this bug with more detail then if I still would need > anything of the needs-root/libvirt-daemon-system. The user running the tests has access to /dev/kvm here. If we want to avoid that we should move virt-host-validate to a separate test since this test is especially meant for qemu:///session. > > > ERR: arch can be x86_64 > > > FIX: modify grep "arch name='x86_64'" -> "arch.*x86_64"" > > > > Which versions did you see this with? > > > > In terms of qemu still an older one as merging that will follow libvirt, so > atm a combination of libvirt 2.5-experimental and qemu 2.6.1. > Both with Ubuntu Delta, but I'd doubt that would change this part of the > behavior. > But if it is the qemu version - then for all sorts of backporting activity > (if ever) it might be useful to have the more relaxed regexp I suggested. > > > > > ERR: potential race, guest dies on most non bare metal platforms after a > > few > > > seconds > > > FIX: well, not a fix but add FIXME comment on 2nd level virtualization > > > issues > > > > I'm not sure how this helps here. > > > > Well it does not "help", it was just a reminder for myself when going > through the code. > I'm perfectly fine not applying that one for now and just forgetting it. > > A real fix would be a guest that does not insist on all the features and > would boot up just fine (I haven't found kernel parameters to do so and > building an extra guest for that seems over-engineering). > > > > ERR: potential race on the check of lxc log after start > > > FIX: lacking a better fix a sleep and sync to closen the remaining > > > race window > > > > Hmm...did you see this? If so we should rather check for running again > > with virsh and then check the log. > > > > No I haven't seen it in this test, but I had an almost equal test a while > ago (start, check for running) which worked on x86. > But then when the tests spread to other architectures it sometimes failed > on ppc64el and almost always on s390x. I think that can't happen here but I'm happy to be proven otherwise. I'll close the bug with the next upload but please follow up with more issues in case you run into them. Cheers, -- Guido
Bug#848312: approx: Approx fails to work at all
Package: approx Version: 5.7-2 Severity: important Dear Maintainer, Approx used to work fine on this server. At some point a few weeks ago it simply stopped working. I am guessing it was an upgrade to of approx (5.7 from 5.4?) or some change in the systemd configuration at the same time that caused the problem. However I was not able to investigate at the time, I just had to switch all the machines to individual working rather than using the approx system. I have just retried and there is no approx service registered and no access to port on the server. Whilst I have added things to the /etc/approx/approx.conf file, I have not fiddles with the approx files in any other way. I thus have the "out of the box" configuration other than extra lines in the one configuration file. On the one hand the problem has a workaround, on the other approx is basically unusable and so this is a crtitical bug. I am hoping that this is a problem at my end I am fearing that approx is no unusable in perpituity -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages approx depends on: ii adduser 3.115 ii bzip21.0.6-8 ii curl 7.51.0-1 ii debconf [debconf-2.0]1.5.59 ii libc62.24-8 ii libpcre3 2:8.39-2 ii rsyslog [system-log-daemon] 8.23.0-2 ii update-inetd 4.43 ii xz-utils 5.2.2-1.2 approx recommends no packages. Versions of packages approx suggests: pn libconfig-model-approx-perl -- Configuration Files: /etc/approx/approx.conf changed [not included] -- debconf information: approx/port:
Bug#847273: jessie-pu: package mapserver/6.4.1-5
On 12/06/2016 10:00 PM, Sebastiaan Couwenberg wrote: > Sorry for the outdated debdiff, for p-u the distribution has been > changed to stable. With mapserver (7.0.3-1) having migrated to testing and the subsequent update of the backport, CVE-2016-9839 is now fixed everywhere except in jessie itself. I'd like to fix that, can I go ahead? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#848314: Further fix for discussion in the scope of smoke-qemu-session
Package: libvirt Version: 2.5.0-1 Severity: normal This is a continuation of debbug 848247. But you said you want to close that with next upload but I should come back. While the tests are now working fine in local autopkgtest I was throwing them at launchpad this night. And I think there I had a case where the discussion on "virt-host-validate qemu". Maybe we should use it as an early exits as in the lxc case - to detect incompatible environments. I've seen this: + virt-host-validate qemu QEMU: Checking for hardware virtualization : PASS QEMU: Checking if device /dev/kvm exists : FAIL (Check that the 'kvm-intel' or 'kvm-amd' modules are loaded & the BIOS has enabled virtualization) [...] + virsh start sqs error: Failed to start domain sqs error: unsupported configuration: Domain requires KVM, but it is not available. Check that virtualization is enabled in the host BIOS, and host configuration is setup to load the kvm modules. That is IMHO due to only having "isolation-container", but could even happen in isolaton-machine dependin on the setup. The TL;DR that I suggest is: 1. tampering with (actually more depending on) modules => needs isolation-machine 2. if virt-host-validate qemu fails use it as an early exit (as you agreed for the lxc case) as the env won't be good (in some way at least) to later on in the test really start the guests I kept the needs-root for now in my local delta, it will still use the qemu:/// connection since the env is set. So for now I'd suggest to add: diff --git a/debian/tests/control b/debian/tests/control index f965827..c4f5244 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -5,7 +5,7 @@ Restrictions: allow-stderr Tests: smoke-qemu-session Depends: libvirt-daemon-system, libvirt-clients, qemu-system, libxml2- utils, qemu-kvm -Restrictions: allow-stderr, isolation-container, needs-root +Restrictions: allow-stderr, isolation-machine, needs-root Tests: smoke-lxc Depends: libvirt-daemon-system, libvirt-clients, libxml2-utils diff --git a/debian/tests/smoke-qemu-session b/debian/tests/smoke-qemu- session index c238308..968a3f3 100755 --- a/debian/tests/smoke-qemu-session +++ b/debian/tests/smoke-qemu-session @@ -29,7 +29,7 @@ if [ $(uname -m) != "x86_64" ]; then fi echo echo "Running as $USER" -virt-host-validate qemu || true +virt-host-validate qemu || exit 0 virsh capabilities virsh capabilities | grep -qs "arch.*x86_64" virsh capabilities | grep -qs 'os_type>hvm' P.S. FYI I found another issue with the smoke-lxc on s390x but haven't debugged it yet - I'll let you know as soon as I know anything more. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
Bug#848315: ITP: node-cheerio -- Server-side jQuery implementation
Package: wnpp Severity: wishlist Owner: Paolo Greppi X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-cheerio Version : 0.22.0 Upstream Author : Matt Mueller (mat.io) * URL : https://github.com/cheeriojs/cheerio#readme * License : Expat Programming Lang: JavaScript Description : Server-side jQuery implementation Node-js module providing a tiny, fast, flexible and elegant implementation of core jQuery designed specifically for the server. . Node.js is an event-based server-side JavaScript engine. It is a requirement of etherpad-lite (https://bugs.debian.org/576998). My intention is to package it within the javascript maintainers team. The repo will be on alioth: https://anonscm.debian.org/git/pkg-javascript/node-cheerio.git Paolo
Bug#848316: etcd: I saw that A new upstream version is available: 3.0.15 - Is this possible to upgrade ?
Source: etcd Severity: wishlist Dear Maintainer, On https://tracker.debian.org/pkg/etcd I saw that a new upstream version is available: 3.0.15 - Is this possible to upgrade ? -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 3.16.0-4-powerpc64le (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#848313: appdirs: copyright file does not mention Eddy Petrisor
Source: appdirs Version: 1.4.0-2 Severity: minor The copyright file only mentions ActiveState, but the file appdirs.py has a second copyright line for the newer version on line 4, which should be in the copyright file. 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)
Bug#824532: Udev rules for U2F devices
Hi, Based on the discussion in #824532, it seems there is a consensus for splitting the udev rules for U2F devices in a separate package. I took the liberty of doing exactly that, and prepared an upload. Best, Nicolas signature.asc Description: PGP signature
Bug#848314: [Pkg-libvirt-maintainers] Bug#848314: Further fix for discussion in the scope of smoke-qemu-session
On Fri, Dec 16, 2016 at 10:02:23AM +0100, Christian Ehrhardt wrote: > Package: libvirt > Version: 2.5.0-1 > Severity: normal > > This is a continuation of debbug 848247. > But you said you want to close that with next upload but I should come back. > > While the tests are now working fine in local autopkgtest I was throwing > them at launchpad this night. > And I think there I had a case where the discussion on "virt-host-validate > qemu". > > Maybe we should use it as an early exits as in the lxc case - to detect > incompatible environments. > I've seen this: > + virt-host-validate qemu > QEMU: Checking for hardware virtualization > : PASS > QEMU: Checking if device /dev/kvm exists > : FAIL (Check that the 'kvm-intel' or 'kvm-amd' modules are loaded & the > BIOS has enabled virtualization) > > [...] > > + virsh start sqs > error: Failed to start domain sqs > error: unsupported configuration: Domain requires KVM, but it is not > available. Check that virtualization is enabled in the host BIOS, and host > configuration is setup to load the kvm modules. > > That is IMHO due to only having "isolation-container", but could even > happen in isolaton-machine dependin on the setup. The fix is to use qemu not kvm in the domain XML in this case. -- Guido
Bug#848233: sphde FTBFS on mips and mipsel: missing mips32 support
Hello Radovan, patches you provided for this bug and #844613 have been applied upstream. If you don't mind, I'll ask a new release to sphde team to have support for mips* and I'll update the packaging with your pie patch. Thanks a lot for all the work you did on mips*, F. On Thu, 15 Dec 2016 13:28:09 +, Radovan Birdic wrote: > Package: sphde > Version: 1.3.0-1 > Severity: important > Tags: sid + patch > Justification: FTBFS > User: debian-m...@lists.debian.org > Usertags: mips-patch > > > Package sphde_1.3.0-1 FTBFS on mips and mipsel with following error: > > > /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/6/crtbeginT.o: relocation > > R_MIPS_HI16 against `a local symbol' can not be used when making a shared > > object; recompile with -fPIC > > /usr/lib/gcc/mipsel-linux-gnu/6/crtbeginT.o: error adding symbols: Bad value > > collect2: error: ld returned 1 exit status > > Full build log: > https://buildd.debian.org/status/fetch.php?pkg=sphde&arch=mipsel&ver=1.3.0-1&stamp=1473250605 > > First, we need to remove "-pie" flag from LDFLAGS (for mips and mipsel > arches) to reslove mentioned error. > After that, build fails because there is no support for mips32 architecture. > We need to define proper addresses (__SAS_BASE_ADDRESS, RegionSize, > SegmentSize and __SAS_SHMAP_MAX) for mips/mipsel into "sasconf.h" file. > > I have created and attached a patches that includes these changes and > resolves these issues. > Patch remove-pie-for-mips32.patch removes "pie" flag from LDFLAGS for > mips/mipsel. > Patch add-mips32-support.patch adds support for mips/mipsel architectures. > > Note: > First it is necessary to apply the patch I have proposed here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844613 > > > With these patches package builds successfully. > > Regards, > Radovan> --- sphde-1.3.0_orig/debian/rules2016-08-31 12:40:30.0 > + > +++ sphde-1.3.0/debian/rules 2016-12-15 09:07:47.0 + > @@ -7,6 +7,11 @@ ifeq ($(shell dpkg-architecture -qDEB_HO > export DEB_LDFLAGS_MAINT_STRIP = -pie > endif > > +ifneq (,$(filter $(shell dpkg-architecture -qDEB_HOST_ARCH),mips mipsel)) > + export DEB_LDFLAGS_MAINT_STRIP = -pie > +endif > + > + > %: > dh $@ --with autoreconf,pkgkde_symbolshelper > > --- sphde-1.3.0.orig/src/sasconf.h > +++ sphde-1.3.0/src/sasconf.h > @@ -86,6 +86,13 @@ > # define __SAS_SHMAP_MAX 0x000100L /* 16MB */ > #endif > > +#ifdef __mips__ > +# define __SAS_BASE_ADDRESS 0x6000UL/* 1,5GB */ > +# define RegionSize 0x1000UL/* 256MB */ > +# define SegmentSize 0x0100UL/* 16MB */ > +# define __SAS_SHMAP_MAX 0x0100UL/* 16MB */ > +#endif > + > /* > * If the platform is not recognized above, select some resonable default. > */
Bug#843638: same problem
folkert wrote: > Tried building it from source (apt-get source + dpkg-buildpackage) You seem to forget "apt-get build-dep". - Fabian
Bug#774164: libocrad-dev: libocrad.a contains non-reallocatable code
On Thu, Dec 15, 2016 at 09:42:08PM +0100, Petter Reinholdtsen wrote: > > Personally I use tesseract these days for my OCR work, and do not need ocrad. I have unfortunately stopped using ocrad in favour of proprietary solutions. Thanks for adding me to the recipient list, but I don't have the motivation to help here. Added Jakub Wilk to copy, IIRC he made the package. Thanks. -- Mit freundlichen Grüßen Alexander Alemayhu
Bug#818978: systemd crashes in lxc on container stop
On Fri, 16 Dec 2016 00:40:10 +0100 Michael Biebl wrote: This was fixed upstream by https://github.com/systemd/systemd/commit/ad2706db7cceba69203f3ac2b6ef65d7490c5f29 Attached is a backport of that patch for v215 Confirmed. That fix works here too. The 'deb http://apt.osso.nl/debian jessie systemd' has been updated with your patch, in case anyone was using that. Cheers, Walter Doekes OSSO B.V.
Bug#848314: [Pkg-libvirt-maintainers] Bug#848314: Further fix for discussion in the scope of smoke-qemu-session
On Fri, Dec 16, 2016 at 10:07 AM, Guido Günther wrote: > The fix is to use qemu not kvm in the domain XML in this case. If that is the way to go - to focus on testing qemu:/// - that is right. The current call to virt-host-validate qemu already has a || true so it is not fatal which is good. What do you think of something like the following then (untested so far): (this is based on my current d/t/control so your diff might be slightly different. That gets more similar again when I rebase to your latest code early next week.) diff --git a/debian/tests/control b/debian/tests/control index c4f5244..cd15424 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -4,7 +4,7 @@ Restrictions: allow-stderr Tests: smoke-qemu-session Depends: libvirt-daemon-system, libvirt-clients, qemu-system, libxml2-utils, - qemu-kvm + qemu-user Restrictions: allow-stderr, isolation-machine, needs-root Tests: smoke-lxc diff --git a/debian/tests/smoke-qemu-session.xml b/debian/tests/smoke-qemu-session.xml index 47b33d5..c471ff2 100644 --- a/debian/tests/smoke-qemu-session.xml +++ b/debian/tests/smoke-qemu-session.xml @@ -1,4 +1,4 @@ - + sqs 256000 256000 @@ -18,7 +18,7 @@ destroy destroy -/usr/bin/kvm +/usr/bin/qemu-x86_64 -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
Bug#845157: systemd: loading compressed modules no longer works
On Nov 21, M G Berberich wrote: > But libkmod was held on 22-1, because debian libkmod does not support > compressed modules. > Upgrading to (a modified) 23-1 did solve the problem. > There seems to be some incompatibility between 22-1 and 23-1 that is > not reflected in the libraries major-number. I do not understand what this is about: the Debian kmod package has never supported compressed modules. -- ciao, Marco signature.asc Description: PGP signature
Bug#848314: [Pkg-libvirt-maintainers] Bug#848314: Further fix for discussion in the scope of smoke-qemu-session
On Fri, Dec 16, 2016 at 10:31:58AM +0100, Christian Ehrhardt wrote: > On Fri, Dec 16, 2016 at 10:07 AM, Guido Günther wrote: > > > The fix is to use qemu not kvm in the domain XML in this case. > > > If that is the way to go - to focus on testing qemu:/// - that is right. > The current call to virt-host-validate qemu already has a || true so it is > not fatal which is good. > > What do you think of something like the following then (untested so far): > (this is based on my current d/t/control so your diff might be slightly > different. > That gets more similar again when I rebase to your latest code early next > week.) > > diff --git a/debian/tests/control b/debian/tests/control > index c4f5244..cd15424 100644 > --- a/debian/tests/control > +++ b/debian/tests/control > @@ -4,7 +4,7 @@ Restrictions: allow-stderr > > Tests: smoke-qemu-session > Depends: libvirt-daemon-system, libvirt-clients, qemu-system, > libxml2-utils, > - qemu-kvm > + qemu-user You want qemu-system running as non root not qemu-user. > Restrictions: allow-stderr, isolation-machine, needs-root > > Tests: smoke-lxc > diff --git a/debian/tests/smoke-qemu-session.xml > b/debian/tests/smoke-qemu-session.xml > index 47b33d5..c471ff2 100644 > --- a/debian/tests/smoke-qemu-session.xml > +++ b/debian/tests/smoke-qemu-session.xml > @@ -1,4 +1,4 @@ > - > + > sqs > 256000 > 256000 > @@ -18,7 +18,7 @@ > destroy > destroy > > -/usr/bin/kvm > +/usr/bin/qemu-x86_64 Like this but using qemu-system-x86_64. Thanks for looking into this! -- Guido > > >function='0x0'/> > > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd
Bug#848317: smoke-lxc on different architectures
Package: libvirt Version: 2.5.0-1 Severity: normal Hi, continuing to iron out the smoke tests as I really would like to get them running stable across all environments and architectures on the 2.5 release. This time I ran the tests (in the somewhat in flight state that we are discussing in other bugs) on all architectures. I found issues on s390x where container-in-container seems not to work as usual for now. I succeeded to run the test on Bare Metal and in a KVM Guest, but in a container I face issues when I want to start the guest. These look like this on automated tests: + virsh start sl error: Failed to start domain sl error: internal error: guest failed to start: 2016-12-16 07:41:53.195+000 Not a lot of info to deal with, so I set up manually and even when fixing up a few minor things I still can't pass over the following error: # virsh start sl error: Failed to start domain sl error: internal error: guest failed to start: Failure in libvirt_lxc startup: Failed to mount devpts on /var/run/libvirt/lxc/sl.devpts: Permission denied I haven't found much more on it - we could in the long term, but I'd like to get it working now if possible. One possible solution would be to do an x86 only like on the qemu test a la: if [ $(uname -m) != "x86_64" ]; then ... Another one could be to restrict it for now to isolation-machine - that seems to get around the issue. That would allow to run on more platforms than pure x86 only - not sure thou what is better. diff --git a/debian/tests/control b/debian/tests/control index cd15424..3a30399 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -9,7 +9,7 @@ Restrictions: allow-stderr, isolation-machine, needs-root Tests: smoke-lxc Depends: libvirt-daemon-system, libvirt-clients, libxml2-utils -Restrictions: allow-stderr, needs-root +Restrictions: allow-stderr, needs-root, isolation-machine Tests: build-test Depends: libvirt-dev, build-essential, pkg-config -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
Bug#809068: Backport to jessie
Please backport to jessie. I have exactly the same problem here and will - meanwhile - patch the packet myself. Regards, Robert
Bug#847018: zfs-dkms: fails to build against kernel version 4.8.0-2-amd64i
Hi I have create the Packages with pbuilder and it works, very nice :) Thanks...
Bug#848129: pie-link specs should not be passed when pie is not enabled
2016-12-15 23:26 GMT+01:00 Matthias Klose : > On 15.12.2016 13:27, Guillem Jover wrote: >> Hi! >> >> On Wed, 2016-12-14 at 12:54:41 +0100, Matthias Klose wrote: >>> Package: dpkg-dev >>> Version: 1.18.15 >>> Severity: important >>> Tags: sid stretch >>> >>> This is seen on all architectures where pie is not enabled by default. These >>> specs should not be passed when pie is not in effect. >> >> I assume you mean enabled by default by gcc. > > No, this particular build log doesn't show any -fPIE/-pie flags, so it is > neither enabled by dpkg-buildflags nor by gcc. > >>> Seen only when looking at the python2.7 ftbfs on x32. And verified that >>> the python2.7 build succeeds again when the specs are not passed. >> >> If python2.7 does not build with the PIE spec files on x32 that means >> that either there's a portability issue on x32 in python2.7, or that >> there's a more fundamental problem with x32 and PIE (f.ex. openssl1.0 >> also only fails on x32 with PIE specs, see #845193, although openssl >> builds fine there). >> >> If the latter, I'd be fine with blacklisting PIE on x32 as "not yet >> working", so that it cannot be enabled at all from the dpkg side. >> (It also might well be that these packages would fail anyway in case >> gcc enabled PIE by default on x32.) Otherwise I guess I'll merge this >> and the other report and probably either reassign to gcc or close. >> >> >> The rationale for ending up enabling this globally in dpkg, was that >> enabling this partially in gcc means handling this in packaging is an >> inconsistent mess. >> >> We'd have some packages building with PIE in some architectures and >> not on others (default hardening build flags option), packages building >> with PIE enabled everywhere using gcc default or dpkg PIE enabling specs >> (with hardening=+pie), or PIE disabled everywhere using PIE disabling >> specs or nothing where gcc does not enable it. >> >> So we'd need specs files in some places no matter what. And the option >> of just never using specs files, and not making it possible to disable >> PIE for example or enable it on other arches explicily would be >> inconsistent and a pain for maintainers. Porters could opt-in for PIE and architectures not opted-in are left out. Please don't enable PIE for architectures not opted-in because those are the architectures with typically fewer users and less manpower to fix issues. I would love to see PIE enabled for all arches, but this needs more work than the available manpower. > > Well, Balint asked to enable the pie defaults in GCC. I wasn't aware that more > work regarding the specs was needed. Ideally these changes should be done in > one place, not in two. Yes, I tested and asked for enabling PIE in GCC because this is the low risk method. It is used by Ubuntu and GCC parameter parsing makes enabling it from dpkg basically does not work. Setting it through spec files is fragile and it is not tested well. Please simply drop using spec files for both setting and disabling PIE. You may be able to figure out a good solution with full archive rebuilds for Stretch+1, but there is no time for that now. The solution of enabling PIE for a subset of arches through GCC and not enabling it for the rest of the arches has Release Team's blessing thus please don't divert from that. > >> We've also never enabled hardening flags partially, all hardening >> flags are always enabled as long as they work, otherwise they are just >> globally blacklisted on certain arches, even if the packages requests >> them. > > The pie flags are the first ones which have a performance impact, and probably > were never tested on our non-linux targets. So yes, I'm careful to apply these > on each target. Please live with it that defaults may differ. > > I don't think that dpkg-buildflags should have any business passing spec files > for cases where these spec files are not needed. This is monkey-patching GCC > for unrelated or convenience reasons. This did go wrong as seen with #843791, > #843826, and now with at least the python2.7 x32 build. For the latter it is > not important that the build can/should be fixed or being worked around, but > that just passing these specs is causing side effects. The GCC packages don't > divert dpkg-buildflags either, and I see this in the end as a diversion as > well. > And I can't find any docs about what these specs are supposed to do. > > For the upload of the GCC 6.3.0 release candidate I'm ignoring these spec > files > when they are not needed. I think this is the least invasive option for the > upcoming stretch release. A 'note' message is printed when these options are > ignored, so this shouldn't be an issue with any -Werror option either. > >> I find the current situation pretty suboptimal TBH. :/ > > Balint and the release team asked to enable this. I raised concerns that this > would be too late for the release cycle, but my concerns were ignored (sorry, > can't find this email in a bug repor
Bug#845323: Issue resolved
Can confirm this on debian 7 wheezy, python-ethtool update fixes the problem. On Mon, 5 Dec 2016 14:21:24 +0100 pyt...@gmx.li wrote: > Hi. > Â > After playing around a while with the packets I could figure out, that the package is working with the stable version of "python-ethtool" (currently 0.11-2). > Â > Workaround by installing the stable version of python-ethtool: > apt-get install python-ethtool/stable > Â > Pls. update the package dependencies. > Â > Kind regards, > Chris > >
Bug#847219: Pending fixes for bugs in the libemail-sender-perl package
tag 847219 + pending thanks Some bugs in the libemail-sender-perl package are closed in revision 2f8217c249f28bda8e0f39e89e2e14dffe3d0896 in branch 'master' by Damyan Ivanov The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libemail-sender-perl.git/commit/?id=2f8217c Commit message: Avoid warning in Email::Sender::Transport::SMTP when parsing the version of Net::SMTP Closes: #847219
Bug#838703: libinput10: leads to a crash of X when working in a virtual tty
Hi Emilio Pozuelo Monfort schrieb am 14.12.2016, 11:15 +0100: >On 14/12/16 11:05, Sebastian Humenda wrote: >> Hi >> >> Emilio Pozuelo Monfort schrieb am 12.12.2016, 19:31 +0100: >>> On 12/12/16 12:54, Sebastian Humenda wrote: Control: reassign 838703 xserver-xorg-input-libinput Control: tags 838703 +pending Samuel Thibault schrieb am 09.12.2016, 20:19 +0100: > This is very likely the same bug as > https://bugs.freedesktop.org/show_bug.cgi?id=98464 which has a proposed > patch, could you check try? Thanks, that patch solves the issue. >>> >>> Can you try with xserver-xorg-input-libinput 0.23.0-1, which I just >>> uploaded? >> Have you applied the very same patch? If so, I have been overoptimistic. The >> problem persists. > >I haven't applied any patch. Ok, that had confused me. I did not look carefully and assumed that you had applied the patch and hence the issue would still exist _with_ the patch. As soon as I apply the patch to the latest version again, everything works as expected, but without, X crashes. I'll participate in the upstream discussion. The Debian bug report is mainly to raise awareness before the next stable release. Thanks Sebastian signature.asc Description: PGP signature
Bug#844701: dpkg-maintscript-helper: Version comparison fails for supposedly valid versions
control: tags -1 +patch
Hi Guillem,
On Sun, Nov 20, 2016 at 03:28:26AM +0100, Guillem Jover wrote:
> Control: retitle -1 dpkg-maintscript-helper: Version comparison fails for
> supposedly valid versions
> Control: severity -1 serious
>
> Hi!
>
> On Fri, 2016-11-18 at 14:02:39 +0530, shirish शिरीष wrote:
> > Package: dpkg
> > Version: 1.18.14
> > Severity: normal
>
> > It seems the bug is in dpkg 1.18.11 and above. I was suffering from
> > some sort of broken packages. I shared my issue at
> > http://unix.stackexchange.com/questions/323817/debian-strech-update-broken-seems-buggy-dpkg
> > . It took quite some time but it seems that dpkg at least 1.18.14 is
> > somewhat broken/buggy in its implementation. In dpkg 1.18.10 I am able
> > to fix the broken packages. These happened a few more times. I did run
> > a few checks
> > http://unix.stackexchange.com/questions/324151/how-to-find-out-half-configured-broken-packages-in-debian
> > but found nothing untoward.
>
> Please include your reports inline, instead of referencing outside
> resources, because this means those details might disappear (in the
> future) in case those sites are shutdown, or it requires maintainers
> to be online to check them.
>
> Ok, so this is about the dpkg-maintscript-helper failing on the
> version validation check for supposedly valid versions. This was
> recently reported on IRC too, but we were unable to reproduce it. If
> you can still reproduce it, I'd appreciate if you could apply the
> attached patch to your installed dpkg-maintscript-helper script
> (from a dpkg version > 1.18.11) and rerun the failing package.
>
> Oh, I think I know what's wrong now, the attached patch should in
> principle fix that.
I've tried the attached patches they still fail in my use case (pbuilder
create). The reason is that stderr contains completely unrelated garbish
form ld.so. I've added a version that relies on exit status only. Can
this be applied?
Cheers,
-- Guido
>From 4dec2511556e80cd4f8fc9073e866e0feaa52108 Mon Sep 17 00:00:00 2001
Message-Id: <4dec2511556e80cd4f8fc9073e866e0feaa52108.1481882206.git@sigxcpu.org>
From: =?UTF-8?q?Guido=20G=C3=BCnther?=
Date: Fri, 16 Dec 2016 10:49:30 +0100
Subject: [PATCH] d-m-h: don't rely on command output for version comparison
Don't capture stderr since it can contain totally unrelated errors e.g.
from ld.so:
dpkg-maintscript-helper: error: version '1.5.58~' is not valid: ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
when running "pbuilder create" with eatmydata configured.
Compare to the same version instead so we only have non-zero exit status
on errors.
---
scripts/dpkg-maintscript-helper.sh | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/scripts/dpkg-maintscript-helper.sh b/scripts/dpkg-maintscript-helper.sh
index f20d826..cffbe66 100755
--- a/scripts/dpkg-maintscript-helper.sh
+++ b/scripts/dpkg-maintscript-helper.sh
@@ -49,8 +49,9 @@ rm_conffile() {
[ "${CONFFILE}" != "${CONFFILE#/}" ] || \
error "conffile '$CONFFILE' is not an absolute path"
# Use --compare-versions to validate the version number.
- [ -z "$(dpkg --compare-versions -- "$LASTVERSION" eq '0' 2>&1)" ] || \
- error "version '$LASTVERSION' is not valid"
+ if ! dpkg --compare-versions -- "$LASTVERSION" eq "$LASTVERSION" 2>&1; then
+ error "version '$LASTVERSION' is not valid."
+ fi
debug "Executing $0 rm_conffile in $DPKG_MAINTSCRIPT_NAME" \
"of $DPKG_MAINTSCRIPT_PACKAGE"
@@ -163,8 +164,9 @@ mv_conffile() {
[ "${NEWCONFFILE}" != "${NEWCONFFILE#/}" ] || \
error "new-conffile '$NEWCONFFILE' is not an absolute path"
# Use --compare-versions to validate the version number.
- [ -z "$(dpkg --compare-versions -- "$LASTVERSION" eq '0' 2>&1)" ] || \
- error "version '$LASTVERSION' is not valid"
+ if ! dpkg --compare-versions -- "$LASTVERSION" eq "$LASTVERSION" 2>&1; then
+ error "version '$LASTVERSION' is not valid."
+ fi
debug "Executing $0 mv_conffile in $DPKG_MAINTSCRIPT_NAME" \
"of $DPKG_MAINTSCRIPT_PACKAGE"
--
2.10.2
Bug#848314: [Pkg-libvirt-maintainers] Bug#848314: Further fix for discussion in the scope of smoke-qemu-session
On Fri, Dec 16, 2016 at 10:42 AM, Guido Günther wrote: > You want qemu-system running as non root not qemu-user. > gah - sorry my bad - of course not cross emulation user mode. > > -/usr/bin/kvm > > +/usr/bin/qemu-x86_64 > > Like this but using qemu-system-x86_64. > Yeah as follow on to the upper change > Thanks for looking into this! > yw, I hope it is a win in test coverage for both of us eventually! I dropped the former adding of isolation-machine and needs-root which was related. with qemu-system-x86_64 that should work now. All that might also close the circle and address what I wanted to add with the FIXME (broken 2nd level KVM virt) as we no more need it. I'm now having this delta for this case left: (depending on qemu-system was already accepted IIRC) diff --git a/debian/tests/smoke-qemu-session.xml b/debian/tests/smoke-qemu-session.xml index 47b33d5..2d90c9f 100644 --- a/debian/tests/smoke-qemu-session.xml +++ b/debian/tests/smoke-qemu-session.xml @@ -1,4 +1,4 @@ - + sqs 256000 256000 @@ -18,7 +18,7 @@ destroy destroy -/usr/bin/kvm +/usr/bin/qemu-system-x86_64 I'll be throwing that against all architectures and get back to you if it works for me. (IIRC you already accepted the d/t/control dependency to qemu-system in my former bug, so not listed) I'm short of loosing overview, so for the next steps after this I'll rebase to your latest commit on Monday first. And then start over again.
Bug#848318: gscan2pdf: Regression from previous version, append and prepend to PDF no longer work
Package: gscan2pdf Version: 1.6.0-1 Severity: normal Dear Maintainer, In 1.6.0 the Save options Append and Prepend to PDF no longer work. They worked in the previous version, but they fail silently even if gscan2pdf is started from the command line. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gscan2pdf depends on: ii imagemagick8:6.9.6.6+dfsg-1 ii imagemagick-6.q16 [imagemagick]8:6.9.6.6+dfsg-1 ii libconfig-general-perl 2.63-1 ii libdate-calc-perl 6.4-1 ii libfilesys-df-perl 0.92-6+b1 ii libgoo-canvas-perl 0.06-2+b3 ii libgtk2-ex-simple-list-perl0.50-2 ii libgtk2-imageview-perl 0.05-2+b3 ii libhtml-parser-perl3.72-3 ii libimage-magick-perl 8:6.9.6.6+dfsg-1 ii liblist-moreutils-perl 0.416-1+b1 ii liblocale-gettext-perl 1.07-3+b1 ii liblog-log4perl-perl 1.47-2 ii libossp-uuid-perl [libdata-uuid-perl] 1.6.2-1.5+b3 ii libpdf-api2-perl 2.030-1 ii libproc-processtable-perl 0.53-2 ii libreadonly-perl 2.050-1 ii librsvg2-common2.40.16-1 ii libsane-perl 0.05-2+b4 ii libset-intspan-perl1.19-1 ii libtiff-tools 4.0.7-3 ii libtry-tiny-perl 0.27-1 ii sane-utils 1.0.25-2+b1 Versions of packages gscan2pdf recommends: ii djvulibre-bin 3.5.27.1-7 ii libgtk2-ex-podviewer-perl 0.18-1 ii sane 1.0.14-11 ii tesseract-ocr 3.04.01-5 ii unpaper6.1-2 ii xdg-utils 1.1.1-1 gscan2pdf suggests no packages. -- no debconf information
Bug#848233: sphde FTBFS on mips and mipsel: missing mips32 support
Hello Frederic, Please do so. Thank you! Regards, Radovan
Bug#848319: smoke-lxc restart does indeed kill
Package: libvirt Version: 2.5.0-1 Severity: normal Hi, this - for now - is less a bug report than more a sanity check on my side. The test smoke-lxc has the following section # Make sure a restart doesn't termiante the domain /etc/init.d/libvirtd restart check_domain While I agree to the thought, for me it actually does just that (terminating the domains on restart). It even looses the definition in libvirt - so a virsh list --all show nothing anymore. I might have been off due to so many consoles, URI exports and so on, but I wanted to make sure one thing before restarting on that one: => Does this section pass for you on your test system? -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
Bug#848320: ITP: python-tinycss -- complete yet simple CSS parser
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-tinycss Version : 0.4 Upstream Author : Simon Sapin * URL : https://github.com/Kozea/tinycss * License : BSD-3-clause Programming Lang: Python Description : complete yet simple CSS parser tinycss is a complete yet simple CSS parser for Python. It supports the full syntax and error handling for CSS 2.1 as well as some CSS 3 modules: . * CSS Color 3 * CSS Fonts 3 * CSS Paged Media 3 . It is designed to be easy to extend for new CSS modules and syntax, and integrates well with cssselect for Selectors 3 support. -BEGIN PGP SIGNATURE- iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlhTvmoRHGZsYWRpQGRl Ymlhbi5vcmcACgkQ/9PIi5l90WpdKwf+PYYZfEZyeMdcqDcY37F/b6XVb5rLDBa3 37OGaUUMDrJHA0dkjP9VvQcBI1kUV/sQS+THGuAh3XooXSiNWsnaRCAHmBjejSDh A0ZN0042UFIAU2SHL52ZzXCHjD2MSolq/qjO7R6YlaVg1Ghfe6sDVWP9YlD4V42C pZ+QCzi179PbTRmkB8NSlefrRhE3nX+LfFzhAPbUmRyFaDVB/YxA8536wqCfXCLi nPkRkG169lYRLc+I5xr1c/AT6yf8xWZAuDtN53r0nmFHyFLi3jujP+zvuDs3mKCs UMFlbHCdInhpgVQbeYNKqW2jGmS4f4EcveK7T/LFzKz2lnL2KbuHVQ== =ytLi -END PGP SIGNATURE-
Bug#847219: Argument "3.08_01" isn't numeric in numeric lt (<) at /usr/share/perl5/Email/Sender/Transport/SMTP.pm line 266.
Hi, Salvatore! -=| Salvatore Bonaccorso, 10.12.2016 09:08:59 +0100 |=- > On Tue, Dec 06, 2016 at 03:14:12PM +, Damyan Ivanov wrote: > > If there are no objections, I'll proceed with fixing the package and > > forwarding this upstream. > > No objections, sure go ahead to notifiy upstream as well in case not > yet known (I have not checked, just saw your report unreplied yet). I finally got around to it. Thank you for taking a look. -- Damyan signature.asc Description: Digital signature
Bug#848321: xorg random crash when firefox-esr is in focus
Package: xorg
Version: 1:7.7+18
Severity: important
Dear Maintainer,
Xorg from server-xorg-core 2:1.19.0-2 always crashes on my thin clients
after 1-30 seconds of user interaction with firefox-esr,
most predictably when starting to render new page, e.g. pressing
Alt-Home to load home page (about:blank).
When firefox is started with DISPLAY pointing to xorg in jessie,
the crash doesn't happen.
Xorg backtrace:
---
#0 0xb76f1ce5 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7194dc0 in __libc_signal_restore_set (set=0xbfb50300) at
../sysdeps/unix/sysv/linux/nptl-signals.h:79
No locals.
#2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:55
set = {__val = {0, 0, 1698051938, 808464434, 2016244256, 808460400,
808464432, 807415856, 858864176,
925971232, 825307442, 538976307, 1920169263, 1651076143, 942893359,
1768697142, 762869102,
796225127, 1734502764, 1969516397, 841835884, 1932406830,
774909551, 808464437, 1644835374,
845493815, 758132784, 1698051938, 808464435, 757953056, 808460400,
808595504}}
pid =
tid =
ret = 0
#3 0xb7196287 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x76765b20, sa_sigaction =
0x76765b20}, sa_mask = {
__val = {173896289, 1714829154, 808464433, 909599277, 808465254,
762454064, 807432312, 808464432,
540028976, 809119792, 540024880, 538976288, 538976288,
1685478176, 173895539, 1714829154,
808464435, 926376493, 808465713, 762454064, 807432312, 808464432,
540028976, 825897008,
825434163, 892482871, 538982452, 1768697632, 862531426,
1814902328, 0, 4096}},
sa_flags = -1223161722, sa_restorer = 0xbfb50560}
sigs = {__val = {32, 0 }}
#4 0xb71d037f in __libc_message (do_abort=, fmt=)
at ../sysdeps/posix/libc_fatal.c:175
ap =
fd = 40
on_2 =
list =
nlist =
cp =
written =
#5 0xb71d6fb7 in malloc_printerr (action=, str=0xb72c6c43
"free(): invalid pointer",
ptr=, ar_ptr=0xb731c780 ) at malloc.c:5046
buf = "b731c7e0"
cp =
ar_ptr = 0xb731c780
ptr =
str = 0xb72c6c43 "free(): invalid pointer"
action =
#6 0xb71d7776 in _int_free (av=0xb731c780 , p=0xb731c7d8
,
have_lock=have_lock@entry=0) at malloc.c:3902
size =
fb =
nextchunk =
nextsize =
nextinuse =
prevsize =
bck =
fwd =
errstr =
locked =
__func__ = "_int_free"
#7 0xb71daf1d in __GI___libc_free (mem=0xb731c7e0 ) at
malloc.c:2982
ar_ptr =
p = 0xb731c7d8
hook =
#8 0x801dbcbb in RegionUninit (_pReg=0xb731c7e4 ) at
../../../include/regionstr.h:166
No locals.
#9 RegionEmpty (_pReg=0xb731c7e4 ) at
../../../include/regionstr.h:194
No locals.
#10 damageRegionProcessPending (pDamage=0xb731c7b0 ,
pDamage@entry=0x80ed9fe0)
at ../../../miext/damage/damage.c:298
No locals.
#11 0x801dc285 in damageComposite (op=12 '\f', pSrc=0x80ed9688,
pMask=0x80eda6d0, pDst=0x80eda090, xSrc=725,
ySrc=60, xMask=0, yMask=0, xDst=0, yDst=0, width=1, height=1) at
../../../miext/damage/damage.c:507
pScreen =
pDamage = 0x80ed9fe0
#12 0xb6a80beb in exaTrapezoids (op=12 '\f', pSrc=0x80ed9688, pDst=0x80eda090,
maskFormat=0x80a6f480,
xSrc=726, ySrc=60, ntrap=, traps=) at
../../exa/exa_render.c:1150
pPicture = 0x80eda6d0
yRel =
xRel =
pScreen =
bounds = {x1 = 0, y1 = 0, x2 = 1, y2 = 1}
#13 0x801d1eee in ProcRenderTrapezoids (client=0x80d43da8) at
../../render/render.c:746
rc =
ntraps = 4
pSrc = 0x80ed9688
pDst = 0x80eda090
pFormat = 0x80a6f480
stuff =
#14 0x800ebf01 in Dispatch () at ../../dix/dispatch.c:469
result =
start_tick = 680
#15 0x800f0221 in dix_main (argc=5, argv=0xbfb50ac4, envp=0xbfb50adc) at
../../dix/main.c:287
i =
alwaysCheckForInput = {0, 1}
#16 0x800d98aa in main (argc=5, argv=0xbfb50ac4, envp=0xbfb50adc) at
../../dix/stubmain.c:34
No locals.
Detaching from program: /usr/lib/xorg/Xorg, process 1905
-- Package-specific info:
X server symlink status:
lrwxrwxrwx 1 root root 13 Feb 24 2015 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Nov 23 21:32 /usr/bin/Xorg
VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV18 [GeForce4 MX
440 AGP 8x] [10de:0181] (rev a4)
/etc/X11/xorg.conf does not exist.
Contents of /etc/X11/xorg.conf.d:
-
total 0
lrwxrwxrwx 1 root root 32 Jul 15 2015 usbsid-generated.conf ->
/var/local/usbsid-generated.conf
Contents of /var/local/usbsid-generated.conf:
-
# stub
/etc/modprobe.d
Bug#842634: [Pkg-rust-maintainers] Bug#842634: rustc: FTBFS (sys_common::net::tests::no_lookup_host_duplicates fails)
On Tue, 29 Nov 2016, Ralph Giles wrote: > On 2016-11-29 1:17 AM, Santiago Vila wrote: > > > I wonder, however, why two lines like this in /etc/hosts > > > > 127.0.0.1 localhost > > 127.0.0.1 localhost ip6-localhost ip6-loopback > > > > should make rustc build to fail at all. > > The test was added in https://github.com/rust-lang/rust/pull/34700 to > guard against regression of a bug where std::net::lookup_host() > incorrectly returned multiple copies of each address. > > The /etc/hosts database format certainly allows duplicate entries. It > seems that glibc, at least, does not merge those, but instead returns > the listed n-to-m mappings directly through the `struct hostent` > returned by both gethostbyaddr() and gethostbyname(). > > Even if it doesn't violate any spec, I agree with Luca that this is a > misconfiguration. The normal application of multiple address entries > is for service failover. Any client connecting to localhost with your > configuration will immediately retry connection failures, which is a > waste of resources. [...] Ok, but the duplicate localhost entry, as I explained, is not something which I deliberately chose, it's the result of using schroot on a machine not having IPv6 enabled. Unless IPv6 has become mandatory for autobuilders (I hope not), this is still a bug (i.e. definitely *not* wishlist) in schroot, for converting ::1 into 127.0.0.1 and causing the FTBFS problem. I'll reassign it. Thanks.
Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57
On Fri, Dec 16, 2016 at 08:25:02AM +, Gianfranco Costamagna wrote: > Hi, > > > >export DEB_BUILD_MAINT_OPTIONS=noopt > > > > >to the top of d/rules and rebuilding should do it. > > > it worked: > DEB_BUILD_OPTIONS=noopt dpkg-buildpackage > > [...] > Interesting. Under the emulator some of the floating point tests fail. But it is an emulator, so maybe it's not perfect. I also compared compiler defaults between Ubuntu and Debian, and tried some other flags and settings that might be relevant, but so far I haven't found anything else that's helpful. I'd still like to find the root cause and fix it, but in the interest of getting it solved before the freeze, I'd like to build the s390x package with O1 and continue building the rest of the archs with O2. If there are no objections, I can have a package ready for upload later today.
Bug#794988: the domhandler dependency
I got the same while testing node-cheerio (ITP: https://bugs.debian.org/848315). The domhandler dependency is indeed listed in the current upstream's package.json. Upgrading node-htmlparser2 from 3.7.3 to 3.9.2 would force us to package domhandler and domutils, and the latter's dependency node-dom-serializer. And I assume this bug would be fixed. BTW while updating we could also add debian/watch to this one ... Paolo
Bug#848322: ITP: node-domhandler -- htmlparser2 handler that turns pages into a dom
Package: wnpp Severity: wishlist Owner: Paolo Greppi X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-domhandler Version : 2.3.0 Upstream Author : Felix Boehm * URL : https://github.com/fb55/DomHandler * License : BSD-2-Clause Programming Lang: JavaScript Description : htmlparser2 handler that turns pages into a DOM Node.js module that creates a DOM (Document Object Model), i.e. a tree data structure containing all nodes of a page that can be manipulated using the node-domutils library. . Node.js is an event-based server-side JavaScript engine. This is required to fix https://bugs.debian.org/794988
Bug#848323: debsources: grab sources form security.debian.org too at least for wheezy-security
Package: qa.debian.org Severity: wishlist User: qa.debian@packages.debian.org I was looking at icu, version 4.8.1.1-12+deb7u5 is in wheezy-security and yet I can't find that version here: https://sources.debian.net/src/icu/ Thus it would be nice if debsources could also import source packages from security.debian.org. It's particularly important for wheezy-security since the package there are never merged back into wheezy (there are no further point releases during the LTS period). -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#848324: ITP: node-domutils -- utilities for working with htmlparser2's dom
Package: wnpp Severity: wishlist Owner: Paolo Greppi X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-domutils Version : 1.5.1 Upstream Author : Felix Boehm * URL : https://github.com/FB55/domutils * License : FIX_ME upstream license Programming Lang: JavaScript Description : utilities for working with htmlparser2's dom Node.js module that provides utilities (stringify, traversal, manipulation and querying) for working with a DOM (Document Object Model) created with the node-domhandler module. . Node.js is an event-based server-side JavaScript engine. This is a requirement for node-domhandler, see ITP: https://bugs.debian.org/848322
Bug#848325: ITP: node-dom-serializer -- render dom nodes to string
Package: wnpp Severity: wishlist Owner: Paolo Greppi X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-dom-serializer Version : 0.1.0 Upstream Author : Felix Boehm * URL : https://github.com/cheeriojs/dom-serializer * License : Expat Programming Lang: JavaScript Description : render dom nodes to string Node.js module that renders to a tring a DOM (Document Object Model) created with the node-domhandler module. . Node.js is an event-based server-side JavaScript engine. This is a requirement for node-domhandler, see ITP: https://bugs.debian.org/848322
Bug#794988: 3 new related ITPs
As a start I'll take care of the three new packages: - node-domhandler https://bugs.debian.org/848322 - node-domutils https://bugs.debian.org/848324 - node-dom-serializer https://bugs.debian.org/848325 Paolo
Bug#817922: [Pkg-roundcube-maintainers] Bug#817922: Bug#817922: PEAR issues
Control: tags -1 +moreinfo Hey, now transistion of Php7 is through and we are in freeze. Is it still an issue? Best Regards, sandro -- Am Freitag, 18. März 2016, 11:22:21 CET schrieb Sandro Knauß: > Hey, > > > Note that I also couldn't make it run correctly with php5-fpm and taking > > php-pear from testing (which is still for 5.x). Somehow RC itself > > introduced some breaking change I couldn't track down. > > I think it will be very unstable till the php7 transition is through and we > have a rc version that works with php7. > > > That silenced fatal error is only one of at least two I found attempting > > to call PEAR. Incredibly frustrating. > > I see - Do you have a patch for makeing it more verbosy? > > > Apart for some minor session issues (session_renegerate_id failing > > somewhere due to the sqlite3 backend), I was able to make it run with > > PHP7 (albeit with several deprecation warnings). > > > > Looks like it's not too far off for php 7. > > So you haven't to change anything on the code to get it running with php7? > > > Regards, > > sandro signature.asc Description: This is a digitally signed message part.
Bug#843356: [Pkg-roundcube-maintainers] Bug#843356: enigma plugin does not seem to work anymore
Control: tags -1 +moreinfo Hey, I see php-crypt-gpg to be available in unstable. What can we improve on our side? We are not the maintainer of php-crypt-gpg, but well the package looks to be in not a good state, if it does not moved to testing for nearly a year now... Best Regards, sandro -- Am Sonntag, 6. November 2016, 10:09:11 CET schrieb Michael Meskes: > Package: roundcube > Version: 1.2.2+dfsg.1-1 > Severity: important > > Hi, > > I just noticed that the enigma plugin does not work anymore, because it > cannot find GPG.php which is in php-crypt-gpg. And yes, that package is gone > because it is no longer installable with the gnupg version. > > Michael > > -- System Information: > Debian Release: stretch/sid > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.7.0-1-amd64 (SMP w/2 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 roundcube-plugins depends on: > ii dpkg1.18.10 > ii roundcube-core 1.2.2+dfsg.1-1 > > roundcube-plugins recommends no packages. > > Versions of packages roundcube-plugins suggests: > pn php-crypt-gpg > pn php-net-sieve > pn php-zip > > Versions of packages roundcube-core depends on: > ii dbconfig-common 2.0.6 > ii debconf [debconf-2.0] 1.5.59 > ii dpkg1.18.10 > ii libapache2-mod-php 1:7.0+45 > ii libapache2-mod-php7.0 [libapache2-mod-php] 7.0.12-1 > ii libmagic1 1:5.29-1 > ii php-auth-sasl 1.0.6-3 > ii php-cli 1:7.0+45 > ii php-common 1:45 > ii php-intl1:7.0+45 > ii php-mail-mime 1.10.0-2 > ii php-mcrypt 1:7.0+45 > ii php-net-smtp1.7.1-2 > ii php-net-socket 1.0.14-2 > ii php-pear1:1.10.1+submodules+notgz-8 > ii php7.0 [php]7.0.12-1 > ii php7.0-cli [php-cli]7.0.12-1 > ii php7.0-intl [php-intl] 7.0.12-1 > ii php7.0-json [php-json] 7.0.12-1 > ii php7.0-mcrypt [php-mcrypt] 7.0.12-1 > ii roundcube-pgsql 1.2.2+dfsg.1-1 > ii ucf 3.0036 > > Versions of packages roundcube-core recommends: > ii apache2 [httpd-cgi] 2.4.23-5 > ii lighttpd [httpd-cgi]1.4.39-1 > ii php-gd 1:7.0+45 > ii php-pspell 1:7.0+45 > ii php7.0-fpm [php-fpm]7.0.12-1 > ii php7.0-gd [php-gd] 7.0.12-1 > ii php7.0-pspell [php-pspell] 7.0.12-1 > ii spawn-fcgi 1.6.4-1 > > Versions of packages roundcube-core suggests: > pn php-crypt-gpg > pn php-net-ldap2 > pn php-net-ldap3 > > Versions of packages roundcube depends on: > ii dpkg1.18.10 > ii roundcube-core 1.2.2+dfsg.1-1 > > ___ > Pkg-roundcube-maintainers mailing list > pkg-roundcube-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-roundcube-mainta > iners signature.asc Description: This is a digitally signed message part.
Bug#848326: src:mapdamage: Please add autopkgtest
Package: src:mapdamage Severity: normal Tags: newcomer Hi, I'm filing a set of bugs for packages where an autopkgtest would make some sense considering its importance due to the number of active users (based on popcon values). Since adding tests should be a task for newcomers the bugs will be tagged that way and I consider these bugs as reasonable targets for our advent bug squashing party. So please add an autopkgtest to mapdamage. Kind regards Andreas. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) 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)
Bug#848327: RFS: libu2f-host/1.1.3-1
Package: sponsorship-requests Severity: normal Control: block 824532 by -1 Control: block 846358 by -1 Control: block 846359 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Mentors, I am looking for a sponsor for my package "libu2f-host": * Package name: libu2f-host Version : 1.1.3-1 Upstream Author : Yubico AG * URL : https://developers.yubico.com/libu2f-host/ * License : LGPLv2 * Section : libs This updates brings: - - a fix for #846358, so that rules for the right udev version are installed; - - as per #846359 and #824532, this creates a new binary package, libu2f-common, containing the udev rules; - - the new upstream version brings udev rules for additional devices. The source and binary (Architecture: all) packages are available here: https://nicolas.braud-santoni.eu/tmp/deb I also uploaded it to mentors.d.n, but it doesn't seem to be visible there yet. Best, nicoo - -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAlhTyOgZHG5pY29sYXNA YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z4yn3EACCh0Jxho0X6oOvR7+e9vRx LFnD92R2HEa+2dXqIr5wVMZQHzSHc814Hr9iSM7yEfeiNEa+OCy3tMYexQ3+wYIJ OHbkzkek9y4DEBpyY12GQIS/W/iWSQFOOch+yQUyf9KORo++7qf7BYWBx6CUI0/S Xr3IaF2kXV/vEQzuGlHcqlRE+9gInu8/Ov+BeygvzGoR2GQgz6Scmcv2t0KViDg+ tgmgsLhQ4iECxQrh9neMaeWmccgAH8ftYGt89kPvbgdBg3NyfcbVO3l3IJldCGUG KHn8lpO62skHqtnA5YTt8ao236QrlPNiqom5a9rqxU6dJ0k0YOIZBS6Im8RmG1Xf qtLgdAEbn0TRU18h1ljOvELSyovwyLoq0KBIVCsntJjXePtVG/x8wR0JrPYfYL0+ H4VA13PNYvkwWabLcVrs9hnXCp6feeDFSMnxK0ujfyU87yUCdrTl9OG0alHVDwki Dl+6PhLPgkbam2YjO3eOVLKSDL4Ui02CONlBGY01oyoP7yeNb+4ieIDOuYESdmtx OoAfojtlQAqse7zA7/ZpfCPlVo1RfNV9NqPBs0f0GdvOvNNpIwjU6sK4iiBCgeRv 34qlH8tLhBLpAIiBl26n4+LtuiMcBNUtEo2w2rGdsohyRtzdoiydM4JRQIb2Qp8v o1zMNcA6Di3m/Sg20loSbg== =bX10 -END PGP SIGNATURE-
Bug#848328: src:fsa: Please add autopkgtest
Package: src:fsa Severity: normal Tags: newcomer Hi, please add an autopkgtest to fsa and join the Debian Med advent calendar bug squashing party by doing so. Kind regards Andreas. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) 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)
Bug#848329: src:prank: Please add autopkgtest
Package: src:prank Severity: normal Tags: newcomer Hi, please add an autopkgtest to prank and join our advent calendar bug squashing party by doing so. Kind regards Andreas. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) 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)
Bug#162917:
внимания; аши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2016 Почты технической поддержки ©2016 спасибо системы администратор
Bug#848331: kdevelop: Segfault when both llvm-3.8-dev and llvm-3.9-dev are installed
Package: kdevelop
Version: 4:5.0.1-2
Severity: normal
Dear Maintainer,
KDevelop crashes with a segfault when I have both llvm-3.8-dev and llvm-3.9-dev
installed. After removing llvm-3.9-dev, kdevelop started working again. I'll
paste the gdb bt below.
gdb -arg kdevelop
[..]
kdevplatform.serialization: version-hint not found, seems to be an old version
kdevplatform.serialization: "The data-repository at
/home/anoko/.cache/kdevduchain/kdevelop-{48d60682-4ad9-43f8-920d-6474371912f6}
has to be cleared."
Icon theme "crystalsvg" not found.
[New Thread 0x7fffbd3e0700 (LWP 25504)]
[New Thread 0x7fffbc7e1700 (LWP 25505)]
Thread 1 "kdevelop" received signal SIGSEGV, Segmentation fault.
0x7fffbda7b6ad in llvm::cl::Option::setArgStr(llvm::StringRef) () from
/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1
(gdb) bt
#0 0x7fffbda7b6ad in llvm::cl::Option::setArgStr(llvm::StringRef) () from
/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1
#1 0x7fffaf1e2acb in ?? () from
/usr/lib/llvm-3.8/lib/../lib/libLLVM-3.8.so.1
#2 0x7fffaf1e2d08 in ?? () from
/usr/lib/llvm-3.8/lib/../lib/libLLVM-3.8.so.1
#3 0x77de95da in call_init (l=, argc=argc@entry=1,
argv=argv@entry=0x7fffe1e8, env=env@entry=0x7fffe1f8) at dl-init.c:72
#4 0x77de96eb in call_init (env=0x7fffe1f8, argv=0x7fffe1e8,
argc=1, l=) at dl-init.c:30
#5 _dl_init (main_map=main_map@entry=0xcb6e60, argc=1, argv=0x7fffe1e8,
env=0x7fffe1f8) at dl-init.c:120
#6 0x77dedc68 in dl_open_worker (a=a@entry=0x7fffcb50) at dl-
open.c:575
#7 0x77de9484 in _dl_catch_error
(objname=objname@entry=0x7fffcb40,
errstring=errstring@entry=0x7fffcb48,
mallocedp=mallocedp@entry=0x7fffcb3f,
operate=operate@entry=0x77ded880 ,
args=args@entry=0x7fffcb50) at dl-error.c:187
#8 0x77ded419 in _dl_open (file=0xcb6d68 "/usr/lib/x86_64-linux-
gnu/qt5/plugins/kdevplatform/25/kdevclangsupport.so", mode=-2147483647,
caller_dlopen=0x75e451be, nsid=-2, argc=,
argv=, env=0x7fffe1f8) at dl-open.c:660
#9 0x7fffed476ee9 in dlopen_doit (a=a@entry=0x7fffcd80) at dlopen.c:66
#10 0x77de9484 in _dl_catch_error (objname=0x63eea0,
errstring=0x63eea8, mallocedp=0x63ee98, operate=0x7fffed476e90 ,
args=0x7fffcd80)
at dl-error.c:187
#11 0x7fffed477521 in _dlerror_run (operate=operate@entry=0x7fffed476e90
, args=args@entry=0x7fffcd80) at dlerror.c:163
#12 0x7fffed476f82 in __dlopen (file=, mode=)
at dlopen.c:87
#13 0x75e451be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x75e3e285 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x76c82cba in KPluginLoader::load() () from /usr/lib/x86_64-linux-
gnu/libKF5CoreAddons.so.5
#16 0x76c82dea in KPluginLoader::instance() () from /usr/lib/x86_64
-linux-gnu/libKF5CoreAddons.so.5
#17 0x76c82e3c in KPluginLoader::factory() () from /usr/lib/x86_64
-linux-gnu/libKF5CoreAddons.so.5
#18 0x77ab3aa5 in
KDevelop::PluginController::loadPluginInternal(QString const&) () from
/usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.10
#19 0x77ab5289 in
KDevelop::PluginController::pluginForExtension(QString const&, QString const&,
QMap const&) ()
from /usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.10
#20 0x77af2bef in ?? () from /usr/lib/x86_64-linux-
gnu/libKDevPlatformShell.so.10
#21 0x77aef435 in KDevelop::DocumentController::openDocument(QUrl
const&, KTextEditor::Range const&,
QFlags, QString const&,
KDevelop::IDocument*) () from /usr/lib/x86_64-linux-
gnu/libKDevPlatformShell.so.10
#22 0x77399ed6 in KDevelop::IDocumentController::openDocument(QUrl
const&, KTextEditor::Cursor const&,
QFlags, QString const&) ()
from /usr/lib/x86_64-linux-gnu/libKDevPlatformInterfaces.so.10
#23 0x77a8d4b7 in ?? () from /usr/lib/x86_64-linux-
gnu/libKDevPlatformShell.so.10
#24 0x77a8e18a in ?? () from /usr/lib/x86_64-linux-
gnu/libKDevPlatformShell.so.10
#25 0x77a876f9 in ?? () from /usr/lib/x86_64-linux-
gnu/libKDevPlatformShell.so.10
#26 0x75e74ffe in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x7319787c in Sublime::Area::changedWorkingSet(Sublime::Area*,
QString, QString) () from /usr/lib/x86_64-linux-
gnu/libKDevPlatformSublime.so.10
#28 0x73168463 in Sublime::Area::setWorkingSet(QString) () from
/usr/lib/x86_64-linux-gnu/libKDevPlatformSublime.so.10
#29 0x7316b6de in Sublime::Area::load(KConfigGroup const&) () from
/usr/lib/x86_64-linux-gnu/libKDevPlatformSublime.so.10
#30 0x77ac2136 in KDevelop::UiController::loadArea(Sublime::Area*,
KConfigGroup const&) () from /usr/lib/x86_64-linux-
gnu/libKDevPlatformShell.so.10
#31 0x77ac55ed in
KDevelop::UiController::loadAllAreas(QExplicitlySharedDataPointer)
() from /usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.10
#32 0x77abf16d in
KDevelop::CorePrivate::initialize(KDeve
Bug#848330: src:dialign-t: Please add autopkgtest
Package: src:dialign-t Severity: normal Tags: newcomer Hi, please add an autopkgtest to dialign-t and join our advent calendar bug squashing party by doing so. Kind regards Andreas. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) 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)
Bug#848334: src:picard-tools: Please add autopkgtest
Package: src:picard-tools Severity: normal Tags: newcomer Hi, please add an autopkgtest to picard-tools and join our advent calendar bug squashing party by doing so. Kind regards Andreas. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) 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)
Bug#848333: src:proda: Please add autopkgtest
Package: src:proda Severity: normal Tags: newcomer Hi, please add an autopkgtest to proda and join our advent calendar bug squashing party by doing so. Kind regards Andreas. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) 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)
Bug#848332: src:poa: Please add autopkgtest
Package: src:poa Severity: normal Tags: newcomer Hi, please add an autopkgtest to poa and join our advent calendar bug squashing party by doing so. Kind regards Andreas. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) 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)
Bug#848165: freeciv-client-qt: crash at exit ...leavegame->quit
As the crash is in atexit handlers when the program is closed, this seems like upstream bug #25364: http://gna.org/bugs/?25364 - ML
Bug#681726: So... what's the current state?
Hi, so a quite long time passed, are there some updates on the subject? Is someone working on the issue or still no one has taken the responsibility to maintain the package? If someone is working on it is there anyway to help? Thanks signature.asc Description: OpenPGP digital signature
Bug#835365: roundcube
Control: tags -1 +moreinfo Hey, without more informations we can't help here. Are you processing an update? What databasebackend you use? What did you select, what webserver Best Regards, sandro signature.asc Description: This is a digitally signed message part.
Bug#848335: src:filo: Please add autopkgtest
Package: src:filo Severity: normal Tags: newcomer Hi, please add an autopkgtest to filo and join our advent calendar bug squashing party by doing so. Kind regards Andreas. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) 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)
Bug#843795: [Pkg-roundcube-maintainers] Bug#843795: In a multipart/related email with an image, the image is not displayed
Control: tags -1 +moreinfo Hey, > Version: 0.7.2-9+deb7u4 what? this old version. We are currently at 1.2.2. Did you checked if there this is still an issue? I would prefer, if you would push this fix upstream, than we can add this to our debian packages. Best Regards, sandro signature.asc Description: This is a digitally signed message part.
Bug#848178: gimagereader fails to start
Hi Adrian, On 15.12.2016 at 20:50, Adrian Bunk wrote: > Please do not close bugs that are actual bug - the generated > dependencies must ensure that problems like the issue in this > bug won't happen. > > Reopened and moved to the package where the root cause of this bug is. well, so true. The root cause of this bug was a silent ABI break in tesseract 3.04.00 -> 3.04.01 which is reverted upstream (https://github.com/tesseract-ocr/tesseract/issues/254). See the corresponding Debian bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794489 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816857 And see also for the whole picture: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815056 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815860 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815970 From my point of view it should have been save to use libtesseract3 (3.04.00-5) with a binary that was build against libtesseract3 (>>3.04.01-4). This does not seem to be the case. As the Debian maintainers of tesseract didn't provide much help in the past (see the first two mentioned bugs) and as it will not affect any Debian release I just closed the bug. But as you said it's actually still a bug in tesseract. Best, Philip signature.asc Description: OpenPGP digital signature
Bug#843356: [Pkg-roundcube-maintainers] Bug#843356: enigma plugin does not seem to work anymore
> I see php-crypt-gpg to be available in unstable. What can we improve > on our > side? We are not the maintainer of php-crypt-gpg, but well the I would love to see the package at least recommend php-crypt-gpg, although that would not help the current situation. So maybe document the problem in a README, so users don't have to debug themselves. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Bug#848297: gst-plugins-bad1.0: docstring collision
On Fri, 2016-12-16 at 00:44 +, Daniel Shahaf wrote: > > Dear Maintainer, > > The documentation of GstColorEffectsPreset sometimes uses the > docstring > of GstColorEffectsPreset and sometimes the docstring of GstMirrorMode [...] Hi Daniel, I've merged your patch upstream and will include it in the 1.10.3 release: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=a38887375f3631c9198fa328e76a7ae7b28a16c0 Thanks for noticing and reporting! > > P.S. Apologies for not making a more thorough investigation; I would, > but for health reasons. No problem, hope you're feeling better again soon :) signature.asc Description: This is a digitally signed message part
Bug#843356: [Pkg-roundcube-maintainers] Bug#843356: enigma plugin does not seem to work anymore
Hey, roundcube-core already suggest php-crypt-gpg. I think suggest is okay for a dependency of a plugin. Best Regards, sandro -- Am Freitag, 16. Dezember 2016, 12:28:27 CET schrieb Michael Meskes: > > I see php-crypt-gpg to be available in unstable. What can we improve > > on our > > side? We are not the maintainer of php-crypt-gpg, but well the > > I would love to see the package at least recommend php-crypt-gpg, > although that would not help the current situation. So maybe document > the problem in a README, so users don't have to debug themselves. > > Thanks. > > Michael signature.asc Description: This is a digitally signed message part.
Bug#824169: ftp.debian.org: src:chocolate-doom/2.2.1-3 is in both main and contrib
Jonathan Dowland wrote: > A workaround that *might* work would be if we did a release entirely in > one > suite only: i.e. temporarily delete the contrib binary packages. I'm not > sure > whether you would be happy to try that, it's pretty drastic. I think I'd rather move the package back to the contrib section but keep all four games as binary packages. - Fabian
Bug#750138: scap-workbench
Did not hear anything, so I assume you are busy but would like to see the current git content in Debian, so I ran 'gbp dch', cleaned up the changelog and uploaded the result. I applied this diff before the upload. diff --git a/debian/changelog b/debian/changelog index a9efea7..325b31b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,12 @@ -scap-workbench (1.1.3-1) UNRELEASED; urgency=medium +scap-workbench (1.1.3-1) unstable; urgency=low - * New upstream version + * Updated to new upstream version 1.1.3. + * Droped patches merged upstream. + * Updated with latest upstream URLs. + * Fixed FTBFS on non-amd64 (Closes #848250). + * Fixed lintian warning vcs-field-uses-insecure-uri. + + * Upload sponsored by Petter Reinholdtsen. -- Frank Lin PIAT Thu, 15 Dec 2016 22:27:10 +0100 It will allow us to see if the code now build on all architectures. -- Happy hacking Petter Reinholdtsen
Bug#848336: less: bad redraw with double-width character after search
Package: less Version: 481-2.1 Severity: normal When a long line contains a double-width character, it is redrawn incorrectly after a search. To reproduce this issue: 1. Open the attached file with "less -c" in a 80-column terminal. The second line in the terminal contains: 3456 2. Search for a string with no matches. The second line in the terminal now contains: 4566 Tested with xterm 327, rxvt-unicode v9.22, and GNOME Terminal 3.22.1. Note: The -c option is not really necessary to reproduce this bug. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/12 CPU cores) Locale: LANG=POSIX, 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 less depends on: ii debianutils 4.8.1 ii libc62.24-8 ii libtinfo56.0+20161126-1 less recommends no packages. less suggests no packages. -- no debconf information 123456789012345678901234567890123456789012345678901234 🍸 12345678901234567890123456 1. Open this file with "less -c" in a 80-column terminal. The second line in the terminal contains: 3456 2. Search for a string with no matches. The second line in the terminal now contains: 4566 Tested with xterm 327, rxvt-unicode v9.22, and GNOME Terminal 3.22.1. Note: The -c option is not really necessary to reproduce this bug.
Bug#817922: [Pkg-roundcube-maintainers] Bug#817922: Bug#817922: PEAR issues
On Fri, Dec 16 2016, Sandro Knauß wrote: > now transistion of Php7 is through and we are in freeze. Is it still an issue? Not anymore, thanks!
Bug#848337: dh-make-perl: Require user intervention to resolve version ambiguity
Package: dh-make-perl
Version: 0.92
Severity: normal
Tags: patch
Dear Maintainer,
Upstream developers sometimes upload Perl modules to CPAN, forgetting to update
the version in the META, Build or Makefile. In these situations, dh-make-perl
ignores the CPAN version and trusts the META.yml version, without making the
packager aware of the discrepancy. Examples of upstream modules where this has
happened are Cache::Memcached::libmemcached and Catalyst::View::CSV.
The attached patch causes dh-make-perl to quit if the module version does not
match the CPAN version, and requires the user to explicity specify the version
with --version.
This reduces the likelihood of the packager uploading a package with a version
number which does not correspond to the actual upstream version.
Thanks.
Christopher Hoskin
>From 71938776dbb0b3ab7d6f35c009ee675655449639 Mon Sep 17 00:00:00 2001
From: Christopher Hoskin
Date: Fri, 16 Dec 2016 11:12:47 +
Subject: [PATCH] Require user intervention to resolve version ambiguity
---
lib/DhMakePerl/Command/Packaging.pm | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/DhMakePerl/Command/Packaging.pm b/lib/DhMakePerl/Command/Packaging.pm
index 2b07ac4..d759b66 100644
--- a/lib/DhMakePerl/Command/Packaging.pm
+++ b/lib/DhMakePerl/Command/Packaging.pm
@@ -356,8 +356,14 @@ sub extract_name_ver {
$ver = $self->version;
}
-$ver = $self->cfg->version
-if $self->cfg->version;
+if ($self->cfg->version) {
+#Version specified on command line trumps other versions
+$ver = $self->cfg->version
+} elsif ( $self->mod_cpan_version ) {
+if ($self->mod_cpan_version != $ver) {
+die "Version ambiguity, cpan has ".$self->mod_cpan_version.", module has ".$ver.". Please specify version with --version.\n";
+}
+}
# final sanitazing of name and version
$name =~ s/::/-/g if defined $name;
--
2.10.2
Bug#848338: RFP: fiche -- Server for command line pastebin for sharing terminal output
Package: wnpp Severity: wishlist * Package name: fiche Version : 0.9 Upstream Author : Solusipse * URL : https://github.com/solusipse/fiche * License : MIT Programming Lang: C Description : Server for command line pastebin for sharing terminal output The fiche server is Netcat-based command line pastebin. Find a live example at http://termbin.com/. It allows one to do: echo "whatever" | nc ficherserver A link with the paste is returned. (If you want a sponsor for this upload, ping me)
Bug#162917:
Здравствуйте! Гавно вопрос! Вот вся интересующая вас информация: Василий: gosha-necr: ИдитеНахуйСоСвоимиПочтами: ИдитеНахуйСоСвоимиПочтами: gosha-n...@ya.ru 83432060606 16.12.2016, 16:03, "системы администратор" : > внимания; > > аши сообщения превысил лимит памяти, который составляет 5 Гб, определенных > администратором, который в настоящее время работает на 10.9GB, Вы не сможете > отправить или получить новую почту, пока вы повторно не проверить ваш > почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового > ящика, отправьте следующую информацию ниже: > > имя: > Имя пользователя: > пароль: > Подтверждение пароля: > Адрес электронной почты: > телефон: > > Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет > отключен! > > Приносим извинения за неудобства. > Проверочный код: EN: Ru...776774990..2016 > Почты технической поддержки ©2016 > > спасибо > системы администратор С уважением, Гуляев Гоша.
Bug#813658: Please enable virgl support
16.12.2016 04:41, john wrote: > Package: qemu-system-x86 > Version: 1:2.7+dfsg-3+b1 > Followup-For: Bug #813658 > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > Hi, Is it possible use virgl/opengl with debian's package? > (No recompile or hand make binary) > > When I launch qemu-system-x86_64 -args -display,gl=on > (which is "man qemu-system-x86_64" say), > It complain "SDL1 display code has no opengl support" issus. > > Please make debian's qemu package support virgl/opengl, thanks. > > *** End of the template - remove these template lines *** John, out of curiocity, what is the reason of this your follow-up, why you sent it? Do you happen to know how to deal with the concerns outlined in this bugreport already? Thanks, /mjt
Bug#848340: RFS: smpq/1.6-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "smpq" * Package name: smpq Version : 1.6-1 Upstream Author : Pali Rohár * URL : https://launchpad.net/smpq * License : GPL-3+ Section : utils It builds those binary packages: kio-smpq - KDE4 kio plugin for StormLib MPQ archiving utility smpq - StormLib MPQ archiving utility To access further information about this package, please visit the following URL: https://mentors.debian.net/package/smpq Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/smpq/smpq_1.6-1.dsc More information about smpq can be obtained from https://launchpad.net/smpq. Changes since the last upload: * New upstream release 1.6 * Fix license name from GPL-3.0+ to GPL-3+ * Update upstream signing-key * Install upstream CHANGELOG file Regards, Pali Rohár signature.asc Description: This is a digitally signed message part.
Bug#847312: [Pkg-roundcube-maintainers] Bug#847312: Bug#847312: roundcube: maintainer address bounces
Hey, I tried to reach toots on 8.Dec 2016 first time, but do not get any answer. So far i searched a little bit in the Debian db and saw that toots is marked as retired. ad...@alioth.debian.org please add hefee@d.o and bernat@d.o as new Admins or give us an password for the lists: Pkg-roundcube-maintainers Pkg-roundcube-devel You can verify that Vincent Bernat and Sandro Knauß are Admins of the pkg- roundcube. Best Regards, sandro PS: I've currently issues sending mails from hefee@d.o, that's why I use b...@sandroknauss.de and my GPG-Key for b...@sandroknauss.de is the same than for hefee@d.o -- Am Mittwoch, 7. Dezember 2016, 13:28:52 CET schrieb Sandro Knauß: > Hey, > > I've wrote the admin of the list a mail with the concerns, than we can > change the settings of the list. > > Btw. also someone from backports team also couldn't wrote to the list. > > Best Regards, > > sandro > > > ❦ 7 décembre 2016 09:52 +0100, Chris Lamb : > > > I tried to send an email to this package address, and I got: > > >Is being held until the list moderator can review it for approval. > > > > > > The reason it is being held: > > > Post by non-member to a members-only list > > > > > > As per Policy §3.3: “The email address given in the ‘Maintainer’ control > > > field must accept mail from those role accounts in Debian used to send > > > automated mails regarding the package. This includes non-spam mail from > > > the bug-tracking system, […].” > > > > Well, this is the case. The BTS is able to post in the mailing > > list. And many other people seem to be able to post to it. I don't have > > access to the administration interface of this mailing list, so I can't > > check what are the rules exactly. I know there is some level of > > filtering since I receive daily reminders for spam (but I can't process > > them, and I don't want to either). signature.asc Description: This is a digitally signed message part.
Bug#848339: unbound-anchor: libunbound.so.2 unknown symbol fake_dsa
Package: unbound-anchor Version: 1.6.0-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upgrade unbound this morning to level 1.6.0-1 * What exactly did you do (or not do) that was effective (or ineffective)? apt-get update apt-get dist-upgrade Debian apt-listbugs is installed and it didn't catch it. DNSSEC is still functional with the current key but I'm assuming this also breaks dnssec-trigger. * What was the outcome of this action? * What outcome did you expect instead? If I run 'service unbound status' I get 'Dec 16 05:47:34 package-helper[11206]: /usr/sbin/unbound-anchor: symbol lookup: error: /usr/lib/x86_64-linux-gnu/libunbound.so.2: undefined symbol: fake_dsa' This also happens if I manually run 'unbound-anchor -a /etc/unbound/root.key' where I keep my DNSSEC key. I'm assuming libunbound2 is broken. *** End of the template - remove these template lines *** -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (800, 'unstable'), (700, 'experimental'), (600, 'stable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-grsec-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages unbound-anchor depends on: ii libc62.24-8 ii libexpat12.2.0-1 ii libssl1.11.1.0c-2 ii libunbound2 1.6.0-1 unbound-anchor recommends no packages. unbound-anchor suggests no packages. -- no debconf information
Bug#848341: jessie-pu: package intel-microcode/3.20161104.1~deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu I would like to update the intel-microcode packages in stable to address several critical errata in newer Intel processors. The updated packages being proposed in this bug report are identical to the ones in unstable/testing and jessie-backports, other than debian/changelog and version numbering. These changes have been tested in unstable since 2016-11-09, in testing since 2016-11-15, and in jessie-backports since 2016-11-17, without any issues being reported. The large change in the "upstream" changelog reflects a change on iucode-tool v2.0 output when listing microcodes: the "pf mask" field was renamed to "pf_mask" to get rid of the embedded space. Relevant information from debian/changelog: + Supposed to fix critical Intel TSX erratum BDE85 on Xeon-D 1500 Y0 + Known to fix critical errata on several Xeon-D 1500 models which will crash vmware (KB2146388) and likely cause problems for Linux as well + Fixes likely critical errata (which ones unknown) on Broadwell-E (Core extreme edition 5th gen, Xeon E5v4, Xeon E7v4) + Removes (very likely outdated) microcode for the C3500 and C5500 family of embedded Xeon (Jasper Forest). These embedded Xeons are typically found on (older) network equipment appliances such as firewalls/IPS/IDS, and also on data storage devices, and thus are supposed to receive microcode updates through their vendors This microcode update is important to get Debian to run in a more stable way on the Xeon-D 1500, and on the Broadwell-E processors. As usual, you will find attached the debdiff output with the changes in the microcode data files removed for brevity. Note that an older microcode data file (20101123) that was *not* used by the build process anymore was also removed. Diffstat: Makefile | 21 changelog | 726 debian/changelog | 56 debian/compat |2 debian/control |4 microcode-20101123.dat |27048 - microcode-20160714.dat |59389 --- microcode-20161104.dat |61630 + 8 files changed, 62079 insertions(+), 86797 deletions(-) (diffstat of the abridged debdiff, for better resolution): Makefile | 21 + changelog| 726 +++ debian/changelog | 56 debian/compat|2 debian/control |4 5 files changed, 449 insertions(+), 360 deletions(-) Thank you! -- Henrique Holschuh diff -Nru intel-microcode-3.20160714.1~deb8u1/changelog intel-microcode-3.20161104.1~deb8u1/changelog --- intel-microcode-3.20160714.1~deb8u1/changelog 2016-07-31 18:11:41.0 -0300 +++ intel-microcode-3.20161104.1~deb8u1/changelog 2016-12-16 08:53:58.0 -0200 @@ -1,496 +1,508 @@ +2016-11-04: + * New Microcodes: +sig 0x00050663, pf_mask 0x10, 2016-10-12, rev 0x70d, size 20480 +sig 0x00050664, pf_mask 0x10, 2016-06-02, rev 0xf0a, size 21504 + + * Updated Microcodes: +sig 0x000306f2, pf_mask 0x6f, 2016-10-07, rev 0x0039, size 32768 +sig 0x000406f1, pf_mask 0xef, 2016-10-07, rev 0xb1f, size 25600 + + * Removed Microcodes: +sig 0x000106e4, pf_mask 0x09, 2013-07-01, rev 0x0003, size 6144 + 2016-07-14: * Updated Microcodes: -sig 0x000306f4, pf mask 0x80, 2016-06-07, rev 0x000d, size 15360 -sig 0x000406e3, pf mask 0xc0, 2016-06-22, rev 0x009e, size 97280 -sig 0x000406f1, pf mask 0xef, 2016-06-06, rev 0xb1d, size 25600 -sig 0x000506e3, pf mask 0x36, 2016-06-22, rev 0x009e, size 97280 +sig 0x000306f4, pf_mask 0x80, 2016-06-07, rev 0x000d, size 15360 +sig 0x000406e3, pf_mask 0xc0, 2016-06-22, rev 0x009e, size 97280 +sig 0x000406f1, pf_mask 0xef, 2016-06-06, rev 0xb1d, size 25600 +sig 0x000506e3, pf_mask 0x36, 2016-06-22, rev 0x009e, size 97280 2016-06-07: * New Microcodes: -sig 0x000406e3, pf mask 0xc0, 2016-04-06, rev 0x008a, size 96256 -sig 0x000406f1, pf mask 0xef, 2016-05-20, rev 0xb1c, size 25600 -sig 0x00050662, pf mask 0x10, 2015-12-12, rev 0x000f, size 28672 -sig 0x000506e3, pf mask 0x36, 2016-04-06, rev 0x008a, size 96256 +sig 0x000406e3, pf_mask 0xc0, 2016-04-06, rev 0x008a, size 96256 +sig 0x000406f1, pf_mask 0xef, 2016-05-20, rev 0xb1c, size 25600 +sig 0x00050662, pf_mask 0x10, 2015-12-12, rev 0x000f, size 28672 +sig 0x000506e3, pf_mask 0x36, 2016-04-06, rev 0x008a, size 96256 * Updated Microcodes: -sig 0x000306c3, pf mask 0x32, 2016-03-16, rev 0x0020, size 22528 -sig 0x000306d4, pf mask 0xc0, 2016-04-29, rev 0x0024, size 17408 -sig 0x000306f2, pf mask 0x6f, 2016-03-28, rev 0x0038, size 32768 -sig 0x000306f4, pf mask 0x80, 2016-02-11, rev 0x000a, size 15360 -sig 0x00040651, pf mask 0x72, 2016-04-01, rev 0x001f, size 20480 -sig 0x00040661, p
Bug#848342: ITP: elpa-git-timemachine -- walk through git revisions of a file
Package: wnpp Severity: wishlist Owner: Lev Lamberov * Package name: elpa-git-timemachine Version : 3.0 Upstream Author : Peter Stiernström * URL : https://github.com/pidu/git-timemachine * License : GPL-3+ Programming Lang: Emacs Lisp Description : walk through git revisions of a file Emacs mode that helps to walk through git revisions of a file. It can be used to browse historic versions of a file with p (previous) and n (next) keys. Also one can jump to a particular revision, copy abbreviate or full hash of the current revision.
Bug#848343: ITP: nrpe-ng -- The next generation Nagios Remote Plugin Executor
Package: wnpp Severity: wishlist Owner: Chris Boot * Package name: nrpe-ng Version : 0.1.2 Upstream Author : Chris Boot * URL : https://github.com/bootc/nrpe-ng * License : GPL Programming Lang: Python Description : The next generation Nagios Remote Plugin Executor This is a rewrite from the ground up of NRPE. This set of programs allows you to run Nagios check scripts on a remote host. Its main selling points are: - nearly drop-in NRPE replacement - real, proper TLS/SSL with keys/certificates - safer command-line argument passing - support for named command-line arguments I plain to maintain both the Debian package and continue upstream development with a colleague for my employer, Tiger Computing, on company time.
Bug#846850: mitmproxy uninstallable in current Sid and soon Stretch Testing (again)
On Dec/15, Maximilian Hils wrote: > (2) mitmproxy may still be installable, but it potentially just > breaks due to backwards-incompatible changes within the dependency. > If I understand things correctly, there's no automated testing that > would alert someone in either case, so (2) may be preferential for > Debian as that it would simply break less often (although possibly in > more subtle ways). I don't know how Debian handles this generally and > what the best practices are for this. All right, I'll remove the versioned dependencies in my package, and users can open bugs when/if a new dependency breaks mitmproxy because of backwards-incompatible changes. Thanks for the all input, cheers, --Seb
Bug#681726: So... what's the current state?
On 16.12.2016 12:08, Antipatico (jaco) wrote: > Hi, > > so a quite long time passed, are there some updates on the subject? > Is someone working on the issue or still no one has taken the > responsibility to maintain the package? > If someone is working on it is there anyway to help? Hi, the problem is still the same. There must be someone who wants to maintain Eclipse and package new updates. We now should have all necessary build-dependencies in Debian. The last one was Tycho which got accepted four days ago. [1] We are approaching the Freeze very quickly now and updating Eclipse and its related modules/plugins is a demanding and time-consuming task. I have been working on Netbeans 8.2 for a while now and many unexpected problems prevented that I could spend more time on packaging Eclipse. Even if Eclipse was packaged today there would basically be no time for testing anymore. So help wanted means, please get involved with packaging and maintaining the software. Best regards, Markus Koschany [1] https://tracker.debian.org/pkg/tycho signature.asc Description: OpenPGP digital signature
Bug#848343: ITP: nrpe-ng -- The next generation Nagios Remote Plugin Executor
On 12/16/2016 01:02 PM, Chris Boot wrote: > This is a rewrite from the ground up of NRPE. This set of programs > allows you to run Nagios check scripts on a remote host. > > Its main selling points are: > - nearly drop-in NRPE replacement > - real, proper TLS/SSL with keys/certificates > - safer command-line argument passing > - support for named command-line arguments > > I plain to maintain both the Debian package and continue upstream > development with a colleague for my employer, Tiger Computing, on > company time. Will you maintain this package under the pkg-nagios umbrella? And how does the TLS/SSL support compare to the reworked TLS/SSL support in NRPE 3.x? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#848343: ITP: nrpe-ng -- The next generation Nagios Remote Plugin Executor
On 12/16/2016 01:02 PM, Chris Boot wrote: > This is a rewrite from the ground up of NRPE. This set of programs > allows you to run Nagios check scripts on a remote host. > > Its main selling points are: > - nearly drop-in NRPE replacement > - real, proper TLS/SSL with keys/certificates > - safer command-line argument passing > - support for named command-line arguments > > I plain to maintain both the Debian package and continue upstream > development with a colleague for my employer, Tiger Computing, on > company time. Will you maintain this package under the pkg-nagios umbrella? And how does the TLS/SSL support compare to the reworked TLS/SSL support in NRPE 3.x? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#848229: systemd: Should systemd provide netbase?
Hello Marco d'Itri, On Thu, Dec 15, 2016 at 11:41:08PM +0100, Marco d'Itri wrote: > On Dec 15, Michael Biebl wrote: [...] > > You could ask the netbase maintainer, Marco, though, if he was open to > > drop the Recommends: ifupdown or demote it to Suggests. > > That would seem like a reasonable suggestion to me. > Yes. #824884. I'd be happy if this could be done, but would also like to ask you to drop the lsb-base dependency. The init-script is long gone after all. Any chance for a netbase upload soon? If you'd like me to NMU the above just say... (I also looked over the other netbase bug reports and might be worth considering #799047 if you're doing a maintainer upload.) Regards, Andreas Henriksson
Bug#848307: gdb-doc has no binaries on any arch
Hello Sven, 2016-12-16 8:18 GMT+01:00 Sven Joachim : > Source: gdb-doc > Version: 7.12-1 > Severity: serious > > The latest upload of gdb-doc included only the source, but the > autobuilders are not allowed to build the binary package because there > is no XS-Autobuild field in debian/control. > > And because of #825398 the binary package has already been removed from > unstable, so you will have to build and upload it. :-( You were amazingly quick :-) Yes, I did source only upload, which I think I did in past, but this time did not build, one reason as you mentioned, we do not set autobuild flag in package metadata and we have not package whitelisted. I was checking if it would be possible to build it in the builders, but probably it'll be easier to do newer source+binary upload. I should fix this in few minutes. :-) Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#709632: gssd: Ignores a preferred_realm specified via the -R option
Hi, version v1.3.4-1 in unstable contains my upstream patch [0], so the problem is fixed in the unstable version. Will there be a new version of this package for Jessie and maybe even Wheezy? Best Max [0] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=a402f768db1dc6497cf7f592b33e142936897de2 -- "Does is bother me, that people hurt others, because they are to weak to face the truth? Yeah. Sorry 'bout that." -- Thirteen, House M.D.
Bug#848344: cgns-convert: /usr/bin/unitconv is already used by xcrysden
Package: cgns-convert Version: 3.3.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + xcrysden Hi, during a test with piuparts I noticed your package ships a binary that is already used by the unrelated package xcrysden: /usr/bin/unitconv Since xcrysden uses that binary name for a long time already, it's probably your package that will have to rename it. Andreas xcrysden=1.5.60-1+b1_cgns-convert=3.3.0-1.log.gz Description: application/gzip
Bug#846410: Help needed with llvm bug
On martes, 13 de diciembre de 2016 11:50:02 ART Lisandro Damián Nicanor Pérez Meyer wrote: > Hi LLVM maintainers! > > We currently have an LLVM-related bug on kdevelop (#846410). It seems that > if the user is using mesa compiled against LLVM 3.9 kdevelop will crash > upon starting (or creating a new project) because it is linked to LLVM 3.8. > > Now I could switch it to use 3.9, but that might get another set of people > into trouble. > > I would like to know if there is a way we can solve this somehow. > > We are currently build depending upon llvm-3.8-dev (>= 1:3.8.1) and > libclang-3.8-dev (>= 1:3.8.1), but maybe we should be using some other > package (AFAIU kdevelop can use llvm >= 3.6). > > Please try to keep 846...@bugs.debian.org while replying :) Hi LLVM team! Can anyone help us here? -- En 1975, a los 99 años, muere Leonor Acevedo de Borges. En el velorio, una mujer da el pésame a Borges y comenta: "Pobre Leonorcita, morirse tan poquito antes de cumplir los 100 años. Si hubiera esperado un poquito más...". Borges responde: "Veo, señora, que es usted devota del sistema decimal". Jorge Luis Borges, en "Borges habla de su madre". http://2tu.us/2i7d Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#846410: Bug#848331: kdevelop: Segfault when both llvm-3.8-dev and llvm-3.9-dev are installed
forcemerge 846410 848331 tag 846410 pending thanks On viernes, 16 de diciembre de 2016 12:01:56 ART André Offringa wrote: [snip] > KDevelop crashes with a segfault when I have both llvm-3.8-dev and > llvm-3.9-dev installed. After removing llvm-3.9-dev, kdevelop started > working again. I'll paste the gdb bt below. I did install it wothout issues, but then we figured out that users that siffer this crash are also using a video driver compiled against llvm-3.9. We still don't know if it's something we can "fix". For now I'm going to upload kdevelop compiled against 3.9... But we might start seeing crashes for people using stuff compiled against 3.8 or 4.0... -- Must it be assumed that because we are engineers beauty is not our concern, and that while we make our constructions robust and durable we do not also strive to make them elegant? Is it not true that the genuine conditions of strength always comply with the secret conditions of harmony? Gustave Eiffel, 1887 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#846410: (no subject)
On martes, 13 de diciembre de 2016 21:00:17 ART Kevin Funk wrote: > KDevelop maintainer here. > > You can build KDevelop against anything >= 3.6 just fine. It's recommended > to use the latest possible version. Thus 3.9 will work just fine. > > Regarding the issue with llvmpipe: That's indeed super unfortunate, but I > don't see an easy solution out of it. The only possibility to have two > versions of LLVM runtimes loaded: > > a) enable symbol versioning on the Clang/LLVM side, or > b) link against static version of libclang/LLVM to import all >Clang/LLVM symbols into the KDevelop Clang plugin. > c) use libclang in a separate non-GUI process >(requires a whole overhaul of the integration in KDevelop though...) We should try to get (a). (b) is a non-go in Debian, and (c) is really up to you upstreams, with all the required effort it might mean. *Thanks* for staying in the loop. -- No subestimes el ancho de banda de un camión cargado de cintas. Andrew S. Tanenbaum Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#848097: terminal.app
Dear Ben Longbons, Terminal.app emulates a DEC VT 100 terminal afaik. Refer the source package README. For the arguments supported please consult the manual page. man Terminal (section 1). Yours,
Bug#846410: Help needed with llvm bug
Hello, Le 16/12/2016 à 13:49, Lisandro Damián Nicanor Pérez Meyer a écrit : > On martes, 13 de diciembre de 2016 11:50:02 ART Lisandro Damián Nicanor Pérez > Meyer wrote: >> Hi LLVM maintainers! >> >> We currently have an LLVM-related bug on kdevelop (#846410). It seems that >> if the user is using mesa compiled against LLVM 3.9 kdevelop will crash >> upon starting (or creating a new project) because it is linked to LLVM 3.8. >> >> Now I could switch it to use 3.9, but that might get another set of people >> into trouble. >> >> I would like to know if there is a way we can solve this somehow. >> >> We are currently build depending upon llvm-3.8-dev (>= 1:3.8.1) and >> libclang-3.8-dev (>= 1:3.8.1), but maybe we should be using some other >> package (AFAIU kdevelop can use llvm >= 3.6). >> >> Please try to keep 846...@bugs.debian.org while replying :) > > Hi LLVM team! Can anyone help us here? I think you should report a bug upstream (kdevelop). I don't see how to fix that in the llvm-toolchain itself. Sorry, Sylvestre
Bug#844701: dpkg-maintscript-helper: Version comparison fails for supposedly valid versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2016-12-16 at 11:00 +0100, Guido Günther wrote: > I've tried the attached patches they still fail in my use case (pbuilder > create). Thanks for the root cause. My use case is the same. > The reason is that stderr contains completely unrelated garbish > form ld.so. I've added a version that relies on exit status only. Hmmm. Yes. THis must be the reason. I'm going to try your patch. > Can > this be applied? - -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhT5k4ACgkQpjpYo/Lh dWnTUA/9EJmXudK5OR/Oo9DUtHzkEYsuN+g+q0ioZXV2Qn/PKKH/NaAVmQHxqjIc lv1sPtsSnKqXnU1Up2M60hjttSPifvdgOvCz9kvXgUmIE7Lw3joMxh7fl/guLhaV RNCpg0l7BOrBWJOIBp6GnIYclrtT5ZqYuFI2jYc3BIXTRSkjvAIuZmoodPIWxfcH U/YlaRSfRlT2eX1mk/Z3pK/0TZIfuQjEBaVSD3tsGluXaXO/ADWj9OQ5Y1t4jYJp 9msZlzkzguc7P52WEyiWEaAVcZlOcIKwTDhbr9NO6up1q8WE1EXrIhXP0p8l7Fpq GYj03bijGqaFHBJf+MCq/RPKDUzV2sd1GYJWXlXC1VEjXhTBFv/qef7wd/t5dx6J SY8EGl0FFUJStths2WEG8cFM/jhk+n1yt3Fq3gW+Ofz72+MISPAyy/lMK4OPWZ1p kFW0ftMqx55DU+KFKnZHofNBilO3v9MCKvnOd6YSIBDvWJ6BGT9PNC4BALo/nhwV SG8MPtS7cSK00sSLRIeJNAUJBD/c/4fXomcAUi9xqBklpxtxBsl0XAbr2k8XM1Zo /E+vB4s+bR7d1dusLlL/MMooVEbyVgYDcK1nBUPPz2Br9komcu33sXs1hnoQ+kl4 gSVqEag/8JNjY810WTp90Ai2bXMXzk+R78Kne5sRrSKazVgf3SQ= =Z9f/ -END PGP SIGNATURE-
Bug#848339: I do apologize.
In my error in the formatting of reporting this bug. My main reporting should be filed under "What was the outcome of this action?" not "What outcome did you expect instead?" The outcome was the libunbound2 unresolved symbol error and the expected outcome was dns-anchor to perform normally. My apologies for the formatting of this bug. I am not that familiar with nano and my main editor is vim-nox. Maybe in the reportbug package there could be a way to 'dpkg-reconfigure reportbug' and have a way to choose the editor to use. Just a suggestion. Best Regards, Lance Lassetter
Bug#845157: systemd: loading compressed modules no longer works
Hi Marco Am 16.12.2016 um 09:17 schrieb Marco d'Itri: > On Nov 21, M G Berberich wrote: > >> But libkmod was held on 22-1, because debian libkmod does not support >> compressed modules. >> Upgrading to (a modified) 23-1 did solve the problem. >> There seems to be some incompatibility between 22-1 and 23-1 that is >> not reflected in the libraries major-number. > I do not understand what this is about: the Debian kmod package has > never supported compressed modules. Ok, so this bug report should be closed as invalid then? In any case, it seems wrong to have it filed against systemd. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#848345: [gpsshogi] 0.7.0 not installable due to dependency
Package: gpsshogi Version: 0.7.0 Severity: serious Gpsshogi 9.7.0 can not be freshly installed because it depends on libosl1 (>= 0.6.0) which is not installable but is replaced by libosl1v5:i386 libosl1v5 which is already installed --- System information. --- Architecture: Kernel: Linux 4.8.0-2-amd64 Debian Release: stretch/sid 500 unstablepackages.siduction.org 500 unstable ftp2.de.debian.org 500 stable repo.vivaldi.com 500 stable dl.google.com --- Package information. --- Depends (Version) | Installed ===-+-= libboost-date-time1.58.0| 1.58.0+dfsg-5.1 libboost-filesystem1.58.0 | 1.58.0+dfsg-5.1 libboost-program-options1.58.0 | 1.58.0+dfsg-5.1 libboost-system1.58.0 | 1.58.0+dfsg-5.1 libboost-thread1.58.0 | 1.58.0+dfsg-5.1 libc6 (>= 2.14) | libgcc1 (>= 1:3.0) | libgsl2 | libosl1v5 | libpocofoundation9v5| libpoconet9v5 | libqt4-network (>= 4:4.5.3) | libqt4-qt3support (>= 4:4.5.3) | libqtcore4 (>= 4:4.8.0) | libqtgui4 (>= 4:4.8.0) | libreadline6 (>= 6.0) | libstdc++6 (>= 5.2) | libtcmalloc-minimal4| gpsshogi-data (= 0.6.0-3+nmu2) | Package's Recommends field is empty. Package's Suggests field is empty.
Bug#843356: [Pkg-roundcube-maintainers] Bug#843356: enigma plugin does not seem to work anymore
> roundcube-core already suggest php-crypt-gpg. I think suggest is okay I know. > for a > dependency of a plugin. Could you then please document the problem that said plugin is unusable until we get a working php-crypt-gpg again? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Bug#844701: dpkg-maintscript-helper: Version comparison fails for supposedly valid versions
Hi! On Fri, 2016-12-16 at 11:00:01 +0100, Guido Günther wrote: > I've tried the attached patches they still fail in my use case (pbuilder > create). The reason is that stderr contains completely unrelated garbish > form ld.so. I've added a version that relies on exit status only. Can > this be applied? Ah clever indeed! I had come to the same conclusion that relying on stdout/stderr was a very bad idea, so I had already implemented a bunch of --validate- commands in dpkg (with being version, pkgname, trigname and archname), which do exactly that, are not affected by debug settings or similar. Which is what I'm in principle planning on merging for .16 which I should really be releasing this week. :/ Sorry for the delay. Things have not been looking good from here. :( Thanks, Guillem
