Bug#948593: [pkg-cryptsetup-devel] Bug#948593: Unable to open LUKS device (error allocating crypto tfm) for aes / cbc-essiv:sha256 sha1 LUKS header
Hello Guilhem, Le samedi, 11 janvier 2020, 14.01:53 h CET Guilhem Moulin a écrit : > On Sat, 11 Jan 2020 at 11:56:35 +, Didier 'OdyX' Raboud wrote: > > From diffing the initramfs'es, I see that > > kernel/arch/x86/crypto/aes-x86_64.ko was present in 5.3.0-3 kernels, but > > not present anymore in 5.4.0-1 or 5.4.0-2 kernels. > > kernel/arch/x86/crypto/aes-x86_64.ko isn't in 5.4.0-2's module tree. Do > you build the initramfs with MODULES="most", MODULES="dep", or something > else? Looking at the output of > > cut -d" " -f1 /proc/modules | xargs -d"\\n" /sbin/modinfo -F filename | > grep /crypto/ > > before and after (formatting and) opening a cbc-essiv:sha256 device > with > > $ cryptsetup luksFormat --type luks1 --cipher aes-cbc-essiv:sha256 > --hash sha1 /tmp/disk.img << /tmp/disk.img test_crypt << > I see that the ‘essiv’ module (and its dependency ‘authenc’) has been > loaded. Is that module missing from your 5.4.0-2 initramfs? If so, > could you please add it to ‘/etc/initramfs-tools/modules’, re-generate > the initramfs and see if that helps? It helps. :-) I can confirm that adding 'essiv' at the tail of ‘/etc/initramfs-tools/ modules’ is sufficient to let me unlock my LUKS volume with MODULES="dep"- built initramfs. Thanks for the hint! > Devices formatted since 2:1.6.1-1 (June 2013) use XTS by default and > AFAICT aren't affected. For other devices and when the initramfs is built > with MODULES!="most" I guess we should change populate_CRYPTO_MODULES() so > the ivmode is appended too, not only cipher+chainmode+ivopts. https://sources.debian.org/src/cryptsetup/2:2.2.2-1/debian/initramfs/hooks/ cryptroot/?hl=318#L318 That'd be useful yes! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#948771: guile-2.2: usrmerge variation for GREP, MKDIR_P, SED, etc.
Source: guile-2.2 Version: 2.2.6+1-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: usrmerge environment X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The attached patch sets SHELL, GREP, SED and MKDIR_P from configure, otherwise the path varies depending on weather it was built on a usrmerge system. e.g. /usr/bin/grep vs. /bin/grep. Since a /bin is a symlink to /usr/bin on a usrmerge system, use the /bin location. live well, vagrant From 60a965a7a387ef23f2689ce7980ac2d408618746 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 12 Jan 2020 18:46:38 -0800 Subject: [PATCH] debian/rules: Set SHELL, GREP SED and MKDIR_P from configure, otherwise the path varies depending on weather it was built on a usrmerge system. --- debian/rules | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index a6527b5..c4ee1b6 100755 --- a/debian/rules +++ b/debian/rules @@ -176,7 +176,8 @@ override_dh_autoreconf: override_dh_auto_configure: dh_auto_configure -- --disable-error-on-warning --disable-rpath \ - --program-suffix "-$(deb_src_eff_ver)" + --program-suffix "-$(deb_src_eff_ver)" \ + SHELL=/bin/bash GREP=/bin/grep SED=/bin/sed MKDIR_P="/bin/mkdir -p" override_dh_auto_clean: # If Makefile doesn't exist GNUmakefile will abort on distclean. -- 2.20.1 signature.asc Description: PGP signature
Bug#948770: subversion: Fix for test failures with python2
Package: subversion Version: 1.13.0-1 Severity: serious Tags: patch Justification: FTBFS User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu focal ubuntu-patch Hi James, With the impending removal of /usr/bin/python and the python package in favor of /usr/bin/python2 (shipped by 'python2'), subversion will start to fail to build due to trying to invoke /usr/bin/env python in the testsuite. The attached patch fixes the build failure in Ubuntu, where python-all-dev has already transitioned to depend on python2 instead of on python. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru subversion-1.13.0/debian/patches/python2-in-tests.patch subversion-1.13.0/debian/patches/python2-in-tests.patch --- subversion-1.13.0/debian/patches/python2-in-tests.patch 1969-12-31 16:00:00.0 -0800 +++ subversion-1.13.0/debian/patches/python2-in-tests.patch 2020-01-12 23:25:01.0 -0800 @@ -0,0 +1,16 @@ +Description: use python2 as the interpreter now for tests, not python + /usr/bin/python is no longer guaranteed to exist, per PEP 394. Use python2 + instead for compatibility. +Author: Steve Langasek +Last-Updated: 2020-01-12 + +Index: subversion-1.13.0/subversion/tests/cmdline/svneditor.py +=== +--- subversion-1.13.0.orig/subversion/tests/cmdline/svneditor.py subversion-1.13.0/subversion/tests/cmdline/svneditor.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python2 + # + # svneditor.py: a mock $SVN_EDITOR for the Subversion test suite + # diff -Nru subversion-1.13.0/debian/patches/series subversion-1.13.0/debian/patches/series --- subversion-1.13.0/debian/patches/series 2019-11-28 19:11:05.0 -0800 +++ subversion-1.13.0/debian/patches/series 2020-01-12 23:21:41.0 -0800 @@ -10,3 +10,4 @@ python-builds examples-compile-instructions workaround_EINVAL_on_kfreebsd +python2-in-tests.patch
Bug#316549: time-daemon pseudopackage
Control: affects -1 src:ntp Am 13.01.20 um 02:02 schrieb Michael Biebl: Hi Michael, On Fri, 1 Jul 2005 13:49:45 -0400 Justin Pryzby wrote: Package: chrony, ntp Severity: normal Only openntpd provides, conflicts, replaces: time-daemon. Seems all NTP clients (ntpsec, chrony, openntpd) aside from ntp itself have Conflict/Replaces/Provides: time-daemon nowadays to prevent multiple implementations being installed and enabled at the same time. This is a common mechanism defined in policy [1] It's kinda annyoing that they all have to special case ntp and must declare explicit Conflicts against ntp. Would be great if you can reconsider this and consider adding Conflict/Replaces/Provides: time-daemon to ntp Hrm, I wasn't involved in this discussion. Right now I don't see a major blocker. There are a few packages that need time sync and only depend on ntp without time-daemon (bwctl-server, lava, openstack-cloud-services, openstack-compute-nodes), we should probably file bugs against them if they only need some timekeeping facility. I remember that some time ago some monitoring solutions also depended on ntp to use and parse the output of ntpq or ntpdc, possibly on remote servers. I only see hobbit-plugins doing that right now, and only using Suggests. Unless I find a major issue I'll do this in the next upload. Bernhard
Bug#948769: avogadrolibs: does not depend on libopenbabel-dev
Source: avogadrolibs Version: 1.92.1-4 Hello, avogadrolibs seems to use neither headers nor the shared library of Open Babel, thus it should not depend on libopenbabel-dev. Sources under avogadro/qtplugins/openbabel/ seem to use the executables of Open Babel (Debian package 'openbabel') instead of its libraries. Andrius
Bug#948768: bisonc++ FTBFS in sid
Source: bisonc++ Version: 6.03.00-1 Severity: important bisonc++ FTBFS in sid with the following error: > RECOMPILE: main.cc > g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security -Wall --std=c++2a -D_FORTIFY_SOURCE=2 -c -o > tmp/main.o main.cc > > chdir tmp > g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security -Wall --std=c++2a -D_FORTIFY_SOURCE=2 -o > bin/binary main.o -lmodules -L. -lbobcat -Wl,-z,relro -Wl,-z,now -Wl,-z,now > mv: cannot stat 'enumsolution/enumsolution.ih.gch': No such file or directory > Fatal: builtin_execute - program indicates failure (status 256) The build failure appears to be the same as that observed for flexc++ and stealth, so perhaps there is a common root cause in the build chain. I've filed this bug along with the others to track it down. Cheers, tony
Bug#948767: ITP: fonts-millimetre -- geometric, constructed sans serif font
Package: wnpp Severity: wishlist * Package name: fonts-millimetre Version : 0.2 Upstream Authors: Jérémy Landes * URL : https://gitlab.com/StudioTriple/Millimetre * License : OFL-1.1 Description : geometric, constructed sans serif font From a stylistic point of view, Millimetre is a geometric, constructed sans serif, with quite wide proportions even if the width of several glyphs could contradict this statement. With its rectangular look and closed terminals, Millimetre reminds us of 60’s sans such as Aldo Novarese's Eurostile. Far from running away from this graphic universe, Millimetre embraces the retro-futuristic, architectural, technological and science-fictional connotations that come with it. Package is available at http://phd-sid.ethz.ch/debian/fonts-millimetre/
Bug#948766: flexc++ FTBFS in sid
Source: flexc++ Version: 2.07.06-1 Severity: important flexc++ FTBFS in sid with the following error: > RECOMPILE: main.cc > g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security --std=c++2a -Wall -D_FORTIFY_SOURCE=2 -c -o > tmp/main.o main.cc > > chdir tmp > g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security --std=c++2a -Wall -D_FORTIFY_SOURCE=2 -o > bin/binary main.o -lmodules -L. -lbobcat -lstdc++fs -Wl,-z,relro -Wl,-z,now > -Wl,-z,now > mv: cannot stat 'flextypes/flextypes.ih.gch': No such file or directory > Fatal: builtin_execute - program indicates failure (status 256) Thanks, tony
Bug#925629: aghermann: ftbfs with GCC-9
Sorry, yes, it was; now cc-ing both.
On Mon, 13 Jan 2020 at 03:36, Matthew Fernandez
wrote:
>
> Was this meant to also go to Andreas and the tracker?
>
> On Sun, 12 Jan 2020 at 16:26, andrei zavada wrote:
>>
>> Indeed, deleting that attribute would be best (perhaps with a link to
>> the gcc bug in a comment).
>>
>> On Mon, 13 Jan 2020 at 00:08, Matthew Fernandez
>> wrote:
>> >
>> >
>> > > On Jan 12, 2020, at 12:49, Andreas Tille wrote:
>> > >
>> > > Hi,
>> > >
>> > > I'm wondering how this bug
>> > >
>> > >
>> > > rk1968/rk1968.cc: In lambda function:
>> > > rk1968/rk1968.cc:237:103: error: expected '{' before '->' token
>> > > 237 | auto make_error_return = [] ( const char* fmt, ...)
>> > > __attribute__ ((format (printf, 2, 3))) -> int
>> > > |
>> > > ^~
>> > >
>> > >
>> > > with gcc 9 can be fixed in aghermann. Any help would be appreciated.
>> >
>> > I think you’re hitting GCC bug #90333 [0]. This claims to have been fixed
>> > in r265787, but I can still reproduce this issue with GCC 9.2.1 that
>> > includes that commit. Turning this into a C++11 attribute
>> > ([[gnu::format(printf, 2, 3)]]) makes the parse error go away, but
>> > -Wattributes still indicates GCC is ignoring it. You might need to bump
>> > that GCC issue with some evidence that the bug still exists and see what
>> > the maintainers say. If you need to bypass this urgently, I would
>> > recommend deleting the attribute as that particular one is only used to
>> > aid the compiler in creating warnings.
>> >
>> > [0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333
Bug#948765: stealth FTBFS in unstable
Source: stealth Severity: important I noticed that stealth fails to build from source in Debian sid. The build fails with the following error: > RECOMPILE: main.cc > g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security --std=c++17 -Wall -pthread -c -o tmp/main.o > main.cc > > chdir tmp > g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security --std=c++17 -Wall -pthread -o bin/binary > main.o -lmodules -L. -lbobcat -Wl,-z,relro -Wl,-z,now -lpthread > mv: cannot stat 'syslogstruct/syslogstruct.ih.gch': No such file or directory > Fatal: builtin_execute - program indicates failure (status 256) Thanks, tony
Bug#948764: pyside2: arch all FTBFS on 32-bit architectures.
Package: pyside2 Version: 5.13.2-2.2 Severity: important Tags: patch Doing a full build (architecture dependent and independent packages) of pyside2 fails on 32-bit architectures (a build that only builds architecture-dependent packages seems to be fine). I noticed this while working on updating pyside2 in raspbian, but it's happening on the reproducible builds site too, so it's not raspbian-specific. https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/pyside2.html dh_installdocs -O--buildsystem=pybuild dh_installdocs: Cannot auto-detect main package for python-pyside2-doc. If the default is wrong, please use --doc-main-package dh_installdocs: Cannot find (any matches for) "pyside3_build/py3.7-qt5.12.5-64bit-relwithdebinfo/shiboken2/doc/html" (tried in ., debian/tmp) The fix is trivial, just a replacement of 64 with ?? in the path. https://github.com/raspbian-packages/pyside2/commit/db69429c836fcdc21a07cd60dd32980a5d525790
Bug#948763: z3: cannot be built on buildds
Source: z3 Version: 4.8.7-3 Severity: serious z3 cannot be built on buildds, because its Build-Depends cannot be satisfied on buildds. Failing to build on buildds is a serious problem. | Build-Depends: debhelper-compat (= 12), |dh-python:all, python3:native, cmake, dh-python:all is broken. This is why dose-builddebcheck rejects your package. dh-python is Multi-Arch: foreign and does not need any annotation. python3:native is correct in principle. The python ecosystem more commonly uses python3:any though. dh-python parses the Build-Depends and I'm not sure that the dh-python parser understands :native today. I suggest that you prefer :any for python interpreter dependencies in general. |javahelper:all [!hppa !hurd-i386 !m68k !sh4], Just like python:all this is broken. We don't support cross building java stuff yet. If you want to get there, get in touch with debian-cr...@lists.debian.org. This needs more work on the lower layers. If you want to cross build z3 without the java bindings, please use the build profile. |default-jdk:native [!hppa !hurd-i386 !m68k !sh4] This can work, but when you switch the development kit to native, you need to explicitly depend on the runtime environment for the host architecture. That'd be default-jre-headless without :native. Unfortunately, doing so presently produces a conflict. Helmut
Bug#938157: [Python-modules-team] Bug#938157: Bug#938157: python-scipy: Python2 removal in sid/bullseye
On January 13, 2020 5:00:24 AM UTC, Drew Parsons wrote: >On 2020-01-13 12:47, Sandro Tosi wrote: >>> Thanks Sandro. There is RC bug#946624 affecting python-scipy, with >a >>> counterpart in #946625 for python3-scipy. Something subtle has >>> changed >>> in the syntax for skipping tests, I haven't figured out what yet. >Help >>> needed. >>> >>> Since that problem needs to be fixed anyway for python3-scipy, I >>> propose >>> dealing with that first before decommissioning python-scipy. I >expect >>> that whatever the fix is that's needed for python3-scipy, the same >>> patch >>> will fix the tests for python-scipy. That way we can put >python-scipy >>> to sleep on a clean bed. >> >> what is the benefit of fixing python-scipy, when we can remove it >> right now? i feel like we could just focus on fixing python3-scipy >and >> use the time/effort for python-scipy for something else :) > >It's just that there is no extra effort required in this case. >python3-scipy does indeed need the effort taken, but once that effort >is >done, it's no more effort to apply the same fix to python-scipy. So >yes, please do focus on fixing python3-scipy! :) Yes, maybe so, but delaying the python2-rm blocks other work and thus delays and complicates getting that major effort completed. Let's not. Scott K
Bug#948611: meson fails to cross build anything with the cross file from debcrossgen
Hi Jussi, On Fri, Jan 10, 2020 at 08:57:54PM +0100, Helmut Grohne wrote: > For most packages, one can use the following workaround: > set -i -e /ld=/d /usr/share/meson/debcrossgen An example where this doesn't work is systemd when building for arm64. It needs ld for linking the EFI stub. We really need a proper solution in a timely manner here. Helmut
Bug#938157: [Python-modules-team] Bug#938157: python-scipy: Python2 removal in sid/bullseye
On 2020-01-13 12:47, Sandro Tosi wrote: Thanks Sandro. There is RC bug#946624 affecting python-scipy, with a counterpart in #946625 for python3-scipy. Something subtle has changed in the syntax for skipping tests, I haven't figured out what yet. Help needed. Since that problem needs to be fixed anyway for python3-scipy, I propose dealing with that first before decommissioning python-scipy. I expect that whatever the fix is that's needed for python3-scipy, the same patch will fix the tests for python-scipy. That way we can put python-scipy to sleep on a clean bed. what is the benefit of fixing python-scipy, when we can remove it right now? i feel like we could just focus on fixing python3-scipy and use the time/effort for python-scipy for something else :) It's just that there is no extra effort required in this case. python3-scipy does indeed need the effort taken, but once that effort is done, it's no more effort to apply the same fix to python-scipy. So yes, please do focus on fixing python3-scipy! :) Drew
Bug#938157: [Python-modules-team] Bug#938157: python-scipy: Python2 removal in sid/bullseye
On Sunday, January 12, 2020 11:28:55 PM EST Drew Parsons wrote: > On 2020-01-13 09:52, Sandro Tosi wrote: > > we finally reach the point were src:python-scipy produces only leaf > > binary packages (excluding packages that are not in testing because RC > > already), so i think it's time to file for its removal, and continue > > with src:scipy. > > > > I've copied maintainers and Drew (whos been doing all the work > > recently); if i dont receive a NACK within a week, i'll file for the > > removal of src:python-scipy. > > Thanks Sandro. There is RC bug#946624 affecting python-scipy, with a > counterpart in #946625 for python3-scipy. Something subtle has changed > in the syntax for skipping tests, I haven't figured out what yet. Help > needed. > > Since that problem needs to be fixed anyway for python3-scipy, I propose > dealing with that first before decommissioning python-scipy. I expect > that whatever the fix is that's needed for python3-scipy, the same patch > will fix the tests for python-scipy. That way we can put python-scipy > to sleep on a clean bed. I don't follow this at all. It sounds to me like you are suggesting not removing a package that is ready to be removed due to python2-rm until it can be fixed. Any bugs on the python2 package are gone as soon as it is. Please don't delay removing packages in order to fix them first. Scott K signature.asc Description: This is a digitally signed message part.
Bug#948753: u-boot-sunxi: no LCD output on pinebook
Control: severity 948753 important Control: retitle 948753 u-boot-sunxi: no LCD output on pinebook > The video output isn't working on pinebook; there may be other issues as > well on other platforms. > > May downgrade the severity later, but want to block migration to testing > for now to buy time to do more testing. Well, looks like I wasn't fast enough and it migrated... downgrading severity. live well, vagrant signature.asc Description: PGP signature
Bug#938157: [Python-modules-team] Bug#938157: python-scipy: Python2 removal in sid/bullseye
> Thanks Sandro. There is RC bug#946624 affecting python-scipy, with a > counterpart in #946625 for python3-scipy. Something subtle has changed > in the syntax for skipping tests, I haven't figured out what yet. Help > needed. > > Since that problem needs to be fixed anyway for python3-scipy, I propose > dealing with that first before decommissioning python-scipy. I expect > that whatever the fix is that's needed for python3-scipy, the same patch > will fix the tests for python-scipy. That way we can put python-scipy > to sleep on a clean bed. what is the benefit of fixing python-scipy, when we can remove it right now? i feel like we could just focus on fixing python3-scipy and use the time/effort for python-scipy for something else :) -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#938157: python-scipy: Python2 removal in sid/bullseye
On 2020-01-13 09:52, Sandro Tosi wrote: we finally reach the point were src:python-scipy produces only leaf binary packages (excluding packages that are not in testing because RC already), so i think it's time to file for its removal, and continue with src:scipy. I've copied maintainers and Drew (whos been doing all the work recently); if i dont receive a NACK within a week, i'll file for the removal of src:python-scipy. Thanks Sandro. There is RC bug#946624 affecting python-scipy, with a counterpart in #946625 for python3-scipy. Something subtle has changed in the syntax for skipping tests, I haven't figured out what yet. Help needed. Since that problem needs to be fixed anyway for python3-scipy, I propose dealing with that first before decommissioning python-scipy. I expect that whatever the fix is that's needed for python3-scipy, the same patch will fix the tests for python-scipy. That way we can put python-scipy to sleep on a clean bed. Drew
Bug#944279: RFP: qabcs -- educational software for young children to learn the alphabet and get familiar with a keyboard
retitle 944279 ITP: qabcs -- educational software to learn the alphabet and get familiar with a keyboard owner 944279 ! thanks --- Hi Alexander, I will package it. Thanks for your work. Regards, Eriberto
Bug#915209: perl: FTBFS in the year 2020: cpan/Time-Local/t/Local.t failure
Package: perl Followup-For: Bug #915209 Dear Maintainer, We have this same issue on 5.24.1 for debian 9 (yes, old stable) cpan/Time-Local/t/Local ... # Failed test 'timelocal year for 1970 1 2 0 0 0' # at t/Local.t line 104. # got: '170' # expected: '70' # Failed test 'timegm year for 1970 1 2 0 0 0' # at t/Local.t line 120. # got: '170' # expected: '70' # Looks like you failed 2 tests of 187. FAILED at test 6 Just adding this here if you would be so kind as to patch it too Dean Psst! It's possible that this email contains information that is on the super secret side of confidential. So if you received it accidentally, let the sender know straight away and delete it (and the email you sent them). Also, we should let you know that any emails that come and go through Winc might be scanned, stored or read by Winc at its discretion. If you've got a question, please give us a buzz on +61 2 9335 0555 (Australia) or +64 9 271 7600 (NZ). Oh, and Winc does its best to avoid errors on emails it sends, but we can't promise that it will be error free. So, please don't hold it against us.
Bug#948734: The package should be in contrib section
On Sun, 12 Jan 2020 21:42:53 -0500 Olek Wojnar wrote: > Could you please explain your rationale? The way I read Policy, I don't > see a problem. To clarify: the package is not installing via snap > because of a licensing issue that prohibits distribution (such as > Flash), that is just to prevent needless transitions in Debian [1]. Policy states that "the packages in main must not require or recommend a package outside of main for compilation or execution" so a dependency on the snap at install time is not allowed. https://www.debian.org/doc/debian-policy/ch-archive.html#the-main-archive-area > Nothing (except saving a LOT of work) prevents any of this from going > into main. Probably time to remove the package from Debian entirely then. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#695849: #695849 RFP: glmark2 -- OpenGL (ES) 2.0 benchmark suite
I've updated the package repository and moved it to https://salsa.debian.org/games-team/glmark2 -- Cheers, Dmitry Smirnov --- And those who were seen dancing were thought to be insane by those who could not hear the music. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#948761: screen: improve examples in /etc/screenrc
Oops... doesn't seem to work if the keycode is single-quoted, so it would need to read: #hotkeys for Ctrl+PageUp/Ctrl+PageDown navigation in screen’s copy/scrollback mode #scroll the display up/down by a half screen #bindkey "^[[5;5~" eval 'copy' 'stuff ^u' #bindkey "^[[6;5~" eval 'copy' 'stuff ^d' #scroll the display up/down by a full screen #bindkey "^[[5;5~" eval 'copy' 'stuff ^b' #bindkey "^[[6;5~" eval 'copy' 'stuff ^f' Cheers, Chris.
Bug#948762: ITP: dark-gtk-themes -- dark GTK2/GTK3/Metacity theme
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: dark-gtk-themes Upstream Author : Ximin Luo based on work by OriginalSeed * URL : https://github.com/infinity0/dark-themes * License : GPL2+ Description : dark GTK2/GTK3/Metacity theme This is Ximin Luo's pair of palette swap versions of DarkCold and DarkMint themes we already have in archive. The new themes are: * DarkFire * DarkBlood Obviously, both are firmly on the reddish side. The carmine shades in DarkBlood fit the color of a certain swirl...
Bug#948761: screen: improve examples in /etc/screenrc
Package: screen Version: 4.7.0-1 Severity: wishlist Hi. Currently /etc/screenrc contains: #termcapinfo xterm|xterms|xs|rxvt ti@:te@ This could perhaps be improved to: #termcapinfo xterm*|xs|rxvt ti@:te@ (right now e.g. xterm-256color isn't matched) Also, right below it, the following could be added: #hotkeys for Ctrl+PageUp/Ctrl+PageDown navigation in screen’s copy/scrollback mode #scroll the display up/down by a half screen #bindkey '^[[5;5~' eval 'copy' 'stuff ^u' #bindkey '^[[6;5~' eval 'copy' 'stuff ^d' #scroll the display up/down by a full screen #bindkey '^[[5;5~' eval 'copy' 'stuff ^b' #bindkey '^[[6;5~' eval 'copy' 'stuff ^f' These seem to work nicely in addition to disabling the alternate screen buffer (which allows scrolling in the terminal, but not if the output was made while the session wasn't attached and thus copy/scrollback mode needs to be used again) Cheers, Chris.
Bug#948760: berusky2: Compile without warnings
Package: berusky2
Version: 0.10+git20170630-3
Severity: normal
Tags: patch
Dear Maintainer,
Currently when Berusky2 is compiled it generates a *lot* of compile
warnings, some of which seem serious. I've fixed all these warnings and
have attached a patch (I've attached it as an attachment rather than
inline because it is quite large (3651 lines) and I don't want to
clutter up the bug report log).
I've set the severity to "normal" since there are so many warnings and I
suspect that my patch may fix some crashes. But feel free to downgrade
as you see fit.
Here is a short summary (not meant to be comprehensive) of the changes I
have made:
* Some functions (such as chdir() and getcwd()) warn if their return
values are not checked. I have added checks to all such functions
which did not already have checks.
* I've added a few assertions where needed to avoid warnings.
* I've changed many calls to sprintf() which may overflow to calls to
snprintf(). I also check the return value of the snprintf() call
since the output may be truncated.
* I've replaced the deprecated ALUT functions alutLoadWAVFile() and
alutUnloadWAV() with local implementations (s/alut/adas/).
* Apparently G++ doesn't like calls to memset() on a non-trivial type
(all of these were structs). So I've casted the pointer to (void *)
before passing it to memset(). Is there a better way to do this? I
don't know C++ very well (the warning said to "use assignment or
value-initialization instead").
* Numerous other miscellaneous fixes.
The coding style of Berusky2 is inconsistent, so I just tried to use the
local style in whatever file (or part of file!) I was editing.
I finally (sort of) figured out how to use quilt properly, and I've
added a DEP-3 compliant header to my patch. Please remember to update
the Bug-Debian (this bug), Reviewed-by (you), and Last-Update headers
before you add the patch.
Since Berusky2 now compiles without warnings, I recommend adding -Werror
to the C{,XX}FLAGS. I guess this would be done by adding it to
DEB_CXXFLAGS_MAINT_APPEND (like you did in 89e7190) and
DEB_CFLAGS_MAINT_APPEND.
I tested running Berusky2 periodically while writing the patch to make
sure that I didn't introduce any bugs. I also tested it after I finished
writing the patch. But I did not test very thoroughly (I just started it
and made a few moves in a level). However, the only part that seems
likely to introduce new bugs is the replacement of the deprecated ALUT
functions, and sound still works fine. So I'm pretty sure I didn't
introduce any new bugs.
I have attached the patch after the message.
Thanks,
Asher
--
...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning.
-- Matt Welsh
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages berusky2 depends on:
ii berusky2-data 0.9-2
ii libalut01.1.0-6
ii libc6 2.29-7
ii libgcc1 1:9.2.1-22
ii libgl1 1.1.0-1+b1
ii libglu1-mesa [libglu1] 9.0.1-1
ii libopenal1 1:1.19.1-1+b1
ii libsdl-image1.2 1.2.12-12
ii libsdl1.2debian 1.2.15+dfsg2-5
ii libstdc++6 9.2.1-22
ii libvorbisfile3 1.3.6-2
ii libx11-62:1.6.8-1
ii zlib1g 1:1.2.11.dfsg-1+b1
berusky2 recommends no packages.
berusky2 suggests no packages.
-- no debconf information
Description: Make Berusky2 compile cleanly with no warnings
Berusky2 used to generate a *lot* of warnings when compiled. Some of
these were not too serious, but some seemed like they could possibly
allow buffer overflows. This patch likely fixes many potential
crashes as well.
Author: Asher Gordon
Bug-Debian: TODO
Reviewed-by: TODO
Last-Update: 2020-01-12
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: berusky2/src/adas/adas.c
===
--- berusky2.orig/src/adas/adas.c
+++ berusky2/src/adas/adas.c
@@ -214,7 +214,7 @@ void adas_Init(ADAS_INIT_DATA * p_adas_d
memcpy(_data, p_adas_data, sizeof(ADAS_INIT_DATA));
- p_Device = alcOpenDevice((ALCubyte *) p_adas_data->Implementation);
+ p_Device = alcOpenDevice(p_adas_data->Implementation);
if (p_Device) {
bDevice = 1;
p_Context = alcCreateContext(p_Device, NULL);
@@ -222,14 +222,14 @@ void
Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot
Hey I got lucky with a google search and found what would be a dupe if it were ever finished. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805821 Somebody else managed to track the problem down. For some reason systemd is only watching for /dev/dm-* rather than the long dmraid device names. This is the equivalent of watching for /dev/sda1 instead of the UUID. Nikita Youshchenko: > This way boot is ok (i.e. no delays and swap is enabled). But this is ugly > and unreliable. This does work when there's only one raid array in the OS, which is most of the time. These are two real devices (no symlinks) with the same major and minor numbers.
Bug#948734: The package should be in contrib section
Hi Shengjing, thanks for the bug report. On 1/12/20 12:02 PM, Shengjing Zhu wrote: > Source: cyphesis-cpp > Version: 0.7.0~snap1 > Severity: serious > > This package now installs the real program via snap. > This shouldn't be in main. Could you please explain your rationale? The way I read Policy, I don't see a problem. To clarify: the package is not installing via snap because of a licensing issue that prohibits distribution (such as Flash), that is just to prevent needless transitions in Debian [1]. Nothing (except saving a LOT of work) prevents any of this from going into main. If you have some clarification on Policy that I haven't seen, please share. Thanks! -Olek [1] https://lists.debian.org/debian-devel-games/2019/12/msg0.html signature.asc Description: OpenPGP digital signature
Bug#948759: apache2: config_vars.mk contains unsanitized CXXFLAGS/-ffile-prefix-map
Source: apache2
Version: 2.4.41-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath environment
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
The CXXFLAGS variable was not getting cleaned in
debian/clean_config_vars, which meant that while -fdebug-prefix-map was
cleaned from CFLAGS, it was still present in CXXFLAGS.
Additionally, support for -ffile-prefix-map was added to GCC and dpkg
and is used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.
The attached patch fixes both issues, and I believe should result in
apache2 being reproducible again in Debian.
Thanks for maintaining apache2!
live well,
vagrant
From 6ef03f7cce3b45999a81485e9bfa178971115d60 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Sun, 12 Jan 2020 18:04:01 -0800
Subject: [PATCH 2/2] Also clean CXXFLAGS and -ffile-prefix-map.
---
debian/clean_config_vars | 6 --
debian/rules | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/debian/clean_config_vars b/debian/clean_config_vars
index f88ab3ca..90867080 100755
--- a/debian/clean_config_vars
+++ b/debian/clean_config_vars
@@ -6,6 +6,7 @@ my %FLAGS = {
'CFLAGS' => $ARGV[0],
'CPPFLAGS' => $ARGV[1],
'LDDFLAGS' => $ARGV[2],
+ 'CXXFLAGS' => $ARGV[3],
};
@@ -22,7 +23,8 @@ sub clean_and_deduplicate
$return_flags .= "$flag " unless
$flag =~ m/PLATFORM/ ||
$flag =~ m/-DBUILD_DATETIME/ ||
- $flag =~ m/-fdebug-prefix-map/;
+ $flag =~ m/-fdebug-prefix-map/ ||
+ $flag =~ m/-ffile-prefix-map/;
}
return $return_flags;
}
@@ -36,7 +38,7 @@ open(TMP_CONFIG_VARS, ">", "tmp_config_vars.mk") || die("tmp_config_vars.mk: $1"
while(my $line = )
{
chomp $line;
- unless ($line =~ m/(^|_)(LD|CPP|C)FLAGS/)
+ unless ($line =~ m/(^|_)(LD|CPP|C|CXX)FLAGS/)
{
print TMP_CONFIG_VARS "$line\n";
}
diff --git a/debian/rules b/debian/rules
index 508dde96..954da288 100755
--- a/debian/rules
+++ b/debian/rules
@@ -74,7 +74,7 @@ clean-config-vars-stamp: debian/tmp/usr/share/apache2/build/config_vars.mk debia
# Clean up config_vars.mk so that flags that are only intended for the
# compilation of apache2 itself are not used by apxs for compiling
# modules.
- perl ./debian/clean_config_vars '$(AP2_CFLAGS)' '$(AP2_CPPFLAGS)' '$(AP2_LDFLAGS)'
+ perl ./debian/clean_config_vars '$(AP2_CFLAGS)' '$(AP2_CPPFLAGS)' '$(AP2_LDFLAGS)' '$(CXXFLAGS)'
touch $@
%: %.in
--
2.20.1
signature.asc
Description: PGP signature
Bug#948758: RM: rpy2-2.8 -- RoQA; python2-only; superseeded by src:rpy2; leaf package
Package: ftp.debian.org Severity: normal
Bug#948757: apache2: embeds path to EGREP in config_vars.mk
Source: apache2 Version: 2.4.41-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: usrmerge X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The EGREP variable is stored in config_vars.mk and is derived from the GREP variable, which may get set to /bin/grep or /usr/bin/grep on usrmerge where /bin is a symlink to /usr/bin. The attached patch sets GREP=/bin/grep in the configure phase to work around this issue, since /bin/grep will work correctly on both usrmerge and non-usrmerge systems. Thanks for maintaining apache2! live well, vagrant From 15184b6753b84174535d29360672f9362e288d76 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 12 Jan 2020 17:44:23 -0800 Subject: [PATCH] Set GREP=/bin/grep during configure for reproducible builds. The EGREP variable is stored in config_vars.mk and is derived from the GREP variable, which may get set to /bin/grep or /usr/bin/grep on usrmerge where /bin is a symlink to /usr/bin. --- debian/rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index 44cfa8a0..508dde96 100755 --- a/debian/rules +++ b/debian/rules @@ -117,7 +117,7 @@ configure-stamp: prebuild-checks-stamp support/suexec-custom.c --enable-mods-shared="all brotli cgi ident authnz_fcgi imagemap cern_meta proxy_fdpass proxy_http2 bucketeer case_filter case_filter_in" \ --enable-mods-static="unixd logio watchdog version" \ CFLAGS="$(AP2_CFLAGS)" CPPFLAGS="$(AP2_CPPFLAGS)" LDFLAGS="$(AP2_LDFLAGS)" \ - LTFLAGS="$(AP2_LTFLAGS)" SHELL=/bin/bash + LTFLAGS="$(AP2_LTFLAGS)" SHELL=/bin/bash GREP=/bin/grep touch $@ debian/config-dir/apache2.conf: debian/config-dir/apache2.conf.in -- 2.20.1 signature.asc Description: PGP signature
Bug#938157: python-scipy: Python2 removal in sid/bullseye
On Fri, 30 Aug 2019 07:46:33 + Matthias Klose wrote: > Package: src:python-scipy > Version: 1.2.2-7 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal we finally reach the point were src:python-scipy produces only leaf binary packages (excluding packages that are not in testing because RC already), so i think it's time to file for its removal, and continue with src:scipy. I've copied maintainers and Drew (whos been doing all the work recently); if i dont receive a NACK within a week, i'll file for the removal of src:python-scipy. Regards, Sandro
Bug#948756: scgi: should this package be removed?
Source: scgi Severity: serious Hello, i think we should remove scgi from debian: * upstream last release was in 2014. no commit ever since * python2-only * leaf package If i dont hear back within a week with a good reason to keep this package, i'll file for its removal. Regards, Sandro -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#948755: icmake: binary-indep build ("dpkg-buildpackage -A") fails
Source: icmake Version: 9.03.00-1 Severity: important Filing a bug report for visibility while I work with the upstream maintainer on the fix. Starting with 9.03.00-1, the package FTBFS when only the binary-indep target is invoked - e.g., see: https://buildd.debian.org/status/fetch.php?pkg=icmake=arm64=9.03.00-1=1578875515=log Cheers, tony
Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language
On Sun, 12 Jan 2020 at 16:56, Adam Borowski wrote: > On Sun, Jan 12, 2020 at 02:13:18PM -0800, Matthew Fernandez wrote: > > * Package name: rumur > >Version : 2020.01.11-1 > > > Changes since the last upload: > > > >* New upstream release. > > Hi! > I'm afraid your package fails autopkgtests, due to a bogus dependency on > non-existing "libgmp". > > In the test control file, you declare: > Depends: build-essential, libfl2, libgmp, python3 (>= 3.6), rumur > > on the other hand, the built package already has: > Depends: libc6 (>= 2.15), libgcc1 (>= 1:3.0), libgmp10, libgmpxx4ldbl, > libstdc++6 (>= 9) > with correct dependencies. > > Ie, you don't need to specify that explicitly, as it's error-prone, and > will > get out of sync the moment libgmp bumps its soname. Thus, you can just > drop > that dependency -- requiring rumur itself will pull in its deps. Thanks for the quick reply. The autopkgtests actually need the GMP headers as well as .so. So I guess I need libgmp-dev? Or does this need an explicit major version in the package name as well?
Bug#316549: time-daemon pseudopackage
Hi Berni On Fri, 1 Jul 2005 13:49:45 -0400 Justin Pryzby wrote: > Package: chrony, ntp > Severity: normal > > Only openntpd provides, conflicts, replaces: time-daemon. Seems all NTP clients (ntpsec, chrony, openntpd) aside from ntp itself have Conflict/Replaces/Provides: time-daemon nowadays to prevent multiple implementations being installed and enabled at the same time. This is a common mechanism defined in policy [1] It's kinda annyoing that they all have to special case ntp and must declare explicit Conflicts against ntp. Would be great if you can reconsider this and consider adding Conflict/Replaces/Provides: time-daemon to ntp Regards, Michael [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#replacing-whole-packages-forcing-their-removal signature.asc Description: OpenPGP digital signature
Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language
On Sun, Jan 12, 2020 at 02:13:18PM -0800, Matthew Fernandez wrote: > * Package name: rumur >Version : 2020.01.11-1 > Changes since the last upload: > >* New upstream release. Hi! I'm afraid your package fails autopkgtests, due to a bogus dependency on non-existing "libgmp". In the test control file, you declare: Depends: build-essential, libfl2, libgmp, python3 (>= 3.6), rumur on the other hand, the built package already has: Depends: libc6 (>= 2.15), libgcc1 (>= 1:3.0), libgmp10, libgmpxx4ldbl, libstdc++6 (>= 9) with correct dependencies. Ie, you don't need to specify that explicitly, as it's error-prone, and will get out of sync the moment libgmp bumps its soname. Thus, you can just drop that dependency -- requiring rumur itself will pull in its deps. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#948754: RM: python-openid -- RoQA; python2-only; superseeded by python3-openid; last upstream release 10 years ago; no more rdeps
Package: ftp.debian.org Severity: normal
Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot
Am 13.01.20 um 01:10 schrieb Joshua Hudson: > I double-checked with init=/bin/sh. All the devices already exist in > /dev/mapper before /linuxrc shuts down the initrd copy of udev. > systemd will never see the activation of a udev device because that's > already done. They're all active. > Well, the udev database from the initrd is transferred to the real root (via /run/udev) So I don't see how this explains the problem. signature.asc Description: OpenPGP digital signature
Bug#947936: chrony: Does (still) not start properly on boot on buster
On 2020-01-13T00:48+0100, Michael Biebl wrote: Am 13.01.20 um 00:43 schrieb Michael Biebl: Am 13.01.20 um 00:05 schrieb Vincent Blut: On 2020-01-12T23:24+0100, Michael Biebl wrote: Am 12.01.20 um 23:08 schrieb Vincent Blut: We probably should not keep this hack forever, but instead let timedated read known NTP implementation unit names from usr/lib/systemd/ntp-units.d/*.list since this has been reintroduced in systemd 243. I added the necessary bits in chrony 3.5-5. Hm, I don't see how this change in timedate would actually help in this situation. Support for ntp-units.d in timedated/timedatectl just enables that if you use "timedatectl set-ntp true|false" it will prefer alternatives if installed. Doesn’t systemd-timesyncd look for foreign services in ntp-units.d/ when starting? I thought that was the case and that it remained inactive in case an NTP implementation with a higher priority was found there. Reading through the diff at https://github.com/systemd/systemd/pull/13136 that doesn't seem to be the case. ntp-units.d is only used by timedated, not timesyncd. Fwiw, there is this related MR https://salsa.debian.org/systemd-team/systemd/merge_requests/61 I mentioned another bug report about a similar issue with ntp. Ideally, only one NTP client should be enabled at a time. Note that we restore timesyncd (if it is enabled) on chrony removal to not wait for the next reboot to get the clock synchronized again, so if having only one NTP client enabled at a time is where we are heading for, then I’ll have to drop that code snippet. signature.asc Description: PGP signature
Bug#948696: Concerning libtimezonemap in Debian (ITP #948696)
Hi Jeremy, thanks for your prompt answer! On Sun, 12 Jan 2020, Jeremy Bicha wrote: > Hi. Thanks for emailing me. libtimezonemap is only used in Ubuntu for > the Ubiquity installer and for unity-control-center so there wasn't > any need for the package in Debian. Will Ubuntu ship Cinnamon 4.4? And if, will Ubuntu use the Debian packages? Will there be any problem if there is a Debian version of libtimezonemap and a Ubuntu-native (not -N version!) of it? I just want to be sure that uploading it to Debian doesn't create too much troubles. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot
I double-checked with init=/bin/sh. All the devices already exist in /dev/mapper before /linuxrc shuts down the initrd copy of udev. systemd will never see the activation of a udev device because that's already done. They're all active.
Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot
That turned out to be really easy to track down. The reason you aren't getting any notification of the raid array being activated is it was already activated in initrd. It will not be activated a second time. dmraid has some interesting principles in play here. 1) dmraid has its own idea of persistent, path-independent names of devices. 2) dmraid is incompatible with UUID= or LABEL=; all users of dmraid must have the raid device names in /etc/fstab and on the kernel command line. GRUB_LINUX_DISABLE_UUID *must* be used. 3) Under normal operation, dmraid is included in initrd as soon as it is installed on the system. 4) If dmraid is installed in initrd, udev will discover the dmraid devices before / is mounted. If udev discovers the dmraid devices, it will start the system. 5) Redundant activations are not possible. So the effect of all this is really simple. systemd can just assume that a dmraid device under /dev/mapper is active if the device node exists at all, and on any reasonable system it doesn't even need to poll the device path; it can check *once* and know the success or failure immediately.
Bug#948626: kicad: Closing pcbnew hangs main kicad process
On Sat, 11 Jan 2020 14:26:12 +0100 Bernhard Übelacker wrote: > Could you recheck - could it be that this pid 309563 > was still running from a previous kicad session and > your hanging kicad was another, newer process? Definitely a new one. To retest: $ pgrep kicad [nothing] [run kicad, get it stuck] $ pgrep kicad 493905 Just a single one running. (gdb) bt #0 0x7faf28a244bc in wxClassInfo::~wxClassInfo() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #1 0x7faf2837c720 in __run_exit_handlers (status=0, listp=0x7faf284f9718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 #2 0x7faf2837c85a in __GI_exit (status=) at exit.c:139 #3 0x7faf28366bc2 in __libc_start_main (main= 0x56538577f880, argc=1, argv=0x7fff267a6058, init=, fini=, rtld_fini=, stack_end=0x7fff267a6048) at ../csu/libc-start.c:342 #4 0x56538578412a in _start () To clarify, this was after simply clicking the windomanager [X] button to close the pcbnew window; I was intending to leave the toplevel kicad window still open. > Because, I guess, the __run_exit_handlers should just > run at process exit. > > The last line in your backtrace point to this line, > with a loop which would fit into the picture: > > https://sources.debian.org/src/wxwidgets3.0/3.0.4+dfsg-15/src/common/object.cpp/#L177 > > When you are in gdb and try to leave the current function > by "finish", do you get again to the debugger prompt, > or is it causing already the 100% CPU usage again? I'll try: (gdb) finish Run till exit from #0 0x7faf28a244bc in wxClassInfo::~wxClassInfo() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 That returns to 100% CPU spin which I believe it'll continue on until SIGTERM. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Bug#947936: chrony: Does (still) not start properly on boot on buster
Am 13.01.20 um 00:43 schrieb Michael Biebl: > Am 13.01.20 um 00:05 schrieb Vincent Blut: >> On 2020-01-12T23:24+0100, Michael Biebl wrote: >>> Am 12.01.20 um 23:08 schrieb Vincent Blut: > We probably should not keep this hack forever, but instead let timedated read known NTP implementation unit names from usr/lib/systemd/ntp-units.d/*.list since this has been reintroduced in systemd 243. I added the necessary bits in chrony 3.5-5. >>> >>> Hm, I don't see how this change in timedate would actually help in this >>> situation. >>> Support for ntp-units.d in timedated/timedatectl just enables that if >>> you use "timedatectl set-ntp true|false" it will prefer alternatives if >>> installed. >> >> Doesn’t systemd-timesyncd look for foreign services in ntp-units.d/ when >> starting? >> I thought that was the case and that it remained inactive in case an >> NTP implementation with a higher priority was found there. > > Reading through the diff at > https://github.com/systemd/systemd/pull/13136 that doesn't seem to be > the case. ntp-units.d is only used by timedated, not timesyncd. > > Fwiw, there is this related MR https://salsa.debian.org/systemd-team/systemd/merge_requests/61 Ideally, only one NTP client should be enabled at a time. signature.asc Description: OpenPGP digital signature
Bug#947936: chrony: Does (still) not start properly on boot on buster
Am 13.01.20 um 00:05 schrieb Vincent Blut: > On 2020-01-12T23:24+0100, Michael Biebl wrote: >> Am 12.01.20 um 23:08 schrieb Vincent Blut: >>> We probably should not keep this hack forever, but instead let timedated >>> read known NTP implementation unit names from >>> usr/lib/systemd/ntp-units.d/*.list since this has been reintroduced in >>> systemd 243. I added the necessary bits in chrony 3.5-5. >> >> Hm, I don't see how this change in timedate would actually help in this >> situation. >> Support for ntp-units.d in timedated/timedatectl just enables that if >> you use "timedatectl set-ntp true|false" it will prefer alternatives if >> installed. > > Doesn’t systemd-timesyncd look for foreign services in ntp-units.d/ when > starting? > I thought that was the case and that it remained inactive in case an > NTP implementation with a higher priority was found there. Reading through the diff at https://github.com/systemd/systemd/pull/13136 that doesn't seem to be the case. ntp-units.d is only used by timedated, not timesyncd. signature.asc Description: OpenPGP digital signature
Bug#942727: sane-backends: New upstream release 1.0.28 available
Package: src:sane-backends Followup-For: Bug #942727 Hi, I noticed that the maintainer already has some packaging work done for the new upstream release, so I tried building updated packages locally and I think the result is good enough. For those who need the newer code and don't want to wait for the maintainer upload here are some instructions for building updated packages locally. You would need 'git-buildpackage' and 'pbuilder'. I decline any responsibility for any damage. :) Create a pbuilder base: $ DIST=sid ARCH=amd64 BUILDER=pbuilder git pbuilder create --extrapackages "ca-certificates" Check out the latest debian source package and build it. $ mkdir ~/debian-workspace $ cd debian-workspace $ git clone git://jff.email/opt/git/sane-backends.git $ cd sane-backends $ git checkout release/experimental/1.0.28-1_experimental1 $ DIST=sid ARCH=amd64 BUILDER=pbuilder gbp buildpackage --git-debian-branch="release/experimental/1.0.28-1_experimental1" --git-upstream-branch=upstream --git-pbuilder -d You will find the resulting packages in ../build-area/ which can be installed with: $ sudo dpkg -i ../build-area/*.deb Hopefully you can use your scanner now. Dear Maintainer, I noticed there are still some minor lintian warnings here and there, if you need some help addressing them just let me know. Thanks, Antonio -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
Bug#948753: u-boot-sunxi: block migration to testing
Package: u-boot-sunxi Version: 2020.01+dfsg-1 Severity: serious The video output isn't working on pinebook; there may be other issues as well on other platforms. May downgrade the severity later, but want to block migration to testing for now to buy time to do more testing. live well, vagrant signature.asc Description: PGP signature
Bug#947936: chrony: Does (still) not start properly on boot on buster
On 2020-01-12T23:24+0100, Michael Biebl wrote: Am 12.01.20 um 23:08 schrieb Vincent Blut: On 2020-01-12T20:41+0100, Michael Biebl wrote: Am 12.01.20 um 20:15 schrieb Santiago Vila: My theory is that this is some kind of race condition. I initially cloned the machine from another one where this happened. Then I discovered that the problem also happens (randomly) in a brand new machine if I copy the journal from the "bad" machine. However, there is nothing special about the journal (or at least "journalctl --verify" says it's ok), except maybe that it's several megabytes long. Could it be that systemd spends some time processing the journal at boot time and this is what triggers the race condition? On my buster system: an 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Looking at job systemd-timesyncd.service/stop conflicted_by=yes Jan 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Looking at job systemd-timesyncd.service/start conflicted_by=no Jan 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Fixing conflicting jobs systemd-timesyncd.service/stop,systemd-timesyncd.service/start by deleting job systemd-timesyncd.service/start Jan 12 20:04:46 debian systemd[1]: chrony.service: Looking at job chrony.service/start conflicted_by=no Jan 12 20:04:46 debian systemd[1]: chrony.service: Looking at job chrony.service/stop conflicted_by=no Jan 12 20:04:46 debian systemd[1]: chrony.service: Fixing conflicting jobs chrony.service/start,chrony.service/stop by deleting job chrony.service/stop Jan 12 20:04:46 debian systemd[1]: Found redundant job systemd-timesyncd.service/stop, dropping from transaction. Those lines are missing on GCE system. Instead I see Jan 12 17:02:01 d1 systemd[1]: Keeping job systemd-timesyncd.service/start because of sysinit.target/start Jan 12 17:02:01 d1 systemd[1]: Keeping job chrony.service/stop because of systemd-timesyncd.service/start Jan 12 17:02:01 d1 systemd[1]: systemd-timesyncd.service: Installed new job systemd-timesyncd.service/start as 119 Jan 12 17:02:01 d1 systemd[1]: chrony.service: Job 82 chrony.service/start finished, result=canceled Jan 12 17:02:01 d1 systemd[1]: chrony.service: Installed new job chrony.service/stop as 121 Jan 12 17:02:01 d1 systemd[1]: chrony.service: Job 121 chrony.service/stop finished, result=done The problem is, that the transaction is computed *before* ConditionFileIsExecutable=!/usr/sbin/chronyd is evaluated (conditions are evaluation just before the binary is executed) and it might indeed depend on the ordering, in which the jobs are scheduled. Makes sense. Thanks for debugging this. So, the simplest fix would be to drop the line Conflicts=systemd-timesyncd.service openntpd.service ntp.service ntpsec.service from chrony.service. This way, systemd will schedule the start of both services. chrony.service will be started properly and for systemd-timesyncd.service the ConditionFileIsExecutable will kick in. If there is no risk of regression, then I’m all for making this change. I don't see a risk for a regression, given that systemd in buster ships disable-with-time-daemon.conf. So if the drop the Conflicts again, we'd basically have the situation again as in stretch. Not for chrony and openntpd. Both were already in conflict with systemd-timesyncd.service in Stretch. That said, we should probably first upload this change to sid to give it some wider exposure first. Sure. We probably should not keep this hack forever, but instead let timedated read known NTP implementation unit names from usr/lib/systemd/ntp-units.d/*.list since this has been reintroduced in systemd 243. I added the necessary bits in chrony 3.5-5. Hm, I don't see how this change in timedate would actually help in this situation. Support for ntp-units.d in timedated/timedatectl just enables that if you use "timedatectl set-ntp true|false" it will prefer alternatives if installed. Doesn’t systemd-timesyncd look for foreign services in ntp-units.d/ when starting? I thought that was the case and that it remained inactive in case an NTP implementation with a higher priority was found there. We don't actually use "timedatectl set-ntp true|false" though in our maintainer scripts though (and I don't think we should). Agreed. signature.asc Description: PGP signature
Bug#948744: voctomix-outcasts: --audio_elements option is ignored.
released! https://github.com/CarlFK/voctomix-outcasts/releases/tag/v0.9.3 Thanks again for putting up with me. On Mon, Jan 13, 2020 at 7:12 AM Carl Karsten wrote: > oh right, I said there is a patch. hmm... let me create a release > after breakfast. > > On Mon, Jan 13, 2020 at 6:48 AM Carl F Karsten > wrote: > >> Package: voctomix-outcasts >> Severity: important >> Tags: patch >> >> Hello Holger! >> >> ingest.py --help says --audio-elements does something, but I never wrote >> the code to do anything. Opps. >> >> code added is basically: >> audio_src += args.audio_elements + " !\n" >> >> It is about to be tested in production at LCA in 2.5 hours! >> >> We coppied the file onto the box, so no need to rush getting this fix >> packaged. >> >> Thanks! >> Carl >> >> >> -- System Information: >> Debian Release: buster/sid >> APT prefers bionic-updates >> APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, >> 'bionic'), (100, 'bionic-backports') >> Architecture: amd64 (x86_64) >> Foreign Architectures: i386 >> >> Kernel: Linux 4.15.0-72-generic (SMP w/4 CPU cores) >> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), >> LANGUAGE=en_US: (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled >> >> Versions of packages voctomix-outcasts depends on: >> ii gir1.2-gst-plugins-base-1.0 1.14.5-0ubuntu1~18.04.1 >> ii gstreamer1.0-plugins-good1.14.5-0ubuntu1~18.04.1 >> ii python3 3.6.7-1~18.04 >> ii python3-gi 3.26.1-2ubuntu1 >> >> Versions of packages voctomix-outcasts recommends: >> ii gstreamer1.0-x 1.14.5-0ubuntu1~18.04.1 >> >> voctomix-outcasts suggests no packages. >> > > > -- > Carl K > -- Carl K
Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot
Control: retitle -1 dmraid volumes are not marked as active, resulting in time out Am 12.01.20 um 20:49 schrieb Joshua Hudson: >>> Dec 31 08:27:23 nova dmraid-activate[554]: ERROR: Cannot retrieve RAID > set information for isw_cfbejbfeib_Volume1 >> Have you further investigated those error messages? > > I have now investigated and it's clearly spurious. > > udev tries to run the following commands: > > /sbin/dmraid-activate /dev/sda > /sbin/dmraid-activate /dev/sdb > /sbin/dmraid-activate sda > /sbin/dmraid-activate sdb > > The first two are correct and succeed. The second two are not correct > and fail. The failure results in log spam. > >> Have you tried with mdadm instead? > > mdadm doesn't recognize the raid descriptor. > >> udevadm info /dev/mapper/isw_cfbejbfeib_Volume14 > > output of this command for this device and all similar devices attached. > Bad news is, that dmraid is basically dead and unmaintained since quite a while. It's unfortunate, that mdadm doesn't have support for your RAID controller. Unfortunately I'm not sure if I can help you further at this point, since I'm not familiar with dmraid. It would probably be a good idea to reassign this bug report to dmraid. But since dmraid upstream is dead and the last Debian upload is 3 years old, I'm not sure you'll get any help there. Maybe you can hack the /sbin/dmraid-activate script and call dmraid with the -d switch to get a more verbose debug output. Maybe that provides you with some clues. signature.asc Description: OpenPGP digital signature
Bug#947075: conque: Should this package be removed?
X-Debbugs-CC: harishbadrin...@gmail.com Hi, Since there's no reply in the last 3 weeks, I will proceed and request for package removal after Jan. 19, 2020. Please let me know ASAP if you have any other issues. Best, Boyuan Yang On Fri, 20 Dec 2019 09:16:19 -0500 Boyuan Yang wrote: > Source: conque > Severity: serious > Version: 2.3-1 > > Dear conque maintainer, > > The package conque you maintain in Debian is currently affected by > Debian's python2 removal. Since conque seems to be a python2-only > packages, is it reasonable to have it removed from Debian archive? > > If you have any thoughts, please let me know ASAP. If there's no > response, I plan to convert this bug report to a removal request to > have this package removed from Debian. signature.asc Description: This is a digitally signed message part
Bug#947936: chrony: Does (still) not start properly on boot on buster
Am 12.01.20 um 23:08 schrieb Vincent Blut: > On 2020-01-12T20:41+0100, Michael Biebl wrote: >> Am 12.01.20 um 20:15 schrieb Santiago Vila: >>> My theory is that this is some kind of race condition. >>> >>> I initially cloned the machine from another one where this happened. >>> >>> Then I discovered that the problem also happens (randomly) in a brand >>> new machine if I copy the journal from the "bad" machine. >>> >>> However, there is nothing special about the journal (or at least >>> "journalctl --verify" says it's ok), except maybe that it's several >>> megabytes long. >>> >>> Could it be that systemd spends some time processing the journal at >>> boot time and this is what triggers the race condition? >> >> On my buster system: >> >> >>> an 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Looking >>> at job systemd-timesyncd.service/stop conflicted_by=yes >>> Jan 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Looking >>> at job systemd-timesyncd.service/start conflicted_by=no >>> Jan 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Fixing >>> conflicting jobs >>> systemd-timesyncd.service/stop,systemd-timesyncd.service/start by >>> deleting job systemd-timesyncd.service/start >>> Jan 12 20:04:46 debian systemd[1]: chrony.service: Looking at job >>> chrony.service/start conflicted_by=no >>> Jan 12 20:04:46 debian systemd[1]: chrony.service: Looking at job >>> chrony.service/stop conflicted_by=no >>> Jan 12 20:04:46 debian systemd[1]: chrony.service: Fixing conflicting >>> jobs chrony.service/start,chrony.service/stop by deleting job >>> chrony.service/stop >>> Jan 12 20:04:46 debian systemd[1]: Found redundant job >>> systemd-timesyncd.service/stop, dropping from transaction. >> >> >> Those lines are missing on GCE system. Instead I see >>> Jan 12 17:02:01 d1 systemd[1]: Keeping job >>> systemd-timesyncd.service/start because of sysinit.target/start >>> Jan 12 17:02:01 d1 systemd[1]: Keeping job chrony.service/stop >>> because of systemd-timesyncd.service/start >>> Jan 12 17:02:01 d1 systemd[1]: systemd-timesyncd.service: Installed >>> new job systemd-timesyncd.service/start as 119 >>> Jan 12 17:02:01 d1 systemd[1]: chrony.service: Job 82 >>> chrony.service/start finished, result=canceled >>> Jan 12 17:02:01 d1 systemd[1]: chrony.service: Installed new job >>> chrony.service/stop as 121 >>> Jan 12 17:02:01 d1 systemd[1]: chrony.service: Job 121 >>> chrony.service/stop finished, result=done >> >> >> The problem is, that the transaction is computed *before* >> ConditionFileIsExecutable=!/usr/sbin/chronyd is evaluated (conditions >> are evaluation just before the binary is executed) and it might indeed >> depend on the ordering, in which the jobs are scheduled. > > Makes sense. Thanks for debugging this. > >> So, the simplest fix would be to drop the line >>> Conflicts=systemd-timesyncd.service openntpd.service ntp.service >>> ntpsec.service >> from chrony.service. >> This way, systemd will schedule the start of both services. >> chrony.service will be started properly and for >> systemd-timesyncd.service the ConditionFileIsExecutable will kick in. > > If there is no risk of regression, then I’m all for making this change. I don't see a risk for a regression, given that systemd in buster ships disable-with-time-daemon.conf. So if the drop the Conflicts again, we'd basically have the situation again as in stretch. That said, we should probably first upload this change to sid to give it some wider exposure first. > We probably should not keep this hack forever, but instead let timedated > read known NTP implementation unit names from > usr/lib/systemd/ntp-units.d/*.list since this has been reintroduced in > systemd 243. I added the necessary bits in chrony 3.5-5. Hm, I don't see how this change in timedate would actually help in this situation. Support for ntp-units.d in timedated/timedatectl just enables that if you use "timedatectl set-ntp true|false" it will prefer alternatives if installed. We don't actually use "timedatectl set-ntp true|false" though in our maintainer scripts though (and I don't think we should). signature.asc Description: OpenPGP digital signature
Bug#948569: elpa-elpy: elpy-find-file: Symbol’s value as variable is void: ffip-prune-patterns
Control: tags -1 + moreinfo unreproducible Hi Salman, Thanks for the follow-up. Salman Mohammadi writes: > Dear Nicholas, > > I mentioned in the previous bug report how to reproduce this message, > but it was not clear, sorry. > > Steps to reproduce: > > 1. install the needed packages in Debian Sid: > > $ sudo apt install elpa-elpy elpa-find-file-in-project > > 2. open emacs and activate python-mode > > M-x python-mode > > 3. run the following command > > C-x C-f > > and you now get the mentioned error message. > This sequence doesn't activate Elpy; it activates python-mode, and C-x C-f runs the built-in 'find-file'. At this time the bug remains unreproducible with the provided information, and it seems like something in your Emacs config is causing this issue; Please do not modify the state of the unreproducible tag. When sufficient information has been provided to reproduce this issue I will drop that tag. I am prioritising #948567, and hope you will do the same. Previously this bug (#948569) seemed to have been most likely caused by #948567, but that isn't the case with the step 1. you just provided. eg: if elpy was upgraded, and the user had custom ffip config, then the user ran apt autoremove, the result would be "Symbol’s value as variable is void: ffip-prune-patterns". #948567 has at least two clear avenues of resolution, whereas this one has none at this time, thus the former is a better use of free time. Best, Nicholas signature.asc Description: PGP signature
Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rumur" * Package name: rumur Version : 2020.01.11-1 Upstream Author : Matthew Fernandez * URL : https://github.com/Smattr/rumur * License : Unlicense * Vcs : https://github.com/Smattr/rumur.git Section : devel It builds those binary packages: rumur - model checker for the Murphi language To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rumur Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2020.01.11-1.dsc Changes since the last upload: * New upstream release. . * Update autopkgtest tests to test the installed binaries and library. Previously this incorrectly ran the upstream test suite. . * Update RUMUR_VERSION variable in rules from 2019.12.22-1 to 2020.01.11-1. Regards, Matthew
Bug#925629: aghermann: ftbfs with GCC-9
> On Jan 12, 2020, at 12:49, Andreas Tille wrote:
>
> Hi,
>
> I'm wondering how this bug
>
>
> rk1968/rk1968.cc: In lambda function:
> rk1968/rk1968.cc:237:103: error: expected '{' before '->' token
> 237 | auto make_error_return = [] ( const char* fmt, ...)
> __attribute__ ((format (printf, 2, 3))) -> int
> |
>^~
>
>
> with gcc 9 can be fixed in aghermann. Any help would be appreciated.
I think you’re hitting GCC bug #90333 [0]. This claims to have been fixed in
r265787, but I can still reproduce this issue with GCC 9.2.1 that includes that
commit. Turning this into a C++11 attribute ([[gnu::format(printf, 2, 3)]])
makes the parse error go away, but -Wattributes still indicates GCC is ignoring
it. You might need to bump that GCC issue with some evidence that the bug still
exists and see what the maintainers say. If you need to bypass this urgently, I
would recommend deleting the attribute as that particular one is only used to
aid the compiler in creating warnings.
[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333
Bug#947936: chrony: Does (still) not start properly on boot on buster
On 2020-01-12T20:41+0100, Michael Biebl wrote: Am 12.01.20 um 20:15 schrieb Santiago Vila: My theory is that this is some kind of race condition. I initially cloned the machine from another one where this happened. Then I discovered that the problem also happens (randomly) in a brand new machine if I copy the journal from the "bad" machine. However, there is nothing special about the journal (or at least "journalctl --verify" says it's ok), except maybe that it's several megabytes long. Could it be that systemd spends some time processing the journal at boot time and this is what triggers the race condition? On my buster system: an 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Looking at job systemd-timesyncd.service/stop conflicted_by=yes Jan 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Looking at job systemd-timesyncd.service/start conflicted_by=no Jan 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Fixing conflicting jobs systemd-timesyncd.service/stop,systemd-timesyncd.service/start by deleting job systemd-timesyncd.service/start Jan 12 20:04:46 debian systemd[1]: chrony.service: Looking at job chrony.service/start conflicted_by=no Jan 12 20:04:46 debian systemd[1]: chrony.service: Looking at job chrony.service/stop conflicted_by=no Jan 12 20:04:46 debian systemd[1]: chrony.service: Fixing conflicting jobs chrony.service/start,chrony.service/stop by deleting job chrony.service/stop Jan 12 20:04:46 debian systemd[1]: Found redundant job systemd-timesyncd.service/stop, dropping from transaction. Those lines are missing on GCE system. Instead I see Jan 12 17:02:01 d1 systemd[1]: Keeping job systemd-timesyncd.service/start because of sysinit.target/start Jan 12 17:02:01 d1 systemd[1]: Keeping job chrony.service/stop because of systemd-timesyncd.service/start Jan 12 17:02:01 d1 systemd[1]: systemd-timesyncd.service: Installed new job systemd-timesyncd.service/start as 119 Jan 12 17:02:01 d1 systemd[1]: chrony.service: Job 82 chrony.service/start finished, result=canceled Jan 12 17:02:01 d1 systemd[1]: chrony.service: Installed new job chrony.service/stop as 121 Jan 12 17:02:01 d1 systemd[1]: chrony.service: Job 121 chrony.service/stop finished, result=done The problem is, that the transaction is computed *before* ConditionFileIsExecutable=!/usr/sbin/chronyd is evaluated (conditions are evaluation just before the binary is executed) and it might indeed depend on the ordering, in which the jobs are scheduled. Makes sense. Thanks for debugging this. So, the simplest fix would be to drop the line Conflicts=systemd-timesyncd.service openntpd.service ntp.service ntpsec.service from chrony.service. This way, systemd will schedule the start of both services. chrony.service will be started properly and for systemd-timesyncd.service the ConditionFileIsExecutable will kick in. If there is no risk of regression, then I’m all for making this change. I'm sorry, that I first asked chrony (and other NTP implementations) to add a Conflicts=systemd-timesyncd.service, hoping I could get rid of the /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf hack. Don’t feel sorry Michael, that was even requested by systemd upstream. From systemd changelog: “… Alternative NTP implementations should add a Conflicts=systemd-timesyncd.service to their unit files to take over and replace systemd's NTP default functionality.” But it appears, this hack is actually much more reliable then using Conflicts= See https://github.com/systemd/systemd/issues/7104#issuecomment-456755980 which explains the problem. We'd need some kind of asymmetrical conflicts. We probably should not keep this hack forever, but instead let timedated read known NTP implementation unit names from usr/lib/systemd/ntp-units.d/*.list since this has been reintroduced in systemd 243. I added the necessary bits in chrony 3.5-5. By the way, it would be great to know if this issue can be triggered by upgrading chrony to the 3.5-5 version (and with systemd >= 243-1). I guess at this point it is best to ask chrony, ntp, openntpd, ntpsec and virtualbox [1] to drop the Conflicts= line again. Maybe we should even do that for buster via a stable upload? Thoughts? Seems good. Michael Cheers, Vincent signature.asc Description: PGP signature
Bug#948735: apt doesn't completely remove "postgresql-11" dependencies
Thank you for your response. >Probably something installed depends, recommends, or suggests the >postgresql-client that it provides. $ apt rdepends postgresql-client-11 --installed returns nothing (empty result). The install/remove/autoremove sequence was executed right after a fresh installation.
Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_XXXXXXX/lib/modules/5.4.0-1-amd64/modules.builtin.bin'
On Wed, 08 Jan 2020 23:07:22 + Ben Hutchings wrote: On Wed, 2020-01-08 at 16:48 -0500, debian wrote: Printing spurious error messages is a bug, and we will fix it (whether in kmod or in initramfs-tools, is to be decided). So the change causing it should be reverted until it has been decided and fixed. -- - Ilkka
Bug#948749: RFS: xcb/2.4-5 [QA] -- Pigeon holes for your cut and paste selections
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "xcb" * Package name: xcb Version : 2.4-5 Upstream Author : None (dead upstream) * URL : NA * License : BSD-like * Vcs : https://salsa.debian.org/debian/xcb Section : x11 It builds those binary packages: xcb - Pigeon holes for your cut and paste selections To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xcb Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xcb/xcb_2.4-5.dsc Changes since the last upload: * QA upload. * Update compat level to 12. * Remove entry from d/watch as URL doesnot work. * Use dh_auto_build to fix ftcbfs. (Closes: #928317) - Thanks Nguyen Van. Hieu * use https in d/copyright format url. * Update compat level to 12. * Update Standards-Version to 4.4.1 * Add Rules-Requires-Root: no * Orphan the package (See: #675764) * Add Vcs links to d/control. -- Regards Sudip
Bug#948751: binutils-avr: Please make another source-only upload to allow testing migration
Source: binutils-avr Severity: important Version: 2.26.20160125+Atmel3.6.2-1 X-Debbugs-CC: ha...@debian.org Dear binutils-avr maintainer, Your latest upload binutils-avr/2.26.20160125+Atmel3.6.2-1 was not a source- only upload; as a result, this package will not migrate to Testing. Since July 2019, only source-only uploads are allowed to migrate to Testing in Debian. Please rebuild your package and make another source-only upload. You may find more information about source-only upload at https://wiki.debian.org/SourceOnlyUpload . -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#948750: RFS: freelan/2.2-1 [RC] [QA] -- Peer-to-peer virtual private network daemon
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "freelan"
* Package name: freelan
Version : 2.2-1
Upstream Author :
* URL : https://www.freelan.org
* License : GPL-3+
* Vcs : https://salsa.debian.org/debian/freelan
Section : net
It builds those binary packages:
freelan - Peer-to-peer virtual private network daemon
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/freelan
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/f/freelan/freelan_2.2-1.dsc
Changes since the last upload:
* QA upload
[ Ondřej Nový ]
* d/copyright: Change Format URL to correct one
.
[ Håvard Flaget Aasen ]
* New upstream release
- Upstream fixes ftbfs with boost 1.67 closes: #914068
- By default it compiles with upnp=yes and moongoose=no
* Create debian/watch file
* d/control
- Added Pre-Depends: ${misc:Pre-Depends}
- Change to debhelper-compat
- Bump debhelper to 12
- Update Standards-Version to 4.4.1
- Use secure URI on homepage
- Add libminiupnpc-dev as build-dependency
* Updated d/clean
* d/rules
- Updated install paths
* Update paths in d/copyright, upstream has restructured the code.
* Patches
- All but two patches got removed, fixed upstream.
- Add 0001-build-Adds-support-for-Boost-1.70.patch
- Add 0002-Fix-for-boost-versions-less-than-1.66.patch
Regards,
Håvard
Bug#948748: mnemosyne: Failed import for google translate, app can't start. Resolvable with 'pip3 install google-translate'
Package: mnemosyne Version: 2.7+ds-1 Severity: normal Dear Maintainer, After updating mnemosyne via synaptic package manager, I attempted to run mnemosyne from the command line and received a Python import error. I installed the following: apt-get install python3-gtts pip3 install google-translate This resolves the issue and mnemosyne runs normally. However I can't find the google-translate package in the apt repository. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mnemosyne depends on: ii libjs-sphinxdoc 1.8.5-4 ii libqt5sql5-sqlite 5.12.5+dfsg-2 ii python3 3.7.5-3 ii python3-cheroot 8.2.1+ds-2 ii python3-cherrypy3 8.9.1-5 ii python3-matplotlib 3.1.2-1 ii python3-pil 6.2.1-2+b1 ii python3-pyqt5 5.13.2+dfsg-1 ii python3-pyqt5.qtsql 5.13.2+dfsg-1 ii python3-pyqt5.qtwebchannel 5.13.2+dfsg-1 ii python3-pyqt5.qtwebengine 5.14.0-1 ii python3-webob 1:1.8.5-1 mnemosyne recommends no packages. mnemosyne suggests no packages. -- no debconf information Warning: Could not import OpenGL. Might cause a black screen on some Linux distributions. Try installing python3-opengl in that case. Log body: An unexpected error has occurred. Please forward the following info to the developers: Traceback (innermost last): File "/usr/bin/mnemosyne", line 270, in debug_file=options.debug_file) File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", line 397, in initialise self.register_components() File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", line 462, in register_components importlib.import_module(module_name), class_name) File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1006, in _gcd_import File "", line 983, in _find_and_load File "", line 967, in _find_and_load_unlocked File "", line 677, in _load_unlocked File "", line 728, in exec_module File "", line 219, in _call_with_frames_removed File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/translators/google_translator.py", line 5, in from googletrans import Translator as gTranslator ModuleNotFoundError: No module named 'googletrans' An unexpected error has occurred. Please forward the following info to the developers: Traceback (innermost last): File "/usr/bin/mnemosyne", line 270, in debug_file=options.debug_file) File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", line 397, in initialise self.register_components() File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", line 462, in register_components importlib.import_module(module_name), class_name) File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1006, in _gcd_import File "", line 983, in _find_and_load File "", line 967, in _find_and_load_unlocked File "", line 677, in _load_unlocked File "", line 728, in exec_module File "", line 219, in _call_with_frames_removed File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/translators/google_translator.py", line 5, in from googletrans import Translator as gTranslator ModuleNotFoundError: No module named 'googletrans' An unexpected error has occurred. Please forward the following info to the developers: Traceback (innermost last): File "/usr/bin/mnemosyne", line 270, in debug_file=options.debug_file) File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", line 397, in initialise self.register_components() File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", line 462, in register_components importlib.import_module(module_name), class_name) File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1006, in _gcd_import File "", line 983, in _find_and_load File "", line 967, in _find_and_load_unlocked File "", line 677, in _load_unlocked File "", line 728, in exec_module File "", line 219, in _call_with_frames_removed File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/translators/google_translator.py", line 5, in from googletrans import Translator as gTranslator
Bug#948747: ITP: r-cran-unitizer -- interactive unit tests for GNU R
Package: wnpp Severity: wishlist Subject: ITP: r-cran-unitizer -- interactive unit tests for GNU R Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-unitizer Version : 1.4.8 Upstream Author : Brodie Gaslam * URL : https://cran.r-project.org/package=unitizer * License : GPL-2+ Programming Lang: GNU R Description : interactive unit tests for GNU R Simplifies regression tests by comparing objects produced by test code with earlier versions of those same objects. If objects are unchanged the tests pass, otherwise execution stops with error details. If in interactive mode, tests can be reviewed through the provided interactive environment. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-unitizer
Bug#948744: voctomix-outcasts: --audio_elements option is ignored.
oh right, I said there is a patch. hmm... let me create a release after breakfast. On Mon, Jan 13, 2020 at 6:48 AM Carl F Karsten wrote: > Package: voctomix-outcasts > Severity: important > Tags: patch > > Hello Holger! > > ingest.py --help says --audio-elements does something, but I never wrote > the code to do anything. Opps. > > code added is basically: > audio_src += args.audio_elements + " !\n" > > It is about to be tested in production at LCA in 2.5 hours! > > We coppied the file onto the box, so no need to rush getting this fix > packaged. > > Thanks! > Carl > > > -- System Information: > Debian Release: buster/sid > APT prefers bionic-updates > APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, > 'bionic'), (100, 'bionic-backports') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.15.0-72-generic (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US: (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages voctomix-outcasts depends on: > ii gir1.2-gst-plugins-base-1.0 1.14.5-0ubuntu1~18.04.1 > ii gstreamer1.0-plugins-good1.14.5-0ubuntu1~18.04.1 > ii python3 3.6.7-1~18.04 > ii python3-gi 3.26.1-2ubuntu1 > > Versions of packages voctomix-outcasts recommends: > ii gstreamer1.0-x 1.14.5-0ubuntu1~18.04.1 > > voctomix-outcasts suggests no packages. > -- Carl K
Bug#948676: at-spi2-core: /etc/X11/Xsession.d/90qt-a11y does not enable Qt5 support as the Wiki indicates
On Sun, Jan 12, 2020 at 09:05:10PM +0100, Samuel Thibault wrote: > Control: forwarded -1 https://codereview.qt-project.org/c/qt/qtbase/+/286336 > > Dmitry Shachnev, le dim. 12 janv. 2020 22:31:14 +0300, a ecrit: > > Any chance you can submit the patch to Qt Gerrit [1]? > > Here it is. Thanks a lot for that! Let's wait for some review, and then I will include it in the packaging. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#930846: New development of how to build the installation-guide for the website [ Re: Bug#930846: partman-auto-lvm: debconf show guided_size during auto install ]
Hi, "Adam D. Barratt" wrote: > On Sun, 2020-01-12 at 18:38 +0100, Holger Wansing wrote: > > A new build has taken place, however on the website we still have a > > mixup of old and newer files, and still no example-preseed.txt. > > While in the lessoften log it looks fine. > > No installmanual build available to me tough... > > The file exists, and the "often" cron is currently running. So I guess > it just needs a little more patience. > > -rw-rw-r-- 1 debwww debwww 18873 Jan 12 15:42 /srv/ > www.debian.org/www/releases/buster/example-preseed.txt You were right! Now everything is fine: https://www.debian.org/releases/stable/installmanual now has the correct version of the manual in all languages and all formats. And it has the example-preseed file. Thanks to all involved. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#948746: django-classy-tags: autopkgtest failure: No module named 'django_classy_tags'
Source: django-classy-tags Version: 0.9.0-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of django-classy-tags you added autopkgtest to django-classy-tags, great. However, the test fails. I copied some of the output at the bottom of this report. You're using autodep8 to trigger the test, but it seems your package naming and Python module name aren't aligned for autodep8. autodep8 recently acquired a new feature that enables you to tell autode8 what the real module name is that should be tested [1]. Currently this regression is blocking the migration to testing [2]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://manpages.debian.org/unstable/autodep8/autodep8.1.en.html#PYTHON_PACKAGES [2] https://qa.debian.org/excuses.php?package=django-classy-tags https://ci.debian.net/data/autopkgtest/testing/amd64/d/django-classy-tags/3812144/log.gz autopkgtest [15:16:11]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import django_classy_tags; print(django_classy_tags)" ; done autopkgtest [15:16:11]: test autodep8-python3: [--- Testing with python3.7: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'django_classy_tags' autopkgtest [15:16:11]: test autodep8-python3: ---] signature.asc Description: OpenPGP digital signature
Bug#925629: aghermann: ftbfs with GCC-9
Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 Andrei Zavada
Hi,
I'm wondering how this bug
rk1968/rk1968.cc: In lambda function:
rk1968/rk1968.cc:237:103: error: expected '{' before '->' token
237 | auto make_error_return = [] ( const char* fmt, ...)
__attribute__ ((format (printf, 2, 3))) -> int
|
^~
with gcc 9 can be fixed in aghermann. Any help would be appreciated.
Kind regards
Andreas.
--
http://fam-tille.de
Bug#948745: ksh: offer both AT ksh93 and the new ksh2020 (separate packages)
Package: ksh Version: 2020.0.0-2 Severity: wishlist ksh2020 has many problems, such as speed reduction by 300%, which currently causes much uproar among its users in IRC. Newly introduced features additionally come with much breakage. Please change the ksh binary package to ship /usr/bin/ksh2020 instead of /usr/bin/ksh93, and reintroduce src:ksh (= 93u+20120801-3.4) as src:ksh93 building a ksh93 binary package with /usr/bin/ksh93 in it, for the time being. This would of course need to Replaces ksh (<< the first upload with /usr/bin/ksh2020 in it), and the other binaries will need consideration as well. For /etc/alternatives/ksh, we currently have: 20 ksh93 (containing ksh2020) 12 mksh 11 mksh-static (I think 10 was pdksh or ksh88?) I’d suggest this: 20 ksh93 (containing ksh93, from the ksh93 binary package) 18 ksh2020 (from the ksh binary package) 12 mksh 11 mksh-static Once ksh2020 has proven itself no regression, we can bump it to 30. (For the pdksh → mksh transition we took seven years, and if not for the request of the pdksh maintainer for mksh to take it over, I’d probably have suggested keeping it. Personally, as a shell developer, it is of great value to me to have as many different shells around as possible in order to see how other shells behave.) One of the ksh2020 developers who’s working for Red Hat is currently considering doing the same (offering both) in Fedora. This is being discussed in #ksh in Freenode IRC, although I’ll point the involved people to this bugreport once I have the number so they might write new info here. -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages ksh depends on: ii binfmt-support 2.2.0-2 ii libc6 2.29-7 ksh recommends no packages. ksh suggests no packages. -- no debconf information
Bug#948744: voctomix-outcasts: --audio_elements option is ignored.
Package: voctomix-outcasts Severity: important Tags: patch Hello Holger! ingest.py --help says --audio-elements does something, but I never wrote the code to do anything. Opps. code added is basically: audio_src += args.audio_elements + " !\n" It is about to be tested in production at LCA in 2.5 hours! We coppied the file onto the box, so no need to rush getting this fix packaged. Thanks! Carl -- System Information: Debian Release: buster/sid APT prefers bionic-updates APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic'), (100, 'bionic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-72-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US: (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages voctomix-outcasts depends on: ii gir1.2-gst-plugins-base-1.0 1.14.5-0ubuntu1~18.04.1 ii gstreamer1.0-plugins-good1.14.5-0ubuntu1~18.04.1 ii python3 3.6.7-1~18.04 ii python3-gi 3.26.1-2ubuntu1 Versions of packages voctomix-outcasts recommends: ii gstreamer1.0-x 1.14.5-0ubuntu1~18.04.1 voctomix-outcasts suggests no packages.
Bug#947001: Bug#947004: S4Vectors Segmentation fault after r-base-core update (Was: Bug#947004: Tests segfaults (since the r-base-core update?))
AFAIK the only standard way to run tests is by sourcing whatever files
are in the tests/ folder of a package. This is actually what 'R CMD
check' does to run the tests.
When you use the following commands
```
require("S4Vectors")
S4Vectors:::.test()
```
or
```
BiocGenerics:::testPackage("S4Vectors")
```
in your build system scripts, you're using the commands contained in the
files found in the tests/ folder and **hardcoding** them in your
scripts. This is fragile because the content of these files could change
anytime (and will very likely change in the near future e.g. when
S4Vectors or other packages with RUnit-based tests switch to
testthat-based tests).
OTOH when you source the files in the tests/ folder you remain agnostic
of the exact commands that are used to run the tests. This is robust.
Back to the segfault issue. The fact that it goes away when replacing
require("S4Vectors"); S4Vectors:::.test() with
BiocGenerics:::testPackage("S4Vectors") sounds like luck, that's all
there is to it. And you didn't get such luck when doing the same for
IRanges. It's worrying that a "fix" for a serious issue like a segfault
relies on luck. In other words, someone should take the time to go to
the bottom of this issue so we **really** understand what's going on.
Thanks,
H.
Bug#948477: transition: openbabel
Control: tags -1 moreinfo Hi Andrius, On 09-01-2020 08:17, mer...@debian.org wrote: > I would like to request a transition slot for openbabel (experimental -> > unstable). Current ben tracker [1] is fine, it just misses avogadrolibs, > which has been recently accepted into unstable. Please elaborate why you think it's missing. The fact that it's new has nothing to do with it. > The status of affected packages: > > * Rebuilds without patching: kalzium, avogadrolibs > * Needs patching (I have patches at hand): ghemical, xdrawchem, > gnome-chemistry-utils> * Sid-only (not in testing due to FTBFS): v-sim, mpqc3 > > As I am team-maintaining most of these packages, I will be able to patch > and upload where needed. xdrawchem is not team-maintained. Please file a bug against that package to notify the maintainer and mark it as blocking this transition. We can mark the bug as RC once the transition starts (probably soon). Paul signature.asc Description: OpenPGP digital signature
Bug#948713: diff NMU for python-pygraphviz_1.5-2.1
tags 948713 +pending thanks Dear maintainer, I have prepared an NMU (versioned as 1.5-2.1) and uploaded to DELAYED/5. Please fell free to tell me if I should delay it longer, cancel or reschedule. Diff is attached. Best regards Anton nmu.debdiff Description: Binary data
Bug#948676: at-spi2-core: /etc/X11/Xsession.d/90qt-a11y does not enable Qt5 support as the Wiki indicates
Control: forwarded -1 https://codereview.qt-project.org/c/qt/qtbase/+/286336 Dmitry Shachnev, le dim. 12 janv. 2020 22:31:14 +0300, a ecrit: > On Sun, Jan 12, 2020 at 07:54:22PM +0100, Samuel Thibault wrote: > > Could we at least restore looking at IsEnabled in Qt, as the attached > > patch does? Actually, that is needed for proper focus tracking in Qt > > applications for zoom support in compiz when Orca is not used. The > > comment there says that IsEnabled is always true, but that's not what I > > am observing with e.g. Debian 8's gnome 3.14, Debian 9's gnome 3.22, and > > Debian 10's 3.30... Ideally, we'd backport this fix to buster too. > > Any chance you can submit the patch to Qt Gerrit [1]? Here it is. Samuel
Bug#948676: at-spi2-core: /etc/X11/Xsession.d/90qt-a11y does not enable Qt5 support as the Wiki indicates
Thorsten Glaser, le dim. 12 janv. 2020 19:37:03 +, a ecrit: > Samuel Thibault dixit: > > >I guess in your case what you expected was that at the very least > >applications started after orca got started should be accessible, even > >if orca is only started by hand. This would work if Qt was not only > >looking at org.a11y.Status ScreenReaderEnabled (the control panel > >configuration), but also at org.a11y.Status IsEnabled (set by Orca on > >startup). This would not be enough for making existing applications > >accessible when you first start Orca, Bug#874054 mentions that it's > >because Qt currently doesn't monitor the dbus IsEnabled variable. > > Ooh, interesting. From what the MuseScore people say, after start > of orca would be enough (also, AIUI, orca starts with the desktop > session or can be made to). Starting orca only wouldn't be enough. But enabling Orca startup in the control panel would be enough. My patch is for the former case. > >Could we at least restore looking at IsEnabled in Qt, as the attached > >patch does? Actually, that is needed for proper focus tracking in Qt > >applications for zoom support in compiz when Orca is not used. The > > Would this have the effect of losing keyboard input in MuseScore > when orca is used, which is what one tester reported? That shouldn't happen, but that could be an effect indeed. > I’m under plain X11 with evilwm, no desktop environment, and did > not have that issue. Getting Orca to access the content of the application would be enough to get the same situation as the users. Samuel
Bug#948743: RM: kadu -- RoQA; FTBFS and discontinued upstream; agreed by maintainer
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear ftp-master, kadu has recently started to FTBFS. It is discontinued upstream and the maintainer of kadu suggested in bug #846695 to remove it from Debian. Please remove kadu from unstable. Paul -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl4bfG4ACgkQnFyZ6wW9 dQpljQgArhJhsvleMOMVj0B7OZFCdGeagkkLBNa/LUJtIcffkfPsgRHkalKz0RtE DznNm2Jvqpz3kxKMwqOiRvLX6t+5Ieukkhft+FJ0HCXkmFwryT9zNEcooD6IQcO9 9isk4ylK/Uqqnup98q+yQ2P4ZIEUgQ7c0BTGsneTAyw1JIvntZXstKiomoc4/vvb BzIoy4Zfv2+1y1aD4h6wevctDQye/q/9QtrXOf6MDdSvqX5ComtJJ5gycbVSDXEi hj515zhp/LPCOLMcP1DuhcN0txlTjWKmba3lvusf7lJFtYqeoA9qi6zlb0/qDmrC zo8LQiJeF8f0qM6f9gG3bXLZ7ZvRuQ== =u/yb -END PGP SIGNATURE-
Bug#948742: RM: kadu-mime-tex -- RoQA; RC buggy since Dec 2016, discontinued upstream, maintainer agrees
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear ftp-master, As discussed in bug #846695, the maintainer of kadu-mime-tex and I agree that kadu-mime-tex should be removed from Debian. The package hasn't been in testing sinse January 2017. Please remove kadu-mime-tex. Paul -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl4be6gACgkQnFyZ6wW9 dQpixwgAg+uLf3veKDYDoTp+0bWIEaSZdl874V195Bf+Ox1Gx4KwImnoZesUT2y9 1qtS7NZ4lWQq6sH5dBVBQU4RqnIMsK6y+fiv2JsjilCLrjiSdmrxmIaPB5EFDnNh eSzyeBlry1TrXNDAqpqkyR+qy6mynBOjSGBdePRqn0d851Whmqx4UcOc5OqPVN/i YutE4WyCfr12Gkc00dw1cLZ+3lQMT/q/rWsS0aYvErDHU/7Y0thNE1pXEEO63slX FDfVnXYG88Et2uRezabUDHhD7RyMdC0qEwZHxDEMc9enzFMUyLsmsRMwBSufGaRf tKCDV13q0dbXv81mgbOC8cWKbFOr0Q== =0XH8 -END PGP SIGNATURE-
Bug#947811: systemd: don't check *mounted* filesystems by default
> If you want to fsck/mount your partitions manually via a custom script that is run before init, then I would set passno to 0. I've since masked the job that systemd uses to run fsck. It's still a bug because if somebody forgets and leaves a filesystem mounted read-write in the emergency shell (fixing anything other than fsck problems in the emergency shell usually requires mounting things read-write), the same problem happens and no custom script is involved.
Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot
>> Dec 31 08:27:23 nova dmraid-activate[554]: ERROR: Cannot retrieve RAID set information for isw_cfbejbfeib_Volume1 > Have you further investigated those error messages? I have now investigated and it's clearly spurious. udev tries to run the following commands: /sbin/dmraid-activate /dev/sda /sbin/dmraid-activate /dev/sdb /sbin/dmraid-activate sda /sbin/dmraid-activate sdb The first two are correct and succeed. The second two are not correct and fail. The failure results in log spam. > Have you tried with mdadm instead? mdadm doesn't recognize the raid descriptor. > udevadm info /dev/mapper/isw_cfbejbfeib_Volume14 output of this command for this device and all similar devices attached. P: /devices/virtual/block/dm-0 N: dm-0 L: 0 S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume1 S: disk/by-id/dm-name-isw_cfbejbfeib_Volume1 S: android0 E: DEVPATH=/devices/virtual/block/dm-0 E: DEVNAME=/dev/dm-0 E: DEVTYPE=disk E: MAJOR=254 E: MINOR=0 E: SUBSYSTEM=block E: USEC_INITIALIZED=1701034 E: DM_UDEV_DISABLE_DM_RULES_FLAG=1 E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES=1 E: DM_UDEV_RULES_VSN=2 E: DM_ACTIVATION=1 E: DM_NAME=isw_cfbejbfeib_Volume1 E: DM_UUID=DMRAID-isw_cfbejbfeib_Volume1 E: DM_SUSPENDED=0 E: ID_PART_TABLE_UUID=373c9bd5 E: ID_PART_TABLE_TYPE=dos E: DEVLINKS=/dev/disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume1 /dev/disk/by-id/dm-name-isw_cfbejbfeib_Volume1 /dev/android0 E: TAGS=:systemd: P: /devices/virtual/block/dm-1 N: dm-1 L: 0 S: android1 S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume11 S: disk/by-id/dm-name-isw_cfbejbfeib_Volume11 S: disk/by-uuid/d847c628-aa10-4bef-92b6-72ebacc07d7b E: DEVPATH=/devices/virtual/block/dm-1 E: DEVNAME=/dev/dm-1 E: DEVTYPE=disk E: MAJOR=254 E: MINOR=1 E: SUBSYSTEM=block E: USEC_INITIALIZED=1707100 E: DM_UDEV_DISABLE_DM_RULES_FLAG=1 E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES=1 E: DM_UDEV_RULES_VSN=2 E: DM_ACTIVATION=1 E: DM_NAME=isw_cfbejbfeib_Volume11 E: DM_UUID=DMRAID-isw_cfbejbfeib_Volume11 E: DM_SUSPENDED=0 E: ID_FS_UUID=d847c628-aa10-4bef-92b6-72ebacc07d7b E: ID_FS_UUID_ENC=d847c628-aa10-4bef-92b6-72ebacc07d7b E: ID_FS_VERSION=1.0 E: ID_FS_TYPE=ext3 E: ID_FS_USAGE=filesystem E: DEVLINKS=/dev/android1 /dev/disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume11 /dev/disk/by-id/dm-name-isw_cfbejbfeib_Volume11 /dev/disk/by-uuid/d847c628-aa10-4bef-92b6-72ebacc07d7b E: TAGS=:systemd: P: /devices/virtual/block/dm-2 N: dm-2 L: 0 S: disk/by-id/dm-name-isw_cfbejbfeib_Volume12 S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume12 S: disk/by-uuid/baad791f-0ba2-4c87-92a1-0cd0ef4f7301 S: android2 E: DEVPATH=/devices/virtual/block/dm-2 E: DEVNAME=/dev/dm-2 E: DEVTYPE=disk E: MAJOR=254 E: MINOR=2 E: SUBSYSTEM=block E: USEC_INITIALIZED=1707179 E: DM_UDEV_DISABLE_DM_RULES_FLAG=1 E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES=1 E: DM_UDEV_RULES_VSN=2 E: DM_ACTIVATION=1 E: DM_NAME=isw_cfbejbfeib_Volume12 E: DM_UUID=DMRAID-isw_cfbejbfeib_Volume12 E: DM_SUSPENDED=0 E: ID_FS_UUID=baad791f-0ba2-4c87-92a1-0cd0ef4f7301 E: ID_FS_UUID_ENC=baad791f-0ba2-4c87-92a1-0cd0ef4f7301 E: ID_FS_VERSION=1 E: ID_FS_TYPE=swap E: ID_FS_USAGE=other E: DEVLINKS=/dev/disk/by-id/dm-name-isw_cfbejbfeib_Volume12 /dev/disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume12 /dev/disk/by-uuid/baad791f-0ba2-4c87-92a1-0cd0ef4f7301 /dev/android2 E: TAGS=:systemd: P: /devices/virtual/block/dm-3 N: dm-3 L: 0 S: android3 S: disk/by-id/dm-name-isw_cfbejbfeib_Volume13 S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume13 S: disk/by-uuid/5744b8b7-dcbf-48c4-868e-fb71fa65d456 E: DEVPATH=/devices/virtual/block/dm-3 E: DEVNAME=/dev/dm-3 E: DEVTYPE=disk E: MAJOR=254 E: MINOR=3 E: SUBSYSTEM=block E: USEC_INITIALIZED=1707545 E: DM_UDEV_DISABLE_DM_RULES_FLAG=1 E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES=1 E: DM_UDEV_RULES_VSN=2 E: DM_ACTIVATION=1 E: DM_NAME=isw_cfbejbfeib_Volume13 E: DM_UUID=DMRAID-isw_cfbejbfeib_Volume13 E: DM_SUSPENDED=0 E: ID_FS_UUID=5744b8b7-dcbf-48c4-868e-fb71fa65d456 E: ID_FS_UUID_ENC=5744b8b7-dcbf-48c4-868e-fb71fa65d456 E: ID_FS_VERSION=1.0 E: ID_FS_TYPE=ext3 E: ID_FS_USAGE=filesystem E: DEVLINKS=/dev/android3 /dev/disk/by-id/dm-name-isw_cfbejbfeib_Volume13 /dev/disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume13 /dev/disk/by-uuid/5744b8b7-dcbf-48c4-868e-fb71fa65d456 E: TAGS=:systemd: P: /devices/virtual/block/dm-4 N: dm-4 L: 0 S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume14 S: disk/by-uuid/c03a09e6-ff90-4803-bd7c-78e34e99457e S: disk/by-id/dm-name-isw_cfbejbfeib_Volume14 S: android4 E: DEVPATH=/devices/virtual/block/dm-4 E: DEVNAME=/dev/dm-4 E: DEVTYPE=disk E: MAJOR=254 E: MINOR=4 E: SUBSYSTEM=block E: USEC_INITIALIZED=1708143 E: DM_UDEV_DISABLE_DM_RULES_FLAG=1 E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES=1 E: DM_UDEV_RULES_VSN=2 E: DM_ACTIVATION=1 E:
Bug#947165: transition: llvm-defaults to 9
Control: tags -1 confirmed Hi, On 03-01-2020 07:56, Paul Gevers wrote: > We currently have a bit much transitions going on (and some backslash > from a piuparts bug), so I'd like to get a bit of those transitions off > the table before starting this one. > > I'll let you know, probably in a week or so. Please go ahead. Paul
Bug#947936: chrony: Does (still) not start properly on boot on buster
Am 12.01.20 um 20:15 schrieb Santiago Vila: > My theory is that this is some kind of race condition. > > I initially cloned the machine from another one where this happened. > > Then I discovered that the problem also happens (randomly) in a brand > new machine if I copy the journal from the "bad" machine. > > However, there is nothing special about the journal (or at least > "journalctl --verify" says it's ok), except maybe that it's several > megabytes long. > > Could it be that systemd spends some time processing the journal at > boot time and this is what triggers the race condition? On my buster system: > an 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Looking at job > systemd-timesyncd.service/stop conflicted_by=yes > Jan 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Looking at job > systemd-timesyncd.service/start conflicted_by=no > Jan 12 20:04:46 debian systemd[1]: systemd-timesyncd.service: Fixing > conflicting jobs > systemd-timesyncd.service/stop,systemd-timesyncd.service/start by deleting > job systemd-timesyncd.service/start > Jan 12 20:04:46 debian systemd[1]: chrony.service: Looking at job > chrony.service/start conflicted_by=no > Jan 12 20:04:46 debian systemd[1]: chrony.service: Looking at job > chrony.service/stop conflicted_by=no > Jan 12 20:04:46 debian systemd[1]: chrony.service: Fixing conflicting jobs > chrony.service/start,chrony.service/stop by deleting job chrony.service/stop > Jan 12 20:04:46 debian systemd[1]: Found redundant job > systemd-timesyncd.service/stop, dropping from transaction. Those lines are missing on GCE system. Instead I see > Jan 12 17:02:01 d1 systemd[1]: Keeping job systemd-timesyncd.service/start > because of sysinit.target/start > Jan 12 17:02:01 d1 systemd[1]: Keeping job chrony.service/stop because of > systemd-timesyncd.service/start > Jan 12 17:02:01 d1 systemd[1]: systemd-timesyncd.service: Installed new job > systemd-timesyncd.service/start as 119 > Jan 12 17:02:01 d1 systemd[1]: chrony.service: Job 82 chrony.service/start > finished, result=canceled > Jan 12 17:02:01 d1 systemd[1]: chrony.service: Installed new job > chrony.service/stop as 121 > Jan 12 17:02:01 d1 systemd[1]: chrony.service: Job 121 chrony.service/stop > finished, result=done The problem is, that the transaction is computed *before* ConditionFileIsExecutable=!/usr/sbin/chronyd is evaluated (conditions are evaluation just before the binary is executed) and it might indeed depend on the ordering, in which the jobs are scheduled. So, the simplest fix would be to drop the line > Conflicts=systemd-timesyncd.service openntpd.service ntp.service > ntpsec.service from chrony.service. This way, systemd will schedule the start of both services. chrony.service will be started properly and for systemd-timesyncd.service the ConditionFileIsExecutable will kick in. I'm sorry, that I first asked chrony (and other NTP implementations) to add a Conflicts=systemd-timesyncd.service, hoping I could get rid of the /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf hack. But it appears, this hack is actually much more reliable then using Conflicts= See https://github.com/systemd/systemd/issues/7104#issuecomment-456755980 which explains the problem. We'd need some kind of asymmetrical conflicts. I guess at this point it is best to ask chrony, ntp, openntpd, ntpsec and virtualbox [1] to drop the Conflicts= line again. Maybe we should even do that for buster via a stable upload? Thoughts? Michael [1] https://codesearch.debian.net/search?q=Conflicts%3Dsystemd-timesyncd.service=1 signature.asc Description: OpenPGP digital signature
Bug#948676: at-spi2-core: /etc/X11/Xsession.d/90qt-a11y does not enable Qt5 support as the Wiki indicates
Dmitry Shachnev, le dim. 12 janv. 2020 22:31:14 +0300, a ecrit: > Any chance you can submit the patch to Qt Gerrit [1]? I'll have a look at it. Samuel
Bug#948676: at-spi2-core: /etc/X11/Xsession.d/90qt-a11y does not enable Qt5 support as the Wiki indicates
Samuel Thibault dixit: >I guess in your case what you expected was that at the very least >applications started after orca got started should be accessible, even >if orca is only started by hand. This would work if Qt was not only >looking at org.a11y.Status ScreenReaderEnabled (the control panel >configuration), but also at org.a11y.Status IsEnabled (set by Orca on >startup). This would not be enough for making existing applications >accessible when you first start Orca, Bug#874054 mentions that it's >because Qt currently doesn't monitor the dbus IsEnabled variable. Ooh, interesting. From what the MuseScore people say, after start of orca would be enough (also, AIUI, orca starts with the desktop session or can be made to). >Could we at least restore looking at IsEnabled in Qt, as the attached >patch does? Actually, that is needed for proper focus tracking in Qt >applications for zoom support in compiz when Orca is not used. The Would this have the effect of losing keyboard input in MuseScore when orca is used, which is what one tester reported? I’m under plain X11 with evilwm, no desktop environment, and did not have that issue. (On the other hand, this means I have no control panel to configure orca either. But I’ve only ran tests on Debian for the benefit of upstream anyway…) bye, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
Bug#948679: [Tts-project] Bug#948679: speech-dispatcher: doesn't start, first due to /var/run/…/cache/… then Can't bind local socket
Hello Samuel, > And the installation log on a freshly installed box confirms that > default configuration: oh, right; perhaps I misread. Yes, it said that (when purging it all then installing it again), and etckeeper reports only K symlinks in rc*.d/ directories. Sorry about the confusion. > Ok, so that path varies with environments... It does, but things all work out: > - only the dummy, generic, and mary-generic modules get enabled. You > need to let apt install the recommended speech-dispatcher-espeak-ng > package, in order to get at least one speech output backend. this did the trick, both spd-say and orca (with musescore3) now work. I reported this as success to MuseScore upstream, and so besides #948676 and AudioOutputMethod "alsa" in /etc/speech-dispatcher/speechd.conf (possibly), things work. Feel free to lower severity of #948679 (this one) accordingly, as it starts fine as regular user. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#948676: at-spi2-core: /etc/X11/Xsession.d/90qt-a11y does not enable Qt5 support as the Wiki indicates
Hi Samuel! On Sun, Jan 12, 2020 at 07:54:22PM +0100, Samuel Thibault wrote: > [...] > > Could we at least restore looking at IsEnabled in Qt, as the attached > patch does? Actually, that is needed for proper focus tracking in Qt > applications for zoom support in compiz when Orca is not used. The > comment there says that IsEnabled is always true, but that's not what I > am observing with e.g. Debian 8's gnome 3.14, Debian 9's gnome 3.22, and > Debian 10's 3.30... Ideally, we'd backport this fix to buster too. Any chance you can submit the patch to Qt Gerrit [1]? I do not want to include patches not from upstream, and I cannot submit it myself because the patch author must agree with the CLA. [1]: https://codereview.qt-project.org/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#948741: libsight-dev: Incorrect manual dependency on libvtk7.1-qt
Package: libsight-dev Version: 19.0.0-4 Severity: serious When reporting #948368 I missed that the same problem is also in the dependencies of libsight-dev, please remove the dependency on libvtk7.1-qt.
Bug#947936: chrony: Does (still) not start properly on boot on buster
My theory is that this is some kind of race condition. I initially cloned the machine from another one where this happened. Then I discovered that the problem also happens (randomly) in a brand new machine if I copy the journal from the "bad" machine. However, there is nothing special about the journal (or at least "journalctl --verify" says it's ok), except maybe that it's several megabytes long. Could it be that systemd spends some time processing the journal at boot time and this is what triggers the race condition? Thanks.
Bug#939989: transition: gdal
Hi Sebastiaan,
On 12-01-2020 08:18, Sebastiaan Couwenberg wrote:
>> Probably I am saying something stupid, but e.g. gdal-data () breaks
>> libgdal* . I notice that the library already has a larger than
>> relation on gdal-data, but apparently there should have been a smaller
>> than relation as well. (As we can't fix the package in testing, I
>> proposed the breaks).
>>
>> Can you please share your view of this problem?
>
> This kind of inter-package dependency should use "(= ${source:Version})"
> like done between arch:any packages with "(= ${binary:Version})", but
> using the exact source version between arch:any and arch:all packages
> breaks arch:all binNMUs, so >= is used instead.
But that has the risk that partial upgrades get it wrong.
> I don't think the gdal source should be changed just to accommodate debci.
Nit-picking: debci has nothing to do with it, it's autopkgtest, apt and
britney that rule here. One of the things that that combination has
revealed often is missing versioned dependencies, those that could cause
issues on partial upgrades or partial migrations). Hence, we're happy
that those are caught. Obviously britney should get smarter in
scheduling tests for binNMU'ed packages from unstable, but most of the
times during transitions apt as run by autopkgtest will pull those in
anyways when failing autopkgtests are retried after binNMU's happen.
However, in this case because the package dependencies don't declare the
proper relation, britney doesn't pull in the binNMU'ed version and it
*discovers* a relation that's broken.
I don't think you should fix it to accommodate QA, I think you should
fix it to avoid issues with partial upgrades.
Paul
signature.asc
Description: OpenPGP digital signature
Bug#948740: clanlib: FTBFS with $* is no longer supported as of Perl 5.30 at ../Utilities/webbuilder.pl line 74.
Source: clanlib Version: 1.0~svn3827-7 Severity: serious Tags: ftbfs Dear maintainer, your package failed to build in a rebuild I'm performing in current unstable with the following error: Making all in Setup make[2]: Entering directory '/build/clanlib-1.0~svn3827/Setup' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/build/clanlib-1.0~svn3827/Setup' Making all in pkgconfig make[2]: Entering directory '/build/clanlib-1.0~svn3827/pkgconfig' make[2]: Leaving directory '/build/clanlib-1.0~svn3827/pkgconfig' Making all in Documentation make[2]: Entering directory '/build/clanlib-1.0~svn3827/Documentation' Making all in Tutorial make[3]: Entering directory '/build/clanlib-1.0~svn3827/Documentation/Tutorial' Making all in Kavanek make[4]: Entering directory '/build/clanlib-1.0~svn3827/Documentation/Tutorial/Kavanek' echo 01-Installing.html echo index.html 01-Installing.html ../../Utilities/xslt.sh 01-Installing.xml 01-Installing.html ./default.xsl index.html ../../Utilities/xslt.sh index.xml index.html ./default.xsl Done make[4]: Leaving directory '/build/clanlib-1.0~svn3827/Documentation/Tutorial/Kavanek' make[4]: Entering directory '/build/clanlib-1.0~svn3827/Documentation/Tutorial' ../Utilities/webbuilder.pl ./../documentation.theme ./../Tutorial/index.xml $* is no longer supported as of Perl 5.30 at ../Utilities/webbuilder.pl line 74. make[4]: *** [Makefile:779: index.html] Error 255 make[4]: Leaving directory '/build/clanlib-1.0~svn3827/Documentation/Tutorial' make[3]: *** [Makefile:505: all-recursive] Error 1 make[3]: Leaving directory '/build/clanlib-1.0~svn3827/Documentation/Tutorial' make[2]: *** [Makefile:511: all-recursive] Error 1 make[2]: Leaving directory '/build/clanlib-1.0~svn3827/Documentation' make[1]: *** [Makefile:478: all-recursive] Error 1 make[1]: Leaving directory '/build/clanlib-1.0~svn3827' dh_auto_build: make -j4 returned exit code 2 make: *** [debian/rules:34: build] Error 255 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#947936: chrony: Does (still) not start properly on boot on buster
Am 12.01.20 um 18:18 schrieb Michael Biebl: > Am 04.01.20 um 20:22 schrieb Santiago Vila: >> Hi. I managed to put the instances in a state where a reboot does not >> make the problem to go away. Please give it a try. > > I could reproduce the issue on the system provided by Santiago. > > I'm dumping the relevant parts of the log here: From a buster system of mine which has chrony and systemd-timesyncd installed and enabled: > ● chrony.service - chrony, an NTP client/server >Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor > preset: enabled) >Active: active (running) since Sun 2020-01-12 19:48:09 CET; 1min 15s ago > Docs: man:chronyd(8) >man:chronyc(1) >man:chrony.conf(5) > Process: 395 ExecStart=/usr/sbin/chronyd $DAEMON_OPTS (code=exited, > status=0/SUCCESS) > Process: 404 ExecStartPost=/usr/lib/chrony/chrony-helper update-daemon > (code=exited, status=0/SUCCESS) > Main PID: 401 (chronyd) > Tasks: 2 (limit: 1149) >Memory: 3.3M >CGroup: /system.slice/chrony.service >├─401 /usr/sbin/chronyd -F -1 >└─403 /usr/sbin/chronyd -F -1 > > Jan 12 19:48:09 debian systemd[1]: chrony.service: Control process exited, > code=exited, status=0/SUCCESS > Jan 12 19:48:09 debian systemd[1]: chrony.service: Got final SIGCHLD for > state start-post. > Jan 12 19:48:09 debian systemd[1]: chrony.service: Changed start-post -> > running > Jan 12 19:48:09 debian systemd[1]: chrony.service: Job 75 > chrony.service/start finished, result=done > Jan 12 19:48:09 debian systemd[1]: Started chrony, an NTP client/server. > Jan 12 19:48:14 debian systemd[1]: chrony.service: chrony.service/stop would > stop a running service. > Jan 12 19:48:14 debian systemd[1]: chrony.service: Deleting > chrony.service/stop to minimize impact. > Jan 12 19:48:17 debian chronyd[401]: Selected source 162.159.200.1 > Jan 12 19:48:18 debian chronyd[401]: Selected source 173.249.58.145 > Jan 12 19:48:19 debian chronyd[401]: Source 129.70.132.37 replaced with > 2a01:4f8:110:12c8::123 > > ● systemd-timesyncd.service - Network Time Synchronization >Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; > vendor preset: enabled) > Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d >└─disable-with-time-daemon.conf >Active: inactive (dead) > Docs: man:systemd-timesyncd.service(8) > Jan 12 19:48:08 debian systemd-sysv-generator[232]: Native unit for > chrony.service already exists, skipping. > Jan 12 19:48:09 debian audit[296]: AVC apparmor="STATUS" > operation="profile_load" profile="unconfined" name="/usr/sbin/chronyd" > pid=296 comm="apparmor_parser" > Jan 12 19:48:09 debian kernel: audit: type=1400 audit(1578854889.112:7): > apparmor="STATUS" operation="profile_load" profile="unconfined" > name="/usr/sbin/chronyd" pid=296 comm="apparmor_parser" > Jan 12 19:48:09 debian chronyd[401]: chronyd version 3.4 starting (+CMDMON > +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 > -DEBUG) > Jan 12 19:48:09 debian chronyd[401]: Frequency 0.000 +/- 100.000 ppm read > from /var/lib/chrony/chrony.drift > Jan 12 19:48:09 debian chronyd[401]: Loaded seccomp filter > Jan 12 19:48:09 debian systemd[1]: chrony.service: > ConditionCapability=CAP_SYS_TIME succeeded. > Jan 12 19:48:09 debian systemd[1]: chrony.service: Passing 0 fds to service > Jan 12 19:48:09 debian systemd[1]: chrony.service: About to execute: > /usr/sbin/chronyd $DAEMON_OPTS > Jan 12 19:48:09 debian systemd[1]: chrony.service: Forked /usr/sbin/chronyd > as 395 > Jan 12 19:48:09 debian systemd[1]: chrony.service: Changed dead -> start > Jan 12 19:48:09 debian systemd[1]: Starting chrony, an NTP client/server... > Jan 12 19:48:09 debian systemd[395]: Successfully mounted > /tmp/systemd-private-c32de5dec7564bdd85daa27163fecfdb-chrony.service-2LqUhJ/tmp > to /run/systemd/unit-root/tmp > Jan 12 19:48:09 debian systemd[395]: Successfully mounted > /var/tmp/systemd-private-c32de5dec7564bdd85daa27163fecfdb-chrony.service-aYqukO/tmp > to /run/systemd/unit-root/var/tmp > Jan 12 19:48:09 debian systemd[395]: chrony.service: Executing: > /usr/sbin/chronyd -F -1 > Jan 12 19:48:09 debian systemd[1]: Received SIGCHLD from PID 400 (chronyd). > Jan 12 19:48:09 debian systemd[1]: Child 395 (chronyd) died (code=exited, > status=0/SUCCESS) > Jan 12 19:48:09 debian systemd[1]: chrony.service: Child 395 belongs to > chrony.service. > Jan 12 19:48:09 debian systemd[1]: chrony.service: Control process exited, > code=exited, status=0/SUCCESS > Jan 12 19:48:09 debian systemd[1]: chrony.service: Got final SIGCHLD for > state start. > Jan 12 19:48:09 debian systemd[1]: chrony.service: New main PID 401 belongs > to service, we are happy. > Jan 12 19:48:09 debian systemd[1]: chrony.service: Main PID loaded: 401 > Jan 12 19:48:09 debian systemd[1]: chrony.service: About to execute: > /usr/lib/chrony/chrony-helper update-daemon >
Bug#948676: at-spi2-core: /etc/X11/Xsession.d/90qt-a11y does not enable Qt5 support as the Wiki indicates
Control: reassign -1 qtbase-opensource-src
Hello,
Thorsten Glaser, le sam. 11 janv. 2020 21:12:47 +0100, a ecrit:
> https://wiki.debian.org/accessibility-devel says it should export
> QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 but it doesn’t.
>
> Exporting that before starting MuseScore makes the latter show up
> in “orca -l” output, so it’s probably needed.
Yes and no.
There is a permanent battle between enabling accessibility by default,
and enabling it only when actually needed.
See Bug#874054 ("Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a
huge negative performance impact, should not be always on") for more
details. Currently Qt only enables accessibility when the orca screen
reader is enabled in the control panel.
I guess in your case what you expected was that at the very least
applications started after orca got started should be accessible, even
if orca is only started by hand. This would work if Qt was not only
looking at org.a11y.Status ScreenReaderEnabled (the control panel
configuration), but also at org.a11y.Status IsEnabled (set by Orca on
startup). This would not be enough for making existing applications
accessible when you first start Orca, Bug#874054 mentions that it's
because Qt currently doesn't monitor the dbus IsEnabled variable.
Could we at least restore looking at IsEnabled in Qt, as the attached
patch does? Actually, that is needed for proper focus tracking in Qt
applications for zoom support in compiz when Orca is not used. The
comment there says that IsEnabled is always true, but that's not what I
am observing with e.g. Debian 8's gnome 3.14, Debian 9's gnome 3.22, and
Debian 10's 3.30... Ideally, we'd backport this fix to buster too.
Samuel
No, isEnabled does not always return true currently.
We do need to test for isEnabled for the case of running Orca by hand.
It's Orca (or compiz' focuspoll) which sets IsEnabled.
---
src/platformsupport/linuxaccessibility/dbusconnection.cpp |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/src/platformsupport/linuxaccessibility/dbusconnection.cpp
+++ b/src/platformsupport/linuxaccessibility/dbusconnection.cpp
@@ -120,8 +120,7 @@ void DBusConnection::serviceRegistered()
//debugging.
static const bool a11yAlwaysOn =
qEnvironmentVariableIsSet("QT_LINUX_ACCESSIBILITY_ALWAYS_ON");
-// a11yStatus->isEnabled() returns always true (since Gnome 3.6)
-bool enabled = a11yAlwaysOn || a11yStatus->screenReaderEnabled();
+bool enabled = a11yAlwaysOn || a11yStatus->screenReaderEnabled() ||
a11yStatus->isEnabled();
if (enabled != m_enabled) {
m_enabled = enabled;
Bug#948543: gnome-logs: Unable to start gnome-logs due to Segmentation fault
Dear Maintainer, I could reproduce this issue. Upstream fixed this crash with this upstream commit: https://gitlab.gnome.org/GNOME/gnome-logs/commit/7d0062a4ab36d457b74fe17b8d494570d4a0334b A package build with this patch applied still crashes, which got fixed in this upstream commit: https://gitlab.gnome.org/GNOME/gnome-logs/commit/86ae341d6837e7b6b36bd8e0c65be0211ef37eba With both patches applied it does not crash (and shows no logs as expected as non-root user). Both patches seem to be already contained in gnome-logs 3.34.0-1 currently in testing, therefore this issue should just affect Buster or older. Kind regards, Bernhard (gdb) bt #0 0x55a9d5e79b4f in gl_journal_update_latest_timestamp (journal=0x55a9d6de69e0) at ../src/gl-journal.c:98 #1 gl_journal_get_boot_time (journal=0x55a9d6de69e0, boot_match=0x0) at ../src/gl-journal.c:127 #2 0x55a9d5e7b4c9 in gl_journal_model_get_boot_time (model=, boot_match=) at ../src/gl-journal-model.c:1158 #3 0x55a9d5e756b0 in gl_event_view_list_get_boot_time (view=view@entry=0x55a9d6ce53c0, boot_match=) at ../src/gl-eventviewlist.c:402 #4 0x55a9d5e7d721 in on_category_list_changed (list=, pspec=, user_data=) at ../src/gl-window.c:252 #5 0x7f2ddab5fc8d in g_closure_invoke (closure=0x55a9d70b8ba0, return_value=0x0, n_param_values=2, param_values=0x7ffec12b7ee0, invocation_hint=0x7ffec12b7e60) at ../../../gobject/gclosure.c:810 ... #57 0x55a9d5e7155c in main (argc=1, argv=0x7ffec12b9858) at ../src/gl-main.c:39 (gdb) # Buster/stable amd64 qemu VM 2020-01-12 apt update apt dist-upgrade apt install systemd-coredump gnome apt build-dep gnome-logs mkdir /home/benutzer/source/gnome-logs/orig -p cd/home/benutzer/source/gnome-logs/orig apt source gnome-logs cd benutzer@debian:~$ export DISPLAY=:0 benutzer@debian:~$ gnome-logs ** (gnome-logs:3016): WARNING **: 19:13:04.073: Error retrieving the sender timestamps: Die angeforderte Adresse kann nicht zugewiesen werden Speicherzugriffsfehler (Speicherabzug geschrieben) dmesg: [ 121.990363] gnome-logs[3016]: segfault at 17fff8 ip 55a9d5e79b4f sp 7ffec12b7cc0 error 4 in gnome-logs[55a9d5e7+e000] [ 121.990370] Code: 43 18 48 8b 3b 48 89 e6 8b 50 08 48 8b 00 83 ea 01 48 8d 14 52 4c 8d 24 d0 e8 4d 6b ff ff 85 c0 0f 88 fd 00 00 00 48 8b 04 24 <49> 39 44 24 10 0f 82 8e 00 00 00 48 8b 3b e8 5e 70 ff ff 85 c0 0f root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Sun 2020-01-12 19:13:04 CET3016 1000 1000 11 present /usr/bin/gnome-logs root@debian:~# coredumpctl gdb 3016 PID: 3016 (gnome-logs) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 11 (SEGV) Timestamp: Sun 2020-01-12 19:13:04 CET (1min 13s ago) Command Line: gnome-logs Executable: /usr/bin/gnome-logs Control Group: /user.slice/user-1000.slice/session-5.scope Unit: session-5.scope Slice: user-1000.slice Session: 5 Owner UID: 1000 (benutzer) Boot ID: 31e1a4dac60f43c3b142249a971244a8 Machine ID: 33f18f39d2a9438eb75b0ed52848afcd Hostname: debian Storage: /var/lib/systemd/coredump/core.gnome-logs.1000.31e1a4dac60f43c3b142249a971244a8.3016.157885278400.lz4 Message: Process 3016 (gnome-logs) of user 1000 dumped core. Stack trace of thread 3016: #0 0x55a9d5e79b4f n/a (gnome-logs) #1 0x55a9d5e7d721 n/a (gnome-logs) #2 0x7f2ddab5fc8d g_closure_invoke (libgobject-2.0.so.0) #3 0x7f2ddab73365 n/a (libgobject-2.0.so.0) #4 0x7f2ddab7c2be g_signal_emit_valist (libgobject-2.0.so.0) #5 0x7f2ddab7c97f g_signal_emit (libgobject-2.0.so.0) #6 0x7f2ddab64364 n/a (libgobject-2.0.so.0) #7 0x7f2ddab66921 g_object_notify_by_pspec (libgobject-2.0.so.0) #8 0x55a9d5e72691 n/a (gnome-logs) #9 0x7f2ddab5fc8d g_closure_invoke (libgobject-2.0.so.0) #10 0x7f2ddab73365 n/a (libgobject-2.0.so.0) #11 0x7f2ddab7c2be g_signal_emit_valist (libgobject-2.0.so.0) #12 0x7f2ddab7c97f g_signal_emit (libgobject-2.0.so.0) #13 0x7f2dda56f735 n/a (libgtk-3.so.0) #14 0x7f2dda573192 n/a (libgtk-3.so.0) #15 0x7f2dda573280 n/a (libgtk-3.so.0) #16 0x7f2dd9aa38ee ffi_call_unix64 (libffi.so.6) #17 0x7f2dd9aa32bf ffi_call (libffi.so.6) #18 0x7f2ddab60906 g_cclosure_marshal_generic_va (libgobject-2.0.so.0) #19 0x7f2ddab5fec6 n/a (libgobject-2.0.so.0) #20 0x7f2ddab7c38d g_signal_emit_valist (libgobject-2.0.so.0) #21 0x7f2ddab7c97f g_signal_emit (libgobject-2.0.so.0) #22
Bug#936464: eclipse-titan: diff for NMU version 6.6.0-1.1
On Sun, Jan 12, 2020 at 10:55:28AM +0100, Pilisi Gergely wrote: > Hi, Hi, > thank you for your upload. Currently I'm preparing the 6.6.1 version > without python2 dependency. > But we still need python3 because the package installs a python script to > this path: > /usr/share/titan/etc/scripts > So I suggest to use python3 instead of completely removing this dependency. thanks, I missed this. Your new package addresses the bug, I have cancelled my NMU. > BR, > Gergely Pilisi Thanks Adrian
Bug#948710: openssh-server: Fail to upgrade "ssh.service: Unit -.mount is masked"
Control: clone -1 -2 Control: reassign -2 gparted 0.32.0-2 Control: retitle -2 gparted should not mask .mount units Control: retitle -1 handle masked .mount unit more gracefully Control: severity -1 important On Sun, 12 Jan 2020 18:06:41 + Colin Watson wrote: > The OpenSSH units don't make any reference to a -.mount unit (explicitly > or implicitly, as far as I can tell), That's not quite true. ssh.service (and the vast majority of services) uses DefaultDependencies=yes (as it is the default behaviour). This will generate a dependency on various .mount units, depending on your /etc/fstab. $ systemctl show ssh.service -p Requires -p After Requires=system.slice -.mount sysinit.target After=auditd.service system.slice basic.target systemd-journald.socket network.target sysinit.target -.mount so I can only assume that this is > some kind of bug in systemd itself; reassigning over there. Feel free > to reassign back if it seems that this is a bug in ssh.service after > all, but in that case I'd appreciate some kind of specific advice on> what > it's doing wrong. The ssh.service is doing nothing wrong. I'd say we have two bugs here: a/ a package or user doing something stupid like masking _.mount b/ systemd not handling that case more gracefully. I quickly checked the gparted sources and noticed that it still does mask all .mount units. gparted.in: | grep -v masked | cut -f1 -d' ' \ gparted.in: systemctl --runtime mask --quiet -- $MOUNTLIST gparted.in: systemctl --runtime unmask --quiet -- $MOUNTLIST So cloning and re-assinging the bug report. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#948727: qgis-providers: postinst creates /.local/share/crssync and/or /root/.local/share/crssync
Control: tags -1 upstream Control: forwarded -1 https://github.com/qgis/QGIS/issues/33743 This is an upstream issue with crssync which should not create these directories by default. Follow up in the upstream issue. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#948738: pysph needs hinting into testing
Package: release.debian.org Severity: normal Issues preventing migration: uninstallable on arch arm64, autopkgtest delayed there For background see #918620. Thanks in advance
Bug#946728: hugo: diff for NMU version 0.59.1-1.1
Control: tags 946728 + patch Control: tags 946728 + pending Dear maintainer, I've prepared an NMU for hugo (versioned as 0.59.1-1.1) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru hugo-0.59.1/debian/changelog hugo-0.59.1/debian/changelog --- hugo-0.59.1/debian/changelog 2020-01-07 14:07:13.0 +0200 +++ hugo-0.59.1/debian/changelog 2020-01-12 20:21:11.0 +0200 @@ -1,3 +1,11 @@ +hugo (0.59.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Depend and build depend on the new version of +golang-github-kyokomi-emoji-dev. (Closes: #946728) + + -- Adrian Bunk Sun, 12 Jan 2020 20:21:11 +0200 + hugo (0.59.1-1) unstable; urgency=medium * New upstream version 0.59.1 diff -Nru hugo-0.59.1/debian/control hugo-0.59.1/debian/control --- hugo-0.59.1/debian/control 2020-01-07 14:06:42.0 +0200 +++ hugo-0.59.1/debian/control 2020-01-12 20:21:11.0 +0200 @@ -34,7 +34,7 @@ golang-github-googleapis-gax-go-dev (>= 2.0.2~), golang-github-gorilla-websocket-dev (>= 1.4.0~), golang-github-jdkato-prose-dev, - golang-github-kyokomi-emoji-dev (>= 0.2.1~), + golang-github-kyokomi-emoji-dev (>= 2.1.0-1~), golang-github-markbates-inflect-dev, golang-github-mattn-go-isatty-dev (>= 0.0.8~), golang-github-miekg-mmark-dev, @@ -121,7 +121,7 @@ golang-github-google-go-cmp-dev (>= 0.3.1~), golang-github-gorilla-websocket-dev (>= 1.4.0~), golang-github-jdkato-prose-dev, - golang-github-kyokomi-emoji-dev (>= 0.2.1~), + golang-github-kyokomi-emoji-dev (>= 2.1.0-1~), golang-github-markbates-inflect-dev, golang-github-mattn-go-isatty-dev (>= 0.0.8~), golang-github-miekg-mmark-dev,
Bug#948737: stretch-pu: package python-pgmagick/0.6.4-1+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
https://tests.reproducible-builds.org/debian/rb-pkg/stretch/amd64/python-pgmagick.html
* Backport upstream FTBFS fix to handle version detection
of graphicsmagick security updates that identify themself
as version 1.4.
The fix is already included in the version in buster.
diff -Nru python-pgmagick-0.6.4/debian/changelog
python-pgmagick-0.6.4/debian/changelog
--- python-pgmagick-0.6.4/debian/changelog 2017-01-22 15:45:47.0
+0200
+++ python-pgmagick-0.6.4/debian/changelog 2020-01-12 19:44:17.0
+0200
@@ -1,3 +1,12 @@
+python-pgmagick (0.6.4-1+deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport upstream FTBFS fix to handle version detection
+of graphicsmagick security updates that identify themself
+as version 1.4.
+
+ -- Adrian Bunk Sun, 12 Jan 2020 19:44:17 +0200
+
python-pgmagick (0.6.4-1) unstable; urgency=medium
* New upstream release
diff -Nru
python-pgmagick-0.6.4/debian/patches/0001-Refactor-DPGMAGICK_LIB_GRAPHICSMAGICK-detection.patch
python-pgmagick-0.6.4/debian/patches/0001-Refactor-DPGMAGICK_LIB_GRAPHICSMAGICK-detection.patch
---
python-pgmagick-0.6.4/debian/patches/0001-Refactor-DPGMAGICK_LIB_GRAPHICSMAGICK-detection.patch
1970-01-01 02:00:00.0 +0200
+++
python-pgmagick-0.6.4/debian/patches/0001-Refactor-DPGMAGICK_LIB_GRAPHICSMAGICK-detection.patch
2020-01-12 19:43:47.0 +0200
@@ -0,0 +1,65 @@
+From 360e1d7e833189339146dc633176ccda15be04d6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Juraj=20Koma=C4=8Dka?=
+Date: Wed, 12 Jul 2017 08:11:55 +0200
+Subject: Refactor -DPGMAGICK_LIB_GRAPHICSMAGICK detection
+
+Use new function library_supports_api that will provide easy way to support
different major and minor versions in the future.
+---
+ setup.py | 34 ++
+ 1 file changed, 22 insertions(+), 12 deletions(-)
+
+diff --git a/setup.py b/setup.py
+index 00a1bde..b32e1a4 100644
+--- a/setup.py
b/setup.py
+@@ -75,6 +75,24 @@ def find_file(filename, search_dirs):
+ return root
+ return False
+
++def library_supports_api(library_version, api_version,
different_major_breaks_support=True):
++"""
++Returns whether api_version is supported by given library version.
++E. g. library_version (1,3,21) returns True for api_version (1,3,21),
(1,3,19), (1,3,'x'), (1,2,'x'), (1, 'x')
++ False for (1,3,24), (1,4,'x'), (2,'x')
++
++different_major_breaks_support - if enabled and library and api major
versions are different always return False
++ ex) with library_version (2,0,0) and for api_version(1,3,24)
returns False if enabled, True if disabled
++"""
++assert isinstance(library_version, (tuple, list)) # won't work with e.g.
generators
++assert len(library_version) == 3
++sequence_type = type(library_version) # assure we will compare same types
++api_version = sequence_type(0 if num == 'x' else num for num in
api_version)
++if different_major_breaks_support and library_version[0] !=
api_version[0]:
++return False
++assert len(api_version) <= 3 # otherwise following comparision won't
work as intended, e.g. (2, 0, 0) > (2, 0, 0, 0)
++return library_version >= api_version
++
+ # find to header path
+ header_path = find_file('Magick++.h', search_include_dirs)
+ if not header_path:
+@@ -138,18 +156,10 @@ if _version:
+ # ex) 1.2 -> 1.2.0
+ _version.append(0)
+ if LIBRARY == 'GraphicsMagick':
+-ext_compile_args = []
+-if _version[0] == 1 and _version[1] == 3 and _version[2] >= 24:
+-ext_compile_args.append("-DPGMAGICK_LIB_GRAPHICSMAGICK_1_3_24")
+-if _version[0] == 1 and _version[1] == 3 and _version[2] >= 22:
+-ext_compile_args.append("-DPGMAGICK_LIB_GRAPHICSMAGICK_1_3_22")
+-if _version[0] == 1 and _version[1] == 3 and _version[2] >= 20:
+-ext_compile_args.append("-DPGMAGICK_LIB_GRAPHICSMAGICK_1_3_20")
+-if _version[0] == 1 and _version[1] == 3 and _version[2] == 19:
+-ext_compile_args.append("-DPGMAGICK_LIB_GRAPHICSMAGICK_1_3_19")
+-if _version[0] == 1 and _version[1] == 3 and _version[2] >= 6:
+-# for not Ubuntu10.04
+-ext_compile_args.append("-DPGMAGICK_LIB_GRAPHICSMAGICK_1_3_6")
++# 1.3.6 for not Ubuntu10.04
++_tested_api_versions = ((1,3,26), (1,3,24), (1,3,22), (1,3,20),
(1,3,19), (1,3,6))
++_supportedApiVersions = (v for v in _tested_api_versions if
library_supports_api(_version, v))
++ext_compile_args = ["-DPGMAGICK_LIB_GRAPHICSMAGICK_" +
'_'.join(map(str, version)) for version in _supportedApiVersions]
+ if not (_version[0] == 1 and _version[1] == 1):
+ # for GM version 1.3.x and higher
+
