Bug#880125: Should Recommend: python3-openpyxl, python3-xlrd
Package: python3-pandas Version: 0.20.3-10 Severity: normal Loading of various Excel documents depends on python3-openpyxl and python3-xlrd. Both were already Recommended in python-pandas, but the same is not true for python3-pandas. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-rc5-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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-pandas depends on: ii python33.6.3-2 ii python3-dateutil 2.6.1-1 ii python3-numpy 1:1.13.1-1 ii python3-pandas-lib 0.20.3-10 ii python3-pkg-resources 36.2.7-2 ii python3-six1.11.0-1 ii python3-tz 2017.2-2 Versions of packages python3-pandas recommends: pn python3-bs4 ii python3-html5lib0.9-1 ii python3-lxml4.0.0-1 ii python3-matplotlib 2.0.0+dfsg1-2+b1 ii python3-numexpr 2.6.2-2 ii python3-scipy 0.19.1-1 ii python3-tables 3.4.2-1 Versions of packages python3-pandas suggests: ii python-pandas-doc 0.20.3-10
Bug#879000: Cannot recover after password timeout
Package: dracut Version: 045+132-1 Severity: normal I briefly tried dracut on a minimal system with cryptosetup+luks root filesystem. Everything works as expected. I discovered a minor issue with the password prompt. During boot, the prompt to unlock the root fs has a timeout. If the timeout is reached, you're dropped onto a recovery shell. At this stage, unfortunately, the password prompt seems to be still active and is still eating half of the keypresses in the background, making it impossible to actually use the recovery shell. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-rc3-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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dracut depends on: ii dracut-core 045+132-1 dracut recommends no packages. Versions of packages dracut suggests: pn dracut-network
Bug#871542: chromium: Chromium 60 UI is huge on HiDPI displays
Package: chromium Version: 61.0.3163.100-2 Followup-For: Bug #871542 I was also hit by this bug with Chromium 61. At 2560x1440 the UI is just overblown. Using an 1.5 scale factor fixes the size to something acceptable, but only when I'm using the laptop's screen. When booting with an external screen, the DPI is lower, and thus the environment variable needs to be changed. I don't understand why Chromium is not using the reported DPI setting (values reported by XRandR are correct!) and instead is introducing another useless scaling factor! -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages chromium depends on: ii chromium-common 61.0.3163.100-2 ii libasound2 1.1.3-5 ii libatk1.0-0 2.26.0-2 ii libavcodec57 10:3.3.4-dmo1 ii libavformat5710:3.3.4-dmo1 ii libavutil55 10:3.3.4-dmo1 ii libc62.24-17 ii libcairo21.14.10-1 ii libcups2 2.2.4-7 ii libdbus-1-3 1.11.18-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.3-1 ii libflac8 1.3.2-1 ii libfontconfig1 2.12.3-0.2 ii libfreetype6 2.8-0.2 ii libgcc1 1:7.2.0-10.0+really6~reproducible1 ii libgdk-pixbuf2.0-0 2.36.10-2 ii libglib2.0-0 2.54.0-1 ii libgtk2.0-0 2.24.31-2 ii libharfbuzz0b1.4.2-1 ii libicu57 57.1-6 ii libjpeg62-turbo 1:1.5.2-2 ii liblcms2-2 2.8-4 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.16-1 ii libnss3 2:3.32-2 ii libopus0 1.2.1-1 ii libpango-1.0-0 1.40.12-1 ii libpangocairo-1.0-0 1.40.12-1 ii libpng16-16 1.6.32-3 ii libpulse011.1-1 ii libre2-3 20170101+dfsg-1 ii libsnappy1v5 1.1.7-1 ii libstdc++6 7.2.0-10.0+really6~reproducible1 ii libvpx4 1.6.1-3 ii libwebp6 0.6.0-3 ii libwebpdemux20.6.0-3 ii libwebpmux3 0.6.0-3 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb1 1.12-1 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.14-3 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-4 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.29-2.1 ii libxss1 1:1.2.2-1+b2 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages chromium recommends: ii fonts-liberation 1:1.07.4-2 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell pn chromium-widevine
Bug#876841: Depends on python3-mock
Package: python3-tables Version: 3.4.2-1 Severity: normal Hi, in the newer release of the package, python3-tables is added as a build dependency, however the package itself depends on python3-mock. After checking though, it seems that python3-mock is only used in tests/test_utils.py (the test suite). Is it necessary dependency? -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-tables depends on: ii python 2.7.14-1 ii python-tables-data 3.4.2-1 ii python3 3.5.3-3 ii python3-mock2.0.0-3 ii python3-numexpr 2.6.2-2 ii python3-numpy 1:1.13.1-1 ii python3-six 1.11.0-1 ii python3-tables-lib 3.4.2-1 python3-tables recommends no packages. Versions of packages python3-tables suggests: pn python-netcdf ii python-tables-doc 3.4.2-1 pn vitables
Bug#729956: Python 3 Statsmodels & Pandas
On Sat, Sep 16 2017, Diane Trout wrote: > I was assuming it's because there's a cyclic dependency between pandas > and statsmodels (needed for pandas unit tests), and statsmodels was > also broken by the fpectl problem. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875805 > > My solution was to use build-profiles to flag the test dependency with > !nocheck Looking at python3-skimage-lib (which also requires a rebuild), it seems that the package failed to pass some tests. Bug #868582 even includes a patch to update to 0.13 [and disables some test failures].
Bug#729956: Python 3 Statsmodels & Pandas
On Sat, Sep 16 2017, Diane Trout wrote:
> python3-pandas: Pandas is not installable
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875723
I would have expected the rebuild of python packages affected by the
fpectl extension with a transition, but it doesn't seem to be the case?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874253
More Breaks where added to {python,python3}-stdlib itself, but there are
still packages which didn't rebuild.
Bug#873499: GnuPG package split and interlocking dependencies [was: Re: Bug#873499: Should depend on "gnupg | gnupg2 | gpg"]
On Mon, Sep 11 2017, Daniel Kahn Gillmor wrote: >> I'd recommend gpg-agent, and suggest gnupg instead. > > why? upstream recommends shipping all the binaries in a single package > as the standard deployment. I'm trying to meet them halfway here. <...> > I'm willing to keep the split in debian to support narrowly-scoped, tiny > systems administered by technically-competent people. But we've got > enough issues to focus on without encouraging full-blown desktop systems > that have gpg fail because of missing dependenencies, which is what i > think would happen if we moved the rest of the suite out of Recommends. > Do you think that wouldn't happen? There's one intricate example which I think would be useful for discussion: what should libgpgme11 do? It currently depends on gnupg, which installs the full suite. But that's a result of the old package structure. I would (personally) make libgpgpme11 depend on gpg only, and move the burden of the final call to the actual tool facing the user. For example, notmuch, which uses libgmime which in turn uses libgpgme11 does that correctly by recommending the agent and gpgsm. But I do see your point. It's an added burden on the maintainer. > Thanks for the suggested text. Can you explain why the package > Description: should call out secret key use separately from, say, > network access, or other modules of the suite? My reasoning is that gpg is supposed to do encryption/decryption and signing, and if you can't decrypt or sign because you don't have the agent you're probably wondering what can you actually do with it. I still see certificate management and network support as extra. > they most certainly do -- for just one example, in a batch script where > gpg is invoked a number of times, the long-running dirmngr process can > cache knowledge about the network between invocations of gpg. I guess this could happen. This probably stems for my own usage of gpg itself, which doesn't involve any network usage on the gpg part.
Bug#873499: Should depend on "gnupg | gnupg2 | gpg"
On Mon, Sep 11 2017, Daniel Kahn Gillmor wrote: > On Mon 2017-09-11 14:28:29 +0200, Yuri D'Elia wrote: >> I'd rather go for this route, and recommend gpg-agent from gpg, > > gpg already Recommends: gnupg, which itself Depends: gpg-agent. I'd recommend gpg-agent, and suggest gnupg instead. > This package contains /usr/bin/gpg itself, and is useful on its own > only for public key operations (encryption, signature verification, > listing OpenPGP certificates, etc). If you want full capabilities > (including secret key operations, network access, etc), please > install the "gnupg" package, which pulls in the full suite of tools. This package contains /usr/bin/gpg itself, and is useful on its own only for public key operations (encryption, signature verification, listing OpenPGP certificates, etc). For operations involving secret keys and passphrases, gpg-agent is also required. If you want full capabilities (network access, X.509 and CMS and all other command line utilities), please install the "gnupg" package, which pulls in the full suite of tools. > Your previous sentence suggests that you don't want to always having a > daemon running. in this sentence, you suggest that you don't like the > systems that help you to avoid always having a daemon running. These > two complaints seem incompatible, unless all you're saying is that you > simply don't like the idea of separated processes with different > requirements/capabilities at all. I don't oppose the idea of a separated process with different capabilities. This is fine for using gpg as a daemon for interactive usage. I'm using gpg-agent with pinentry for ssh keys as well, so I'm not complaining about this. I overall like how these work together. But on the other side, when all you want to do is use gpg in a batch script and it fed stuff which is already on disk, these separate processes do hardly anything useful. > Can you tell me (probably in a separate report) what unattended > operation problem you're particularly having, so we can try to get it > resolved? surely the fact that unattended operation might involve > multiple processes instead of a single process isn't the problem in > itself. Let's continue this into a separated report then. Let me know what you think about the revised description and suggested dependencies.
Bug#873499: Should depend on "gnupg | gnupg2 | gpg"
On Mon, Sep 11 2017, Daniel Kahn Gillmor wrote: > gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory > gpg: can't connect to the agent: No such file or directory > gpg: agent_genkey failed: No agent running > Key generation failed: No agent running > 2 dkg@sid:~$ Since I always had to use the agent, I never noticed. Sorry about that. > something fancier and more narrowly targeted, they could do something > like: > > Depends: gpg-agent, gpg > Recommends: gnupg I'd rather go for this route, and recommend gpg-agent from gpg, mentioning that secret key operations require at least the agent to be running in the description. > since i don't believe that pass has any need for network access > (dirmngr) or X.509 or CMS (gpgsm). But i don't know pass super well so > i can't guarantee that this is correct. pass doesn't fetch external keys. > I certainly don't want most users to have to think about which > specific packages they need to install. I'm actually happy that newer versions of gpg do not require dirmngr to be running anymore. When using gpg non-interactively, having services start-up unexpectedly (especially under systemd activation) is not something I'm pleased with. I remember I filed a bug report about the agent/dirmngr activation. I use gpg for batch unattended operations, but it looks like gpg is becoming more and more a tool for strictly interactive usage.
Bug#875303: Troublesome systemd-networkd-wait-online.service
Package: systemd Version: 234-3 Severity: normal The systemd-networkd-wait-online.service is causing tlp.service (among others) to break in my setup. The issue is caused by the rule Also=systemd-networkd-wait-online.service present in systemd-network.service. Several services include include an explicit dependency on network-online.target which then drag in systemd-networkd-wait-online.service. One is apt-daily.service, but exim4 (via LFS) is another. The net result is that multi-user.target now depends on systemd-networkd-wait-online.service. However, on a laptop, this is broken. multi-user.target shouldn't directly depend on a working connection. In case of tlp.service, which has After=multi-user.target, will execute the startup rules *after* wait-online timeouts, which is some minutes after I could login. Incidentally, exim4 also isn't started until timeout occurs, which makes local mail delivery broken until then. This is more subtle. The init script in this case depends on $network. systemd shouldn't automatically translate this to include network-online.target, but only network.target. I currently masked network-online.service to resolve this issue, but this shouldn't be. Services should be able to depend on network-online without affecting system startup. -- Package-specific info: -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.116 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-10 ii libaudit1 1:2.7.7-1+b2 ii libblkid1 2.29.2-4 ii libc6 2.24-17 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-4 ii libgcrypt20 1.8.1-1 ii libgpg-error0 1.27-3 ii libidn111.33-1 ii libip4tc0 1.6.1-2 ii libkmod224-1 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.3 ii libmount1 2.29.2-4 ii libpam0g1.1.8-3.6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.7-1 ii libsystemd0 234-3 ii mount 2.29.2-4 ii procps 2:3.3.12-3 ii util-linux 2.29.2-4 Versions of packages systemd recommends: ii dbus1.11.16+really1.11.16-2 ii libpam-systemd 234-3 Versions of packages systemd suggests: ii policykit-10.105-18 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.130 ii udev 234-3 -- Configuration Files: /etc/systemd/journald.conf changed [not included] /etc/systemd/logind.conf changed [not included] /etc/systemd/resolved.conf changed [not included] /etc/systemd/timesyncd.conf changed [not included]
Bug#875298: New upstream version available
Source: mlmmj Severity: wishlist A new upstream version of mlmmj is available: 1.3.0 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.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 /bin/dash Init: systemd (via /run/systemd/system)
Bug#729956: git-dpm (was Re: Bug#729956: Forwarded upstream)
On Wed, Sep 06 2017, Andreas Tille wrote: >> But just to confirm, I see that statsmodels is just using >> git-buildpackage? > > Yes. Ok, that's reassuring. I'll have a look at the packaging, since I'm already on alioth. But since DPMT is CC-ed (I normally follow via gmane), I take the occasion to say that I _really_ _REALLY_ wished the recommendation on git-dpm to be reconsidered, or at least relaxed. For a newcomer, git-dpm is overkill and underdocumented. >From an outsider, making a Debian package already looks daunting. git-dpm does not help. On the other hand, git-buildpackage is a relatively smooth progression from quilt, and it does provide some added convenience.
Bug#729956: Forwarded upstream
On Wed, Sep 06 2017, Andreas Tille wrote: > Great. What about sending a patch with your changes to the bug > report? I've added a branch debian-python3 to I always built from source, not with the debian packaging. >https://anonscm.debian.org/git/debian-science/packages/statsmodels.git > > but the build failed (for other reasons). I'd willing to work on this > but I definitely need help since I'm lacking the needed Python > knowledge. Hum, I always assumed the consensus on python packages was to manage them with git-dpm, which is something I cannot digest (and has stopped me from contributing more). But just to confirm, I see that statsmodels is just using git-buildpackage?
Bug#729956: Forwarded upstream
On Wed, Sep 06 2017, Andreas Tille wrote: > I opened an issue on Github > > https://github.com/statsmodels/statsmodels/issues/3909 > > requesting Python3 support. I concur with what was said in the issue. This is only an issue with debian's packaging. I've been using a custom build of statsmodels on python3 since years as well without problems.
Bug#741613: Switch to RFP
Control: retitle -1 RFP: glslang -- OpenGL / OpenGL ES Shading Language Reference Compiler Switch to RFP, as it's unlikely I can work on the packaging in the near future.
Bug#874258: Requires rebuild due to pyfpe ABI change
Package: python3-scipy Version: 0.18.1-2+b2 Severity: important python3 stopped building the fpectl module, requiring a rebuild of the affected modules. scipy.linalg is affected: import scipy import scipy.linalg Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/scipy/linalg/__init__.py", line 175, in from .basic import * File "/usr/lib/python3/dist-packages/scipy/linalg/basic.py", line 21, in from ._solve_toeplitz import levinson ImportError: /usr/lib/python3/dist-packages/scipy/linalg/_solve_toeplitz.cpython-35m-x86_64-linux-gnu.so: undefined symbol: PyFPE_jbuf -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-scipy depends on: ii libblas3 [libblas.so.3] 3.7.1-1+b1 ii libc6 2.24-17 ii libgcc1 1:7.2.0-3 ii libgfortran47.2.0-3 ii liblapack3 [liblapack.so.3] 3.7.1-1+b1 ii libopenblas-base [liblapack.so.3] 0.2.20+ds-2+b1 ii libquadmath07.2.0-3 ii libstdc++6 7.2.0-3 ii python3 3.5.3-3 ii python3-decorator 4.1.1-1 ii python3-numpy [python3-numpy-abi9] 1:1.12.1-3.2 Versions of packages python3-scipy recommends: ii g++ [c++-compiler]4:7.1.0-2 ii g++-7 [c++-compiler] 7.2.0-3 Versions of packages python3-scipy suggests: ii python-scipy-doc 0.18.1-2
Bug#874253: Needs rebuild due to PyFPE
Package: python3-pandas-lib Version: 0.20.3-1 Severity: important python stopped building the fpectl extension, which results in this: ImportError: C extension: /usr/lib/python3/dist-packages/pandas/_libs/tslib.cpython-35m-x86_64-linux-gnu.so: undefined symbol: PyFPE_jbuf not built. If you want to import pandas from the source directory, you may need to run 'python setup.py build_ext --inplace --force' to build the C extensions first. The python package added some Breaks against numpy, however it seems that pandas-lib was skipped. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-pandas-lib depends on: ii libc6 2.24-17 ii libgcc1 1:7.2.0-3 ii libstdc++6 7.2.0-3 ii python3 3.5.3-3 ii python3-numpy [python3-numpy-abi9] 1:1.12.1-3.2 python3-pandas-lib recommends no packages. python3-pandas-lib suggests no packages.
Bug#873499: Should depend on "gnupg | gnupg2 | gpg"
On Tue, Aug 29 2017, Colin Watson wrote: > This package contains /usr/bin/gpg itself, and is useful on its own > only for public key operations (encryption, signature verification, > listing OpenPGP certificates, etc). If you want full capabilities > (including secret key operations, network access, etc), please > install the "gnupg" package, which pulls in the full suite of tools. > > pass requires secret key operations, not just public key operations. I've been using pass with gpg only already since gpg 2.1.23 became available using an equivs package to fulfill the dependency. Can you make an example of a "secret key operation"? I think gpg's description is misleading. gpg can definitely generate and manipulate secret keys by itself for example. The only difference is that you need to depend on dirmngr/gpgsm or the tools package explicitly.
Bug#873498: Should depend on "gnupg | gnupg2 | gpg"
On Tue, Aug 29 2017, Sean Whitton wrote: >> binary itself. To avoid extra dependencies, it would be nice to update >> the dependency to "gnupg | gnupg2 | gpg". > > Well, gnupg2 is a transitional package, so no point in having that. > > Would 'gpg' be enough? The package description says it can't do > anything with secret keys, which would render git-remote-gcrypt pretty > much useless. I currently have an equivs package that provides gnupg2 while depending only on gpg to satisfy existing packages, and had no problems. I'm not sure what the description intends about "secret keys", since I can generate and manipulate secret keys as usual. gnupg just depends on additional modules by default. If you need specific functionality, such as dirmngr, I'd say you should depend on it explicitly (look at python-apt), but avoid to depend on the full suite. I never ever used gpgsm for example, and with gpg 2.1.23 I even disabled dirmngr.
Bug#873499: Should depend on "gnupg | gnupg2 | gpg"
Package: pass Version: 1.7.1-3 Severity: normal The gnupg2 package in unstable has been renamed again and split into several components. The "gnupg" package is now the full suite, while "gpg" contains the binary itself. To avoid extra dependencies, it would be nice to update the dependency to "gnupg | gnupg2 | gpg". -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pass depends on: pn gnupg2 | gnupg ii tree1.7.0-5 Versions of packages pass recommends: ii git 1:2.14.1-2 pn gnupg2 pn qrencode pn xclip Versions of packages pass suggests: ii libxml-simple-perl 2.24-1 ii perl5.26.0-5 ii python 2.7.13-2 ii python3 3.5.3-3 pn ruby
Bug#873498: Should depend on "gnupg | gnupg2 | gpg"
Package: git-remote-gcrypt Version: 1.0.1-1 Severity: normal The gnupg2 package in unstable has been renamed again and split into several components. The "gnupg" package is now the full suite, while "gpg" contains the binary itself. To avoid extra dependencies, it would be nice to update the dependency to "gnupg | gnupg2 | gpg". -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-remote-gcrypt depends on: ii git 1:2.14.1-2 pn gnupg | gnupg2 Versions of packages git-remote-gcrypt recommends: ii curl 7.55.0-1 ii rsync 3.1.2-2 git-remote-gcrypt suggests no packages.
Bug#872983: Do not depend on openbox-menu
Package: openbox Version: 3.6.1-4.1 Severity: wishlist I'm using openbox without a desktop menu entirely. Openbox 3.6.1-5 switched from Suggests: openbox-menu to Depends: openbox-menu. Can we push it back to a Suggests or a Recommends for those that don't need it? -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openbox depends on: ii libc6 2.24-15 ii libglib2.0-0 2.53.6-1 ii libice6 2:1.0.9-2 ii libobrender32v5 3.6.1-5 ii libobt2v5 3.6.1-5 ii libsm62:1.2.2-1+b3 ii libstartup-notification0 0.12-4+b2 ii libx11-6 2:1.6.4-3 ii libxau6 1:1.0.8-1+b2 ii libxcursor1 1:1.1.14-2 ii libxext6 2:1.3.3-1+b2 ii libxi62:1.7.9-1 ii libxinerama1 2:1.1.3-1+b3 ii libxrandr22:1.5.1-1 Versions of packages openbox recommends: ii obconf 1:2.0.4+git20150213-2 pn python-xdg | obsession pn scrot Versions of packages openbox suggests: ii fonts-dejavu 2.37-1 ii libxml2-dev2.9.4+dfsg1-3.1 pn menu pn openbox-gnome-session pn openbox-kde-session pn openbox-menu ii python 2.7.13-2 pn tint2
Bug#871774: Broken dependencies
Package: bogofilter-bdb Severity: normal Version: 1.2.4+dfsg1-9+b1 Probably as a result of a rebuild, bogofilter-bdb 1.2.4+dfsg1-9+b1 depends on both: --- bogofilter-common (= 1.2.4+dfsg1-9) --- bogofilter-common (= 1.2.4+dfsg1-9+b1) (UNAVAILABLE) -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-trunk-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 /bin/dash Init: systemd (via /run/systemd/system)
Bug#868433: Needs rebuild for gdal-abi-2.2
Package: libopencv-imgcodecs3.2 Version: 3.2.0+dfsg-1~exp1 Severity: normal On unstable, gdal has been upgraded to 2.2, which makes imgcodecs3.2 uninstallable.
Bug#868429: 1.12.2 uninstallable
Package: gstreamer1.0-vaapi Version: 1.12.2-1 Severity: serious The dependencies for libgstreamer-plugins-bad1.0-0 listed in the current 1.12.2 version of the package make it uninstallable. *-vaapi depends on both: libgstreamer-plugins-bad1.0-0 (< 1.12.2) libgstreamer-plugins-bad1.0-0 (>= 1.12.1)
Bug#866598: 1.10.0+dfsg-5+b2 uninstallable: conflicts with debconf
Package: python3-cairo Version: 1.10.0+dfsg-5+b1 Severity: serious Preparing to unpack .../python3-cairo_1.10.0+dfsg-5+b2_amd64.deb ... Unpacking python3-cairo (1.10.0+dfsg-5+b2) over (1.10.0+dfsg-5+b1) ... dpkg: error processing archive /var/cache/apt/archives/python3-cairo_1.10.0+dfsg-5+b2_amd64.deb (--unpack): trying to overwrite '/usr/lib/python2.7/dist-packages/debconf.py', which is also in package debconf 1.5.61 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-cairo depends on: ii libc6 2.24-12 ii libcairo2 1.14.8-1 ii python33.5.3-3 python3-cairo recommends no packages. python3-cairo suggests no packages.
Bug#864905: New upstream 4.0.6 available
Package: kicad Version: 4.0.5+dfsg1-4 Severity: wishlist Upstream released a new stable version of kicad (4.0.6). Notably, it chances some paths that should fix #860093 as well.
Bug#864601: Missing 'HuC' firmware on Intel Kabylake/Skylake/Broxton
Package: firmware-misc-nonfree Version: 20161130-3 Severity: normal The HuC firmware is currently missing for the i915 module: W: Possible missing firmware /lib/firmware/i915/kbl_huc_ver02_00_1810.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_07_1398.bin for module i915 W: Possible missing firmware /lib/firmware/i915/skl_huc_ver01_07_1398.bin for module i915 It is currently available on https://01.org/linuxgraphics/downloads/firmware -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-trunk-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 /bin/dash Init: systemd (via /run/systemd/system) firmware-misc-nonfree depends on no packages. firmware-misc-nonfree recommends no packages. Versions of packages firmware-misc-nonfree suggests: ii initramfs-tools 0.130
Bug#864197: Allow to match packages by their source name in apt_preferences
On Mon, Jun 05 2017, Julian Andres Klode wrote: >> In apt_preferences, would it possible to pin packages by their source name? > > That is planned. We already have a almost 15 year old wishlist > bug for that, so I'm merging this one into that. Missed that. Mmmh, I guess I shouldn't sweat on it...
Bug#864197: Allow to match packages by their source name in apt_preferences
Package: apt Version: 1.4.6 Severity: wishlist In apt_preferences, would it possible to pin packages by their source name? I'm a developer and I'm using pinning for several development packages. I currently list the binary packages by hand, by really I'd like to match packages by their source name in _most_ scenarios. For packages such as llvm, it's cumbersome and error-prone to list all built packages. Skipping one package will likely result in dependency issues due to version mismatches. I'd rather match on "Source: llvm-toolchain-*". Likewise, I'd like to match all packages built by "rustc". This is true for almost all packages that build more than a single binary. Would it be possible to extend apt_preferences so that in addition to Package stanzas we also have Source? -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-trunk-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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt depends on: ii adduser 3.115 ii debian-archive-keyring 2017.5 ii gpgv2.1.18-8 ii init-system-helpers 1.48 ii libapt-pkg5.0 1.4.6 ii libc6 2.24-11 ii libgcc1 1:6.3.0-18 ii libstdc++6 6.3.0-18 Versions of packages apt recommends: ii gnupg 2.1.18-8 Versions of packages apt suggests: ii apt-doc 1.4.6 ii aptitude0.8.7-1 ii dpkg-dev1.18.24 pn powermgmt-base ii python-apt 1.4.0~beta3
Bug#823110: cups-filters: Versioned dependency on imagemagick makes using graphicsmagick harder
On Wed, May 31 2017, Samuel Thibault wrote: > Hello, > > Versioned Provides are now supported, so graphicsmagick can just Provide > the appropriate version of imagemagick. I'll ask, but maybe they don't already because graphicsmagick-imagemagick-compat does not guarantee 100% feature parity. I'm using both, and certain filters/flags are just not available in gm-compat, independently of the version. > I don't see the point: we'd still want to recommend that package, so > it's installed by default without making it a requirement. Just keeping > it inside the cups-filter package gets the same dependencies in the end, > while keeping things simpler. My main point was that graphicsmagick/imagemagick is only used for those filters. In theory, if you don't have liblouis* installed, imagemagick is not going to be needed as well, which doesn't justify the hard dependency. You could put imagemagick as a recommend as well, but I always find it confusing if one feature is dependent on *both* recommended packages to be installed (sure, you can write about this in the README.Debian -- many packages do this, but it's not very friendly).
Bug#823110: cups-filters: Versioned dependency on imagemagick makes using graphicsmagick harder
Package: cups-filters Version: 1.11.6-3 Followup-For: Bug #823110 I second this, and push it further. cups-filters depends on imagemagik for "convert" alone, and it's used only in: /var/lib/cups/filter/imagetobrf /var/lib/cups/filter/texttobrf Both usage of convert are absolutely trivial, and graphicsmagick can fulfil both without problems. I originally filed a bug to downgrade the dependency of braille-dependent tools to a Recommends. Please change the dependency to: Recommends: imagemagick (>= 6.4~) | graphicsmagick-imagemagick-compat Please note that I do not want to dismiss braille support here. I'd rather see braille filters split into a separate package where we can properly Depend on the required tools instead. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups-filters depends on: ii bc 1.06.95-9+b3 ii cups-filters-core-drivers1.11.6-3 ii ghostscript 9.20~dfsg-3.2 ii imagemagick 8:6.9.7.4+dfsg-9 ii imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-9 ii libc62.24-10 ii libcups2 2.2.1-8 ii libcupsfilters1 1.11.6-3 ii libcupsimage22.2.1-8 ii libfontconfig1 2.12.1-0.1 ii libfontembed11.11.6-3 ii libgcc1 1:6.3.0-18 ii libijs-0.35 0.35-12 ii libpoppler64 0.48.0-2 ii libqpdf176.0.0-2 ii libstdc++6 6.3.0-18 ii poppler-utils0.48.0-2 Versions of packages cups-filters recommends: ii colord1.3.3-2 pn liblouisutdml-bin | liblouis-bin Versions of packages cups-filters suggests: pn antiword pn docx2txt pn foomatic-db-compressed-ppds | foomatic-db -- Configuration Files: /etc/modules-load.d/cups-filters.conf [Errno 2] No such file or directory: '/etc/modules-load.d/cups-filters.conf'
Bug#860763: imagemagick: /etc/imagemagick-6/policy.xml useless limits settings
Package: imagemagick-6-common Version: 8:6.9.7.4+dfsg-9 Followup-For: Bug #860763 I agree with the original reporter here. The policy includes arbitrary limits which cannot easily be modified by invoking the commands. If we want to ensure the "resource" limits do not get exceeded in order to avoid a potential DOS, the admin should use ulimit(1). The '' policy also kills the ability to annotate text in a pipe: echo 'x' | convert -annotate '@-' ... will fail with a 'not authorized' error, which is rather confusing as this is precisely the kind of example as done in the documentation. Of course, @[path] will allow to read-in external data, but this somehow implies that the user of convert is *not* under control of the annotation text. This seems a rather weak form of protection which prevents a rather useful feature. The only "policy" that I agree with is to disable remote delegates (I never expect an image toolkit to perform remote queries). -- Package-specific info: ImageMagick program version --- animate: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org compare: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org convert: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org composite: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org conjure: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org display: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org identify: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org import: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org mogrify: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org montage: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org stream: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Configuration Files: /etc/ImageMagick-6/policy.xml changed [not included]
Bug#860188: v40 interpreter in 2.7
On Thu, May 18 2017, Laurent Bigonville wrote: > 2.7.1 is currently in experimental and AFAIKS the v40 interpreter is enabled > by > default in that version, see: > https://www.freetype.org/freetype2/docs/subpixel-hinting.html > > Where you thinking about something else? After rechecking with the experimental version, it looks like v40 is working as it should. I was just confused by ftview not showing the engine version, but this was due to me also enabling the v38 engine as well. Sorry for the noise.
Bug#862671: Pressure wrap-around in qt4 programs
Package: xserver-xorg-input-wacom Version: 0.34.0-1 Severity: normal I'm using a wacom bamboo tablet, and noticed that starting with xserver-xorg-input-wacom 0.34.0-1 the pressure reported by the stylus in Qt4 programs wraps around at 0.5 (going back to -0.5 instead), thus never reaching 1. This looks like a botched signed integer conversion to float. Downgrading to 0.33.0-1+b1 fixes the issue (the pressure range reported by the stylus is in the 0-1 range as it should), which makes me think the issue is either an ABI breakage or some issue in the driver itself. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xserver-xorg-input-wacom depends on: ii libc6 2.24-10 ii libudev1 233-6 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.3-1+b3 ii libxrandr2 2:1.5.1-1 ii xserver-xorg-core [xorg-input-abi-24] 2:1.19.3-1 xserver-xorg-input-wacom recommends no packages. Versions of packages xserver-xorg-input-wacom suggests: ii xinput 1.6.2-1+b1
Bug#861813: Should Suggest: khal-doc
Package: khal Version: 0.9.5-2 Severity: wishlist Since a khal-doc package is available, it would be nice if khal suggested it. Thanks. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages khal depends on: ii python3-atomicwrites 1.1.5-1 ii python3-click 6.6-1 ii python3-configobj 5.0.6-2 ii python3-dateutil 2.5.3-2 ii python3-icalendar 3.8-1 ii python3-pkg-resources 33.1.1-1 ii python3-tz 2016.7-0.3 ii python3-tzlocal1.4-1 ii python3-urwid 1.3.1-2+b1 ii python3-xdg0.25-4 pn python3:any Versions of packages khal recommends: pn python3-setproctitle khal suggests no packages.
Bug#860188: v40 interpreter in 2.7
Package: libfreetype6 Version: 2.7.1-0 Severity: wishlist Freetype 2.7 introduces a new v40 truetype interpreter mode, which is not currently enabled. I've been using a custom-built freetype with the v40 interpreter enabled for the past 6 months, and I wouldn't go back. v40 has some differencies, but it really does improve on many corner cases while preserving the original glypth shape much better. When v40 is enabled, the interpreter version can be switched with an environment variable. This is not optimal (fontconfig support would be nice), but it *does* allow for people to revert to the old rendering behavior if needed. Can we enable v40 on unstable or experimental, or is there anything preventing a rendering change? -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libfreetype6 depends on: ii libc62.24-10 ii libpng16-16 1.6.28-1 ii zlib1g 1:1.2.8.dfsg-5 libfreetype6 recommends no packages. libfreetype6 suggests no packages.
Bug#859006: fontconfig alias issue
Package: xfonts-terminus Version: 4.40-2 Severity: normal I'm not sure this is related to #843982 so I'm filing it as a new report. With the upgrade to fontconfig 2.12, using 'Terminus' as a font family stopped working. xlsfonts lists the various fonts and aliases, but fc-list shows 'xos4 Terminus' as the full family name. Sure enough, using 'xos4 Terminus' in fc-enabled programs works. $ fc-list |grep Terminus /usr/share/fonts/X11/misc/ter-u24b_unicode.pcf.gz: xos4 Terminus:style=Bold /usr/share/fonts/X11/misc/ter-u22n_unicode.pcf.gz: xos4 Terminus:style=Regular ... As such, I added an alias for 'Terminus' in my 50-enable-terminus.conf so that I can still use 'Terminus' as the full family name. Is this necessary, or maybe it's an issue with fontconfig? -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfonts-terminus depends on: ii xfonts-utils 1:7.7+4 xfonts-terminus recommends no packages. Versions of packages xfonts-terminus suggests: pn xfonts-terminus-oblique ii xserver-xephyr [xserver] 2:1.19.3-1 ii xserver-xorg [xserver]1:7.7+18 ii xvfb [xserver]2:1.19.3-1 -- Configuration Files: /etc/fonts/conf.avail/50-enable-terminus.conf changed: Terminus xos4 Terminus Terminus
Bug#470417: fail2ban: please support ipv6 addresses (and ipv6tables)
Package: fail2ban Followup-For: Bug #470417 Any progress on packaging the experimental version? On a dual-stack server, the current fail2ban is useless.
Bug#858637: Acknowledgement (Downgrade dependency on python3-tk)
And after re-reading #858576, I'd say the dependency should be dropped entirely. The import error is in matplotlib itself. Seaborn shouldn't depend indirectly on matplotlib backends. python3-matplotlib recommends python3-tk already, as it should.
Bug#858637: Downgrade dependency on python3-tk
Package: python3-seaborn Version: 0.7.1-3 Severity: normal seaborn 0.7.1-3 now depends on tk, but it's not directly required for seaborn. It's only used when the tkagg backend is selected in matplotlib. For other backends, tk is not required. Please downgrade the dependency to a Recommends. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-seaborn depends on: ii python3-matplotlib 2.0.0+dfsg1-2 ii python3-numpy 1:1.12.0-2 ii python3-pandas 0.19.2-5 ii python3-scipy 0.18.1-2 pn python3:any Versions of packages python3-seaborn recommends: pn python3-bs4 ii python3-patsy 0.4.1+git34-ga5b54c2-1 python3-seaborn suggests no packages.
Bug#858617: Fails to load certain JPEG files
Package: inkscape Version: 0.92.1-1 Severity: normal inkscape fails to load (or import) the following 1.4Mb image file: https://gemex.eurac.edu/dl/?t=ada658ec062a8ff67c9360852058c3f1 This is a (seemingly) standard JPEG image produced by OpenCamera on Android. Interestingly, it fails to load only in inkscape. $ inkscape IMG_20161206_163501.jpg GdkPixbuf loader failed When doing an import, the image preview says "Linked image not found". Import fails with "Unable to load ...". I thought about an issue with libgtk-pixbuf, but all programs I tried that link with gtk-pixbuf (g3data, glade with an image widget, ...) load the image without a problem. Just resaving the image as jpeg with gimp or imagemagick's "convert" fixes the issue, so there's some sort of issue specific to this image and to inkscape as well. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages inkscape depends on: ii libaspell150.60.7~20110707-3+b2 ii libatk1.0-02.22.0-1 ii libatkmm-1.6-1v5 2.24.2-2 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libcairomm-1.0-1v5 1.12.0-1+b1 ii libcdr-0.1-1 0.1.3-3+b1 ii libdbus-1-31.10.16-1 ii libdbus-glib-1-2 0.108-2 ii libfontconfig1 2.11.94-0ubuntu1 ii libfreetype6 2.7.1-0ubuntu0.16.10.2ppa2 ii libgc1c2 1:7.4.2-8 ii libgcc11:6.3.0-10 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-2 ii libglibmm-2.4-1v5 2.50.0-1 ii libgomp1 6.3.0-10 ii libgsl22.3+dfsg-1 ii libgtk2.0-02.24.31-2 ii libgtkmm-2.4-1v5 1:2.24.5-1 ii libgtkspell0 2.0.16-1.1 ii libjpeg62-turbo1:1.5.1-2 ii liblcms2-2 2.8-4 ii libmagick++-6.q16-78:6.9.7.4+dfsg-2 ii libmagickcore-6.q16-3 8:6.9.7.4+dfsg-2 ii libmagickwand-6.q16-3 8:6.9.7.4+dfsg-2 ii libpango-1.0-0 1.40.4-1 ii libpangocairo-1.0-01.40.4-1 ii libpangoft2-1.0-0 1.40.4-1 ii libpangomm-1.4-1v5 2.40.1-3 ii libpng16-161.6.28-1 ii libpoppler-glib8 0.48.0-2 ii libpoppler64 0.48.0-2 ii libpopt0 1.16-10+b2 ii libpotrace01.14-1 ii librevenge-0.0-0 0.0.4-6 ii libsigc++-2.0-0v5 2.10.0-1 ii libstdc++6 6.3.0-10 ii libvisio-0.1-1 0.1.5-4+b1 ii libwpg-0.3-3 0.3.1-3 ii libx11-6 2:1.6.4-3 ii libxml22.9.4+dfsg1-2.2 ii libxslt1.1 1.1.29-2 pn python:any ii zlib1g 1:1.2.8.dfsg-5 Versions of packages inkscape recommends: ii aspell 0.60.7~20110707-3+b2 ii imagemagick 8:6.9.7.4+dfsg-2 ii imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-2 ii libimage-magick-perl 8:6.9.7.4+dfsg-2 pn libwmf-bin pn python-lxml ii python-numpy 1:1.12.0-2 pn python-scour pn transfig Versions of packages inkscape suggests: pn dia | dia-gnome pn libsvg-perl pn libxml-xql-perl ii pstoedit 3.70-3+b2 pn python-uniconvertor pn ruby
Bug#858292: New upstream 1.2 available
Package: goaccess Severity: wishlist Upstream is now at 1.2, but the current version in debian is only at 0.9.4.
Bug#858106: Should Suggest: python-cvxopt-doc
Package: python3-cvxopt Version: 1.1.8+dfsg-1 Severity: wishlist It would be nice if both python-cvxopt and python3-cvxopt suggested their own documentation since it is available in a separate package. Thanks! -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-cvxopt depends on: ii libamd21:4.5.4-1 ii libblas3 [libblas.so.3]3.7.0-1 ii libc6 2.24-9 ii libcholmod31:4.5.4-1 ii libcolamd2 1:4.5.4-1 ii libdsdp-5.8gf 5.8-9.1+b2 ii libfftw3-double3 3.3.5-3 ii libglpk40 4.61-1 ii libgsl22.3+dfsg-1 ii liblapack3 [liblapack.so.3]3.7.0-1 ii libopenblas-base [liblapack.so.3] 0.2.19-2 ii libsuitesparseconfig4 1:4.5.4-1 ii libumfpack51:4.5.4-1 ii python33.5.3-1 pn python3:any python3-cvxopt recommends no packages. python3-cvxopt suggests no packages.
Bug#857139: Should Suggest: libwayland-doc
Package: libwayland-dev Version: 1.12.0-1 Severity: wishlist It would be nice if libwayland-dev suggested it's reference documentation. Thanks! -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libwayland-dev:amd64 depends on: ii libwayland-bin 1.12.0-1 ii libwayland-client0 1.12.0-1 ii libwayland-cursor0 1.12.0-1 ii libwayland-server0 1.12.0-1 libwayland-dev:amd64 recommends no packages. libwayland-dev:amd64 suggests no packages.
Bug#856966: Uninstallable on sid
Package: libcore-ocaml-dev Severity: normal I was trying to install libcore-ocaml-dev, but multiple dependencies are currently unavailable, making the package uninstallable: https://packages.debian.org/sid/libcore-ocaml-dev -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#856958: Should Suggest: tar-doc
Package: tar Version: 1.29b-1.1 Severity: wishlist It would be nice if tar suggested it's own full documentation package, even if it's not fully DFSG compatible.
Bug#856956: Should Suggest: flex-doc
Package: flex Version: 2.6.1-1.3 Severity: wishlist It would be nice if flex suggested it's own documentation. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages flex depends on: ii debconf [debconf-2.0] 1.5.60 ii dpkg 1.18.23 ii install-info 6.3.0.dfsg.1-1+b2 ii libc6 2.24-9 ii m4 1.4.18-1 Versions of packages flex recommends: ii gcc [c-compiler]4:6.3.0-1 ii gcc-6 [c-compiler] 6.3.0-8 pn libfl-dev Versions of packages flex suggests: ii bison2:3.0.4.dfsg-1+b1 ii build-essential 12.3
Bug#854699: Shutdown fails with an encrypted filesystem on virtio device
On Sat, Feb 11 2017, Michael Biebl wrote:
>> I cannot explain why given the exact same partition/volume scheme by
>> lvm/cryptsetup, in one case I can shutdown cleanly, and in the other it
>> breaks.
>
> While I can reproduce the error messages on shutdown, it does *not*
> cause a dirty file system (in particular /var) here.
> I do have persistent journal enabled on the test VM, but the filing
> killing/unmount spree in systemd-shutdown properly unmounts /var.
I reinstalled a lenovo yoga x1 with the latest amd64 daily debian
netinst image yesterday. Minimal install (empty tasksel). Again, I've
just followed the guided "lvm + full disk encryption" with an ext4 root
(default settings) and grub on the mbr ("legacy" boot - not even uefi).
I ended up with the same issue. At the first shutdown triggered by C-A-D
(without even logging in), I noticed the block device error, followed by
a dirty fs on the next reboot.
This is completely unrelated to virtio.
Bug#855607: Error during installation
Package: mmm-mode Version: 0.5.4-1 Severity: normal This is shown during install: Setting up mmm-mode (0.5.4-1) ... ERROR: mmm-mode is broken - called emacs-package-install as a new-style add-on, but has no compat file. Install mmm-mode for emacs install/mmm-mode: Handling install of emacsen flavor emacs Install mmm-mode for emacs25 install/mmm-mode: Handling install of emacsen flavor emacs25 install/mmm-mode: byte-compiling for emacs25 A similar error is shown during removal. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mmm-mode depends on: ii dpkg 1.18.22 ii emacs25-lucid [emacsen] 25.1+1-3+b1 ii install-info 6.3.0.dfsg.1-1+b1 mmm-mode recommends no packages. mmm-mode suggests no packages.
Bug#804552: API reference mostly empty
On Mon, 09 Nov 2015 15:35:57 +0100 Yuri D'Elia wrote: The "API reference" (/usr/share/doc/python-pandas-doc/html/api.html) in the current package is mostly empty. For example, "General functions" contains no links at all except for section titles. The package now contains no actual documentation.
Bug#571234: Missing dependency on xbitmaps
This seems to be due that vlines2 is a bitmap in the package xbitmaps, which I didn't have installed at the time of the bug report (the only hard dependency that forced install is xterm on my current system). Maybe x11-utils should Recommend: xbitmaps, the same way x11-apps does.
Bug#824506: Issues with GTK
Please close this, I'm reporting it upstream.
Bug#848913: libeigen3-doc
Sorry, never got this message since I wasn't cc-ed. Got around it now as I'm re-checking my reports. Yes, I'm sorry about this. It was an issue with my mirror. The package is clearly fine. You can close, Thanks!
Bug#826581: Issues on broadwell
Starting with 4.8 kernels, booting with i915.enable_rc6=0 fixes this issue for me, including several other random crashes that were occurring without apparent reason. I guess it would be proper to move this report against one of the current kernel images, since the problem still persists on current sid kernels.
Bug#836458: [pkg-gnupg-maint] Bug#836458: Cannot edit key stored with an empty passphrase
On Sat, Sep 03 2016, Werner Koch wrote:
> I just tried this:
>
> gpg --edit-key some_key_with_no_passphrase
>
> At the prompt, I set a new passphrase using the "passwd" command. A bit
> annoying is that you need to repeat it for the subkey. Next I used
> "passwd" again and entered an empty passphrase. I had to confirm that I
> really want an empty one ("Yes, no protection needed") but then I got my
> passphrase less key back. FWIW, I am using the standard Gtk+ Pinentry,
I refreshed my setup a week ago, and started with a fresh environment
where I re-imported my existing keys and attempted to create new ones.
I cannot reproduce this issue with the current gpg, so I apologize for
the noise. Maybe there was some issue on my part.
Please close.
Thanks.
Bug#855313: Invalid option -l
Source: aide Severity: normal It seems that the short form of --limit: "-l", does not work: # aide.wrapper -l test /usr/bin/aide: invalid option -- 'l' Unknown option given. Exiting although it's clearly documented in the manual, man page and in the --help. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#855029: doc-base error while installing python-matplotlib-doc
Package: python-matplotlib-doc Version: 2.0.0+dfsg1-1 Severity: normal Noticed this error during installation: Processing 4 changed doc-base files... Error in `/usr/share/doc-base/python-matplotlib-doc', line 13: all `Format' sections are invalid. Note: `install-docs --verbose --check file_name' may give more details about the above error. running install-docs gives: install-docs --verbose --check /usr/share/doc-base/python-matplotlib-doc Warning in `/usr/share/doc-base/python-matplotlib-doc', line 13: file `/usr/share/doc/python-matplotlib-doc/html/index.html' does not exist. Error in `/usr/share/doc-base/python-matplotlib-doc', line 13: all `Format' sections are invalid. /usr/share/doc-base/python-matplotlib-doc: Fatal error found, the file won't be registered. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-matplotlib-doc depends on: ii libjs-jquery 3.1.1-2 python-matplotlib-doc recommends no packages. python-matplotlib-doc suggests no packages.
Bug#854699: Shutdown fails with an encrypted filesystem on virtio device
On Sat, Feb 11 2017, Michael Biebl wrote: >> reached? If I cannot get a clean journal out, there's nothing much I can >> debug. > > You could try to attach a serial device to your VM and log the output to > that device [1]. This will get us a more complete log. > Attach the complete file. But for reference, how would I proceed on real hardware instead? I had multiple occasions in the past with systemd+cryptsetup with where the root fs was left unsynced and the journal becomes corrupted. I couldn't find a way to reliable force an unit to be sequenced just prior to shutdown.target.
Bug#854699: Shutdown fails with an encrypted filesystem on virtio device
On Sat, Feb 11 2017, Michael Biebl wrote: > While I can reproduce the error messages on shutdown, it does *not* > cause a dirty file system (in particular /var) here. > I do have persistent journal enabled on the test VM, but the filing > killing/unmount spree in systemd-shutdown properly unmounts /var. > > So it seems mostly cosmetic to me. That's even more concerning that's it's so inconsistent. Any idea on how could I force an unmount exactly when shutdown.target is reached? If I cannot get a clean journal out, there's nothing much I can debug.
Bug#854814: Fails to start systemd-resolved
Package: systemd Version: 232-17 Severity: normal With the update to 232-17, systemd-resolved fails to start with the following error: Feb 10 17:46:31 test systemd[1]: Starting Network Name Resolution... -- Subject: Unit systemd-resolved.service has begun start-up -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit systemd-resolved.service has begun starting up. Feb 10 17:46:31 test systemd[10963]: systemd-resolved.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-resolved: No such file or directory -- Subject: Process /lib/systemd/systemd-resolved could not be executed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- The process /lib/systemd/systemd-resolved could not be executed and failed. -- -- The error number returned by this process is 2. Feb 10 17:46:31 test systemd[1]: systemd-resolved.service: Main process exited, code=exited, status=226/NAMESPACE Feb 10 17:46:31 test systemd[1]: Failed to start Network Name Resolution. -- Subject: Unit systemd-resolved.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit systemd-resolved.service has failed. -- -- The result is failed. -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.11.0-2 ii libaudit1 1:2.6.7-1 ii libblkid1 2.29.1-1 ii libc6 2.24-9 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-3 ii libgcrypt20 1.7.6-1 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-5 ii libkmod223-2 ii liblz4-10.0~r131-2 ii liblzma55.2.2-1.2 ii libmount1 2.29.1-1 ii libpam0g1.1.8-3.5 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3 ii libsystemd0 232-17 ii mount 2.29.1-1 ii util-linux 2.29.1-1 Versions of packages systemd recommends: ii dbus1.10.14-1 ii libpam-systemd 232-17 Versions of packages systemd suggests: ii policykit-10.105-17 pn systemd-container ii systemd-ui 3-4 Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.127 ii udev 232-17 -- Configuration Files: /etc/systemd/journald.conf changed [not included] /etc/systemd/logind.conf changed [not included] /etc/systemd/resolved.conf changed [not included] /etc/systemd/timesyncd.conf changed [not included]
Bug#854699: Shutdown fails with an encrypted filesystem on virtio device
On Fri, Feb 10 2017, Michael Biebl wrote: > Looks similar to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848044 and a lot like > https://github.com/systemd/systemd/issues/1620 Uhm, it does. Aside from the fact that it's not at all harmless as mentioned, since the root fs is not unmounted. And since the journal itself becomes corrupted, the log is lost. However there seem to be no real progress on any front, including in the bugs regarding cryptsetup and lvm2 (which I've seen before). I cannot explain why given the exact same partition/volume scheme by lvm/cryptsetup, in one case I can shutdown cleanly, and in the other it breaks. I looked at the documentation twice, but I couldn't see any way to somehow simulate the chain of events that shutdown.target should generate. I guess there's no way?
Bug#854699: Shutdown fails with an encrypted filesystem on virtio device
Package: systemd Version: 232-15 Severity: normal I've setup a VM using kvm with a virtio block device, running debian unstable and an encrypted root filesystem (automatically setup during installation as lvm+encrypted volume). Somehow, systemd tries to stop the lvm/crypto block devices way too early during shutdown, causing the root filesystem to be left unsynced. I'm running an identical setup on the real hardware, and the shutdown sequence is correct, so I assume there is some issue with how virtio block devices are seen by systemd? Aside from the system using /dev/vda instead of /dev/sda, the partition scheme and the rest of the setup is identical. This is the visible shutdown sequence on the console: [ OK ] Stopped target System Time Synchronized. [ OK ] Stopped target Network is Online. [ OK ] Stopped target Network. Stopping Raise network interfaces... [ OK ] Started Show Plymouth Reboot Screen. [11899.805246] systemd[1]: Stopped (with error) /dev/disk/by-id/lvm-pv-uuid-sHRNAT-RMhn-Xhi6-8maP-jAdc-OLVu-nS2bY3. [FAILED] Stopped (with error) /dev/disk/by-i…T-RMhn-Xhi6-8maP-jAdc-OLVu-nS2bY3. [11899.808206] systemd[1]: Stopped (with error) /dev/disk/by-id/dm-name-vda5_crypt. [FAILED] Stopped (with error) /dev/disk/by-id/dm-name-vda5_crypt. [11899.813510] systemd[1]: Stopped (with error) /sys/devices/virtual/block/dm-3. [FAILED] Stopped (with error) /sys/devices/virtual/block/dm-3. [11899.815784] systemd[1]: Stopped (with error) /dev/dm-3. [FAILED] Stopped (with error) /dev/dm-3. [11899.817433] systemd[1]: Stopped (with error) /dev/dm-0. [FAILED] Stopped (with error) /dev/dm-0. [11899.819205] systemd[1]: Stopped (with error) /sys/devices/virtual/block/dm-0. [FAILED] Stopped (with error) /sys/devices/virtual/block/dm-0. [11899.821010] systemd[1]: Stopped (with error) /dev/mapper/backup_crypt. [FAILED] Stopped (with error) /dev/mapper/backup_crypt. [11899.822558] systemd[1]: Stopped (with error) /dev/mapper/vda5_crypt. [FAILED] Stopped (with error) /dev/mapper/vda5_crypt. [FAILED] Stopped (with error) /dev/disk/by-i…0b4d27a1048270f285d317-vda5_crypt. [ OK ] Stopped LSB: Start/stop the postgrey daemon. [ OK ] Stopped target Basic System. [ OK ] Stopped target Sockets. [ OK ] Closed Syslog Socket. [ OK ] Closed UUID daemon activation socket. [ OK ] Closed D-Bus System Message Bus Socket. [ OK ] Stopped target Remote File Systems. [ OK ] Stopped target Slices. [ OK ] Removed slice User and Session Slice. [ OK ] Stopped target Paths. [ OK ] Stopped systemd-cron path monitor. [ OK ] Stopped ACPI Events Check. [ OK ] Closed ACPID Listen Socket. [ OK ] Stopped target System Initialization. Stopping Load/Save Random Seed... Stopping Update UTMP about System Boot/Shutdown... [ OK ] Stopped target Encrypted Volumes. Stopping Cryptography Setup for backup_crypt... [ OK ] Stopped Forward Password Requests to Wall Directory Watch. Stopping Cryptography Setup for vda5_crypt... Stopping Network Time Synchronization... [ OK ] Stopped Load/Save Random Seed. [ OK ] Stopped Network Time Synchronization. [ OK ] Stopped Update UTMP about System Boot/Shutdown. [ OK ] Stopped Create Volatile Files and Directories. [ OK ] Stopped Cryptography Setup for backup_crypt. [ OK ] Stopped Raise network interfaces. [ OK ] Stopped target Network (Pre). Stopping ferm firewall configuration... [ OK ] Stopped target Local File Systems. Unmounting /boot... Unmounting Temporary Directory... Unmounting /run/user/0... [ OK ] Stopped Apply Kernel Variables. [ OK ] Stopped Load Kernel Modules. [ OK ] Unmounted /run/user/0. [ OK ] Unmounted Temporary Directory. [ OK ] Stopped target Swap. Deactivating swap /dev/test-vg/swap_1... [ OK ] Deactivated swap /dev/test-vg/swap_1. [ OK ] Deactivated swap /dev/disk/by-uuid/…b58ce-41b3-4341-bd9d-98c4a7bab372. [ OK ] Deactivated swap /dev/disk/by-id/dm…vo0DXoVoelCMxoj00n4D8AA9T0tuJtogp. [ OK ] Deactivated swap /dev/disk/by-id/dm-name-test--vg-swap_1. [ OK ] Deactivated swap /dev/dm-2. [ OK ] Deactivated swap /dev/mapper/test--vg-swap_1. [ OK ] Unmounted /boot. [ OK ] Stopped File System Check on /dev/d…24dbc-8f9e-44c4-8f4b-82c25271a2a4. [ OK ] Stopped target Local File Systems (Pre). [ OK ] Stopped Remount Root and Kernel File Systems. Stopping Monitoring of LVM2 mirrors…ng dmeventd or progress polling... [ OK ] Stopped Create Static Device Nodes in /dev. [ OK ] Removed slice system-systemd\x2dfsck.slice. [ OK ] Stopped Monitoring of LVM2 mirrors,…sing dmeventd or progress polling. Stopping LVM2 metadata daemon... [ OK ] Stopped LVM2 metadata daemon. [ OK ] Stopped ferm firewall configuration. [ OK ] Stopped Cryptography Setup for vda5_crypt. [ OK ] Reached target Unmount All Filesystems. [ OK ] Removed slice system-systemd\x2dcryptsetup.slice. [ OK ] Reached target Shutdown. Since the filesys
Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible
On Mon, Feb 06 2017, Daniel Kahn Gillmor wrote: >> gpg --batch -qe -r keyid "$@" > > sure, but what's the "$@" ? Is it guaranteed to be a simple file name? > or could it be more gpg options? I left that out in a copy-paste, but it's empty. There are no extra args to given to gpg that I didn't show. > So i'm still unable to reproduce this :/ I need to output extra debugging in the cron job, but I need some extra time to set some testing environment. >> gpg: WARNING: server 'gpg-agent' is older than us (2.1.17 < 2.1.18) > > hm, that's interesting. I wonder whether it makes sense for a package > upgrade that includes user services to tell all systemd-managed user > services to reload. I could see that being useful, but i don't know how > to do it. I think that terminating the agent when unused, in combination with the socket listening is the right approach here. Thanks a lot for requesting this upstream. >> In the specific cron case, I do see the listening sockets being created >> (due to pam-systemd integration I guess) and removed at each job. > > so in that case, when the listening sockets are removed, does the > gpg-agent process itself also get terminated properly? or does the > process continue to survive even with all sockets removed? gpg-agent > should notice that removal and shut itself down. It survives, obviously :/ There are some extra questions raised by cron+pam-systemd+linger here. For instance, this should only happen because root has no session active, and thus cron starts/destroys one. But if the agent is using the systemd's socket, this should get removed and I should see more agents being started at each cron job. This is not happening. I conclude that the agent is not actually using the sockets provided by the service at all in the cron session[?]. Initially, in my report, I was actually assuming the sockets where probed by something else that's using the agent - not gpg itself, and hence my willingness to disable the socket creation entirely. For example, does using ssh trigger the creation of the agent now, simply because the sockets are available? I can answer some of those question, but I need to setup some separate testing environment.
Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible
On Mon, Feb 06 2017, Michael Biebl wrote: >> These are all single processes just waiting. >> So for gpg purposes, the agent is working as intended. >> However, I'm perplexed as of why I have so many running. > > I guess all of this could be solved if gnupg-agent was using > exit-on-idle (with some sensible default for the timeout). Or is there a > reason why you want/need to keep gnupg-agent running all time? To do the right thing, you'd need to consider the current timeout settings for each key currently in the agent.
Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible
On Sat, Feb 04 2017, Daniel Kahn Gillmor wrote: > Can you give me the exact invocation? If the agent is being > queried/auto-launched when it doesn't need to be, that'd be something > worth asking GnuPG upstream to take a look at. Nothing fancy. The command line is: gpg --batch -qe -r keyid "$@" >> There's no secret key available for the recipient, but the agent is >> somehow started, and actually gets stale. > > what does "stale" mean? simply a running agent that became older than the current release of gpg. from cron itself I also get: gpg: WARNING: server 'gpg-agent' is older than us (2.1.17 < 2.1.18) >> Now cron will actually create an user slice for root, meaning that >> there's some extra interplay with cron that I'm trying to exclude. > > what implementation of cron are you using? Are you using "systemd-cron" > or the canonical "cron" package? This is from regular "cron". But I could test the behavior on another system where I'm using systemd-cron as well. > Why do you have lingering enabled if you don't want users running > services? I do absolutely want users being able to run services. > For auto-launched gpg-agent processes (not systemd user services), i > don't think lingering is the relevant configuration. The relevant In the specific cron case, I do see the listening sockets being created (due to pam-systemd integration I guess) and removed at each job. > I/O contention? Or is it a single process that sleeps in the > background, paged out until someone queries it? These are all single processes just waiting. So for gpg purposes, the agent is working as intended. However, I'm perplexed as of why I have so many running.
Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible
On Sat, Feb 04 2017, Daniel Kahn Gillmor wrote: > What are you doing with gpg? if whatever you're doing needs the secret > keyring, the agent will be launched. if it doesn't need the secret > keyring, the agent will not be launched. In one instance, I have a couple of gpg --batch processes that are run via cron to encrypt some files. There's no secret key available for the recipient, but the agent is somehow started, and actually gets stale. Now cron will actually create an user slice for root, meaning that there's some extra interplay with cron that I'm trying to exclude. I was assuming the agent wouldn't be started at all, but it still is. > With gpg-agent as a systemd user service, when the user completely logs > out of the system, any services launched (socket-activated or otherwise) > will be stopped automatically. Extra question, if this would be true for an user with lingering enabled? Because on servers we have those enabled for all users. > Yuri, it sounds like you've got a particular scenario that you don't > like, and you're trying lots of things to change it, but i don't > understand what the scenario is. Not fully, no :/ Bug debugging some of these runaway processes is tricky and time consuming.
Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible
On Fri, Feb 03 2017, Michael Biebl wrote: >> When gpg is used via command line, the agent is started automatically >> and then it's left sitting there. But for a system without seats, the >> agent doesn't make sense. It shouldn't be running. > > That doesn't make sense. Even if you stop the sockets, once you use gpg, > gpg-agent will be auto-started as well, just using a different mechanism. It this also true also when --no-autostart is in use?
Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible
On Fri, Feb 03 2017, Michael Biebl wrote: >> I'm quite happy about the listening sockets by default on desktop, but >> on servers it's exactly the opposite. And masking is currently > > What's the problem with having them started on servers? Those are UNIX > sockets, not something which is accessible remotely. When gpg is used via command line, the agent is started automatically and then it's left sitting there. But for a system without seats, the agent doesn't make sense. It shouldn't be running. Over time, gpg even complains that "the agent is older than us", because the uptime of the server will outlast multiple gpg upgrades. I assume gpg will at some point just refuse to talk to the running agent? I wonder also if the socket is probed by other programs (?), as I've seen the agent started by users which are not using gpg by my accounts.
Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible
On Fri, Feb 03 2017, Michael Biebl wrote: >> I wouldn't change anything for stretch and keep the status quo. > > And as already said, once we have support for user services in i-s-h, > this can be revisited post stretch. i-s-h? So the reasoning here is that dh-systemd doesn't support presetting yet? I'm quite happy about the listening sockets by default on desktop, but on servers it's exactly the opposite. And masking is currently generating huge amounts of useless chat in the journal. I'm also not happy about starting any of those at root sessions by default. I'm not sure if Michael can help here, but I cannot see any option to disable user sockets for a pre-determined user (root). I can see user services becoming more popular, and these issues are going to become more common.
Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible
Package: gnupg-agent Version: 2.1.18-3 Severity: normal According to upstream, it's incorrect to ship user/sockets.target.wants/* files directly, as those cannot be disabled by the administrator. Quote: ... should instead ship this with an [install] section and enable it at package install time with "systemctl preset --global gpg-agent.socket" ... that you way can "systemctl disable --global gpg-agent.socket" whenever you like. See: https://github.com/systemd/systemd/issues/5179#issuecomment-276797851
Bug#850982: closed by Daniel Kahn Gillmor (Bug#850982: fixed in gnupg2 2.1.17-6)
On Wed, Jan 18 2017, Debian Bug Tracking System wrote: > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Daniel Kahn Gillmor > by > replying to this email. I'm not completely satisfied, unfortunately. I'd like to disable this service for *all* users by default on servers. It seems there's no systemctl command for this. You can mask the service by creating links in /etc/systemd/user/, but then each user session generates the following warning: gpg-agent.socket: Cannot add dependency job, ignoring: Unit gpg-agent.socket is masked.
Bug#851593: Should Recommend: slop
Package: maim Severity: normal Since slop is debian as well, maim should definitely recommend (or *at least* suggest) it, as maim's -s depend on slop to be installed.
Bug#850982: [pkg-gnupg-maint] Bug#850982: Add instructions to disable gpg-agent user service in README.Debian
On Thu, Jan 12 2017, Yuri D'Elia wrote: > I'm also not entirely sure on the best way to disable the socket. > Should you mask it? Just to clarify, you can mask them per-user, but placing a symlink to /dev/null in /etc/systemd/user/ has no effect. Ideas?
Bug#851138: logrotate dummy_* fails
On Thu, Jan 12 2017, Marc Haber wrote: > On Thu, Jan 12, 2017 at 12:25:14PM +0100, Yuri D'Elia wrote: >> The fix for #833982 is not enough. The current logrotate scripts for atop >> cause >> logrotate to exit with non-zero status, and run-parts to fail as a result. > > One needs additionally nocompress. Please verify _before_ updating > logrotate, the recent logrotate update seems to fix this issue as well. Verified without updating logrotate. nocompress works around it as well.
Bug#851138: logrotate dummy_* fails
Package: atop Version: 2.2.6-2 Severity: normal The fix for #833982 is not enough. The current logrotate scripts for atop cause logrotate to exit with non-zero status, and run-parts to fail as a result. Adding nomail is not enough: Jan 12 11:52:50 eab16011nb run-parts[661]: /etc/cron.daily/logrotate: Jan 12 11:52:50 eab16011nb run-parts[661]: error: error opening /var/log/atop/dummy_before.1.gz: No such file or directory Jan 12 11:52:50 eab16011nb run-parts[661]: error: error opening /var/log/atop/dummy_after.1.gz: No such file or directory Jan 12 11:52:50 eab16011nb run-parts[661]: run-parts: /etc/cron.daily/logrotate exited with return code 1 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages atop depends on: ii init-system-helpers 1.46 ii initscripts 2.88dsf-59.8 ii libc62.24-8 ii libncurses5 6.0+20161126-1 ii libtinfo56.0+20161126-1 ii lsb-base 9.20161125 ii zlib1g 1:1.2.8.dfsg-4 Versions of packages atop recommends: ii systemd-cron [cron-daemon] 1.5.4-4 atop suggests no packages.
Bug#850982: [pkg-gnupg-maint] Bug#850982: Add instructions to disable gpg-agent user service in README.Debian
On Wed, Jan 11 2017, Daniel Kahn Gillmor wrote: >> I do not want to auto-start these services for the root user. I also want to >> disable auto-start completely in servers I'm logging into. I think both are >> pretty common scenarios and deserve special mention, as systemctl --user >> disable won't work some might expect. > > fwiw, nothing is auto-started at all -- the systemd user session opens > the sockets, but doesn't launch any daemons if the sockets are never > used. > > Put in more systemd-ish terms: it's the .socket units which are > automatically enabled, not the .service units. > > does that change what you want to happen? Listening is still not a good idea in these cases. For instance, any command that probes the agent will start it as a result. This might be especially annoying for ssh, as there is still the choice between the gpg agent, ssh-agent, and nothing at all. I also don't think that these services make any sense for root (or more generally, any system user). Is there a way to restrict the unit? I'm also not entirely sure on the best way to disable the socket. Should you mask it?
Bug#850982: Add instructions to disable gpg-agent user service in README.Debian
Package: gnupg-agent Version: 2.1.17-4 Severity: normal The gpg-agent and dirmngr services are now auto-enabled for user sessions, which is actually a nice improvement. Can we tweak the instructions present in the README.Debian to include the commands required to disable this for a single user, and also globally? I do not want to auto-start these services for the root user. I also want to disable auto-start completely in servers I'm logging into. I think both are pretty common scenarios and deserve special mention, as systemctl --user disable won't work some might expect. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnupg-agent depends on: ii libassuan02.4.3-2 ii libc6 2.24-8 ii libgcrypt20 1.7.5-2 ii libgpg-error0 1.26-1 ii libnpth0 1.3-1 ii libreadline7 7.0-1 ii pinentry-gtk2 [pinentry] 1.0.0-1 Versions of packages gnupg-agent recommends: ii gnupg 2.1.17-4 Versions of packages gnupg-agent suggests: pn scdaemon
Bug#459427: changelog vs. NEWS handling
On Mon, Jan 02 2017, Russ Allbery wrote: > No matter what we do here, we're going to make a bunch of packages buggy, > because the archive is very divided on current best practice. :( Buggy in the sense that existing packages wouldn't comply with the new rules? I don't see this as "buggyness", but more of a simple transition like any other. By this metric, the current state is equally buggy. I see the current mixture of changelog and release logs as proof that maintainers would like to do the best thing for the users, but get tangled by the policy. I had the same dilemma when packaging. I *also* abuse "changelog" to ship the release notes. It feels doubly weird that I have to override the default dh_installchangelogs rule to do this.
Bug#459427: changelog vs. NEWS handling
On Sun, Jan 01 2017, Andreas Henriksson wrote: > My personal opinion is that a changelog is something where every change > is guaranteed to be logged. (And that guarantee is basically just saying > that if it's ever noticed that a change was not logged, that's indeed a > bug.) > A NEWS file is something different to me in that it's a subset of the > changelog. Sometimes that subset might be equal to the entire changelog > set, but there's no guarantee that NEWS logs every change - rather the > opposite. Fully agree here. > Additionally possibly clarify that when something is not available from > upstream people should *not* go out of their way to find something to > stuff in there. Many times I've heard that "policy says I have to" > when asking people why they're insisting on showing a bad lie down my > throut when they could have just left it out (because all > policy really said was just "...should ... if ..."). > > In other words, I support suggestion number 1 (with the extension of > standardizing the NEWS name along side changelog). I would also like this approach. Reading a release summary in a changelog is a "quirk" I've sometimes came to expect from packages. There is a push to ship a changelog, which is why many packages go to great lengths to put something there. But changelogs are rarely useful for users. I'm a developer, and I never read changelogs, as they're almost never useful unless you also have the source at hand. If I need to, I go to the source repository and get the history from there. I /could/ want the source package to include it (as it generally strips the repository metadata), but not the binary. In fact, I'd rather have a consistent NEWS location, and shift the focus to this release summary instead, while not changing the existing changelog rules. It's way more consistent with the best practices already seen everywhere in source tarballs. As an user, I really want the release summary.
Bug#848692: Acknowledgement (reportbug fails with apostrophe in full name)
Should have written "single quote" to make it more obvious.
Bug#848582: atopacctd cannot start
On Mon, Dec 19 2016, Marc Haber wrote: > This is related to #833997. You're caught by one of the two kernel > issues mentioned in this bug. The fact that atopacctd 2.2.4 starts > correctly is that it doesn't check for this kernel issue. It starts, > but never receives process accounting messages. > > I'll keep this bug report open for reference, but I don't think it's a > bug in atop. Thanks a lot for reporting the issues upstream. It seems that the same still holds for the current 4.9-rc8 image (and I don't see any sign of related changes from rc8 to the official 4.9).
Bug#848582: atopacctd cannot start
Just some extra info to report that 2.2.4 (the version I upgraded from) starts correctly.
Bug#848582: atopacctd cannot start
Package: atop Version: 2.2.5-1~exp1 Severity: normal I just upgraded to 2.2.5 to test the new logging, but atopacctd.service does not start: Dec 18 16:45:47 eab16011nb atopacctd[4018]: Version: 2.2.5 - 2016/12/15 10:12:34 Dec 18 16:45:47 eab16011nb atopacctd[4018]: accounting to /run/pacct_source Dec 18 16:45:47 eab16011nb atopacctd[4016]: unexpected error on NETLINK: Invalid argument Dec 18 16:45:47 eab16011nb systemd[1]: atopacct.service: PID 4018 read from file /run/atopacctd.pid does not exist or is a zombie. Dec 18 16:45:47 eab16011nb kernel: Process accounting resumed Dec 18 16:45:47 eab16011nb atopacctd[4018]: unexpected error on NETLINK: Invalid argument Dec 18 16:45:47 eab16011nb atopacctd[4018]: Terminated! Dec 18 16:45:47 eab16011nb systemd[1]: Failed to start Atop process accounting daemon. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-rc8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages atop depends on: ii init-system-helpers 1.46 ii initscripts 2.88dsf-59.8 ii libc62.24-8 ii libncurses5 6.0+20161126-1 ii libtinfo56.0+20161126-1 ii lsb-base 9.20161125 ii zlib1g 1:1.2.8.dfsg-4 Versions of packages atop recommends: ii systemd-cron [cron-daemon] 1.5.4-2 atop suggests no packages.
Bug#848494: Inconsistent status of active tasks
Package: taskwarrior Version: 2.5.1+dfsg-2 Severity: whishlist I'd expect that active tasks could be filtered using status:active, but only the +ACTIVE pseudo-tag is available. I see this as an inconsistency. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-rc8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages taskwarrior depends on: ii libc62.24-8 ii libgcc1 1:6.2.1-7 ii libgnutls30 3.5.7-2 ii libstdc++6 6.2.1-7 ii libuuid1 2.29-1 taskwarrior recommends no packages. taskwarrior suggests no packages.
Bug#817922: [Pkg-roundcube-maintainers] Bug#817922: Bug#817922: PEAR issues
On Fri, Dec 16 2016, Sandro Knauß wrote: > now transistion of Php7 is through and we are in freeze. Is it still an issue? Not anymore, thanks!
Bug#848161: muttrc(5) doesn't mention "bright" color prefix
Package: mutt Version: 1.7.1-5 Severity: minor I was reading muttrc(5) and the mutt manual at the same time for the "color" keyword. muttrc(5) lists conveniently all the color aliases, but fails to mention that colors can be prefixed with "bright" to make the face bold. It would be nice if this can be added with a short sentence after "Valid colors include...".. Color names can be prefixed with "bright" to make them bold. This info is included in the manual.
Bug#844067: opencv: Uninstallable package libopencv-dev after binNMU
Package: libopencv-dev Version: 3.1.0+dfsg-1~exp2 Followup-For: Bug #844067 Any news on this?
Bug#845209: Switch to clang-3.9
Package: clang-defaults Severity: wishlist Clang 3.9 is the latest release of clang, which is already available on unstable. Is there any reason to keep depending on 3.8 as the default? -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#834402: aptitude: search loses column format when redirected or piped
Package: aptitude Version: 0.8.3-1+b2 Followup-For: Bug #834402 I also consider this a regression. For instance, see this example: aptitude -s search -F '%c%M %p' '~i' > status.txt The width doesn't matter, I'm logging the output for archival. I actually *want* infinite width. But %M is now expanded to the empty string when missing, causing the output to be mis-aligned. Fine, but consider the following tweak: aptitude -s search -F '%c%1M %p' '~i' > status.txt it *still* expands to empty, even though I'm requesting 1 column of output with %1M in any condition. This is broken. -- Package-specific info: Terminal: rxvt-unicode-256color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.3 Compiler: g++ 6.2.0 20161103 Compiled against: apt version 5.0.0 NCurses version 6.0 libsigc++ version: 2.10.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20160917 cwidget version: 0.5.17 Apt version: 5.0.0 aptitude linkage: linux-vdso.so.1 (0x7ffcd5b67000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7fb2ddf5f000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fb2ddd2f000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fb2ddb05000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fb2dd8fe000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7fb2dd601000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fb2dd2f7000) libboost_iostreams.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7fb2dd0df000) libboost_filesystem.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7fb2dcec6000) libboost_system.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7fb2dccc2000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7fb2dc8b4000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fb2dc697000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fb2dc314000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fb2dc01) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fb2dbdf9000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb2dba5b000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb2db857000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fb2db64) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fb2db424000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fb2db214000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fb2dafee000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7fb2daddc000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fb2dabd4000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fb2da9cd000) /lib64/ld-linux-x86-64.so.2 (0x55d973091000) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common0.8.3-1 ii libapt-pkg5.0 1.3.1 ii libboost-filesystem1.62.0 1.62.0+dfsg-4 ii libboost-iostreams1.62.0 1.62.0+dfsg-4 ii libboost-system1.62.0 1.62.0+dfsg-4 ii libc6 2.24-5 ii libcwidget3v5 0.5.17-4+b1 ii libgcc11:6.2.0-13 ii libncursesw5 6.0+20160917-1 ii libsigc++-2.0-0v5 2.10.0-1 ii libsqlite3-0 3.15.1-1 ii libstdc++6 6.2.0-13 ii libtinfo5 6.0+20160917-1 ii libxapian301.4.1-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-11 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: ii apt-xapian-index0.49 pn aptitude-doc-en | aptitude-doc ii debtags 2.1.2 pn tasksel
Bug#843897: Should allow pyqt5
Package: python-pyqtgraph Version: 0.9.10-5 Severity: normal pyqtgraph 0.10 can now also work with pyqt5. I'd suggest adjusting the dependencies to allow this. python-pyqtgraph should depend on python-qt4 | python-pyqt5 | python-pyside python3-pyqtgraph should depend on python3-pyqt4 | python3-pyqt5 | python3-pyside Thanks. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-pyqtgraph depends on: ii python-numpy 1:1.11.2-1 ii python-qt44.11.4+dfsg-2 ii python-scipy 0.18.1-2 pn python:any Versions of packages python-pyqtgraph recommends: ii python-matplotlib 1.5.3-1 ii python-opengl 3.1.0+dfsg-1 ii python-qt4-gl 4.11.4+dfsg-2 Versions of packages python-pyqtgraph suggests: ii python-pyqtgraph-doc 0.9.10-5
Bug#843537: Fails to start dovecot/resolved with NAMESPACE spawning error
On Mon, Nov 07 2016, Michael Biebl wrote: >> Kernel: Linux 3.4.112-kvm-i386-20161024 > > I suspect your kernel is too old and/or doesn't have all necessary > features enabled. Have you checked As written, this is 3.4. > See /usr/share/doc/systemd/README.gz > It explicitly mentions 3.12 as minimum required version and all > necessary config options. Big bummer, I didn't notice the minimal version, as I didn't see anything relevant in the systemd changelog for 232. I guess this bars me from using systemd for this system[!].
Bug#843537: Fails to start dovecot/resolved with NAMESPACE spawning error
Package: systemd Version: 232-1 Severity: serious Upgrading systemd from 231-10 to either 232-1 or 232-2 breaks systemd-resolved and dovecot on my system, with the following error when the units are started: Nov 7 15:26:03 e systemd[18963]: systemd-resolved.service: Failed at step NAMESPACE spawning /bin/sh: Bad file descriptor Nov 7 15:26:03 e systemd[1]: systemd-resolved.service: Control process exited, code=exited status=226 Nov 7 15:26:17 e systemd[1]: Stopping Dovecot IMAP/POP3 email server... Nov 7 15:26:17 e systemd[19423]: dovecot.service: Failed at step NAMESPACE spawning /usr/bin/doveadm: Bad file descriptor Nov 7 15:26:17 e systemd[1]: dovecot.service: Control process exited, code=exited status=226 On top of that, udevd.service also emits the following error: Nov 7 15:26:33 e systemd[1]: systemd-udevd.service: Failed to set invocation ID on control group /system.slice/systemd-udevd.service, ignoring: Operation not supported although the service is still started. This is an i386 kvm image running linux 3.4. Downgrading to 231-10 fixes the issue. -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.4.112-kvm-i386-20161024 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.10.95-5 ii libaudit1 1:2.6.7-1 ii libblkid1 2.28.2-1 ii libc6 2.24-5 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-1 ii libgcc1 1:6.2.0-11 ii libgcrypt20 1.7.3-2 ii libgpg-error0 1.24-1 ii libidn111.33-1 ii libip4tc0 1.6.0-4 ii libkmod223-1 ii liblzma55.2.2-1.2 ii libmount1 2.28.2-1 ii libpam0g1.1.8-3.3 ii libseccomp2 2.3.1-2 ii libselinux1 2.6-2 pn libsystemd0 ii mount 2.28.2-1 ii util-linux 2.28.2-1 Versions of packages systemd recommends: ii dbus1.10.12-1 pn libpam-systemd Versions of packages systemd suggests: ii policykit-10.105-17 pn systemd-container pn systemd-ui Versions of packages systemd is related to: pn dracut pn initramfs-tools pn udev -- Configuration Files: /etc/systemd/logind.conf changed [not included] /etc/systemd/resolved.conf changed [not included]
Bug#843536: Setting a package on hold resets the auto flag
Package: aptitude Version: 0.8.3-1+b1 Severity: normal Setting a package in "iA" state on hold clears the automatic flag, but there's no reason it should. The auto state should be preserved when putting a package on hold, as forbid currently does. -- Package-specific info: Terminal: rxvt-unicode-256color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.3 Compiler: g++ 6.2.0 20160914 Compiled against: apt version 5.0.0 NCurses version 6.0 libsigc++ version: 2.10.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20160917 cwidget version: 0.5.17 Apt version: 5.0.0 aptitude linkage: linux-vdso.so.1 (0x7fffa7bfe000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7f20930c3000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f2092e93000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f2092c69000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f2092a62000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f2092765000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f209245b000) libboost_iostreams.so.1.61.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.61.0 (0x7f2092243000) libboost_filesystem.so.1.61.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.61.0 (0x7f209202a000) libboost_system.so.1.61.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.61.0 (0x7f2091e26000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7f2091a18000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f20917fb000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f2091478000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f2091174000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f2090f5d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2090bbf000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f20909bb000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f20907a4000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f2090588000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f2090378000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f2090152000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f208ff4) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f208fd38000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f208fb31000) /lib64/ld-linux-x86-64.so.2 (0x55dbc2e0b000) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common0.8.3-1 ii libapt-pkg5.0 1.3.1 ii libboost-filesystem1.61.0 1.61.0+dfsg-3+b1 ii libboost-iostreams1.61.0 1.61.0+dfsg-3+b1 ii libboost-system1.61.0 1.61.0+dfsg-3+b1 ii libc6 2.24-5 ii libcwidget3v5 0.5.17-4+b1 ii libgcc11:6.2.0-11 ii libncursesw5 6.0+20160917-1 ii libsigc++-2.0-0v5 2.10.0-1 ii libsqlite3-0 3.15.1-1 ii libstdc++6 6.2.0-11 ii libtinfo5 6.0+20160917-1 ii libxapian301.4.1-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-11 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: ii apt-xapian-index0.49 pn aptitude-doc-en | aptitude-doc ii debtags 2.1.2 pn tasksel
Bug#843257: No GTK style
Package: qt5-style-plugins Severity: important Dear maintainer, Qt 5.7 doesn't support the GTK style anymore. The qt5-gtk-themeplatform is next to useless (what I care about is consistency between widgets!). It looks like the qt5ct package (ITP #822246) could still make use of use the gtk2 style, which has unfortunately been removed. I don't use KDE, which is basically required for the 3 plasma themes also sharing some GTK themes. To get consistency between gtk2/gtk3, you have to go for unpackaged themes (such as Numix, or Arch-Theme), which provide decent uniformity. QML even adds a completely different look and behavior, that makes me cringe in all platforms I've used it on, ESPECIALLY on the desktop. This is INSANE. As a developer, providing something that integrates nicely is important. Even though I understand the logic here, the GTK+ style is important cross-platform widget set. Please build the GTK2 style. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#836734: Considerable I/O performance regression on Lenovo Carbon X1 with 4.7.0
On Wed, Nov 02 2016, Salvatore Bonaccorso wrote: >> I'm unsure at what exactly look for, as it could also be related to many >> subsystems (I'm using an ext4 fs in an encrypted volume). > > I was seeing similar issues with a X1 laptop after the update of 4.6.x > to 4.7.x, and seem dissapeared with the update to 4.8.5-1. I was > unable to deduce though the introducing change for this regression. Hi. It does seem to have improved. In fact, the last 4.7 kernel also doesn't seem to suffer from this problem. But since you mention also having an X1, can I ask if you have problems with system hangs occasionally when wifi is turned on? This problem similarly started with the 4.7 kernels. I know it's because of the wifi as I'm almost always working with a cable and never have issues, but when I work over wifi, I often get hangs when the system is displaying some heavy web page. sysrq doesn't work (the system is totally frozen). On top of that, the X1 also does seem to hang if you plug usb hid devices during boot (confirmed with other laptops with the same series). We have a batch of 12 of those laptops. Two of those developed "stains" in the brightness of the backlight. 6 of those have a defective up arrow key. The contrast of the screen also degraded quite quickly, making it much less appealing as it was supposed to be. This is the crappiest QC I've ever seen in a laptop which is supposedly top of the line. Sorry, rant over.
Bug#807125: Should Suggest: ipython-doc
Package: ipython3 Version: 5.1.0-2 Followup-For: Bug #807125 With the update to 5.1, the package now builds python-ipython-doc, but it's still not suggested by ipython[3] or python[3]-ipython. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ipython3 depends on: ii python3-ipython 5.1.0-2 ipython3 recommends no packages. ipython3 suggests no packages.
Bug#832010: Please enable LZ4 compression
On Sat, Oct 22 2016, Michael Biebl wrote: > Is it possible to enable lz4 for coredumps only? Not according to upstream. > Felipe's argument about apt already pulling in libz4 makes me less > concerned, fwiw, as we wouldn't introduce yet another new dependency in > the "base" system. I think the main argument is for supporting both compression schemes all the time if we enable lz4. I don't think it's an issue, as upstream *will* be forced to do it forever for the same reasons. I also think lz4 it's a much better choice for the journal as well, so I'm all the more in favor of enabling lz4.
Bug#838979: Suggests non-existent hevea-doc
Package: hevea Version: 2.29-1 Severity: normal Looks like that since 2.29-1 the hevea-doc package is no longer built. It would be nice if the package would be built again, or in the worst case, drop the suggests. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hevea depends on: ii ghostscript 9.19~dfsg-3 ii netpbm 2:10.0-15.3+b1 ii ocaml-base-nox [ocaml-base-nox-4.02.3] 4.02.3-7 ii tex-common 6.05 ii texlive-base2016.20160819-2 hevea recommends no packages. Versions of packages hevea suggests: ii hevea-doc2.28-1 ii texlive-latex-extra 2016.20160819-1
Bug#838279: Depends on libopencv-video-dev
Package: libopencv-shape3.0 Severity: normal Version: 3.0.0+dfsg-1~exp7 I wanted to give opencv3 a try from the experimental packaging. I noticed libopencv-shape3.0 depends on both libopencv-video-dev and libopencv-video3.0 at the same time. I suppose libopencv-video-dev is undeeded. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
