Bug#870329: qemu-user-static: please make it support a configuration file for QEMU_CPU etc
Package: qemu-user-static Version: 1:2.8+dfsg-6 Severity: normal When /usr/bin/qemu-arm-static is run by default it emulates armv7l. I want to emulate armv5tel so I need to set QEMU_CPU=pxa250 before running /usr/bin/qemu-arm-static. This is OK when I want to run a single process or chroot shell. But when I want to have a full environment running with systemd-nspawn and ssh to it things don't work. I wrote the following wrapper to /usr/bin/qemu-arm-static as a hack to work around this, but it is annoying to deploy. It would be much easier if /usr/bin/qemu-arm-static would read /etc/qemu/arm.conf or something to get configuration for such things. #include #include #include int main(int argc, char **argv) { if(setenv("QEMU_CPU", "pxa250", 1)) { printf("Can't set $QEMU_CPU\n"); return 1; } execv("/usr/bin/qemu-arm-static.orig", argv); printf("Can't execute \"%s\" because of qemu failure\n", argv[0]); return 1; } -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.1.7-1 Versions of packages qemu-user-static suggests: ii sudo 1.8.20p2-1 -- no debconf information
Bug#557765: libfishsound1-dev: The -dev package should be named libfishsound-dev
[Ron] > So if you just want to get this off the triage radar, that seems like > the better option to me - unless I'm missing something like there > being an actual ABI change about to happen. My main goal is to get it off the bug list, but bringing it in line with other dev packages in Debian and closer to the recommended practice seem like nice goals too. If no-one insist on the renaming, I agree we just close this bug and do the renaming in the next API change, which given the current activity level with libfishsound most likely is never going to happen. -- Happy hacking Petter Reinholdtsen
Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts
I am adding the maintainer of the New Maintainer's Guide and the Guide for Debian Maintainers, Osamu Aoki, to this discussion. I would like to reassign this wishlist bug to one of those packages if Osamu agrees. On Sun, Jul 16, 2017 at 6:59 PM, Paul Hardy wrote: > Sean, > > On Sun, Jul 16, 2017 at 5:42 PM, Sean Whitton > wrote: >> Hello Paul, >> >> On Sun, Jul 16, 2017 at 04:28:03PM -0700, Paul Hardy wrote: >>> My intention was to point someone new to packaging fonts in Debian in >>> the direction of an easy path, rather than leaving it up to that >>> person to find things out the hard way--or worse yet, doing things the >>> hard way. >> >> Right. It would be good to have that somewhere ... >> >>> How about a footnote pointing to >>> https://wiki.debian.org/Fonts/PackagingPolicy? That document is not >>> formal policy, but it would make life easier for someone if they are >>> new to packaging fonts. >>> >>> Alternatively, do you think this bug report should get reassigned to >>> the New Maintainer's Guide and be addressed as a request there? The >>> scope of that guide is mainly to walk someone through creating a >>> simple binary package. >> >> ... and the new maintainer's guide seems like a decent place. >> >> How about adding a section to that guide listing links to packaging >> guides for specific types of packages, such as fonts? > > I can certainly do that if the maintainer of that package would like > to add such a section. I have filed a bug report with a set of > proposed patches for maint-guide, and would wait for that to get > processed first (with my patches accepted or rejected). Osamu: Do you think that mentioning font packaging in the Guide for Debian Maintainers or the New Maintainer's Guide is appropriate? If so, I will reassign this bug to the package you prefer. I think just a pointer to https://wiki.debian.org/Fonts/PackagingPolicy with a brief explanation will be enough, with the expectation that the Fonts Wiki page will always have the most current information. If you do not think that information about packaging fonts belongs in either guide, let me know and I will try to come up with some other idea. As of today, the New Maintainer's Guide is still required reading for New Maintainers, but the Guide for Debian Maintainers is not required reading. I will assume that is going to change in the future with Osamu's focus on the latter document going forward if font packaging information is added there. Otherwise, someone wanting to package fonts for Debian for the first time could still wind up having to hunt for and hopefully be lucky enough to find the Fonts Wiki page to learn how. Thank you, Paul Hardy
Bug#867541: please build ruby binding of grpc
Control: tag -1 help On Wed, 12 Jul 2017 23:10:48 +0530 Pirate Praveen wrote: > On Mon, 10 Jul 2017 01:00:07 +0530 Pirate Praveen > wrote: > > Attaching the debdiff to build ruby-grpc. > Sesse, László, > > See this debdiff which use --gem-install option so it installs all > required files. But its failing to find openssl. > > Can you help? I was able to build it locally since I had older openssl > installed I guess. The failure is in sbuild. I was able to build it against libgrpc.a from libgrpc-dev, but during tests I get undefined symbol error. I'm trying to figure out a way to pass libgrpc.a path to the built-tree instead of trying to build it again. Current work can be found at https://git.fosscommunity.in/praveen/grpc (under branch ruby). RUBYLIB=. GEM_PATH=debian/ruby-grpc/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all ruby2.3 -S rake -f debian/ruby-tests.rake /usr/bin/ruby2.3 /usr/bin/rspec --pattern ./src/ruby/spec/\*\*/\*_spec.rb --format documentation /<>/debian/ruby-grpc/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0/gems/grpc-1.3.2/src/ruby/lib/grpc/grpc.rb:37:in `require_relative': /<>/debian/ruby-grpc/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0/gems/grpc-1.3.2/src/ruby/lib/grpc/grpc_c.so: undefined symbol: inflate - /<>/debian/ruby-grpc/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0/gems/grpc-1.3.2/src/ruby/lib/grpc/grpc_c.so (LoadError) signature.asc Description: OpenPGP digital signature
Bug#820983: ok to close
this bug can be closed since the omission was addressed not long after. samba (2:4.2.10+dfsg-0+deb8u3) jessie-security; urgency=high ... [ Andrew Bartlett ] * Add back better NEWS item for 2:4.2.10+dfsg-0+deb8u1 ... -- Salvatore Bonaccorso Wed, 01 Jun 2016 17:05:31 +0200 I verified this on verison 2:4.2.14+dfsg-0+deb8u7 thanks Andrew and Salvatore Vince
Bug#870328: sox: CVE-2017-11332 CVE-2017-11358 CVE-2017-11359
Source: sox Version: 14.4.1-5 Severity: important Tags: upstream security Hi, the following vulnerabilities were published for sox. CVE-2017-11332[0]: | The startread function in wav.c in Sound eXchange (SoX) 14.4.2 allows | remote attackers to cause a denial of service (divide-by-zero error and | application crash) via a crafted wav file. CVE-2017-11358[1]: | The read_samples function in hcom.c in Sound eXchange (SoX) 14.4.2 | allows remote attackers to cause a denial of service (invalid memory | read and application crash) via a crafted hcom file. CVE-2017-11359[2]: | The wavwritehdr function in wav.c in Sound eXchange (SoX) 14.4.2 allows | remote attackers to cause a denial of service (divide-by-zero error and | application crash) via a crafted snd file, during conversion to a wav | file. All three affect 14.4.1-5 so commont to jessie, stretch and sid, thus filled only one bug for all three CVEs. Please clone and reassign if the issues cannot be fixed all at the same time. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-11332 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11332 [1] https://security-tracker.debian.org/tracker/CVE-2017-11358 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11358 [2] https://security-tracker.debian.org/tracker/CVE-2017-11359 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11359 [3] http://seclists.org/fulldisclosure/2017/Jul/81 Regards, Salvatore
Bug#870232: flex FTBFS: dh_install: Cannot find (any matches for) "debian/tmp/include" (tried in ., debian/tmp)
reassign 870232 debhelper found 870232 10.7 fixed 870232 10.7.1 close 870232 forcemerge 870232 870230 thanks On Mon, 31 Jul 2017 06:59:42 +0200 Helmut Grohne wrote: > Source: flex > Version: 2.6.1-1.3 > Severity: serious > User: helm...@debian.org > Usertags: rebootstrap > > flex fails to build from source in unstable amd64. > > | dh_install > | dh_install: Cannot find (any matches for) "debian/tmp/include" (tried in ., > debian/tmp) > | > | dh_install: libfl-dev missing files: debian/tmp/include > | dh_install: Cannot find (any matches for) "debian/tmp/lib" (tried in ., > debian/tmp) > | > | dh_install: libfl-dev missing files: debian/tmp/lib > | dh_install: missing files, aborting > | debian/rules:43: recipe for target 'override_dh_install' failed > | make[1]: *** [override_dh_install] Error 25 > | make[1]: Leaving directory '/<>' > | debian/rules:27: recipe for target 'binary-arch' failed > | make: *** [binary-arch] Error 2 > | dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit > status 2 > > I guess #813266 is the cause. > > Helmut > > Hi, This was a regression in debhelper 10.7 that was fixed in 10.7.1. Thanks, ~Niels
Bug#870230: libpng-dev: error when installing together: trying to overwrite shared '/usr/bin/libpng16-config'
reassign 870230 debhelper found 870230 10.7 fixed 870230 10.7.1 close 870230 thanks On Mon, 31 Jul 2017 06:45:42 +0200 Helmut Grohne wrote: > Package: libpng-dev > Version: 1.6.30-2 > Severity: important > User: helm...@debian.org > Usertags: rebootstrap > > When installing a libpng-dev built with debhelper (<< 10.7) and a > libpng-dev built with debhelper (>= 10.7) together, dpkg errors out: > > | Unpacking libpng-dev:mips (1.6.30-2) ... > | dpkg: error processing archive > /tmp/apt-dpkg-install-gmKkex/19-libpng-dev_1.6.30-2_mips.deb (--unpack): > | trying to overwrite shared '/usr/bin/libpng16-config', which is different > from other instances of package libpng-dev:mips > | dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) > > libpng-config.in interpolates @includedir@ which happens to be > ${prefix}/include on older debhelper releases and /usr/include on newer > ones. Thus the interpolated file differs (in bytes, not in behaviour). > > The relevant debhelper change is #813266. > > I believe that a good solution to this problem would be adding a version > constraint on debhelper. There are two reasonable choices: > > * Build-Depends: debhelper (>= 10.7~) > * Build-Depends: debhelper (<< 10.7~) > > The former is useful for unstable and the latter is useful for > backports. > > Helmut > > Hi, This was a regression in debhelper 10.7 that was fixed in 10.7.1. Thanks, ~Niels
Bug#870326: yaml-cpp: CVE-2017-11692
Source: yaml-cpp Version: 0.5.1-1 Severity: important Tags: upstream security Forwarded: https://github.com/jbeder/yaml-cpp/issues/519 Control: clone -1 -2 Control: reassign -2 src:yaml-cpp0.3 Control: found -2 0.3.0-1.1 Control: retitle -2 yaml-cpp0.3: CVE-2017-11692 Hi, the following vulnerability was published for yaml-cpp. CVE-2017-11692[0]: | The function "Token& Scanner::peek" in scanner.cpp in yaml-cpp 0.5.3 | and earlier allows remote attackers to cause a denial of service | (assertion failure and application exit) via a '!2' string. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-11692 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11692 [1] https://github.com/jbeder/yaml-cpp/issues/519 Regards, Salvtore
Bug#870325: /etc/init.d/tinyproxy points to the old path of tinyproxy.conf
Package: tinyproxy Version: 1.8.4-2 Severity: important Tags: patch Hello, A old path for the configuration file in /etc/init.d/tinyproxy prevents tinyproxy to start with sysvint. Also, /etc/tinyproxy.conf should no longer be listed as conffile for package tinyproxy. (Eg. the "-- Configuration Files:" section at the end of this mail is confusing.) Regards, Yixuan == PATCH == diff --git a/debian/init b/debian/init index be80a0d..368b61f 100644 --- a/debian/init +++ b/debian/init @@ -14,7 +14,7 @@ # PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin -CONFIG=/etc/tinyproxy.conf +CONFIG=/etc/tinyproxy/tinyproxy.conf DAEMON=/usr/sbin/tinyproxy DESC="Tinyproxy lightweight HTTP proxy daemon" FLAGS= == END OF PATCH == -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.6-1 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages tinyproxy depends on: ii init-system-helpers 1.49 ii libc62.24-12 ii logrotate3.11.0-0.1 ii lsb-base 9.20161125 tinyproxy recommends no packages. tinyproxy suggests no packages. -- Configuration Files: /etc/init.d/tinyproxy changed [not included] /etc/tinyproxy.conf [Errno 2] No such file or directory: '/etc/tinyproxy.conf' /etc/tinyproxy/tinyproxy.conf changed [not included] -- no debconf information
Bug#870324: RFS: stendhal-installer/0.1-1 [ITP] -- Unofficial way to easily install game
Rectifying: > More information about hello can be obtained from https://github.com/coringao/ stendhal-installer More information about 'Stendhal Installer' can be obtained from https://github. com/coringao/stendhal-installer Thanks! -- ⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao] ⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao ⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780 ⠈⠳⣄⠀⠀⠀ 2157 630B D441 A775 BEFF D35F FA63 ADA6 B638 B780 signature.asc Description: This is a digitally signed message part
Bug#870324: RFS: stendhal-installer/0.1-1 [ITP] -- Unofficial way to easily install game
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "stendhal-installer" * Package name: stendhal-installer Version : 0.1-1 Upstream Author : Carlos Donizete Froes * URL : https://stendhalgame.org * License : GPL-2+ Section : games It builds those binary packages: stendhal-installer - Unofficial way to easily install game To access further information about this package, please visit the following URL: https://mentors.debian.net/package/stendhal-installer Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/stendhal-installer/stendhal-installer_0.1-1.dsc More information about hello can be obtained from https://github.com/coringao/stendhal-installer Regards, Carlos Donizete Froes
Bug#842706: solr-jetty: packaged version is ancient
I made an attempt to package a newer version of Solr last December, but it got bogged down by a combination of missing dependencies and problems related to Maven that I wasn't able to troubleshoot with my limited Java packaging experience. I've published works in progress here: - https://github.com/sruggier/debian-morfologik-stemming - https://github.com/sruggier/debian-spatial4j - https://github.com/sruggier/debian-solr I'd welcome anyone who wants to either take these over, or help troubleshoot the dependency problems I was having. On Mon, 31 Oct 2016 09:23:04 -0400 Thomas Quinot wrote: > Package: solr-jetty > Version: 3.6.2+dfsg-9 > Severity: normal > > Dear Maintainer, > > The package version of Solr is 3.6.2, released in December 2012. > The current Solr release is 6.2.1, release in September 2016. > Are there any plans to upgrade the package? > > Thanks! > > -- System Information: > Debian Release: 8.6 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > >
Bug#557765: libfishsound1-dev: The -dev package should be named libfishsound-dev
On Tue, Aug 01, 2017 at 12:05:34AM +0200, Petter Reinholdtsen wrote: > So, perhaps now is a good time to rename the -dev package? > What do the rest of you think? Any of you have time to follow > up the migration process? I doubt I will any time soon. :( Personally, I don't see much value in gratuitous renaming of packages. The original "bug" reported was: "The -dev package should be named libfishsound-dev, without the 1, so that reverse dependencies don't need to bump their build dependency whenever the ABI changes." And it's now been nearly 8 years, and that fear still hasn't actually come true. It hasn't changed ABI, so it would be a bit ironic to make this be a self-fulfilling prophecy and break the rdeps just to close this bug :) If it ever does change ABI, *that* might be a good time to rename this, but even then, if you don't want coinstallability, you still wouldn't *have* to rename the -dev package from what it is now, so this problem could be avoided that way too. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557765#10, the maintainer at the time wrote: > close 557765 > tags 557765 wontfix but just didn't actually CC the control server with that. So if you just want to get this off the triage radar, that seems like the better option to me - unless I'm missing something like there being an actual ABI change about to happen. Cheers, Ron
Bug#870323: ahven: FTBFS with gnat-7: assertion error during build tests
Source: ahven Version: 2.6-1.1 Severity: minor Hello. A rebuild of ahven with gnat-7 in experimental crashes with: -- ... "gnatmake" -P ../../ahven_tests.gpr -aP../.. -p-j2 -R -v -eS -cargs -g -O2 -fdebug-prefix-map=/build/ahven-2.6=. -fstack-protector-strong -bargs -largs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,-z,defs ... gnatbind-7 -shared -E -static -F -x /build/ahven-2.6/gnat/obj/dynamic/obj/test/tester.ali raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : binde.adb:1005 -- Specifying both -shared and -static can probably be considered an error. The attached archive contains the changes used to reproduce the problem, as well as various unrelated suggestions that you may be interested in. ahven-gcc-7.tar.gz Description: application/gzip
Bug#834129: pgadmin4 needs flask_htmlmin
I spent an hour trying to roll a barebones deb from pgadmin4.git. I got stuck here: Exception occurred: File "/tmp/pgadmin4-X/web/pgadmin/__init__.py", line 19, in from flask_htmlmin import HTMLMIN ImportError: No module named flask_htmlmin According to apt-file, flask_htmlmin isn't in Stretch. It appears to be this: https://github.com/hamidfzm/Flask-HTMLmin That puts pgadmin4 into my "too hard" basket for now. Here's where I got to before giving up: debian/changelog:pgadmin4 (1.6+53-ge506fa1-1) unstable; urgency=low debian/changelog: debian/changelog: * Initial release (Closes: #) debian/changelog: debian/changelog: -- root Tue, 01 Aug 2017 11:56:36 +1000 debian/clean:# FIXME: remove after calling python3 properly debian/clean:*/*.pyc debian/clean:*/*/*.pyc debian/clean:*/*/*/*.pyc debian/compat:9 debian/control:Source: pgadmin4 debian/control:Section: unknown debian/control:Priority: optional debian/control:Maintainer: root debian/control:Build-Depends: debhelper (>= 9), python-flask, python-sphinx, python-flask-babel debian/control:Standards-Version: 3.9.5 debian/control:Homepage: debian/control: debian/control:Package: pgadmin4 debian/control:Architecture: any debian/control:Depends: ${shlibs:Depends}, ${misc:Depends} debian/control:Description: debian/control: debian/docs:README debian/docs:libraries.txt debian/docs:requirements.txt debian/rules:#!/usr/bin/make -f debian/rules:DPKG_EXPORT_BUILDFLAGS = 1 debian/rules:include /usr/share/dpkg/default.mk debian/rules:%: debian/rules: dh $@ debian/source/format:3.0 (quilt) signature.asc Description: Digital signature
Bug#870252: pkg-perl-autopkgtest: skip t/00-compile/*.t
On Mon, 31 Jul 2017 13:18:55 +0300, Niko Tyni wrote: > These are not going to work with our autopkgtest setup as they look for > modules in the build tree. Also, we run 'perl -wc' in the autopkgtest > syntax check which should be more or less equivalent. > I propose that we add t/00-compile/*.t to the list that the smoke check > skips automatically. Ack. There are also tons of t/*compile*.t tests which are at best useless: 246 t/00-compile.t 107 t/00_compile.t 68 t/01_compile.t 15 t/compile.t 11 t/00-compile ← the directory 8 t/000-compile-modules.t 6 t/00compile.t 6 t/01-compile.t 5 t/author-00-compile.t 5 t/01compile.t 2 t/20compile.t 2 t/000-compile.t 2 t/001_compile.t 2 t/000_compile.t 2 t/compile-time.t … (and we are patching some of the t/*compile.t files for autopkgtest) pkg-perl-tools' TODO file also has the note (by me): "maybe skip more *pod* tests?" Currently we're removing rm -f $TDIR/t/pod.t rm -f $TDIR/t/pod-coverage.t but there's also (*pod*, with at least 4 hits): 219 t/release-pod-syntax.t 127 t/release-pod-coverage.t 108 t/author-pod-syntax.t 70 t/pod_coverage.t 59 t/author-pod-coverage.t 53 t/02pod.t 47 t/03podcoverage.t 39 t/99pod.t 29 t/99_pod.t 27 t/pod_cvg.t 27 t/98_pod.t 27 t/pod_syn.t 22 t/99-pod.t 21 t/author-pod-spell.t 15 t/release-pod-linkcheck.t 13 t/99_pod_coverage.t 12 t/00-pod.t 11 t/02-pod-coverage.t 10 t/00_pod.t 10 t/99-pod-coverage.t 9 t/91podcover.t 9 t/90podtest.t 8 t/10pod.t 8 t/03-test-pod.t 7 t/02_pod.t 7 t/02-pod.t 6 t/release-pod-no404s.t 6 t/pod_cvg_pp.t 6 t/01-pod.t 6 t/release-pod-spell.t 6 t/00pod.t 5 t/98-pod_coverage.t 5 t/z_pod.t 5 t/podspell.t 5 t/pods.t 5 t/11pod_cover.t 5 t/01_pod.t 5 t/90-pod.t 5 t/03_pod_coverage.t 5 t/podcover.t 5 t/98_pod_coverage.t 4 t/99podcov.t 4 t/98_pod-coverage.t 4 t/91-pod-coverage.t 4 t/01-pod-coverage.t 4 t/98podsyn.t 4 t/pod_cov.t 4 t/98pod-coverage.t 4 t/99_podcoverage.t (*release* and *author* are probably skipped but the rest of the variety is quite interesting.) I also assume that for rm -f $TDIR/t/04critic.t rm -f $TDIR/t/97_meta.t we could fine some nice variations. 15 t/perlcritic.t 8 t/critic.t 5 t/04critic.t 3 t/96-perl-critic.t 3 t/90-release-perlcritic.t 2 t/93-perl-critic.t … 36 t/release-distmeta.t 17 t/97_meta.t 9 t/96metatest.t 9 t/94metatest.t 9 t/meta.t 6 t/metadata.t 6 t/release-meta-json.t 3 t/02metafiles.t 3 t/05metaspec.t 3 t/04metatester.t 3 t/z_meta.t 2 t/006_metaclass_traits.t 2 t/meta-yml.t 2 t/98metatest.t 2 t/03metaversion.t 2 t/meta-json.t 2 t/release-meta-yaml.t 2 t/02_meta.t … Lots of opportunities to clean up a bit :) Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#870309: [checkbashisms] False positive in "sourced script with arguments"
Chris Lamb writes: > Note that the unquoted version on line 3 is not warned about. Not sure > if this is due to the subshell or the implicit nested quotes.. To distinguish, I've made another test case. Attached to this message #! /bin/sh printf "%s %s\n" "command-not-quoted" "list-not-quoted" . $(printf "lorem %s\n" foo bar baz) printf "%s %s\n" "command-not-quoted" "list-quoted" . $(printf "lorem %s\n" "foo bar baz") printf "%s %s\n" "command-quoted" "list-not-quoted" . "$(printf "lorem %s\n" foo bar baz)" printf "%s %s\n" "command-quoted" "list-quoted" . "$(printf "lorem %s\n" "foo bar baz")" That causes two warnings from ‘checkbashisms’: = $ checkbashisms ./870309.test.sh possible bashism in ./870309.test.sh line 10 (sourced script with arguments): . "$(printf "lorem %s\n" foo bar baz)" possible bashism in ./870309.test.sh line 13 (sourced script with arguments): . "$(printf "lorem %s\n" "foo bar baz")" = So, it complains when the argument to ‘.’ is a quoted command substitution, but not when it's an unquoted command substitution. -- \ “I busted a mirror and got seven years bad luck, but my lawyer | `\thinks he can get me five.” —Steven Wright | _o__) | Ben Finney
Bug#870322: apt: AutoRemover broke stuff
Package: apt Version: 1.4.7 Severity: important Tags: upstream Dear Maintainer, I enabled the sources for 'testing' alongside sources for stable. I used apt- pinning to prefer ONLY packages from stable. I upgraded my system but carelessly, I upgraded to testing, as my I miss-spelled the 'preferences' file for apt-pinning. I corrected my pinning and tried to sync with stable by making use of apt-pinning to downgrade my packages. First, I updated my apt packages list (apt update), then I ran an apt upgrade. When I tried to run apt dist- upgrade, I received the following message: -- Reading state information... Done Calculating upgrade... Done Hmm, seems like the AutoRemover destroyed something which really shouldn't happen. Please file a bug report against apt. The following information may help to resolve the situation: The following packages have unmet dependencies: libidn2-0:i386 : Depends: libunistring0:i386 but it is not going to be installed E: Internal Error, AutoRemover broke stuff -- This is what my sources.list looks like: deb http://deb.debian.org/debian stable main contrib non-free deb-src http://deb.debian.org/debian stable main contrib non-free deb http://deb.debian.org/debian stable-updates main contrib non-free deb-src http://deb.debian.org/debian stable-updates main contrib non-free deb http://security.debian.org/ stable/updates main contrib non-free deb-src http://security.debian.org/ stable/updates main contrib non-free deb http://deb.debian.org/debian testing main contrib non-free deb-src http://deb.debian.org/debian testing main contrib non-free deb http://deb.debian.org/debian testing-updates main contrib non-free deb-src http://deb.debian.org/debian testing-updates main contrib non-free deb http://security.debian.org/ testing/updates main contrib non-free deb-src http://security.debian.org/ testing/updates main contrib non-free -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "true"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.11\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-3-amd64$"; APT::NeverAutoRemove:: "^postgresql-"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Periodic ""; APT::Periodic:
Bug#870321: disabled proxies hide working proxies
Package: squid-deb-proxy-client Version: 0.8.9 Severity: normal Tags: patch Hi! I must admit: I have a broken setup. So maybe this could be argued as "garbage in, garbage out". But hear me out before you discard this one. :) In my home network, I did some tests to setup apt-cacher-ng on my workstation, then deployed the results on the real local server. As a result, I have *two* apt-cacher-ng services (or so I thought), running in the local network. It turns out the workstation one isn't working very well and is refusing connexions: nc: unable to connect to address 192.168.0.175, service 3142 Oops. Not sure what happened there. Oh well. But squid-deb-proxy-client don't care right? He'll survive this, there's this timing thing to rate proxies and chose the fastest one and all. Wrong! It actually completely fails to find the right proxy, because the above misconfiguration triggers an exception on the client side: $ apt-avahi-discover error: uncaptured python exception, closing channel ('fd05:5f2d:569f::fc3', 3142, 0, 0): 9223372036854775807 (:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454]) error: uncaptured python exception, closing channel ('192.168.0.175', 3142): 9223372036854775807 (:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454]) http://192.168.0.3:3142/ Boom. Here you can see the correct proxy URL is shown, but only *after* uncaught exceptions are dumped on the console. APT, naturally, freaks out and doesn't find the proxy and falls back to just doing a direct connexion. This could be fine, except it means that a local proxy can be "hidden" with a deliberately misconfigured Avahi service. Now I don't think this is a security issue per se - merely an annoyance. But it *does* make debugging quite hard, because everything seems fine from the client's perspective: the real server is properly configured and answering requests. It's only when you run that script by hand that you realize you left that other service running. I have found, mostly through trial and error, that the following patch fixes the issue: --- apt-avahi-discover 2013-09-20 08:04:12 + +++ apt-avahi-discover 2017-08-01 01:21:12 + @@ -48,6 +48,11 @@ self._time_init = time.time() self.time_to_connect = sys.maxint self.address = addr +def handle_connect_event(self): +try: +asyncore.dispatcher.handle_connect_event(self) +except Exception as e: +DEBUG("error from dispatcher: %s" % e) def handle_connect(self): self.time_to_connect = time.time() - self._time_init self.close() I originally tried to add exception handlers in __init__ and handle_connect but for some reason, handle_connect_event is where the exception is raised. Go figure. With the above, my APT client works correctly even if there's a misbehaving Avahi server out there. Thanks! -- System Information: Debian Release: 8.9 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages squid-deb-proxy-client depends on: ii apt 1.0.9.8.4 ii avahi-utils 0.6.31-5 ii python 2.7.9-1 squid-deb-proxy-client recommends no packages. squid-deb-proxy-client suggests no packages. -- no debconf information
Bug#870320: Missing bold, italic and bold-italic style
Package: xfonts-ayu Version: 1:1.7a-1 The package in stretch is missing bold, italic and bold-italic style contained in jessie's.
Bug#783875: No multi-arch
Would it be acceptable to show a debconf dialog/warning to the user? For example ``` playonlinux requires a 32-bit installation of wine Please make sure multi-arch is enabled: dpkg --add-architecture i386 && apt update And install the wine:i386 package: apt install wine:i386 ``` I spent some time debugging this before finding the bug report. To make matters worse the playonlinux message is very vague. I think reminding users to manually install a dependency would help many. Thanks
Bug#870239: this only happens on timeout
This only happens when there's a timeout, not on other errors. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#870247: [/master] Backport upstream patch fixing bug preventing the Preferences dialog from opening in some cases (Closes: #870247).
tag 870247 pending thanks Date: Mon Jul 31 20:13:05 2017 -0400 Author: Andrew Starr-Bochicchio Commit ID: 8964f48254d181a619b6b59cdf87d968aaae6bb7 Commit URL: https://anonscm.debian.org/cgit/collab-maint/deluge.git;a=commitdiff;h=8964f48254d181a619b6b59cdf87d968aaae6bb7 Patch URL: https://anonscm.debian.org/cgit/collab-maint/deluge.git;a=commitdiff_plain;h=8964f48254d181a619b6b59cdf87d968aaae6bb7 Backport upstream patch fixing bug preventing the Preferences dialog from opening in some cases (Closes: #870247).
Bug#866055: linux-image-4.9.0-3-amd64: Broadwell laptop hangs during light usage since upgrading to stretch
Thanks for the heads up. I've just installed 4.9.30-2+deb9u2 to see if that resolves my issues. I had been running my 4.11.8 kernel with no issues for 25 days before upgrading to Debian's backported 4.11 kernel. Sadly, the same day I upgraded to the backported kernel, it hung! -- Matt Horan m...@matthoran.com http://matthoran.com/
Bug#870319: ben: Please make generated simple query match the set of exact package names
I believe the provided patch is inaccurate because it doesn't handle the case of a given package name appearing at the very beginning or the very end of the dependency list. The syntax that I have used for transition trackers in Ubuntu that works reliably is: /(^| )(list|of|packages)\s*([,(:]|$)/ Note that ^ and $ do not work as part of a character class in the regexp implementation used by ben, the last time I checked. Breaking this down, we have: - either the beginning of the dependency list or a space - the package name - optional whitespace - either the end of the dependency list, or one of the characters [,(:] The three possible terminating characters are for: a bare dependency followed by another ("libevent-0.2-5, [...]"); a versioned dependency ("libevent-0.2-5 (>= [...])"; and a multiarch dependency ("libevent-0.2-5:any"). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#870319: ben: Please make generated simple query match the set of exact package names
Source: ben Version: 0.7.7 Severity: normal Tags: patch Dear Maintainers, The queries generated for the auto-* transitions may match more packages than expected due to \b matching "-". For example this query matches packages depending on libevent-2.0-5: ben query ".depends ~ /\b(libevent)\b/" Please consider accepting the attached patch that fixes the generated queries. Cheers, Balint -- Balint Reczey Debian & Ubuntu Developer From 447a9693c890742807efac0019c517dda1ea12db Mon Sep 17 00:00:00 2001 From: Balint Reczey Date: Tue, 1 Aug 2017 01:13:51 +0200 Subject: [PATCH] Make generated simple query match set of exact package names \b matched "-", too. --- lib/query.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/query.ml b/lib/query.ml index 58ca3dd..1cf09b6 100644 --- a/lib/query.ml +++ b/lib/query.ml @@ -31,7 +31,7 @@ let rec simplify query = match query with | packages -> let packages = List.map Re_pcre.quote packages in let r_string = String.concat "|" packages in - let rex = Re_pcre.regexp (Printf.sprintf "\b(%s)\b" r_string) in + let rex = Re_pcre.regexp (Printf.sprintf "[ ](%s)[, $]" r_string) in EMatch (field, ERegexp (package, rex)) end | EMatch (_, (EDep _ | ERegexp _)) -> query -- 2.11.0
Bug#850165: jwm: typo in the man page
Oops, i replied to the wrong bugreport, sorry, it was meant to this one[1]. [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849534 Samuel Henrique 2017-07-31 20:32 GMT-03:00 Samuel Henrique : > Hello Ulyanich, > > thanks for reporting this, and sorry for taking so long to reply, > > i was not able to reproduce to problem, jwm should not use $HOME/jwmrc/ at > all, could you make sure that jwm is really using that folder for anything? > > or is there any possibility you did run a script that (possibly wrongly) > created that folder? > > my bet is that this was not created by jwm or its package. > > thanks > > > Samuel Henrique >
Bug#849534: Fwd: Bug#850165: jwm: typo in the man page
Hello Ulyanich, thanks for reporting this, and sorry for taking so long to reply, i was not able to reproduce to problem, jwm should not use $HOME/jwmrc/ at all, could you make sure that jwm is really using that folder for anything? or is there any possibility you did run a script that (possibly wrongly) created that folder? my bet is that this was not created by jwm or its package. thanks Samuel Henrique
Bug#850165: jwm: typo in the man page
Hello Ulyanich, thanks for reporting this, and sorry for taking so long to reply, i was not able to reproduce to problem, jwm should not use $HOME/jwmrc/ at all, could you make sure that jwm is really using that folder for anything? or is there any possibility you did run a script that (possibly wrongly) created that folder? my bet is that this was not created by jwm or its package. thanks Samuel Henrique
Bug#855118: wrk: only loops and burns CPU
Hi. Looks like patch intended to fix FTBFS was wrong. And rendered wrk unusable. One can't just replace __sync_val_compare_and_swap by __atomic_compare_exchange without other changes, since former function returns previous value of the atomic variable, while latter returns a boolean value. True for success. Placing that value into "max" starts a infinite loop if n was larger than 1, which is almost always. Proposed patch attached. --- Rinatdiff -urN wrk-4.0.2-prev/src/stats.c wrk-4.0.2/src/stats.c --- wrk-4.0.2-prev/src/stats.c 2017-08-01 01:35:38.0 +0300 +++ wrk-4.0.2/src/stats.c 2017-08-01 01:57:00.900436161 +0300 @@ -25,8 +25,17 @@ __atomic_fetch_add(&stats->count, 1, __ATOMIC_SEQ_CST); uint64_t min = stats->min; uint64_t max = stats->max; -while (n < min) min = __atomic_compare_exchange(&stats->min, &min, &n, false,__ATOMIC_SEQ_CST,__ATOMIC_SEQ_CST); -while (n > max) max = __atomic_compare_exchange(&stats->max, &max, &n, false,__ATOMIC_SEQ_CST,__ATOMIC_SEQ_CST); +while (n < min) { +__atomic_compare_exchange(&stats->min, &min, &n, false, + __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST); +min = stats->min; +} +while (n > max) { +__atomic_compare_exchange(&stats->max, &max, &n, false, + __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST); +max = stats->max; +} + return 1; }
Bug#870318: mate-polkit: MATE polkit built against GTK 3 displays a corrupted icon.
Package: mate-polkit Version: 1.16.0-2 Severity: minor Dear Maintainer, when using the MATE-polkit package that is built against GTK 3 the elevated privileges icon seems a little off (It appears as a 1 1/2 icon), the bug seems to be fixed in the 1.18 version but is it possible that the stretch version will get a fix? -- System Information: Debian Release: 9.1 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-0.bpo.1-amd64 (SMP w/2 CPU cores) Locale: LANG=es_MX.UTF-8, LC_CTYPE=es_MX.UTF-8 (charmap=UTF-8), LANGUAGE=es_MX:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mate-polkit depends on: ii accountsservice0.6.43-1 ii libatk1.0-02.22.0-1 ii libc6 2.24-11+deb9u1 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-0 3.22.11-1 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-01.40.5-1 ii libpolkit-agent-1-00.105-18 ii libpolkit-gobject-1-0 0.105-18 ii mate-polkit-common 1.16.0-2 ii policykit-10.105-18 mate-polkit recommends no packages. mate-polkit suggests no packages. -- no debconf information
Bug#869029: simutrans: Simutrans has no sound
Control: tags -1 pending On Thu, 20 Jul 2017 08:54:36 +0300 Julius Andrikonis wrote: > Package: simutrans > Version: 120.1.3+repack-3 > Severity: important > Tags: upstream > > Dear Maintainer, > > simutrans start with no sound. [...] I have found the root cause. The 0500-config.diff patch wrongly enabled SDL2_CONFIG instead of SDL_CONFIG. Thus the game was not compiled with MIDI sound enabled. It will take a bit longer to fix this in Stretch but I'm sure the release team will approve the update. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#868258: [V2] Patches or pull request before updating to 4.11.1
On 31 July 2017 at 22:11, Nicholas D Steeves wrote: > Hi Dimitri, > > Thank you for taking a look at these. > > On Mon, Jul 31, 2017 at 04:03:36PM +0100, Dimitri John Ledkov wrote: >> On 14 July 2017 at 00:59, Nicholas D Steeves wrote: >> > M 0002-Ignore-.pc-the-quilt-state-tracking-dir.patch >> > * I read that this is supposed to be standard in dgit repos >> >> True, but upstream tarball ships .gitignore, and i'd rather not patch >> upstream .gitignore =/ >> I personally have a global ignore setup on my machine to ignore .pc, >> or e.g. you can use local per-repository ignore. >> So i'm not taking this for now. > > In that case, lets submit the patch upstream? I'd be happy to, if > you're busy, and I'm reasonably confident it would be accepted because > Debian/Ubuntu are serious distributions and it doesn't break anything > for anyone else. > possibly. >> > N 0004-Move-all-binaries-back-to-sbin-Closes-786893.patch >> > * Completely up to you, of course ;-) >> >> H.. maybe i should give up on this one and apply it. > > Please consider it :-) If/when Debian/Ubuntu moves to /usrmerge by > default, then it will be confusing to have mkfs and admin tools in > /usr/bin rather than /usr/sbin. At some point in the future I'm sure > there will a tool that is limited to a subset of 'btrfs' that insures > users don't do unsafe things, and that tool will go in /usr/bin. IIRC > Ubuntu has /sbin and /usr/sbin for all sudoers, and Debian users who > complain can be referred to the traditional > PATH="$PATH:/sbin:/usr/sbin" > > That said, thank you for your work on finding and challenging > arbitrary restrictions in initramfs and other parts of Debian. > Smooth flattery. >> > I 0006-Exclude-non-free-RFC-BCP78-files-affects-test-suite.patch >> >> The code from RFC 6234 is under Simplified BSD License see sha.h. How >> is this non-free / what am I missing that you have spotted? > > I took a look at this again, and tests/sha224-256.c is the only > non-free file. I've pushed a fixup to my proposed branch, and have > also attached it as a patch. 5f1d55d is a fixup for 9e41daf. As is > customary, I'll leave it to you to rebase/autosquash fixup before > pushing. > > As I read it the licensing is a combination of Simplified BSD plus BCP > 78 restrictions. The following article mentions two problems with BCP > 78: > > Problem #1: No Rights To Adapt Parts Of Contributions > Problem #2: No Rights Are Granted To Third Parties > https://josefsson.org/bcp78broken/ > As i read it is this. The whole RFC is subject to BCP 79, which states that a subset of the document - the code component, is only subject to BSD license as long as both the BSD license and the IETF copyright is included. The whole text of RFC does not follow the copyright, only the the code component which is only under the bsd as documented in the sha.h. > Also there's the lintian Error: license-problem-non-free-RFC-BCP78... > If you're certain that it's a false positive then you can probably > override it. I hope it's a false positive, because upstream finally > made the test suite actually work! Sadly, I think the error is > legitimate... > I will check the tag, but it does seem like a false positive to me. I will check if I can consult somebody about this. >> > I 0008-Add-dversionmangle-to-handle-dfsg-version-suffix.patch >> >> On hold, until 0006 is discussed. >> >> > N 0011-debian-watch-Switch-to-version-4-and-add-repacksuffi.patch >> >> Simply updated to v4 without any other changes due to 0006. > > If you agree, please take a look at these. > >> > N 0012-Drop-btrfs-tools-transitional-dummy-package.patch >> > * Can be safely dropped now, because Stretch was released with >> > the transitional package >> >> https://launchpad.net/ubuntu/+source/btrfs-progs >> >> But not yet Ubuntu 18.04 LTS. So 16.04 LTS was still with btrfs-tools, >> thus ideally I would want to drop this transitional package in May >> 2018, after 18.04 LTS has been released. Is that ok? > > Agreed, we shouldn't break downstreams. I suspect waiting until after > the last Debian->Ubuntu sync for 18.04 rather than release would be > best, because Debian will probably be in some state of freeze at that > time. I don't think is is possible to drop a dummy package during > deep freeze, but I could be wrong. > That's probably doable. Or e.g. have the dbg package as a delta in ubuntu temporarliy. >> > N 0013-Switch-to-debhelper-10-and-automatically-generated-d.patch >> > * No time like the present, right? :-) >> >> Ack, with dropping btrfs-tools-dbg transitional package, because nobody >> cares =) > > Haha, indeed! Ubuntu 18.04 will install btrfs-progs-dbgsym for anyone > who needs it. > >> > N 0014-Update-changelog.patch >> > * Please delete entries for patches you reject >> > >> >> Instead of this, I simply used $ gbp dch to generate the changelog >> entries from the git commit messages and thus matches what has been >> applied. They are not as p
Bug#870310: glib-mkenums: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: ordinal not in range(128)
Am 01.08.2017 um 00:34 schrieb Adrian Bunk: > Control: tags -1 - moreinfo > > On Tue, Aug 01, 2017 at 12:03:31AM +0200, Michael Biebl wrote: >> Control: tags -1 + moreinfo >> >> Am 31.07.2017 um 23:04 schrieb Adrian Bunk: >>> File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode >>> return codecs.ascii_decode(input, self.errors)[0] >>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: >>> ordinal not in range(128) >>> Found cached translation database >>> Merging translations into gthumb.desktop. >>> Makefile:963: recipe for target 'org.gnome.gthumb.enums.xml' failed >>> make[4]: *** [org.gnome.gthumb.enums.xml] Error 1 >> >> Are you using a non-UTF-8 locale > > Works with LANG=C.UTF-8 and FTBFS with LANG=C > >> and are you processing data containing >> unicode characters? > > Yes, some files in gthumb are using the UTF-8 copyright symbol. Not sure what glib-mkenums is supposed to do about this then. It's the package/build environment not using a UTF-8 locale and Python 3 being picky about that. Making glib-mkenums forcefully set a specific locale doesn't look like a solution to me. -- 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#870310: glib-mkenums: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: ordinal not in range(128)
Control: tags -1 - moreinfo On Tue, Aug 01, 2017 at 12:03:31AM +0200, Michael Biebl wrote: > Control: tags -1 + moreinfo > > Am 31.07.2017 um 23:04 schrieb Adrian Bunk: > > File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode > > return codecs.ascii_decode(input, self.errors)[0] > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: > > ordinal not in range(128) > > Found cached translation database > > Merging translations into gthumb.desktop. > > Makefile:963: recipe for target 'org.gnome.gthumb.enums.xml' failed > > make[4]: *** [org.gnome.gthumb.enums.xml] Error 1 > > Are you using a non-UTF-8 locale Works with LANG=C.UTF-8 and FTBFS with LANG=C > and are you processing data containing > unicode characters? Yes, some files in gthumb are using the UTF-8 copyright symbol. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#870317: dash: "type" doesn't threat "--" specially (POSIX compliance issue)
Package: dash Version: 0.5.8-2.4 Severity: normal Tags: upstream dash$ type -- ls --: not found ls is /bin/ls "type" doesn't threat "--" specially. But POSIX 2016 edition says it should. Also, all your builtins mentioned in POSIX (be it "special built-in utility" or normal utility) should threat "--" specially. Unless it is in this list: --begin of list-- break : continue . eval exec exit return shift times echo test [ --end of list-- -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dash depends on: ii debianutils 4.8.1.1 ii dpkg 1.18.24 ii libc62.24-11+deb9u1 dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: true
Bug#870025: qemu: Please switch to SDL2
Hi Michael, 2017-07-31 12:04 GMT+02:00 Michael Tokarev : > 29.07.2017 01:48, Manuel A. Fernandez Montecelo wrote: >> Package: qemu-system-x86 >> Version: 1:2.8+dfsg-6 >> Severity: wishlist >> >> Hi! >> >> According to [1], it seems that since version 2.4 in 2015 this project >> supports >> both SDL1.2 and SDL2, and since the recent 2.10 [2] it prefers SDL2 if both >> are >> available. > > I tried switching to SDL2 but it turned out the support was incomplete, like > some functional keys (like resizing the guest display) didn't work in SLD2 but > worked in SDL1. > > Now with availability of GTK frontend we'll either switch to that or, better > yet, try to make display modular (a very frequently asked feature is to be > able to install a "headless" qemu without graphics libs), again, with GTK > being > the default. Right, better to have a Qemu using an old version of SDL than a faulty one! My most sincere thanks for the effort and the quick reply. -- Manuel A. Fernandez Montecelo
Bug#870316: sawfish-merlin-ugliness: almost completely broken after upgrade to stretch
Package: sawfish-merlin-ugliness Version: 1.3.1-1 Severity: grave Tags: patch Dear Maintainer, I recently upgraded from jessie to stretch. I found that nearly all customisations from sawfish-merlin-ugliness are missing from the configurator, and settings made before the upgrade have no effect. Customisations uglicon-ignore-hints and uglicon-search-filesystem are present in the configurator (Appearance->Window icons), but cannot be changed from their default values. The error log includes these errors: [2017-07-31 22:11:39] Unbound variable: expert [2017-07-31 22:11:39] Unbound variable: uglicon-reset [2017-07-31 22:11:39] Unbound variable: uglicon-reset [2017-07-31 22:11:39] Unbound variable: expert I think this is related to uglicon.jl's use of the defcustom :user-level key, which was already deprecated, and has been removed in the new version of sawfish. (I think that actually happened a long time ago upstream.) I assume this causes the loading of merlin.uglicon in ugliness.jl to fail, losing that file's functionality too. The attached patch seems to fix it. Tim Bagot -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sawfish-merlin-ugliness depends on: ii sawfish 1:1.11.90-1+b1 sawfish-merlin-ugliness recommends no packages. sawfish-merlin-ugliness suggests no packages. -- no debconf information --- uglicon.jl +++ uglicon.jl @@ -66,7 +66,6 @@ "Path to search for icons." :tooltip "Colon separated paths." :type string -:user-level expert :group (appearance uglicon) :depends uglicon-search-filesystem :after-set (lambda () (uglicon-reset))) @@ -75,7 +74,6 @@ "Icon prefixes to look for." :tooltip "Comma separated prefixes." :type string -:user-level expert :group (appearance uglicon) :depends uglicon-search-filesystem :after-set (lambda () (uglicon-reset))) @@ -84,7 +82,6 @@ "Icon suffixes to look for." :tooltip "Comma separated suffixes." :type string -:user-level expert :group (appearance uglicon) :depends uglicon-search-filesystem :after-set (lambda () (uglicon-reset))) @@ -93,14 +90,12 @@ "Maximum width of window icons." :type number :range (1 . 128) -:user-level expert :group (appearance uglicon)) (defcustom uglicon-height 48 "Maximum height of window icons." :type number :range (1 . 128) -:user-level expert :group (appearance uglicon)) (define-match-window-property 'window-icon 'appearance 'file)
Bug#870301: systemd: Touchpad fix Dell Inspiron Mini 1012
Hi Am 31.07.2017 um 21:25 schrieb b17: > Package: systemd > Version: 232-25+deb9u1 > Severity: wishlist > Tags: upstream patch > > Dear Maintainer, > > Here's a little fix for the touchpad. > It would be great if you can file this issue upstream at https://github.com/systemd/systemd/issues Such a change really belongs into upstream and should not be added as a downstream patch. 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#870315: nmu: libwx-perl_1:0.9932-1+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libwx-perl_1:0.9932-1+b1 . ANY . unstable . -m "Rebuild against rebuilt libalien-wxwidgets-perl." After a new upstream upload of wxwidgets3.0, libalien-wxwidgets-perl needs a binnmu because it generates a "Provides" based on the wxwidgets3.0 version e.g.: Provides: wxperl-gtk2-3-0-3-uni-gcc-3-4 That's already been done, but now libwx-perl needs a rebuilt so this change is reflected in its "Depends", which currently doesn't match: Depends: [...], wxperl-gtk2-3-0-2-uni-gcc-3-4, [...] Cheers, Olly
Bug#557765: libfishsound1-dev: The -dev package should be named libfishsound-dev
So, perhaps now is a good time to rename the -dev package? What do the rest of you think? Any of you have time to follow up the migration process? I doubt I will any time soon. :( -- Happy hacking Petter Reinholdtsen
Bug#870310: glib-mkenums: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: ordinal not in range(128)
Control: tags -1 + moreinfo Am 31.07.2017 um 23:04 schrieb Adrian Bunk: > File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode > return codecs.ascii_decode(input, self.errors)[0] > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: > ordinal not in range(128) > Found cached translation database > Merging translations into gthumb.desktop. > Makefile:963: recipe for target 'org.gnome.gthumb.enums.xml' failed > make[4]: *** [org.gnome.gthumb.enums.xml] Error 1 Are you using a non-UTF-8 locale and are you processing data containing unicode characters? -- 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#870314: Does not properly clean up /usr/share/meson/mesonbuild/ on purge
Package: meson Version: 0.41.2-2 Severity: important Hi, when purging the meson package, the following files are not removed properly: /usr/share/meson/mesonbuild/wrap/__pycache__/wrap.cpython-35.pyc /usr/share/meson/mesonbuild/wrap/__pycache__/__init__.cpython-35.pyc /usr/share/meson/mesonbuild/modules/__pycache__/i18n.cpython-35.pyc /usr/share/meson/mesonbuild/modules/__pycache__/__init__.cpython-35.pyc /usr/share/meson/mesonbuild/modules/__pycache__/pkgconfig.cpython-35.pyc /usr/share/meson/mesonbuild/backend/__pycache__/backends.cpython-35.pyc /usr/share/meson/mesonbuild/backend/__pycache__/ninjabackend.cpython-35.pyc /usr/share/meson/mesonbuild/backend/__pycache__/__init__.cpython-35.pyc /usr/share/meson/mesonbuild/scripts/__pycache__/meson_exe.cpython-35.pyc /usr/share/meson/mesonbuild/scripts/__pycache__/symbolextractor.cpython-35.pyc /usr/share/meson/mesonbuild/scripts/__pycache__/__init__.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/mparser.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/mesonlib.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/dependencies.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/interpreter.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/coredata.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/optinterpreter.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/mlog.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/build.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/__init__.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/mesonmain.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/environment.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/compilers.cpython-35.pyc /usr/share/meson/mesonbuild/__pycache__/interpreterbase.cpython-35.pyc It looks like meson does not use the debian python helpers to properly register and unregister the py files on installationa/uninstallation. Regards, Michael [1] https://www.debian.org/doc/packaging-manuals/python-policy/ -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages meson depends on: ii ninja-build 1.7.2-3 ii python3 3.5.3-3 meson recommends no packages. meson suggests no packages. -- no debconf information
Bug#869924: irqbalance: would it be reasonable to make irqbalance Multi-Arch:foreign ?
Disclaimer: I'm not (this or any package) maintainer, TMMV. There are a number of architecture-dependent #ifdef's in the code (AARCH64 in 1.1.0, __i386__ || __amd64__ in git master), so I think that running foreign-arch irqbalance can be unsafe (well, I guess only practical case when someone would want to run foreign-arch irqbalance is amd64/i386/x32, and /this/ combination seems not affected; unfortunately, as there are no way "partially enable m-a foreign on subset of architectures", it is still no go).
Bug#870313: openjdk-8-jre-headless: org.classpath.icedtea.pulseaudio.PulseAudioClip#close hangs forver (probably a deadlock)
Package: openjdk-8-jre-headless Version: 8u141-b15-1~deb9u1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? The game https://github.com/odoepner/bagh-chal hangs right after playing the first sound. It works fine with Oracle Java 8 and Zulu Java 8. * What exactly did you do (or not do) that was effective (or ineffective)? - Download the jar (https://bintray.com/artifact/download/odoepner/generic/bagh-chal.jar). - Run it using jav -jar bagh-chal.jar - Drag and drop one of the goat pieces onto the game board. * What was the outcome of this action? The game becomes unresponsive. A thread dump shows that it hangs in PulseAudioClip#close. I will attch the thread dump to this bug if possible. * What outcome did you expect instead? The computer player to move one of the tigers and dragging of goats be possible again. *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20170531+nmu1 ii java-common 0.58 ii libc6 2.24-11+deb9u1 ii libcups2 2.2.1-8 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18 ii libjpeg62-turbo 1:1.5.1-2 ii liblcms2-22.8-4 ii libnss3 2:3.26.2-1.1 ii libpcsclite1 1.8.20-1 ii libstdc++66.3.0-18 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi62:1.7.9-1 ii libxrender1 1:0.9.10-1 ii libxtst6 2:1.2.3-1 ii multiarch-support 2.24-11+deb9u1 ii util-linux2.29.2-1 ii zlib1g1:1.2.8.dfsg-5 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra2.37-1 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei pn fonts-wqy-zenhei ii libnss-mdns 0.10-8 -- no debconf information 2017-07-31 18:39:37 Full thread dump OpenJDK 64-Bit Server VM (25.141-b15 mixed mode): "TimerQueue" #23 daemon prio=5 os_prio=0 tid=0x7fae7cb17000 nid=0x20f9 waiting on condition [0x7fae69c34000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xefb4f928> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.DelayQueue.take(DelayQueue.java:211) at javax.swing.TimerQueue.run(TimerQueue.java:174) at java.lang.Thread.run(Thread.java:748) "Thread-3" #20 prio=6 os_prio=0 tid=0x7fae7cb3f000 nid=0x20f6 waiting for monitor entry [0x7fae6bc26000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xefe6c240> (a java.lang.Object) at java.lang.Object.wait(Object.java:502) at org.classpath.icedtea.pulseaudio.Operation.waitForCompletion(Operation.java:153) - locked <0xefe6c240> (a java.lang.Object) at org.classpath.icedtea.pulseaudio.PulseAudioClip$ClipThread.run(PulseAudioClip.java:130) "PulseAudio Eventloop Thread" #19 daemon prio=6 os_prio=0 tid=0x7fae7c46c000 nid=0x20f5 in Object.wait() [0x7fae6bd26000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xefecd638> (a org.classpath.icedtea.pulseaudio.PulseAudioClip$ClipThread) at java.lang.Thread.join(Thread.java:1252) - locked <0xefecd638> (a org.classpath.icedtea.pulseaudio.PulseAudioClip$ClipThread) at java.lang.Thread.join(Thread.java:1326) at org.classpath.icedtea.pulseaudio.PulseAudioClip.close(PulseAudioClip.java:247) at net.doepner.baghchal.resources.AudioUrlPlayer$$Lambda$39/633734841.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) at net.doepner.baghchal.resources.AudioUrlPlayer.lambda$play$0(AudioUrlPlayer.java:29) at net.doepner.baghchal.resources.AudioUrlPlayer$$Lambda$38/798764151.update(Unknown Source) at org.classpath.icedtea.pulseaudio.PulseAudioLine.fireLineEvent(PulseAudioLine.java:76) at org.classpath.icedtea.pulseaudio.PulseAudioDataLine$
Bug#867316: O: awesome -- highly configurable X window manager
Hello. The attached archive gathers available or trivial patches. It should be easyer to "git am" from the bug log than separate patches. Before that, upstream 4.2 should be imported and merged. The upstream branch seems to track *every* upstream commit, but differs from the history visible on github. Julien, could you explain your workflow? We could then describe it in README.source for potential adopters. Thanks. awesome-4.0to4.2.tar.gz Description: application/gzip
Bug#870090: Pending fixes for bugs in the libpdl-graphics-gnuplot-perl package
tag 870090 + pending thanks Some bugs in the libpdl-graphics-gnuplot-perl package are closed in revision b9279b2e9a67ea7cf9cefa164bd109c796baf401 in branch 'master' by Bas Couwenberg The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libpdl-graphics-gnuplot-perl.git/commit/?id=b9279b2 Commit message: Require at least libalien-gnuplot-perl 1.031. (closes: #870090)
Bug#869356: ghc: Eats gigabytes of memory when compiling haskell-skylighting
Quoting Samuel Thibault (2017-07-22 11:45:22) > As https://buildd.debian.org/status/package.php?p=haskell-skylighting > shows, haskell-skylighting fails to build on a lot of architectures, > from getting out of memory. I have indeed observed the RSS to be going > very high during the build, more than a Gigabyte... The version of skylighting in unstable is 0.1.1.5. https://github.com/jgm/skylighting/blob/master/changelog.md has this in its section for release 0.2: > Skylighting.Syntax.*: use string representation of the Syntax, which > is then 'read', rather than including the code for the data structure > directly (#7). This indirect method produces faster compile times and > avoids massive memory usage by ghc (especially in profiling builds). > For background see > http://stackoverflow.com/questions/16348340/compiling-very-large-constants-with-ghc Skylighting is now at version 0.3.3.1. Can we please have a newer release of Skylighting in Debian? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#868973: kxd: FTBFS: Test failures
On Wed, Jul 19, 2017 at 10:26:20PM +0200, Lucas Nussbaum wrote: > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. Thanks for the report! I think this is something that has been fixed since 0.12, and updating to a newer version should solve it. I'm talking with Maxy about doing this, so hopefully this will be fixed before 17/August (the autoremoval deadline). Alberto
Bug#870312: flatpak FTBFS on amd64/arm64: ERROR: testlibrary - missing test plan
Source: flatpak Version: 0.8.7-4 Severity: serious Some recent change in unstable makes flatpak FTBFS on amd64/arm64: https://tests.reproducible-builds.org/debian/history/flatpak.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/flatpak.html ... ERROR: testlibrary - missing test plan ERROR: testlibrary - exited with status 134 (terminated by signal 6?) = Flatpak 0.8.7: ./test-suite.log = # TOTAL: 20 # PASS: 6 # SKIP: 12 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 2 .. contents:: :depth: 2 SKIP: test-doc-portal = # random seed: R02S2d187e435d4aa4fb68938109e0122c30 1..2 # Start of db tests ok 1 /db/create_doc # SKIP this test requires FUSE SKIP: test-doc-portal 1 /db/create_doc # SKIP this test requires FUSE ok 2 /db/recursive_doc # SKIP this test requires FUSE SKIP: test-doc-portal 2 /db/recursive_doc # SKIP this test requires FUSE # End of db tests ERROR: testlibrary == ** flatpak:ERROR:tests/testlibrary.c:668:add_remote: assertion failed (status == 0): (256 == 0) ./buildutil/tap-test: line 23: 59830 Aborted ${srcd}/${bn} -k --tap # random seed: R02Sbf4ab0218f9346d8617da03c0d7234c9 # flatpak:ERROR:tests/testlibrary.c:668:add_remote: assertion failed (status == 0): (256 == 0) ERROR: testlibrary - missing test plan ERROR: testlibrary - exited with status 134 (terminated by signal 6?) ...
Bug#870073: [Pkg-mozext-maintainers] Bug#870073: enigmail: Does not encrypt and gives alerts after upgrade to Thunderbird 52
Control: tags 870073 + moreinfo unreproducible Hi Paul-- I have a jessie system with the exact same versions of the software described here, and i'm not seeing this behavior. Can you help me to replicate it? On Sat 2017-07-29 15:20:33 +0200, Paul van der Vlis wrote: > > When I read an encrypted message in Thunderbird, I get this warning: > -- > Enigmail Alert: > GnuPG reported an error in the communication with gpg-agent (a component of > GnuPG). > This is a system setup or configuration error that prevents Enigmail from > working properly and cannot be fixed automatically. > We strongly recommend that you consult our support web site at > https://enigmail.net/faq. > -- > After this, the message is decrypted. I haven't seen this message at all. are you certain that gpg-agent is running? Do you ever see a dialog box that prompts you for your gpg password? Can you try adding "use-agent" to your ~/.gnupg/gpg.conf and then logging out and logging back in again? As a workaround, please also try closing thunderbird and then re-launching it with the following command: gpg-agent --daemon thunderbird Does that cause the error message to go away? > But when I sent a message to somebody with a PGP key in my keyring, > the message is normally encrypted. But not now, and I do not get a > warning about that. If you open up the "Enigmail" menu (from the "hamburger" menu on the right-hand of the toolbar), and choose "Preferences", and then click "Display Expert Settings and Menus", then you'll have more debugging options visible to you. once you've got that checked, the "Enigmail" menu should have "Debugging Options" which shows "View Console" and "View Log". can you send some details from those to this bug report, if they seem safe to publish? (if they do not seem safe to publish, or you are unsure, but you're OK sharing them with me, you can encrypt them with key 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 and e-mail them to me privately). I'd also be interested in knowing if you have this problem on a debian stretch system (the current version of debian stable). hopefully we can get to the bottom of this! thanks for persevering, --dkg signature.asc Description: PGP signature
Bug#869926: RFS: oprofile/1.2.0-1 [ITP]
Thanks for reviewing it Andrey! I tried to apply your suggestions in the package and also made some other improvements. Hope it looks better now.
Bug#870311: gitano FTBFS with git 2.13
Source: gitano Version: 1.0-2 Severity: serious Tags: buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gitano.html ... Failed scenarios: - Verification of basic behaviour - using bypass warns loudly - server-side clone failure modes - user-created repositories - repository destruction failure modes - repository destruction - graveyard - Performing git-archive operations - rename permissions - Pushing shallow history ERROR: Test suite FAILED in 10 scenarios Makefile:218: recipe for target 'sshtests' failed make[1]: *** [sshtests] Error 1 make[1]: Leaving directory '/build/1st/gitano-1.0' dh_auto_test: make -j1 test returned exit code 2 debian/rules:12: recipe for target 'build' failed make: *** [build] Error 2
Bug#868258: P.S. Re: Bug#868258: [V2] Patches or pull request before updating to 4.11.1
P.S. If you have the time, could you please take a look at the Policy 4.0.0 checklist and update Standards-Version for the 4.12 upload? Thanks! Nicholas signature.asc Description: PGP signature
Bug#870213: pajeng FTBFS with perl 5.26
Control: tag -1 + patch On Mon, 31 Jul 2017 03:14:40 +0300, Adrian Bunk wrote: > Start 12: pj_validate_simu-mardi > 1/12 Test #4: pj_dump_native_paje ..***Failed0.10 sec > Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in > m/\${ <-- HERE (\w+)(?::[=-][^}]*)?}/ at > /build/1st/pajeng-1.3.4/obj-x86_64-linux-gnu/bin/tesh line 235. Here's a patch that escapes the curlies. Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- diff -Nru pajeng-1.3.4/debian/changelog pajeng-1.3.4/debian/changelog --- pajeng-1.3.4/debian/changelog 2016-12-01 03:10:15.0 -0500 +++ pajeng-1.3.4/debian/changelog 2017-07-31 17:05:06.0 -0400 @@ -1,3 +1,12 @@ +pajeng (1.3.4-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix "pajeng FTBFS with perl 5.26": +add a patch to escape the literal left braces in regexps. +(Closes: #870213) + + -- gregor herrmann Mon, 31 Jul 2017 17:05:06 -0400 + pajeng (1.3.4-2) unstable; urgency=medium * Add libfl-dev to the Build-deps (Closes: #846446). diff -Nru pajeng-1.3.4/debian/patches/perl-5.26 pajeng-1.3.4/debian/patches/perl-5.26 --- pajeng-1.3.4/debian/patches/perl-5.26 1969-12-31 19:00:00.0 -0500 +++ pajeng-1.3.4/debian/patches/perl-5.26 2017-07-31 17:05:06.0 -0400 @@ -0,0 +1,34 @@ +Description: Fix "Unescaped left brace in regex is illegal here" errors with perl 5.26 +Origin: vendor +Bug: https://github.com/schnorr/pajeng/issues/24 +Bug-Debian: https://bugs.debian.org/870213 +Author: gregor herrmann +Last-Update: 2017-07-31 + +--- a/tests/scripts/tesh b/tests/scripts/tesh +@@ -60,12 +60,12 @@ + sub var_subst { + my ($text, $name, $value) = @_; + if ($value) { +-$text =~ s/\${$name(?::[=-][^}]*)?}/$value/g; ++$text =~ s/\$\{$name(?::[=-][^}]*)?}/$value/g; + $text =~ s/\$$name(\W|$)/$value$1/g; + } + else { +-$text =~ s/\${$name:=([^}]*)}/$1/g; +-$text =~ s/\${$name}//g; ++$text =~ s/\$\{$name:=([^}]*)}/$1/g; ++$text =~ s/\$\{$name}//g; + $text =~ s/\$$name(\W|$)/$1/g; + } + return $text; +@@ -232,7 +232,7 @@ + $cmd{'cmd'} = var_subst($cmd{'cmd'}, $key, $environ{$key}); + } + # substitute remaining variables, if any +- while ($cmd{'cmd'} =~ /\${(\w+)(?::[=-][^}]*)?}/) { ++ while ($cmd{'cmd'} =~ /\$\{(\w+)(?::[=-][^}]*)?}/) { + $cmd{'cmd'} = var_subst($cmd{'cmd'}, $1, ""); + } + while ($cmd{'cmd'} =~ /\$(\w+)/) { diff -Nru pajeng-1.3.4/debian/patches/series pajeng-1.3.4/debian/patches/series --- pajeng-1.3.4/debian/patches/series 2016-12-01 03:10:15.0 -0500 +++ pajeng-1.3.4/debian/patches/series 2017-07-31 17:05:06.0 -0400 @@ -1,2 +1,3 @@ # drop_dependencies soname +perl-5.26 signature.asc Description: Digital Signature
Bug#868258: [V2] Patches or pull request before updating to 4.11.1
Hi Dimitri, Thank you for taking a look at these. On Mon, Jul 31, 2017 at 04:03:36PM +0100, Dimitri John Ledkov wrote: > On 14 July 2017 at 00:59, Nicholas D Steeves wrote: > > M 0002-Ignore-.pc-the-quilt-state-tracking-dir.patch > > * I read that this is supposed to be standard in dgit repos > > True, but upstream tarball ships .gitignore, and i'd rather not patch > upstream .gitignore =/ > I personally have a global ignore setup on my machine to ignore .pc, > or e.g. you can use local per-repository ignore. > So i'm not taking this for now. In that case, lets submit the patch upstream? I'd be happy to, if you're busy, and I'm reasonably confident it would be accepted because Debian/Ubuntu are serious distributions and it doesn't break anything for anyone else. > > N 0004-Move-all-binaries-back-to-sbin-Closes-786893.patch > > * Completely up to you, of course ;-) > > H.. maybe i should give up on this one and apply it. Please consider it :-) If/when Debian/Ubuntu moves to /usrmerge by default, then it will be confusing to have mkfs and admin tools in /usr/bin rather than /usr/sbin. At some point in the future I'm sure there will a tool that is limited to a subset of 'btrfs' that insures users don't do unsafe things, and that tool will go in /usr/bin. IIRC Ubuntu has /sbin and /usr/sbin for all sudoers, and Debian users who complain can be referred to the traditional PATH="$PATH:/sbin:/usr/sbin" That said, thank you for your work on finding and challenging arbitrary restrictions in initramfs and other parts of Debian. > > I 0006-Exclude-non-free-RFC-BCP78-files-affects-test-suite.patch > > The code from RFC 6234 is under Simplified BSD License see sha.h. How > is this non-free / what am I missing that you have spotted? I took a look at this again, and tests/sha224-256.c is the only non-free file. I've pushed a fixup to my proposed branch, and have also attached it as a patch. 5f1d55d is a fixup for 9e41daf. As is customary, I'll leave it to you to rebase/autosquash fixup before pushing. As I read it the licensing is a combination of Simplified BSD plus BCP 78 restrictions. The following article mentions two problems with BCP 78: Problem #1: No Rights To Adapt Parts Of Contributions Problem #2: No Rights Are Granted To Third Parties https://josefsson.org/bcp78broken/ Also there's the lintian Error: license-problem-non-free-RFC-BCP78... If you're certain that it's a false positive then you can probably override it. I hope it's a false positive, because upstream finally made the test suite actually work! Sadly, I think the error is legitimate... > > I 0008-Add-dversionmangle-to-handle-dfsg-version-suffix.patch > > On hold, until 0006 is discussed. > > > N 0011-debian-watch-Switch-to-version-4-and-add-repacksuffi.patch > > Simply updated to v4 without any other changes due to 0006. If you agree, please take a look at these. > > N 0012-Drop-btrfs-tools-transitional-dummy-package.patch > > * Can be safely dropped now, because Stretch was released with > > the transitional package > > https://launchpad.net/ubuntu/+source/btrfs-progs > > But not yet Ubuntu 18.04 LTS. So 16.04 LTS was still with btrfs-tools, > thus ideally I would want to drop this transitional package in May > 2018, after 18.04 LTS has been released. Is that ok? Agreed, we shouldn't break downstreams. I suspect waiting until after the last Debian->Ubuntu sync for 18.04 rather than release would be best, because Debian will probably be in some state of freeze at that time. I don't think is is possible to drop a dummy package during deep freeze, but I could be wrong. > > N 0013-Switch-to-debhelper-10-and-automatically-generated-d.patch > > * No time like the present, right? :-) > > Ack, with dropping btrfs-tools-dbg transitional package, because nobody cares > =) Haha, indeed! Ubuntu 18.04 will install btrfs-progs-dbgsym for anyone who needs it. > > N 0014-Update-changelog.patch > > * Please delete entries for patches you reject > > > > Instead of this, I simply used $ gbp dch to generate the changelog > entries from the git commit messages and thus matches what has been > applied. They are not as pretty, but I hope that is ok. Sean Whitton likes very detailed and pretty changelogs, which is why I took care to write a nice one, but honestly that's fine with me. I'll configure my editor to hard-wrap lines for any future patches. Would you please take care to reflow those long lines in the current changelog when you're ready to release? The lintian Warning debian-changelog-line-too-long occurs without this. Cheers, Nicholas From 5f1d55d60a77afb4d66b025cb84509f45f646c78 Mon Sep 17 00:00:00 2001 From: Nicholas D Steeves Date: Mon, 31 Jul 2017 15:56:26 -0400 Subject: [PATCH] fixup! Exclude non-free-RFC-BCP78 files (affects test suite) --- debian/copyright | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/copyright b/debian/copyright index 91b885
Bug#870310: glib-mkenums: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: ordinal not in range(128)
Package: libglib2.0-dev-bin Version: 2.53.4-2 Severity: grave Control: affects -1 src:gthumb https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/gtk2-engines-xfce.html https://buildd.debian.org/status/package.php?p=gthumb&suite=sid ... Found cached translation database Merging translations into gthumb-import.desktop. Traceback (most recent call last): File "/usr/bin/glib-mkenums", line 669, in process_file(fname) File "/usr/bin/glib-mkenums", line 406, in process_file line = curfile.readline() File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: ordinal not in range(128) Found cached translation database Merging translations into gthumb.desktop. Makefile:963: recipe for target 'org.gnome.gthumb.enums.xml' failed make[4]: *** [org.gnome.gthumb.enums.xml] Error 1
Bug#870135: radeontop: does not report vram usage with amdgpu driver
Hi Ole! On 07/30/2017 12:59 PM, Ole Harth wrote: > yes, I can confirm this fixes the problem Can you please test the updated package I uploaded in [1]? Adrian > [1] https://people.debian.org/~glaubitz/radeontop/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#867081: autopkgtest: @ no longer pulls in packages with versioned Provides
On Mon, Jul 03, 2017 at 10:40:45PM +0300, Niko Tyni wrote: > Package: autopkgtest > Version: 4.4 > User: debian-p...@lists.debian.org > Usertags: versioned-provides > X-Debbugs-Cc: debian-p...@lists.debian.org > > As seen on ci.debian.net with for instance libhttp-tiny-perl and > libcpan-meta-perl, autopkgtest gets confused about versioned Provides > that were introduced in sid recently with perl_5.24.1-5. > > It looks like "Depends: @" will no longer pull in the binary packages > to be tested if the same name is also Provided by installed packages > with a version. > > My reading of the autopkgtest code is that it synthesizes a dependency > on 'package (>= 0~)', where the versioning is assumed to guarantee that > only a real package gets pulled in. This assumption no longer holds with > versioned Provides. Oh, I'd mostly forgotten about #761003 which introduced the '(>= 0~)' thing three years ago and where we predicted that this will break with versioned Provides. The solution we discussed there was to insert an additional explicit apt-get install phase to the autopkgtest-satdep.deb installation (which unpacks a temporary package and then calls 'apt-get --fix-missing' to have apt solve the dependencies.) This explicit call prefers real packages to virtual ones (at least in all my tests though I can't find this documented; possibly this should be checked with the apt maintainers.) Is this approach something you would consider now that the versioned Provides issue has materialized in practice? -- Niko Tyni nt...@debian.org
Bug#869884: chemical-mime-data: diff for NMU version 0.1.94-6.1
Control: tags 869884 + pending Dear maintainer, I've prepared an NMU for chemical-mime-data (versioned as 0.1.94-6.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- diff -Nru chemical-mime-data-0.1.94/debian/changelog chemical-mime-data-0.1.94/debian/changelog --- chemical-mime-data-0.1.94/debian/changelog 2012-02-26 14:30:20.0 -0500 +++ chemical-mime-data-0.1.94/debian/changelog 2017-07-31 16:48:01.0 -0400 @@ -1,3 +1,13 @@ +chemical-mime-data (0.1.94-6.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix "Local copy of intltool-* fails with perl 5.26": +Add patch 869884_perl-5.26.patch to fix errors caused by unescaped left +braces in embedded intltool-update copy. +(Closes: #869884) + + -- gregor herrmann Mon, 31 Jul 2017 16:48:01 -0400 + chemical-mime-data (0.1.94-6) unstable; urgency=low * debian/rules (override_dh_auto_configure): Set RSVG to point to the path diff -Nru chemical-mime-data-0.1.94/debian/patches/869884_perl-5.26.patch chemical-mime-data-0.1.94/debian/patches/869884_perl-5.26.patch --- chemical-mime-data-0.1.94/debian/patches/869884_perl-5.26.patch 1969-12-31 19:00:00.0 -0500 +++ chemical-mime-data-0.1.94/debian/patches/869884_perl-5.26.patch 2017-07-27 21:57:23.0 -0400 @@ -0,0 +1,55 @@ +Description: Fix "Unescaped left brace in regex" errors +Origin: vendor +Bug: https://bugs.debian.org/869884 +Forwarded: no +Author: gregor herrmann +Last-Update: 2017-07-27 + +--- a/intltool-update.in b/intltool-update.in +@@ -872,13 +872,13 @@ + } + } + +-if ($str =~ /^(.*)\${?([A-Z_]+)}?(.*)$/) ++if ($str =~ /^(.*)\$\{?([A-Z_]+)}?(.*)$/) + { + my $rest = $3; + my $untouched = $1; + my $sub = ""; + # Ignore recursive definitions of variables +-$sub = $varhash{$2} if defined $varhash{$2} and $varhash{$2} !~ /\${?$2}?/; ++$sub = $varhash{$2} if defined $varhash{$2} and $varhash{$2} !~ /\$\{?$2}?/; + + return SubstituteVariable ("$untouched$sub$rest"); + } +@@ -996,10 +996,10 @@ + ($name, $version) = ($1, $2); + $name=~ s/[\[\]\s]//g; + $version =~ s/[\[\]\s]//g; +- $varhash{"PACKAGE_NAME"} = $name if (not $name =~ /\${?AC_PACKAGE_NAME}?/); +- $varhash{"PACKAGE"} = $name if (not $name =~ /\${?PACKAGE}?/); +- $varhash{"PACKAGE_VERSION"} = $version if (not $name =~ /\${?AC_PACKAGE_VERSION}?/); +- $varhash{"VERSION"} = $version if (not $name =~ /\${?VERSION}?/); ++ $varhash{"PACKAGE_NAME"} = $name if (not $name =~ /\$\{?AC_PACKAGE_NAME}?/); ++ $varhash{"PACKAGE"} = $name if (not $name =~ /\$\{?PACKAGE}?/); ++ $varhash{"PACKAGE_VERSION"} = $version if (not $name =~ /\$\{?AC_PACKAGE_VERSION}?/); ++ $varhash{"VERSION"} = $version if (not $name =~ /\$\{?VERSION}?/); + } + + if ($conf_source =~ /^AC_INIT\(([^,\)]+),([^,\)]+)/m) +@@ -1007,10 +1007,10 @@ + ($name, $version) = ($1, $2); + $name=~ s/[\[\]\s]//g; + $version =~ s/[\[\]\s]//g; +- $varhash{"PACKAGE_NAME"} = $name if (not $name =~ /\${?AC_PACKAGE_NAME}?/); +- $varhash{"PACKAGE"} = $name if (not $name =~ /\${?PACKAGE}?/); +- $varhash{"PACKAGE_VERSION"} = $version if (not $name =~ /\${?AC_PACKAGE_VERSION}?/); +- $varhash{"VERSION"} = $version if (not $name =~ /\${?VERSION}?/); ++ $varhash{"PACKAGE_NAME"} = $name if (not $name =~ /\$\{?AC_PACKAGE_NAME}?/); ++ $varhash{"PACKAGE"} = $name if (not $name =~ /\$\{?PACKAGE}?/); ++ $varhash{"PACKAGE_VERSION"} = $version if (not $name =~ /\$\{?AC_PACKAGE_VERSION}?/); ++ $varhash{"VERSION"} = $version if (not $name =~ /\$\{?VERSION}?/); + } + + # \s makes this not work, why? diff -Nru chemical-mime-data-0.1.94/debian/patches/series chemical-mime-data-0.1.94/debian/patches/series --- chemical-mime-data-0.1.94/debian/patches/series 2012-02-26 14:30:01.0 -0500 +++ chemical-mime-data-0.1.94/debian/patches/series 2017-07-27 21:54:57.0 -0400 @@ -1,2 +1,3 @@ 661326_rsvg-convert.patch 652153_drop_gmd.patch +869884_perl-5.26.patch signature.asc Description: Digital Signature
Bug#870308: ruby-ridley FTBFS: test failures
Source: ruby-ridley Version: 4.4.3-2 Severity: serious Tags: buster sid Some recent change in unstable makes ruby-ridley FTBFS: https://tests.reproducible-builds.org/debian/history/ruby-ridley.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-ridley.html ... ┌──┐ │ Run tests for ruby2.3 from debian/ruby-tests.rake│ └──┘ RUBYLIB=/build/1st/ruby-ridley-4.4.3/debian/ruby-ridley/usr/lib/ruby/vendor_ruby:. GEM_PATH=debian/ruby-ridley/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all ruby2.3 -S rake -f debian/ruby-tests.rake /usr/bin/ruby2.3 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb Run options: include {:focus=>true} All examples were filtered out; ignoring {:focus=>true} ..FFF..F*...FFF..F...F.FF...FF..FF..F.FF..F..FFF..F*...WARNING: Using the `raise_error` matcher without providing a specific error or message risks false positives, since `raise_error` will match when Ruby raises a `NoMethodError`, `NameError` or `ArgumentError`, potentially allowing the expectation to pass without even executing the method you are intending to call. Actual error raised was #. Instead consider providing a specific error class or message. This message can be suppressed by setting: `RSpec::Expectations.configuration.on_potential_false_positives = :nothing`. Called from /build/1st/ruby-ridley-4.4.3/spec/unit/ridley/chef/cookbook/metadata_spec.rb:47:in `block (3 levels) in '. ...**.F.F..F.F***...**..***..*..**..*.*..F.F.F.F Pending: (Failures listed here are expected and do not affect your suite's status) 1) Client API operations deleting all clients deletes all clients from the remote # Temporarily skipped with xit # ./spec/acceptance/client_resource_spec.rb:68 2) User API operations deleting all users deletes all users from the remote # Temporarily skipped with xit # ./spec/acceptance/user_resource_spec.rb:68 3) Ridley::Chef::Cookbook::SyntaxCheck#validate_template asks #shell_out to check the files syntax # Not yet implemented # ./spec/unit/ridley/chef/cookbook/syntax_check_spec.rb:113 4) Ridley::Chef::Cookbook::SyntaxCheck#validate_ruby_file asks #shell_out to check the files syntax # Not yet implemented # ./spec/unit/ridley/chef/cookbook/syntax_check_spec.rb:117 5) Ridley::ClientObject#to_json # No reason given # ./spec/unit/ridley/chef_objects/client_object_spec.rb:5 6) Ridley::ClientObject#regenerate_key # No reason given # ./spec/unit/ridley/chef_objects/client_object_spec.rb:9 7) Ridley::SandboxObject#checksums # No reason given # ./spec/unit/ridley/chef_objects/sandbox_object_spec.rb:30 8) Ridley::Connection configurable retries attempts five (5) retries by default # Temporarily skipped with xit # ./spec/unit/ridley/connection_spec.rb:17 9) Ridley::Connection configurable retries given a configured count of two (2) retries attempts two (2) retries # Temporarily skipped with xit # ./spec/unit/ridley/connection_spec.rb:29 10) Ridley::Connection#stream creates a destination file on disk # Temporarily skipped with xit # ./spec/unit/ridley/connection_spec.rb:62 11) Ridley::Connection#stream returns true when the file was copied # Temporarily skipped with xit # ./spec/unit/ridley/connection_spec.rb:68 12) Ridley::Connection#stream contains the contents of the response body # Temporarily skipped with xit # ./spec/unit/ridley/connection_spec.rb:72 13) Ridley::Resource::delete_all sends a delete request for every object in the collection # No reason given # ./spec/unit/ridley/resource_spec.rb:137 14) Ridley::CookbookResource#update # No reason given # ./spec/unit/ridley/resources/cookbook_resource_spec.rb:151 15) Ridley::DataBagItemResource # No reason given # ./spec/unit/ridley/resources/data_bag_item_resource_spec.rb:6 16) Ridley::DataBagResource#find # No reason given # ./spec/unit/ridley/resources/data_bag_resource_spec.rb:21 17) Ridley::RoleResource # No reason given # ./spec/unit/ridley/resources/role_resource_spec.rb:6 Failures: 1) Client API operations creating a client returns a Ridley::ClientObject Failure/Error: raise Errors::HTTPError.fabricate(env) Ridley::Errors::H
Bug#870309: [checkbashisms] False positive in "sourced script with arguments"
Package: devscripts Version: 2.17.9 Severity: normal Hi, I've found a false positive in "sourced script with arguments": #!/bin/sh . "$(subcmd $arg)" . "$(subcmd "$arg")" .. results in possible bashism in test line 4 (sourced script with arguments): . "$(subcmd "$arg")" Note that the unquoted version on line 3 is not warned about. Not sure if this is due to the subshell or the implicit nested quotes.. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#870307: tinyproxy: CVE-2017-11747: Creating PID file after privileges dropping allows local DoS
Source: tinyproxy Version: 1.8.3-3 Severity: normal Tags: upstream security Forwarded: https://github.com/tinyproxy/tinyproxy/issues/106 Hi, the following vulnerability was published for tinyproxy, opeing this in the BTS for tracking purposes. CVE-2017-11747[0]: | main.c in Tinyproxy 1.8.4 and earlier creates a | /run/tinyproxy/tinyproxy.pid file after dropping privileges to a | non-root account, which might allow local users to kill arbitrary | processes by leveraging access to this non-root account for | tinyproxy.pid modification before a root script executes a "kill `cat | /run/tinyproxy/tinyproxy.pid`" command. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-11747 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11747 Regards, Salvatore
Bug#870306: ruby-dep-selector FTBFS with libgecode-dev 5.1.0-2
Source: ruby-dep-selector Version: 1.0.3-2 Severity: serious Tags: buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-dep-selector.html ... g++ -I. -I/usr/include/x86_64-linux-gnu/ruby-2.3.0 -I/usr/include/ruby-2.3.0/ruby/backward -I/usr/include/ruby-2.3.0 -I. -I/usr/include -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -O2 -fdebug-prefix-map=/build/ruby2.3-8Td9HM/ruby2.3-2.3.3=. -fstack-protector-strong -Wformat -Werror=format-security -o dep_selector_to_gecode.o -c dep_selector_to_gecode.cpp In file included from dep_selector_to_gecode.cpp:26:0: dep_selector_to_gecode.h:162:25: error: type/value mismatch at argument 1 in template parameter list for 'template class E> class Gecode::RBS' RBS solver; ^ dep_selector_to_gecode.h:162:25: note: expected a type, got 'DFS' dep_selector_to_gecode.h:162:25: error: type/value mismatch at argument 2 in template parameter list for 'template class E> class Gecode::RBS' dep_selector_to_gecode.h:162:25: note: expected a class template, got 'VersionProblem' dep_selector_to_gecode.cpp: In member function 'void VersionProblem::Finalize()': dep_selector_to_gecode.cpp:404:80: error: no matching function for call to 'branch(VersionProblem&, Gecode::BoolVarArray&, Gecode::IntVarBranch, Gecode::IntValBranch)' branch(*this, disabled_package_variables, INT_VAR_SIZE_MIN(), INT_VAL_MIN()); ^ ...
Bug#869357: libdigest-whirlpool-perl: diff for NMU version 1.09-1.1
Control: tags 869357 + pending Dear maintainer, I've prepared an NMU for libdigest-whirlpool-perl (versioned as 1.09-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- diff -u libdigest-whirlpool-perl-1.09/debian/changelog libdigest-whirlpool-perl-1.09/debian/changelog --- libdigest-whirlpool-perl-1.09/debian/changelog +++ libdigest-whirlpool-perl-1.09/debian/changelog @@ -1,3 +1,13 @@ +libdigest-whirlpool-perl (1.09-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix "libdigest-whirlpool-perl FTBFS on s390x: test failure": +cherry-pick 66405ec from upstream git: +https://github.com/avar/digest-whirlpool/commit/66405ec9ca44492a38a82c2d7fa98c291d46eef1 +(Closes: #869357) + + -- gregor herrmann Mon, 31 Jul 2017 16:32:36 -0400 + libdigest-whirlpool-perl (1.09-1) unstable; urgency=low * New upstream release. Closes: #626628. only in patch2: unchanged: --- libdigest-whirlpool-perl-1.09.orig/Whirlpool.xs +++ libdigest-whirlpool-perl-1.09/Whirlpool.xs @@ -15,7 +15,6 @@ new(SV * class) CODE: Digest__Whirlpool self; -SV * self_ref; const char * pkg; /* Figure out what class we're supposed to bless into, handle @@ -34,7 +33,6 @@ containing its memory location */ Newz(0, self, 1, struct whirlpool); NESSIEinit(&self->state); -self_ref = newRV_noinc((SV *) self); RETVAL = newSV(0); /* This gets mortalized automagically */ sv_setref_pv(RETVAL, pkg, (void*)self); signature.asc Description: Digital Signature
Bug#869601: python-afl: error in DEP-8 testing on py-afl-cmin: do not use this script in /tmp or /var/tmp
Control: retitle -1 python-afl: error in DEP-8 testing on py-afl-cmin: do not use this script in /tmp or /var/tmp This has been assigned to afl by mistake. Thanks, DS -- 4096R/DF5182C8 (sten...@debian.org) http://www.danielstender.com/
Bug#870305: RM: trackballs-music -- ROM; superseded by trackballs-data
Package: ftp.debian.org Severity: normal Hi, please remove trackballs-music from Debian because the music files are now shipped by trackballs-data. I have recently adopted trackballs [1] and Ari had no objections. Regards, Markus [1] https://bugs.debian.org/868983
Bug#870203: dune-grid FTBFS on mips: test-ug (Timeout)
Control: severity -1 important Adrian Bunk writes: > Start 31: test-ug > 31/60 Test #31: test-ug > ...***Timeout 300.02 sec Yes, saw the same issue also on PowerPC. I haven't found time to look at this yet and have asked for dune-grid and rdeps to be removed from mips and powerpc for now (#869688). I'm downgrading the bug as the removal will make this non-RC. Ansgar
Bug#870304: yabause FTBFS with buster libgtkglext1-dev
Source: yabause Version: 0.9.14-2 Severity: serious Tags: buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/yabause.html ... -- Found GTK2_GTK: /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so -- Found OpenGL and Gtk+ but not libgtkglext, skipping Gtk+ port. ... dh_install dh_install: Cannot find (any matches for) "usr/bin/yabause-gtk" (tried in ., debian/tmp) dh_install: yabause-gtk missing files: usr/bin/yabause-gtk dh_install: Cannot find (any matches for) "usr/share/applications/yabause-gtk.desktop" (tried in ., debian/tmp) dh_install: yabause-gtk missing files: usr/share/applications/yabause-gtk.desktop dh_install: Cannot find (any matches for) "usr/share/man/man1/yabause-gtk.1" (tried in ., debian/tmp) dh_install: yabause-gtk missing files: usr/share/man/man1/yabause-gtk.1 dh_install: missing files, aborting debian/rules:12: recipe for target 'binary' failed make: *** [binary] Error 25 This is caused by gdkglext-config.h changing location -/usr/lib/gtkglext-1.0/include/gdkglext-config.h +/usr/include/gtkglext-1.0/gdkglext-config.h and yabause still searching in the old location.
Bug#869758: Pending fixes for bugs in the libxml-simple-perl package
tag 869758 + pending thanks Some bugs in the libxml-simple-perl package are closed in revision 03ee016593218259e1f55a45d7bacdea72468e2f in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libxml-simple-perl.git/commit/?id=03ee016 Commit message: Declare package as "Multi-Arch: foreign". Closes: #869758
Bug#865013: network-manager-gnome: Consistent segfault when connecting to WPA2 network
Package: network-manager-gnome Version: 1.8.2-1 Followup-For: Bug #865013 Control: tags -1 - unreproducible Dear Maintainer, I think I'm seeing the same bug, since it also crashes in libnma. Relevant part of gdb: #0 0xb76b121e in modules_initialized (object=0x0, res=0x8104d8e0, user_data=0x81058178) at src/libnma/nma-cert-chooser-button.c:95 self = 0x81058178 [NMACertChooserButton] error = 0x0 modules = 0x0 iter = {stamp = -2134551640, user_data = 0x80c553c8, user_data2 = 0x1, user_data3 = 0x80f8af20} And line 95 is: 93 if (!modules) { 94 /* The Front Fell Off. */ 95 g_critical ("Error getting registered modules: %s", error->message); 96 g_error_free (error); 97 } It tries to access the 'message' field of 'error', which is null. So there is a soft-error (no modules found), which is then handled badly at some point ('error' ends up being null-but-accessed). 'error' probably should be written by 'gck_modules_initialize_registered_finish', and I have no idea why it doesn't. Steps to reproduce on my system: - run 'nm-connection-editor' - select some encrypted WLAN (in my case, a home WLAN) for which the computer doesn't have the password yet - click the 'edit' button Expected behavior: Not sure how, but it should open the configuration dialog eventually. Actual behavior: Segfault in src/libnma/nma-cert-chooser-button.c:95 Not sure if the problem is with gck or with libnma's usage of it. Cheers, Ben -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.11.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager-gnome depends on: ii dbus-x11 [dbus-session-bus] 1.10.20-1 ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2+b1 ii libatk1.0-0 2.24.0-1 ii libc62.24-12 ii libcairo21.14.10-1 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.52.3-1 ii libgtk-3-0 3.22.16-1 ii libjansson4 2.10-1 ii libmm-glib0 1.6.8-1 ii libnm0 1.8.2-1 ii libnma0 1.8.2-1 ii libnotify4 0.7.7-2 ii libpango-1.0-0 1.40.6-1 ii libpangocairo-1.0-0 1.40.6-1 ii libsecret-1-00.18.5-3.1 ii libselinux1 2.6-3+b2 ii network-manager 1.8.2-1 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-6 Versions of packages network-manager-gnome recommends: pn gnome-keyring ii iso-codes3.75-1 pn mobile-broadband-provider-info ii notification-daemon 3.20.0-1+b1 ii xfce4-notifyd [notification-daemon] 0.3.6-1 Versions of packages network-manager-gnome suggests: pn network-manager-openconnect-gnome pn network-manager-openvpn-gnome pn network-manager-pptp-gnome pn network-manager-vpnc-gnome -- no debconf information
Bug#869542: python-afl autopkgtest is broken in 0.6-1
Control: tags -1 + fixed-upstream * Steve Langasek , 2017-07-23, 21:42: CalledProcessError: Command './py-afl-cmin' returned non-zero exit status 1 [...] [-] Error: do not use this script in /tmp or /var/tmp. This is fixed upstream in 0.6.1. If you don't want to upload the new upstream release for some reason, you can cherry-pick this patch: https://github.com/jwilk/python-afl/commit/4c138687008a3d212906367a315ea79b6f6727c9.patch -- Jakub Wilk
Bug#869774: [Pkg-mozext-maintainers] Bug#869774: [SECURITY] [DSA 3921-1] enigmail update
On Sat 2017-07-29 16:20:09 +0200, Paul van der Vlis wrote: > I've tried today the upgrade, but there was no new version. > > When I look at the end of this page: > https://packages.debian.org/jessie/enigmail > > Then I see architecture "all" with version 2:1.9.8.1-1~deb8u1, and e.g. > architecture amd64 with version 2:1.8.2-4~deb8u1. I think the last one > is used, and that's the old one. > > For Stretch, there is only an architecture "all". That's correct. Newer versions of thunderbird and enigmail are more closely aligned, so that Enigmail requires only architecture-independent javascript code to run. So you should expect enigmail packages to be architecture "all" henceforth. Regards, --dkg
Bug#870225: manpages-dev: fails to upgrade from 'stretch' - trying to overwrite /usr/share/man/man3/explicit_bzero.3.gz
Am 31.07.2017 um 06:03 schrieb Andreas Beckmann: > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'stretch'. > It installed fine in 'stretch', then the upgrade to 'buster' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. Hi Andreas, thanks for spotting and reporting this bug. It should be fixed with the next upload, due shortly. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#870303: igtf-policy-bundle: po-debconf french translation
Package: igtf-policy-bundle Version: N/A Severity: wishlist Tags: patch l10n Dear Maintainer, Please find attached the debconf french translation, proofread by the debian-l10n-french mailing list contributors. This file should be put as debian/po/fr.po in your package build tree. Thanks, Baptiste -- System Information: Debian Release: 8.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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) # Translation of igtf-policy-bundle debconf templates to french. # Copyright (C) Debian French l10n team # This file is distributed under the same license as the igtf-policy-bundle package. # Julien Patriarca , 2014. # msgid "" msgstr "" "Project-Id-Version: igtf-policy-bundle\n" "Report-Msgid-Bugs-To: igtf-policy-bun...@packages.debian.org\n" "POT-Creation-Date: 2017-07-24 17:44+0200\n" "PO-Revision-Date: 2017-07-30 21:00+0200\n" "Last-Translator: Julien Patriarca \n" "Language-Team: FRENCH \n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates.in:2001 msgid "Trust IGTF @PROFILE@ CAs by default?" msgstr "Faut-il toujours faire confiance aux certificats d'autorités IGTF @PROFILE@ ?" #. Type: boolean #. Description #: ../templates.in:2001 msgid "" "Trusted IGTF Certification Authority certificates are installed in " "${location}." msgstr "" "Les certificats d'autorités de certification de confiance IGTF sont " "installés dans ${location}." #. Type: boolean #. Description #: ../templates.in:2001 msgid "" "Accept this option to have certificates included by default unless they are " "explicitly excluded. Reject it to choose the reverse policy, excluding them " "unless explicitly included." msgstr "" "Choisissez cette option pour avoir des certificats inclus par défaut, sauf " "s'ils ont été explicitement exclus. Ne l'acceptez pas si vous choisissez " "l'inverse, à savoir les exclure sauf s'ils ont été explicitement inclus." #. Type: boolean #. Description #: ../templates.in:2001 msgid "You will then have the opportunity to define the list of exceptions." msgstr "Vous aurez alors l'opportunité de définir la liste des exceptions." #. Type: multiselect #. Description #: ../templates.in:3001 msgid "Certificates to explicitly exclude:" msgstr "Certificats à exclure explicitement :" #. Type: multiselect #. Description #: ../templates.in:3001 msgid "" "Please select which certificates should not be installed in ${location}." msgstr "" "Veuillez choisir quels certificats ne doivent pas être installés dans " "${location}." #. Type: multiselect #. Description #: ../templates.in:4001 msgid "Certificates to explicitly include:" msgstr "Certificats à inclure explicitement :" #. Type: multiselect #. Description #: ../templates.in:4001 msgid "Please select which certificates should be installed in ${location}." msgstr "" "Veuillez choisir quels certificats doivent être installés dans ${location}." #. Type: string #. Description #: ../templates.in:5001 msgid "Installation directory of the certificates:" msgstr "Répertoire d'installation des certificats :" #. Type: string #. Description #: ../templates.in:5001 msgid "" "The default location /etc/grid-security/certificates should work fine in " "most cases." msgstr "La destination par défaut, /etc/grid-security/certificates, " "devrait fonctionner dans la majorité des cas." #. Type: string #. Description #: ../templates.in:5001 msgid "An alternative location can be given here if needed." msgstr "Un autre répertoire peut être indiqué ici si besoin."
Bug#870302: pavucontrol: High CPU usage
Package: pavucontrol Version: 3.0-3.1 Severity: normal Hi! I saw that pavucontrol uses about 2.4% ~ 3.3% of CPU without doing anything (when nothing is playing a sound in the computer). Trying to see what is happening with strace there is a lot (really a lot) of polling: = read(12, "\1\0\0\0\0\0\0\0", 8) = 8 getpid()= 23673 getpid()= 23673 getpid()= 23673 getpid()= 23673 write(10, "\1\0\0\0\0\0\0\0", 8)= 8 recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 5, 0) = 0 (Timeout) recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 5, 19980) = 1 ([{fd=12, revents=POLLIN}]) read(12, "\1\0\0\0\0\0\0\0", 8) = 8 getpid()= 23673 getpid()= 23673 getpid()= 23673 getpid()= 23673 write(10, "\1\0\0\0\0\0\0\0", 8)= 8 recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 5, 0) = 0 (Timeout) recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 5, 0) = 0 (Timeout) poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{iov_base="5\30\4\0sE\300\1\3\0\300\1\223\3\n\0\213\4\6\0tE\300\1sE\300\1*\0\0\0"..., iov_len=1608}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 1608 recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 5, 2) = 1 ([{fd=12, revents=POLLIN}]) (...) = Maybe this could somehow be improved? Wasting CPU for polling like this doesn't seem so right. Thank you! Best regards, Nelson -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (200, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pavucontrol depends on: ii libatk1.0-0 2.24.0-1 ii libatkmm-1.6-1v5 2.24.2-2 ii libc62.24-12 ii libcairo-gobject21.14.10-1 ii libcairo21.14.10-1 ii libcairomm-1.0-1v5 1.12.2-1 ii libcanberra-gtk3-0 0.30-3 ii libcanberra0 0.30-3 ii libgcc1 1:7.1.0-10 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.52.3-1 ii libglibmm-2.4-1v52.50.1-1 ii libgtk-3-0 3.22.16-1 ii libgtkmm-3.0-1v5 3.22.1-1 ii libpango-1.0-0 1.40.6-1 ii libpangocairo-1.0-0 1.40.6-1 ii libpangomm-1.4-1v5 2.40.1-3 ii libpulse-mainloop-glib0 10.0-2 ii libpulse010.0-2 ii libsigc++-2.0-0v52.10.0-1 ii libstdc++6 7.1.0-10 ii libx11-6 2:1.6.4-3 Versions of packages pavucontrol recommends: ii pulseaudio 10.0-2 pavucontrol suggests no packages. -- no debconf information
Bug#799295: lvm2: Errors about lvmetad on boot
On Thu 2015-09-17 17:33:43 +0200, Ralf Jung wrote: > Since a recent upgrade, I see the following error on every boot: > > /run/lvm/lvmetad.socket: connect failed: no such file or directory > WARNING: Failed to connect to lvmetad. Falling back to internal scanning. > > I have a LUKS-encrypted physical volume containing my root partition, and > this error > appears twice after I enter my password. I see this on boot as well, also on systems that have the root filesystem on an LVM volume that is only accessible once a dm-crypt volume is unlocked. I believe these warnings are harmless, but they are certainly noisy and scary-looking. If that's wrong, I hope that someone more knowledgable about LVM than i am will weigh in and explain why we should care about this warning. If this warning is indeed harmless, I recommend suppressing it entirely if possible when the configuration is one one of the common ones (e.g. in the initramfs) where we know that lvmetad is unlikely to already be running anyway. (if detecting that state is too much trouble, then i'd suppress it in all cases, unless the user is running lvm with --debug or --verbose) Regards, --dkg signature.asc Description: PGP signature
Bug#870284: ifupdown needs better support for complex ip route and rules
On Mon, Jul 31, 2017 at 04:41:22PM +0100, Peter Collinson wrote: >I am a Debian newbie - and arrived after many years of Redhattery. >RHEL has a per-interface file of rules and routes commands for the >ip command which can be used to both on up and down. The files >contain command lines for the ip command but they don't have >/bin/ip add or /bin/ip del so they are re-usuable. [...] > All this may have been suggested before, or be against Debian > philosophy so if this is Debian 'rubbish' please feel free to > ditch this report. Thanks for the suggestion Peter. I agree it would be nice to have this kind of functionality in the default network configuration tool of Debian. However, Debian does not only run on Linux kernels, and ifupdown tries to cater to FreeBSD and Hurd kernels as well. I'm not sure adding another, Linux-only way of configuring interfaces is the right thing to do. If anything, I'd rather change the syntax of the /etc/network/interfaces file in such a way that you can write: iface eth0 address 192.168.1.1/24 address fec0:1::1/64 route 10.1.1.0/24 route fec0:2::/64 via fec0:1::2 rule from 172.16.0.0/16 table foo ...etc... Since that still looks very much like the current syntax, and the simple forms of address and route can easily be supported on other kernels. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#867679: libglib2.0-dev-bin: fails to upgrade from 'sid' - trying to overwrite /usr/bin/gdbus-codegen
On 2017-07-08 14:54 +0200, Andreas Beckmann wrote: > Package: libglib2.0-dev-bin > Version: 2.53.3-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'sid' to 'experimental'. > It installed fine in 'sid', then the upgrade to 'experimental' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. There is already a Breaks+Replaces combo, but the versions are too low: , | $ apt-cache show libglib2.0-dev-bin | grep -E '^(Breaks|Replaces)' | Replaces: libglib2.0-dev (<< 2.51.4-1~) | Breaks: libglib2.0-dev (<< 2.51.4-1~) ` They need to be bumped to 2.53 or so, because glib2.0 2.52.3 ended up in unstable without the libglib2.0-dev-bin binary package. Cheers, Sven
Bug#870280: xelatex: Undefined control sequence \l__xeCJK_listings_letter_bool
Control: tags -1 - moreinfo Control: severity -1 serous Control: affects -1 src:developers-reference src:kicad Control: reassign -1 dblatex Control: tags -1 buster sid On Mon, Jul 31, 2017 at 11:49:38PM +0900, Norbert Preining wrote: > tags 870280 + moreinfo I did give a small example, > severity 870280 normal and a regression that causes at least 6 packages to FTBFS has to be RC bug(s) somewhere. > thanks > > > \usepackage{docbook} > > Using this package has been an endless source of problems. Please > provide a minimal non-working example *NOT* using docbook (dblatex) > or reassign the bug to dblatex. > > dblatex is notorious for messing up all kinds of internals of all > kinds of packages, and there is nothing to be debugged in the > horrible conondrum of dblatex. It is up to the dblatex maintainers. I'm reassigning to dblatex. > Best > > Norbert cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#859546: crypto is pointless
Control: tags -1 + patch The cryptography that is broken in this package is comically old and broken: single-DES, broken in every case in 2012 for ~$200 / 26 hours. Upstream is dead, and a fork is maintained in the src:barnowl project. The fork contains fixed code, both for the comically awful legacy crypto, and for the modern protocol that it appears people actually use in the real world: https://sources.debian.net/src/barnowl/1.9-4/zcrypt.c/#L24 I would love to see this package RM'd, but if not, then turning off the uselessly broken crypto might be a good solution: diff --git a/owl-2.2.2/owl.h b/owl-2.2.2/owl.h index a306373..aa4bbcf 100644 --- a/owl-2.2.2/owl.h +++ b/owl-2.2.2/owl.h @@ -180,10 +180,6 @@ static const char owl_h_fileIdent[] = "$Id: owl.h,v 1.128 2009/04/07 05:00:29 kr #define OWL_REGEX_QUOTECHARS"+*.?[]^\\${}()" #define OWL_REGEX_QUOTEWITH "\\" -#if defined(HAVE_DES_STRING_TO_KEY) && defined(HAVE_DES_KEY_SCHED) && defined(HAVE_DES_ECB_ENCRYPT) -#define OWL_ENABLE_ZCRYPT 1 -#endif - #define OWL_META(key) ((key)|0200) /* OWL_CTRL is definied in kepress.c */ This removes the dependencies on libssl-dev entirely, fixing the whole problem. The package builds fine with the useless dependency, but dh_shlibs gets mangry. Chris.
Bug#870297: Libre Office upgrade problem
Hi, On Mon, Jul 31, 2017 at 08:59:09PM +0200, ba...@jastra.netprojekt.pl wrote: > The following packages have unmet dependencies: > libreoffice : Depends: libreoffice-base but it is not going to be installed >Depends: libreoffice-calc but it is not going to be installed >Depends: libreoffice-core (= 1:5.3.5~rc1-3) but it is not > going to be installed >Depends: libreoffice-draw but it is not going to be installed >Depends: libreoffice-impress but it is not going to be > installed >Depends: libreoffice-math but it is not going to be installed >Depends: libreoffice-report-builder-bin but it is not going to > be installed >Depends: libreoffice-writer but it is not going to be installed >Depends: libreoffice-avmedia-backend-gstreamer but it is not > going to be installed or >libreoffice-avmedia-backend-vlc but it is not going to > be installed >Depends: python3-uno (>= 4.4.0~beta2) but it is not going to > be installed >Recommends: libreoffice-librelogo but it is not going to be > installed >Recommends: libreoffice-nlpsolver but it is not going to be > installed >Recommends: libreoffice-ogltrans but it is not going to be > installed >Recommends: libreoffice-pdfimport but it is not going to be > installed >Recommends: libreoffice-report-builder but it is not going to > be installed >Recommends: libreoffice-script-provider-bsh but it is not > going to be installed >Recommends: libreoffice-script-provider-js but it is not going > to be installed >Recommends: libreoffice-script-provider-python but it is not > going to be installed >Recommends: libreoffice-sdbc-postgresql but it is not going to > be installed >Recommends: libreoffice-wiki-publisher but it is not going to > be installed > E: Unable to correct problems, you have held broken packages. > extensa:/home/basia# > ** > > extensa:/home/basia# apt-get install libreoffice-base Why -base? You should try first with low-level like ure, uno-libs3 or libreoffice-core before trying -base (yes, I know the name is confusing.) Is your system clean otherwise? What does a apt-get -f install do? Does it work after that? > Do you have any idea? Perhaps debian mirror? I am using ftp.task.gda.pl Also tried with ftp.task.gda.pl now. Works, too. Regards, Rene
Bug#813266: debhelper: dh_auto_configure assumes install paths to be re-evaluated
Control: found -1 10.7.1 Hi, Unfortunately, we had to pull this patch out again as it broke packages. One of 5 examples were liblockfile that implicitly depends on ${prefix} to remain unexpanded for its DESTDIR support to work. Thanks, ~Niels
Bug#870150: sks FTBFS with OCaml 4.05.0: missing ?cloexec argument to UnixLabels.socket
On Sun 2017-07-30 16:53:28 +0200, Stéphane Glondu wrote: > sks FTBFS with OCaml 4.05.0. Relevant log: >> [...] >> ocamlc -I lib -I bdb -I +zarith -I +cryptokit -ccopt -g -ccopt -O2 >> -ccopt -fdebug-prefix-map=/tmp/sks-1.1.6=. -ccopt -fstack-protector-strong >> -ccopt -Wformat -ccopt -Werror=format-security -ccopt -O3 -ccopt >> -Werror-implicit-funct >> File "eventloop.ml", line 133, characters 15-19: >> Error: This expression has type ?cloexec:bool -> Unix.file_descr >>but an expression was expected of type >> Unix.file_descr = Unix.file_descr >> ocamlc -I lib -I bdb -I +zarith -I +cryptokit -ccopt -g -ccopt -O2 >> -ccopt -fdebug-prefix-map=/tmp/sks-1.1.6=. -ccopt -fstack-protector-strong >> -ccopt -Wformat -ccopt -Werror=format-security -ccopt -O3 -ccopt >> -Werror-implicit-funct >> Makefile:357: recipe for target 'eventloop.cmo' failed >> make[2]: *** [eventloop.cmo] Error 2 >> [...] thanks for the heads-up, Stéphane! > Attached is a patch. Unfortunately it is not compatible with the > version of OCaml currently in unstable, so you'll have to wait until > we upload ocaml >= 4.05.0. and thanks for the patch. But the fact that we need it is pretty disappointing, and it's not the first time that a backwards-incompatible API change was introduced in what looks like a minor release of OCaml. (see also the bytes changes introduced in 4.02 or 4.03 for example). What does OCaml upstream think that packages that are actually supposed to ship against multiple architectures and versions of the ocaml compiler should do in these cases? if we include this patch in debian, we will have to drop it in backports, etc. This kind of bookkeeping is annoying and error-prone. If it happened at major version transitions for OCaml, i'd be more inclined to put up with it, but when it's on seemingly minor updates, it makes me grumpy :/ --dkg signature.asc Description: PGP signature
Bug#858552: Acknowledgement (shairport-sync: shairport-sync user and group are not removed when package is purged)
Control: tags -1 wontfix Control: severity wishlist On 24/03/17 15:59, Denys Berkovskyy wrote: > Hi, > > Please find attached a path which fixes the issue. Since I was fixing issue > in git I have as well pushed changes to github and attached pull-request. To > test the changes I have made a package with changes applied to new upstream > version and uploaded it to mentors.debian.org: > https://mentors.debian.net/package/shairport-sync > > Alternatively you can download the package from mentors with dget: > dget -x > https://mentors.debian.net/debian/pool/main/s/shairport-sync/shairport-sync_3.0.2-0.1.dsc > > > I am new to the Debian packaging and I am not sure if I am doing the things > correctly. Could you let me know what should I do in the future. Is it > preferable to create and send patched on BTS, or doing it in git repository > and sending pull-requests is preferred way? And if creating packages with > changes applied is any use to maintainers? I would as well appreciate any > other comments you have. Hi Denys, First of all, sorry for leaving your bug report hanging for so long despite you being ultra-helpful and including a patch. I don't think the package should remove its user or group when it is removed or purged. The reason is twofold: 1- should there be any files leftover on your system owned by said user they will now show up only with their UID/GID numbers, and 2- if you then install another package the UID/GID will be recycled and they will be owned by the new user. shairport-sync doesn't install any files itself, and the only leftover items will likely be under /run, but I can't guarantee that users won't chown/chgrp files elsewhere on their filesystem, leading to confusion and even potential security issues. I had a scout around other common packages, and none that I looked at remove their users/groups. Aside from that your patch looks perfectly valid and it was very helpful that you went out of your way to learn how to do this. Please don't be discouraged by me not applying your patch! Attaching the patch to the bug and uploading to mentors were both very good things to do. Debian developers have a tendency not to use GitHub for a plethora of reasons. I don't personally mind GitHub at all and use it for various things, but I have used Debian's Alioth project system to host my Debian packages. All this means is that pushing to GitHub and doing the pull request was unnecessary, even if some people might find it helpful. Thanks again, Chris -- Chris Boot bo...@debian.org GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE signature.asc Description: OpenPGP digital signature
Bug#870300: vdr-plugin-epgsearch: Enable Pearl compatible regexes
Package: vdr-plugin-epgsearch Version: 1.0.1~beta6+git20150211-4.1 Severity: wishlist Dear Maintainer, Please enable pcre-library in the build to get Pearl compatible regexes. Default compile options in epgsearch only enable POSIX Extended Regular Expressions which in my opinion lack features that users are expecting. Epgsearch supports pcre out of the box but this needs to be enabled at compile time. From INSTALL document: "For support of Perl compatible regular expressions in a search you have to use libpcre: simply edit the plugins Makefile and uncomment '#REGEXLIB = pcre' to 'REGEXLIB = pcre' or append 'REGEXLIB=pcre' to your 'make plugins' call. (you will need pcreposix installed, comes with libpcre from www.pcre.org, but it's already part of most distributions)" This would add dependency to libpcre. (Package if have installed at the moment is locally compiled with pcre so system information shows this dependecy already) -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (1001, 'stable'), (510, 'testing'), (509, 'unstable'), (505, 'experimental'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vdr-plugin-epgsearch depends on: ii libc6 2.24-11+deb9u1 ii libgcc1 1:6.3.0-18 ii libpcre32:8.39-3 ii libstdc++6 6.3.0-18 ii sendemail 1.56-5 ii vdr [vdr-abi-2.2.0-debian] 2.2.0-6+b1 vdr-plugin-epgsearch recommends no packages. vdr-plugin-epgsearch suggests no packages. -- Configuration Files: /etc/vdr/plugins/epgsearch/epgsearchmenu.conf changed [not included] -- no debconf information
Bug#870234: Pending fixes for bugs in the arename package
tag 870234 + pending thanks Some bugs in the arename package are closed in revision e14aae77925bc43319e86fb1c8a34201eaf96415 in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/arename.git/commit/?id=e14aae7 Commit message: Add upstream patch for perl 5.26 compatibility. Thanks: Steve Langasek for the bug report and patch. Closes: #870234
Bug#869997: refcard: Portuguese translation update
Control: tags -1 + pending Miguel Figueiredo wrote: > Package: refcard > version: n/a > Tags: l10m, patch > Severity: minor > > Updated Portuguese translation. Feel free to use it. Committed to git, thanks! marking this bug as pending. Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0 " J E S S I E " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#870295: perl: broken symlink /usr/share/man/man1/pstruct.1.gz
Control: tag -1 pending On Mon, Jul 31, 2017 at 07:15:39PM +0200, Manolo Díaz wrote: > Package: perl > Version: 5.26.0-4 > Severity: normal > > Dear Maintainer, > > /usr/share/man/man1/pstruct.1.gz is a broken symlink that points to the > c2ph.1.gz file in the same directory which isn't provided by any package > from Debian testing accordantly to apt-file. Thanks! This will be fixed in the next upload. -- Niko Tyni nt...@debian.org
Bug#870235: Pending fixes for bugs in the libchi-perl package
tag 870235 + pending thanks Some bugs in the libchi-perl package are closed in revision 5338f8bdf495d32bbd25fca8dbb2c24a08bf9def in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libchi-perl.git/commit/?id=5338f8b Commit message: Add patch from CPAN RT for compatibility with Cache::FastMmap >= 1.45. Closes: #870235
Bug#870299: links: CVE-2017-11114
Source: links2 Version: 2.14-2 Severity: grave Tags: security upstream Hi, the following vulnerability was published for links. CVE-2017-4[0]: The put_chars function in html_r.c in Links 2.14 can cause a denial of service (buffer over-read) via a crafted html file. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-4 [1] http://seclists.org/fulldisclosure/2017/Jul/76 Regards, Laszlo/GCS
Bug#870297: Libre Office upgrade problem
On Mon, Jul 31, 2017 at 08:18:46PM +0200, ba...@jastra.netprojekt.pl wrote: > Dnia Mon, 31 Jul 2017 20:14:14 +0200 napisales[as]: > > > tag 870297 + moreinfo > > Good Afternoon, > > Should I try to translate Polish system messages? No, you should make apt print english. export LANG=C > I am using Debian testing. Thanks, but I guessed that from the version. Clean testing: rene@frodo:~$ sudo chroot buster root@frodo:/# apt install libreoffice Reading package lists... Done Building dependency tree... Done The following additional packages will be installed: adwaita-icon-theme ant ant-optional at-spi2-core bzip2 ca-certificates ca-certificates-java coinor-libcbc3 coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5 coinor-libcoinutils3v5 coinor-libosi1v5 dbus dconf-gsettings-backend dconf-service default-java-plugin default-jre default-jre-headless dh-python dictionaries-common emacsen-common file firebird3.0-common firebird3.0-common-doc firebird3.0-server-core fontconfig fontconfig-config fonts-crosextra-caladea fonts-crosextra-carlito fonts-dejavu fonts-dejavu-core fonts-dejavu-extra fonts-liberation fonts-linuxlibertine fonts-open-sans fonts-opensymbol fonts-sil-gentium fonts-sil-gentium-basic freepats gcj-6-jre-lib glib-networking glib-networking-common glib-networking-services gnome-icon-theme gsettings-desktop-schemas gstreamer1.0-plugins-bad gstreamer1.0-plugins-base gtk-update-icon-cache hicolor-icon-theme hunspell-en-us i965-va-driver icedtea-8-plugin icedtea-netx icedtea-netx-common iso-codes java-common krb5-locales libaacs0 libabw-0.1-1 libapache-poi-java libapache-pom-java libasound2 libasound2-data libass9 libasyncns0 libatk-bridge2.0-0 libatk-wrapper-java libatk-wrapper-java-jni libatk1.0-0 libatk1.0-data libatomic1 libatspi2.0-0 libavahi-client3 libavahi-common-data libavahi-common3 libavcodec57 libavformat57 libavutil55 libbase-java libbcmail-java libbcpkix-java libbcprov-java libbdplus0 libblas-common libblas3 libbluray2 libboost-date-time1.62.0 libboost-filesystem1.62.0 libboost-iostreams1.62.0 libboost-system1.62.0 libbs2b0 libbsh-java libcairo-gobject2 libcairo2 libcap2-bin libcdparanoia0 libcdr-0.1-1 libchromaprint1 libclucene-contribs1v5 libclucene-core1v5 libcmis-0.5-5v5 libcolamd2 libcolord2 libcommons-codec-java libcommons-collections3-java libcommons-logging-java libcommons-parent-java libcroco3 libcrystalhd3 libcups2 libcurl3-gnutls libdatrie1 libdbus-1-3 libdbus-glib-1-2 libdc1394-22 libdca0 libdconf1 libde265-0 libdom4j-java libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libdvdnav4 libdvdread4 libe-book-0.1-1 libedit2 libegl1-mesa libehcache-java libeot0 libepoxy0 libetonyek-0.1-1 libexpat1 libexttextcat-2.0-0 libexttextcat-data libfaad2 libfbclient2 libfftw3-double3 libflac8 libflite1 libfluidsynth1 libflute-java libfontconfig1 libfontenc1 libfonts-java libformula-java libfreehand-0.1-1 libfreetype6 libfribidi0 libgail-common libgail18 libgbm1 libgcj-bc libgcj-common libgcj17 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libgfortran3 libgif7 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglib2.0-0 libglib2.0-data libgltf-0.1-1 libgme0 libgomp1 libgraphite2-3 libgsm1 libgssapi-krb5-2 libgstreamer-plugins-bad1.0-0 libgstreamer-plugins-base1.0-0 libgstreamer1.0-0 libgtk-3-0 libgtk-3-bin libgtk-3-common libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libgudev-1.0-0 libharfbuzz-icu0 libharfbuzz0b libhsqldb1.8.0-java libhunspell-1.6-0 libhyphen0 libib-util libice6 libicu57 libilmbase12 libisorelax-java libitext-java libjack-jackd2-0 libjaxen-java libjbig0 libjcommon-java libjdom1-java libjpeg62-turbo libjson-glib-1.0-0 libjson-glib-1.0-common libk5crypto3 libkate1 libkeyutils1 libkrb5-3 libkrb5support0 liblangtag-common liblangtag1 liblapack3 liblayout-java liblcms2-2 libldap-2.4-2 libldap-common liblilv-0-0 libllvm3.9 libloader-java liblog4j1.2-java libltdl7 libmagic-mgc libmagic1 libmail-java libmhash2 libmjpegutils-2.1-0 libmms0 libmodplug1 libmp3lame0 libmpcdec6 libmpdec2 libmpeg2encpp-2.1-0 libmpg123-0 libmplex2-2.1-0 libmspub-0.1-1 libmsv-java libmwaw-0.3-3 libmythes-1.2-0 libneon27-gnutls libnghttp2-14 libnspr4 libnss3 libnuma1 libodfgen-0.1-1 libofa0 libogg0 libopenal-data libopenal1 libopencv-calib3d2.4v5 libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5 libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5 libopencv-objdetect2.4v5 libopencv-video2.4v5 libopenexr22 libopenjp2-7 libopenmpt0 libopus0 liborc-0.4-0 liborcus-0.12-0 libpagemaker-0.0-0 libpam-cap libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpaper-utils libpaper1 libpciaccess0 libpcsclite1 libpentaho-reporting-flow-engine-java libpixie-java libpixman-1-0 libpng16-16 libpoppler64 libpq5 libproxy1v5 libpulse0 libpython-stdlib libpython2.7-minimal libpython2.7-stdlib libpython3-stdlib libpython3.5 libpython3.5-minimal libpython3.5-stdlib libquadmath0 libra
Bug#870298: 4.11.0-2-amd64 headers cannot be installed
Package: linux-headers-4.11.0-2-amd64 Version: 4.11.11-1+b1 Severity: serious Hi, I have been trying to install linux-headers-4.11.0-2-amd64 on unstable/sid for a couple of days now and cannot due to an unresolved dependency. Specifically, the package depends on linux-headers-4.11.0-2-common revision (= 4.11.11-1+b1), but the latter does not exist. Can someone check that revision numbers and dependencies are correct? # LANG=C apt-get install linux-headers-4.11.0-2-amd64 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-headers-4.11.0-2-amd64 : Depends: linux-headers-4.11.0-2-common (= 4.11.11-1+b1) but 4.11.11-1 is to be installed E: Unable to correct problems, you have held broken packages. Thank you. Regards, Philippe
Bug#859551: fixed upstream
Control: tags -1 + fixed-upstream pgbouncer contains an embedded copy of libusual, where the problems appear to lie. Upstream have picked up an updated embedded copy of libusual[1], and now builds fine. The libusual fixes are pretty spread out, e.g. https://github.com/libusual/libusual/commit/1c7798405869bb56e9c055dcf1f115b409f82ed1 https://github.com/libusual/libusual/commit/0e56f729d74e4af6c19fe60f6e2b47f5e717dcac Doesn't seem worth trying to backport them? Chris. 1: https://github.com/pgbouncer/pgbouncer/commit/2a064d04b346f3496f82682ffe997c3bca7d5f67
Bug#870297: Libre Office upgrade problem
tag 870297 + moreinfo tag 870297 + unreproducible thanks Hi, On Mon, Jul 31, 2017 at 07:57:11PM +0200, ba...@jastra.netprojekt.pl wrote: > I have installed some programs, which I hoped could help me to contact my > tablet with Android. They resulted uninstalling my Libre Office. Then your system was in some way broken. > Attempt to install Libre Office again resulted dependencies problems with > versions (system communicates in Polish) Then please send it again in english? > extensa:/home/basia# apt-get install libreoffice > Czytanie list pakietów... Gotowe > Budowanie drzewa zależności > Odczyt informacji o stanie... Gotowe > Nie udało się zainstalować niektórych pakietów. Może to oznaczać, > że zażądano niemożliwej sytuacji lub użyto dystrybucji niestabilnej, > w której niektóre pakiety nie zostały jeszcze utworzone lub przeniesione > z katalogu Incoming ("Przychodzące"). > Następujące informacje mogą pomóc rozwiązać sytuację: > Następujące pakiety mają niespełnione zależności: > libreoffice : Wymaga: libreoffice-base ale nie zostanie zainstalowany >Wymaga: libreoffice-calc ale nie zostanie zainstalowany >Wymaga: libreoffice-core (= 1:5.3.5~rc1-3) ale nie zostanie > zainstalowany >Wymaga: libreoffice-draw ale nie zostanie zainstalowany >Wymaga: libreoffice-impress ale nie zostanie zainstalowany >Wymaga: libreoffice-math ale nie zostanie zainstalowany >Wymaga: libreoffice-report-builder-bin ale nie zostanie > zainstalowany >Wymaga: libreoffice-writer ale nie zostanie zainstalowany >Wymaga: libreoffice-avmedia-backend-gstreamer ale nie zostanie > zainstalowany lub >libreoffice-avmedia-backend-vlc ale nie zostanie > zainstalowany >Wymaga: python3-uno (>= 4.4.0~beta2) ale nie zostanie > zainstalowany >Poleca: libreoffice-librelogo ale nie zostanie zainstalowany >Poleca: libreoffice-nlpsolver ale nie zostanie zainstalowany >Poleca: libreoffice-ogltrans ale nie zostanie zainstalowany >Poleca: libreoffice-pdfimport ale nie zostanie zainstalowany >Poleca: libreoffice-report-builder ale nie zostanie > zainstalowany >Poleca: libreoffice-script-provider-bsh ale nie zostanie > zainstalowany >Poleca: libreoffice-script-provider-js ale nie zostanie > zainstalowany >Poleca: libreoffice-script-provider-python ale nie zostanie > zainstalowany >Poleca: libreoffice-sdbc-postgresql ale nie zostanie > zainstalowany >Poleca: libreoffice-wiki-publisher ale nie zostanie > zainstalowany > E: Nie udało się naprawić problemów, zatrzymano uszkodzone pakiety. > extensa:/home/basia# > *** LO is definitely installable in testing. I believe you have a weird mix of packages installed. Which wouldn't be a LO bug at all. > Please, try to organize upgrade of needed components for Libre Office Please write bug reports in english, and this is not a support forum. Regards, Rene
Bug#867975: I second that
I second that, I was going to ask the same. By the way, this bug appears on source package, I may very well be wrong, and it probably doesn't matter, but I expected to see it applied to binary package. Still having a game with this old Debian version right now, appreciated it so far. I also added this game to JeuxLibres.net database (french news website about FLOSS videogames). Thanks!
Bug#870297: Libre Office upgrade problem
Package: libreoffice version: 1:5.3.5~rc1-3 I have installed some programs, which I hoped could help me to contact my tablet with Android. They resulted uninstalling my Libre Office. Attempt to install Libre Office again resulted dependencies problems with versions (system communicates in Polish) extensa:/home/basia# apt-get install libreoffice Czytanie list pakietów... Gotowe Budowanie drzewa zależności Odczyt informacji o stanie... Gotowe Nie udało się zainstalować niektórych pakietów. Może to oznaczać, że zażądano niemożliwej sytuacji lub użyto dystrybucji niestabilnej, w której niektóre pakiety nie zostały jeszcze utworzone lub przeniesione z katalogu Incoming ("Przychodzące"). Następujące informacje mogą pomóc rozwiązać sytuację: Następujące pakiety mają niespełnione zależności: libreoffice : Wymaga: libreoffice-base ale nie zostanie zainstalowany Wymaga: libreoffice-calc ale nie zostanie zainstalowany Wymaga: libreoffice-core (= 1:5.3.5~rc1-3) ale nie zostanie zainstalowany Wymaga: libreoffice-draw ale nie zostanie zainstalowany Wymaga: libreoffice-impress ale nie zostanie zainstalowany Wymaga: libreoffice-math ale nie zostanie zainstalowany Wymaga: libreoffice-report-builder-bin ale nie zostanie zainstalowany Wymaga: libreoffice-writer ale nie zostanie zainstalowany Wymaga: libreoffice-avmedia-backend-gstreamer ale nie zostanie zainstalowany lub libreoffice-avmedia-backend-vlc ale nie zostanie zainstalowany Wymaga: python3-uno (>= 4.4.0~beta2) ale nie zostanie zainstalowany Poleca: libreoffice-librelogo ale nie zostanie zainstalowany Poleca: libreoffice-nlpsolver ale nie zostanie zainstalowany Poleca: libreoffice-ogltrans ale nie zostanie zainstalowany Poleca: libreoffice-pdfimport ale nie zostanie zainstalowany Poleca: libreoffice-report-builder ale nie zostanie zainstalowany Poleca: libreoffice-script-provider-bsh ale nie zostanie zainstalowany Poleca: libreoffice-script-provider-js ale nie zostanie zainstalowany Poleca: libreoffice-script-provider-python ale nie zostanie zainstalowany Poleca: libreoffice-sdbc-postgresql ale nie zostanie zainstalowany Poleca: libreoffice-wiki-publisher ale nie zostanie zainstalowany E: Nie udało się naprawić problemów, zatrzymano uszkodzone pakiety. extensa:/home/basia# *** Please, try to organize upgrade of needed components for Libre Office Many thanks in advance With best regards :-) Basia
Bug#870296: libreoffice-writer: Orca incorrectly announces paragraph indentation when using the get attributes "orca+f" keyboard shortcut
Package: libreoffice-writer Version: 4.3.5.2 1:5.4.0-1 Tags: a11y upstream Owner: b...@hypra.fr User: b...@hypra.fr Usertags: hypra Forwarded: https://bugs.documentfoundation.org/show_bug.cgi?id=88762 DESCRIPTION FROM UPSTREAM: When indenting the first line of a paragraph through the paragraph settings dialog in the format menu, orca says the text is indented when I use the "orca+f" keyboard command even if I am not on the first line of the paragraph. Orca should only announce this indent when on the first line of the paragraph.
Bug#870295: perl: broken symlink /usr/share/man/man1/pstruct.1.gz
Package: perl Version: 5.26.0-4 Severity: normal Dear Maintainer, /usr/share/man/man1/pstruct.1.gz is a broken symlink that points to the c2ph.1.gz file in the same directory which isn't provided by any package from Debian testing accordantly to apt-file. Regards, -- Manolo Díaz