Bug#914776: sympa: Preseeding installation with debconf-set-selections not possible
Package: sympa Version: 6.2.16~dfsg-3+deb9u1 Severity: normal Dear Maintainer, It's not possible to use dpkg-set-selections to preseed the following debconf items: sympa/language sympa/hostname sympa/listmaster wwsympa/wwsympa_url This is due to debian/config always using db_set to overwrite these values. Instead of always using the values set under "# Default values", the config script should check whether the debconf database already has entries for these items, and use them instead.
Bug#914646: piuparts: failed-testing with no prpblem listed
On 2018-11-26 05:46, Andreas Beckmann wrote:
>> There is nothing in the log indicating why this is failed-testing.
>
> There is, although it is not abvious:
>
> 0m21.0s INFO: dirname part contains a symlink:
> /var/run/sslsplit (sslsplit) != /run/sslsplit (?)
> /var/run -> /run
Would this end of the logfile have been more helpful?
[...]
install ok installed util-linux util-linux 2.32.1-0.2
install ok installed zlib1g:amd64zlib1g 1:1.2.11.dfsg-1
7m51.2s DEBUG: Command ok: ['chroot', '/srv/piuparts/tmp/tmpcKLOF_',
'dpkg-query', '-W', '-f',
'${Status}\\t${binary:Package}\\t${Package}\\t${Version}\\n']
7m51.9s ERROR: installs objects over existing directory symlinks:
/var/run/sslsplit (sslsplit) != /run/sslsplit (?)
/var/run -> /run
7m52.3s DEBUG: Starting command: ['umount',
'/srv/piuparts/tmp/tmpcKLOF_/dev/shm']
8m21.7s DEBUG: Command ok: ['umount', '/srv/piuparts/tmp/tmpcKLOF_/dev/shm']
8m21.7s DEBUG: Starting command: ['umount',
'/srv/piuparts/tmp/tmpcKLOF_/dev/console']
8m21.7s DEBUG: Command ok: ['umount', '/srv/piuparts/tmp/tmpcKLOF_/dev/console']
8m21.7s DEBUG: Starting command: ['umount',
'/srv/piuparts/tmp/tmpcKLOF_/dev/ptmx']
8m21.8s DEBUG: Command ok: ['umount', '/srv/piuparts/tmp/tmpcKLOF_/dev/ptmx']
8m21.8s DEBUG: Starting command: ['umount',
'/srv/piuparts/tmp/tmpcKLOF_/dev/pts']
8m22.7s DEBUG: Command ok: ['umount', '/srv/piuparts/tmp/tmpcKLOF_/dev/pts']
8m22.7s DEBUG: Starting command: ['umount', '/srv/piuparts/tmp/tmpcKLOF_/proc']
8m22.8s DEBUG: Command ok: ['umount', '/srv/piuparts/tmp/tmpcKLOF_/proc']
8m22.8s DEBUG: Starting command: ['rm', '-rf', '--one-file-system',
'/srv/piuparts/tmp/tmpcKLOF_']
8m22.9s DEBUG: Command ok: ['rm', '-rf', '--one-file-system',
'/srv/piuparts/tmp/tmpcKLOF_']
8m22.9s DEBUG: Removed directory tree at /srv/piuparts/tmp/tmpcKLOF_
8m22.9s ERROR: piuparts run ends.
Andreas
Bug#867035: context: fatal file format error
On 03.07.17 17:43, Sanjoy Mahajan wrote: Hi Sanjoy, Sorry late response. Your E-Mail did not make to the mailing list, b/c it breached the 100k limit. > context fails with "(Fatal format file error; I'm stymied)". Here the > log from a minimal example, with test.tex as > > \starttext > \input knuth > \stoptext > > Here's the end of the output showing the error: > > mtx-context | run 1: luatex > --fmt="/var/lib/texmf/luatex-cache/context/b47c3d3cee7cb6c86268d0595268c442/formats/luatex/cont-en" > --jobname="test" > --lua="/var/lib/texmf/luatex-cache/context/b47c3d3cee7cb6c86268d0595268c442/formats/luatex/cont-en.lui" > --no-parse-first-line --c:currentrun=1 --c:fulljobname="./test.tex" > --c:input="./test.tex" --c:kindofrun=1 --c:maxnofruns=9 "cont-yes.mkiv" > This is LuaTeX, Version 1.0.4 (TeX Live 2017/Debian) >system commands enabled. > > (Fatal format file error; I'm stymied) > mtx-context | fatal error: return code: 1 > > The full log is attached. > > I think that the problem happens because context is still at 2016 > whereas texlive-binaries recently became 2017. I'm running a mostly > testing system, and texlive-binaries 2017 made it out of unstable into > testing, but the newer, 2017 context hasn't made it out of unstable. > > As a test of this guess, on my other laptop (also Debian/amd64/mostly > testing), which has the same problem as reported here, I did > > $ apt -t unstable install context > > which brought in zillions of texlive packages, and reran context on > test.tex -- with no problem. I also reran it on my current book project > (about 100 pages so far), and it also worked. > Thanks for your analysis! Currently all packages in Debian testing seem to be consistent. So I'd assume that your issue is gone. Can we close that bug now? Hilmar -- #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#914613: xdg-screensaver: Does nothing for many DEs (lxde, dde, enlightenment etc.)
Teemu Ikonen wrote: > The attached patch makes the 'xset s' codepath the default. It > is now run if the DE is detected, but there is no specialized > code to handle its screensaver. On further testing I noticed that this patch breaks programs which expect 'xdg-screensaver lock' to succeed (for example xfce4-power-manager complains about not able to lock screen on suspend). This is because the 'screensaver_xserver' code in xdg-screensaver does not support the lock subcommand. The bug report itself is still valid though, LXDE users without a screen saver other than the X server blanking would benefit from having a working 'xdg-screensaver reset' command, which is used by many media players to inhibit screen saving. I found this bug when setting up xss-lock. I ended up writing a patch to support it explicitly in xdg-screensaver, submitted to upstream here: https://bugs.freedesktop.org/show_bug.cgi?id=108865 Best, Teemu
Bug#914575: [Pkg-alsa-devel] Bug#914575: libasound2: ALSA stopped working after updating libasound2 to 1.1.7
* Beta Version [2018-11-25 09:44 +0300]: > Package: libasound2 > Version: 1.1.7-1 > Severity: important > > Dear Maintainer, > > after updating libasound2 package to 1.1.7-1 version, ALSA stopped working in > Audacious player and Audacity audio editor. When trying to use ALSA output in > Audacious, it gives error: ALSA error: snd_pcm_open failed: Нет такого файла > или каталога. > > Audacious terminal output: > ERROR alsa.cc:569 [open_mixer]: snd_mixer_find_selem failed. > WARNING ffaudio-core.cc:188 [ffaudio_log_cb]: <(nil)> Invalid return value 0 > for stream protocol > WARNING ffaudio-core.cc:188 [ffaudio_log_cb]: <(nil)> Invalid return value 0 > for stream protocol > WARNING ffaudio-core.cc:188 [ffaudio_log_cb]: <(nil)> Invalid return value 0 > for stream protocol > WARNING ffaudio-core.cc:188 [ffaudio_log_cb]: <(nil)> Invalid return value 0 > for stream protocol > ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave > ERROR util.cc:269 [audgui_simple_message]: ALSA error: snd_pcm_open failed: > Нет > такого файла или каталога. > > Pulseaudio output in Audacious works ok. > > Audacity sound editor produce no sound and i can't choose other sound output, > except unworking ALSA. > > Audacity terminal output: > ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave > ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave > ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear > ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe > ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side > Cannot connect to server socket err = Нет такого файла или каталога > Cannot connect to server request channel > jack server is not running or cannot be started > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > unlock > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > unlock > Cannot connect to server socket err = Нет такого файла или каталога > Cannot connect to server request channel > jack server is not running or cannot be started > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > unlock > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > unlock > ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port > ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port > Expression 'alsa_snd_pcm_hw_params_set_period_size_near( pcm, hwParams, > , )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: > 924 > ALSA lib pcm_a52.c:823:(_snd_pcm_a52_open) a52 is only for playback > ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card > ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card > ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave > ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave > ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave > Cannot connect to server socket err = Нет такого файла или каталога > Cannot connect to server request channel > jack server is not running or cannot be started > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > unlock > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > unlock > Expression 'stream->playback.pcm' failed in > 'src/hostapi/alsa/pa_linux_alsa.c', > line: 4628 > Expression 'stream->playback.pcm' failed in > 'src/hostapi/alsa/pa_linux_alsa.c', > line: 4628 What tells: $ dpkg -l | egrep "(libasou|alsa)" ? Elimar -- Learned men are the cisterns of knowledge, not the fountainheads ;-) signature.asc Description: PGP signature
Bug#914592: [Python-modules-team] Bug#914592: Upcoming pytest-4 problems
Hi Ondrej, On 26.11.18 21:29, Ondrej Novy wrote: > my plan is: > > * keep 3.x for Buster > * upgrade to >= 4.x just after Buster release > > Because we are going to drop Python after Buster release, I think it's > perfectly fine that Astropy (Py2 version) will not support Pytest 4.x. Thanks, however it turns out that this will unfortunately not work for me: from astropys POV, pytest seems to be broken in versions 3.7 - 3.10; see https://github.com/astropy/astropy/issues/8177 I also observed diverse failures on other (astropy dependent) packages with 3.10. Which basically means that I need to switch off the tests, unless pytests upstream provides a bugfixed 3.X version. However, it seems that I need to start with the removal of the Python 2 astropy ecosystem, which may be in any case not the worst decision. Personally, I like to put pressure to move towards Python 3. Cheers Ole
Bug#914775: openjdk-8: does not honor DEB_BUILD_OPTIONS=parallel=3
Source: openjdk-8 Version: 8u191-b12-1 Severity: important Hi, openjdk-8 does not seem to honor the DEB_BUILD_OPTIONS=parallel=... setting. I just noticed during an automated rebuild of experimental on a machine with `nproc` = 8 and DEB_BUILD_OPTIONS=parallel=3 that there were 8 java processes running in parallel doing the tests ... creating much more load than expected. Andreas
Bug#914774: nordugrid-arc: please enable parallel building
Source: nordugrid-arc Version: 5.4.3-2 Severity: wishlist Tags: patch Hi, nordugrid-arc seems to build fine with multiple build jobs when building. Thus, my suggestion is to enable the parallel build (reading the number of jobs from DEB_BUILD_OPTIONS, and adding it to the make invocation) to speed up the build when requested (see also Policy §4.9.1). Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -14,6 +14,10 @@ else CANL_CONFIGURE_OPTION = endif +ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +NJOBS := -j $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +endif + configure: configure-stamp configure-stamp: @@ -51,9 +55,9 @@ build-indep: build-stamp build-stamp: configure-stamp dh_testdir - $(MAKE) + $(MAKE) $(NJOBS) ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),) - $(MAKE) check + $(MAKE) $(NJOBS) check endif touch $@
Bug#547292: Need help dealing with this l10n bug?
Hello Emfox, On Tue, Nov 27, 2018 at 10:39:11AM +0800, Emfox Zhou wrote: > Hello, comix package upstream is MIA long ago, and a new community > version call mcomix is formed and well maintained, so all work moved to > mcomix. Thanks for the information / pointer. > we have concern to orphan or remove comix later. I suggest to do so, asking for removal of comix in this situation. Probably best to do so soon, as the freeze is supposed to occur early 2019. Greetings helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: Digital signature
Bug#914773: ITP: r-cran-rcppprogress -- interruptible progress bar for C++ in GNU R packages
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-rcppprogress Version : 0.4.1 Upstream Author : Karl Forner * URL : https://cran.r-project.org/package=RcppProgress * License : GPL-3+ Programming Lang: GNU R Description : interruptible progress bar for C++ in GNU R packages This GNU R package allows one to display a progress bar in the R console for long running computations taking place in c++ code, and support for interrupting those computations even in multithreaded code, typically using OpenMP. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-rcppprogress This package is a predependency of my final target r-other-uwot.
Bug#908992: diffoscope: side-by-side diff for terminal output
Hi Paul, > Hmm, I would have thought the recursion level could be determined at > the time the data is being extracted from the data structure? How is > the recursion level determined right now? I didn't really check at the time, it was mostly a gut feel & braindump in case anyone else was moved to try and implement this. (You saw the scrappiness of the diff, right?) It's either just not present where need it to be (ie. we simply aren't passing some parameters around or something quote-unquote-trivial), or we really don't know it. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#914466: RM: icu4j-49 -- ROM; Obsolete, no longer used
On Fri, 23 Nov 2018 18:00:12 +0100 Emmanuel Bourg wrote: > Package: ftp.debian.org > Severity: normal > > Hi, > > Please remove the icu4j-49 package. It's an old version of ICU4J that was > only used for the needs of src:eclipse, and it's about to be removed (#914448). At least according to DAK, not quite: Checking reverse dependencies... # Broken Build-Depends: lucene4.10: libicu4j-49-java Dependency problem found. Please remove the moreinfo tag once this is resolved. Scott K
Bug#914772: ITP: r-cran-rcppannoy -- Rcpp bindings for Annoy (approximate nearest neighbors)
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-rcppannoy Version : 0.0.11 Upstream Author : Dirk Eddelbuettel * URL : https://cran.r-project.org/package=RcppAnnoy * License : GPL-2+ Programming Lang: GNU R Description : Rcpp bindings for Annoy (approximate nearest neighbors) 'Annoy' is a small C++ library for Approximate Nearest Neighbors written for efficient memory usage as well an ability to load from / save to disk. This package provides an R interface by relying on the 'Rcpp' package, exposing the same interface as the original Python wrapper to 'Annoy'. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-rcppannoy This package is a predependency of my final target r-other-uwot.
Bug#914771: bundler: cannot load such file -- bundler-1.16.1/exe/bundle
Package: bundler Version: 1.16.1-3 Severity: normal Dear Maintainer, I'm preparing open-build-service 2.9 package for Debian. While that I got to update some build-deps and noticed that there is an issue in bundler package that the tests on `ruby-appraisal` reports: ``` │ Run tests for ruby2.5 from debian/ruby-tests.rake │ └──┘ RUBYLIB=/build/ruby-appraisal-2.2.0/debian/ruby-appraisal/usr/lib/ruby/vendor_ruby:. GEM_PATH=debian/ruby-appraisal/usr/share/rubygems-integration/all:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all ruby2.5 -S rake -f debian/ruby-tests.rake /usr/bin/ruby2.5 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb bin/bundle:104:in `load': cannot load such file -- /usr/share/rubygems-integration/all/gems/bundler-1.16.1/exe/bundle (LoadError) ``` We noticed this has been addressed upstream: https://github.com/bundler/bundler/issues/6537 And you can see, upstream said that it is fixed on September 18, and the current version in Debian archive is from July 23. So there is probably a need to be update. If you agree, I may proceed a newer version(which one you prefer?) in salsa.d.o for you to review. Best regards, -Andrew
Bug#913845: httping FTCBFS: builds for the wrong architecture
Hi Helmut. Its still FTBFS in reproducible builds :( --a
Bug#914767: RM: foma/1:0.9.18~r248-1
Control: reassign -1 ftp.debian.org On Tue, 2018-11-27 at 10:49 +0530, Kartik Mistry wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > Please remove foma from experimental (1:0.9.18~r248-1). This is as > requested > by upstream also. I'll prepare updated version in unstable after > this. The Release Team don't manage experimental; ftp-master do. Re-assigning. Regards, Adam
Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source
Aha! I didn't have the correct versions of the dependencies as packaged in sid. Your error is the same as in the original email. The error "Glyph psili cannot be in both @MC_top and @MC_topleft" I believe was fixed by https://github.com/googlei18n/ufo2ft/pull/276, and should not occur with ufo2ft >= 2.3.0.
Bug#914770: llvm-toolchain-7: baseline violation on i386
Source: llvm-toolchain-7 Version: 1:7.0.1~+rc2-7 Severity: grave LLVM violates the i386 baseline by using SSE2, which on this Pentium III machine results in a crash when starting xorg due to an illegal instruction: [ 112.413] (EE) [ 112.413] (EE) Backtrace: [ 112.414] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x122) [0x5c4a62] [ 112.416] (EE) 1: linux-gate.so.1 (?+0x0) [0xb7fc5d68] [ 112.420] (EE) 2: /lib/i386-linux-gnu/libLLVM-7.so.1 (_init+0x52eea) [0xae21d898] [ 112.420] (EE) [ 112.421] (EE) Illegal instruction at address 0xae1ca9ae [ 112.421] (EE) Fatal server error: [ 112.421] (EE) Caught signal 4 (Illegal instruction). Server aborting Reverting back to mesa 18.1.9 and thus LLVM 6 fixes the problem. With the LLVM dev tools, the problem can be trivially reproduced: $ llvm-config-7 Illegal instruction $ GDB confirms that it's caused by SSE2: (gdb) x/1i $eip => 0xb4fde9ae: punpcklqdq %xmm1,%xmm2
Bug#914769: RFP: bindgen -- Generate Rust FFI bindings to C and C++ libraries
Package: wnpp Severity: wishlist * Package name: bindgen Version : 0.43.2 Upstream Author : Jyun-Yan You * URL : https://github.com/rust-lang/rust-bindgen * License : BSD-3-Clause Programming Lang: Rust Description : Generate Rust FFI bindings to C and C++ libraries Automatically generates Rust FFI bindings to C and C++ libraries. This is the opposite direction of cbindgen (which is already in debian) -- it makes it straightforward to create Rust bindings over C and (some) C++ libraries. Concretely, it is a build-dependency for packaging the rust nettle bindings, which are used by the Sequoia OpenPGP implementation.
Bug#914768: sed: Typos in 'info'.
Package: sed
Version: 4.5-1
Severity: wishlist
Dear Maintainer,
In these examples from "info sed", `-E' is not used for anything:
$ printf '%s\n' a1 a2 a3 | sed -E '/1/bx ; s/a/z/ ; :x ; y/123/456/'
$ printf '%s\n' a1 a2 a3 | sed -E '/1/!s/a/z/ ; y/123/456/'
In this example from "info sed", `g' is not used for anything:
sed ':x ; /=$/ { N ; s/=\n//g ; bx }' jaques.txt
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sed depends on:
ii libc62.27-5
ii libselinux1 2.8-1+b1
sed recommends no packages.
sed suggests no packages.
-- no debconf information
Bug#615134: fixed in bash-completion 1:1.90-1
On Mon, Nov 26, 2018 at 09:44:35PM -0200, Gabriel F. T. Gomes wrote: > I noticed that you reopened this bug report and I suppose you did so > because you think that the bug is only partially fixed (as suggested in > message #25 [1]). Uff, this is an old bug. I confirm that it is partially fixed in the version in Debian unstable. A source line with quotes and tilde is not followed, but without quotes a tilde is correctly expanded. In my local configuration, I've removed the quotes and was happy since. > I just submitted a patch upstream [2] that, to the best of my knowledge, > fixes the rest of the problem, but since I'm not a mutt user, could you > please confirm that it also works for you? > > [1] https://bugs.debian.org/615134#25 > > [2] https://github.com/scop/bash-completion/pull/261 I confirm that the patch makes mutt source stanzas with quotes and tilde work. The commit description precisely describes the problem. Thank you. Helmut
Bug#914767: RM: foma/1:0.9.18~r248-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove foma from experimental (1:0.9.18~r248-1). This is as requested by upstream also. I'll prepare updated version in unstable after this. Thanks! -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:gu (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Kartik Mistry | IRC: kart_ https://kartikm.wordpress.com signature.asc Description: PGP signature
Bug#914766: mkl: path of headers
Package: libmkl-dev Version: 2019.0.117-2 Severity: important MKL's mkl_cblas.h header can be used as a CBlas header alternative. However when it is really used in this way, the preprocessor won't be able to find another header "mkl_types.h" in public directory. That means, I'd better move the MKL headers to the public directory from the private directory /usr/include/mkl. And this change will reduce other software's build system maintenance burden since they won't need to add the -I/usr/include/mkl argument anymore. This problem is found during the local rebuild of opencv 3.2.0+dfsg-4.1 .
Bug#805987: (no subject)
Shall be fixed in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914765 smime.p7s Description: S/MIME Cryptographic Signature
Bug#914765: An improved version upstream
Package: fonts-radisnoir Source: fonts-radisnoir Version: 0.9b-3 Severity: important I have uploaded an improved version of this font the following site, version which basically corrects the metadata: https://fontlibrary.org/en/font/radis-sans The original website from this font is no longer available. You will want to make the above page the new one, and build this package from there in case there are further updates. Also fixes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805987 smime.p7s Description: S/MIME Cryptographic Signature
Bug#914764: biometric-driver-community-multidevice: modifies conffiles (policy 10.7.3): /etc/biometric-auth/biometric-drivers.conf
Package: biometric-driver-community-multidevice Version: 0.9.56-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package modifies conffiles. This is forbidden by the policy, see https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files 10.7.3: "[...] The easy way to achieve this behavior is to make the configuration file a conffile. [...] This implies that the default version will be part of the package distribution, and must not be modified by the maintainer scripts during installation (or at any other time)." Note that once a package ships a modified version of that conffile, dpkg will prompt the user for an action how to handle the upgrade of this modified conffile (that was not modified by the user). Further in 10.7.3: "[...] must not ask unnecessary questions (particularly during upgrades) [...]" If a configuration file is customized by a maintainer script after having asked some debconf questions, it may not be marked as a conffile. Instead a template could be installed in /usr/share and used by the postinst script to fill in the custom values and create (or update) the configuration file (preserving any user modifications!). This file must be removed during postrm purge. ucf(1) may help with these tasks. See also https://wiki.debian.org/DpkgConffileHandling In https://lists.debian.org/debian-devel/2012/09/msg00412.html and followups it has been agreed that these bugs are to be filed with severity serious. debsums reports modification of the following files, from the attached log (scroll to the bottom...): /etc/biometric-auth/biometric-drivers.conf cheers, Andreas biometric-driver-community-multidevice_0.9.56-1.log.gz Description: application/gzip
Bug#914763: neutron-vpnaas-common: fails to remove: neutron-vpnaas-common.postrm: neutron-plugin-manage: not found
Package: neutron-vpnaas-common Version: 2:13.0.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to remove. >From the attached log (scroll to the bottom...): Removing neutron-vpnaas-common (2:13.0.1-1) ... /var/lib/dpkg/info/neutron-vpnaas-common.postrm: 1115: /var/lib/dpkg/info/neutron-vpnaas-common.postrm: neutron-plugin-manage: not found dpkg: error processing package neutron-vpnaas-common (--remove): installed neutron-vpnaas-common package post-removal script subprocess returned error exit status 127 cheers, Andreas neutron-vpnaas-common_2:13.0.1-1.log.gz Description: application/gzip
Bug#914695: dgit autopkgtest breaks with git 2.20
Hi Ian, Ian Jackson wrote: > https://ci.debian.net/data/autopkgtest/testing/amd64/d/dgit/1382882/log.gz [...] > Looking at the test log did not immediately suggest a cause to me. > But it is probably much easier for me to (at least initially) > investigate this, since I will hopefully understand what the test case > was trying to do. Very much appreciated. [...] > To the git maintainers: please let me know if this update was urgent > so that I can prioritise appropriately. The main source of urgency is that this could help shed light on whether the rewrite of "git rebase" in C is not ready for prime time, so we can make an appropriate choice for the imminent Git 2.20 release about whether to use it by default. In other words, we're trying to decide whether to apply https://public-inbox.org/git/xmqq36roz7ve.fsf...@gitster-ct.c.googlers.com/. The test log says + git reflog + egrep 'debrebase new-upstream.*checkout' + test 1 = 0 + t-report-failure + set +x TEST FAILED cwd: /tmp/autopkgtest-lxc.q9szjzqq/downtmp/autopkgtest_tmp/example funcs: t-report-failure main lines: 1 0 files: tests/lib /tmp/autopkgtest-lxc.q9szjzqq/downtmp/build.sQK/src/tests/tests/gdr-newupstream gzip: warning: GZIP environment variable is deprecated; use an alias or script 81.2% autopkgtest [04:30:20]: test gdr-newupstream: ---] autopkgtest [04:30:20]: test gdr-newupstream: - - - - - - - - - - results - - - - - - - - - - gdr-newupstream FAIL non-zero exit status 16 The relevant part of the test script says t-gdr-good laundered git reflog | egrep 'debrebase new-upstream.*checkout' which I admit is a bit inscrutable to me. So a reduced testcase would be very welcome. Thanks, sincerely, Jonathan
Bug#908994: diffoscope: extract information from OpenPGP keys and signatures
On Mon, 2018-11-26 at 16:31 -0500, Chris Lamb wrote: > I added support for pgpdump in diffoscope version 82 via #859034. > Had you seen this? I hadn't noticed that yet, thanks for that. > I do note that your bug mentions some other tools (name gpg --list- > packets, hot dump and hot dearmor) however. Are there any of these you > would suggest we prioritise? I don't recall if any of the tools are more useful than the others but playing around just now I see only minor differences. I'd suggest prioritising supporting gpg because that is more likely to be already installed on more systems than pgpdump is. The hopenpgp-tools package is more obscure and less likely to be installed as it is Haskell so might not be available on some platforms that gpg/pgpdump are and it also seems a bit less capable than gpg/pgpdump so maybe ignore it. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#908992: diffoscope: side-by-side diff for terminal output
On Mon, 2018-11-26 at 16:58 -0500, Chris Lamb wrote: > I think this could be made to work. > As a demo, I just knocked together: > ... which resulted in the attached. Looks good. > One difficulty however will be in passing in a sane value of `cols` to > ConsoleDiff; not because it's difficult to obtain (see icdiff.py for > this terminal foo) but rather we need to subtract 2 or 3 for each > indentation/recursion level and we may not know that at the time we > run icdiff. Hmm, I would have thought the recursion level could be determined at the time the data is being extracted from the data structure? How is the recursion level determined right now? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#913539: typo in gsl-randist(1)
On 12 November 2018 at 10:19, Dirk Eddelbuettel wrote:
|
| On 12 November 2018 at 01:40, Barak A. Pearlmutter wrote:
| | Package: gsl-bin
| | Version: 2.5+dfsg-5
| |
| | Thanks for maintaining gsl; I use it all the time.
|
| My pleasure, and "anytime" -- I get a lot of use out of your packaging too :)
|
| | The gsl-randist(1) page suggest the sample command
| |
| | gsl-randist 0 1 cauchy 30 | gsl-histogram -100 100 200
| | > histogram.dat
| |
| | which has a typo: gsl-histogram interprets the -100 as an option. It should
read
| |
| | gsl-randist 0 1 cauchy 30 | gsl-histogram -- -100 100
| | 200 > histogram.dat
| |
| | or even
| |
| | gsl-randist 0 10 cauchy 30 | gsl-histogram -- -100 100
| | 200 | awk '{print $1, $3 ; print $2, $3}' | graph -T X
|
| Thanks -- seems plainly upstream. I have another issue for them (they named a
| struct element 'class' or something like that upsetting C++ use) and maybe
| Patrick can fix that for the next release.
Sorry, took a moment but this is now applied -- and had been reported upstream.
Thanks again, Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#912341: libgsl23: operator delete clash when using gsl_filter.h
On 30 October 2018 at 19:47, Dirk Eddelbuettel wrote: | | Hi, | | On 31 October 2018 at 00:15, D Haley wrote: | | Hi, | | | | I've attached a patch that might suit - | | Thanks for that. | | | however I am a bit unsure about modifying a non-leaf package, such as GSL. | | "Yes but" this is new-ish functionality in 2.5 only. So few depends on this. | | I'd say if 'make; make check' passes it is worth a try. Could you try 'make | check' on your end? | | | Most of the references to delete were of the form xxx_delete, which are | | not relevant to the current problem (as this does not conflict with the | | C++ operator). The only externally visible (in header files) clash that | | I could find was in the gsl_movstat.h file. This is referenced in a few | | files in movstat/ internally, and needed to be adjusted. | | I saw just that when I glanced at it, but that was while I was at work and | preoccupied with a million other things. | | It is clearly just a field in a struct we can renamed but ... someone | somewhere must be referencing the struct, no? | | We can also get Patrick involved who is ... pretty much carrying upstream GNU | GSL by himself from what I can tell. | | | This fixes the problem for me, and can be used as a patch in the debian | | gsl git, c3eee7ef (as a file in debian/patches/). I've rebuilt the .deb | | on a VM, and made a few quick tests using g++. | | It's a good start so thanks for that! Sorry for taking so long on this -- I just uploaded a new version with the corresponding upstream patch. Thanks again for reporting this. Cheers, Dirk | Dirk | | -- | http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#913146: ovmf debug
hey Bastian! What should this look like? Maybe an ovmf-debug package that provides a /usr/share/ovmf/OVMF-debug.fd? Or would it need to use the same paths as the ovmf package and therefore conflict with it? -dann
Bug#914758: linux-image-4.18.0-2-amd64: setting elevator=none does not change io scheduler
Control: tag -1 upstream
Control: retitle -1 Missing equivalent of elevator kernel parameter for blk-mq
On Mon, 2018-11-26 at 18:10 -0600, Matt Zagrabelny wrote:
> Package: src:linux
> Version: 4.18.10-2
> Severity: normal
>
> Greetings!
>
> Thank you for your contribution to Debian. It is appreciated!
>
> I am running:
>
> linux-image-4.18.0-2-amd64 4.18.10-2+b1
>
> and attempting to set the IO scheduler.
>
> Looking at the current scheduler:
>
> # cat /sys/block/sda/queue/scheduler
> [mq-deadline] none
This is a device implemented using the "blk-mq" API, which was
introduced a few years ago but has only recently come to be used by
most block devices.
[...]
> I just don't know why the elevator parameter isn't working. According to the
> kernel documentation for 4.18:
>
> grep -A3 elevator
> /usr/src/linux-source-4.18/Documentation/admin-guide/kernel-parameters.txt
> elevator= [IOSCHED]
> Format: {"cfq" | "deadline" | "noop"}
> See Documentation/block/cfq-iosched.txt and
> Documentation/block/deadline-iosched.txt for details.
[...]
This is correct, but incomplete. The "elevator" kernel parameter only
controls the default schedulers for the old "blk-rq" device API.
Unfortunately, because of the differences between the old and new APIs
it was also necessary to introduce a new set of schedulers. There
isn't (yet) a kernel parameter to choose the default for blk-mq
devices.
Ben.
--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
signature.asc
Description: This is a digitally signed message part
Bug#547292: Need help dealing with this l10n bug?
Hello, comix package upstream is MIA long ago, and a new community version call mcomix is formed and well maintained, so all work moved to mcomix. we have concern to orphan or remove comix later. On Mon, Nov 26, 2018 at 12:33 AM Helge Kreutzmann wrote: > Hello Emfox, > this German l10n bug is open for more than 9 years. Do you need help > dealing with it? I could provide a NMU, but of course a maintainer > upload is (much) preferred. > > Greetings > > Helge > -- > Dr. Helge Kreutzmann deb...@helgefjell.de >Dipl.-Phys. > http://www.helgefjell.de/debian.php > 64bit GNU powered gpg signed mail preferred >Help keep free software "libre": http://www.ffii.de/ > -- Emfox Zhou GnuPG Public Key: 0x1DEB
Bug#914762: r-cran-mclust: autopkgtest regression
Source: r-cran-mclust
Version: 5.4.2-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 5.4.2-1, r-cran-mclust fails its own autopkgtests
[1] with the following error:
autopkgtest [21:18:08]: test vignette: [---
BEGIN VIGNETTE vignettes/mclust.Rmd
Warning in engine$weave(file, quiet = quiet, encoding = encoding, ...) :
The vignette engine knitr::rmarkdown is not available, because the
rmarkdown package is not installed. Please install it.
Package 'mclust' version 5.4.2
Type 'citation("mclust")' for citing this R package in publications.
Quitting from lines 106-120
(/tmp/autopkgtest-lxc.dtg_wxgz/downtmp/build.muH/src/vignettes/mclust.Rmd)
Error in find.package(package, lib.loc, verbose = verbose) :
there is no package called 'MASS'
Calls: ... withVisible -> eval -> eval -> data -> find.package
Execution halted
autopkgtest [21:18:23]: test vignette: ---]
autopkgtest [21:18:23]: test vignette: - - - - - - - - - - results -
- - - - - - - - -
vignette FAIL non-zero exit status 1
Regards
Graham
[1] https://ci.debian.net/packages/r/r-cran-mclust/testing/amd64/
Bug#914761: mysql-workbench: fails to build
On Tuesday, 27 November 2018 11:55:41 AM AEDT Jeremy Bicha wrote: > mysql-workbench fails to build from source, as seen in Ubuntu and in > reproducible-builds. I'm not sure what could be done about it at this point... :( See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910052 -- Cheers, Dmitry Smirnov. --- If liberty means anything at all, it means the right to tell people what they do not want to hear. -- George Orwell signature.asc Description: This is a digitally signed message part.
Bug#865975: #865975 docker.io breaks (bridged) network for VMs
This bug is basically a duplicate of #903635. On Tuesday, 27 November 2018 9:00:20 AM AEDT Marvin Renich wrote: > HUH??? Since when is it okay for software that is not advertised as > firewall software to modify the sysadmin's implicit or explicit iptables > setup for IP packets completely unrelated to said software? > > I understand that this is a non-trivial problem because of the history > behind /proc/sys/net/ipv4/ip_forward and the FORWARD chain, but docker > can and needs to do better. My first approximation would be to only > change the policy for FORWARD if ip_forward was 0 before docker added > its own iptables rules. This will probably work 99.9% of the time. > > The current behavior appears to break other software 100% of the time > if that software relies on ip_forward being 1 and the FORWARD chain > being in its default state. Situation is unfortunate and upstream does not care enough. They probably want Docker users to use Docker exclusively without any other software on the host. I very much dislike this approach but that's Docker for you... :( About 6 months ago I've moved all my application containers from Docker to "rkt" and I couldn't be happier. Although still immature, in the future libpod/podman will likely become a worthy Docker successor. > I'm raising this back to critical (makes unrelated software on the > system break), as I cannot fathom how this could not be broken for > anyone using KVM with a bridging network interface unless they have > found one of the workarounds given in this thread (i.e. the > /etc/docker/daemon.json modification, or manually modifying the FORWARD > chain). I'm lowering severity back to "important". You are not wrong that Docker is hostile to other applications but I think many users would agree that we need Docker in "testing" and upcoming Debian release despite of this problem. -- All the best, Dmitry Smirnov. --- Truth never damages a cause that is just. -- Mahatma Gandhi signature.asc Description: This is a digitally signed message part.
Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs
On Sun, Nov 25, 2018 at 12:08:03AM +0100, Vincent Lefevre wrote: > On 2018-11-21 19:02:33 -0500, Thomas Dickey wrote: > > I don't see how this could happen unless you combined the action with > > some pasting (such as bracketed-paste). > > I paste nothing. > > > xterm's formatting of the string is shell-agnostic, and the exec'd > > "browser" command would only depend on what the formatted URL looked > > like. > > > > In either case, steps-to-reproduce seem obscure. > > With zsh, one can reproduce the issue with: > > $ xterm -e zsh -f If you added a "-l" option, that would turn on xterm's logging feature xterm -l -e zsh -f which could be interesting. But the bug report deals with programs run from xterm, which the shell wouldn't see -- unless it's reading xterm's output in some way. > > then in the xterm: > > zira% bindkey -e Perhaps "zira%" is your shell prompt. What does "bindkey -e" have to do with exec-formatted? -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature
Bug#914395: [pkg-gnupg-maint] Bug#914395: Bug#914395: dirmngr log
On Mon 2018-11-26 08:42:20 +0100, Werner Koch wrote: > On Sun, 25 Nov 2018 22:22, csm...@debian.org said: >> It seems it needs the SRV record and fails wrong without it. >> Checking on the same system looking up that SRV record I get the >> expected NXDOMAIN error. > > That seems to be a Debian specific problem; with a dirmngr started by > the gpg command, I get this with master (and pretty sure also with 2.2.11): I don't see the problem on my local network when using 2.2.11-1 (that is, including the debian-specific patches, and using dirmngr as launched by the local user's systemd instance). I wouldn't be surprised if the problems about the specific network are the cause here. ~/.gnupg/dirmngr.conf contains only: debug ipc,dns,network And I ran the following two commands: systemctl --user stop dirmngr gpg-connect-agent --dirmngr 'KEYSERVER --clear hkp://keyring.debian.org' 'KS_GET -- 0xDF50FEA5' /bye To get the logs, i ran: journalctl --since -10min --user-unit dirmngr.service Nov 26 16:24:04 testhost systemd[1509]: Started GnuPG network certificate management daemon. Nov 26 16:24:04 testhost dirmngr[32374]: dirmngr[32374]: enabled debug flags: ipc dns network Nov 26 16:24:04 testhost dirmngr[32374]: permanently loaded certificates: 129 Nov 26 16:24:04 testhost dirmngr[32374]: runtime cached certificates: 0 Nov 26 16:24:04 testhost dirmngr[32374]:trusted certificates: 129 (128,0,0,1) Nov 26 16:24:04 testhost dirmngr[32374]: handler for fd 5 started Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 -> # Home: /home/dkg/.gnupg Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 -> # Config: /home/dkg/.gnupg/dirmngr.conf Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 -> OK Dirmngr 2.2.11 at your service Nov 26 16:24:04 testhost dirmngr[32374]: connection from process 32373 (1000:1000) Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 <- KEYSERVER --clear hkp://keyring.debian.org Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 -> OK Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 <- KS_GET -- 0xDF50FEA5 Nov 26 16:24:04 testhost dirmngr[32374]: DBG: dns: libdns initialized (tor mode) Nov 26 16:24:05 testhost dirmngr[32374]: DBG: dns: getsrv(_pgpkey-http._tcp.keyring.debian.org) -> 0 records Nov 26 16:24:05 testhost dirmngr[32374]: DBG: dns: libdns initialized (tor mode) Nov 26 16:24:06 testhost dirmngr[32374]: DBG: dns: resolve_dns_name(keyring.debian.org): Success Nov 26 16:24:06 testhost dirmngr[32374]: resolve_dns_addr for 'keyring.debian.org': 'keyring.debian.org' [already known] Nov 26 16:24:06 testhost dirmngr[32374]: number of system provided CAs: 128 Nov 26 16:24:06 testhost dirmngr[32374]: DBG: Using TLS library: GNUTLS 3.5.19 Nov 26 16:24:06 testhost dirmngr[32374]: DBG: http.c:connect_server: trying name='keyring.debian.org' port=11371 Nov 26 16:24:07 testhost dirmngr[32374]: DBG: dns: resolve_dns_name(keyring.debian.org): Success Nov 26 16:24:08 testhost dirmngr[32374]: DBG: http.c:1877:socket_new: object 0x7f2b0c3490a0 for fd 6 created Nov 26 16:24:08 testhost dirmngr[32374]: DBG: http.c:request: Nov 26 16:24:08 testhost dirmngr[32374]: DBG: >> GET /pks/lookup?op=get=mr=0xDF50FEA5 HTTP/1.0\r\n Nov 26 16:24:08 testhost dirmngr[32374]: DBG: >> Host: keyring.debian.org:11371\r\n Nov 26 16:24:08 testhost dirmngr[32374]: DBG: http.c:request-header: Nov 26 16:24:08 testhost dirmngr[32374]: DBG: >> \r\n Nov 26 16:24:08 testhost dirmngr[32374]: DBG: chan_5 -> S PROGRESS tick ? 0 0 Nov 26 16:24:08 testhost dirmngr[32374]: DBG: http.c:response: Nov 26 16:24:08 testhost dirmngr[32374]: DBG: >> HTTP/1.1 200 OK\r\n Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Date: Mon, 26 Nov 2018 21:24:08 GMT' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Server: Apache' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'X-Content-Type-Options: nosniff' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'X-Frame-Options: sameorigin' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Referrer-Policy: no-referrer' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'X-Xss-Protection: 1' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Vary: Accept-Encoding' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'X-Clacks-Overhead: GNU Terry Pratchett' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Connection: close' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Content-Type: text/html; charset=ISO-8859-1' Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: '' Nov 26 16:24:08 testhost dirmngr[32374]: DBG: chan_5 -> S SOURCE http://keyring.debian.org:11371 Nov 26 16:24:08 testhost dirmngr[32374]: DBG: (20847 bytes sent via D lines not shown) Nov 26 16:24:08 testhost dirmngr[32374]: DBG: chan_5 -> OK Nov 26 16:24:08 testhost dirmngr[32374]: DBG: chan_5 <- [eof] Nov 26 16:24:08 testhost dirmngr[32374]: handler for fd 5 terminated So i think this shows that it doesn't appear to be
Bug#914505: Acknowledgement (linux: reference to netfilter chain not removed on rule replacement, subsequently system hangs)
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=201791
Bug#914761: mysql-workbench: fails to build
Source: mysql-workbench Version: 6.3.10+dfsg-3 Severity: serious Tags: ftbfs mysql-workbench fails to build from source, as seen in Ubuntu and in reproducible-builds. https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mysql-workbench.html (Look at the test history) https://launchpad.net/ubuntu/+source/mysql-workbench/6.3.10+dfsg-3ubuntu2 Thanks, Jeremy Bicha
Bug#914760: simple-scan: Please package 3.30.2
Source: simple-scan Version: 3.30.1.1-1 Severity: wishlist Please update simple-scan to 3.30.2. For most GNOME projects, the .2 release is the last scheduled release for each version series. Please also see my proposed patches at https://bugs.debian.org/904168 I would be happy to sponsor this update for you if you include my patches. :) simple-scan shows up at https://www.0d.be/debian/debian-gnome-3.30-status.html so it would be nice to get that chart as green as possible. Thanks, Jeremy Bicha
Bug#628908: mc: Fails on looooong paths in posix tar archives
Package: mc Version: 3:4.8.21-1 Followup-For: Bug #628908 I am not sure if this is the same problem, but I have an archive 72MB in size (~2GB before compression), compressed into tar.zst with about 1.1M files (0 - 100 bytes each) and about 120 characters in path of each file. Listing content is fast: $ time zstdcat ../gnuplot-fuzzing-instrumented-snapshot-2018-11-27T01\:12.tar.zst | tar tf - | wc -l 1139010 real0m4.619s user0m3.935s sys 0m4.387s $ With metadataa: $ time zstdcat ../gnuplot-fuzzing-instrumented-snapshot-2018-11-27T01\:12.tar.zst | tar tvf - | wc -l 1139010 real0m10.418s user0m6.176s sys 0m8.681s $ Via index file: $ time zstdcat ../gnuplot-fuzzing-instrumented-snapshot-2018-11-27T01\:12.tar.zst | tar -t -v --index-file=/tmp/zlk -f - | wc -l 0 real0m9.234s user0m5.837s sys 0m5.323s $ wc -l /tmp/zlk 1139010 /tmp/zlk $ Yes, mc is stuck for 20 minutes when trying to enter the same archive. mc is using 100% CPU (one thread). tar or zstd processes nowhere to be found tho. strace -p `pidof mc` is showing enormous amount of lseeks and small reads: lseek(9, 512, SEEK_CUR) = 1075074048 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075075072 read(9, "././@LongLink\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075077120 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075078144 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075079168 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075080192 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075081216 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075082240 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075083264 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075084288 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075085312 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075086336 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075087360 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075088384 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075089408 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075090432 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075091456 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075092480 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075093504 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075094528 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075095552 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075096576 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075097600 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075098624 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075099648 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075100672 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075101696 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075102720 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075103744 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075104768 read(9, "././@LongLink\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075106816 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) = 1075107840 read(9, "gnuplot-fuzzing-instrumented/out"..., 512) = 512 lseek(9, 512, SEEK_CUR) =
Bug#914759: /usr/bin/zstd: zstdcat confusing error message on incorrect filename
Package: zstd Version: 1.3.5+dfsg-1 Severity: normal File: /usr/bin/zstd user@debian:~/mkd$ zstdcat abc.tar.zst | tar xf - zstd: abc.tar.zst is not a regular file -- ignored tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors user@debian:~/mkd$ ls abc.tar.zst ls: cannot access 'abc.tar.zst': No such file or directory user@debian:~/mkd$ stat abc.tar.zst stat: cannot stat 'abc.tar.zst': No such file or directory user@debian:~/mkd$ The error message isn't helpful, because it suggest the filename is correct but it is not a file, and maybe a directory or a block device or something. Best regards, Witold -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zstd depends on: ii libc6 2.27-8 ii libgcc1 1:8.2.0-9 ii liblz4-11.8.2-1 ii liblzma55.2.2-1.3 ii libstdc++6 8.2.0-9 ii zlib1g 1:1.2.11.dfsg-1 zstd recommends no packages. zstd suggests no packages. -- no debconf information
Bug#891414: enable qt5 front-end
No worries and no hurry, have the same problem with audacious - the Qt version has improved a lot, but i guess it is not prime time ready. So - patience is a virtue. Cheers Alf signature.asc Description: OpenPGP digital signature
Bug#914758: linux-image-4.18.0-2-amd64: setting elevator=none does not change io scheduler
Package: src:linux
Version: 4.18.10-2
Severity: normal
Greetings!
Thank you for your contribution to Debian. It is appreciated!
I am running:
linux-image-4.18.0-2-amd64 4.18.10-2+b1
and attempting to set the IO scheduler.
Looking at the current scheduler:
# cat /sys/block/sda/queue/scheduler
[mq-deadline] none
However my kernel command line:
# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.18.0-2-amd64
root=UUID=1965daa6-aa4c-4c02-8402-589867e32517 ro elevator=none quiet
I can set the scheduler via sysfs:
# echo none > /sys/block/sda/queue/scheduler
# cat /sys/block/sda/queue/scheduler
[none] mq-deadline
I just don't know why the elevator parameter isn't working. According to the
kernel documentation for 4.18:
grep -A3 elevator
/usr/src/linux-source-4.18/Documentation/admin-guide/kernel-parameters.txt
elevator= [IOSCHED]
Format: {"cfq" | "deadline" | "noop"}
See Documentation/block/cfq-iosched.txt and
Documentation/block/deadline-iosched.txt for details.
It appears that I should pass "noop" to the elevator parameter. However, the
same results occur:
# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.18.0-2-amd64
root=UUID=1965daa6-aa4c-4c02-8402-589867e32517 ro elevator=noop quiet
# cat /sys/block/sda/queue/scheduler
[mq-deadline] none
If I look at the kernel ring buffer I see some evidence that I perhaps should
be using the "noop" scheduler:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.18.0-2-amd64
root=UUID=1965daa6-aa4c-4c02-8402-589867e32517 ro elevator=noop quiet
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.18.0-2-amd64
root=UUID=1965daa6-aa4c-4c02-8402-589867e32517 ro elevator=noop quiet
[0.432773] Block layer SCSI generic (bsg) driver version 0.4 loaded (major
248)
[0.432794] io scheduler noop registered (default)
[0.432795] io scheduler deadline registered
[0.432825] io scheduler cfq registered
[0.432826] io scheduler mq-deadline registered
I see the same io scheduler registerd when I use "elevator=none", too. That is
"none" is not registered, but "noop" is.
I don't see anything in my udev configs that would be setting the scheduler.
This is a VM system.
Thanks for any help!
-- Package-specific info:
** Kernel log: boot messages should be attached
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-image-4.18.0-2-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.132
ii kmod25-1
ii linux-base 4.5
Versions of packages linux-image-4.18.0-2-amd64 recommends:
ii apparmor 2.13.1-3+b1
ii firmware-linux-free 3.4
ii irqbalance 1.5.0-0.1
Versions of packages linux-image-4.18.0-2-amd64 suggests:
pn debian-kernel-handbook
ii extlinux3:6.04~git20171011.af7e95c3+dfsg1-5
ii grub-pc 2.02+dfsg1-8
pn linux-doc-4.18
Versions of packages linux-image-4.18.0-2-amd64 is related to:
ii firmware-amd-graphics 20180825+dfsg-1
pn firmware-atheros
pn firmware-bnx2
pn firmware-bnx2x
pn firmware-brcm80211
pn firmware-cavium
pn firmware-intel-sound
pn firmware-intelwimax
pn firmware-ipw2x00
pn firmware-ivtv
pn firmware-iwlwifi
pn firmware-libertas
ii firmware-linux-nonfree20180825+dfsg-1
ii firmware-misc-nonfree 20180825+dfsg-1
pn firmware-myricom
pn firmware-netxen
pn firmware-qlogic
pn firmware-realtek
pn firmware-samsung
pn firmware-siano
pn firmware-ti-connectivity
pn xen-hypervisor
-- no debconf information
Bug#914757: Mouse Dell MS819 didn't work
Package: linux Version: 4.9.130-2 Severity: normal The mouse Dell MS819 didn't work (mouse part and fingerprint part) on Linux Debian but works perfectly on Windows 10. Dell MS819 is a mouse with fingerprint reader. The classic part of mouse (cursor and buttons) should work out of the box on same way another mouse. [535546.361651] usb 1-1.3.1: New USB device found, idVendor=413c, idProduct=3021 [535546.361654] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [535546.361657] usb 1-1.3.1: Product: MS819 Dell Wired Mouse With Fingerprint Reader [535546.361659] usb 1-1.3.1: Manufacturer: Chicony [535546.364911] input: Chicony MS819 Dell Wired Mouse With Fingerprint Reader as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/1-1.3.1/1- 1.3.1:1.0/0003:413C:3021.000F/input/input16 [535546.365315] hid-generic 0003:413C:3021.000F: input,hidraw4: USB HID v1.10 Mouse [Chicony MS819 Dell Wired Mouse With Fingerprint Reader] on usb-:00:1a.0-1.3.1/input0 [535546.370282] hid-generic 0003:413C:3021.0010: hiddev0,hidraw5: USB HID v1.10 Device [Chicony MS819 Dell Wired Mouse With Fingerprint Reader] on usb-:00:1a.0-1.3.1/input1 Nothing have been for device 413c:3021 with Google. 413c:3021 didn't exist in http://www.linux-usb.org/usb.ids https://wiki.debian.org/fr/Smartcards list 413c:2100 and 413c:2101. -- Nicolas DEFFAYET
Bug#914677: [Pkg-electronics-devel] Bug#914677: libmawk fails it's tests on s390x
Matthias Klose writes: > libmawk fails it's tests on s390x (also different failures on some non-release > architectures). Thanks, I've let upstream know. Bdale signature.asc Description: PGP signature
Bug#914750: High cpu usage
On Tue, Nov 27, 2018 at 12:15:51AM +0100, Yuri D'Elia wrote: > On Mon, Nov 26 2018, Bill Allombert wrote: > > On my laptop with 49 days uptime (w/ lot of suspend-to-disk), > > consolation only used 30m and I always use the console. > > Random question: could it be that it's due to the fact that I barely use > the console at all? > > > What kind of pointing devices do you have ? > > This is a lenovo yoga 3rd gen. Integrated touchpad, touchscreen (that I > disabled via `xinput float`), the red-finger-joystick thingy, it has a > built-in wacom digitizer (that I do use - but not today) and generally > an additional usb mouse plugged too. > > So... yeah. There are some pointing devices. As far as I know, libinput does not provide a way to filter events, (like X does) so consolation still need to read all the events even those it will ignore. > > We would need to use some profiling to see how the time is spend. > > (If it is spend in libinput, then this might not be fixable in > > consolation). > > Any specific tool you want me to run? gprof with default arguments would > be fine? This is the idea. Note that currently gprof is busted unless you rebuild consolation with -no-pie. See #854704. Cheers, -- Bill. Imagine a large red swirl here.
Bug#550676: [Bash-completion-devel] Bug#550676: Bug#550676: please make bash-completion falling back to path completion if nothing else is found
On Sat, 19 Jul 2014 16:33:07 +0300 Ville Skyttä wrote: > On Fri, Jul 18, 2014 at 10:14 PM, David Paleino wrote: > > > > Just use Alt-/, which is the default bash shortcut for "complete on all > > files". > > ...or try the COMP_FILEDIR_FALLBACK environment variable: > http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=blob;f=doc/bash_completion.txt;h=c6e53d4;hb=HEAD#l33 Current sources for this can be found at the new repository [1], but I think that for the suggestion to actually work, it requires a fix, which I submitted upstream as pull request #260 [2]. I'll wait for comments before closing this bug report. [1] https://github.com/scop/bash-completion/blob/78aa9236df56016ded1185f877b0ba1c656fc439/doc/bash_completion.txt#L40-L43 [2] https://github.com/scop/bash-completion/pull/260
Bug#615134: fixed in bash-completion 1:1.90-1
Hi, Helmut Grohne, I noticed that you reopened this bug report and I suppose you did so because you think that the bug is only partially fixed (as suggested in message #25 [1]). I just submitted a patch upstream [2] that, to the best of my knowledge, fixes the rest of the problem, but since I'm not a mutt user, could you please confirm that it also works for you? [1] https://bugs.debian.org/615134#25 [2] https://github.com/scop/bash-completion/pull/261
Bug#914729: texlive-latex-recommended: fancyvrb/xcolor "Option clash for package xcolor"
On Mon, 26 Nov 2018, Hilmar Preuße wrote: > @Norbert: do you agree here? Completely Order of package loading is important and documents need adjustments with new versions of support packages, as in this case. This has always been like this, and there is unfortunately no way around it (at least not in LaTeX2e, LaTeX3 might be a bit more resilient to that). Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#914756: ITP: golang-github-influxdata-platform -- InfluxDB 2.0: The community version of the InfluxData Platform for Time Series
Package: wnpp Severity: wishlist Owner: Alexandre Viau * Package name: golang-github-influxdata-platform Version : 0.0~git20181126.a123b7b0d-1 Upstream Author : InfluxData * URL : https://github.com/influxdata/platform * License : TODO Programming Lang: Go Description : InfluxDB 2.0: The community version of the InfluxData Platform for Time Series This is a new dependency for influxdb 1.7 (yes! influxdb 1.7 depends on influxdb 2.0!) Cheers, -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#914755: /etc/default/dnsmasq ENABLED=0 does not work
Package: dnsmasq Version: 2.79-1 Severity: normal Setting ENABLED=0 in /etc/default/dnsmasq does not prevent dnsmasq from starting at boot. It appears that dnsmasq will start at boot regardless of what ENABLED is set to. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dnsmasq depends on: ii dnsmasq-base [dnsmasq-base] 2.79-1 ii init-system-helpers 1.55 ii lsb-base 9.20170808 ii netbase 5.4 dnsmasq recommends no packages. Versions of packages dnsmasq suggests: ii resolvconf 1.79 -- Configuration Files: /etc/default/dnsmasq changed [not included] /etc/dnsmasq.conf changed [not included] -- no debconf information
Bug#850945: ant: exec task fails with error 127 on kfreebsd-i386
Le 11/01/2017 à 21:37, Gilles Filippini a écrit : > I've just submitted #851053 against openjdk-8 on kfreebsd-*. #851053 has been fixed last year. I guess we can closed this bug now?
Bug#912737: Bug#912737: openssl: SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed
Hi Sorry for the late response. I believe issue was on lenovo.com's side and it's load balancing. On one system, on an other network, I was able to correctly download the file and saw it redirecting to a specific ip. On the system where the download didn't work, it was redirecting to another ip. We should close this issue. Thanks Julien On 11/26/18 11:21 PM, Sebastian Andrzej Siewior wrote: On 2018-11-04 15:10:42 [+0100], Julien Lecomte wrote: I'll move the issue directly to ubiquiti to figure out what is going wrong. should we just close on the Debian side or did you gather additional information? Thanks Julien Sebastian
Bug#914750: High cpu usage
On Mon, Nov 26 2018, Bill Allombert wrote: > On my laptop with 49 days uptime (w/ lot of suspend-to-disk), > consolation only used 30m and I always use the console. Random question: could it be that it's due to the fact that I barely use the console at all? > What kind of pointing devices do you have ? This is a lenovo yoga 3rd gen. Integrated touchpad, touchscreen (that I disabled via `xinput float`), the red-finger-joystick thingy, it has a built-in wacom digitizer (that I do use - but not today) and generally an additional usb mouse plugged too. So... yeah. There are some pointing devices. > We would need to use some profiling to see how the time is spend. > (If it is spend in libinput, then this might not be fixable in > consolation). Any specific tool you want me to run? gprof with default arguments would be fine?
Bug#873065: Processed: reassign 873065 to libssl1.1
control: reassign -1 postfix 3.2.2-1 On 2018-01-29 12:47:11 [-0500], Scott Kitterman wrote: > On Monday, January 29, 2018 05:53:47 PM Kurt Roeckx wrote: > > I'm not sure why you've reassign it. I think that postfix really > > should do that, just like it enables anonymous ciphers. > > > > Upstream might actually already have changes for this. > > > > > > Kurt > > OK. Feel free to reassign it back. I'll check. reassign back as requested. > Scott K Sebastian
Bug#914754: autosuspend: Typos in package description
Package: autosuspend Severity: minor Dear Maintainer, I noticed a couple of typos in the autosuspend package description while translating it on the DDTSS. Indeed, "none of theme" should be "none of _them_" and I believe "in case of future wake up time" should be "in case _the_ future wake up time". Thanks a lot for maintaining and developing autosuspend! Cheers, Thomas -- System Information: Debian Release: 9.6 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#912087: reassign to systemd #912087 | openssh-server: Slow startup after the upgrade to 7.9p1
control: reassign -1 systemd 239-13 I hereby reassign the bug to systemd. The problem is that OpenSSL is now using getrandom() for entropy which is not (yet) ready and therefore OpenSSH needs longer for startup by simply waiting for entropy. Theodore Y. Ts'o suggested adding hw-rng to KVM/virt setups [0]. Everything else should work just "fine". Either way there is nothing OpenSSL wise that can be done. A similar issue [1] has been reported once GnuTLS which to getrandom(). Systemd wise there is https://github.com/systemd/systemd/issues/4271 https://github.com/systemd/systemd/pull/10621 where people want systemd to systemd to credit entropy. I'm not much a fan of that but that is a different story. [0] https://bugs.debian.org/912087#118 [1] https://bugs.debian.org/837597 Sebastian
Bug#914748: ant: Fail when installed along with usrmerge and invoked via /bin/ant
Control: severity -1 normal Le 26/11/2018 à 23:38, Gilles Filippini a écrit : > To me this is RC because it makes opencv FTBFS on some official buildd > machines. No opinion at all about usrmerge. My understanding is that usrmerge is optional at this point and the builders are going to be reverted to non usrmerged. For this reason I'm lowering the severity. > In any case the scriplet replaced by the patch is buggy. > How about pushing this patch upstream? The patch looks good to me, thanks a lot. Do you know if readlink is commonly available on other Unix platforms? Emmanuel Bourg
Bug#914703: apt-listbugs: [INTL:de] Updated German translation
On Mon, 26 Nov 2018 14:39:27 +0100 Chris Leick wrote: > Hi, > > please find attached the newest German translation. Hello Chris, thanks for your fast update! I will soon push the new .po file to the public git repository; it will be included in the next upload. Your contribution is greatly appreciated! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpyrE6I8HdQ1.pgp Description: PGP signature
Bug#914750: High cpu usage
On Mon, Nov 26, 2018 at 11:33:08PM +0100, Yuri D'Elia wrote: > Package: consolation > Severity: normal > Version: 0.0.6-2 > > I've been running consolation for quite a while but I noticed recently > it accumulates a considerable amount of CPU time over the course of a > day. > > On a system with a ~2 hours uptime, sorting by cpu time, I have Xorg > (40m), pulseaudio (20m) and consolation (15m)! which is taking more CPU > time than my window manager or systemd... > > And I never switched to the console since boot. Hello Yuri, sorry to hear that. On my laptop with 49 days uptime (w/ lot of suspend-to-disk), consolation only used 30m and I always use the console. What kind of pointing devices do you have ? We would need to use some profiling to see how the time is spend. (If it is spend in libinput, then this might not be fixable in consolation). Cheers, -- Bill. Imagine a large red swirl here.
Bug#914753: needrestart: Please skip check when the system is shutting down already
Package: needrestart Severity: wishlist Version: 3.3-2 Hi, Unattended-upgrades has a mode where it installs upgrades during shutdown where discovering the services in need of a restart is not particularly useful but the discovery itself slows down the shutdown. Please consider detecting if the system goes down already per systemd and also please check for logind's PreparingForShutdown state [2]. Thanks, Balint [1] https://github.com/mvo5/unattended-upgrades/blob/master/debian/NEWS [2] https://www.freedesktop.org/wiki/Software/systemd/inhibit/ -- Balint Reczey Ubuntu & Debian Developer
Bug#891414: enable qt5 front-end
Hi, don't worry, although I just uploaded gImageReader 3.3.0 without qt5 front-end this does not mean that I will not add it with the next upload. I try to upload a qt5 enabled version later this week (but I have to contact my former sponsor and it has to pass the NEW queue). Best, Philip signature.asc Description: OpenPGP digital signature
Bug#914744: gdb ftbfs with Python 3.7
On Monday, November 26 2018, Matthias Klose wrote: > gdb ftbfs with Python 3.7. upstream version 8.2 build fine. > > x86_64-linux-gnu-g++ -x c++ -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -I. > -I/<>/gdb -I/<>/gdb/common > -I/<>/gdb/config -DLOCALEDIR="\"/usr/share/locale\"" > -DHAVE_CONFIG_H -I/<>/gdb/../include/opcode > -I/<>/gdb/../opcodes/.. -I../bfd -I/<>/gdb/../bfd > -I/<>/gdb/../include -I../libdecnumber > -I/<>/gdb/../libdecnumber -I/<>/gdb/gnulib/import > -Ibuild-gnulib/import -DTUI=1 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > -I/usr/include/python3.7m -I/usr/include/python3.7m -Wall -Wpointer-arith > -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts > -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable > -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized > -Wformat-nonliteral -c -o elfread.o -MT elfread.o -MMD -MP -MF > ./.deps/elfread.Tpo /<>/gdb/elfread.c > /<>/gdb/python/python.c: In function 'bool > do_start_initialization()': > /<>/gdb/python/python.c:1710:45: error: too few arguments to > function 'int _PyImport_FixupBuiltin(PyObject*, const char*, PyObject*)' >_PyImport_FixupBuiltin (gdb_module, "_gdb"); > ^ > In file included from /usr/include/python3.7m/Python.h:126, > from /<>/gdb/python/python-internal.h:100, > from /<>/gdb/python/python.c:94: > /usr/include/python3.7m/import.h:112:17: note: declared here > PyAPI_FUNC(int) _PyImport_FixupBuiltin( > ^~ > make[3]: *** [Makefile:1621: python/python.o] Error 1 > make[3]: *** Waiting for unfinished jobs > make[3]: Leaving directory '/<>/build/objdir/gdb' > make[2]: *** [Makefile:8491: all-gdb] Error 2 > make[2]: Leaving directory '/<>/build/objdir' > make[1]: *** [Makefile:850: all] Error 2 Thanks for the report. FWIW, this has been fixed upstream by: commit aeab512851bf6ed623d1c6c4305b6ce05e51a10c Author: Paul Koning Date: Fri Jun 8 13:26:36 2018 -0400 Fix build issue with Python 3.7 Not sure why this hasn't been picked by the rebase. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source
Am Montag, den 26.11.2018, 09:19 -0800 schrieb James Godfrey-Kittle:
> > Yes, according to https://packages.debian.org/fontmake both Buster and
> Sid are packaging fontmake 1.6.1. I also tried with the latest version
> on Github (1.8.0) and got no error.
Well, then something is still odd on the Debian side. This is what I
get on an up-to-date sid system:
$ fontmake --version
1.6.1
$ fontmake -g FiraCode.glyphs
INFO:fontmake.font_project:Building master UFOs and designspace from
Glyphs source
INFO:glyphsLib.classes:Parsing "FiraCode.glyphs" file into
INFO:fontmake.font_project:Building OTF for FiraCode-Regular
INFO:ufo2ft:Pre-processing glyphs
INFO:ufo2ft.filters:Running DecomposeComponentsFilter on FiraCode-
Regular
INFO:ufo2ft.filters:Running RemoveOverlapsFilter on FiraCode-Regular
INFO:ufo2ft:Building OpenType tables
INFO:ufo2ft.outlineCompiler:The copyright was normalized for storage in
the CFF table and consequently some characters were dropped: 'Copyright
Copyright 2015 by Nikita Prokopov'
Traceback (most recent call last):
File "/usr/bin/fontmake", line 11, in
load_entry_point('fontmake==1.6.1', 'console_scripts',
'fontmake')()
File "/usr/lib/python3/dist-packages/fontmake/__main__.py", line 248,
in main
project.run_from_glyphs(glyphs_path, **args)
File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line
548, in run_from_glyphs
self.run_from_designspace(designspace_path, **kwargs)
File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line
623, in run_from_designspace
**kwargs)
File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line
654, in run_from_ufos
self.build_otfs(ufos, **kwargs)
File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line
232, in build_otfs
self.save_otfs(ufos, **kwargs)
File "/usr/lib/python3/dist-packages/fontTools/misc/loggingTools.py",
line 372, in wrapper
return func(*args, **kwds)
File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line
395, in save_otfs
for font, ufo in zip(fonts, ufos):
File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line
280, in _iter_compile
yield compile_func(ufo, **options)
File "/usr/lib/python3/dist-packages/ufo2ft/__init__.py", line 89, in
compileOTF
featureCompilerClass=featureCompilerClass,
File "/usr/lib/python3/dist-packages/ufo2ft/__init__.py", line 230,
in compileFeatures
return featureCompiler.compile()
File "/usr/lib/python3/dist-packages/ufo2ft/featureCompiler.py", line
125, in compile
self.setupFeatures()
File "/usr/lib/python3/dist-packages/ufo2ft/featureCompiler.py", line
225, in setupFeatures
writer.write(self.ufo, featureFile, compiler=self)
File "/usr/lib/python3/dist-
packages/ufo2ft/featureWriters/baseFeatureWriter.py", line 118, in
write
return self._write()
File "/usr/lib/python3/dist-
packages/ufo2ft/featureWriters/markFeatureWriter.py", line 691, in
_write
features = self._makeFeatures()
File "/usr/lib/python3/dist-
packages/ufo2ft/featureWriters/markFeatureWriter.py", line 640, in
_makeFeatures
indicGlyphs = self._getIndicGlyphs()
File "/usr/lib/python3/dist-
packages/ufo2ft/featureWriters/markFeatureWriter.py", line 677, in
_getIndicGlyphs
gsub = self.compileGSUB()
File "/usr/lib/python3/dist-
packages/ufo2ft/featureWriters/baseFeatureWriter.py", line 181, in
compileGSUB
gsub = compileGSUB(self.context.feaFile, glyphOrder)
File "/usr/lib/python3/dist-packages/ufo2ft/util.py", line 119, in
compileGSUB
addOpenTypeFeatures(font, featureFile, tables={"GSUB"})
File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py",
line 22, in addOpenTypeFeatures
builder.build(tables=tables)
File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py",
line 132, in build
table = self.makeTable(tag)
File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py",
line 540, in makeTable
table.LookupList.Lookup = self.buildLookups_(tag)
File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py",
line 530, in buildLookups_
return [l.build() for l in lookups]
File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py",
line 530, in
return [l.build() for l in lookups]
File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py",
line 1265, in build
self.setBacktrackCoverage_(prefix, st)
File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py",
line 1185, in setBacktrackCoverage_
coverage = otl.buildCoverage(p, self.glyphMap)
File "/usr/lib/python3/dist-packages/fontTools/otlLib/builder.py",
line 11, in buildCoverage
self.glyphs = sorted(glyphs, key=glyphMap.__getitem__)
KeyError: ''
signature.asc
Description: This is a digitally signed message part
Bug#914752: opencv: FTBFS against python3.7.1: error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
Source: opencv Version: 3.2.0+dfsg-4.1+b1 Severity: serious Tags: ftbfs Justification: FTBFS -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, OpenCV FTBFS aginst python3.7.1 which is transitioning as default for python3: /build/opencv-mrTo2C/opencv-3.2.0+dfsg/modules/python/src2/cv2.cpp:730:34: error: invalid conversion from 'const char*' to 'char*' [-fpermissive] char* str = PyString_AsString(obj); Full builg log: https://buildd.debian.org/status/fetch.php?pkg=opencv=arm64=3.2.0%2Bdfsg-4.1%2Bb2=1542824858=0 Thanks, _g. - -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlv8eHMACgkQ7+hsbH/+ z4OPqQgArPF9NPdy3KqXceZ9fZCAo5rwN1O4Cwj9B5ZT7Cz1YEOQHiJQn89NCMYd VKOPbBLerQrsKj5sVdT+i27DKvj7Z7QYtPF1M5vCBegLIva72BqkOSMcm+h4nB/i 4GFu/dPkviRor1vjeZhycHyVSvuCy3z4ogWanh/N00cwbk62xmvPKiYKdwiib7Oy nKOye5qVSHL2wD9oStYh2v/ToU3NrG+gRyUgzNfQ/HBbAXvYS9Mn8AjWaY7tGFwT 7tstxkR+jhd425wyrl6com89DqOQpjGcQKQWI5Yo1UD+amVbU/2Vvs89ufhHflS+ RVeYScSvPMC9gAuHj7U5hN6ZKOF07w== =rTDr -END PGP SIGNATURE-
Bug#912864: openssl: new version of openssl breaks some openvpn clients
On 2018-11-04 22:15:04 [+0100], Kurt Roeckx wrote: > > You're implying openvpn doesn't pick up the openssl.cnf changes so I > > have to set tls-version-min 1.0 in the server side configuration? OK, > > that works too. > > Your client doesn't support the settings in the openssl.cfg file. Your > openvpn client by defaults does TLS 1.0 only. The only way for your client > to do something other than TLS 1.0 is set the tls-version-min variable > to something. If you set it to 1.0, it will do any version > supported by the openssl library higher than 1.0. James, is everything okay/clear? The tls-version-min option for the older OpenVPN version should have fixed things. Is there anything else or can this be considered done? > Kurt Sebastian
Bug#914751: storymaps: Fail to display the cards at startup (missing deps?)
Package: storymaps Version: 1.0+dfsg-3 Severity: important Justification: completely unusable on my machine (does not start properly) Hello, I think that this package is missing several dependencies because the first time I tried to start it, it was complaining that my java virtual machine was in Java 8 while the package is compiled for Java 10. After I installed Java 10 and changed my default jar command to point to the latest version, the program is starting, but it fails to display the playing cards. Here are the some lines of the log (full log attached): [...] Caused by: com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Invalid escape sequence at line 1 column 154 path $[0].instructions at com.google.gson.internal.Streams.parse(Streams.java:60) at com.google.gson.JsonParser.parse(JsonParser.java:84) at com.google.gson.JsonParser.parse(JsonParser.java:59) at com.google.gson.JsonParser.parse(JsonParser.java:45) at storymaps.Function.initialiseFunctionsIfNecessary(Function.java:92) [...] It seems to me that the jarfile distributed on the upstream web page is using another json parser, but actually, I have no idea of what's going on here... Thanks for packaging this nice application anyway, and also for the rest ;) Mt. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages storymaps depends on: ii default-jre [java9-runtime] 2:1.10-68 ii jarwrapper 0.70 ii libfreemarker-java 2.3.23-8 ii libgoogle-gson-java 2.8.2-1 ii libpiccolo-java 1.2-1.1 ii openjdk-10-jre [java9-runtime] 10.0.2+13-2 ii openjdk-8-jre [java8-runtime] 8u171-b11-2 ii openjdk-9-jre [java9-runtime] 9.0.4+12-4 storymaps recommends no packages. storymaps suggests no packages. -- no debconf information nov. 26, 2018 11:28:47 PM storymaps.Application updateStoryOpenedDate INFOS: Reset story opened date to: Mon Nov 26 23:28:47 CET 2018 Exception in thread "main" Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError Caused by: java.lang.RuntimeException: Exception when reading functions file. at storymaps.Function.initialiseFunctionsIfNecessary(Function.java:116) at storymaps.Function.getFunctions(Function.java:122) at storymaps.StoryCards.(StoryCards.java:78) at storymaps.Application.initializePCanvas(Application.java:398) at storymaps.Application.makeFrame(Application.java:313) at storymaps.Application.(Application.java:237) at storymaps.Application.(Application.java:112) Caused by: com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Invalid escape sequence at line 1 column 154 path $[0].instructions at com.google.gson.internal.Streams.parse(Streams.java:60) at com.google.gson.JsonParser.parse(JsonParser.java:84) at com.google.gson.JsonParser.parse(JsonParser.java:59) at com.google.gson.JsonParser.parse(JsonParser.java:45) at storymaps.Function.initialiseFunctionsIfNecessary(Function.java:92) ... 6 more Caused by: com.google.gson.stream.MalformedJsonException: Invalid escape sequence at line 1 column 154 path $[0].instructions at com.google.gson.stream.JsonReader.syntaxError(JsonReader.java:1568) at com.google.gson.stream.JsonReader.readEscapeCharacter(JsonReader.java:1559) at com.google.gson.stream.JsonReader.nextQuotedValue(JsonReader.java:1014) at com.google.gson.stream.JsonReader.nextString(JsonReader.java:815) at com.google.gson.internal.bind.TypeAdapters$29.read(TypeAdapters.java:701) at com.google.gson.internal.bind.TypeAdapters$29.read(TypeAdapters.java:722) at com.google.gson.internal.bind.TypeAdapters$29.read(TypeAdapters.java:714) at com.google.gson.internal.bind.TypeAdapters$29.read(TypeAdapters.java:697) at com.google.gson.internal.Streams.parse(Streams.java:48) ... 10 more java.lang.NoClassDefFoundError: Could not initialize class storymaps.Application at storymaps.Application$4.componentResized(Application.java:295) at java.desktop/java.awt.Component.processComponentEvent(Component.java:6415) at java.desktop/java.awt.Component.processEvent(Component.java:6369) at java.desktop/java.awt.Container.processEvent(Container.java:2261) at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4966) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2319) at
Bug#914748: ant: Fail when installed along with usrmerge and invoked via /bin/ant
Hi Markus, Markus Koschany a écrit le 26/11/2018 à 23:10 : > Hi, > > Am 26.11.18 um 22:46 schrieb Gilles Filippini: >> Package: ant >> Version: 1.9.10-1 >> Severity: serious >> Tags: patch >> Justification: Causes FTBFS >> >> Hi, >> >> When installed along with usrmerge, ant can be invoked via /bin/ant. In this >> case it fails with: > > [...] > > Just some quick notes, not that I'm strongly opposed against usrmerge or > dislike the idea in general but this is somehow odd. First of all why is > this serious now? I know there is an ongoing discussion on debian-devel > about usrmerge but when was it decided to file RC bugs and make this > release-critical? I suppose opencv will work perfectly fine with the > traditional file system layout? To me this is RC because it makes opencv FTBFS on some official buildd machines. No opinion at all about usrmerge. > In any case it is not a very good idea to diverge from upstream or to > carry yet another patch. I wonder why this hasn't been changed already > because Fedora moved to this scheme already and they should have noticed > that too. In any case the scriplet replaced by the patch is buggy. How about pushing this patch upstream? Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#914729: texlive-latex-recommended: fancyvrb/xcolor "Option clash for package xcolor"
On 26.11.18 22:45, Adrian Bunk wrote: > On Mon, Nov 26, 2018 at 10:38:24PM +0100, Hilmar Preuße wrote: Hi Adrian, >> but w/ >> options by default. AFAICT this example is not the only one where the >> load order of the packages does matter. > > My LaTeX knowledge is extremely rusty. > > Is there some way to fix this in fancyvrb, or is the only way > forward to change pycorrfit (and potentially other affected > packages)? > I'm sorry, but fancyvrb can't know that the document tries to load xcolor another time after the fancyvrb call. So I'm afraid we can't do anything here. @Norbert: do you agree here? Hilmar -- #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#914750: High cpu usage
Package: consolation Severity: normal Version: 0.0.6-2 I've been running consolation for quite a while but I noticed recently it accumulates a considerable amount of CPU time over the course of a day. On a system with a ~2 hours uptime, sorting by cpu time, I have Xorg (40m), pulseaudio (20m) and consolation (15m)! which is taking more CPU time than my window manager or systemd... And I never switched to the console since boot. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-rc7-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages consolation depends on: ii libc6 2.27-8 ii libevdev2 1.6.0+dfsg-1 ii libinput10 1.12.1-1 ii libudev1239-13 ii lsb-base9.20170808 consolation recommends no packages. consolation suggests no packages.
Bug#881896: RFP: src -- Simple Revision Control, single-file and single-user version tracking
[Adding kact...@debian.org to CC] Jochen Hein wrote: > On http://www.catb.org/esr/src/ upstream describes it as "Simple > Revision Control". Something like simple-revision-control? That would pass NEW from my PoV. Dimitry, that work for you? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#914749: goxel: Typo in the package description
Package: goxel Severity: minor Dear Maintainer, While translating the description of goxel in the DDTSS, a member of the french l10n team noticed a typo. Indeed, the "pyl" output format should instead be "ply". Thanks for maintaining goxel! Cheers, Thomas -- System Information: Debian Release: 9.6 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#912737: Bug#912737: openssl: SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed
On 2018-11-04 15:10:42 [+0100], Julien Lecomte wrote: > I'll move the issue directly to ubiquiti to figure out what is going wrong. should we just close on the Debian side or did you gather additional information? > Thanks > Julien Sebastian
Bug#914748: ant: Fail when installed along with usrmerge and invoked via /bin/ant
Hi, Am 26.11.18 um 22:46 schrieb Gilles Filippini: > Package: ant > Version: 1.9.10-1 > Severity: serious > Tags: patch > Justification: Causes FTBFS > > Hi, > > When installed along with usrmerge, ant can be invoked via /bin/ant. In this > case it fails with: [...] Just some quick notes, not that I'm strongly opposed against usrmerge or dislike the idea in general but this is somehow odd. First of all why is this serious now? I know there is an ongoing discussion on debian-devel about usrmerge but when was it decided to file RC bugs and make this release-critical? I suppose opencv will work perfectly fine with the traditional file system layout? In any case it is not a very good idea to diverge from upstream or to carry yet another patch. I wonder why this hasn't been changed already because Fedora moved to this scheme already and they should have noticed that too. So far Markus signature.asc Description: OpenPGP digital signature
Bug#865975: #865975 docker.io breaks (bridged) network for VMs
Control: severity -1 critical * Alban Browaeys [171022 00:01]: > The FORWARD chain policy is set to DROP by docker since 1.13. HUH??? Since when is it okay for software that is not advertised as firewall software to modify the sysadmin's implicit or explicit iptables setup for IP packets completely unrelated to said software? I understand that this is a non-trivial problem because of the history behind /proc/sys/net/ipv4/ip_forward and the FORWARD chain, but docker can and needs to do better. My first approximation would be to only change the policy for FORWARD if ip_forward was 0 before docker added its own iptables rules. This will probably work 99.9% of the time. The current behavior appears to break other software 100% of the time if that software relies on ip_forward being 1 and the FORWARD chain being in its default state. * Dmitry Smirnov [180607 09:31]: > I'm lowering severity of this bug since it is not clear how to reproduce the > problem and because networking is not broken for everyone... I'm raising this back to critical (makes unrelated software on the system break), as I cannot fathom how this could not be broken for anyone using KVM with a bridging network interface unless they have found one of the workarounds given in this thread (i.e. the /etc/docker/daemon.json modification, or manually modifying the FORWARD chain). The following should reliably reproduce the problem (disclaimer: I haven't gone back to a clean system and tried this from the start, but I have been using virt-manager for a while, and installing docker.io immediately broke networking on my VMs): * Ensure dockerd is not running and iptables is empty and in its default state (FORWARD chain policy is ACCEPT). * Install virt-manager. * Create a virtual machine with a bridging virtual network interface (e.g. for network source choose "Bridge br0: Host device ens3" where ens3 is the host's wired interface to the LAN). * Ensure networking on the VM works correctly (to the LAN or beyond), and that FORWARD chain still has POLICY ACCEPT. * Start dockerd. The VM's networking to the LAN or beyond (but not to the host machine) will now be broken. Another scenario that I expect to reliably fail is machine A with two wired NIC's, one connected to the LAN and the other connected directly to isolated machine B (e.g. a Raspberry Pi). The connection between A and B could be USB networking. Ensure: * The LAN gateway has a route to B via A. (Using a different /24 between A and B is recommended here.) * Machine A has ip_forward set to 1, and empty, default FORWARD chain. * Machine A has a route to B. * Machine B can reach outside the LAN. I would be extremely surprised if installing docker.io did not break this scenario for machine B. ...Marvin
Bug#844524: disorderfs: rewinddir doesn't work, causing glibc tests to fail under disorderfs
Ximin Luo wrote: > disorderfs: rewinddir doesn't work, causing glibc tests to fail > under disorderfs Hm, I wonder if this was fixed in: https://salsa.debian.org/reproducible-builds/disorderfs/commit/39e29c4ef96319a4c716832a73ad5fd62ed9ff75 … via #898287, released in 0.5.3. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#908992: diffoscope: side-by-side diff for terminal output
Hi Paul, > The HTML output uses a side-by-side diff but the terminal output uses > `diff -u` style output. It would be nice to have an option for > side-by-side diffs with the terminal output. The icdiff package > contains a Python 3 module that could be used for this. I think this could be made to work. As a demo, I just knocked together: --- a/diffoscope/diff.py +++ b/diffoscope/diff.py @@ -324,7 +324,11 @@ def diff(feeder1, feeder2): fifo2_path = os.path.join(tmpdir, 'fifo2') with FIFOFeeder(feeder1, fifo1_path) as fifo1, \ FIFOFeeder(feeder2, fifo2_path) as fifo2: -return run_diff(fifo1_path, fifo2_path, fifo1.end_nl_q, fifo2.end_nl_q) +from icdiff import ConsoleDiff +cd = ConsoleDiff(cols=100) +lines_1 = open(fifo1_path).readlines() +lines_2 = open(fifo2_path).readlines() +return '\n'.join(cd.make_table(lines_1, lines_2, '', '', numlines=7)) ... which resulted in the attached. One difficulty however will be in passing in a sane value of `cols` to ConsoleDiff; not because it's difficult to obtain (see icdiff.py for this terminal foo) but rather we need to subtract 2 or 3 for each indentation/recursion level and we may not know that at the time we run icdiff. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#914729: texlive-latex-recommended: fancyvrb/xcolor "Option clash for package xcolor"
On Mon, Nov 26, 2018 at 10:38:24PM +0100, Hilmar Preuße wrote:
> On 26.11.18 19:53, Adrian Bunk wrote:
>
> Hi Adrian,
Hi Hilmar,
> > https://buildd.debian.org/status/package.php?p=pycorrfit=sid
> >
> > This FTBFS in pycorrfit boils down to the following regression:
> >
> > $ cat test.tex
> > \documentclass{article}
> > \usepackage{fancyvrb}
> > \usepackage[svgnames]{xcolor}
> > \begin{document}
> > Hello world
> > \end{document}
> > $ latex test
> >
>
> > ! LaTeX Error: Option clash for package xcolor.
> >
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type H for immediate help.
> > ...
> >
> > l.4 \begin
> > {document}
> > ?
> >
> Not sure if a single minimal example makes a bug to state RC. There is
> currently no solution form upstream bug a simple work around: load
I need an RC bug somewhere for a FTBFS.
> \usepackage[svgnames]{xcolor} before \usepackage{fancyvrb}
Thanks.
> The issue is caused by the fact that fancyvrb loads xcolor,
This seems to be the relevant recent change.
> but w/
> options by default. AFAICT this example is not the only one where the
> load order of the packages does matter.
My LaTeX knowledge is extremely rusty.
Is there some way to fix this in fancyvrb, or is the only way forward
to change pycorrfit (and potentially other affected packages)?
> Hilmar
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#914748: ant: Fail when installed along with usrmerge and invoked via /bin/ant
Package: ant Version: 1.9.10-1 Severity: serious Tags: patch Justification: Causes FTBFS -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, When installed along with usrmerge, ant can be invoked via /bin/ant. In this case it fails with: /bin/ant: 1: cd: can't cd to /bin/../share/ant/bin/.. Error: Could not find or load main class org.apache.tools.ant.launch.Launcher Caused by: java.lang.ClassNotFoundException: org.apache.tools.ant.launch.Launcher The attached patch solves the problem for me. Setting severity to serious because it causes FTBFS. See for example [1]. [1] https://buildd.debian.org/status/fetch.php?pkg=opencv=amd64=3.2.0%2Bdfsg-4.1%2Bb2=1542819371=0 Thanks, _g. -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlv8aaYACgkQ7+hsbH/+ z4MTeAf/dTyabk7caN+jIGWSZfSxW3HTob2CoGUHbTDclbZvVfX91PvbszNJlADO kXgPZI6ngOky3gx0MwH8H/SqQFt2PamHFdfguSpxWG7ARIERxII7D0ifhFd4eU4V S1RA/ZH1qP98pTX1FFDTBC4l3a8qqDXgIIOmhWqkqiXcbnG9nJMmOdQJWRDjVHQk 9YI3Si/M9wTATCF6fyQhCUG4YqstY6+5ITvuHnQzFhGebC7TElZDuwqF46ZGNnNp 0LXUZjj1A2/UYGzdx0t2YepcHHXd9tFbrDLUZN2OdIaxNorZGoq1xHAEA7x5ussm gRyZebWqgf3B2jGmXs194+27iAt1XQ== =Zgso -END PGP SIGNATURE- diff -Nru ant-1.10.5/debian/changelog ant-1.10.5/debian/changelog --- ant-1.10.5/debian/changelog 2018-08-27 14:57:47.0 +0200 +++ ant-1.10.5/debian/changelog 2018-11-26 22:00:46.0 +0100 @@ -1,3 +1,11 @@ +ant (1.10.5-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * New patch usrmerge-proof.patch to fix failure when installed along +with usrmerge and invoked via /bin/ant + + -- Gilles Filippini Mon, 26 Nov 2018 22:00:46 +0100 + ant (1.10.5-2) unstable; urgency=medium * Team upload. diff -Nru ant-1.10.5/debian/patches/series ant-1.10.5/debian/patches/series --- ant-1.10.5/debian/patches/series2018-08-27 14:57:47.0 +0200 +++ ant-1.10.5/debian/patches/series2018-11-26 21:55:03.0 +0100 @@ -4,3 +4,4 @@ 0013-auto-adjust-target.patch 0015-javadoc-ignore-source-errors.patch 0014-remove-java-activation-module.patch +usrmerge-proof.patch diff -Nru ant-1.10.5/debian/patches/usrmerge-proof.patch ant-1.10.5/debian/patches/usrmerge-proof.patch --- ant-1.10.5/debian/patches/usrmerge-proof.patch 1970-01-01 01:00:00.0 +0100 +++ ant-1.10.5/debian/patches/usrmerge-proof.patch 2018-11-26 22:00:43.0 +0100 @@ -0,0 +1,26 @@ +Description: With usrmerge configured, ant may be called via /bin/ant. + In this case it fails with: + /bin/ant: 1: cd: can't cd to /bin/../share/ant/bin/.. + Using 'readlink -f' instead of this cumbersome while loop solves the + problem. +Index: ant-1.10.5/src/script/ant +=== +--- ant-1.10.5.orig/src/script/ant ant-1.10.5/src/script/ant +@@ -144,15 +144,7 @@ if [ -z "$ANT_HOME" -o ! -d "$ANT_HOME" + progname=`basename "$0"` + + # need this for relative symlinks +- while [ -h "$PRG" ]; do +-ls=`ls -ld "$PRG"` +-link=`expr "$ls" : '.*-> \(.*\)$'` +-if expr "$link" : '/.*' > /dev/null; then +- PRG="$link" +-else +- PRG=`dirname "$PRG"`"/$link" +-fi +- done ++ PRG=`readlink -f $PRG` + + ANT_HOME=`dirname "$PRG"`/.. +
Bug#914743: (no subject)
KDE upstream bug #396980
Patch: https://phabricator.kde.org/D14554
--
Enneamerdiff -Nru kdepim-runtime-16.04.2/debian/patches/fix-array-access-bounds-in-IMAP-resource.patch kdepim-runtime-16.04.2/debian/patches/fix-array-access-bounds-in-IMAP-resource.patch
--- kdepim-runtime-16.04.2/debian/patches/fix-array-access-bounds-in-IMAP-resource.patch 1969-12-31 19:00:00.0 -0500
+++ kdepim-runtime-16.04.2/debian/patches/fix-array-access-bounds-in-IMAP-resource.patch 2018-11-26 15:48:39.0 -0500
@@ -0,0 +1,41 @@
+Fix array access bounds in IMAP resource
+
+ImapQuotaAttribute::serialized() processes IMAP roots assigning
+corresponding QUOTA and USAGE attributes to each root. It uses three
+dictionaries: mRoots, mLimits, and mUsages assuming that these
+dictionaries always have the same number of elements. In a case when
+mRoots contains more elements than other two dictionaries, this causes
+referencing to non-existent elements in mLimits and mUsages and
+segfaults.
+
+Fix this by using mLimits.size() and mUsages.size() in corresponding
+loops.
+
+BUG: 396980
+Developers: gkowal
+Reviewers: KDE PIM, dvratil
+Reviewed By: KDE PIM, dvratil
+Subscribers: mlaurent, cfeck, kde-pim
+Tags: KDE PIM
+
+Differential Revision: https://phabricator.kde.org/D14554
+--- a/resources/shared/singlefileresource/imapquotaattribute.cpp
b/resources/shared/singlefileresource/imapquotaattribute.cpp
+@@ -91,7 +91,7 @@
+ result += " "; // Members separator
+
+ // Then the limit maps list
+-for (int i = 0; i < mRoots.size(); ++i) {
++for (int i = 0; i < mLimits.size(); ++i) {
+ const QMap limits = mLimits[i];
+ for (auto it = limits.cbegin(), end = limits.cend(); it != end; ++it) {
+ result += it.key();
+@@ -107,7 +107,7 @@
+ result += " "; // Members separator
+
+ // Then the usage maps list
+-for (int i = 0; i < mRoots.size(); ++i) {
++for (int i = 0; i < mUsages.size(); ++i) {
+ const QMap usages = mUsages[i];
+ for (auto it = usages.cbegin(), end = usages.cend(); it != end; ++it) {
+ result += it.key();
diff -Nru kdepim-runtime-16.04.2/debian/patches/series kdepim-runtime-16.04.2/debian/patches/series
--- kdepim-runtime-16.04.2/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ kdepim-runtime-16.04.2/debian/patches/series 2018-11-26 15:47:09.0 -0500
@@ -0,0 +1 @@
+fix-array-access-bounds-in-IMAP-resource.patch
Bug#914729: texlive-latex-recommended: fancyvrb/xcolor "Option clash for package xcolor"
On 26.11.18 19:53, Adrian Bunk wrote:
Hi Adrian,
> https://buildd.debian.org/status/package.php?p=pycorrfit=sid
>
> This FTBFS in pycorrfit boils down to the following regression:
>
> $ cat test.tex
> \documentclass{article}
> \usepackage{fancyvrb}
> \usepackage[svgnames]{xcolor}
> \begin{document}
> Hello world
> \end{document}
> $ latex test
>
> ! LaTeX Error: Option clash for package xcolor.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type H for immediate help.
> ...
>
> l.4 \begin
> {document}
> ?
>
Not sure if a single minimal example makes a bug to state RC. There is
currently no solution form upstream bug a simple work around: load
\usepackage[svgnames]{xcolor} before \usepackage{fancyvrb}
The issue is caused by the fact that fancyvrb loads xcolor, but w/
options by default. AFAICT this example is not the only one where the
load order of the packages does matter.
Hilmar
--
#206401 http://counter.li.org
Bug#914691: RFA: agda-stdlib -- standard library for Agda
Hello everyone, On Mon, 2018-11-26 at 10:26 +, Iain Lane wrote: > > I'm not involved in this area any more. I've been basically ignoring > the > package and people from the Haskell team have been kindly uploading > it > in my absence. > > I'd like it if someone were to take it off my hands. That will > probably > be the Haskell team, but Sean points out to me that there would be no > human uploaders if the team were to take it over directly. So ideally > someone in the team would sign up to be an Uploader and make pkg- > haskell > the Maintainer. Let me know if there is a process to follow in applying, but I'd like to contribute with maintaining this library package. So far I had a few attempts about two years ago in creating a C++ package or two, but none in Haskell or Agda. I use Haskell professionally and I've been learning Agda. -- Regards, Marko Dimjašević https://dimjasevic.net/marko PGP key ID: 056E61A6F3B6C9323049DBF9565EE9641503F0AA Learn email self-defense! https://emailselfdefense.fsf.org signature.asc Description: This is a digitally signed message part
Bug#914747: bs1770gain FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck
Source: bs1770gain Version: 0.5.1-2 Tags: patch bs1770gain fails to cross build from source, because it fails running tests with an Exec format error despite setting DEB_BUILD_OPTIONS=nocheck. The attached patch implements the nocheck flag and makes bs1770gain cross build successfully. Please consider applying it. Helmut diff --minimal -Nru bs1770gain-0.5.1/debian/changelog bs1770gain-0.5.1/debian/changelog --- bs1770gain-0.5.1/debian/changelog 2018-10-19 12:01:10.0 +0200 +++ bs1770gain-0.5.1/debian/changelog 2018-11-26 22:32:02.0 +0100 @@ -1,3 +1,10 @@ +bs1770gain (0.5.1-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Support DEB_BUILD_OPTIONS=nocheck. (Closes: #-1) + + -- Helmut Grohne Mon, 26 Nov 2018 22:32:02 +0100 + bs1770gain (0.5.1-2) unstable; urgency=medium [ Ondřej Nový ] diff --minimal -Nru bs1770gain-0.5.1/debian/rules bs1770gain-0.5.1/debian/rules --- bs1770gain-0.5.1/debian/rules 2018-10-19 11:43:12.0 +0200 +++ bs1770gain-0.5.1/debian/rules 2018-11-26 22:31:58.0 +0100 @@ -2,10 +2,12 @@ %: dh $@ +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) # Run our test suite until the upstream source get one override_dh_auto_test: dh_auto_test BS1770GAIN=`pwd`/bs1770gain/bs1770gain ./debian/tests/test-cmd-tool +endif # Generate and install manual page debian/bs1770gain.1: debian/bs1770gain.txtman
Bug#908994: diffoscope: extract information from OpenPGP keys and signatures
Control: tags -1 + moreinfo Hi Paul, > When comparing OpenPGP keys or signatures (binary and ASCII-armoured), > either as raw files or embedded in other formats (like .dsc files), > it would be nice to compare the internal data of those keys and sigs. Thanks for another good wishlist bug against diffoscope. I added support for pgpdump in diffoscope version 82 via #859034. Had you seen this? I do note that your bug mentions some other tools (name gpg --list- packets, hot dump and hot dearmor) however. Are there any of these you would suggest we prioritise? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#914746: [apt-cacher-ng] print configuration option not recognised
Package: apt-cacher-ng Version: 2-2 Severity: normal --- Please enter the report below this line. --- Running apt-cacher-ng with -p options does not show current configuration. manpage does not mention -p option, but 'apt-cacher-ng -h' does. # apt-cacher-ng -p Not a valid configuration directive: -p Usage: apt-cacher-ng [options] [ -c configdir ] Options: -h: this help message -c: configuration directory -e: on startup, run expiration once -p: print configuration and exit -i: ignore configuration loading errors Most interesting variables: ForeGround: Don't detach (default: 0) Port: TCP port number (default: 3142) CacheDir: /directory/for/storage LogDir: /directory/for/logfiles See configuration examples for all directives. # apt-cacher-ng -h Usage: apt-cacher-ng [options] [ -c configdir ] Options: -h: this help message -c: configuration directory -e: on startup, run expiration once -p: print configuration and exit -i: ignore configuration loading errors Most interesting variables: ForeGround: Don't detach (default: 0) Port: TCP port number (default: 3142) CacheDir: /directory/for/storage LogDir: /directory/for/logfiles See configuration examples for all directives. --- System information. --- Architecture: Kernel: Linux 4.18.0-0.bpo.1-amd64 Debian Release: 9.6 500 stretch-backports ftp.pl.debian.org 500 stable-debugdebug.mirrors.debian.org 500 stable security.debian.org 500 stable ftp.pl.debian.org 500 stable dl.google.com 500 proposed-updates ftp.pl.debian.org 450 stable www.deb-multimedia.org 402 unstable-debug debug.mirrors.debian.org 402 unstableftp.pl.debian.org 401 experimentalftp.pl.debian.org --- Package information. --- Depends(Version) | Installed -+-= libbz2-1.0 | 1.0.6-8.1 libc6 (>= 2.22) | libgcc1 (>= 1:3.3.1) | liblzma5(>= 5.1.1alpha+20120614) | libssl1.1 (>= 1.1.0) | libstdc++6 (>= 5.2) | libsystemd0 (>= 210) | libwrap0 (>= 7.6-4~) | zlib1g (>= 1:1.2.0) | debconf(>= 0.5) | OR debconf-2.0 | init-system-helpers (>= 1.18~) | adduser | lsb-base (>= 3.0-6) | Package's Recommends field is empty. Suggests (Version) | Installed ===-+-=== doc-base| 0.10.7 libfuse2 (>= 2.5) | 2.9.7-1+deb9u2 avahi-daemon| 0.6.32-2 --- Output from package bug script ---
Bug#914745: calligrawords: Second page is empty if margins is set to 0
Package: calligrawords Version: 1:2.9.11+dfsg-4+b1 Severity: normal Dear Maintainer, -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages calligrawords depends on: ii calligra-libs 1:2.9.11+dfsg-4+b1 ii calligrawords-data 1:2.9.11+dfsg-4 ii kde-runtime 4:16.08.3-2 ii libc6 2.24-11+deb9u3 ii libgcc1 1:6.3.0-18+deb9u1 ii libkdecore5 4:4.14.26-2 ii libkdeui5 4:4.14.26-2 ii libodfgen-0.1-1 0.1.6-2 ii libqt4-svg 4:4.8.7+dfsg-11 ii libqt4-xml 4:4.8.7+dfsg-11 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui4 4:4.8.7+dfsg-11 ii librevenge-0.0-00.0.4-6 ii libstdc++6 6.3.0-18+deb9u1 ii libwpd-0.10-10 0.10.1-5+deb9u1 ii libwpg-0.3-30.3.1-3 ii zlib1g 1:1.2.8.dfsg-5 calligrawords recommends no packages. Versions of packages calligrawords suggests: ii khelpcenter 4:16.08.3-1 -- no debconf information Follow these instructions: 1. open new blank document 2. Go to "page layout", set all margins to 0 3. Copy/paste something to document. Second page is always blank. 4. With margins everything works fine. Stretch Calligra Words version is 2.9.11, maybe newer version should be taken from sid repository?
Bug#914413: supermin: should at least suggest a kernel package
* Johannes 'josch' Schauer: > Package: supermin > Version: 5.1.19-3 > Severity: wishlist > > Hi, > > when using supermin with --copy-kernel on a system without a kernel > (like inside a container) then supermin will fail with: > […] > Since having a kernel image available is required for some use of > supermin, it should at least suggest a kernel package in its > dependencies. I'm going to make that a Recommends. Cheers, -Hilko
Bug#914744: gdb ftbfs with Python 3.7
Package: src:gdb Version: 8.1-4 Severity: serious Tags: sid buster gdb ftbfs with Python 3.7. upstream version 8.2 build fine. x86_64-linux-gnu-g++ -x c++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -I. -I/<>/gdb -I/<>/gdb/common -I/<>/gdb/config -DLOCALEDIR="\"/usr/share/locale\"" -DHAVE_CONFIG_H -I/<>/gdb/../include/opcode -I/<>/gdb/../opcodes/.. -I../bfd -I/<>/gdb/../bfd -I/<>/gdb/../include -I../libdecnumber -I/<>/gdb/../libdecnumber -I/<>/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.7m -I/usr/include/python3.7m -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wformat-nonliteral -c -o elfread.o -MT elfread.o -MMD -MP -MF ./.deps/elfread.Tpo /<>/gdb/elfread.c /<>/gdb/python/python.c: In function 'bool do_start_initialization()': /<>/gdb/python/python.c:1710:45: error: too few arguments to function 'int _PyImport_FixupBuiltin(PyObject*, const char*, PyObject*)' _PyImport_FixupBuiltin (gdb_module, "_gdb"); ^ In file included from /usr/include/python3.7m/Python.h:126, from /<>/gdb/python/python-internal.h:100, from /<>/gdb/python/python.c:94: /usr/include/python3.7m/import.h:112:17: note: declared here PyAPI_FUNC(int) _PyImport_FixupBuiltin( ^~ make[3]: *** [Makefile:1621: python/python.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/<>/build/objdir/gdb' make[2]: *** [Makefile:8491: all-gdb] Error 2 make[2]: Leaving directory '/<>/build/objdir' make[1]: *** [Makefile:850: all] Error 2
Bug#912583: simpleitk patch for Python 3.7
Control: tags -1 + patch patch at https://patches.ubuntu.com/s/simpleitk/simpleitk_1.0.1-2ubuntu1.patch
Bug#914742: zeroc-ice ftbfs in unstable with Python 3.7
Package: src:zeroc-ice Version: 3.7.1-5 Severity: serious Tags: sid buster patch zeroc-ice ftbfs in unstable with Python 3.7 x86_64-linux-gnu-g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -MT modules/IcePy/build/x86_64-linux-gnu/shared/pic/Proxy.o -MMD -MP -MF modules/IcePy/build/x86_64-linux-gnu/shared/pic/Proxy.Td -Wall -Wdeprecated -Werror -pthread -DNDEBUG -Imodules/IcePy -I../cpp/include -I../cpp/include/generated -I../cpp/src -I/usr/include/python3.7m -I/usr/include/python3.7m -Wno-unused-result -Wsign-compare -g -fdebug-prefix-map=/build/python3.7-0HyDJv/python3.7-3.7.1=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector -Wformat -Werror=format-security -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 -c modules/IcePy/Proxy.cpp -o modules/IcePy/build/x86_64-linux-gnu/shared/pic/Proxy.o modules/IcePy/Communicator.cpp: In function ‘PyObject* communicatorWaitForShutdown(IcePy::CommunicatorObject*, PyObject*)’: modules/IcePy/Communicator.cpp:475:36: error: comparison of integer expressions of different signedness: ‘long unsigned int’ and ‘long int’ [-Werror=sign-compare] if(PyThread_get_thread_ident() == _mainThreadId) ^~~~ cc1plus: all warnings being treated as errors make[2]: *** [Makefile:41: modules/IcePy/build/x86_64-linux-gnu/shared/pic/Communicator.o] Error 1 make[2]: *** Waiting for unfinished jobs work around patch available at https://patches.ubuntu.com/z/zeroc-ice/zeroc-ice_3.7.1-5ubuntu1.patch
Bug#914743: kdepim-runtime: akonadi_imap_resource crashes with bus error while syncing the inbox
Package: kdepim-runtime Version: 4:16.04.2-2+b2 Severity: important Dear Maintainer, akonadi_imap_resource crashes with bus error while syncing to my mailbox hosted by a cPanel server. I initially set up the IMAP resource yesterday and synced 2 emails without issue. The third email was sent to me today and may have triggered the issue. The email was fetched successfully though. Application: akonadi_imap_resource (akonadi_imap_resource), signal: Bus error Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f0355e11f80 (LWP 2273))] Thread 1 (Thread 0x7f0355e11f80 (LWP 2273)): [KCrash Handler] #6 std::__atomic_base::load (__m=std::memory_order_relaxed, this=) at /usr/include/c++/6/bits/atomic_base.h:396 #7 QAtomicOps::load (_q_value=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic_cxx11.h:227 #8 QBasicAtomicInteger::load (this=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qbasicatomic.h:99 #9 QtPrivate::RefCount::ref (this=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:55 #10 QMap::QMap (other=..., this=0x7ffef5670560) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:615 #11 Akonadi::ImapQuotaAttribute::serialized (this=0x5634b2953650) at ./resources/shared/singlefileresource/imapquotaattribute.cpp:95 #12 0x7f0368336a62 in attributesToProtocolImpl (ns=, entity=...) at ./src/core/protocolhelper.cpp:110 #13 Akonadi::ProtocolHelper::attributesToProtocol (collection=..., ns=ns@entry=false) at ./src/core/protocolhelper.cpp:205 #14 0x7f036837827f in Akonadi::CollectionModifyJob::doStart (this=0x5634b2941720) at ./src/core/jobs/collectionmodifyjob.cpp:102 #15 0x7f036838b8c0 in Akonadi::JobPrivate::startQueued (this=) at ./src/core/jobs/job.cpp:174 #16 0x7f036834c72e in Akonadi::SessionPrivate::startJob (this=this@entry=0x5634b28953e0, job=job@entry=0x5634b2941720) at ./src/core/session.cpp:204 #17 0x7f036834e5fb in Akonadi::SessionPrivate::doStartNext (this=0x5634b28953e0) at ./src/core/session.cpp:181 #18 0x7f03662ac499 in QObject::event (this=0x5634b2890570, e=) at kernel/qobject.cpp:1263 #19 0x7f0366b62b8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #20 0x7f0366b6a341 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #21 0x7f036627f9e0 in QCoreApplication::notifyInternal2 (receiver=0x5634b2890570, event=event@entry=0x5634b297d010) at kernel/qcoreapplication.cpp:988 #22 0x7f036628216d in QCoreApplication::sendEvent (event=0x5634b297d010, receiver=) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #23 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x5634b282ad10) at kernel/qcoreapplication.cpp:1649 #24 0x7f03662825d8 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1503 #25 0x7f03662d3c43 in postEventSourceDispatch (s=0x5634b2865020) at kernel/qeventdispatcher_glib.cpp:276 #26 0x7f03600377f7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #27 0x7f0360037a60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #28 0x7f0360037b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #29 0x7f03662d404f in QEventDispatcherGlib::processEvents (this=0x5634b2877b00, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #30 0x7f036627d9ca in QEventLoop::exec (this=this@entry=0x7ffef5670e30, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #31 0x7f036628613c in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1261 #32 0x7f036869f91e in Akonadi::ResourceBase::init(Akonadi::ResourceBase*) () from /usr/lib/x86_64-linux-gnu/libKF5AkonadiAgentBase.so.5 #33 0x5634b2093ca5 in Akonadi::ResourceBase::init (argc=, argv=) at /usr/include/KF5/AkonadiAgentBase/resourcebase.h:196 #34 0x7f03656e92e1 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #35 0x5634b2093b1a in _start () -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kdepim-runtime depends on: ii akonadi-server 4:16.04.3-4 ii kdepimlibs-data 4:16.04.2-2 ii kf5-kdepimlibs-kio-plugins 4:16.04.2-2 ii kio 5.28.0-2 ii libc6 2.24-11+deb9u3 ii libgcc1 1:6.3.0-18+deb9u1 ii libkf5akonadiagentbase5 4:16.04.3-4 ii libkf5akonadicalendar5 16.04.2-2 ii libkf5akonadicontact5
Bug#914741: pycorrfit ftbfs in unstable
Package: src:pycorrfit Version: 1.1.4+dfsg-2 Severity: serious Tags: sid buster seen with the last binNMU, failing to build the docs: Output written on PyCorrFit_doc.pdf (32 pages, 549743 bytes). SyncTeX written on PyCorrFit_doc.synctex.gz. Transcript written on PyCorrFit_doc.log. make[1]: *** [debian/rules:29: override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>/pycorrfit-1.1.4+dfsg' make: *** [debian/rules:22: build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 Build finished at 2018-11-26T13:55:06Z
Bug#914740: agg FTCBFS: configures for the build architecture
Source: agg Version: 1:2.4-r127+dfsg1-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap agg fails to cross build from source, because it configures for the build architecture by not passing the relevant --host flag. The easiest way of doing so is using dh_auto_configure. The attached patch implements that and makes agg cross buildable. Please consider applying it. Helmut diff --minimal -Nru agg-2.4-r127+dfsg1/debian/changelog agg-2.4-r127+dfsg1/debian/changelog --- agg-2.4-r127+dfsg1/debian/changelog 2017-08-14 00:32:15.0 +0200 +++ agg-2.4-r127+dfsg1/debian/changelog 2018-11-26 21:57:00.0 +0100 @@ -1,3 +1,10 @@ +agg (1:2.4-r127+dfsg1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_configure pass --host to configure. (Closes: #-1) + + -- Helmut Grohne Mon, 26 Nov 2018 21:57:00 +0100 + agg (1:2.4-r127+dfsg1-1) unstable; urgency=medium * I am taking over this package. Thank you Andrea Veri for your diff --minimal -Nru agg-2.4-r127+dfsg1/debian/rules agg-2.4-r127+dfsg1/debian/rules --- agg-2.4-r127+dfsg1/debian/rules 2017-06-19 06:27:04.0 +0200 +++ agg-2.4-r127+dfsg1/debian/rules 2018-11-26 21:57:00.0 +0100 @@ -2,7 +2,7 @@ FLAVOURS := pic nonpic -CONFIGURE_ARGS_COMMON := --prefix=/usr --disable-examples --x-includes=/usr/include --x-libraries=/usr/lib +CONFIGURE_ARGS_COMMON := --libdir=/usr/lib --disable-examples --x-includes=/usr/include --x-libraries=/usr/lib CONFIGURE_ARGS_pic := -with-pic CONFIGURE_ARGS_nonpic := --disable-gpc DESTDIR_nonpic := debian/libagg-dev @@ -19,7 +19,8 @@ mkdir -p $(CURDIR)/$(builddir) find $(CURDIR)/* -maxdepth 0 -not -path '$(CURDIR)/obj-*' | \ xargs cp -rlf -t $(CURDIR)/$(builddir) - cd $(builddir) && env NOCONFIGURE=1 sh autogen.sh && ./configure $(CONFIGURE_ARGS_COMMON) $(CONFIGURE_ARGS_$(1)) $(shell dpkg-buildflags --export=configure) + cd $(builddir) && env NOCONFIGURE=1 sh autogen.sh + dh_auto_configure --sourcedirectory=$(builddir) -- $(CONFIGURE_ARGS_COMMON) $(CONFIGURE_ARGS_$(1)) $(shell dpkg-buildflags --export=configure) touch $$@ build-$(1): build-$(1)-stamp
Bug#914738: painintheapt: Please append subject to XMPP message
Thanks for your problem report! Quoting Gerald Turner : However newer versions split this information into a separate 'subject' field, which my XMPP client (Pidgin usually) ignores. It's also absent from MUC group messages entirely. True. I will either remove the subject again or duplicate it in the message, so that it works well enough with (almost) all XMPP clients. Cheers
Bug#785356: que
Bitte mailen Sie mir zurück Wayne.
Bug#910059: RFH: gnucash -- personal and small-business financial-accounting software
On Monday, 26 November 2018 2:14:34 AM AEDT Raphael Hertzog wrote: > a good start would be to include Dmitry in your recipient list. The > Debian bug tracker does not include the bug submitter by default. > > I have cced him so hopefully he will be able to reply to you. Thanks, Raphael. > > I'd be interested in helping to maintain gnucash. I am looking to get > > involved in Debian and use gnucash personally. Do you have any advice on > > how to get started? It is always a good idea to start with bugs and work through them... -- Cheers, Dmitry Smirnov. --- It is a fine thing to be honest, but it is also very important to be right. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
