Bug#950465: RM: pyexiv2 -- ROM; python 2 only, not maintained
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi I think it's time to remove pyexiv2. It's Python 2 only package. The recommended upstream approach was to use GI (and gir1.2-gexiv2-0.10) and that's where most of the reverese dependencies have migrated. - -- Michal Čihař | https://cihar.com/ | https://weblate.org/ -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEh+Zzr4P2w6DDRMjD9KoinU1YwkUFAl42eGAACgkQ9KoinU1Y wkUODg//WHBtlv+FvtahDbBgus12Cj3CV+nI/2KyhKWLYdu15ySt8MUPM+QjzQOT fiBWmCZwfHWEkLLKiwKkgp9A/j9kVctyk5qU99facfg0Q5sbEGChtishsUQiaaSL KwR/h6/Igca7H9gV+IOTK/uHFoQsSoKAr0AzhztEXk7x7iP0hYaWy1vworBxBFn8 6llOMk97SWMT9aeTdLhto8+2Jj3YvjGPAajpk1/1RpyjnYZazVwUoVEekdl4eITF m3Hjc3u41cytEk7OilrvPOQGsoYj9ecYbWywgHvx5w1YkqEYhVDsJvXFW2sLzMGu HHN0PESRDXjwTgKnWdkPP5U9E7n/iDUoOrZBXttu/aaaLIW+ctnQbMAqOEhz/MDn FBoRScSVDvwJPI3IyYgL20GmP7qXj6JcjiKKdhNWGRTVJ92UWZIgmeCkV6X2BU7V wLTAtMruJ0lttmJX3pkKCsgOBih8r300E9hVO+jjKBQkXfRJdix4CpipHBsYkzq0 PArf8j+iXE6ucoLznOBBXKhZ6fRkMmZPF/z6yt33VeKOihzZeil7rrU4JPQ4SgPq isSY52GJQslrOUDyRc4OAJ+CeLlXanHBb/FwdD1IerMXZfPqwdisfDjSVpVL/2yT 2yCExU3XJzIu3JhIHowbC08PGZa0608GhPwxCL5sNyYvRirjo1Y= =Mn+x -END PGP SIGNATURE-
Bug#948477: Update to openbabel3 done
Control: reopen -1 Hi Georges, On 01-02-2020 20:29, Georges Khaznadar wrote: > ... But I forgot to close the bugreport in debian/changes. Which is good, because that's not how these bugs work. These bugs are managed by us and are only closed when the transition is finished. As openbabel3 could smooth-update, the old library is allowed to stay around and the transition is only finished when that's gone from testing. Paul signature.asc Description: OpenPGP digital signature
Bug#950464: pygobject: autopkgtest fails with changes to .pc files in python3.8
Package: pygobject
Version: 3.34.0-5
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch
Dear maintainers,
In Ubuntu, the 'build3' autopkgtest has started to fail in pygobject because
Ubuntu has moved default python3 to python3.8, and in the python3.8 package,
python3.pc no longer says to link against libpython (now being intended only
for modules rather than for applications embedding python), and applications
which need to embed libpython need to use python3-embed.pc instead.
I've verified that the attached patch fixes the autopkgtest failure in
Ubuntu, and it should work for Debian as well once python3-defaults 3.8
leaves experimental.
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 pygobject-3.34.0/debian/tests/build3
pygobject-3.34.0/debian/tests/build3
--- pygobject-3.34.0/debian/tests/build32020-01-29 16:20:26.0
-0800
+++ pygobject-3.34.0/debian/tests/build32020-02-01 22:15:13.0
-0800
@@ -34,7 +34,7 @@
# Deliberately word-splitting, that's how pkg-config works:
# shellcheck disable=SC2046
-"${CROSS_COMPILE}gcc" -o pytest pytest.c $("${CROSS_COMPILE}pkg-config"
--cflags --libs python3 pygobject-3.0)
+"${CROSS_COMPILE}gcc" -o pytest pytest.c $("${CROSS_COMPILE}pkg-config"
--cflags --libs python3-embed pygobject-3.0)
echo "build: OK"
[ -x pytest ]
./pytest
Bug#950463: python3-theano: Installing theano shows SyntaxWarnings (and some questionable code)
Package: python3-theano
Version: 1.0.4+dfsg-1
Severity: normal
Hi. First of all, thanks for packaging Theano. It is really appreciated.
Now, to the bug report. I was just installing python3-theano now and it
showed some warnings:
,
| Setting up python3-parameterized (0.7.0-2) ...
| Setting up python3-theano (1.0.4+dfsg-1) ...
| /usr/lib/python3/dist-packages/theano/compile/mode.py:264: SyntaxWarning:
"is" with a literal. Did you mean "=="?
| if optimizer is 'default':
| /usr/lib/python3/dist-packages/theano/gof/op.py:1543: SyntaxWarning: 'str'
object is not callable; perhaps you missed a comma?
| define_macros.append("#define INPUT_%d %s" (i, inp))
| /usr/lib/python3/dist-packages/theano/gof/op.py:1547: SyntaxWarning: 'str'
object is not callable; perhaps you missed a comma?
| define_macros.append("#define OUTPUT_%d %s" (i, inp))
| /usr/lib/python3/dist-packages/theano/gof/opt.py:1287: SyntaxWarning: "is"
with a literal. Did you mean "=="?
| if len(tracks) is 0:
| /usr/lib/python3/dist-packages/theano/gof/tests/test_link.py:116:
SyntaxWarning: "is" with a literal. Did you mean "=="?
| assert 1.0 is fn(1.0)
| /usr/lib/python3/dist-packages/theano/tensor/nnet/bn.py:645: SyntaxWarning:
"is" with a literal. Did you mean "=="?
| return [theano.gradient.DisconnectedType()() if r is 0 else r
| /usr/lib/python3/dist-packages/theano/tensor/nnet/tests/test_conv.py:98:
SyntaxWarning: "is not" with a literal. Did you mean "!="?
| if border_mode is not 'full':
| /usr/lib/python3/dist-packages/theano/tests/test_determinism.py:60:
SyntaxWarning: "is not" with a literal. Did you mean "!="?
| if var.name is not None and var.name is not 'b':
`
All of these warnings are easy to solve and show some questionable code, like:
,
| define_macros.append("#define OUTPUT_%d %s" (i, inp))
`
It would be great if we could have a new upload with these bugs fixed.
Thanks,
Rogério Brito.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8),
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python3-theano depends on:
ii libatlas-base-dev [libblas.so]3.10.3-9
ii libopenblas-pthread-dev [libblas.so] 0.3.7+ds-7
ii python3 3.7.5-3
ii python3-dev 3.7.5-3
ii python3-numpy 1:1.17.4-5
ii python3-scipy 1.3.3-3
ii python3-six 1.14.0-2
Versions of packages python3-theano recommends:
ii cython30.29.14-0.1+b1
ii g++4:9.2.1-3.1
ii graphviz 2.42.2-3
ii libgpuarray-dev0.7.6-5
ii python3-nose 1.3.7-4
ii python3-parameterized 0.7.0-2
ii python3-pkg-resources 44.0.0-1
ii python3-pydot 1.4.1-3
ii python3-pygpu 0.7.6-5
Versions of packages python3-theano suggests:
pn nvidia-cuda-toolkit
pn python3-pycuda
pn theano-doc
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#879631: flask_socketio import error persists - pls help
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896360 I have problems installing flask_socketio (when running flask, I get "ModuleNotFoundError: No module named 'flask_socketio'"). I tried setting FLASK_DEBUG=0 (apparently that worked for someone I read) and tried uninstalling and re-installing (re-installing when installed just gives me a bunch of "Requirement already satisfied"). I set up a brand new virtual environment and if it helps below is my pip freeze and the complete error. Am using python version 3.6.8. (Apologies- I'm a beginner,so maybe there is too much or incomplete info..) Click==7.0 dnspython==1.16.0 eventlet==0.25.1 Flask==1.1.1 Flask-SocketIO==4.2.1 greenlet==0.4.15 itsdangerous==1.1.0 Jinja2==2.11.1 MarkupSafe==1.1.1 monotonic==1.5 pkg-resources==0.0.0 python-engineio==3.11.2 python-socketio==4.4.0 six==1.14.0 Werkzeug==0.16.1 --- (py2) anna@DESKTOP-CD69S60:/mnt/c/git/project2$ flask run * Serving Flask app "application.py" * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: off Usage: flask run [OPTIONS] Error: While importing "application", an ImportError was raised: Traceback (most recent call last): File "/home/anna/.local/lib/python3.6/site-packages/flask/cli.py", line 240, in locate_app __import__(module_name) File "/mnt/c/git/project2/application.py", line 4, in from flask_socketio import SocketIO, emit ModuleNotFoundError: No module named 'flask_socketio'
Bug#950462: openpyxl: please build and ship documentation
Source: openpyxl Severity: normal Hello, the source package contains a doc/ directory, containing sphinx doc: can you please build it and start producing a -doc package with it? thanks, 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#950237: squid CVE-2019-18676 and CVE-2019-12523 status
Control: 950237 fixed 4.9 On Thu, 30 Jan 2020 11:53:30 + Christian Ruppert wrote: > Package: squid > Version: 3.5.23-5+deb9u1 > > Hi, > > I just wanted to ask if there's any ETA for > https://security-tracker.debian.org/tracker/CVE-2019-18676 and > https://security-tracker.debian.org/tracker/CVE-2019-12523 for jessie > and buster. The other ones had been fixed already. Patches are > available according to the security tracker. There is not. Whether it happens at all will depend on the LTS backporters. The patch available assumes some features of Squid-4 and C++11 compiler capabilities not supported in Squid-3.x. So the port has some work required. Amos
Bug#950461: libical3: Please update to 3.0.7
Source: libical3 Version: 3.0.5-2 Severity: wishlist evolution-data-server 3.36 requires libical 3.0.7. Please package the new version. https://github.com/libical/libical/releases Thanks, Jeremy Bicha
Bug#920147: Sage FTBFS on mipsel + mips64el
On the off-chance they're relevant and Jmol is a red herring, I'm re-sending my misplaced comments [1] about relevant parts of /usr/bin/sage here: > By the way, looking at the header of that file I see > # workaround #892622; unfortunately we can't simply run setarch -R when > running Singular > # because src/sage/libs/singular/singular.pyx loads libsingular.so into the > current process > if [ "$(arch)" = "mips64" -a -z "$SAGE_DEB_MIPS64_WORKAROUND" ]; then > SAGE_DEB_MIPS64_WORKAROUND=1 exec setarch mips64 -R "$0" "$@" > fi > > I don't understand the test inside the brackets. Why do you use -a [in > addition to the -z] when there is no mention of a file? And if you're > checking equality, shouldn't that be a double equals sign (==)? > > Furthermore, the code refers to mips64, but #892622 refers to mips64el. Is > it possible these issues are the cause of Sage failing to build from source > there (#920147)? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948731#12 signature.asc Description: This is a digitally signed message part.
Bug#950450: libm4rie-0.0.20200125: Depends on libm4ri-0.0.20200115
libm4ri is in NEW I would guess that the maintainer uploaded libm4ri and libm4rie to the new queue together, but the ftpmasters only released the latter and not the former. The question I guess is whether it is worth doing a source only upload of libm4rie now, only to have to get it rebuilt again when the ftpmasters get around to releasing libm4ri from NEW
Bug#950287: autofs: automount expriing unmounts target filesystem
On Sat, 2020-02-01 at 22:39 +0100, Marc Lehmann wrote: > On Sat, Feb 01, 2020 at 07:41:03AM +0800, Ian Kent > wrote: > > > decided that nobody should use symlinks as bind mounts are the > > > future(tm). > > > From an upstream POV it was more neglect (on my part) of the > > symlink code in favour of bind mounts. > > Not sure why you write this, but it's clearly not true: > >Date: Tue, 29 May 2001 14:00:42 -0700 >[...] >I don't want to perpetuate the symlink thing because it is a > terrible >hack in the kernel part of the code, and thus will be removed in > autofs >v5. > >-hpa > > (I hope he forgives me to quote a private mail, but the fact is > documented > in debian bug #128171). > > That was probably a bit before your time, but the last time I > reported > problems with symlinks to upstream I was told (in a long thread) that > it > is a hack and will not be supported. Yes, it was before my time and things have changed a lot. TBH I'm not sure what hpa was referring to there. He may have been talking about the abuse of symlink following in the VFS to effect automounting, but that's long since been resolved by adding automount support to the VFS itself, not only for use by autofs but other file systems like NFS, CIFS, AFS, etc.. > > And the result was that the debian maintainer locally applied a patch > (in > 2006) to make symlinks configurable, for which I was super-thankful. > > (Note that there are two sides to this: symlinks for local nfs > mounts, and > symlinks for bind mounts, which are not the same, and which confused > me for > quite a while). > > > But the autofs amd format map support needs them to work properly > > so quite a bit of effort went into making them work as best as I > > could. > > Yes, I am very fond of this change in policy, thanks a lot - the > effect is > that I can consider autofs again for new deployments, rather than > having > had to give up on it :) I also am very fond of amd map support, > although > documentation, of course, is sorely lacking. Yeah, but the amd support is very much for people that can't convert their maps to autofs format to get the same function. You can always look to: https://www.am-utils.org/docs/am-utils/am-utils.pdf while it's still around. Then it's just a matter of working out what's not supported in autofs and that's not all that much. The main problem with using autofs with amd maps is the way autofs works internally, it's different to amd so you end up with more actual mounts which isn't ideal from an amd POV. > > In any case, since we all seems to agree on the bug part, I think > this > part of the disucssion (who stated what policy when) should stay off > the > debian bts :) Agreed, the autofs mailing list is the better place for these discussions, ;) Ian
Bug#950460: libdata-messagepack-perl: FTBFS with msgpack-c/3.2.1-1
Source: libdata-messagepack-perl
Version: 1.00-2
Severity: important
While testing reverse build-deps of msgpack-c against the latest version
(currently in experimental), your package failed to build:
x86_64-linux-gnu-gcc -c "-I." "-I." -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -Wall -W -Wno-comment -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -D_REENTRANT
-D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include
-DVERSION=\"1.00\" -DXS_VERSION=\"1.00\" -o xs-src/MessagePack.o -fPIC
"-I/usr/lib/x86_64-linux-gnu/perl/5.30/CORE" -DUSE_PPPORT xs-src/MessagePack.c
x86_64-linux-gnu-gcc -c "-I." "-I." -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -Wall -W -Wno-comment -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -D_REENTRANT
-D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include
-DVERSION=\"1.00\" -DXS_VERSION=\"1.00\" -o xs-src/pack.o -fPIC
"-I/usr/lib/x86_64-linux-gnu/perl/5.30/CORE" -DUSE_PPPORT xs-src/pack.c
In file included from xs-src/pack.c:45:
/usr/include/msgpack/pack_template.h:897:65: error: unknown type name
‘msgpack_timestamp’
897 | msgpack_pack_inline_func(_timestamp)(msgpack_pack_user x, const
msgpack_timestamp* d)
|
^
/usr/include/msgpack/pack_template.h: In function ‘msgpack_pack_timestamp’:
/usr/include/msgpack/pack_template.h:899:21: error: request for member ‘tv_sec’
in something not a structure or union
899 | if int64_t)d->tv_sec) >> 34) == 0) {
| ^~
/usr/include/msgpack/pack_template.h:900:40: error: request for member
‘tv_nsec’ in something not a structure or union
900 | uint64_t data64 = ((uint64_t) d->tv_nsec << 34) |
(uint64_t)d->tv_sec;
|^~
/usr/include/msgpack/pack_template.h:900:70: error: request for member ‘tv_sec’
in something not a structure or union
900 | uint64_t data64 = ((uint64_t) d->tv_nsec << 34) |
(uint64_t)d->tv_sec;
| ^~
In file included from /usr/lib/x86_64-linux-gnu/perl/5.30/CORE/perl.h:1159,
from ./xshelper.h:36,
from xs-src/pack.c:5:
/usr/include/msgpack/pack_template.h:918:9: error: request for member ‘tv_nsec’
in something not a structure or union
918 | _msgpack_store32([0], d->tv_nsec);
| ^~~~
In file included from /usr/include/msgpack/sysdep.h:91,
from /usr/include/msgpack/pack_define.h:13,
from xs-src/pack.c:7:
/usr/include/msgpack/pack_template.h:919:9: error: request for member ‘tv_sec’
in something not a structure or union
919 | _msgpack_store64([4], d->tv_sec);
| ^~~~
make[1]: *** [Makefile:357: xs-src/pack.o] Error 1
make[1]: Leaving directory '/<>'
make: *** [/usr/share/cdbs/1/class/makefile.mk:77: debian/stamp-makefile-build]
Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
It appears to be mis-handling the new timestamp related types added in
msgpack-c 3.1.0.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on localhost
+==+
| libdata-messagepack-perl 1.00-2 (amd64) Sun, 02 Feb 2020 00:45:27 + |
+==+
Package: libdata-messagepack-perl
Version: 1.00-2
Source Version: 1.00-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary
I: NOTICE: Log filtering will replace
'var/run/schroot/mount/unstable-amd64-sbuild-38ce2b69-f844-4e15-a7a0-22cacd945a64'
with '<>'
I: NOTICE: Log filtering will replace
'build/libdata-messagepack-perl-0J6vzW/resolver-Uv8PxX'
Bug#937063: moin: updating py2 removal status
> We're using moin for the Debian wiki, so we can't sensibly just remove > it from Debian. Upstream are working on python3 migration, but only > for the new moin2 codebase. I'm watching the work going on there to > see when it makes sense for us to start playing with it... that seems a sensible decision, but by looking at their progress (and in particular at https://github.com/moinwiki/moin/issues/941) it appears upstream is working on the python3 porting rather slowly. Did you have a chance to look at the codebase yet? is there someone that could lend a hand to the moin team to speed up development? once we have a py3k codebase in Debian then there will be also need to develop a plan to migrate our current wiki instance to the new software (http://moinmo.in/MoinMoin2.0 mentions several chances). Cheers, Sandro
Bug#950459: initscripts: bootmisc.sh needs to set SE Linux context after file creation
Package: initscripts
Version: 2.96-2.1
Severity: normal
Tags: patch
The following patch gives the correct SE Linux context for this file and does
nothing on systems that don't have SE Linux. Generally any time a system
script creates a file and needs to run chmod or similar it will need to run
restorecon.
--- /etc/init.d/bootmisc.sh.orig2020-02-02 00:28:31.053649650 +
+++ /etc/init.d/bootmisc.sh 2020-02-02 00:29:32.454386939 +
@@ -35,6 +35,7 @@
if > "${utmp}" ; then
chgrp utmp "${utmp}" || log_warning_msg "failed to chgrp
${utmp}"
chmod 664 "${utmp}" || log_warning_msg "failed to chmod
${utmp}"
+ [ -x /sbin/restorecon ] && /sbin/restorecon "${utmp}"
return 0
else
log_failure_msg "failed to truncate ${utmp}"
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default
Versions of packages initscripts depends on:
ii coreutils 8.30-3+b1
ii debianutils 4.9.1
ii lsb-base11.1.0
ii sysv-rc 2.96-2.1
ii sysvinit-utils 2.96-2.1
Versions of packages initscripts recommends:
iu e2fsprogs 1.45.5-2
ii psmisc 23.2-1
initscripts suggests no packages.
-- Configuration Files:
/etc/init.d/bootmisc.sh changed [not included]
/etc/rc.local changed [not included]
-- no debconf information
Bug#950412: mew-beta: does not validate server certificate subject
On February 1, 2020 at 6:29PM +0900, tats (at debian.org) wrote: > Control: clone -1 -2 > Control: reassign -2 mew-beta > Control: retitle -2 mew-beta: does not validate server certificate subject > Control: found -2 7.0.50~6.7+0.20161225-1 > Control: found -2 7.0.50~6.8+0.20190228-1 > Control: fixed -2 7.0.50~6.8+0.20200130-1 > > The mew-beta package is also affected. Patch updated for buster, mew-beta 7.0.50~6.8+0.20190228-1. Thanks, -- Tatsuya Kinoshita Subject: Enable checkHost for stunnel Origin: upstream, https://github.com/kazu-yamamoto/Mew/commit/8de0a1398f10d0e8da29ce91ec22af17430c0004 Bug: https://github.com/kazu-yamamoto/Mew/pull/133 --- a/mew-ssl.el +++ b/mew-ssl.el @@ -109,6 +109,8 @@ insert no extra text.") (if mew-ssl-unixlike (insert "pid=\n")) (insert (format "verify=%d\n" (mew-ssl-verify-level case))) + (if (> (mew-ssl-verify-level case) 0) + (insert (format "checkHost=%s\n" server))) (if mew-ssl-unixlike (insert "foreground=yes\n")) (insert "debug=debug\n") pgpmkVoN7cOnX.pgp Description: PGP signature
Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu
Quoting Francesco Poli (2020-02-01 16:52:47) > The only differences shown in the resulting report_diffoscope.html file seem > to be: > > • the generated files in the content > of ./boot/initrd.img-5.4.0-3-amd64 have differing creation > timestamps (but this is obvious, since the two initrd were not > created exactly at the same time!) > > • ./var/lib/initramfs-tools/5.4.0-3-amd64 files differ (but they seem > to include some checksum of the initrd, hence the difference should > be consequence of the first point) this should go away when you set SOURCE_DATE_EPOCH to something like $(date +%s) -- why didn't you set it in your tests? > • ./etc/machine-id and ./var/lib/dbus/machine-id files differ (but I > think this should not be surprising...) In the next mmdebstrap release /etc/machine-id will be set to an empty file. > • ./usr/lib/python3.7/__pycache__/hashlib.cpython-37.pyc files have > some different hex values (I am not sure why, but it's compiled > Python code, maybe it includes a compilation timestamp or > something?!?) This is a known bug that I have yet to report to the Python maintainers. > I am under the impression that the two .tar files are to be considered > equivalent. > Do you agree? Yes. :) signature.asc Description: signature
Bug#950458: node-babel-traverse: Duplicate paragraph in long description
Package: node-babel-traverse Severity: minor Dear Maintainer, The long description of node-babel-traverse currently contains twice the paragraph "Babel is a JavaScript compiler to use next generation JavaScript, today.". Thanks a lot for maintaining node-babel. Thomas -- System Information: Debian Release: 10.2 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages node-babel-traverse depends on: pn node-babel-code-frame pn node-babel-messages pn node-babel-runtime pn node-babel-types pn node-babylon pn node-debug pn node-globals pn node-invariant pn node-lodash ii nodejs 10.15.2~dfsg-2 node-babel-traverse recommends no packages. node-babel-traverse suggests no packages.
Bug#950457: linux-image-5.4.0-0.bpo.2-amd64: Regression: mount option not correctly handled
Package: src:linux Version: 5.4.8-1~bpo10+1 Severity: important Hi, I'm using singularity on kvm Debian machines. After the last upgrade that installed the linux-image-5.4.0-0.bpo.2-amd64 kernel, I cannot start any singularity image. The error is: $ singularity -v -v shell /srv/scratch/atac-20180906-012322.simg [...] VERBOSE: Mounting squashfs image: /dev/loop0 -> /var/lib/singularity/mnt/container ERROR : Failed to mount squashfs image in (read only): Invalid argument ABORT : Retval = 255 Using strace, I investiguate the problem, and find this: # mount -o ro,loop,offset=31,errors=remount-ro -t squashfs /srv/scratch/atac-20180906-012322.simg /mnt/ mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error. # mount -o ro,loop,offset=31 -t squashfs /srv/scratch/atac-20180906-012322.simg /mnt/ # ls /mnt [ all file of my singularity image ] With the previous installed kernel (5.3.0-0.bpo.2-amd64), the first mount (with the "errors=remount-ro" option) succeed. And, of course, strace told me that singularity is using the "errors=remount-ro" option... For now, I'm downgrading my kernel and using 5.3.0-0.bpo.2-amd64 as a workaround. Regards, Vincent PS: see https://github.com/sylabs/singularity/issues/4801 for the issue in singularity where it will be fixed (errors=remount-ro removed). But as I'm still using singularity from strech-backports, (singularity-container is not in buster and, in any case, I need to stick to 2.X version for singularity due to the use of datacenters where 3.X images are not yet supported) -- Package-specific info: ** Version: Linux version 5.4.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.4.8-1~bpo10+1 (2020-01-07) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-0.bpo.2-amd64 root=/dev/mapper/ge83982--vm1-root ro apparmor=0 quiet ** Not tainted ** Kernel log: [2.993838] sd 0:0:0:2: Power-on or device reset occurred [2.993863] usb 1-1: new high-speed USB device number 2 using ehci-pci [2.993864] sd 0:0:0:1: Power-on or device reset occurred [2.995633] sd 0:0:0:2: [sdb] 2147483648 512-byte logical blocks: (1.10 TB/1.00 TiB) [2.995634] sd 0:0:0:1: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB) [2.995746] sd 0:0:0:1: [sda] Write Protect is off [2.995749] sd 0:0:0:1: [sda] Mode Sense: 63 00 00 08 [2.995752] sd 0:0:0:2: [sdb] Write Protect is off [2.995755] sd 0:0:0:2: [sdb] Mode Sense: 63 00 00 08 [2.995879] sd 0:0:0:1: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [2.995884] sd 0:0:0:2: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [2.999071] sr 0:0:0:0: Power-on or device reset occurred [2.999282] sr 0:0:0:0: [sr0] scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray [2.999284] cdrom: Uniform CD-ROM driver Revision: 3.20 [3.031252] sr 0:0:0:0: Attached scsi CD-ROM sr0 [3.067516] sda: sda1 sda2 sda3 [3.070413] sd 0:0:0:1: [sda] Attached SCSI disk [3.083294] sdb: sdb1 sdb2 [3.086273] sd 0:0:0:2: [sdb] Attached SCSI disk [3.156216] usb 1-1: New USB device found, idVendor=0627, idProduct=0001, bcdDevice= 0.00 [3.156219] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=5 [3.156221] usb 1-1: Product: QEMU USB Tablet [3.156223] usb 1-1: Manufacturer: QEMU [3.156225] usb 1-1: SerialNumber: 42 [3.170058] hidraw: raw HID events driver (C) Jiri Kosina [3.181006] usbcore: registered new interface driver usbhid [3.181006] usbhid: USB HID core driver [3.183898] input: QEMU QEMU USB Tablet as /devices/pci:00/:00:1d.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4 [3.184398] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-:00:1d.7-1/input0 [3.335960] 9pnet: Installing 9P2000 support [3.364289] random: lvm: uninitialized urandom read (4 bytes read) [3.412111] device-mapper: uevent: version 1.0.3 [3.412335] device-mapper: ioctl: 4.41.0-ioctl (2019-09-16) initialised: dm-de...@redhat.com [3.414744] random: lvm: uninitialized urandom read (2 bytes read) [3.490968] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 [3.803171] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [4.031278] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [4.789972] pcieport :00:02.6: pciehp: Failed to check link status [4.801959] pcieport :00:02.3: pciehp: Failed to check link status [5.048843] systemd[1]: Inserted module 'autofs4' [5.154338] random: crng init done [5.229945] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT
Bug#950456: lios: Please package the new upstream version (2.7.2)
Source: lios Version: 2.7-4 Dear lios maintainer, A new version of lios is now available: https://github.com/Nalin-x-Linux/lios-3/releases (which can be found through the homepage https://sourceforge.net/projects/lios/ ) . Please consider packaging it. Thanks! -- Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#950454: msgpack-c: please make the build reproducible
Source: msgpack-c Version: 3.0.1-3 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0] we noticed that msgpack-c could not be built reproducibly. This because it embedded absolute filenames in the Doxygen documentation. Patch attached that disables this. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/reproducible-build.patch 2020-02-01 14:27:13.953251913 +0100 @@ -0,0 +1,15 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2020-02-01 + +--- msgpack-c-3.0.1.orig/Doxyfile msgpack-c-3.0.1/Doxyfile +@@ -105,7 +105,7 @@ INLINE_INHERITED_MEMB = NO + # path before files name in the file list and in the header files. If set + # to NO the shortest path that makes the file name unique will be used. + +-FULL_PATH_NAMES= YES ++FULL_PATH_NAMES= NO + + # If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag + # can be used to strip a user-defined part of the path. Stripping is --- a/debian/patches/series 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/series 2020-02-01 14:27:13.233198185 +0100 @@ -0,0 +1 @@ +reproducible-build.patch
Bug#950455: override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS should not be emitted for compat level >= 13
Source: lintian Version: 2.48.0 Severity: normal […] * In compat 13, the dh command sequencer will skip any hook or override target for dh_auto_test, dh_dwz, and dh_strip if nocheck and nostrip are present in DEB_BUILD_OPTIONS. This avoids a papercut where overriding the commands often breaks the nocheck / nostrip functionality (unless you remember to inject the correct makefile runes). […] Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#950453: Mark debhelper compatibility level 9 as deprecated
Source: lintian Version: 2.48.0 Severity: normal […] * Compatibility level 9 is hereby officially deprecated and will trigger deprecation warnings soon. We recommend people migrate their packages to compat 12 or 10 depending on whether oldstable support is needed. Please note that compat 11 is actively discouraged in some cases. (see the section above). […] Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#938078: python-pymzml: diff for NMU version 0.7.6-dfsg-5.2
Control: tags 938078 + pending Dear maintainer, I've prepared an NMU for python-pymzml (versioned as 0.7.6-dfsg-5.2) and uploaded it to DELAYED/10. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru python-pymzml-0.7.6-dfsg/debian/changelog python-pymzml-0.7.6-dfsg/debian/changelog --- python-pymzml-0.7.6-dfsg/debian/changelog 2019-10-08 04:27:22.0 +0300 +++ python-pymzml-0.7.6-dfsg/debian/changelog 2020-02-02 00:05:47.0 +0200 @@ -1,3 +1,10 @@ +python-pymzml (0.7.6-dfsg-5.2) unstable; urgency=medium + + * Non-maintainer upload. + * Use python3-sphinx instead of python-sphinx. (Closes: #938078) + + -- Adrian Bunk Sun, 02 Feb 2020 00:05:47 +0200 + python-pymzml (0.7.6-dfsg-5.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru python-pymzml-0.7.6-dfsg/debian/control python-pymzml-0.7.6-dfsg/debian/control --- python-pymzml-0.7.6-dfsg/debian/control 2019-10-08 04:21:46.0 +0300 +++ python-pymzml-0.7.6-dfsg/debian/control 2020-02-02 00:05:47.0 +0200 @@ -17,7 +17,7 @@ texlive-font-utils, ghostscript, texlive-fonts-recommended, - python-sphinx (>= 1.1.3) + python3-sphinx (>= 1.1.3) X-Python-Version: >= 2.6 X-Python3-Version: >= 3.2 Standards-Version: 4.0.1
Bug#950452: getlive: Is this program still working at all?
Package: getlive Severity: grave https://bugs.launchpad.net/ubuntu/+source/getlive/+bug/1654811 https://sourceforge.net/p/getlive/news/2014/05/the-end-of-getlive---stay-tuned/ After more than 7 years being able of implementing change-after-change on hotmail and hotmail live, I need to give up on the latest changes. There's no way I can reasonably patch GetLive further to fetch mail. So I guess that's the end of GetLive.
Bug#948940: kaccounts-providers FTBFS fixed upstream
Control: forwarded -1 https://cgit.kde.org/kaccounts-providers.git/commit/?id=fd6b3ebf Control: tags -1 patch fixed-upstream This was caused by the newer version of Qt and builds with the patch. signature.asc Description: This is a digitally signed message part.
Bug#949236: ktp-common-internals FTBFS fixed upstream
Control: forwarded -1 https://phabricator.kde.org/D25269 Control: tags -1 fixed-upstream patch Control: reassign 949238 src:ktp-common-internals Control: reassign 949239 src:ktp-common-internals Control: forcemerge -1 949238 949239 Control: affects -1 + src:ktp-text-ui Control: affects -1 + src:ktp-contact-runner It seems that telepathy-qt 0.9.8 broke several packages and is the cause of #949236–949240. Fixing ktp-common-internals #949236 allows the latter two (ktp-text-ui and ktp-contact-runner) to build. I plan to prepare a merge request in the coming days. signature.asc Description: This is a digitally signed message part.
Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1
On Wed, Jan 22, 2020 at 10:23:04AM +0200, Adrian Bunk wrote: > On Tue, Dec 24, 2019 at 10:18:37PM -0500, Sandro Tosi wrote: > > On Sun, Dec 22, 2019 at 4:22 PM Dmitry Shachnev wrote: > >... > > > Recently your script bumped many Python 2 removal bugs to RC, with the > > > intention to accelerate porting those packages to Python 3 (or getting > > > them > > > removed). Maybe better to wait a couple of months and then just upload new > > > Sphinx and break its Python 2 reverse build-dependencies? > > > > only 49 of those 100 blocked packages are currently RC, so it will > > take quite more time i suspect; also some of those packages are sphinx > > extensions, that will have to go at the same time as sphinx maybe? > >... > > Complete list of packages that currently still build depend on > python-sphinx in testing is below. Annotated current list below. cu Adrian # python-sphinx compass-susy-plugin: python-sphinx (fixed in delayed/10) flufl.testing: python-sphinx (fixed in unstable) gearmand: python-sphinx (fixed in delayed/10) ghc: python-sphinx grpc: python-sphinx (fixed in experimental) krb5: python-sphinx llvm-toolchain-6.0: python-sphinx (RM bug exists) llvm-toolchain-7: python-sphinx (RM bug exists) mydumper: python-sphinx nevow: python-sphinx nose: python-sphinx ns3: python-sphinx (fixed in unstable) pam-python: python-sphinx (fixed in unstable) panoramisk: python-sphinx (fixed in unstable) parsley: python-sphinx pycollada: python-sphinx (fixed in unstable) pycurl: python-sphinx pygame: python-sphinx (fixed in unstable) pylibmc: python-sphinx pymongo: python-sphinx (fixed in unstable) pypy: python-sphinx pypy3: python-sphinx python-concurrent.futures: python-sphinx python-future: python-sphinx python-gevent: python-sphinx python-greenlet: python-sphinx python-pathlib: python-sphinx python-pymzml: python-sphinx (fixed in delayed/10) rdflib: python-sphinx reclass: python-sphinx routes: python-sphinx (fixed in unstable) sphinx-rtd-theme: python-sphinx (removable soon, see below) xapian-bindings: python-sphinx # python-sphinx-rtd-theme compass-susy-plugin: python-sphinx-rtd-theme (fixed in delayed/10) grpc: python-sphinx-rtd-theme (fixed in experimental) python-attrs: python-sphinx-rtd-theme (see #950449) python-cryptography: python-sphinx-rtd-theme (see #950448)
Bug#950451: RFS: pygresql/1:5.1-1 [QA] -- PostgreSQL module for Python3
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pygresql" * Package name: pygresql Version : 1:5.1-1 Upstream Author : PyGreSQL team pygre...@vex.net * URL : http://www.pygresql.org/index.html * License : PostgreSQL * Vcs : https://salsa.debian.org/debian/pygresql Section : python It builds those binary packages: python3-pygresql - PostgreSQL module for Python3 python-pygresql-doc - Python Pygresql (common documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pygresql Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pygresql/pygresql_5.1-1.dsc Changes since the last upload: * QA upload. * New upstream version 5.1 * Update d/watch, now points to PyPi * Update Standards-Version to 4.5.0 * Add d/source/lintian-overrides * Update d/copyright, remove files entries that is removed upstream. * Change doc package from *.rst.txt to *.html files - Add sphinxdoc:Depends for doc package in d/control - Add d/python-pygresql-doc.doc-base * Remove unneeded build-dependencies * Add Rules-Requires-Root: no * Add salsa CI Regards,
Bug#950330: libvncclient1: Serious artifacts after upgrading to 0.9.12
Hi Cesare, On Sa 01 Feb 2020 18:09:34 CET, Cesare Leonardi wrote: On 01/02/20 17:21, Mike Gabriel wrote: can you please test your issue using http://packages.sunweavers.net/debian/pool/main/libv/libvncserver/libvncclient1_0.9.12+dfsg-8~test1_amd64.deb Hello Mike, your package seems to fix the issue. I've tried two connection: (1) TightVNC 2.8.5 (Win7 64 bit) (2) TightVNC 2.8.? (Win7 32 bit) With both I've set Remmina connection to 16 bpp. Also with (1) I've also tried all quality values (poor, medium, good, best) and also 8 bpp and 32 bpp. In all cases, everything looks good. Unfortunately I have no VNC servers to test other than TightVNC 2.8.x under Win7/Win10. Thank you very much. Cesare. Thanks for testing. Your successful tests are indication enough for me to get this patch into Debian. Just uploaded. Thanks! Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpDNsBJq52VA.pgp Description: Digitale PGP-Signatur
Bug#947936: chrony: Does (still) not start properly on boot on buster
On Sat, Feb 01, 2020 at 10:46:24PM +0100, Michael Biebl wrote: > > Would it make sense to ship systemd-timesyncd disabled by default in > > buster and add a README to enable it only if the user really decides > > to enable it? (Maybe also documenting this in the release notes). > > I think this would break more setups then it fixes. > The default behaviour of systemd-timesyncd has been since two releases > to be enabled by default. We can't easily change that. > > > That would be the most simple solution for stable that I can think, > > as it would reduce the number of packages to change to just one. > > Unfortunately I think that disabling systemd-timesyncd by default is one > of the most intrusive changes. After all, systemd is installed by > default (and thus systemd-timesyncd enabled by default). I fear this is > a no-go. Ok, in such case, the only other solution which comes to mind is what you proposed in the message I was replying to, i.e. this: > I guess at this point it is best to ask chrony, ntp, openntpd, ntpsec > and virtualbox [1] to drop the Conflicts= line again. If I'm not mistaken, this is how it was done in stretch, so the fix would be as "conservative" as it can be. I would not worry about the number of packages that need to be changed being "high". If you as systemd maintainer believe that this is the best solution for buster, I would hope that the other maintainers agree. Thanks.
Bug#935304: libpam-systemd: Please relax Depends: systemd-sysv
On Fri, 31 Jan 2020 02:36:29 -0500 Sam Hartman wrote: > > "Michael" == Michael Biebl writes: > > Michael> Tbh, I'm not sure what kind of answer you expect from me. > > Michael> I guess I already provided my feedback here and mentioned > Michael> what kind of solution I prefer. I can repeat this in this > Michael> bug report, but I'm not sure if this is helpful. > > Are you referring to the idea of using libsystemd0 and having elogind > use the same dbus interface so be able to reuse libsystemd0? > > If so, Mark explained why that didn't work in #940034. > I think when you originally raised the concern Mark may not have > entirely understood what you were thinking about. But at least if I > characterized things correctly above, Mark did fully explore that option > in #940034. > > A brief summary is that libelogind0 does basically use the same dbus > interface as libsystemd0. However, libsystemd0's interface requirements > extends beyond dbus; there are a number of functions that for example > are implemented purely in terms of cgroup membership tests. Elogind's > interface diverges among other reasons because elogind has a different > cgroup hierarchy. If this is unfixable in elogind, I only see two alternatives: a/ elogind is not suitable for a binary distro like Debian and should be removed b/ you need a different way to switch over. Reboot into an environment for which you have control over, then uninstall systemd/systemd-sysv without triggering the removal of most packages. I acknowledge that this is inconvenient, but such a switch-over should not happen often. Michael signature.asc Description: OpenPGP digital signature
Bug#947936: chrony: Does (still) not start properly on boot on buster
On 2020-02-01T22:46+0100, Michael Biebl wrote:
Am 01.02.20 um 22:37 schrieb Santiago Vila:
On Sun, Jan 12, 2020 at 08:41:19PM +0100, Michael Biebl wrote:
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?
Hi. I definitely think this should be fixed in stable, in whatever way
it's considered best for stable.
The last thing a system admin would expect from Debian stable is that
the clock is off by several minutes in a system where a time-keeping
package like ntp or chrony is present. This was completely unexpected
for me. (In fact, I would have reported this as serious but I prefer
to concentrate on finding a good fix).
Regarding the proper fix: Anything which makes chrony and ntp work
again (without surprises) would do. I agree that the less intrusive
the change, the better.
In the Debian 10 instances at GCE where I found this I just did this:
systemctl disable systemd-timesyncd
Would it make sense to ship systemd-timesyncd disabled by default in
buster and add a README to enable it only if the user really decides
to enable it? (Maybe also documenting this in the release notes).
I think this would break more setups then it fixes.
The default behaviour of systemd-timesyncd has been since two releases
to be enabled by default. We can't easily change that.
That would be the most simple solution for stable that I can think,
as it would reduce the number of packages to change to just one.
Unfortunately I think that disabling systemd-timesyncd by default is one
of the most intrusive changes. After all, systemd is installed by
default (and thus systemd-timesyncd enabled by default). I fear this is
a no-go.
I wholeheartedly agree with you, Michael. To me having an {S}NTP
implementation by default is a must. Disabling systemd-timesyncd at this
point would probably seen as a serious regression.
Despite what Balint thinks, I think that we, maintainers of alternative
NTP implementations, should just stop conflicting with
systemd-timesyncd.service on stable and oldstable. Regarding Bulleye,
that should not be an issue if Balint and Michael’s work is pushed in
the archive.
signature.asc
Description: PGP signature
Bug#943094: gearmand: diff for NMU version 1.1.18+ds-3.1
Control: tags 943094 + patch
Control: tags 943094 + pending
Dear maintainer,
I've prepared an NMU for gearmand (versioned as 1.1.18+ds-3.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru gearmand-1.1.18+ds/debian/changelog gearmand-1.1.18+ds/debian/changelog
--- gearmand-1.1.18+ds/debian/changelog 2018-08-23 18:21:58.0 +0300
+++ gearmand-1.1.18+ds/debian/changelog 2020-02-01 23:42:48.0 +0200
@@ -1,3 +1,11 @@
+gearmand (1.1.18+ds-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Use python-sphinx instead of python-sphinx. (Closes: #943094)
+ * libgearman-doc: Add the missing dependency on ${sphinxdoc:Depends}.
+
+ -- Adrian Bunk Sat, 01 Feb 2020 23:42:48 +0200
+
gearmand (1.1.18+ds-3) unstable; urgency=medium
* Add "sharness" to debian/tests/control, really fixing #906629
diff -Nru gearmand-1.1.18+ds/debian/control gearmand-1.1.18+ds/debian/control
--- gearmand-1.1.18+ds/debian/control 2018-08-23 18:21:58.0 +0300
+++ gearmand-1.1.18+ds/debian/control 2020-02-01 23:42:48.0 +0200
@@ -27,7 +27,7 @@
memcached,
pkg-config,
procps,
- python-sphinx,
+ python3-sphinx,
sharness,
systemtap-sdt-dev [amd64 armel armhf i386 ia64 powerpc s390],
uuid-dev
@@ -65,7 +65,7 @@
Package: libgearman-doc
Architecture: all
Section: doc
-Depends: ${misc:Depends}
+Depends: ${misc:Depends}, ${sphinxdoc:Depends}
Description: API Documentation for the Gearman Library
Gearman is a system to farm out work to other machines, dispatching function
calls to machines that are better suited to do work, to do work in parallel,
Bug#947936: chrony: Does (still) not start properly on boot on buster
Am 01.02.20 um 22:37 schrieb Santiago Vila: > On Sun, Jan 12, 2020 at 08:41:19PM +0100, Michael Biebl wrote: > >> 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? > > Hi. I definitely think this should be fixed in stable, in whatever way > it's considered best for stable. > > The last thing a system admin would expect from Debian stable is that > the clock is off by several minutes in a system where a time-keeping > package like ntp or chrony is present. This was completely unexpected > for me. (In fact, I would have reported this as serious but I prefer > to concentrate on finding a good fix). > > Regarding the proper fix: Anything which makes chrony and ntp work > again (without surprises) would do. I agree that the less intrusive > the change, the better. > > In the Debian 10 instances at GCE where I found this I just did this: > > systemctl disable systemd-timesyncd > > Would it make sense to ship systemd-timesyncd disabled by default in > buster and add a README to enable it only if the user really decides > to enable it? (Maybe also documenting this in the release notes). I think this would break more setups then it fixes. The default behaviour of systemd-timesyncd has been since two releases to be enabled by default. We can't easily change that. > That would be the most simple solution for stable that I can think, > as it would reduce the number of packages to change to just one. Unfortunately I think that disabling systemd-timesyncd by default is one of the most intrusive changes. After all, systemd is installed by default (and thus systemd-timesyncd enabled by default). I fear this is a no-go. signature.asc Description: OpenPGP digital signature
Bug#950450: libm4rie-0.0.20200125: Depends on libm4ri-0.0.20200115
Package: libm4rie-0.0.20200125 Version: 20200125-1 Severity: serious Hi, seems that something went wrong with the binary upload of libm4rie on amd64. On this architecture libm4rie-0.0.20200125 depends on libm4ri-0.0.20200115 which makes it uninstallable. This might be fixable with a source-only-upload. Best, Tobias
Bug#947936: chrony: Does (still) not start properly on boot on buster
On Sun, Jan 12, 2020 at 08:41:19PM +0100, Michael Biebl wrote: > 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? Hi. I definitely think this should be fixed in stable, in whatever way it's considered best for stable. The last thing a system admin would expect from Debian stable is that the clock is off by several minutes in a system where a time-keeping package like ntp or chrony is present. This was completely unexpected for me. (In fact, I would have reported this as serious but I prefer to concentrate on finding a good fix). Regarding the proper fix: Anything which makes chrony and ntp work again (without surprises) would do. I agree that the less intrusive the change, the better. In the Debian 10 instances at GCE where I found this I just did this: systemctl disable systemd-timesyncd Would it make sense to ship systemd-timesyncd disabled by default in buster and add a README to enable it only if the user really decides to enable it? (Maybe also documenting this in the release notes). That would be the most simple solution for stable that I can think, as it would reduce the number of packages to change to just one. Thanks.
Bug#950287: autofs: automount expriing unmounts target filesystem
On Sat, Feb 01, 2020 at 07:41:03AM +0800, Ian Kent wrote: > > decided that nobody should use symlinks as bind mounts are the > > future(tm). > > >From an upstream POV it was more neglect (on my part) of the > symlink code in favour of bind mounts. Not sure why you write this, but it's clearly not true: Date: Tue, 29 May 2001 14:00:42 -0700 [...] I don't want to perpetuate the symlink thing because it is a terrible hack in the kernel part of the code, and thus will be removed in autofs v5. -hpa (I hope he forgives me to quote a private mail, but the fact is documented in debian bug #128171). That was probably a bit before your time, but the last time I reported problems with symlinks to upstream I was told (in a long thread) that it is a hack and will not be supported. And the result was that the debian maintainer locally applied a patch (in 2006) to make symlinks configurable, for which I was super-thankful. (Note that there are two sides to this: symlinks for local nfs mounts, and symlinks for bind mounts, which are not the same, and which confused me for quite a while). > But the autofs amd format map support needs them to work properly > so quite a bit of effort went into making them work as best as I > could. Yes, I am very fond of this change in policy, thanks a lot - the effect is that I can consider autofs again for new deployments, rather than having had to give up on it :) I also am very fond of amd map support, although documentation, of course, is sorely lacking. In any case, since we all seems to agree on the bug part, I think this part of the disucssion (who stated what policy when) should stay off the debian bts :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#938337: rdiff-backup: Python2 removal in sid/bullseye
Hello! Yes, we are working on it. I am both upstream and Debian maintainer. I need to fix some upstream bugs first and will import to Debian a version that makes sense to introduce in Debian unstable.
Bug#928086: closed by Emfox Zhou (close the bug)
On Sat, Feb 01, 2020 at 07:33:11AM +, Debian Bug Tracking System wrote: > Subject: close the bug > > you can now custom your temp dir via preference. Thats cool, but that doesn't affect the bug in any way (which is about a wrong default) - unpacking big archives into /tmp (which is a tmpfs on standard debian) is wrong even if this can somehow be changed - kepe in mind that this can easily crash machines. In any case, I cannot force you to fix this bug, so if you want to keep mcomix buggy, I will not press this issue further. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#950449: python-attrs: Stale build dependency on python-sphinx-rtd-theme
Source: python-attrs Version: 18.2.0-1 Severity: normal Control: block 938545 by -1 Control: unblock 938545 by 937587 python-attrs (18.2.0-1) unstable; urgency=medium ... * Use 'python3 -m sphinx' instead of sphinx-build for building docs Build-Depends: python-sphinx-rtd-theme, python3-sphinx, The build dependency on python-sphinx-rtd-theme seems to be either unnecessary or should be updated to python3-sphinx-rtd-theme.
Bug#942922: compass-susy-plugin: diff for NMU version 2.2.12-1.1
Control: tags 942922 + patch Control: tags 942922 + pending Dear maintainer, I've prepared an NMU for compass-susy-plugin (versioned as 2.2.12-1.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru compass-susy-plugin-2.2.12/debian/changelog compass-susy-plugin-2.2.12/debian/changelog --- compass-susy-plugin-2.2.12/debian/changelog 2016-12-14 13:31:14.0 +0200 +++ compass-susy-plugin-2.2.12/debian/changelog 2020-02-01 23:16:02.0 +0200 @@ -1,3 +1,10 @@ +compass-susy-plugin (2.2.12-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Use python3-sphinx instead of python-sphinx. (Closes: #942922) + + -- Adrian Bunk Sat, 01 Feb 2020 23:16:02 +0200 + compass-susy-plugin (2.2.12-1) unstable; urgency=medium [ upstream ] diff -Nru compass-susy-plugin-2.2.12/debian/control compass-susy-plugin-2.2.12/debian/control --- compass-susy-plugin-2.2.12/debian/control 2016-12-14 13:21:42.0 +0200 +++ compass-susy-plugin-2.2.12/debian/control 2020-02-01 23:16:02.0 +0200 @@ -8,8 +8,8 @@ debhelper, dh-buildinfo, gem2deb, - python-sphinx, - python-sphinx-rtd-theme, + python3-sphinx, + python3-sphinx-rtd-theme, ruby | ruby-interpreter, ruby-sass (>= 3.4) Standards-Version: 3.9.8 diff -Nru compass-susy-plugin-2.2.12/debian/rules compass-susy-plugin-2.2.12/debian/rules --- compass-susy-plugin-2.2.12/debian/rules 2016-12-14 13:28:08.0 +0200 +++ compass-susy-plugin-2.2.12/debian/rules 2020-02-01 23:16:02.0 +0200 @@ -28,7 +28,7 @@ DEB_UPSTREAM_TARBALL_SRCDIR = susy-$(DEB_UPSTREAM_TARBALL_VERSION) # needed during build -bdeps = gem2deb, python-sphinx, python-sphinx-rtd-theme +bdeps = gem2deb, python3-sphinx, python3-sphinx-rtd-theme # needed during build and at runtime deps = ruby | ruby-interpreter
Bug#938337: rdiff-backup: Python2 removal in sid/bullseye
Control: tags -1 +fixed-upstream On Fri, 30 Aug 2019 07:49:53 + Matthias Klose wrote: > Package: src:rdiff-backup > Version: 1.3.3-1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal it appears just yesterday upstream released the second beta for 2.0.0, https://github.com/rdiff-backup/rdiff-backup/releases, which supports python3. maybe it's time to consider preparing it for Debian and upload it to unstable? it's one of the only 2 reverse dependencies for pylibacl and pyxattr, so moving this package over to python3 will help with those packages too. Thanks for considering
Bug#950188: gcc-snapshot: FTBFS on hurd-i386
reassign 950188 gcc-10-10-20200129
thanks!
>
> The patches have now been committed upstream by Ian.
>
> > They don't apply to gcc-10 in experimental. Close this issue?
>
> They might not apply to gcc-10, but they apply fine to 1:20200124-1.
> I'm still confused why you have both gcc-10 and gcc-snapshot?
They do apply to 10_10-20200129-1 as well as 1:20200124-1. I'm
attaching them now for completeness, but they should not be needed
anymore. The upstream bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468
was closed by Ian on January 30.
I have now test-built gcc-10 as well as gcc-snapshot with successful
outcome.
> > > Or is gcc-10 release upstream already (I don't think so)?
> > they are the same, there's some overlap. it's easier to provide
> > current trunk in just a single package during development.
Thanks!
--- a/src/libgo/go/runtime/nbpipe_pipe2.go 2020-01-23 21:11:38.0 +0100
+++ b/src/libgo/go/runtime/nbpipe_pipe2.go 2020-01-27 17:31:31.0 +0100
@@ -2,7 +2,7 @@
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
-// +build freebsd linux netbsd openbsd solaris
+// +build freebsd hurd linux netbsd openbsd solaris
package runtime
--- a/src/libgo/go/runtime/netpoll_hurd.go 2020-01-18 16:14:17.0 +0100
+++ b/src/libgo/go/runtime/netpoll_hurd.go 2020-01-27 16:23:00.0 +0100
@@ -85,6 +85,10 @@
return uintptr(rdwake<<16 | wrwake)
}
+func netpollIsPollDescriptor(fd uintptr) bool {
+ return fd == uintptr(rdwake) || fd == uintptr(wrwake)
+}
+
// netpollwakeup writes on wrwake to wakeup poll before any changes.
func netpollwakeup() {
if pendingUpdates == 0 {
@@ -158,17 +162,32 @@
unlock()
}
-// polls for ready network connections
-// returns list of goroutines that become runnable
+// netpollBreak interrupts an epollwait.
+func netpollBreak() {
+ netpollwakeup()
+}
+
+// netpoll checks for ready network connections.
+// Returns list of goroutines that become runnable.
+// delay < 0: blocks indefinitely
+// delay == 0: does not block, just polls
+// delay > 0: block for up to that many nanoseconds
//go:nowritebarrierrec
-func netpoll(block bool) gList {
- timeout := int32(0)
- if !block {
- timeout = 0
+func netpoll(delay int64) gList {
+ timeout:= int32(0)
+ if delay < 0 {
+ timeout = 0
+ } else if delay == 0 {
+ // TODO: call poll with timeout == 0
return gList{}
- }
- if pollVerbose {
- println("*** netpoll", block)
+ } else if delay < 1e6 {
+ timeout = 1
+ } else if delay < 1e15 {
+ timeout = int32(delay / 1e6)
+ } else {
+ // An arbitrary cap on how long to wait for a timer.
+ // 1e9 ms == ~11.5 days.
+ timeout = 1e9
}
retry:
lock()
@@ -176,40 +195,37 @@
pendingUpdates = 0
unlock()
- if pollVerbose {
- println("*** netpoll before poll")
- }
- n := libc_poll([0], int32(len(pfds)), timeout)
- if pollVerbose {
- println("*** netpoll after poll", n)
- }
+ n := libc_poll([0], int32(len(pfds)), timeout)
if n < 0 {
e := errno()
if e != _EINTR {
println("errno=", e, " len(pfds)=", len(pfds))
throw("poll failed")
}
- if pollVerbose {
- println("*** poll failed")
- }
unlock()
+ // If a timed sleep was interrupted, just return to
+ // recalculate how long we should sleep now.
+ if timeout > 0 {
+ return gList{}
+ }
goto retry
}
// Check if some descriptors need to be changed
if n != 0 && pfds[0].revents&(_POLLIN|_POLLHUP|_POLLERR) != 0 {
- var b [1]byte
- for read(rdwake, unsafe.Pointer([0]), 1) == 1 {
- if pollVerbose {
-println("*** read 1 byte from pipe")
+ if delay != 0 {
+ // A netpollwakeup could be picked up by a
+ // non-blocking poll. Only clear the wakeup
+ // if blocking.
+ var b [1]byte
+ for read(rdwake, unsafe.Pointer([0]), 1) == 1 {
}
}
- // Do not look at the other fds in this case as the mode may have changed
- // XXX only additions of flags are made, so maybe it is ok
- unlock()
- goto retry
+ // Still look at the other fds even if the mode may have
+ // changed, as netpollBreak might have been called.
+ n--
}
var toRun gList
- for i := 0; i < len(pfds) && n > 0; i++ {
+ for i := 1; i < len(pfds) && n > 0; i++ {
pfd := [i]
var mode int32
@@ -222,19 +238,14 @@
pfd.events &= ^_POLLOUT
}
if mode != 0 {
- if pollVerbose {
-println("*** netpollready i=", i, "revents=", pfd.revents, "events=", pfd.events, "pd=", pds[i])
+ pds[i].everr = false
+ if pfd.revents == _POLLERR {
+pds[i].everr = true
}
netpollready(, pds[i], mode)
n--
}
}
unlock()
- if block && toRun.empty() {
- goto retry
- }
- if pollVerbose {
- println("*** netpoll returning end")
- }
return toRun
}
--- a/src/libgo/go/syscall/sockcmsg_unix_other.go 2020-01-23 21:11:38.0 +0100
+++ b/src/libgo/go/syscall/sockcmsg_unix_other.go 2020-01-27 16:49:55.0 +0100
@@ -2,7 +2,7 @@
// Use of this source code is governed by a BSD-style
// license that can be found in
Bug#950448: python-cryptography: Stale build dependency on python-sphinx-rtd-theme
Source: python-cryptography Version: 2.6.1-2 Severity: normal Control: block 938545 by -1 Control: unblock 938545 by 937672 python-cryptography (2.6.1-2) unstable; urgency=medium ... * Use 'python3 -m sphinx' instead of sphinx-build for building docs ... -- Tristan Seligmann Fri, 08 Mar 2019 20:56:58 +0200 Build-Depends: python-sphinx-rtd-theme , python3-sphinx , The build dependency on python-sphinx-rtd-theme seems to be either unnecessary or should be updated to python3-sphinx-rtd-theme.
Bug#950249: Patch submitted upstream
This bug is due to a gap in Python 3 support for pagekite. I submitted upstream patches to fix the problem. New or patched versions of socksipychain and pagekite will be needed. https://github.com/pagekite/PySocksipyChain/pull/10 https://github.com/pagekite/PyPagekite/pull/75 Thanks, -- Sunil signature.asc Description: OpenPGP digital signature
Bug#604565: debhelper: Please provide a way to get a list of packages without DH_INTERNAL_OPTIONS complicating things
Control: tags -1 wontfix On Mon, 22 Nov 2010 23:53:31 + Roger Leigh wrote: > On Mon, Nov 22, 2010 at 07:00:38PM -0400, Joey Hess wrote: > > Roger Leigh wrote: > > > However, if I did want a complete list of all packages, all arch or > > > all indep packages irrespective of what is currently in > > > DH_INTERNAL_OPTIONS, it would be nice to have a --force|-f option > > > or the like to do this so I don't need to use debhelper internals. > > > > I'm not clear on what you'd expect to find in that list. Eg, should it > > contain packages that are only built on other architectures? > > That's a good question. For the uses I was thinking of, I wanted to > compare a package (or set of packages) with the list of packages > being built on the current architecture to see if there was an > intersection between the two sets. > > This would be the same output you would get from running > dh_listpackages in the source tree without involving dh or > DH_INTERNAL_OPTIONS. > > > My initial use was to use it like in the example shown in my initial > mail, to find out if we are building arch or indep packages: > > target: > ifneq (,$(strip $(foreach V,$(shell dh_listpackages),$(filter $(V),$(shell > DH_INTERNAL_OPTIONS= dh_listpackages -a) > @echo Arch > endif > ifneq (,$(strip $(foreach V,$(shell dh_listpackages),$(filter $(V),$(shell > DH_INTERNAL_OPTIONS= dh_listpackages -i) > @echo Indep > endif > > But there's obviously a simpler solution, as I showed. > > There are less complicated uses for the information during a package > build, such as: > > - checking if a package is to be built (irrespective of how invoked > by dh) > - and more complex conditionals where the packages to check are in > both the arch and indep lists and you need the full list > > > Regards, > Roger > > -- > .''`. Roger Leigh > : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ > `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ >`-GPG Public Key: 0x25BFB848 Please GPG sign your mail. Hi, I am closing this bug on the assumption that the -arch/-indep override/hook targets and present behaviour seem to mostly satisfy the use-case. If there is a concrete use-case where the current behaviour/methods are insufficient and where said use-case is likely to be useful for many packages, please reopen this bug with a reference to that use-case. Thanks, ~Niels
Bug#950447: Document that persistent journal is now enabled in systemd
Package: release-notes Severity: normal See https://lists.debian.org/debian-devel/2020/02/msg4.html We should document in the release notes, that systemd has enabled persistent logging in journald. Personally, I would prefer to do that on upgrades and new installations and document that accordingly (and that is what the systemd package currently does). The discussions on debian-devel are still ongoing, so this might still change though. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#947688: systemd-networkd: Python socket.getfqdn() not working properly when resolv.conf lacks "domain" key
Am 01.02.20 um 07:28 schrieb Michael Biebl: Did you find time to reproduce the issue with v244? No, sorry. And I won't for at least another week. Bye... Dirk -- Dirk Heinrichs GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015 Sichere Internetkommunikation: http://www.retroshare.org Privacy Handbuch: https://www.privacy-handbuch.de
Bug#924087:
חזור אליי לפרטים בברכה. עורך דין מנשה אטוה. שירותי ייעוץ מנהל דיני עסקים, כתובת: Rehoboth Place, N ° 1 צפון טוגו. P.O.Box: CT 924, [image: image.png] קנטונים
Bug#923387: [Pkg-utopia-maintainers] Bug#923387: udisks2: Please support new logind virtual packages
Am 31.01.20 um 05:40 schrieb Benda Xu: > Hi Michael, > > What is the status of this bug? > > > elogin now provides sd_uid_is_on_seat: > > $ nm -D /lib/elogind/libelogind-shared-241.3.so | grep sd_uid_is_on_seat > > 000b5b90 T sd_uid_is_on_seat > > > Please express your concern. The libpam-systemd dependency was added in 2.1.3-2. Here's the relevant changelog entry > udisks2 (2.1.3-2) unstable; urgency=medium ... > * debian/control: Add dependecy against libpam-systemd, we need to be sure a > logind session is registered for seat detection and system inhibitors > > -- Laurent Bigonville Sat, 31 May 2014 22:40:10 +0200 The seat detection is acquired via libsystemd, not the D-Bus interface afaics. The virtual package logind only provides guarantees regarding the D-Bus interface. From /usr/share/doc/debian-policy/virtual-package-names-list.yaml.gz - name: logind description: an org.freedesktop.login1 D-Bus API implementation (versioned) Can you provide more information if the C-API of logind is fully implemented in elogind? Should debian-policy be updated then? That is my concern number one. Second, I don't think the logind virtual package gives any guarantees regarding the systemd inhibit API. How does elogind enforce an inhibition lock? Say udisks currently executed a destructive operation operation. How does it prevent (accidental) shutdowns in this case, which would render your system broken? Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#944478: fixed in debhelper 12.8
Am 01.02.20 um 20:43 schrieb Michael Biebl: > What's your thought here? Should we transition to the name > debian/foo.tmpfiles in compat 13? It would probably be good to keep > support for debian/foo.tmpfile in compat 13 but logging a warning and > making the existentence of a debian/foo.tmpfile a hard error in compat 14? > > Or do you think the name is purely cosmetical and changing it now is > just creating busy work? If we decide to change the name, now would probably be a good time before compat 13 is officially released. I assume it's still ok to change the behaviour of compat 13 or is this already too late? Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#950444: #950444: intltool: race condition with cache files
Control: retitle 950444 intltool: race condition with cache files Oops, fix the title to something a little less FIXME. live well, vagrant signature.asc Description: PGP signature
Bug#950437: garcon: encoding of .directory files differs depending on locale
Control: tags 950437 -patch Control: block 950437 by 950444 On 2020-02-01, Vagrant Cascadian wrote: > When built with the C locale, some files differ from when built with a > UTF-8 locale, such as xfce-screensavers.directory: > > Icon=preferences-desktop-screensaver > Name=Screensavers > Name[am]=መመልከቻ·ማዳኛ ... > The attached patch works around this by exporting LC_ALL=C.UTF-8 in > debian/rules, ensuring all builds use a UTF-8 locale. On looking into the issue a little deeper and after a few more test builds, this doesn't seem to consistantly address the issue; I believe the issue is a race condition in intltool. Removing the patch tag and adding that it is blocked by the intltool bug. Sorry for the noise! live well, vagrant signature.asc Description: PGP signature
Bug#950372: Is radare2 suitable for stable Debian releases?
Hi Hilko, On Sat, Feb 01, 2020 at 12:57:27AM +0100, Hilko Bengen wrote: > * Moritz Mühlenhoff: > > >> FTR, this was as well raised back in [1]. AFAIK there was no direct > >> feedback to the question from Moritz back then. > > > > Yeah, we should at least remove radare2 from oldstable (IIRC for > > buster there's an rdep which prevents that) > > That reverse dependency is radare2-cutter which should be treated the > same as radare2, IMO. So, there would be a point release for buster and stretch very soon. If you feel there is agreement within the Debian Security Tools team on it, can any of you fill the respective removal requests for the upcoming point release? Regards, Salvatore
Bug#950445: python-couchdb: should this package be removed?
Package: python-couchdb Severity: serious Hello, i believe this package should be removed from debian: * currently py2 only in Debian, with py3 support upstream * no reverse dependencies * low popcon * deprecated upstram, python-cloudant suggested as a better replacement (https://github.com/djc/couchdb-python/blob/master/README.rst) If i dont hear a good reason to keep this package in Debian within a week, 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 Versions of packages python-couchdb depends on: ii libjs-jquery 3.3.1~dfsg-3 ii libjs-underscore 1.9.1~dfsg-1 ii python 2.7.16-1 ii python-simplejson 3.16.0-1 python-couchdb recommends no packages. Versions of packages python-couchdb suggests: pn couchdb
Bug#950326: dgit: can't import binutils 2.33.90.20200122-2
Control: clone -1 -2
Control: severity -2 normal
Control: reassign -2 git-buildpackage
Control: found -2 0.9.14
Control: fixed -2 0.8.12.2
Hi. Dear gbp maintainers:
gbp pq can fail to apply patches where the `Date:' in the patch is
mangled or broken. My test case works in stretch, but not buster:
peter green writes ("Bug#950326: dgit: can't import binutils
2.33.90.20200122-2"):
> Package: dgit
> Version: 9.9~bpo10+1
>
> When trying to import binutils 2.33.90.20200122-2 I get the following.
>
> ['dgit', 'import-dsc',
> '/build/workingrepo/pool/main/b/binutils/binutils_2.33.90.20200122-2.dsc',
> '..workingbranch']
> Dgit metadata in .dsc: NO git hash
> using existing binutils_2.33.90.20200122.orig.tar.xz
> using existing binutils_2.33.90.20200122-2.debian.tar.xz
> dpkg-source: info: extracting binutils in binutils-2.33.90.20200122
> dpkg-source: info: unpacking binutils_2.33.90.20200122.orig.tar.xz
> dpkg-source: info: unpacking binutils_2.33.90.20200122-2.debian.tar.xz
> warning: gbp pq import failed: subprocess failed with error exit status 1
> dgit: trying slow absurd-git-apply...
> gbp:error: Failed to apply
> '/build/git/b/binutils/.git/dgit/unpack/binutils-2.33.90.20200122/debian/patches/001_ld_makefile_patch.patch':
> Failed to commit tree: fatal: invalid date format: ??
> gbp:error: Couldn't apply patches
> gbp pq import failed: subprocess failed with error exit status 1
Steps to reproduce, without using dgit:
DGET_UNPACK=no dget
http://deb.debian.org/debian/pool/main/b/binutils/binutils_2.33.90.20200122-2.dsc
dpkg-source --skip-patches -x binutils_2.33.90.20200122-2.dsc
cd binutils-2.33.90.20200122/
git add -Af .
git commit -q -m import
gbp pq import
Actual results:
gbp:error: Failed to apply
'/home/ian/things/Dgit/Bugs/950326/binutils-2.33.90.20200122/debian/patches/001_ld_makefile_patch.patch':
Failed to commit tree: fatal: invalid date format: ??
Expected results: some kind of degraded operation, eg as with gbp pq
from stretch:
gbp:info: Trying to apply patches at
'8f09971b78f3a5deb13ee5b0afe7813855e2fc3a'
gbp:warning: Patch '001_ld_makefile_patch.patch' has no authorship
information, using 'Matthias Klose '
gbp:warning: Patch '002_gprof_profile_arcs.patch' has no authorship
information, using 'Matthias Klose '
[...]
gbp:info: 20 patches listed in 'debian/patches/series' imported on
'patch-queue/master'
The patch files in the binutils are quite badly mangled:
Author:
Description: Description: correct where ld scripts are installed
Author: Chris Chimelis
Upstream status: N/A
Date: ??
--- a/ld/Makefile.am
+++ b/ld/Makefile.am
Note the two Author lines as well as the mangled Date. stretch's gbp
seems to handle this by ignoring the metadata, or rather, treating it
as commit message.
I am hoping that gbp's design intent is for it to work on arbitrary
packages that dpkg-source accepts. If this is not the case then
please feel free to downgrade or even close this report against gbp.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#950444: intltool: race condition when generating FIXME
Package: intltool
Version: 0.51.0-5
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Control: affects -1 exo
Control: affects -1 garcon
A fix for a race condition was submitted upstream. The effects result in
partial or completely missing translations. The Reproducible Builds
folks have identified over twenty packages which may be affected:
https://tests.reproducible-builds.org/debian/issues/unstable/translations_missing_in_desktop_files_issue.html
The fix was submitted and merged upstream some years ago, but a new
release was never made:
https://bugs.launchpad.net/intltool/+bug/1687644
https://bazaar.launchpad.net/~intltool/intltool/trunk/revision/748
I've done several tests building "exo" and "garcon" packages on multiple
machines with varying environments, and the attached patch appears to
work.
Thanks for maintaining intltool!
live well,
vagrant
From ea5b70f1aae8115595226a9f2e23d3bb2c98bdd4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Sat, 1 Feb 2020 10:13:30 -0800
Subject: [PATCH] debian/patches: Add patch from upstream to fix race intltool
race condition end up using a partial cache, resulting in missing
translations in some cases.
---
...re-some-processes-try-to-use-a-parti.patch | 57 +++
debian/patches/series | 1 +
2 files changed, 58 insertions(+)
create mode 100644 debian/patches/0001-Avoid-a-race-where-some-processes-try-to-use-a-parti.patch
diff --git a/debian/patches/0001-Avoid-a-race-where-some-processes-try-to-use-a-parti.patch b/debian/patches/0001-Avoid-a-race-where-some-processes-try-to-use-a-parti.patch
new file mode 100644
index 000..d5998c9
--- /dev/null
+++ b/debian/patches/0001-Avoid-a-race-where-some-processes-try-to-use-a-parti.patch
@@ -0,0 +1,57 @@
+From 97c9854c9ffe34d5fb4c8e928530c9a41b8e1a35 Mon Sep 17 00:00:00 2001
+From: "Bernhard M. Wiedemann"
+Date: Thu, 18 May 2017 21:09:18 +0200
+Origin: https://bazaar.launchpad.net/~intltool/intltool/trunk/revision/748
+ https://bugs.launchpad.net/intltool/+bug/1687644
+Subject: [PATCH] Avoid a race where some processes try to use a partial cache
+ file that is still being written to. Note that we release the lock before
+ load_cache, because if we got the lock, the cache is already completely
+ written and it is OK to have multiple parallel readers
+
+Without this patch, translation files would randomly miss translations
+for some or all languages.
+
+fixes bug #1687644
+maybe also bug #986897
+---
+ intltool-merge.in | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/intltool-merge.in b/intltool-merge.in
+index 05db7cf..89923a7 100644
+--- a/intltool-merge.in
b/intltool-merge.in
+@@ -43,6 +43,7 @@ use Getopt::Long;
+ use Text::Wrap;
+ use File::Basename;
+ use Encode;
++use Fcntl qw(:flock);
+
+ my $must_end_tag = -1;
+ my $last_depth= -1;
+@@ -392,11 +393,14 @@ sub load_cache
+
+ sub get_cached_translation_database
+ {
++open(my $lockfh, ">", "$cache_file.lock") or die $!;
++flock($lockfh, LOCK_EX) or die "Could not lock '$cache_file.lock' - $!";
+ my $cache_file_age = -M $cache_file;
+ if (defined $cache_file_age)
+ {
+ if ($cache_file_age <= _newest_po_age)
+ {
++close($lockfh);
+ _cache;
+ return;
+ }
+@@ -404,6 +408,7 @@ sub get_cached_translation_database
+ }
+
+ _cache;
++close($lockfh);
+ }
+
+ sub add_translation
+--
+2.20.1
+
diff --git a/debian/patches/series b/debian/patches/series
index 4ca6c6d..7ccf586 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
perl5.26-regex-fixes.patch
+0001-Avoid-a-race-where-some-processes-try-to-use-a-parti.patch
--
2.20.1
signature.asc
Description: PGP signature
Bug#944478: fixed in debhelper 12.8
Hi Niels, I was triggered by your latest debhelper announcement. On Sun, 19 Jan 2020 10:19:22 + Niels Thykier wrote: > debhelper (12.8) unstable; urgency=medium > . >[ Niels Thykier ] ... >* dh_installtmpfiles: New command extracted from > dh_installsystem that will handle tmpfiles.d Thanks a lot for this. When we discussed splitting off the tmpfiles.d related functionality into its own helper a while back on IRC, I remember that Ansgar wanted to have debian/foo.tmpfile renamed to debian/foo.tmpfiles. I agree that he has a point here. It would make the naming more consistent. After all the mechanism is uses the term tmpfiles.d and the dh helper is now called dh_installtmpfiles. If one runs "man tmpfile", you get documentation about the tmpfile() function call. The relevant man page would be "man tmpfiles.d". What's your thought here? Should we transition to the name debian/foo.tmpfiles in compat 13? It would probably be good to keep support for debian/foo.tmpfile in compat 13 but logging a warning and making the existentence of a debian/foo.tmpfile a hard error in compat 14? Or do you think the name is purely cosmetical and changing it now is just creating busy work? CCing Ansgar here and the pkg-systemd-maintainers list, in case they want to chime in here as well. Regards, Michael P.S: This affects 79 packages, shipping 100 tmpfiles. List attached acmetool-0.0.62 bind9-9.11.14+dfsg binkd-1.1a-99 bley-2.0.0 cinder-15.0.0 conserver-8.2.4 courier-1.0.6 courier-authlib-0.69.0 custodia-0.6.0 cyrus-imapd-3.0.13 ejabberd-19.09.1 freeipa-4.8.3 fwknop-2.6.10 gitaly-1.78.0+dfsg haproxy-2.0.12 i2pd-2.29.0 inn-1.7.2q inspircd-3.4.0 iodine-0.7.0 keystone-16.0.0 knot-2.7.8 krb5-1.17 kubernetes-1.7.16+dfsg ladvd-1.1.2 lemonldap-ng-2.0.7+ds mailman-2.1.29 mailman3-3.2.2 mailman-suite-0+20180916 memcached-1.5.21 mpd-0.21.16 munge-0.5.13 munin-2.0.54 nagios-nrpe-4.0.0 neutron-15.0.0 nextepc-0.3.10+nods ngircd-25 nova-20.0.0 nrpe-ng-0.2.0 nsd-4.1.26 nullmailer-2.2 nut-2.7.4 opencryptoki-3.8.1+dfsg opendkim-2.11.0~beta2 opendmarc-1.3.2 opendnssec-2.1.4 opensips-2.2.2 open-vm-tools-11.0.5 pgpool2-4.1.0 php7.3-7.3.12 postgresql-common-211 prads-0.3.3 prelude-correlator-5.1.0+ds prelude-lml-5.1.0 prelude-manager-5.1.0 puppet-5.5.10 pushpin-1.26.0 resolvconf-1.82 rkt-1.30.0+dfsg1 rpcbind-1.2.5 screen-4.7.0 shadow-4.8 shairport-sync-3.3.5 shibboleth-sp-3.0.4+dfsg1 softflowd-1.0.0 speech-dispatcher-0.9.1 squid-4.9 sslh-1.20 tcpcrypt-0.5 tinyproxy-1.10.0 tomcat9-9.0.27 trafficserver-8.0.5+ds ulogd2-2.0.7 vrfydmn-0.11.0 vsftpd-3.0.3 wdm-1.28 wesnoth-1.14-1.14.9 yadifa-2.3.8 zabbix-4.0.16+dfsg zoneminder-1.32.3 acmetool-0.0.62/debian/acmetool.tmpfile bind9-9.11.14+dfsg/debian/bind9.tmpfile binkd-1.1a-99/debian/binkd.tmpfile bley-2.0.0/debian/bley.tmpfile cinder-15.0.0/debian/cinder-common.tmpfile conserver-8.2.4/debian/conserver-server.tmpfile courier-1.0.6/debian/courier-imap.tmpfile courier-1.0.6/debian/courier-ldap.tmpfile courier-1.0.6/debian/courier-mlm.tmpfile courier-1.0.6/debian/courier-mta.courier.tmpfile courier-1.0.6/debian/courier-mta.tmpfile courier-1.0.6/debian/courier-pop.tmpfile courier-1.0.6/debian/sqwebmail.tmpfile courier-authlib-0.69.0/debian/courier-authdaemon.tmpfile custodia-0.6.0/debian/custodia.tmpfile cyrus-imapd-3.0.13/debian/cyrus-common.cyrus-imapd.tmpfile ejabberd-19.09.1/debian/ejabberd.tmpfile freeipa-4.8.3/debian/freeipa-client.tmpfile fwknop-2.6.10/debian/fwknop-server.tmpfile gitaly-1.78.0+dfsg/debian/gitaly.tmpfile haproxy-2.0.12/debian/haproxy.tmpfile i2pd-2.29.0/debian/i2pd.tmpfile inn-1.7.2q/debian/inn.tmpfile inspircd-3.4.0/debian/inspircd.tmpfile iodine-0.7.0/debian/iodined.tmpfile keystone-16.0.0/debian/keystone.tmpfile knot-2.7.8/debian/knot.tmpfile krb5-1.17/debian/krb5-otp.tmpfile kubernetes-1.7.16+dfsg/debian/kubernetes-master.tmpfile kubernetes-1.7.16+dfsg/debian/kubernetes-node.tmpfile ladvd-1.1.2/debian/ladvd.tmpfile lemonldap-ng-2.0.7+ds/debian/lemonldap-ng-fastcgi-server.tmpfile mailman-2.1.29/debian/mailman.tmpfile mailman3-3.2.2/debian/mailman3.tmpfile mailman-suite-0+20180916/debian/mailman3-web.tmpfile memcached-1.5.21/debian/memcached.tmpfile mpd-0.21.16/debian/mpd.tmpfile munge-0.5.13/debian/munge.tmpfile munin-2.0.54/debian/munin-common.tmpfile munin-2.0.54/debian/munin-node.tmpfile nagios-nrpe-4.0.0/debian/nagios-nrpe-server.tmpfile neutron-15.0.0/debian/neutron-common.tmpfile nextepc-0.3.10+nods/debian/nextepc-hss.tmpfile nextepc-0.3.10+nods/debian/nextepc-mme.tmpfile nextepc-0.3.10+nods/debian/nextepc-pcrf.tmpfile nextepc-0.3.10+nods/debian/nextepc-pgw.tmpfile nextepc-0.3.10+nods/debian/nextepc-sgw.tmpfile ngircd-25/debian/ngircd.tmpfile nova-20.0.0/debian/nova-common.tmpfile nrpe-ng-0.2.0/debian/nrpe-ng.tmpfile nsd-4.1.26/debian/nsd.tmpfile nullmailer-2.2/debian/nullmailer.tmpfile nut-2.7.4/debian/nut-client.tmpfile nut-2.7.4/debian/nut-server.tmpfile opencryptoki-3.8.1+dfsg/debian/opencryptoki.tmpfile
Bug#950443: "Debian Testing Weekly" Installation Failed
Package: installation-reports
Boot method: CD
Image version:
http://saimei.ftp.acc.umu.se/cdimage/unofficial/non-free/images-including-firmware/weekly-builds/amd64/iso-cd/firmware-testing-amd64-netinst.iso
Date: February 1 2020 - 19:00
Machine: HP --> 15-ay003nt (full model of laptop)
Processor: Intel i3 5005U
Memory: 4 GB
Partitions: Standard Win10 installation and 150 GB root partition.
Output of lspci -knn (or lspci -nn):
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot: [O]
Detect network card:[O]
Configure network: [O]
Detect CD: [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives: [O]
Install base system:[O]
Clock/timezone setup: [O]
User/password setup:[O]
Install tasks: [E]
Install boot loader:[ ]
Overall install:[ ]
Comments/Problems:
Failed on "Select and Install" final "dpkg" operation ("DE" installation)
Bug#950326: dgit: can't import binutils 2.33.90.20200122-2
> The system is running buster, git is at version 1:2.20.1-2+deb10u1 > git-buildpackage is at 0.9.14 and dgit is at 9.9~bpo10+1 Thanks. I have reproduced the problem. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#950431: qemu-system-ppc: file conflict between qemu-system-{data, ppc}
01.02.2020 18:53, Adam Borowski wrote: > Package: qemu-system-ppc > Version: 1:4.2-2 > Severity: grave > Justification: renders package uninstallable > > Hi! > Upon upgrading or a fresh install: > > Unpacking qemu-system-ppc (1:4.2-2) ... > dpkg: error processing archive «TMP»/3-qemu-system-ppc_1%3a4.2-2_amd64.deb > (--unpack): > trying to overwrite '/usr/share/qemu/skiboot.lid', which is also in package > qemu-system-data 1:4.2-2 Heh. Heh, heh, heh. I never realized we have this that bad. We never depend on qemu-skiboot package for whatever reason, so I thought there were no skiboot support at all before this, and ofcource haven't noticed the link in qemu-system-ppc... Oh well. Fixed! Thanks, /mjt
Bug#944055: Debdiff fixing linbox FTBFS on armhf and mipsel.
tags 950433 +patch
tags 944055 +patch
thanks
As has been reported linbox is currently blocked from migrating to testing by
build failures on armhf and mipsel autobuilders.
In some armhf environments (notablly on Debian porterboxes and buildds with
arm64 kernels), linbox fails to build with bus errors. I tracked these down to
dodgy pointer typecasts leading to unaligned memory accesses. I fixed these by
replacing the dodgy pointer typecasts with memcpy calls.
The mipsel failues were a case of the assembler running out of memory. I don't
quite understand why the assembler is running out of memory so early, maybe it
is being run inside the compiler and the compiler has already eaten a bunch of
address space. In any case I decided the sensible thing to do was to simply
disable the tests in question on mipsel.
While working on these issues I ran into problems with the clean target not
cleaning up properly which I also fixed.
Note: the mipsel and arm64 patches were tested seperately, I did not do any
test builds with both enabled, but I don't see any reason to expect problems.
A debdiff is attached
diff -Nru linbox-1.6.3/debian/changelog linbox-1.6.3/debian/changelog
--- linbox-1.6.3/debian/changelog 2019-09-11 18:44:18.0 +
+++ linbox-1.6.3/debian/changelog 2020-02-01 15:52:03.0 +
@@ -1,3 +1,14 @@
+linbox (1.6.3-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Replace dangerous pointer casts that are causing bus errors on
+some arm setups with memcpy calls.
+ * Disable test-rank-md, test-solve-full and test-solve on mips/mipsel,
+they fail to build with an out of memory error from the assembler on
mipsel.
+ * Fix clean target.
+
+ -- Peter Michael Green Sat, 01 Feb 2020 15:52:03 +
+
linbox (1.6.3-1) unstable; urgency=medium
* Team upload.
diff -Nru
linbox-1.6.3/debian/patches/replace-dangerous-pointer-casts-with-memcpy.patch
linbox-1.6.3/debian/patches/replace-dangerous-pointer-casts-with-memcpy.patch
---
linbox-1.6.3/debian/patches/replace-dangerous-pointer-casts-with-memcpy.patch
1970-01-01 00:00:00.0 +
+++
linbox-1.6.3/debian/patches/replace-dangerous-pointer-casts-with-memcpy.patch
2020-02-01 15:51:51.0 +
@@ -0,0 +1,138 @@
+Author: Peter Michael Green
+Date: Thu Jan 30 22:25:50 2020 +
+
+ Use memcpy instead of dangerous casts. This fixes testsuite failures
+ When building on systems that don't support fully support unaligned
+ memory access.
+
+Index: linbox-1.6.3/linbox/util/serialization.inl
+===
+--- linbox-1.6.3.orig/linbox/util/serialization.inl
linbox-1.6.3/linbox/util/serialization.inl
+@@ -103,7 +103,7 @@ namespace LinBox {
+ inline uint64_t unserialize_raw(T& value, const std::vector&
bytes, uint64_t offset)
+ {
+ auto uValue = (offset);
+-value = *reinterpret_cast(uValue);
++memcpy(,uValue,sizeof(T));
+ return sizeof(T);
+ }
+
+@@ -128,7 +128,7 @@ namespace LinBox {
+ inline uint64_t unserialize(int16_t& value, const std::vector&
bytes, uint64_t offset)
+ {
+ auto uValue = (offset);
+-value = *reinterpret_cast(uValue);
++memcpy(,uValue,sizeof(int16_t));
+ #if defined(__LINBOX_HAVE_BIG_ENDIAN)
+ value = __builtin_bswap16(value);
+ #endif
+@@ -137,7 +137,7 @@ namespace LinBox {
+ inline uint64_t unserialize(uint16_t& value, const std::vector&
bytes, uint64_t offset)
+ {
+ auto uValue = (offset);
+-value = *reinterpret_cast(uValue);
++memcpy(,uValue,sizeof(uint16_t));
+ #if defined(__LINBOX_HAVE_BIG_ENDIAN)
+ value = __builtin_bswap16(value);
+ #endif
+@@ -147,7 +147,7 @@ namespace LinBox {
+ inline uint64_t unserialize(int32_t& value, const std::vector&
bytes, uint64_t offset)
+ {
+ auto uValue = (offset);
+-value = *reinterpret_cast(uValue);
++memcpy(,uValue,sizeof(int32_t));
+ #if defined(__LINBOX_HAVE_BIG_ENDIAN)
+ value = __builtin_bswap32(value);
+ #endif
+@@ -156,7 +156,7 @@ namespace LinBox {
+ inline uint64_t unserialize(uint32_t& value, const std::vector&
bytes, uint64_t offset)
+ {
+ auto uValue = (offset);
+-value = *reinterpret_cast(uValue);
++memcpy(,uValue,sizeof(uint32_t));
+ #if defined(__LINBOX_HAVE_BIG_ENDIAN)
+ value = __builtin_bswap32(value);
+ #endif
+@@ -166,7 +166,7 @@ namespace LinBox {
+ inline uint64_t unserialize(int64_t& value, const std::vector&
bytes, uint64_t offset)
+ {
+ auto uValue = (offset);
+-value = *reinterpret_cast(uValue);
++memcpy(,uValue,sizeof(int64_t));
+ #if defined(__LINBOX_HAVE_BIG_ENDIAN)
+ value = __builtin_bswap64(value);
+ #endif
+@@ -175,7 +175,7 @@ namespace LinBox {
+ inline uint64_t unserialize(uint64_t& value, const std::vector&
bytes, uint64_t offset)
+ {
+ auto
Bug#950442: radicale: missing-systemd-service-for-init.d-script
Source: radicale Version: 2.1.11-7 Severity: normal Dear Maintainer, Please consider shipping a native systemd service masking the already shipped init script (fixes lintian tag[1] in subject). The upstream webpage has instructions at https://radicale.org/setup/ under "Linux with systemd system-wide" (including security hardening![2]). You can put the file in debian/radicale.service to have debhelper handle installing it. Since debhelper compat 9 is now deprecated, your best option is likely to bump to debhelper compat 10 (or higher) and maintscript integration should be automatic. Please don't hesitate to reach out if you need any assistance. I'm happy to help if you provide the testing and review (as I don't use radicale myself). Regards, Andreas Henriksson [1]: https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html [2]: https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html
Bug#950441: snmptt: missing-systemd-service-for-init.d-script
Package: snmptt
Version: 1.4-2
Severity: normal
Tags: patch bullseye sid
Dear Maintainer,
Please consider adding a native systemd service masking the currently
shipped init scripts (fixes lintian tag[1] in subject).
I tried creating a native systemd service myself based on reading the
init script. There where some additional changes needed to the packaging
(like making logrotate use invoke-rc.d) so I'm providing my work as a
debdiff in the hope that it can be useful to you. Note that I've only
build-tested the patch (as I'm not personally using the package).
Please note that I also bumped debhelper compat to 10, as compat 9 is
now deprecated which made me feel like doing the systemd integration
the <10 way seemed pointless.
Don't hesitate to reach out if any help is necessary. I'll happily help
if you provide the testing and review (as I don't use snmptt myself).
Further improvements like security hardening[2] could be added later.
Regards,
Andreas Henriksson
[1]:
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
[2]:
https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html
diff -Nru snmptt-1.4/debian/changelog snmptt-1.4/debian/changelog
--- snmptt-1.4/debian/changelog 2018-05-19 16:23:26.0 +0200
+++ snmptt-1.4/debian/changelog 2020-02-01 19:24:17.0 +0100
@@ -1,3 +1,15 @@
+snmptt (1.4-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/logrotate: Use invoke-rc.d instead of init script directly.
+ * Add debian/snmptt.service masking init script
+ * Drop lsb-base dependency
+- it's guaranteed to be installed on sysvinit systems and not
+ needed on other systems now that there's a native systemd unit.
+ * Bump debhelper compat to 10 for automatic systemd handling
+
+ -- Andreas Henriksson Sat, 01 Feb 2020 19:24:17 +0100
+
snmptt (1.4-2) unstable; urgency=medium
* Depend on lsb-base.
diff -Nru snmptt-1.4/debian/compat snmptt-1.4/debian/compat
--- snmptt-1.4/debian/compat2014-10-09 15:29:23.0 +0200
+++ snmptt-1.4/debian/compat2020-02-01 19:24:17.0 +0100
@@ -1 +1 @@
-9
+10
diff -Nru snmptt-1.4/debian/control snmptt-1.4/debian/control
--- snmptt-1.4/debian/control 2018-05-19 16:23:26.0 +0200
+++ snmptt-1.4/debian/control 2020-02-01 19:24:17.0 +0100
@@ -2,7 +2,7 @@
Section: net
Priority: optional
Maintainer: Christoph Berg
-Build-Depends: debhelper (>= 9)
+Build-Depends: debhelper (>= 10)
Homepage: http://www.snmptt.org/
Standards-Version: 4.1.4
Vcs-Git: https://salsa.debian.org/debian/snmptt.git
@@ -14,7 +14,6 @@
adduser,
libconfig-inifiles-perl,
libsnmp-perl,
- lsb-base,
snmpd,
${misc:Depends},
Recommends: libsys-syslog-perl
diff -Nru snmptt-1.4/debian/logrotate snmptt-1.4/debian/logrotate
--- snmptt-1.4/debian/logrotate 2012-12-22 14:44:50.0 +0100
+++ snmptt-1.4/debian/logrotate 2020-02-01 19:24:05.0 +0100
@@ -6,6 +6,6 @@
compress
sharedscripts
postrotate
- /etc/init.d/snmptt reload > /dev/null
+ invoke-rc.d --quiet snmptt reload > /dev/null
endscript
}
diff -Nru snmptt-1.4/debian/snmptt.service snmptt-1.4/debian/snmptt.service
--- snmptt-1.4/debian/snmptt.service1970-01-01 01:00:00.0 +0100
+++ snmptt-1.4/debian/snmptt.service2020-02-01 19:23:48.0 +0100
@@ -0,0 +1,22 @@
+[Unit]
+Description=SNMP trap translator
+After=network.target
+
+[Service]
+Type=forking
+PIDFile=/run/snmptt.pid
+Environment=DAEMON_ARGS="--daemon"
+EnvironmentFile=-/etc/default/snmptt
+ExecStart=/usr/sbin/snmptt $DAEMON_ARGS
+# Note: signals are async, but ExecReload command should block until
+# reloading is finished.
+ExecReload=/bin/kill -HUP $MAINPID
+ExecReload=/bin/sleep 2
+# Daemon will drop privilegies on its own. Will use privilegied mode for
+# dealing with pidfile. Might be better to try to start it unprivilegied
+# instead at some point
+#User=snmptt
+#Group=snmptt
+
+[Install]
+WantedBy=multi-user.target
Bug#950326: dgit: can't import binutils 2.33.90.20200122-2
On 01/02/2020 18:04, Ian Jackson wrote:
peter green writes ("Bug#950326: dgit: can't import binutils
2.33.90.20200122-2"):
Package: dgit
Version: 9.9~bpo10+1
When trying to import binutils 2.33.90.20200122-2 I get the following.
['dgit', 'import-dsc',
'/build/workingrepo/pool/main/b/binutils/binutils_2.33.90.20200122-2.dsc',
'..workingbranch']
Dgit metadata in .dsc: NO git hash
using existing binutils_2.33.90.20200122.orig.tar.xz
using existing binutils_2.33.90.20200122-2.debian.tar.xz
dpkg-source: info: extracting binutils in binutils-2.33.90.20200122
dpkg-source: info: unpacking binutils_2.33.90.20200122.orig.tar.xz
dpkg-source: info: unpacking binutils_2.33.90.20200122-2.debian.tar.xz
warning: gbp pq import failed: subprocess failed with error exit status 1
dgit: trying slow absurd-git-apply...
gbp:error: Failed to apply
'/build/git/b/binutils/.git/dgit/unpack/binutils-2.33.90.20200122/debian/patches/001_ld_makefile_patch.patch':
Failed to commit tree: fatal: invalid date format: ??
gbp:error: Couldn't apply patches
gbp pq import failed: subprocess failed with error exit status 1
I don't seem to be able to reproduce this on stretch. What versions
of git-buildpackage and git do you have installed ?
The system is running buster, git is at version 1:2.20.1-2+deb10u1
git-buildpackage is at 0.9.14 and dgit is at 9.9~bpo10+1
Bug#944968: popularity-contest: Program accesses internal dpkg database
On Sat, Feb 01, 2020 at 07:09:56PM +0100, Bill Allombert wrote: > On Sat, Feb 01, 2020 at 07:02:38PM +0100, Guillem Jover wrote: > > On Thu, 2019-11-28 at 22:41:44 +0100, Bill Allombert wrote: > > > On Thu, Nov 28, 2019 at 08:55:00PM +, Niels Thykier wrote: > > > > While it would take a bit of restructuring / refactoring, I think it > > > > would be possible to use a single dpkg-query for everything and still be > > > > able to process the data in a "streaming" fashion. > > > > > > Yes this could work, however this is assuming that dpkg-query is not > > > allocating everything in memory at once. > > > > dpkg-query will load everything in memory, in the same way it does > > while doing a «dpkg --install» or similar. The key here is that these > > files are just going to disappear in an inminent future, and anything > > relying on them will just break. Also dpkg will be moving into keeping > > the entire package filesystem knowledge in a single database file anyway. > > A database file normally allows to extract fields without having the whole > database in memory. dpkg should provide an interface to that. In fact, popcon do not even require that. If it is a single line-based text file, popcon should be able to read it line-by-line, freeing previously read lines as soon as it does not need them. The total memory used will be of the order of the generated popcon report. Cheers, -- Bill. Imagine a large red swirl here.
Bug#950440: debian-policy: Confusing conflation of Essential:yes w/ Priority:required
Package: debian-policy Version: 4.5.0.0 Severity: normal Hi! This was brought up on debian-devel, and I think it needs to be updated/corrected in the policy manual: On Fri, 2020-01-17 at 12:21:11 +0100, Guillem Jover wrote: > On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote: > > Johannes Schauer writes: > > > My advice would also be to switch from debootstrap to mmdebstrap because > > > the > > > latter is able to create a chroot with only Essential:yes packages in it > > > while > > > debootstrap includes Priority:required packages as well. Alternatively, > > > debootstrap could gain a variant only installing Essential:yes packages > > > and > > > their dependencies (why doesn't it have that already?). > > > > Debian doesn't support systems that don't have "required" packages > > installed. So buildds should have them installed. > > If these statements are based on the policy quote below, then I do > not agree. I don't see why e2fsprogs would need to be installed on > a chroot, as long as there's nothing depending on it, for example. > > > Policy states: > > "Removing a required package may cause your system to become totally > > broken and you may not even be able to use dpkg to put things back, so > > only do so if you know what you are doing." > > That seems wrong, or inaccurate at best. dpkg should never depend on > anything that is not part of the pseudo-essential set (strictly > speaking only Essential:yes + awk-virtual), or that it depends on > explicitly. So as long as a package has not been forced out, dpkg > must work. > > Removing a required package (that is not Essential:yes) might indeed > render your system broken, but what broken means or in what context is > not qualified there. This could apply to systems that get booted for > example, but not to chroots. A package that relies on another package > that is Priority:required and not Essential:yes, and that it does not > depend on, is just broken. > > Here's the current list of these packages on my system: > > $ aptitude -F '%p' search '~prequired !~E' > debconf > e2fsprogs > gcc-10-base > gcc-9-base > libpam-modules > libpam-modules-bin > libpam-runtime > mawk > mount > passwd > tzdata > > And most of these are actually part of the pseudo-essential set > anyway, and cannot be removed w/o force. > > That passage in policy might have made sense some time ago, when > Priority:required almost matched the pseudo-essential set, and when we > didn't have a separation of "dpkg-essential" and "boot-essential". Regards, Guillem
Bug#950438: [Piuparts-devel] Bug#950438: piuparts: test for systemd dependency cycle
On 01/02/2020 18.21, Christian Göttsche wrote: > I like to suggest adding a test whether a package introduces a systemd > dependency cycle, e.g. #950418 . That sounds a bit like it would be more suitable for an (automatic) autopkgtest or debian-ci. I'm not sure if a minimal piuparts chroot (probably without systemd) can be used for such tests - how would they look like? Andreas
Bug#944968: popularity-contest: Program accesses internal dpkg database
On Sat, Feb 01, 2020 at 07:02:38PM +0100, Guillem Jover wrote: > On Thu, 2019-11-28 at 22:41:44 +0100, Bill Allombert wrote: > > On Thu, Nov 28, 2019 at 08:55:00PM +, Niels Thykier wrote: > > > While it would take a bit of restructuring / refactoring, I think it > > > would be possible to use a single dpkg-query for everything and still be > > > able to process the data in a "streaming" fashion. > > > > Yes this could work, however this is assuming that dpkg-query is not > > allocating everything in memory at once. > > dpkg-query will load everything in memory, in the same way it does > while doing a «dpkg --install» or similar. The key here is that these > files are just going to disappear in an inminent future, and anything > relying on them will just break. Also dpkg will be moving into keeping > the entire package filesystem knowledge in a single database file anyway. A database file normally allows to extract fields without having the whole database in memory. dpkg should provide an interface to that. Cheers, -- Bill. Imagine a large red swirl here.
Bug#950326: dgit: can't import binutils 2.33.90.20200122-2
peter green writes ("Bug#950326: dgit: can't import binutils
2.33.90.20200122-2"):
> Package: dgit
> Version: 9.9~bpo10+1
>
> When trying to import binutils 2.33.90.20200122-2 I get the following.
>
> ['dgit', 'import-dsc',
> '/build/workingrepo/pool/main/b/binutils/binutils_2.33.90.20200122-2.dsc',
> '..workingbranch']
> Dgit metadata in .dsc: NO git hash
> using existing binutils_2.33.90.20200122.orig.tar.xz
> using existing binutils_2.33.90.20200122-2.debian.tar.xz
> dpkg-source: info: extracting binutils in binutils-2.33.90.20200122
> dpkg-source: info: unpacking binutils_2.33.90.20200122.orig.tar.xz
> dpkg-source: info: unpacking binutils_2.33.90.20200122-2.debian.tar.xz
> warning: gbp pq import failed: subprocess failed with error exit status 1
> dgit: trying slow absurd-git-apply...
> gbp:error: Failed to apply
> '/build/git/b/binutils/.git/dgit/unpack/binutils-2.33.90.20200122/debian/patches/001_ld_makefile_patch.patch':
> Failed to commit tree: fatal: invalid date format: ??
> gbp:error: Couldn't apply patches
> gbp pq import failed: subprocess failed with error exit status 1
I don't seem to be able to reproduce this on stretch. What versions
of git-buildpackage and git do you have installed ?
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#944968: popularity-contest: Program accesses internal dpkg database
On Thu, 2019-11-28 at 22:41:44 +0100, Bill Allombert wrote: > On Thu, Nov 28, 2019 at 08:55:00PM +, Niels Thykier wrote: > > While it would take a bit of restructuring / refactoring, I think it > > would be possible to use a single dpkg-query for everything and still be > > able to process the data in a "streaming" fashion. > > Yes this could work, however this is assuming that dpkg-query is not > allocating everything in memory at once. dpkg-query will load everything in memory, in the same way it does while doing a «dpkg --install» or similar. The key here is that these files are just going to disappear in an inminent future, and anything relying on them will just break. Also dpkg will be moving into keeping the entire package filesystem knowledge in a single database file anyway. Thanks, Guillem
Bug#838232: profanity-nox package
Hi, I modified the source package so that it produces a profanity and a profanity-nox package. The latter does not have X-Dependencies. You can find the merge request there: https://salsa.debian.org/xmpp-team/profanity/merge_requests/2 To the maintainer(s): As I am not experienced in debian packaging you should see this as a proof-of-concept and check it thoroughly before merging. But I can tell that building it works well for me locally and the profanity-nox package is running right now on my VPS which is, of course, headless. Best regards, Martin signature.asc Description: PGP signature
Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck
I added nomodeset as described in https://askubuntu.com/a/38834 . Then, the boot process displayed some error concerning UMS and radeon early in the process, and the screen resolution is different. The boot process still gets stuck, and switching with Ctrl+Alt+F1 followed by Ctrl+Alt+F2 makes it continue, but the segfault message disappears from dmesg.
Bug#950403: RFS: scons/3.1.2-2 -- replacement for make
On Sat, Feb 01, 2020 at 08:49:20AM +0100, Jörg Frings-Fürst wrote: > I think it was my error by merging into the release branch. > > Now the correct version is uploaded into git and to mentors. Compared to the version in experimental, the new one adds Depends:python-any -- is this intentional? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ The ill-thought conversion to time64_t will make us suffer from ⣾⠁⢠⠒⠀⣿⡁ the Y292B problem. So let's move the Epoch by 43545140006400 ⢿⡄⠘⠷⠚⠋⠀ (plus a safety margin in case of bad physicists) and make it ⠈⠳⣄ unsigned -- that'll almost double the range.
Bug#950439: debtags: [All tips] links to non-existent Alioth page
Package: debtags Version: 2.1.5 Severity: normal Dear Maintainer, on the tag editor page there is a button [All tips] (bottom of Tagging tip) which leads to non-existent Alioth page, http://debtags.alioth.debian.org/edit-tips.html Regards, Lev Lamberov -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debtags depends on: ii python3 3.7.5-3 ii python3-apt 1.8.5 ii python3-debian 0.1.36 debtags recommends no packages. Versions of packages debtags suggests: ii tagcoll 2.0.14-2 -- no debconf information
Bug#947558: d1x-rebirth: diff for NMU version 0.58.1-1.1
On Sunday, 2 February 2020 2:28:04 AM AEDT Stephen Kitt wrote: > I've prepared an NMU for d1x-rebirth (versioned as 0.58.1-1.1) and > uploaded it to DELAYED/5. Thank you very much for doing this, Stephen. Much appreciated. -- Cheers, Dmitry Smirnov. --- The cure for the evils of democracy is more democracy. -- H. L. Mencken signature.asc Description: This is a digitally signed message part.
Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck
In the attachment you find /var/log/Xorg.0.log. It contains some error message. Concerning nomodeset: can I add it during boot process when the grub screen pops up? [37.930] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [37.931] Build Operating System: Linux 4.9.0-8-amd64 i686 Debian [37.931] Current Operating System: Linux T42-LAPTOP 4.19.0-6-686 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) i686 [37.931] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-686 root=UUID=c2e7e76d-6ee0-4705-9f83-ed1310bcbced ro quiet [37.931] Build Date: 05 March 2019 08:11:12PM [37.931] xorg-server 2:1.20.4-1 (https://www.debian.org/support) [37.931] Current version of pixman: 0.36.0 [37.931] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [37.931] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [37.932] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 1 18:22:53 2020 [38.244] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [38.454] (==) No Layout section. Using the first Screen section. [38.454] (==) No screen section available. Using defaults. [38.454] (**) |-->Screen "Default Screen Section" (0) [38.454] (**) | |-->Monitor "" [38.484] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [38.485] (==) Automatically adding devices [38.485] (==) Automatically enabling devices [38.485] (==) Automatically adding GPU devices [38.485] (==) Max clients allowed: 256, resource mask: 0x1f [38.905] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [38.905] Entry deleted from font path. [39.435] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [39.435] (==) ModulePath set to "/usr/lib/xorg/modules" [39.435] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [39.435] (II) Loader magic: 0x70a740 [39.435] (II) Module ABI versions: [39.435] X.Org ANSI C Emulation: 0.4 [39.435] X.Org Video Driver: 24.0 [39.435] X.Org XInput driver : 24.1 [39.435] X.Org Server Extension : 10.0 [39.443] (++) using VT number 7 [39.443] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [39.444] (II) xfree86: Adding drm device (/dev/dri/card0) [39.461] (--) PCI:*(1@0:0:0) 1002:4c57:1014:0530 rev 0, Mem @ 0xe000/134217728, 0xc010/65536, I/O @ 0x3000/256, BIOS @ 0x/131072 [39.557] (II) LoadModule: "glx" [39.584] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [40.260] (II) Module glx: vendor="X.Org Foundation" [40.260] compiled for 1.20.4, module version = 1.0.0 [40.260] ABI class: X.Org Server Extension, version 10.0 [40.260] (II) Applying OutputClass "Radeon" to /dev/dri/card0 [40.260] loading driver: radeon [40.260] (==) Matched radeon as autoconfigured driver 0 [40.260] (==) Matched ati as autoconfigured driver 1 [40.260] (==) Matched modesetting as autoconfigured driver 2 [40.260] (==) Matched fbdev as autoconfigured driver 3 [40.260] (==) Matched vesa as autoconfigured driver 4 [40.260] (==) Assigned the driver to the xf86ConfigLayout [40.260] (II) LoadModule: "radeon" [40.329] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so [40.575] (II) Module radeon: vendor="X.Org Foundation" [40.575] compiled for 1.20.4, module version = 19.0.1 [40.575] Module class: X.Org Video Driver [40.575] ABI class: X.Org Video Driver, version 24.0 [40.575] (II) LoadModule: "ati" [40.575] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so [40.594] (II) Module ati: vendor="X.Org Foundation" [40.594] compiled for 1.20.4, module version = 19.0.1 [40.594] Module class: X.Org Video Driver [40.594] ABI class: X.Org Video Driver, version 24.0 [40.596] (II) LoadModule: "modesetting" [40.596] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [40.722] (II) Module modesetting: vendor="X.Org Foundation" [40.722] compiled for 1.20.4, module version = 1.20.4 [40.722] Module class: X.Org Video Driver [40.722] ABI class: X.Org Video Driver, version 24.0 [40.722] (II) LoadModule: "fbdev" [40.723] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [40.796] (II) Module fbdev: vendor="X.Org Foundation" [40.796] compiled for 1.20.0, module version = 0.5.0 [40.796] Module class: X.Org Video Driver [40.796]
Bug#950438: piuparts: test for systemd dependency cycle
Package: piuparts Version: 1.1.1 Severity: wishlist I like to suggest adding a test whether a package introduces a systemd dependency cycle, e.g. #950418 .
Bug#950437: garcon: encoding of .directory files differs depending on locale
Source: garcon Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: environment locale X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org When built with the C locale, some files differ from when built with a UTF-8 locale, such as xfce-screensavers.directory: Icon=preferences-desktop-screensaver Name=Screensavers Name[am]=መመልከቻ·ማዳኛ Name[ar]=حافظات·الشاشة Name[ast]=Curiapantalles Name[be]=Ахоўнікі·экра The encoding of the file also varies. The attached patch works around this by exporting LC_ALL=C.UTF-8 in debian/rules, ensuring all builds use a UTF-8 locale. Thanks for maintaining garcon. live well, vagrant From 0e8418abdfdd062ec372f73bb3a45e5bb1bc6ed9 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sat, 1 Feb 2020 08:32:08 -0800 Subject: [PATCH] debian/rules: export LC_ALL=C.UTF-8 to ensure reproducible builds regardless of locale. --- debian/rules | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/rules b/debian/rules index c0a9c6a..931e87d 100755 --- a/debian/rules +++ b/debian/rules @@ -3,6 +3,9 @@ export DEB_LDFLAGS_MAINT_APPEND=-Wl,-z,defs -Wl,--as-needed -Wl,-O1 export DEB_BUILD_MAINT_OPTIONS=hardening=+all +# Use C.UTF-8 locale to ensure reproducible builds +export LC_ALL=C.UTF-8 + %: dh $@ -- 2.20.1 signature.asc Description: PGP signature
Bug#950418: Bug #950418: haveged: Strange systemd trace since last version
Running 'systemd-analyze verify default.target' prints the following: haveged.service: Found ordering cycle on systemd-tmpfiles-setup.service/start haveged.service: Found dependency on systemd-journal-flush.service/start haveged.service: Found dependency on systemd-journald.service/start haveged.service: Found dependency on haveged.service/start haveged.service: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with haveged.service/start So 'haveged' depends on 'systemd-tmpfiles-setup.service', which depends on 'systemd-journald.service', which depends on 'haveged.service'.
Bug#950436: RM: pyblosxom -- ROM; no longer actively maintained
Package: ftp.debian.org Severity: normal Dear ftp team, please remove pyblosxom from Debian. The blog compiler is Python 2 only and upstream is no longer actively maintaining this software. We have several good alternatives in Debian like Hugo or Jekyll to compensate for the removal. Thanks, Markus
Bug#950330: libvncclient1: Serious artifacts after upgrading to 0.9.12
On 01/02/20 17:21, Mike Gabriel wrote: can you please test your issue using http://packages.sunweavers.net/debian/pool/main/libv/libvncserver/libvncclient1_0.9.12+dfsg-8~test1_amd64.deb Hello Mike, your package seems to fix the issue. I've tried two connection: (1) TightVNC 2.8.5 (Win7 64 bit) (2) TightVNC 2.8.? (Win7 32 bit) With both I've set Remmina connection to 16 bpp. Also with (1) I've also tried all quality values (poor, medium, good, best) and also 8 bpp and 32 bpp. In all cases, everything looks good. Unfortunately I have no VNC servers to test other than TightVNC 2.8.x under Win7/Win10. Thank you very much. Cesare.
Bug#937393: pyblosxom: Python2 removal in sid/bullseye
According to upstream's notice on http://pyblosxom.github.io/, Pyblosxom is no longer in active development. There was the attempt to port it to Python 3 but this one was never completed. Nowadays we have several good alternatives in Debian that achieve the same thing, e.g. hugo or jekyll. I believe it is time now to file a removal request for pyblosxom. signature.asc Description: OpenPGP digital signature
Bug#950435: haproxy build-depends on package that has been dropped.
Package: haproxy Version: 2.0.12-1 Severity: serious haproxy build-depends-indep on python-mako, which is no longer built by the mako source package, it is still present in unstable as a cruft package, but is completely gone from testing.
Bug#943027: fretsonfire: Python2 removal in sid/bullseye
> Am 01.02.20 um 17:06 schrieb Steve Cotton: > > On Sat, Feb 01, 2020 at 04:06:56PM +0100, Markus Koschany wrote: > >> Please don't remove any games from Debian because of the Python 2 > >> removal and try to port the games to Python 3 instead. For instance who should port these games? the upstream maintaintainers? maybe but what if they are not developing the game anymore? the debian maintainers? i dont think that's appropriate to ask that, as then even more burden will fall on them (both keeping the package up to standards *and* maintain the py3k port). so whos left? it appears nobody. > >> Bernhard has done a lot of good porting work and ported several games to > >> Python 3 already. Even if we don't succeed in porting all games to > >> Python 3 in time for Debian 11, then we should just give people more > >> time to realize the impact of the py2removal goal. No. with this approach, nobody will do anything about py2removal and we're gonna keep python2 around forever. you had more than a year, nothing happen, it's time to be objective and realize there wont be a savior for fretsonfire and it's time for Debian to drop it. > > > > Markus, the trouble with saying "give people more time" is that there's been > > a py2removal bug open on Frets On Fire since October 2018. That's #912511, > > from the python-pygame mass bug filing. > > We have one year left in this release cycle and you cannot expect that no we dont. at some point in the next months the distribution will freeze and we wont be able to make substantial progress. > all Python 2 games will be ported to Python 3 at the same time or in a > few months. There is no urgency at all to remove those games from > Debian. really? what about all the reverse dependencies that need to be kept in the archive *just* for this antique softwares to remain usable? I, for example, have 2 packages i cant remove because of fretsonfire; at some point i'll have to make a decision, and most likely i'll favor my own packages over a relic from 10+ years ago. > It also does not matter how old a game is because games like > fretsonfire are feature complete. OMG LOL! did you look at the sourceforge page? there are literally hundreds of bug reports and feature requests. year "feature complete". > Please contribute by fixing those bugs > for a change. i sincerely hope this is not meant for me. Please revisit your position to make the Debian distribution progress towards the py2removal goal: dont be an obstacle, help instead. Regard,s -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#937435: pyexiv2: Python2 removal in sid/bullseye
> I'd preffer to drop pyexiv2 completely. The recommended upstream > approach was to use GI (and gir1.2-gexiv2-0.10) and that's where most > of the reverese dependencies have migrated. Sure, that sounds like a good plan: do you want me to file the RM bug? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#950434: ITP: net-cpp -- C++11 library for networking purposes
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: net-cpp Version : 2.0.1 Upstream Author : Marius Gripsgard * URL : https://gitlab.com/ubports/core/lib-cpp/net-cpp/ * License : LGPL-3.0 Programming Lang: C++ Description : C++11 library for networking purposes Net-Cpp is a simple and straightforward networking library for C++11. This package will be maintained by the Debian UBports Team and is a requirement for the U(nity)8 Desktop Environment.
Bug#943027: fretsonfire: Python2 removal in sid/bullseye
Am 01.02.20 um 17:06 schrieb Steve Cotton: > On Sat, Feb 01, 2020 at 04:06:56PM +0100, Markus Koschany wrote: >> Please don't remove any games from Debian because of the Python 2 >> removal and try to port the games to Python 3 instead. For instance >> Bernhard has done a lot of good porting work and ported several games to >> Python 3 already. Even if we don't succeed in porting all games to >> Python 3 in time for Debian 11, then we should just give people more >> time to realize the impact of the py2removal goal. > > Markus, the trouble with saying "give people more time" is that there's been > a py2removal bug open on Frets On Fire since October 2018. That's #912511, > from the python-pygame mass bug filing. We have one year left in this release cycle and you cannot expect that all Python 2 games will be ported to Python 3 at the same time or in a few months. There is no urgency at all to remove those games from Debian. It also does not matter how old a game is because games like fretsonfire are feature complete. Please contribute by fixing those bugs for a change. signature.asc Description: OpenPGP digital signature
Bug#950330: libvncclient1: Serious artifacts after upgrading to 0.9.12
Hi Cesare, On Sa 01 Feb 2020 00:06:13 CET, Cesare Leonardi wrote: On 31/01/20 23:00, Mike Gabriel wrote: @Cesare: would you be ok, if I provided you with a binary build of libvncserver outside of the debian.org namespace (via packages.sunweavers.net) for testing? If so, please let me know and I'll provide you with test packages. On the other hand, if you feel confident enough to build a patches libvncserver yourself, you can of course cherry-pick the fix for libvncserver/issues/335 and try a test build yourself. Let me know what you prefer? Hello guys, I've read your messages and these: https://github.com/LibVNC/libvncserver/issues/335 https://gitlab.com/Remmina/Remmina/issues/1824 There are a lot information there and not all are completely clear to me. I just confirm that in Remmina, as a workaround, changing "Color depth" away from "High color (16 bpp)", make corruptions go away: no problem neither with 8 bit nor 32 bit. Mike, I'll be happy to test your deb packages: please provide me the URL when you are ready. I'm just a user, I'm not able to build packages myself, sorry. Cesare. can you please test your issue using http://packages.sunweavers.net/debian/pool/main/libv/libvncserver/libvncclient1_0.9.12+dfsg-8~test1_amd64.deb Thanks, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpILFNI9oHFi.pgp Description: Digitale PGP-Signatur
Bug#943027: fretsonfire: Python2 removal in sid/bullseye
On Sat, Feb 01, 2020 at 04:06:56PM +0100, Markus Koschany wrote: > Please don't remove any games from Debian because of the Python 2 > removal and try to port the games to Python 3 instead. For instance > Bernhard has done a lot of good porting work and ported several games to > Python 3 already. Even if we don't succeed in porting all games to > Python 3 in time for Debian 11, then we should just give people more > time to realize the impact of the py2removal goal. Markus, the trouble with saying "give people more time" is that there's been a py2removal bug open on Frets On Fire since October 2018. That's #912511, from the python-pygame mass bug filing. BR, Steve
Bug#950433: linbox FTBFS on mipsel, oom while building tests.
Package: linbox Version: 1.6.3-1 Severity: serious Since I was looking at the linbox failure on armhf, I figured i'd have a look at the mipsel one too. Based on past experiences with other packages, I was expecting it to also be related to alignment issues. However I was wrong! It seems it is failing with an out of memory error, while trying to build one of the tests. What is strange is it seems to be failing after allocating only a relatively small amount of memory. I'm not sure if this is some mipsel weirdness or just as not correctly reporting how much memory it has allocated. I suspect the best course of action is to disable building or running the test in question on mipsel. Thoughts?
Bug#933334: fixed in ugene 33.0+dfsg-1
reopen 94 found 94 1.31.1+dfsg-1 fixed 94 33.0+dfsg-1 thanks Reopening because packages in stable must build in stable.
Bug#950432: cfengine3: missing-systemd-service-for-init.d-script
Source: cfengine3
Version: 3.12.1-2
Severity: normal
Tags: patch bullseye sid
Dear Maintainer,
Please consider shipping native systemd services masking the currently
shipped init script (fixes lintian tag[1] in subject).
Please note that systemd services are already provided by upstream!
I'm attaching a patch that simply installs them (which has only been
build-tested, as I don't personally use cfengine3).
Since you have a home-grown mechanism to enable/disable services,
rather than using the systemwide way[2] you might want to look
into adding maintscript code for a one-time upgrade conversion
of the home-grown state to system-wide so that the new
services maintains their old state.
Regards,
Andreas Henriksson
[1]:
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
[2]:
https://lintian.debian.org/tags/init.d-script-should-always-start-service.html
diff -Nru cfengine3-3.12.1/debian/cfengine3.install
cfengine3-3.12.1/debian/cfengine3.install
--- cfengine3-3.12.1/debian/cfengine3.install 2019-01-07 10:08:09.0
+0100
+++ cfengine3-3.12.1/debian/cfengine3.install 2020-02-01 16:51:23.0
+0100
@@ -1,2 +1,3 @@
debian/tmp/usr/bin/*usr/sbin/
debian/tmp/usr/share/cfengine3
+debian/tmp/lib/systemd/system
diff -Nru cfengine3-3.12.1/debian/changelog cfengine3-3.12.1/debian/changelog
--- cfengine3-3.12.1/debian/changelog 2019-01-07 10:08:09.0 +0100
+++ cfengine3-3.12.1/debian/changelog 2020-02-01 16:51:23.0 +0100
@@ -1,3 +1,11 @@
+cfengine3 (3.12.1-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add configure flag --with-systemd-service=/lib/systemd/system
+ * debian/cfengine3.install: Add /lib/systemd/system
+
+ -- Andreas Henriksson Sat, 01 Feb 2020 16:51:23 +0100
+
cfengine3 (3.12.1-2) unstable; urgency=medium
* debian/patches:
diff -Nru cfengine3-3.12.1/debian/rules cfengine3-3.12.1/debian/rules
--- cfengine3-3.12.1/debian/rules 2019-01-07 10:08:09.0 +0100
+++ cfengine3-3.12.1/debian/rules 2020-02-01 16:51:19.0 +0100
@@ -27,6 +27,7 @@
--with-workdir=/var/lib/cfengine3 \
--with-logdir=/var/log/cfengine3 \
--with-piddir=/var/run/cfengine3 \
+ --with-systemd-service=/lib/systemd/system \
--libdir=/usr/lib/cfengine3 \
--docdir=\$${prefix}/share/doc/cfengine3 \
--datadir=\$${prefix}/share/cfengine3 \
Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu
On Fri, 31 Jan 2020 06:28:07 +0100 Johannes Schauer wrote: [...] > Quoting Francesco Poli (2020-01-30 23:41:11) [...] > > Wait, does this change the result? [...] > in your case, TMPDIR was a relative path. [...] > Your expectation was, that when you set TMPDIR, the only one who would consume > that environment variable would be mmdebstrap itself. I think that thought is > not unreasonable. That's why I think it's important that mmdebstrap unsets > that > variable before it executes processes inside the chroot. All your reasoning makes sense to me. I agree that TMPDIR should be unset by mmdebstrap before running hooks. I tried to check that the resulting .tar file is not affected by this TMPDIR unsetting. I did the following: $ cat ABSTMPDIR/test.sh #!/bin/sh SETUP_TESTBED="/usr/share/autopkgtest/setup-commands/setup-testbed" LIMAVAR="amd64" SUITE="sid" SIZE="2GiB" TMPDIR=$(pwd) export TMPDIR mmdebstrap --variant=important --include=linux-image-"$LIMAVAR" \ --customize-hook='chroot "$1" passwd --delete root' \ --customize-hook='chroot "$1" useradd --home-dir /home/user --create-home user' \ --customize-hook='chroot "$1" passwd --delete user' \ --customize-hook='echo host > "$1/etc/hostname"' \ --customize-hook='echo "127.0.0.1 localhost host" > "$1/etc/hosts"' \ --customize-hook="$SETUP_TESTBED" \ "$SUITE" debian-unstable.tar $ cat NOTMPDIR/test.sh #!/bin/sh SETUP_TESTBED="/usr/share/autopkgtest/setup-commands/setup-testbed" LIMAVAR="amd64" SUITE="sid" SIZE="2GiB" TMPDIR='.' export TMPDIR mmdebstrap --variant=important --include=linux-image-"$LIMAVAR" \ --customize-hook='chroot "$1" passwd --delete root' \ --customize-hook='chroot "$1" useradd --home-dir /home/user --create-home user' \ --customize-hook='chroot "$1" passwd --delete user' \ --customize-hook='echo host > "$1/etc/hostname"' \ --customize-hook='echo "127.0.0.1 localhost host" > "$1/etc/hosts"' \ --customize-hook='env --unset=TMPDIR /usr/share/autopkgtest/setup-commands/setup-testbed "$1"' \ "$SUITE" debian-unstable.tar After running the two test.sh scripts within their respective directories, I used diffoscope to highlight the differences between the two resulting .tar files: $ TMPDIR=/run/shm diffoscope \ --max-diff-block-lines 15000 \ --max-page-diff-block-lines 1500 \ --html report_diffoscope.html \ ABSTMPDIR/debian-unstable.tar \ NOTMPDIR/debian-unstable.tar The only differences shown in the resulting report_diffoscope.html file seem to be: • the generated files in the content of ./boot/initrd.img-5.4.0-3-amd64 have differing creation timestamps (but this is obvious, since the two initrd were not created exactly at the same time!) • ./var/lib/initramfs-tools/5.4.0-3-amd64 files differ (but they seem to include some checksum of the initrd, hence the difference should be consequence of the first point) • ./etc/machine-id and ./var/lib/dbus/machine-id files differ (but I think this should not be surprising...) • ./usr/lib/python3.7/__pycache__/hashlib.cpython-37.pyc files have some different hex values (I am not sure why, but it's compiled Python code, maybe it includes a compilation timestamp or something?!?) I am under the impression that the two .tar files are to be considered equivalent. Do you agree? P.S.: I still have to find the time to check the .qcow2 file I obtained on last Wednesday... :-( -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpbwUbL69RDJ.pgp Description: PGP signature
Bug#950431: qemu-system-ppc: file conflict between qemu-system-{data,ppc}
Package: qemu-system-ppc Version: 1:4.2-2 Severity: grave Justification: renders package uninstallable Hi! Upon upgrading or a fresh install: Unpacking qemu-system-ppc (1:4.2-2) ... dpkg: error processing archive «TMP»/3-qemu-system-ppc_1%3a4.2-2_amd64.deb (--unpack): trying to overwrite '/usr/share/qemu/skiboot.lid', which is also in package qemu-system-data 1:4.2-2 Fix is obvious... Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-00053-g164b7343ac03 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages qemu-system-ppc depends on: ii libaio1 0.3.112-5 ii libasound2 1.2.1.2-2 ii libbrlapi0.7 6.0+dfsg-4+b1 ii libc62.29-9 ii libcacard0 1:2.6.1-1 ii libcapstone3 4.0.1+really+3.0.5-1+b1 ii libepoxy01.5.4-1 ii libfdt1 1.5.1-1 ii libgbm1 19.3.3-1 ii libgcc-s1 [libgcc1] 10-20191205-1 ii libgcc1 1:9.2.1-25 ii libglib2.0-0 2.62.4-1+b1 ii libgnutls30 3.6.11.1-2 ii libibverbs1 27.0-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libncursesw6 6.1+20191019-1 ii libnettle7 3.5.1+really3.5.1-2 ii libnuma1 2.0.12-1+b1 ii libpixman-1-00.36.0-1 ii libpmem1 1.8-1 ii libpng16-16 1.6.37-1 ii librdmacm1 27.0-2 ii libsasl2-2 2.1.27+dfsg-2 ii libseccomp2 2.4.2-2 ii libslirp04.1.0-2 ii libspice-server1 0.14.2-4 ii libtinfo66.1+20191019-1 ii libusb-1.0-0 2:1.0.23-2 ii libusbredirparser1 0.8.0-1+b1 ii libvdeplug2 2.3.2+r586-2.2+b1 ii libvirglrenderer10.8.1-6 ii openbios-ppc 1.1.git20181001-1 ii openhackware 0.4.1+git-20140423.c559da7c-4.1 ii qemu-slof20191209+dfsg-1 ii qemu-system-common 1:4.2-2 ii qemu-system-data 1:4.2-2 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages qemu-system-ppc recommends: ii ipxe-qemu1.0.0+git-20190125.36a4c85-4 ii qemu-system-gui 1:4.2-2 ii qemu-utils 1:4.2-2 ii seabios 1.13.0-1 Versions of packages qemu-system-ppc suggests: pn qemu-block-extra pn samba pn vde2 -- no debconf information
Bug#943481: Please update to 1.4.0
1.4.0 has been released. Option to duplicate page(s) (#18) Remember previous crop input values (#118) Fix rotation with PikePDF & already rotated pages (#120) Update screenshot in appdata (#121) Remove PyPDF2 (#124) Split page spreads into pages (#86) Add basic metadata editing (#68)
Bug#950430: transition: pandas 0.25 -> 1.0
Package: python3-pandas Version: 0.25.3+dfsg-4 Severity: wishlist https://pandas.pydata.org/docs/whatsnew/v1.0.0.html#backwards-incompatible-api-changes
Bug#947558: d1x-rebirth: diff for NMU version 0.58.1-1.1
Control: tags 947558 + patch
Control: tags 947558 + pending
Dear maintainer,
I've prepared an NMU for d1x-rebirth (versioned as 0.58.1-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards,
Stephen
diff -Nru d1x-rebirth-0.58.1/debian/changelog d1x-rebirth-0.58.1/debian/changelog
--- d1x-rebirth-0.58.1/debian/changelog 2013-08-03 22:24:22.0 +0200
+++ d1x-rebirth-0.58.1/debian/changelog 2020-02-01 16:24:25.0 +0100
@@ -1,3 +1,10 @@
+d1x-rebirth (0.58.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Allow building with Python 3. Closes: #947558.
+
+ -- Stephen Kitt Sat, 01 Feb 2020 16:24:25 +0100
+
d1x-rebirth (0.58.1-1) unstable; urgency=low
* New upstream release [July 2013].
diff -Nru d1x-rebirth-0.58.1/debian/patches/python3.patch d1x-rebirth-0.58.1/debian/patches/python3.patch
--- d1x-rebirth-0.58.1/debian/patches/python3.patch 1970-01-01 01:00:00.0 +0100
+++ d1x-rebirth-0.58.1/debian/patches/python3.patch 2020-02-01 16:22:58.0 +0100
@@ -0,0 +1,200 @@
+Description: Allow building with Python 3
+Author: Stephen Kitt
+
+--- a/SConstruct
b/SConstruct
+@@ -12,19 +12,8 @@
+ def get(self,name,value):
+ return self.ARGUMENTS.get('%s_%s' % (self.prefix, name), self.ARGUMENTS.get(name,value))
+
+-# endianess-checker
+-def checkEndian():
+-import struct
+-array = struct.pack('', '\x01', '\x02', '\x03', '\x04')
+-i = struct.unpack('i', array)
+-if i == struct.unpack('i', array):
+-return "big"
+-return "unknown"
+-
+ class DXXCommon:
+- __endian = checkEndian()
++ __endian = sys.byteorder
+ class UserSettings:
+ def __init__(self,ARGUMENTS):
+ # Paths for the Videocore libs/includes on the Raspberry Pi
+@@ -55,7 +44,7 @@
+ builddir_suffix = ARGUMENTS.get('builddir_suffix', None)
+ default_builddir = builddir_prefix or ''
+ if builddir_prefix is not None or builddir_suffix is not None:
+-if os.environ.has_key('CC'):
++if 'CC' in os.environ:
+ default_builddir += '%s-' % os.path.basename(os.environ['CC'])
+ for a in (
+ ('debug', 'dbg'),
+@@ -91,7 +80,7 @@
+ osdef = '__APPLE__'
+ def __init__(self,user_settings):
+ user_settings.asm = 0
+- self.lflags = os.environ["LDFLAGS"] if os.environ.has_key('LDFLAGS') else ''
++ self.lflags = os.environ["LDFLAGS"] if 'LDFLAGS' in os.environ else ''
+ def adjust_environment(self,program,env):
+ VERSION = str(program.VERSION_MAJOR) + '.' + str(program.VERSION_MINOR)
+ if (program.VERSION_MICRO):
+@@ -129,7 +118,7 @@
+ flags = self.__pkg_config_sdl[cmd]
+ except KeyError as e:
+ if (program.user_settings.verbosebuild != 0):
+- print "%s: reading SDL settings from `%s`" % (program.PROGRAM_NAME, cmd)
++ print("%s: reading SDL settings from `%s`" % (program.PROGRAM_NAME, cmd))
+ self.__pkg_config_sdl[cmd] = env.backtick(cmd)
+ flags = self.__pkg_config_sdl[cmd]
+ env.MergeFlags(flags)
+@@ -154,31 +143,31 @@
+ self.env.Append(CPPDEFINES = ['NETWORK'])
+ # Get traditional compiler environment variables
+ for cc in ['CC', 'CXX']:
+- if os.environ.has_key(cc):
++ if cc in os.environ:
+ self.env[cc] = os.environ[cc]
+ for flags in ['CFLAGS', 'CXXFLAGS']:
+- if os.environ.has_key(flags):
++ if flags in os.environ:
+ self.env[flags] += SCons.Util.CLVar(os.environ[flags])
+
+ def check_endian(self):
+ # set endianess
+ if (self.__endian == "big"):
+- print "%s: BigEndian machine detected" % self.PROGRAM_NAME
++ print("%s: BigEndian machine detected" % self.PROGRAM_NAME)
+ self.asm = 0
+ self.env.Append(CPPDEFINES = ['WORDS_BIGENDIAN'])
+ elif (self.__endian == "little"):
+- print "%s: LittleEndian machine detected" % self.PROGRAM_NAME
++ print("%s: LittleEndian machine detected" % self.PROGRAM_NAME)
+
+ def check_platform(self):
+ # windows or *nix?
+ if sys.platform == 'win32':
+- print "%s: compiling on Windows" % self.PROGRAM_NAME
++ print("%s: compiling on Windows" % self.PROGRAM_NAME)
+ platform = self.Win32PlatformSettings
+ elif sys.platform == 'darwin':
+- print "%s: compiling on Mac OS X" % self.PROGRAM_NAME
++ print("%s: compiling on Mac OS X" % self.PROGRAM_NAME)
+ platform = self.DarwinPlatformSettings
+ else:
+- print "%s: compiling on *NIX" % self.PROGRAM_NAME
++ print("%s: compiling on *NIX" % self.PROGRAM_NAME)
+ platform = self.LinuxPlatformSettings
+ self.platform_settings = platform(self.user_settings)
+ # Acquire environment object...
+@@ -192,15 +181,15 @@
+ # opengl or software renderer?
+ if (self.user_settings.opengl == 1) or (self.user_settings.opengles == 1):
+ if (self.user_settings.opengles == 1):
+-print "%s: building with OpenGL ES" % self.PROGRAM_NAME
++print("%s: building with OpenGL ES" % self.PROGRAM_NAME)
+ env.Append(CPPDEFINES = ['OGLES'])
+ else:
+-print "%s: building with OpenGL" % self.PROGRAM_NAME
++print("%s:
Bug#950331: [Python-modules-team] Bug#950331: python3-aiohttp: please package the documentation
Package: python3-aiohttp Version: 3.5.1-1 Hello, I've just push to salsa the docs package. I will need sponsor to upload it. Thanks Cheers, Arias Emmanuel @eamanu http://eamanu.com El vie., 31 de ene. de 2020 a la(s) 11:54, Martin (deba...@debian.org) escribió: > > Quoting Emmanuel Arias : > > I wil try to package today > > Thank you very much! >
Bug#950429: transition: statsmodels 0.10 -> 0.11
Package: python3-statsmodels Version: 0.10.2-1 Severity: wishlist The upstream release notes https://www.statsmodels.org/stable/release/version0.11.html don't specifically list API breaks. The one item that is _obviously_ an API break (removal of DynamicVAR) is something codesearch says we don't use, but there might be others.
