Bug#937143: Bug:#937143: nipy: Python2 removal in sid/bullseye

[Stuart Prescott]

Dear maintainer,

I've prepared an upload of nipy (0.4.2-2.1) that provides a Python 3 module 
package along with a bit of additional polish to the package. I've uploaded it 
to experimental so that the package can pass through the NEW process.

A MR on salsa also brings in the changes, although I'm happy to push the 
changes and tag directly if you'd like to give me appropriate access.

https://salsa.debian.org/neurodebian-team/nipy/merge_requests/1

regards
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#950303: libgpg-error: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: libgpg-error
Version: 1.36-7
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Daniel,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The libgpg-error tests currently fail in this environment, because they
include a build test that does not invoke the toolchain in a cross-aware
manner.  I've verified that the attached patch lets the tests successfully
build (and run) i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
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 libgpg-error-1.36/debian/tests/build 
libgpg-error-1.36/debian/tests/build
--- libgpg-error-1.36/debian/tests/build2019-07-14 20:04:17.0 
-0700
+++ libgpg-error-1.36/debian/tests/build2020-01-30 23:38:12.0 
-0800
@@ -2,6 +2,12 @@
 
 set -e
 
-gcc -pedantic -Wall -Werror -o test-run debian/tests/simple-build.c 
$(pkg-config --cflags --libs gpg-error)
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE=${DEB_HOST_GNU_TYPE}-
+else
+CROSS_COMPILE=
+fi
+
+${CROSS_COMPILE}gcc -pedantic -Wall -Werror -o test-run 
debian/tests/simple-build.c $(${CROSS_COMPILE}pkg-config --cflags --libs 
gpg-error)
 ./test-run
 rm -f test-run

Bug#950302: libpam-geoip_1.1-4_amd64.deb does not work

[Joerg Dorchain]

Package: libpam-geoip
Version: 1.1-5

Hello,

since the update to version 1.1-5 of libpam-geoip I get error in the log and
denied services.

authlog contains (for dovecot):

Jan 31 07:53:31 Redstar auth worker: PASSV: PAM unable to dlopen(pam_geoip.so): 
/lib/security/pam_geoip.so: cannot open shared object file: No such file or 
directory
Jan 31 07:53:31 Redstar auth worker: PASSV: PAM unable to dlopen(pam_geoip.so): 
/lib/security/pam_geoip.so: cannot open shared object file: No such file or 
directory
Jan 31 07:53:31 Redstar auth worker: PASSV: PAM adding faulty module: 
pam_geoip.so
Jan 31 07:53:31 Redstar auth worker: PASSV: PAM adding faulty module: 
pam_geoip.so

pam.d contains:
account required pam_geoip.so debug system_file=/etc/security/geoip.conf 
geoip_db=/usr/share/GeoIP/GeoIPCity.dat use_v6=0 action=allow


/etc/security/geoip.conf:
*   *   allow   DE;LU;BE;NL;FR;CH;AT
*   *   ignore  UNKNOWN
*   *   deny*

Downgrading to version 1.1-4 helps.

Bye,

Joerg


signature.asc
Description: PGP signature

Bug#944040: haveged requires debhelper >= 12.5

[Daniel Baumann]

Hi Nicolas,

On 1/31/20 5:54 AM, Nicolas Braud-Santoni wrote:
> I'm not able to reproduce your issue; I literally just made a backport
> without changing the original package (except for the d/changelog entry),
> which built fine in my buster-backports environment.

I can reproduce it with unpacked sources (untar orig.tar.xz, and then
untar debian.tar.xz inside it) and then running 'dpkg-buildpackage -B'
for a local backport on a clean buster-only chroot (using debhelper 12.1.1).

---snip---
debian/rules override_dh_makeshlibs
make[1]: Entering directory '/build/haveged-1.9.8-3_progress5+u1'
# havege-udeb contains a library that's shipped in libhavege2; this is OK.
dh_makeshlibs --no-add-udeb
Unknown option: no-add-udeb
dh_makeshlibs: unknown option or error during option parsing; aborting
make[1]: *** [debian/rules:23: override_dh_makeshlibs] Error 2
make[1]: Leaving directory '/build/haveged-1.9.8-3_progress5+u1'
make: *** [debian/rules:6: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
exit status 2
build@debian:~/haveged-1.9.8-3_progress5+u1$
---snap---

It builds fine when using a backported debhelper (currently 12.9).

> In particular, could the issue be that you are trying to run `dh clean` 
> outside
> the build environment?

I don't.

Hope that helps, if there's anything more I can do I'm happy to help.

Regards,
Daniel

Bug#935304: libpam-systemd: Please relax Depends: systemd-sysv

[Sam Hartman]

> "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.


I guess there's one way that we could use lybsystemd0 while running
elogind.  If libsystemd0 were patched to understand both the elogind and
systemd cgroup interfaces, I suspect that would be enough that you could
use libsystemd0 at least for applications that do not want elogind
specific functionality.  I suspect such patches are small, but my
presumption is that the systemd maintainers would not want to carry such
patches.  Exploring those patches hasn't really been done I think
because everyone involved assumed that would not be the direction the
systemd maintainers would want to go.

So, what answer would I expect?  A number of possibilities spring to
mind:

1)  "I haven't read Mark's analysis of why libsystemd can't be used and
am not likely to have time right now.  I regret that I cannot help."

2) "Ah, I understand, but I don't have any ideas of how to fix this;
perhaps something will come out of the debian-devel discussion."


3) "Mark missed something important; you could get lybsystemd to work if
you just did X."

I guess you could also say that the Debian maintainers should rewrite
elogind to use systemd's interfaces, although honestly it seems like
that's a huge burden to try and stick on package maintainers.
Upstream, elogind wanted the integration point to be the elogind library
API.  They made their library ABI compatible for us, but my
understanding is that they designed their product so that  you'd build a
given app against either libsystemd0 or libelogind0...  I understand
that our dependency management makes it tricky to do multiple builds of
the related apps to make that work well.

It's totally fine if you don't have answers.  My hope is that you will
take the time to realize that Mark seriously considered your advice and
tried to make it work.  And also, if you do have bright ideas, please
share.:-)

Thanks for listening.

Bug#949386: python3-argcomplete: ships global completion for bash referencing python-argcomplete-check-easy-install-script

[Witold Baryluk]

Package: python3-argcomplete
Version: 1.8.1-1.3
Followup-For: Bug #949386

Indeed, when one installs the completion script via
activate-global-python-argcomplete3 (--user or --dest for example).

and inspect the generated file it containst a reference to

python-argcomplete-check-easy-install-script

but this file is not present in the package.

It should either by activate-global-python-argcomplete3 as shipped, or
because really this file is identival to the one in python2 version of
the package, ship it as activate-global-python-argcomplete without
suffix.

If the python2 version is removed, it is probably worth removing the
suffixes from the scripts names, to match closer the upstream
documentation.

Regards,
Witold



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-argcomplete depends on:
ii  python3  3.7.5-3

python3-argcomplete recommends no packages.

python3-argcomplete suggests no packages.

-- no debconf information

Bug#950287: autofs: automount expriing unmounts target filesystem

[Marc Lehmann]

> > Sounds like I have enough information to duplicate the problem so
> > I'll have a look see.
> 
> Oh, as usual, what's the autofs source version of your package please,
> since I'll be using the current development source to work on it.

It's the one mentioned in my original report (that you probably didn't
get): 5.1.2-4

On Fri, Jan 31, 2020 at 02:07:54PM +0800, Ian Kent  wrote:
> A quick test with the current Fedora autofs package, autofs-5.1.5-
> 10.fc30.x86_64, I see that at expire the symlink is removed but the
> mount point directory used for browsing isn't recreated.
> 
> I'll need to fix that.

That's the minor aspect (But of course appreciqated :).

> IIUC, the other aspect of this problem is that the target of the
> symlink, the NFSv4 mount, is also umounted at expire. That doesn't
> happen with the above Fedora package.

The target (in my example) is not an NFS mount at all, it's just normal
mountpoint, the target of the symlink (which in general might not be a but
mountpoint, in my case, is one).

The problem is that autofs calls umount on the symlink (in my example,
/fs/bp), but umount follows symlinks, so the target filesystem is unnmounted,
if it is a mountpoint.

I tried with debug logging, and it looks like this on kill -USR1:

   expiring path /fs/bp
   umount_multi: path /fs/bp incl 1
   umount_multi: removing symlink /fs/bp
   expired /fs/bp

When stracing, it literally execs umount /fs/bp:

   5463  execve("/bin/umount", ["/bin/umount", "/fs/bp"], 0x555b23a0 /* 20 
vars */) = 0

As explained earlier this only happens with misc-device support because
autofs thinks /fs/bp is a mountpoint as the kernel seems to follow
symlinks as well - without /dev/autofs it uses another method which
correctly finds that /fs/bp is not a mountpoint, so umount is never
called.

> This could get a bit complicated since there have been kernel
> changes as well as user space changes to the symlink handling
> with later version of autofs, we will need to work that out as
> we go.

I don't think it's a new bug (or change) in the kernel, as I remember
having had exactly this problem years ago (so long ago that I forgot about
it when confronted with the workaround, but it came back to me quickly).

But for the record, I am using linux 5.4.15.

The reason I didn't report it at the time was that I binary-patched the
debian package (with a regex-replace on mount_bind.so), and obviously all
bets are off with that method, and I didn't have time to reproduce it with
the pristine debian package, which I did now, however.

> Can you confirm this second part of the problem occurs with the
> Debian package your using please, then we can hunt for patches
> from later autofs releases.

It happens with the debian package I am using, yes.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#950211: python-virustotal-api fails autopkg test

[Sascha Steinbiss]

Hi Matthias,

>>> Or you remove the autodep8 test from debian/control.
>> Indeed that is what I changed in 1.1.11-2 which should be in both sid
>> and bullseye by now -- I changed the autopkgtest definition and added
>> custom test scripts reflecting the situation.
>> 
>> All tests are green so far now [3]. Where did you get your log snippet from?
> 
> http://autopkgtest.ubuntu.com/packages/p/python-virustotal-api/focal/amd64

But version 1.1.11-2 (without the ubuntu1 patch) also passes its autopkgtest in 
the list on that page (row 3)?

> that's what I changed, it's still in the control file.
> 
> http://launchpadlibrarian.net/462719068/python-virustotal-api_1.1.11-2_1.1.11-2ubuntu1.diff.gz

This would also only cause the CI to run the regular autopkgtest in 
debian/tests, instead of the failing Python-specific ones that assume a 
particular mapping from import name to package name. My change in 1.1.11-2 does 
the same:

diff --git a/debian/control b/debian/control
index 83a6cfe..6032eda 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: debhelper-compat (= 12),
python3-setuptools,
python3-requests
 Standards-Version: 4.5.0
-Testsuite: autopkgtest-pkg-python
+Testsuite: autopkgtest
 Vcs-Git: https://salsa.debian.org/debian/python-virustotal-api.git
 Vcs-Browser: https://salsa.debian.org/debian/python-virustotal-api
 Homepage: https://github.com/blacktop/virustotal-api

Plus adding a separate, explicit test setup in d/tests, of course.

I do not see where removing the Testsuite line would change anything compared 
to 1.1.11-2, given that the autopkgtest for that’s version passes even on 
Ubuntu’s CI. Am I missing something?

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP

Bug#948653: stretch-pu: package mod-gnutls/0.8.2-3+deb9u1

[Adrian Bunk]

Control: block -1 by 950300

On Tue, Jan 28, 2020 at 08:41:29AM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On 2020-01-11 10:34, Adrian Bunk wrote:
> >   * Avoid deprecated ciphersuites in test suite (Closes: #907008)
> > 
> > FTBFS, tests were broken by gnutls28 3.5.8-5+deb9u4.
> 
> Please go ahead.

The apache2 2.4.25-3+deb9u9 upgrade causes an unrelated FTBFS in 
mod-gnutls, which made 0.8.2-3+deb9u1 fail on the buildds.

Reported as #950300, this bug is present even in unstable.

Seems fixed in upstream 0.9.1.

I'll take care of this, but there is not enough time left to get this 
fixed for the upcoming stretch point release - I won't do a 0-day NMU 
for a just reported FTBFS in unstable.

> Regards,
> 
> Adam

cu
Adrian

Bug#784324: x11-xserver-utils: xrandr segfault

[Vincent Bernat]

Package: x11-xserver-utils
Version: 7.7+8
Followup-For: Bug #784324

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

I am also hit by xrandr segfaulting from time to time. I don't know if
I am in the same case as Steve (its coredump is too old to match
current binary), but I have traced my case to line 3900 of xrandr.c
and this is fixed in 1.5.1 upstream:

https://gitlab.freedesktop.org/xorg/app/xrandr/commit/9e5fa7c8c26f78e121ffad0d7a745a674c4a1849

Would it be possible to update xrandr to 1.5.1?

Thanks.

- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 
'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages x11-xserver-utils depends on:
ii  cpp  4:9.2.1-3.1
ii  libc62.29-9
ii  libice6  2:1.0.9-2
ii  libx11-6 2:1.6.8-1
ii  libxaw7  2:1.0.13-1+b2
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxi6   2:1.7.9-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxmuu1 2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxt6   1:1.1.5-1+b3
ii  libxxf86vm1  1:1.1.4-1+b2

x11-xserver-utils recommends no packages.

Versions of packages x11-xserver-utils suggests:
pn  cairo-5c
pn  nickle  
pn  xorg-docs-core  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4zyigSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5q4kP+gId6flDKvt8Bz23plaVkLEE5Ecz8uPB
tKyZzhMpK7ubiFmCHpVHs44wWYKXa/OLEL3HBgvy8IOQqIabjNvFho+aFICuWugs
0K0Y2abHMk5t8IqNy71P0sCrz5rq4DQBmDLLvIEDoWBA0KEGkOUlb1zUCg1AL40f
KdzHFuQrUVxcyNZhhp/WgKUKUMJbc8ycO+ZI/2+x0BqSIl/rU0bdAselGQKGifmK
7nmnDTfKI+Revq/mJIa+6LrUOfr1CoL7waNqOqhDFgjA7dPABnFDKnqbI9fEfROJ
mCX3SE/0ow5uGq8Wnl/JiZqQvbOtFirunUEgxqV+RMenjV+zQFjnTGBle0qbsn0K
AfM0pDdM1atOeWowHUbSGVwlktIo+/gtHDbvehBGHy+3s0aV4Mdazoaf4O9q3e07
2eiSxYQW55ZV7j57WH7RmxrovwS+f/6wtHitnkLPBw61ZvBHnSXOpoIFZKR+tY/G
C4+5o8cN1G9fcMBSrlLLcAwS8LwXC/7aoY1LD/gT/Jwq3H0kERCtCvbW8/DH6BOa
U+ZF53HG7G8ISDhztQWtL9HcSCouudsaHoZ4HLiRaqX7RHxvClDRg3OqwZ2WM2mB
N3eLhigC9VRB3MK3lmHDuY0cmmNEb2TGi23eBAdAKdsMvXKW9PSfyaqWhK73mTr3
v7f8knK1sVy8
=6LxZ
-END PGP SIGNATURE-

Bug#938797: volatility: Python2 removal in sid/bullseye

[Sandro Tosi]

On Thu, 16 Jan 2020 21:36:39 -0500 Sandro Tosi  wrote:
> On Sat, 19 Oct 2019 11:56:21 -0300 Eriberto  wrote:
> > Em sábado, 19 de outubro de 2019, Raphael Hertzog 
> > escreveu:
> >
> > > Control: tag -1 + fixed-upstream
> > >
> > > On Fri, 30 Aug 2019, Matthias Klose wrote:
> > > > Python2 becomes end-of-live upstream, and Debian aims to remove
> > > > Python2 from the distribution, as discussed in
> > > > https://lists.debian.org/debian-python/2019/07/msg00080.html
> > >
> > > There's a volatility 3.0 that works with Python 3:
> > > https://github.com/volatilityfoundation/volatility3
> > >
> > > We should package it! Putting in CC the uploaders of volatility.
> > >
> > >
> > Don't worry. I will update it soon.
>
> any update here?

another 2 weeks have passed with no progress; should we keep volatile
out of testing for the time being?

please note volatility is the last reverse dependency of
python-openpyxl, which would be great to drop.

if i dont hear anything within a week, i'll ask the release team to
kick volatile out of testing + file and RC bug to keep it out.

Cheers,
Sandro

Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail

[Mad Horse]

Furthermore, with --private=/foo/bar, how can I access the encrypted directories
under the real ${HOME}, which is even not introduced into jail anymore with
--private=/foo/bar ? 


在 2020/1/31 下午2:08, Mad Horse 写道:
> With --private=/foo/bar, configurations store under real ${HOME} becomes
> inaccessible,
>
> e.g.
>
>> $ firejail --allusers --private=/tmp/home/
>> --profile=/etc/firejail/firefox.profile /bin/bash
> so it is impractical (Please consider I am running profiled
> applications, rather than shell
>
> with default profile).
>
> Besides, although /home/.fscrypt appears inside jail, a tmpfs is mounted
>
> atop it, and --whitelist cannot be used to mount the real /home/.fscrypt
> there, for /home is
>
> not permitted top directory.
>
>
> 在 2020/1/31 上午7:55, Reiner Herrmann 写道:
>> On Sat, Jan 25, 2020 at 10:45:08PM +0800, Mad Horse wrote:
>>> I have not remembered that because --private is used so widely in
>>> officially shipped profiles, so I have to inspect them with command like
>>>
 $ firejail --profile=/etc/firejail/firefox.profile /bin/bash
>> Hm, I couldn't find "private" in the firefox(-common) profile.
>> Does it work if you start it by giving it a location where it can store
>> the private home directory?
>> Like: firejail --allusers --private=/foo/bar
>> (see also: 
>> https://github.com/netblue30/firejail/issues/3185#issuecomment-578413651 )
>>
>> Regards,
>>   Reiner
>

Bug#938656: texlive-extra: Python2 removal in sid/bullseye

[Sandro Tosi]

Dear TeX Maintainers,

On Fri, 30 Aug 2019 07:55:39 + Matthias Klose  wrote:
> Package: src:texlive-extra
> Version: 2019.20190824-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

could you please have a look at this bug soon? texlive-science is the
last reverse dependency of python-sympy, and be able to remove that
package would unlock several other packages removal.

thanks,
Sandro

Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail

[Mad Horse]

Sorry, it is --whitelist which also conflict with --allusers that appears
in most shipped profiles.

在 2020/1/25 下午10:39, Reiner Herrmann 写道:
> On Sat, Jan 25, 2020 at 10:30:50PM +0800, Mad Horse wrote:
>>> Warning: allusers option disabled by private or whitelist option
>> Because of this, inside jails started with private or whitelist options,
>> /home remains masked, so files encrypted with fscrypt remain inaccessible.
> Ok, so I assume that you are using --private (because whitelisting your
> home directory would not be needed)?

Bug#936952: lintian: Python2 removal in sid/bullseye

[Sandro Tosi]

Dear Lintian maintainers,

On Fri, 30 Aug 2019 07:24:56 + Matthias Klose  wrote:
> Package: src:lintian
> Version: 2.19.0
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

it looks like the python dependencies were introduced in 2.5.5 for:

+ [JW] Add Build-Dependency on python-numpy and python-all-dev
  for the test suite.

is there any chance you could migrate the test suite to python3
anytime soon? if i read the code correctly (be aware, it's 1am here,
conclusions may be fuzzy) it may be necessary to adapt the
`missing-dependency-on-numpy-abi` tag processing.

thanks,
Sandro

Bug#950300: mod-gnutls: apache CVE-2019-10092 fix causes FTBFS

[Adrian Bunk]

Source: mod-gnutls
Version: 0.8.2-3
Severity: serious
Tags: ftbfs

mod-gnutls appears to rely on the exact wording of apache
error messages, and these changed with CVE-2019-10092.

https://buildd.debian.org/status/package.php?p=mod-gnutls=stretch
https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/mod-gnutls.html

...
FAIL: test-18_client_verification_wrong_cert


TESTING: 18_client_verification_wrong_cert
Server version: Apache/2.4.38 (Debian)
Server built:   2019-10-15T19:53:42
Server's Module Magic Number: 20120211:84
Server loaded:  APR 1.6.5, APR-UTIL 1.6.1
Compiled using: APR 1.6.5, APR-UTIL 1.6.1
Architecture:   64-bit
Server MPM: worker
  threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"
[Mon Jan 27 07:56:11.674982 2020] [gnutls:debug] [pid 45519:tid 
139910356628608] gnutls_cache.c(354): mgs_cache_inst_config: Socache 
'shmcb:cache/gnutls_cache_18_client_verification_wrong_cert(65536)' created.
AH00557: apache2: apr_sockaddr_info_get() failed for profitbricks-build11-amd64
AH00558: apache2: Could not reliably determine the server's fully qualified 
domain name, using 127.0.0.1. Set the 'ServerName' directive globally to 
suppress this message
flock: getting lock took 1.910177 seconds
flock: executing /usr/sbin/apache2
Processed 1 CA certificate(s).
Processed 1 client X.509 certificates...
Resolving 'localhost:9932'...
Connecting to '127.0.0.1:9932'...
- Successfully sent 1 certificate(s) to server.
- Server has requested a certificate.
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=localhost', issuer `CN=Testing Authority', serial 0x22fff0d9, 
RSA key 3072 bits, signed using RSA-SHA256, activated `2020-01-27 19:56:05 
UTC', expires `2021-01-26 19:56:05 UTC', 
pin-sha256="ShqMB70z9iMRONejdL+6v98HfExpZp/aWi6nXzD6vJE="
Public Key ID:
sha1:7bb678f9fe68cd7ed0fd1df39e9aebad4eee2b94

sha256:4a1a8c07bd33f6231138d7a374bfbabfdf077c4c69669fda5a2ea75f30fabc91
Public Key PIN:
pin-sha256:ShqMB70z9iMRONejdL+6v98HfExpZp/aWi6nXzD6vJE=

- Status: The certificate is trusted. 
- Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Options:
- Handshake was completed

- Simple Client Mode:

HTTP/1.1 403 Forbidden
Date: Mon, 27 Jan 2020 19:56:11 GMT
Server: Apache/2.4.38 (Debian) mod_gnutls/0.9.0 GnuTLS/3.6.7
Content-Length: 199
Connection: close
Content-Type: text/html; charset=iso-8859-1



403 Forbidden

Forbidden
You don't have permission to access this resource.

- Peer has closed the GnuTLS connection
  PID TTY  TIME CMD
45530 ?00:00:00 sleep
--- /build/mod-gnutls-0.9.0/test/tests/18_client_verification_wrong_cert/output 
2017-02-28 07:05:55.0 -1200
+++ /dev/fd/63  2020-01-27 07:56:11.809997988 -1200
@@ -1,7 +1,7 @@
+
+403 Forbidden
 
 Forbidden
-You don't have permission to access /test.txt
-on this server.
-
+You don't have permission to access this resource.
 
 - Peer has closed the GnuTLS connection
FAILURE: 18_client_verification_wrong_cert
[Mon Jan 27 07:56:11.869868 2020] [gnutls:debug] [pid 45630:tid 
139891390706816] gnutls_cache.c(354): mgs_cache_inst_config: Socache 
'shmcb:cache/gnutls_cache_18_client_verification_wrong_cert(65536)' created.
AH00557: apache2: apr_sockaddr_info_get() failed for profitbricks-build11-amd64
AH00558: apache2: Could not reliably determine the server's fully qualified 
domain name, using 127.0.0.1. Set the 'ServerName' directive globally to 
suppress this message

Apache error logs:
[Mon Jan 27 07:56:11.697229 2020] [mpm_worker:debug] [pid 45520:tid 
139910356628608] worker.c(1758): AH00294: Accept mutex: sysvsem (default: 
sysvsem)
[Mon Jan 27 07:56:11.697257 2020] [watchdog:debug] [pid 45523:tid 
139910356628608] mod_watchdog.c(567): AH02980: Watchdog: nothing configured?
[Mon Jan 27 07:56:11.697509 2020] [watchdog:debug] [pid 45525:tid 
139910356628608] mod_watchdog.c(567): AH02980: Watchdog: nothing configured?
[Mon Jan 27 07:56:11.710332 2020] [gnutls:debug] [pid 45523:tid 
139910314034944] gnutls_hooks.c(1072): [client 127.0.0.1:43624] early_sni_hook: 
Selected virtual host localhost from early SNI, connection server is localhost.
[Mon Jan 27 07:56:11.785399 2020] [gnutls:debug] [pid 45523:tid 
139910314034944] gnutls_io.c(535): [client 

Bug#950301: mod-gnutls FTBFS: ERROR: Cipher suites mismatching or missing!

[Adrian Bunk]

Source: mod-gnutls
Version: 0.9.0-1
Severity: serious
Tags: ftbfs bullseye sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mod-gnutls.html

...
ERROR: Cipher suites mismatching or missing!
Server: '(TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)'
Client: '(TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)'
FAIL test-16_view-status.bash (exit status: 1)

Bug#950299: RM: pygts -- ROM; dead upstream, no Python 3 support

[Stuart Prescott]

Package: ftp.debian.org
Severity: normal

As discussed in #937455, pygts is no longer developed upstream and has not
been ported to Python 3. It can be removed from Debian.

thanks
Stuart

Bug#947995: ncbi-entrez-direct: ncbi-entrez-direct FTBFS in testing/unstable

[Andreas Tille]

Hi Aaron,

I used routine-update[1] to update the packaging of ncbi-entrez-direct.
Since this includes a new upstream version I'm hesitating with uploading
and thus stopped working on this bug.

The build now fails with

...
dh_auto_build
install amino-acid-composition archive-pubmed between-two-genes 
entrez-phrase-search fetch-pubmed filter-stop-words index-pubmed 
intersect-uid-lists join-into-groups-of pm-* protein-neighbors reorder-columns 
sort-uniq-count* stream-pubmed word-at-a-time xy-plot debian/efetch 
debian/einfo bin/
mkdir -p 
/build/ncbi-entrez-direct-13.3.20200128+ds/obj-x86_64-linux-gnu/src/github.com/fiam
ln -s ../rainycape 
/build/ncbi-entrez-direct-13.3.20200128+ds/obj-x86_64-linux-gnu/src/github.com/fiam/gounidecode
go build -v -gccgoflags '-g -O2 
-fdebug-prefix-map=/build/ncbi-entrez-direct-13.3.20200128+ds=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,-z,now -Wl,--as-needed' -o bin/xtract \
xtract.go common.go
failed to initialize build cache at /nonexistent/.cache/go-build: mkdir 
/nonexistent: permission denied
make[1]: *** [debian/rules:84: override_dh_auto_build] Error 1
...


I think that's just a matter of setting $HOME to something sensible and
is probably less than 10min work for you.  Could you please take over
from here?

Kind regards

  Andreas.


[1] 
https://salsa.debian.org/r-pkg-team/maintenance-utilities/blob/master/routine-update

-- 
http://fam-tille.de

Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail

[Mad Horse]

With --private=/foo/bar, configurations store under real ${HOME} becomes
inaccessible,

e.g.

> $ firejail --allusers --private=/tmp/home/
> --profile=/etc/firejail/firefox.profile /bin/bash

so it is impractical (Please consider I am running profiled
applications, rather than shell

with default profile).

Besides, although /home/.fscrypt appears inside jail, a tmpfs is mounted

atop it, and --whitelist cannot be used to mount the real /home/.fscrypt
there, for /home is

not permitted top directory.


在 2020/1/31 上午7:55, Reiner Herrmann 写道:
> On Sat, Jan 25, 2020 at 10:45:08PM +0800, Mad Horse wrote:
>> I have not remembered that because --private is used so widely in
>> officially shipped profiles, so I have to inspect them with command like
>>
>>> $ firejail --profile=/etc/firejail/firefox.profile /bin/bash
> Hm, I couldn't find "private" in the firefox(-common) profile.
> Does it work if you start it by giving it a location where it can store
> the private home directory?
> Like: firejail --allusers --private=/foo/bar
> (see also: 
> https://github.com/netblue30/firejail/issues/3185#issuecomment-578413651 )
>
> Regards,
>   Reiner

Bug#950287: autofs: automount expriing unmounts target filesystem

[Ian Kent]

On Fri, 2020-01-31 at 13:34 +0800, Ian Kent wrote:
> On Fri, 2020-01-31 at 01:09 +0100, Marc Lehmann wrote:
> > On Thu, Jan 30, 2020 at 11:50:32PM +, Mike Gabriel <
> > sunwea...@debian.org> wrote:
> > > This seems like something to be discussed upstream. I Cc:ed Ian
> > > Kent, maybe
> > > he has some 2? to add.
> > 
> > Cool!
> > 
> > In the meantime, I digged a bit more, and it seems that it is
> > because
> > with
> > misc-device support, autofs uses the AUTOFS_DEV_IOCTL_ISMOUNTPOINT
> > ioctl
> > to check whether something is a mountpoint, which returns 1, which
> > causes
> > the code in umount_multi to decude it cannot be symlink and
> > unmounting it.
> > 
> > Indeed, rm /dev/autofs before starting autofs makes it partially
> > work
> > (the
> > target dir is not unmounted, but the entry is still gone without
> > ghosting).
> > 
> > Upstream probably already knows this, of course.
> 
> Upstream doesn't know about this, ;)
> 
> The behaviour is not correct and needs to be fixed.
> 
> Sounds like I have enough information to duplicate the problem so
> I'll have a look see.

A quick test with the current Fedora autofs package, autofs-5.1.5-
10.fc30.x86_64, I see that at expire the symlink is removed but the
mount point directory used for browsing isn't recreated.

I'll need to fix that.

IIUC, the other aspect of this problem is that the target of the
symlink, the NFSv4 mount, is also umounted at expire. That doesn't
happen with the above Fedora package.

This could get a bit complicated since there have been kernel
changes as well as user space changes to the symlink handling
with later version of autofs, we will need to work that out as
we go.

Can you confirm this second part of the problem occurs with the
Debian package your using please, then we can hunt for patches
from later autofs releases.

Ian

Bug#950296: clamav-daemon.config

[Cash]

It looks like the problem is caused by the change to clamav-daemon.config
when ScanOnAccess was removed.

I believe line 561 should have an extra option

StateGeneric low clamav-daemon/LogRotate LogFile

Something like

StateGeneric low clamav-daemon/LogRotate OnAccessMaxFileSize LogFile

Bug#950287: autofs: automount expriing unmounts target filesystem

[Ian Kent]

On Fri, 2020-01-31 at 13:34 +0800, Ian Kent wrote:
> On Fri, 2020-01-31 at 01:09 +0100, Marc Lehmann wrote:
> > On Thu, Jan 30, 2020 at 11:50:32PM +, Mike Gabriel <
> > sunwea...@debian.org> wrote:
> > > This seems like something to be discussed upstream. I Cc:ed Ian
> > > Kent, maybe
> > > he has some 2? to add.
> > 
> > Cool!
> > 
> > In the meantime, I digged a bit more, and it seems that it is
> > because
> > with
> > misc-device support, autofs uses the AUTOFS_DEV_IOCTL_ISMOUNTPOINT
> > ioctl
> > to check whether something is a mountpoint, which returns 1, which
> > causes
> > the code in umount_multi to decude it cannot be symlink and
> > unmounting it.
> > 
> > Indeed, rm /dev/autofs before starting autofs makes it partially
> > work
> > (the
> > target dir is not unmounted, but the entry is still gone without
> > ghosting).
> > 
> > Upstream probably already knows this, of course.
> 
> Upstream doesn't know about this, ;)
> 
> The behaviour is not correct and needs to be fixed.
> 
> Sounds like I have enough information to duplicate the problem so
> I'll have a look see.

Oh, as usual, what's the autofs source version of your package please,
since I'll be using the current development source to work on it.

> 
> Thanks for the report
> Ian

Bug#950287: autofs: automount expriing unmounts target filesystem

[Ian Kent]

On Fri, 2020-01-31 at 01:09 +0100, Marc Lehmann wrote:
> On Thu, Jan 30, 2020 at 11:50:32PM +, Mike Gabriel <
> sunwea...@debian.org> wrote:
> > This seems like something to be discussed upstream. I Cc:ed Ian
> > Kent, maybe
> > he has some 2? to add.
> 
> Cool!
> 
> In the meantime, I digged a bit more, and it seems that it is because
> with
> misc-device support, autofs uses the AUTOFS_DEV_IOCTL_ISMOUNTPOINT
> ioctl
> to check whether something is a mountpoint, which returns 1, which
> causes
> the code in umount_multi to decude it cannot be symlink and
> unmounting it.
> 
> Indeed, rm /dev/autofs before starting autofs makes it partially work
> (the
> target dir is not unmounted, but the entry is still gone without
> ghosting).
> 
> Upstream probably already knows this, of course.

Upstream doesn't know about this, ;)

The behaviour is not correct and needs to be fixed.

Sounds like I have enough information to duplicate the problem so
I'll have a look see.

Thanks for the report
Ian

Bug#950298: Please fix several problem (bug) in dnscrypt-proxy package

[Andrey Nikitushkin]

Package: dnscrypt-proxy
Version: 2.0.19

Hello, friends!
I resolve problem in installation package "dnscrypt-proxy". This package 
contains an incorrect command to start the /etc/init.d/dnscrypt-proxy 
service in the executable file:

/cmd="/usr/sbin/dnscrypt-proxy -c /etc/dnscrypt-proxy/dnscrypt-proxy.toml"/
The service launch command should be:
/cmd="/usr/sbin/dnscrypt-proxy -config 
/etc/dnscrypt-proxy/dnscrypt-proxy.toml"/



*Developers, please fix this problem. Without fixing this problem in the 
"dnscrypt-proxy" installation package, this package is not installed 
using the "apt" package installer.*



*Thanks you!*

Please fix another problem with package "dnscrypt-proxy". Please add the 
following lines to the start service script of the 
/etc/init.d/dnscrypt-proxy:

/
if  [ ! -d /var/cache/dnscrypt-proxy/ ]; then
        mkdir /var/cache/dnscrypt-proxy
fi
/

This is fix the problem with downloading source public-resolvers from 
https://download.dnscrypt.info


*Developers, please add these changes to the "dnscrypt-proxy" 
installation package.*


*
*

*Please see: https://dev1galaxy.org/viewtopic.php?id=3292
*

--

С наилучшими пожеланиями, Никитушкин Андрей!
Тел.(сот.): +79063975544

Bug#937129: netifaces: diff for NMU version 0.10.9-0.2

[Sandro Tosi]

Control: tags 937129 + patch


Dear maintainer,

I've prepared an NMU for netifaces (versioned as 0.10.9-0.2). The diff
is attached to this message.

Regards.

diff -Nru netifaces-0.10.9/debian/changelog netifaces-0.10.9/debian/changelog
--- netifaces-0.10.9/debian/changelog	2019-11-25 11:16:02.0 -0500
+++ netifaces-0.10.9/debian/changelog	2020-01-31 00:43:09.0 -0500
@@ -1,3 +1,10 @@
+netifaces (0.10.9-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937129
+
+ -- Sandro Tosi   Fri, 31 Jan 2020 00:43:09 -0500
+
 netifaces (0.10.9-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru netifaces-0.10.9/debian/control netifaces-0.10.9/debian/control
--- netifaces-0.10.9/debian/control	2019-11-25 11:16:02.0 -0500
+++ netifaces-0.10.9/debian/control	2020-01-31 00:39:47.0 -0500
@@ -8,9 +8,6 @@
 Build-Depends:
  debhelper (>= 9),
  dh-python,
- python-all-dbg,
- python-all-dev,
- python-setuptools,
  python3-all-dbg,
  python3-all-dev,
  python3-setuptools,
@@ -19,39 +16,6 @@
 Vcs-Browser: https://salsa.debian.org/python-team/modules/netifaces
 Homepage: http://alastairs-place.net/projects/netifaces/
 
-Package: python-netifaces
-Architecture: any
-Depends:
- ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends},
-Provides:
- ${python:Provides},
-XB-Python-Version: ${python:Versions}
-Description: portable network interface information - Python 2.x
- netifaces provides a (hopefully portable-ish) way for Python programmers to
- get access to a list of the network interfaces on the local machine, and to
- obtain the addresses of those network interfaces.
- .
- This package contains the module for Python 2.x.
-
-Package: python-netifaces-dbg
-Section: debug
-Priority: extra
-Architecture: any
-Depends:
- python-dbg,
- python-netifaces (= ${binary:Version}),
- ${misc:Depends},
- ${shlibs:Depends},
-XB-Python-Version: ${python:Versions}
-Description: portable network interface information - Python 2.x debug extension
- netifaces provides a (hopefully portable-ish) way for Python programmers to
- get access to a list of the network interfaces on the local machine, and to
- obtain the addresses of those network interfaces.
- .
- This package contains debug symbols of python-netifaces.
-
 Package: python3-netifaces
 Architecture: any
 Depends:
diff -Nru netifaces-0.10.9/debian/python-netifaces.install netifaces-0.10.9/debian/python-netifaces.install
--- netifaces-0.10.9/debian/python-netifaces.install	2018-04-02 16:08:38.0 -0400
+++ netifaces-0.10.9/debian/python-netifaces.install	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-usr/lib/python2.*/*/*.egg-info
-usr/lib/python2.*/*/netifaces.so
diff -Nru netifaces-0.10.9/debian/rules netifaces-0.10.9/debian/rules
--- netifaces-0.10.9/debian/rules	2019-11-25 11:16:02.0 -0500
+++ netifaces-0.10.9/debian/rules	2020-01-31 00:40:57.0 -0500
@@ -1,42 +1,33 @@
 #!/usr/bin/make -f
 
 
-PYVERS = $(shell pyversions -vr)
-PYVERSION = $(shell pyversions -vd)
+PY3VERSION = $(shell py3versions -vd)
 PY3VERS = $(shell py3versions -vr)
 
 
 %:
-	dh $@ --with=python2,python3
+	dh $@ --with=python3 --buildsystem=pybuild
 
 override_dh_auto_clean:
 	rm -rf $(CURDIR)/build
 	dh_auto_clean
 
-override_dh_auto_build:
-	set -ex && for pyvers in $(PYVERS) $(PY3VERS); do \
-		python$$pyvers setup.py build; \
-		python$$pyvers-dbg setup.py build; \
-	done
-
-override_dh_auto_install:
-	set -ex && for pyvers in $(PYVERS) $(PY3VERS); do \
-		python$$pyvers setup.py install --install-layout=deb --root $(CURDIR)/debian/tmp; \
-		python$$pyvers-dbg setup.py install --install-layout=deb --root $(CURDIR)/debian/tmp; \
-	done
+
+#override_dh_auto_install:
+#	set -ex && for pyvers in $(PYVERS) $(PY3VERS); do \
+#		python$$pyvers setup.py install --install-layout=deb --root $(CURDIR)/debian/tmp; \
+#		python$$pyvers-dbg setup.py install --install-layout=deb --root $(CURDIR)/debian/tmp; \
+#	done
 
 override_dh_installdocs:
 	dh_installdocs
-	rm -rf debian/python-netifaces-dbg/usr/share/doc/python-netifaces-dbg
-	ln -s python-netifaces debian/python-netifaces-dbg/usr/share/doc/python-netifaces-dbg
 
 	rm -rf debian/python3-netifaces-dbg/usr/share/doc/python3-netifaces-dbg
 	ln -s python3-netifaces debian/python3-netifaces-dbg/usr/share/doc/python3-netifaces-dbg
 
 
 override_dh_strip:
-	dh_strip -X"python3" --dbg-package=python-netifaces-dbg
-	dh_strip -X"python2" --dbg-package=python3-netifaces-dbg
+	dh_strip --dbg-package=python3-netifaces-dbg
 
 override_dh_python3:
 	find debian/python3-netifaces -name 'netifaces.cpython-*d*-$(DEB_HOST_MULTIARCH).so' | xargs -r rm -f

Bug#936566: fs-uae: Python2 removal in sid/bullseye - reopen 936566

[Sandro Tosi]

On Thu, Jan 30, 2020 at 2:31 AM John Paul Adrian Glaubitz
 wrote:
>
> Hello!
>
> Thanks for notifying me.
>
> On 1/19/20 3:23 AM, Sandro Tosi wrote:
> > This bug was closed, but the package has still some dependencies towards
> > Python2 packages, in details:
> >
> > (binary:fs-uae-arcade)Recommends->python-lhafile
>
> FWIW, a Recommends is not the same as a Dependency meaning that
> if a Recommends is not available it won't get installed.

hm are you sure you're not mixing Recommends and Suggests? also note
that Recommends are installed by default nowadays.

> And, secondly, python-lhafile was never part of Debian. The Recommends
> he is just an artifact from the upstream packaging code. It was never
> used in any way.
>
> > Re-opening, so that they can be taken care of.
>
> I understand. But I don't this the severity "serious" is justified
> in this case.

ok, can you fix it then? you make it sound pretty easy so can you just
go ahead and address it? as per the severity, please check the
reference in the first severity bump email.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Hi,

Quoting Francesco Poli (2020-01-30 23:41:11)
> On Thu, 30 Jan 2020 01:26:09 +0100 Johannes Schauer wrote:
> > the problem is fixed when TMPDIR gets unset for hook.
> Wait, does this change the result?
> 
> I mean: some commands executed (directly or indirectly) by
> setup-testbed perform operations on the directory which mmdebstrap set
> up as TMPDIR.
> If this is the case (as I think it is, at least for the udev hook
> called by update-initramfs), I wonder whether unsetting TMPDIR causes
> setup-testbed to perform some of its operations on the wrong directory...
> 
> Am I completely off-track?

in your case, TMPDIR was a relative path. It doesn't even matter whether the
script reading TMPDIR runs inside or outside the chroot. That script might
change its working directory to anywhere during its operation. If it then tries
to access a file that expects to be in $TMPDIR it will obviously not find it
because it changed working directory.

Another scenario: imagine you set TMPDIR to an absolute path outside the
chroot. Naturally, that path is not available inside the chroot and programs
inside the chroot might fail when they try to store data into the non-existing
TMPDIR.

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.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#950297: libyaml-syck-perl FTCBFS: compiler check too strict

[Helmut Grohne]

Source: libyaml-syck-perl
Version: 1.32-1
Tags: upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libyaml-syck-perl fails to cross build from source even after you
updated its Build-Depends. It happens to fail while running its
Makefile.PL:

|dh_auto_configure -a
| perl -I/usr/lib/aarch64-linux-gnu/perl/cross-config-5.30.0 
Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"LD=aarch64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,-z,now"
| Couldn't load HASCOMPILERsEl9/TESTr0el.so: 
/<>/HASCOMPILERsEl9/TESTr0el.so: cannot open shared object file: 
No such file or directory at ./inc/ExtUtils/HasCompiler.pm line 141.
|  at Makefile.PL line 8.
| Sorry! YAML::Syck requires a compiler in order to be built.
| dh_auto_configure: error: perl 
-I/usr/lib/aarch64-linux-gnu/perl/cross-config-5.30.0 Makefile.PL 
INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" "LD=aarch64-linux-gnu-gcc -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z,relro -Wl,-z,now" returned exit code 1
| make: *** [debian/rules:6: build-arch] Error 25
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

libyaml-syck-perl has a inc/ExtUtils/HasCompiler.pm that is used for
checking whether the compiler can build a loadable module. That fails. I
think the failure is to be expected, because a cross compiled object
cannot be loaded into the native perl. Once removing the "exit 1;" from
Makefile.PL line 11, libyaml-syck-perl cross builds just fine. So it
really is just this check.

I'd assume that simply patching it out does not suit well with upstream.
After all, they put it there for a reason. Unfortunately, I have little
clue how to express a "if cross compiling" in perl. Do you have any idea
on how to fix this?

I was also wondering about many warnings during the build:
| warning: incompatible implicit declaration of built-in function ‘malloc’
The source does #include  if HAVE_STDLIB_H is set. This macro
is set if I_STDLIB is set somewhere, but nothing ever sets it. This
behaviour is also present in native builds, see e.g.:
https://buildd.debian.org/status/fetch.php?pkg=libyaml-syck-perl=ppc64el=1.32-1=1580299988=0
This hints that something else is broken about configuration of
libyaml-syck-perl. I'm merely reporting it as this observation here and
hope that it helps somehow.

Can you think of a good way to disable or fix this test for cross
compilation? Given that I don't have a good answer here, I don't have a
patch this time.

Helmut

Bug#944040: haveged requires debhelper >= 12.5

[Nicolas Braud-Santoni]

Control: retitle -1 haveged requires debhelper >= 12.5
Control: tag -1 + moreinfo

Hi Daniel,

On Sun, Nov 03, 2019 at 09:43:07AM +0100, Daniel Baumann wrote:
> haveged 1.9.8-1 FTBFS on stable because it requires debhelper >= 12.5
> without declaring so.

I'm not able to reproduce your issue; I literally just made a backport
without changing the original package (except for the d/changelog entry),
which built fine in my buster-backports environment.

I might upload it later, but I would need to test it first, especially as it
includes some rather-invasive changes in the systemd unit's security
configuration that I only landed now in unstable.


Could you include the full build log, including the commands used for the build?

In particular, could the issue be that you are trying to run `dh clean` outside
the build environment?  If you use sbuild, try passing --no-clean-source to
avoid doing that (git-buildpackage already ensures the source is clean).


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#950296: noninteractive loop

[Cash]

Works when LogFile is set to `none`

root@7f0bd3ca0e58:~# cat /etc/clamav/clamd.conf | grep LogFile
LogFile none
LogFileUnlock false
LogFileMaxSize 0
root@7f0bd3ca0e58:~# time DEBIAN_FRONTEND=noninteractive
DEBCONF_NONINTERACTIVE_SEEN=true dpkg-reconfigure clamav-daemon
invoke-rc.d: could not determine current runlevel
invoke-rc.d: policy-rc.d denied execution of restart.

real 0m0.949s
user 0m0.260s
sys 0m0.030s



However, when logfile is populated, dpkg-reconfigure hangs forever, here I
^C after 30 seconds.

root@7f0bd3ca0e58:~# cat /etc/clamav/clamd.conf | grep LogFile
LogFile /var/log/clamav/clamav.log
LogFileUnlock false
LogFileMaxSize 0
root@7f0bd3ca0e58:~# time DEBIAN_FRONTEND=noninteractive
DEBCONF_NONINTERACTIVE_SEEN=true dpkg-reconfigure clamav-daemon
^C

real 0m34.909s
user 0m23.450s
sys 0m9.110s

Bug#923387: udisks2: Please support new logind virtual packages

[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.

Yours,
Benda

Bug#950296: clamav-daemon: dpkg-reconfigure clamav-daemon infinate loop on log file input

[Cash Williams]

Package: clamav-daemon
Version: 0.102.1+dfsg-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   
   running `dpkg-reconfigure clamav-daemon` and entering the prompts.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   Providing a log file creates an infinte loop:

   Log file for clamav-daemon (enter none to disable): 
/var/log/clamav/clamav.log
   Do you want to log time information with each message? [yes/no] yes
   Do you want to enable log rotation? [yes/no] yes
   Log file for clamav-daemon (enter none to disable): 
/var/log/clamav/clamav.log
   Do you want to log time information with each message? [yes/no] yes
   Do you want to enable log rotation? [yes/no] yes
   Log file for clamav-daemon (enter none to disable): 
/var/log/clamav/clamav.log
   Do you want to log time information with each message? [yes/no] yes
   Do you want to enable log rotation? [yes/no] yes
   Log file for clamav-daemon (enter none to disable): 
/var/log/clamav/clamav.log
   Do you want to log time information with each message? [yes/no] yes
   Do you want to enable log rotation? [yes/no] yes
   Log file for clamav-daemon (enter none to disable): 
/var/log/clamav/clamav.log
   Do you want to log time information with each message? [yes/no] yes
   Do you want to enable log rotation? [yes/no] yes
   Log file for clamav-daemon (enter none to disable): 
/var/log/clamav/clamav.log
   Do you want to log time information with each message? [yes/no] no
   Do you want to enable log rotation? [yes/no] no
   Log file for clamav-daemon (enter none to disable): none
   During the SelfCheck the daemon checks if it needs to reload the virus 
database. It also tries to repair problems caused by bugs in the
   daemon, (that is, in some cases it's able to repair broken data structures).

   * What was the outcome of this action?
   * What outcome did you expect instead?


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "30"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog 

Bug#950295: gnome-keyring: uses MD5

[brian m. carlson]

Package: gnome-keyring
Version: 3.34.0-1
Severity: normal
Tags: security

gnome-keyring makes copious use of MD5.  It hashes attributes with it
and uses it as an integrity check in the encrypted data.  Unfortunately,
MD5 is, according to CMU, “cryptographically broken and unsuitable for
further use.”  It has been known to be insecure since at least 2004.

While it is true that MD5 is not practically vulnerable to preimage
attacks, gnome-keyring cannot make assumptions about the data that it
may be asked to store and therefore cannot rule out collisions as an
attack vector.  Additionally, MD5 is so weak and has been for so long
that its use is a major cryptographic red flag.

gnome-keyring should transition to algorithms which are not broken.
SHA-2, SHA-3, and BLAKE2 are all valid options for secure, robust hash
algorithms, and BLAKE2 is faster than MD5, in the unlikely situation
upstream feels performance is a concern.  Moreover, libgcrypt supports
all of these options.

While the upgrade is taking place, it may be prudent to consider using a
MAC (such as HMAC with a suitably secure algorithm) as an integrity
check instead of an encrypted hash.  This allows the integrity check to
occur before any data is decrypted and is in line with best practices
that encourage using encrypt-then-mac.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-keyring depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  dconf-gsettings-backend [gsettings-backend]   0.34.0-2
ii  gcr   3.34.0-1
ii  libc6 2.29-9
ii  libcap-ng00.7.9-2.1+b1
ii  libcap2-bin   1:2.27-1
ii  libgck-1-03.34.0-1
ii  libgcr-base-3-1   3.34.0-1
ii  libgcrypt20   1.8.5-3
ii  libglib2.0-0  2.62.4-1+b1
ii  p11-kit   0.23.20-1
ii  pinentry-gnome3   1.1.0-3+b1

Versions of packages gnome-keyring recommends:
ii  gnome-keyring-pkcs11  3.34.0-1
ii  libpam-gnome-keyring  3.34.0-1

gnome-keyring suggests no packages.

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#949385: cacti: Cacti fails under PHP-FPM

[Adam Thompson]

The reason we’re running php-7.4 is because I screwed up; I enabled the entire 
backports repo instead of selecting individual packages from it.
Given that this is the Nth time I’ve done this or seen it done, I suspect it’s 
a reasonably common scenario/mistake.
-Adam

Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Felipe Sateler]

On Thu, Jan 30, 2020 at 6:40 PM Michael Biebl  wrote:

> Hi Felipe
>
> Am 30.01.20 um 22:30 schrieb Felipe Sateler:
> >
> >
> > On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl  > > wrote:
> >
> > Am 28.01.20 um 17:27 schrieb Ansgar:
> > > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
> > >> Am 28.01.20 um 14:59 schrieb Ansgar:
> > >>> I tried linking systemd-{sysusers,tmpfiles} statically against
> > >>> systemd's private library earlier this month.  It increases the
> > >>> binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
> > >>> systemd that is just one percent).
> > >>
> > >> Is that 100K per binary?
> > >
> > > I checked my notes at it was 100 kB per binary: they are 212 kB
> larger
> > > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested with
> > > systemd 243-8.
> > >
> > > It might be possible to make it a bit smaller if one was to somehow
> > > link libsystemd0 for functions available there (libsystemd-shared
> > > currently duplicates those).
> >
> >
> > That is not possible. There is global state that is not to be shared.
> > See https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
>
> What's your thought on how to solve this libsystemd-shared issue should
> we consider splitting out systemd-{sysusers,tmpfiles}
>
> - link statically (and carry a downstream patch for eternity)
> - move libsystemd-shared to systemd-utils and risk the breakage that can
> result from a partial/aborted upgrade
> - copy, instead of move, the binaries + libsystemd-shared and make the
> resulting systemd-utils package Conflict with systemd (instead of having
> systemd depend on systemd-utils)
> - something else?
>

I tried linking statically the "can run without systemd-pid1 tools" with
the attached patch.

Disk usage appears to increase by about 400 kb:
% dpkg --info systemd_244.1-1_amd64.deb|grep Installed

 Installed-Size: 13908
% dpkg --info ../systemd_244-3_amd64.deb|grep Installed
 Installed-Size: 14319

Maybe upstream can be persuaded to merge something like this?

-- 

Saludos,
Felipe Sateler
diff --git a/meson.build b/meson.build
index b8dff8cd94..39cef6b301 100644
--- a/meson.build
+++ b/meson.build
@@ -1493,6 +1493,29 @@ make_autosuspend_rules_py = find_program('tools/make-autosuspend-rules.py')
 
 
 
+
+libutil = static_library(
+'util',
+[
+'src/shared/acl-util.c',
+'src/shared/enable-mempool.c',
+'src/shared/id128-print.c',
+'src/shared/pager.c',
+'src/shared/path-lookup.c',
+'src/shared/pretty-print.c',
+'src/shared/spawn-ask-password-agent.c',
+'src/shared/spawn-polkit-agent.c',
+'src/shared/specifier.c',
+'src/shared/sysctl-util.c',
+'src/shared/sysctl-util.h',
+'src/shared/tmpfile-util-label.c',
+'src/shared/uid-range.c',
+'src/shared/verbs.c',
+] + id128_sources,
+link_with: [libbasic, libsystemd_static],
+include_directories: includes
+)
+
 # binaries that have --help and are intended for use by humans,
 # usually, but not always, installed in /bin.
 public_programs = []
@@ -1537,6 +1560,7 @@ test_dlopen = executable(
 include_directories : includes,
 link_with : [libbasic],
 dependencies : [libdl],
+b_lto: false,
 build_by_default : want_tests != 'false')
 
 foreach tuple : [['myhostname', 'ENABLE_NSS_MYHOSTNAME'],
@@ -2407,7 +2431,7 @@ install_data('src/sleep/sleep.conf',
 exe = executable('systemd-sysctl',
  'src/sysctl/sysctl.c',
  include_directories : includes,
- link_with : [libshared],
+ link_with : [libutil],
  install_rpath : rootlibexecdir,
  install : true,
  install_dir : rootlibexecdir)
@@ -2440,7 +2464,7 @@ public_programs += exe
 exe = executable('systemd-escape',
  'src/escape/escape.c',
  include_directories : includes,
- link_with : [libshared],
+ link_with : [libutil],
  install_rpath : rootlibexecdir,
  install : true,
  install_dir : rootbindir)
@@ -2474,7 +2498,7 @@ executable('systemd-cgroups-agent',
 exe = executable('systemd-id128',
  'src/id128/id128.c',
  include_directories : includes,
- link_with : [libshared],
+ link_with : [libutil],
  install_rpath : rootlibexecdir,
  install : true)
 public_programs += exe
@@ -2482,7 +2506,7 @@ public_programs += exe
 exe = executable('systemd-path',
  'src/path/path.c',
  include_directories 

Bug#936617: Updated on salsa; pending upload

[Philippe Mathieu-Daudé]

Hi Jelmer,

On Thu, Jan 30, 2020 at 3:27 PM Jelmer Vernooij  wrote:
>
> It looks like this package has been ported to Python 3, but has not
> yet been uploaded. The last changelog entry on salsa
> (https://salsa.debian.org/philmd-guest/git-publish.git) says:
>
> git-publish (1.5.1-1) UNRELEASED; urgency=medium
>
>   * Non-maintainer upload.
>   * Update to git-publish 1.5.1:
> - few bugfixes
> - added more options
> - use Python3
>
>  -- Philippe Mathieu-Daudé   Fri, 06 Dec 2019 15:53:10 +0100
>
> Philippe, would you like me to sponsor an upload of the package?

This is very kind of you!

I updated to git-publish 1.6.0 about a month ago, but then got
distracted when looking for a sponsor...
So your help is very much appreciated :)

I tested/pushed in this branch:
https://salsa.debian.org/philmd-guest/git-publish/tree/debian-v1.6.0
All the CI passed:
https://salsa.debian.org/philmd-guest/git-publish/pipelines/98389

>From here I'm not sure if this is correct (should I use another branch? 
>master?)
Is this enough for you to upload? Should I do something more?

Again, thanks a lot!

Phil.

>
> --
> Jelmer Vernooij 
> PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#950132: Fixed bugs are now always "Done: Debian FTP Masters "

[Don Armstrong]

On Thu, 30 Jan 2020, Ansgar wrote:
> There are a surprising number of consumbers of these mails, including
> AFAIK buildds or the BTS bot on IRC (which interestingly wasn't
> confused by this change).

Probably because it never paid any attention to From: anyway.

> It is also unclear what other services might consume the mails
> (directly or indirectly), and I don't really have an idea how to find
> out (besides debian-services-admin@).

The direct consumers of the mail are listed in the dak codebase:

https://salsa.debian.org/ftp-team/dak/blob/master/daklib/announce.py#L141
https://salsa.debian.org/ftp-team/dak/blob/master/config/debian/dak.conf#L13


-- 
Don Armstrong  https://www.donarmstrong.com

When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.
 -- Edmund Burke "Thoughts on the Cause of Present Discontents"

Bug#950294: libuv1: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: libuv1
Version: 1.33.1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The libuv1 tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
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 libuv1-1.33.1/debian/tests/control libuv1-1.33.1/debian/tests/control
--- libuv1-1.33.1/debian/tests/control  2019-10-31 09:49:00.0 -0700
+++ libuv1-1.33.1/debian/tests/control  2020-01-30 16:53:07.0 -0800
@@ -1,3 +1,3 @@
 Tests: run-tests
 Restrictions: allow-stderr
-Depends: @, gyp, gcc, libc-dev, g++
+Depends: @, gyp:native, build-essential
diff -Nru libuv1-1.33.1/debian/tests/run-tests 
libuv1-1.33.1/debian/tests/run-tests
--- libuv1-1.33.1/debian/tests/run-tests2019-10-31 09:49:00.0 
-0700
+++ libuv1-1.33.1/debian/tests/run-tests2020-01-30 16:53:07.0 
-0800
@@ -5,8 +5,14 @@
 echo "creating makefile for tests"
 ./gyp_uv.py -f make
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE=${DEB_HOST_GNU_TYPE}-
+else
+CROSS_COMPILE=
+fi
+
 echo "creating test binaries"
-make -C out
+make -C out CC=${CROSS_COMPILE}gcc LINK=${CROSS_COMPILE}gcc
 
 echo "Runing tests"
 ./out/Debug/run-tests

Bug#950293: u-boot-exynos: MMC is broken on Odroid U3

[Vagrant Cascadian]

Package: u-boot-exynos
Version: 2020.01+dfsg-1
Severity: important
Tags: fixed-upstream

The Odroid U3 would fail to detect MMC, which was fixed upstream:

  
https://gitlab.denx.de/u-boot/u-boot/commit/1bca28a5d98a81a9d189a46347f8a92619624f94

This isn't yet present in 2020.04-rc2, but I'll push the extra patches
in the next upload.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

[Thomas Dickey]

On Thu, Jan 30, 2020 at 08:11:30PM -0500, Thomas Dickey wrote:
...

The logfile doesn't give a clue about the screensize; there's no
cursor movement in it other than to the home-position.

Using unmap, which prints the escapes in visible form (and happens
to split the lines on escape characters), I see something a little
odd.  Here's a little slice from that listing:

\E]2;vinc17@zira - ~ | pts/23^G
\E(B
\E(B
\E[m
\E[?12l
\E[?25h
\E[?1007l\r
\E[0m
\E[27m
\E[24m
\E[J
\E[40m
\E[93mzira:~,2> 

The odd part is the (xterm-specific) 

\E[?1007l\r

(the "\r" isn't part of the sequence, but that's how unmap presents it).

XTerm Control Sequences summarizes this:

Ps = 1 0 0 7  -> Disable Alternate Scroll Mode, xterm.  This
  corresponds to the alternateScroll resource.

The manual page gives a little more information:

   alternateScroll (class ScrollCond)
   If “true”, the scroll-back and scroll-forw actions send
   cursor-up and -down keys when xterm is displaying the
   alternate screen.  The default is “false”.

   The alternateScroll state can also be set using a control
   sequence.

The changelog tells a little more:

Patch #291 - 2013/02/26

 * add  validity  check for xterm widget parameter to AlternateScroll
   function,  needed  to  handle  wheel mouse events in the scrollbar
   areasince[451]patch#282   changes   which   introduced
   alternateScroll feature (Redhat #874327).

Earlier in the output of unmap, it's switching to the alternate screen:

\E[?1049h

but then switches back out before the 1007's.  Just to check, I ran xterm
with that disabled, and it made no difference.

However, looking at the trace for something that might set the top/bottom
margins, I see a case (this time from Trace-parent.out):

parse 001B -> CASE_ESC ansi_table (used=0)
params 0 (0)
parse 006C -> CASE_HP_MEM_LOCK esc_table (used=0)
CASE_HP_MEM_LOCK
set_tb_margins 16..23, prior 0..23

That's documented in XTerm Control Sequences:

ESC l Memory Lock (per HP terminals).  Locks memory above the cursor.

and it comes from (unmap) this section of the logfile:

\E[00;92mcryptsetup
\E[0m/
\Els: cannot open directory '/run/cups/certs': Permission denied\r
\nls: cannot open directory '/run/firejail/firejail.ro.dir': Permission denied\r
\n[m\r

xterm's doing what it's documented to do.

So... (see my previous message), there's no way for xterm (or any terminal)
to distinguish your shell's stdout from stderr.  There's only the usual
solution, which assumes that applications which spit out both will do
fflush's to keep the two in sync.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#937484: Info received (Taking over)

[Jelmer Vernooij]

Oops - I should have read the earlier part of the this bug better. :-/

gpodder's mtp support appears to have been commented out for a long
time. FWIW, the MTP support in gvfs doesn't appear to work as an
alternative for me - get an error about the filesystem not being
local.

I do actually have a version of the package ported to Python 3, if
that would be useful.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#950292: ITP: python-versioneer -- determine version from repository tag

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: python-versioneer -- determine version from repository tag
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-versioneer
  Version : 0.18
  Upstream Author : Copyright: Brian Warner
* URL : https://github.com/warner/python-versioneer
* License : CC0
  Programming Lang: Python
  Description : determine version from repository tag
 This is a tool for managing a recorded version number in distutils-based
 python projects. The goal is to remove the tedious and error-prone
 "update the embedded version string" step from your release
 process. Making a new release should be as easy as recording a new tag
 in your version-control system, and maybe making new tarballs.

Remark: This package is maintained by Debian Python Modules Team at
   https://salsa.debian.org/python-team/modules/python-versioneer

Bug#936806: koji: Python2 removal in sid/bullseye

[Mike Miller]

On Thu, Jan 30, 2020 at 01:36:33 -0500, Sandro Tosi wrote:
> yep i came across all of them starting from python-lzma -- do you know
> what's the status of the "RedHat infrastructure" in debian? many (if
> not all) of those tools are relatively old, not maintained (or just in
> life support mode) and most of all, python2 with no port to python3
> available

Yeah. I was responsible for some of these, but put them up for adoption
about a year ago. You've about captured the status, all rpm-related
packages in Debian are old, unmaintained, Python 2 only. Updating to
Python 3 ports of mock and koji need dnf, yum is abandonware.

I've seen a couple threads about packaging dnf (likely not archived),
but so far no one has committed enough to file an ITP.

There _is_ an ITP for createrepo-c (#912338), a C-only reimplementation,
also a koji dependency, but looks like it may have stalled.

-- 
mike


signature.asc
Description: PGP signature

Bug#937484: Taking over

[Jelmer Vernooij]

Hi Hans-Christoph,

I'm interested in pymtp, since gpodder can optionally use it.  Thanks for 
packaging it!

I'll prepare an upload to migrate it to Python3, and will move it to
the Python team.

Cheers,

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#864932: gparted fails if PS_FORMAT options are specified

[Nicolas Braud-Santoni]

On Fri, Jan 31, 2020 at 02:29:08AM +0100, Nicolas Braud-Santoni wrote:
> Please find enclosed a patch that fixes the issue,
> using pgrep(1) instead of ps(1).

This works better if I recall to attach the patch  >_>'
Subject: gparted: Use pgrep(1) instead of ps(1) and grep(1)

Unlike ps(1), pgrep(1) is not affected by environment variables such as
PS_FORMAT, so it is safe to use without assuming PS_FORMAT is similar-enough
to the default.

Moreover, this is more efficient and less error-prone.
---
 gparted.in | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/gparted.in b/gparted.in
index 3f9b0f1..a4e71ff 100755
Origin: vendor
Bug-Debian: https://bugs.debian.org/864932
From: Nicolas Braud-Santoni 
Forwarded: no
Applied-Upstream: no
Last-Update: 2020-01-31

--- a/gparted.in
+++ b/gparted.in
@@ -30,7 +30,7 @@
 #
 #  Only permit one instance of GParted to execute at a time
 #
-if test "z`ps -e | grep gpartedbin`" != "z"; then
+if test -n "$(pgrep gpartedbin)"; then
 	echo "The process gpartedbin is already running."
 	echo "Only one gpartedbin process is permitted."
 	exit 1
@@ -94,7 +94,7 @@ fi
 HAVE_SYSTEMCTL=no
 for k in '' `echo "$PATH" | sed 's,:, ,g'`; do
 	if test -x "$k/systemctl"; then
-		if test "z`ps -e | grep systemd`" != "z"; then
+		if test -n "$(pgrep systemd)"; then
 			HAVE_SYSTEMCTL=yes
 			break
 		fi
@@ -107,7 +107,7 @@ done
 #
 HAVE_UDISKS2_INHIBIT=no
 if test -x "/usr/lib/udisks2/udisks2-inhibit"; then
-	if test "z`ps -e | grep 'udisksd'`" != "z"; then
+	if test -n "$(pgrep udisksd)"; then
 		HAVE_UDISKS2_INHIBIT=yes
 	fi
 fi
@@ -119,7 +119,7 @@ fi
 HAVE_UDISKS=no
 for k in '' `echo "$PATH" | sed 's,:, ,g'`; do
 	if test -x "$k/udisks"; then
-		if test "z`ps -e | grep udisks-daemon`" != "z"; then
+		if test -n "$(pgrep udisks-daemon)"; then
 			HAVE_UDISKS=yes
 			break
 		fi
@@ -133,7 +133,7 @@ done
 HAVE_HAL_LOCK=no
 for k in '' `echo "$PATH" | sed 's,:, ,g'`; do
 	if test -x "$k/hal-lock"; then
-		if test "z`ps -e | grep hald`" != "z"; then
+		if test -n "$(pgrep hald)"; then
 			HAVE_HAL_LOCK=yes
 			break
 		fi


signature.asc
Description: PGP signature

Bug#864932: gparted fails if PS_FORMAT options are specified

[Nicolas Braud-Santoni]

Control: tag -1 + patch pending upstream

Hi js,

On Sat, Jun 17, 2017 at 11:37:18AM -0400, js wrote:
> Dear Maintainer,
> 
> I have set PS_FORMAT environment variable to control the output of ps.
> As a result, the following test from the gparted script always fails:
> 
> #
> #  Only permit one instance of GParted to execute at a time
> #
> if test "z`ps -e | grep gpartedbin`" != "z"; then ## 
> env-dependent test
> echo "The process gpartedbin is already running."
>   echo "Only one gpartedbin process is permitted."
>   exit 1
>   fi

This is absolutely correct.

Please find enclosed a patch that fixes the issue,
using pgrep(1) instead of ps(1).

I commited the patch to the packaging repository, so it should be part of the
next upload of gparted, and I am forwarding it upstream.


Best regards,

  nicoo


signature.asc
Description: PGP signature

Bug#923201: it's already Recommends, but please support elogind

[Felipe Sateler]

On Thu, Jan 30, 2020 at 5:15 PM Adam Borowski  wrote:

> On Fri, Jan 17, 2020 at 10:43:35AM -0300, Felipe Sateler wrote:
> > Pulseaudio needs not only logind for user tracking (which could be
> replaced
> > by other logind), but right now requires it for actually starting up (it
> > requires systemd --user). Please help
> > https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/6 get
> > merged and then we can do this.
>
> I've looked at the PR again, and as expected, reversing the order of
> /lib/systemd/pulseaudio-enable-autospawn.service /dev/null
> to
> /dev/null /lib/systemd/pulseaudio-enable-autospawn.service
> makes it all goodness.
>

Thanks, I have pushed the change. If you could please test it one more time
before clicking merge, it would be great.

I'll include this with the next upload.

-- 

Saludos,
Felipe Sateler

Bug#851747: sysvinit-utils: drop Essential flag

[Thorsten Glaser]

On Fri, 31 Jan 2020, Andreas Henriksson wrote:

> > One of mine popped up, and, while I might investigate into
> > writing a systemd service for it,
> 
> In my opinion it's just time (well overdue if you ask me) that
> /everything/ gets native systemd units. The sysvinit compatibility is
> just a compatibility shim. It doesn't give you many of the advantages of
> systemd that someone using systemd would expect.

Yesss, but I cannot test them, and I don’t know about the specifics.

> I don't think that's needed as vars.sh (and sysvinit-utils) is
> (and likely always will be) guaranteed to be installed on a
> sysvinit(-core) system.

Wasn’t this thread about the issue of what to do with them
on a non-sysvinit system that uses initscript fallback (and
there are multiple of those)?

> Given that exists, it's not possible for lsb-base to depend on
> sysvinit-utils as it would cause a circular dependency.

Yeah… except if you split the scripts into another package.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#518348: [PATCH] Add support for decompressing zstd rpm payloads

[Lars Kellogg-Stedman]

Package: alien
Version: 8.95

Recent (Fedora 32 and later) versions of Fedora have switched to
using zstd to compress rpm payloads.

Resolves Debian #518348
---
 Alien/Package/Rpm.pm | 15 +--
 debian/control   |  3 +--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Alien/Package/Rpm.pm b/Alien/Package/Rpm.pm
index d53be2b..b9177d6 100644
--- a/Alien/Package/Rpm.pm
+++ b/Alien/Package/Rpm.pm
@@ -159,9 +159,20 @@ sub unpack {
$this->SUPER::unpack(@_);
my $workdir=$this->unpacked_tree;

-   # Check if we need to use lzma to uncompress the cpio archive
+   # Check if we need to uncompress the cpio archive
my $decomp='';
-   if ($this->do("rpm2cpio '".$this->filename."' | lzma -t -q > /dev/null 
2>&1")) {
+
+   if ($this->do("rpm2cpio '".$this->filename."' | xz -t -q > /dev/null 
2>&1")) {
+   # we first check xz (previously lzma) because this is the
+   # most common compression type at the moment.
+   $decomp = 'xz -d -q |';
+   } elsif ($this->do("rpm2cpio '".$this->filename."' | zstd -t -q > 
/dev/null 2>&1")) {
+   # we next check zstd, which is used by newer (Fedora 32 and 
later)
+   # rpms.
+   $decomp = 'zstd -d -q |';
+   } elsif ($this->do("rpm2cpio '".$this->filename."' | lzma -t -q > 
/dev/null 2>&1")) {
+   # We check lzma last in case we're on an older system with
+   # only lzma and no xz
$decomp = 'lzma -d -q |';
}
 
diff --git a/debian/control b/debian/control
index f6f0af0..7e4a873 100644
--- a/debian/control
+++ b/debian/control
@@ -4,12 +4,11 @@ Priority: optional
 Build-Depends: debhelper (>= 9)
 Maintainer: Debian QA Group 
 Standards-Version: 3.9.6
-Vcs-Git: git://git.kitenet.net/alien
 Homepage: http://kitenet.net/~joey/code/alien/
 
 Package: alien
 Architecture: all
-Depends: debhelper (>= 7), ${misc:Depends}, ${perl:Depends}, rpm (>= 2.4.4-2), 
dpkg-dev, make, cpio, rpm2cpio
+Depends: debhelper (>= 7), ${misc:Depends}, ${perl:Depends}, rpm (>= 2.4.4-2), 
dpkg-dev, make, cpio, rpm2cpio, xz-utils, zstd
 Suggests: patch, bzip2, lintian, lzma
 Description: convert and install rpm and other packages
  Alien allows you to convert LSB, Red Hat, Stampede and Slackware Packages
-- 
2.24.1


-- 
Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
http://blog.oddbit.com/| N1LKS

Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck

[Md Ayquassar]

First, thanks for a quick response.
Second, is a reassignment to some Mesa package required?
Third, is there anything else I can do as a user to help the developers to 
bugfix
this? Bug at line 1017 is strange: if there is a NULL dereference there, there
should also probably be one in line 1016 unless someone has a deterministic
concurrent access to that data.
Fourth, I apologize for long delays.I don’t always have the laptop at my direct
disposal.

 31.01.2020, 02:09, Bernhard Übelacker  Hello Md
 Ayquassar,
 sorry, I did not recognize that you
 seem to have a usrmerge'd system.

 Then I get following backtraces from your
 core dump, with and without debug symbols.

 It looks like a function pointer gets called
 unconditionally, while containing NULL.
 Seems to be graphics driver related.

 Kind regards,
 Bernhard



 
https://sources.debian.org/src/mesa/18.3.6-2/src/egl/drivers/dri2/egl_dri2.c/#L1017



 (gdb) bt
 #0 0x in ?? ()
 #1 0xaf7d2c74 in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0
 #2 0xaf7d755e in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0
 #3 0xade2d004 in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so
 #4 0xade2d812 in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so
 #5 0xade9232f in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so
 #6 0xaf7d29ba in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0
 #7 0xaf7c061c in eglMakeCurrent () from /lib/i386-linux-gnu/libEGL_mesa.so.0
 #8 0xb4cd8b58 in ?? () from /lib/i386-linux-gnu/libEGL.so.1
 #9 0xb674a1bd in _cogl_winsys_egl_make_current () from
 /usr/lib/i386-linux-gnu/mutter/libmutter-cogl-3.so
 #10 0xb6d8f1f6 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
 #11 0xb6ceaca4 in meta_renderer_rebuild_views () from
 /lib/i386-linux-gnu/libmutter-3.so.0
 #12 0xb6d920fa in meta_stage_native_rebuild_views () from
 /lib/i386-linux-gnu/libmutter-3.so.0
 #13 0xb6d83ba7 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
 #14 0xb6ccf11a in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
 #15 0xb6ccff40 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
 #16 0xb6d83f98 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
 #17 0xb6cd053a in meta_clutter_init () from
 /lib/i386-linux-gnu/libmutter-3.so.0
 #18 0xb6d20323 in meta_init () from /lib/i386-linux-gnu/libmutter-3.so.0
 #19 0x004ad53d in ?? ()
 #20 0xb6aa2b41 in __libc_start_main (main=0x4ad430, argc=1, argv=0xbff2c2a4,
 init=0x4adfa0, fini=0x4ae000, rtld_fini=0xb7f97520 <_dl_fini>,
 stack_end=0xbff2c29c) at ../csu/libc-start.c:308
 #21 0x004ad8d1 in ?? ()
 (gdb)




 Core was generated by `/usr/bin/gnome-shell'.
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0 0x in ?? ()
 [Current thread is 1 (Thread 0xb1f2eb80 (LWP 899))]
 (gdb) set width 0
 (gdb) set pagination off
 (gdb) bt
 #0 0x in ?? ()
 #1 0xaf7d2c74 in dri2_egl_surface_alloc_local_buffer (dri2_surf=0x1b8e9f0,
 att=9, format=32) at ../src/egl/drivers/dri2/egl_dri2.c:1017
 #2 0xaf7d755e in dri2_drm_get_buffers_with_format (driDrawable=0x1b73580,
 width=0x1b73598, height=0x1b7359c, attachments=0xbff2bb04, count=2,
 out_count=0xbff2baf8, loaderPrivate=0x1b8e9f0) at
 ../src/egl/drivers/dri2/platform_drm.c:344
 #3 0xade2d004 in radeon_update_renderbuffers (context=0x19e7d60,
 drawable=0x1b73580, front_only=0 '\000') at
 ../src/mesa/drivers/dri/radeon/radeon_common_context.c:421
 #4 0xade2d812 in radeonMakeCurrent (driContextPriv=0x19e7d60,
 driDrawPriv=0x1b73580, driReadPriv=0x1b73580) at
 ../src/mesa/drivers/dri/radeon/radeon_common_context.c:616
 #5 0xade9232f in driBindContext (pcp=0x19e7d60, pdp=0x1b73580, prp=0x1b73580)
 at ../src/mesa/drivers/dri/common/dri_util.c:579
 #6 0xaf7d29ba in dri2_make_current (drv=0x19e5120, disp=0x19e49c0,
 dsurf=0x1b8e9f0, rsurf=0x1b8e9f0, ctx=) at
 ../src/egl/drivers/dri2/egl_dri2.c:1516
 #7 0xaf7c061c in eglMakeCurrent (dpy=0x19e49c0, draw=0x1b8e9f0,
 read=0x1b8e9f0, ctx=0x19fe5c0) at ../src/egl/main/eglapi.c:860
 #8 0xb4cd8b58 in InternalMakeCurrentVendor (dpy=0x19e3dd0, 
draw=draw@entry=0x1b8e9f0,
 read=0x1b8e9f0, read@entry=0x19c3310, context=0x19fe5c0, apiState=0x19fe360,
 vendor=) at ../../../src/EGL/libegl.c:861
 #9 0xb4cd9606 in eglMakeCurrent (dpy=, draw=,
 read=0x1b8e9f0, context=0x19fe5c0) at ../../../src/EGL/libegl.c:727
 #10 0xb674a1bd in _cogl_winsys_egl_make_current (display=0x19ca4d8,
 draw=0x1b8e9f0, read=0x1b8e9f0, context=0x19fe5c0) at
 winsys/cogl-winsys-egl.c:300
 #11 0xb6d8f1f6 in meta_renderer_native_create_view (renderer=0x19c8610,
 logical_monitor=0x19bbf20) at backends/native/meta-renderer-native.c:2949
 #12 0xb6ceaca4 in meta_renderer_create_view (logical_monitor=,
 renderer=0x19c8610) at ./backends/meta-renderer.h:36
 #13 meta_renderer_rebuild_views (renderer=0x19c8610) at
 backends/meta-renderer.c:73
 #14 0xb6d920fa in meta_stage_native_rebuild_views (stage_native=0x19c2470) at
 backends/native/meta-stage-native.c:141
 #15 0xb6d83ba7 in meta_backend_native_update_screen_size (backend=0x19a48b8,
 width=1024, height=768) 

Bug#795445: Problem solved in Buster

[Ichthyostega]

Hello back from the future...

just run my probided testcase from Debian/Buster, i.e. with

GNU gdb (Debian 8.2.1-2+b3) 8.2.1


...and it did not crash anymore.

IMHO ticket could be closed

Bug#950291: /usr/bin/wlfreerdp: wlfreerdp logs in to remote server but does not render in sway

[Michael Westwind]

Package: freerdp2-wayland
Version: 2.0.0~git20190204.1.2693389a+dfsg1-2
Severity: important
File: /usr/bin/wlfreerdp

Dear Maintainer,


I am trying to duplicate my normal work environment using wayland and have
rejected using gnome or plasma if possible.  I normally use xfreerdp (which
continues to work fine with xwayland).  Trying wlfreerdp with gnome or plasma
works but is buggy (not resizing properly among other things), but on sway
fails to show the gui. I get the following output:

earthworm@savigny:~$ wlfreerdp /f /u:yyy /p:xxx /v:freegeek.myrealdata.net
/g:rdg.myrealdata.net /gt:http /gu:myrealdata\\yyy /gp:xxx /printer:WC-
Local,"HP Universal Printing PCL 5" /printer:BOP-Local,"HP Universal Printing
PCL 5" /printer:glorp /printer:HP-Color-Laserjet-3600
[16:13:40:834] [18506:18506] [INFO][com.freerdp.client.common.cmdline] -
loading channelEx rdpdr
[16:13:40:834] [18506:18506] [INFO][com.freerdp.client.common.cmdline] -
loading channelEx rdpsnd
[16:13:40:834] [18506:18506] [INFO][com.freerdp.client.common.cmdline] -
loading channelEx cliprdr
[16:13:42:967] [18506:18506] [ERROR][com.winpr.timezone] - Unable to find a
match for unix timezone: US/Pacific
[16:13:43:680] [18506:18506] [INFO][com.freerdp.gdi] - Local framebuffer format
PIXEL_FORMAT_BGRA32
[16:13:43:680] [18506:18506] [INFO][com.freerdp.gdi] - Remote framebuffer
format PIXEL_FORMAT_RGB16
[16:13:43:682] [18506:18506] [INFO][com.winpr.clipboard] - initialized POSIX
local file subsystem
[16:13:43:691] [18506:18515] [INFO][com.freerdp.channels.rdpdr.client] -
Loading device service printer [WC-Local] (static)
[16:13:43:691] [18506:18516] [INFO][com.freerdp.channels.rdpsnd.client] -
Loaded fake backend for rdpsnd
[16:13:43:692] [18506:18515] [INFO][com.freerdp.channels.rdpdr.client] -
Loading device service printer [BOP-Local] (static)
[16:13:43:693] [18506:18515] [INFO][com.freerdp.channels.rdpdr.client] -
Loading device service printer [glorp] (static)
[16:13:43:693] [18506:18515] [INFO][com.freerdp.channels.rdpdr.client] -
Loading device service printer [HP-Color-Laserjet-3600] (static)
xdg_surface@22: error 3: xdg_surface has never been configured
[16:13:46:273] [18506:18515] [INFO][com.freerdp.channels.rdpdr.client] -
registered device #1: PRN1 (type=4 id=1)
[16:13:46:273] [18506:18515] [INFO][com.freerdp.channels.rdpdr.client] -
registered device #2: PRN2 (type=4 id=2)
[16:13:46:273] [18506:18515] [INFO][com.freerdp.channels.rdpdr.client] -
registered device #3: PRN3 (type=4 id=3)
[16:13:46:273] [18506:18515] [INFO][com.freerdp.channels.rdpdr.client] -
registered device #4: PRN4 (type=4 id=4)
[16:14:46:386] [18506:18506] [INFO][com.freerdp.core] -
ERRINFO_DISCONNECTED_BY_OTHER_CONNECTION (0x0005):Another user connected to
the server, forcing the disconnection of the current connection.


There is no gui showing, but clearly I am logged in to the remote server, and
then when I connect with xfreerdp, it works and disconnects me from the
wlfreerdp interface (last line).

I considered that this might be best posted to sway, but I found this
discussion and patch on another application
(https://patches.videolan.org/patch/20875/)that pointed out the problem to be
the error above "xdg_surface@22: error 3: xdg_surface has never been
configured" and that failing to render at all was an appropriate response to
this bug.  That application also worked but buggily in gnome and plasma.

Thank you for your attention.



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages freerdp2-wayland depends on:
ii  libc6 2.29-9
ii  libfreerdp-client2-2  2.0.0~git20190204.1.2693389a+dfsg1-2
ii  libfreerdp2-2 2.0.0~git20190204.1.2693389a+dfsg1-2
ii  libuwac0-02.0.0~git20190204.1.2693389a+dfsg1-2
ii  libwinpr2-2   2.0.0~git20190204.1.2693389a+dfsg1-2

freerdp2-wayland recommends no packages.

freerdp2-wayland suggests no packages.

-- no debconf information

Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'

[Vagrant Cascadian]

Noticed that I can successfully build arch:all OR arch:any, but not
arch:all AND arch:any when building with sbuild.

Fails, building both arch:all and arch:any in one pass (which I think is
the default for pbuilder?):

 sbuild -d UNRELEASED -c sid --no-source --arch-any --arch-all 
xz-utils_5.2.4-1.dsc

Succeeds, building arch:all only:

 sbuild -d UNRELEASED -c sid --no-source --no-arch-any --arch-all 
xz-utils_5.2.4-1.dsc

Succeeds, building arch:any only:

 sbuild -d UNRELEASED -c sid --no-source --arch-any --no-arch-all 
xz-utils_5.2.4-1.dsc


That would explain why it works on the buildd's but not with pbuilder or
with the reproducible builds infrastructure (which also uses pbuilder
with a all+any build, usually).


At some point, it would be nice to systematically test these types of
issues as part of the reproducible builds infrastructure, but that is
probably a ways off...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

[Thomas Dickey]

On Sat, Jan 18, 2020 at 12:26:34AM +0100, Vincent Lefevre wrote:
> On 2020-01-18 00:02:46 +0100, Vincent Lefevre wrote:
> > On my machine, the problem is almost always reproducible with
> > 
> >   ll -R /run | less
> > 
> > where
> > 
> > zira:~> where ll
> > ll: aliased to ls -l
> > zira:~> where ls
> > ls: aliased to \ls -bFv --color
> > /bin/ls
> > 
> > but it does not seem to be reproducible with
> > 
> >   /bin/ls -bFv --color -l -R /run | less
> > 
> > That's rather strange.
> 
> The xterm logs show that stdout and stderr are mixed up in different
> ways, which explains that the bug does not occur with the second
> command. In short, there's some kind of race condition, and I suppose
> that the difference is caused by a slightly different timing between
> both commands. This *might* also explain why I cannot reproduce the
> bug in other terminals.

There's nothing for me to fix:

+ xterm's checking for invalid escape sequences, and stopping interpretation
  when it sees an error.  Some other terminal can check and handle the error
  differently (or in the examples you gave, simply not check at all).  Because
  xterm's using a state machine, it'll see errors that a switch/case logic
  won't address.

  In this report, you've assumed that terminals respond to errors identically.

+ there's no way that xterm can ever tell which bits came from your stdout
  and which from stderr.
  
  In this report you've assumed that it can.

+ for issues such as this, using "script" to generate a typescript file is
  the place to start (providing a reproducible test-case).

  You've described an error condition which you cannot reproduce at will.

You really ought to read the tag descriptions:

https://www.debian.org/Bugs/Developer#tags

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck

[Bernhard Übelacker]

Hello Md Ayquassar,
sorry, I did not recognize that you
seem to have a usrmerge'd system.

Then I get following backtraces from your
core dump, with and without debug symbols.

It looks like a function pointer gets called
unconditionally, while containing NULL.
Seems to be graphics driver related.

Kind regards,
Bernhard



https://sources.debian.org/src/mesa/18.3.6-2/src/egl/drivers/dri2/egl_dri2.c/#L1017



(gdb) bt
#0  0x in ?? ()
#1  0xaf7d2c74 in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0
#2  0xaf7d755e in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0
#3  0xade2d004 in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so
#4  0xade2d812 in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so
#5  0xade9232f in ?? () from /usr/lib/i386-linux-gnu/dri/radeon_dri.so
#6  0xaf7d29ba in ?? () from /lib/i386-linux-gnu/libEGL_mesa.so.0
#7  0xaf7c061c in eglMakeCurrent () from /lib/i386-linux-gnu/libEGL_mesa.so.0
#8  0xb4cd8b58 in ?? () from /lib/i386-linux-gnu/libEGL.so.1
#9  0xb674a1bd in _cogl_winsys_egl_make_current () from 
/usr/lib/i386-linux-gnu/mutter/libmutter-cogl-3.so
#10 0xb6d8f1f6 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#11 0xb6ceaca4 in meta_renderer_rebuild_views () from 
/lib/i386-linux-gnu/libmutter-3.so.0
#12 0xb6d920fa in meta_stage_native_rebuild_views () from 
/lib/i386-linux-gnu/libmutter-3.so.0
#13 0xb6d83ba7 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#14 0xb6ccf11a in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#15 0xb6ccff40 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#16 0xb6d83f98 in ?? () from /lib/i386-linux-gnu/libmutter-3.so.0
#17 0xb6cd053a in meta_clutter_init () from /lib/i386-linux-gnu/libmutter-3.so.0
#18 0xb6d20323 in meta_init () from /lib/i386-linux-gnu/libmutter-3.so.0
#19 0x004ad53d in ?? ()
#20 0xb6aa2b41 in __libc_start_main (main=0x4ad430, argc=1, argv=0xbff2c2a4, 
init=0x4adfa0, fini=0x4ae000, rtld_fini=0xb7f97520 <_dl_fini>, 
stack_end=0xbff2c29c) at ../csu/libc-start.c:308
#21 0x004ad8d1 in ?? ()
(gdb) 




Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
[Current thread is 1 (Thread 0xb1f2eb80 (LWP 899))]
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x in ?? ()
#1  0xaf7d2c74 in dri2_egl_surface_alloc_local_buffer (dri2_surf=0x1b8e9f0, 
att=9, format=32) at ../src/egl/drivers/dri2/egl_dri2.c:1017
#2  0xaf7d755e in dri2_drm_get_buffers_with_format (driDrawable=0x1b73580, 
width=0x1b73598, height=0x1b7359c, attachments=0xbff2bb04, count=2, 
out_count=0xbff2baf8, loaderPrivate=0x1b8e9f0) at 
../src/egl/drivers/dri2/platform_drm.c:344
#3  0xade2d004 in radeon_update_renderbuffers (context=0x19e7d60, 
drawable=0x1b73580, front_only=0 '\000') at 
../src/mesa/drivers/dri/radeon/radeon_common_context.c:421
#4  0xade2d812 in radeonMakeCurrent (driContextPriv=0x19e7d60, 
driDrawPriv=0x1b73580, driReadPriv=0x1b73580) at 
../src/mesa/drivers/dri/radeon/radeon_common_context.c:616
#5  0xade9232f in driBindContext (pcp=0x19e7d60, pdp=0x1b73580, prp=0x1b73580) 
at ../src/mesa/drivers/dri/common/dri_util.c:579
#6  0xaf7d29ba in dri2_make_current (drv=0x19e5120, disp=0x19e49c0, 
dsurf=0x1b8e9f0, rsurf=0x1b8e9f0, ctx=) at 
../src/egl/drivers/dri2/egl_dri2.c:1516
#7  0xaf7c061c in eglMakeCurrent (dpy=0x19e49c0, draw=0x1b8e9f0, 
read=0x1b8e9f0, ctx=0x19fe5c0) at ../src/egl/main/eglapi.c:860
#8  0xb4cd8b58 in InternalMakeCurrentVendor (dpy=0x19e3dd0, 
draw=draw@entry=0x1b8e9f0, read=0x1b8e9f0, read@entry=0x19c3310, 
context=0x19fe5c0, apiState=0x19fe360, vendor=) at 
../../../src/EGL/libegl.c:861
#9  0xb4cd9606 in eglMakeCurrent (dpy=, draw=, 
read=0x1b8e9f0, context=0x19fe5c0) at ../../../src/EGL/libegl.c:727
#10 0xb674a1bd in _cogl_winsys_egl_make_current (display=0x19ca4d8, 
draw=0x1b8e9f0, read=0x1b8e9f0, context=0x19fe5c0) at 
winsys/cogl-winsys-egl.c:300
#11 0xb6d8f1f6 in meta_renderer_native_create_view (renderer=0x19c8610, 
logical_monitor=0x19bbf20) at backends/native/meta-renderer-native.c:2949
#12 0xb6ceaca4 in meta_renderer_create_view (logical_monitor=, 
renderer=0x19c8610) at ./backends/meta-renderer.h:36
#13 meta_renderer_rebuild_views (renderer=0x19c8610) at 
backends/meta-renderer.c:73
#14 0xb6d920fa in meta_stage_native_rebuild_views (stage_native=0x19c2470) at 
backends/native/meta-stage-native.c:141
#15 0xb6d83ba7 in meta_backend_native_update_screen_size (backend=0x19a48b8, 
width=1024, height=768) at backends/native/meta-backend-native.c:493
#16 0xb6ccf11a in meta_backend_sync_screen_size 
(backend=backend@entry=0x19a48b8) at backends/meta-backend-private.h:52
#17 0xb6ccff40 in meta_backend_real_post_init (backend=0x19a48b8) at 
backends/meta-backend.c:442
#18 0xb6d83f98 in meta_backend_native_post_init (backend=0x19a48b8) at 
./backends/meta-backend-private.h:52
#19 0xb6cd053a in meta_backend_post_init (backend=) at 
backends/meta-backend-private.h:52
#20 meta_clutter_init () at backends/meta-backend.c:1239
#21 

Bug#950290: Acknowledgement (bley: Port to use publicsuffix2, missing depends)

[Scott Kitterman]

Patch attached for completeness.  I assume this won't be ported to python3, so 
this is irrelevant, but if it is, this needs to be done too.

Scott K

Note: Despite the NMU style debian/changelog, I do not intend to NMU this 
package.
diff -Nru bley-2.0.0/debian/changelog bley-2.0.0/debian/changelog
--- bley-2.0.0/debian/changelog	2015-01-09 02:11:09.0 -0500
+++ bley-2.0.0/debian/changelog	2020-01-30 19:57:12.0 -0500
@@ -1,3 +1,10 @@
+bley (2.0.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Port to use publicsuffix2 (Closes: #950290)
+
+ -- Scott Kitterman   Thu, 30 Jan 2020 19:57:12 -0500
+
 bley (2.0.0-2) unstable; urgency=medium
 
   * drop dnsbl.ahbl.org from the config, it was shut down and produces
diff -Nru bley-2.0.0/debian/patches/publicsuffix2_port.patch bley-2.0.0/debian/patches/publicsuffix2_port.patch
--- bley-2.0.0/debian/patches/publicsuffix2_port.patch	1969-12-31 19:00:00.0 -0500
+++ bley-2.0.0/debian/patches/publicsuffix2_port.patch	2020-01-30 19:57:12.0 -0500
@@ -0,0 +1,47 @@
+Description: Use publicsuffix2
+Author: Scott Kitterman 
+Bug-Debian: https://bugs.debian.org/950290
+Origin: vendor
+Forwarded: no
+Last-Update: 2020-01-31
+
+--- bley-2.0.0.orig/bleyhelpers.py
 bley-2.0.0/bleyhelpers.py
+@@ -29,9 +29,9 @@ import spf
+ import re
+ import ipaddr
+ try:
+-import publicsuffix
++import publicsuffix2
+ except ImportError:
+-publicsuffix = None
++publicsuffix2 = None
+ 
+ publicsuffixlist = None
+ 
+@@ -67,11 +67,11 @@ def domain_from_host(host):
+ @return: the extracted domain
+ '''
+ 
+-if publicsuffix:
++if publicsuffix2:
+ global publicsuffixlist
+ if publicsuffixlist is None:
+-publicsuffixlist = publicsuffix.PublicSuffixList()
+-domain = publicsuffixlist.get_public_suffix(host)
++publicsuffixlist = publicsuffix2.PublicSuffixList()
++domain = publicsuffixlist2.get_public_suffix(host)
+ else:
+ d = host.split('.')
+ if len(d) > 1:
+--- bley-2.0.0.orig/setup.py
 bley-2.0.0/setup.py
+@@ -34,7 +34,7 @@ setup(
+ extras_require={
+ 'PostgreSQL backend': ['psycopg2'],
+ 'MySQL backend': ['MySQL-python'],
+-'publicsuffix.org support': ['publicsuffix'],
++'publicsuffix.org support': ['publicsuffix2'],
+ },
+ data_files=[
+ ('/etc/bley', ['bley.conf.example',
diff -Nru bley-2.0.0/debian/patches/series bley-2.0.0/debian/patches/series
--- bley-2.0.0/debian/patches/series	2015-01-09 02:11:09.0 -0500
+++ bley-2.0.0/debian/patches/series	2020-01-30 19:57:12.0 -0500
@@ -1,2 +1,3 @@
 01-debian_config_and_paths.patch
 drop-dnsbl.ahbl.org-from-the-config.patch
+publicsuffix2_port.patch


signature.asc
Description: This is a digitally signed message part.

Bug#950290: bley: Port to use publicsuffix2, missing depends

[Scott Kitterman]

Package: bley
Severity: serious
Justification: Policy 3.5

The python-publicsuffix package was deprecated by upstream and has been
replaced in Debian by python-publicsuffix2.  If bley is ported to Python
3 so it can stay in Debian, it also needs to be ported to publicsuffix2.

Scott K

Versions of packages bley depends on:
ii  adduser3.118
pn  dbconfig-common
ii  debconf [debconf-2.0]  1.5.71
ii  init-system-helpers1.56+nmu1
ii  python 2.7.16-1
pn  python-dns 
pn  python-ipaddr  
ii  python-publicsuffix1.1.0-2
pn  python-spf 
pn  python-twisted-core
pn  python-twisted-names   

Versions of packages bley recommends:
ii  postfix 3.4.8-0+10debu1
pn  postgresql-client | mysql-client | sqlite3  
pn  python-psycopg2 | python-mysqldb

bley suggests no packages.

Bug#950289: python-internetarchive is leaking files descriptors - Fixed patch

[kpcyrd]

I'm terribly sorry, this is the correct patch:

--- >8 ---
diff --git a/internetarchive/utils.py b/internetarchive/utils.py
index db8412a..2f3e04e 100644
--- a/internetarchive/utils.py
+++ b/internetarchive/utils.py
@@ -235,14 +235,16 @@ def recursive_file_count(files, item=None, 
checksum=False):
 is_dir = False
 if is_dir:
 for x, _ in iter_directory(f):
-lmd5 = get_md5(open(x, 'rb'))
+with open(x, 'rb') as f_:
+lmd5 = get_md5(f_)
 if lmd5 in md5s:
 continue
 else:
 total_files += 1
 else:
 try:
-lmd5 = get_md5(open(f, 'rb'))
+with open(f, 'rb') as f_:
+lmd5 = get_md5(f_)
 except TypeError:
 # Support file-like objects.
 lmd5 = get_md5(f)
--- 8< ---

Bug#916260: gparted mounts partition without protection

[Nicolas Braud-Santoni]

Hi Phillip,

On Thu, Dec 13, 2018 at 09:02:24AM -0500, Phillip Susi wrote:
> On 12/12/2018 11:59 PM, Marc Lehmann wrote:
> > As you say, there are several ways, some where the user can choose to
> > make the files accessible and some where she can choose to not make them
> > available.
> 
> I'm not sure what you mean by this.

The scenario at play is the following:

1. I am a user with some level of administrative privileges, and run gparted.
2. I resize a partition (btrfs, in Marc's initial report),
   causing it to be mounted under /tmp, with a mountpoint that's chmod 0777.
3. Now *another user* on the same machine can access that file system,
   which I unwittingly mounted and exposed.

I agree with Marc that the simplest way to negate the issue would be
for gparted to make a private, temporary directory (chmod 0700) and put
all its temporary files and mountpoints there, so they cannot be accidentally
exposed to other users.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#950289: python-internetarchive is leaking filedescriptors

[kpcyrd]

Package: internetarchive
Version: 1.8.1-1
Severity: important

I've tried to upload to archive.org and noticed ia crashes on
large folders.

$ ulimit -n
1024
$ ia upload asdf ./folder-with-more-than-1024-files/
[...]
OSError: [Errno 24] Too many open files
[...]
$

The bug is present in src:python-internetarchive, I found a patch that
resolves the issue from 2018 that was never applied. You can find a
patch that cleanly applies to the current debian/sid below. The original
author is github.com/Arkiver2:

--- >8 ---
diff --git a/internetarchive/utils.py b/internetarchive/utils.py
index db8412a..7385857 100644
--- a/internetarchive/utils.py
+++ b/internetarchive/utils.py
@@ -235,14 +235,16 @@ def recursive_file_count(files, item=None, 
checksum=False):
 is_dir = False
 if is_dir:
 for x, _ in iter_directory(f):
-lmd5 = get_md5(open(x, 'rb'))
+with open(x, 'rb') as f_:
+lmd5 = get_md5(f_)
 if lmd5 in md5s:
 continue
 else:
 total_files += 1
 else:
 try:
-lmd5 = get_md5(open(f, 'rb'))
+with open(x, 'rb') as f_:
+lmd5 = get_md5(f_)
 except TypeError:
 # Support file-like objects.
 lmd5 = get_md5(f)
--- 8< ---

Bug#950287: autofs: automount expriing unmounts target filesystem

[Marc Lehmann]

On Thu, Jan 30, 2020 at 11:50:32PM +, Mike Gabriel  
wrote:
> This seems like something to be discussed upstream. I Cc:ed Ian Kent, maybe
> he has some 2? to add.

Cool!

In the meantime, I digged a bit more, and it seems that it is because with
misc-device support, autofs uses the AUTOFS_DEV_IOCTL_ISMOUNTPOINT ioctl
to check whether something is a mountpoint, which returns 1, which causes
the code in umount_multi to decude it cannot be symlink and unmounting it.

Indeed, rm /dev/autofs before starting autofs makes it partially work (the
target dir is not unmounted, but the entry is still gone without ghosting).

Upstream probably already knows this, of course.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#950235: marked as done (cl-asdf build fails on sbcl-2.0.1)

[Benda Xu]

Thank you, Sébastien!

Benda


signature.asc
Description: PGP signature

Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail

[Reiner Herrmann]

On Sat, Jan 25, 2020 at 10:45:08PM +0800, Mad Horse wrote:
> I have not remembered that because --private is used so widely in
> officially shipped profiles, so I have to inspect them with command like
> 
> > $ firejail --profile=/etc/firejail/firefox.profile /bin/bash

Hm, I couldn't find "private" in the firefox(-common) profile.
Does it work if you start it by giving it a location where it can store
the private home directory?
Like: firejail --allusers --private=/foo/bar
(see also: 
https://github.com/netblue30/firejail/issues/3185#issuecomment-578413651 )

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#938184: Issue resolved

[Sunil Mohan Adapa]

tag 938184 + pending
tag 947812 + pending
tag 948930 + pending
thanks

I have pushed fixes for these issues into the package repository.
Requested an upload.

Thank you,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#950287: autofs: automount expriing unmounts target filesystem

[Mike Gabriel]

Hi Marc, hi Ian,

@Ian: I am the new autofs package maintainer in Debian.

On  Fr 31 Jan 2020 00:38:10 CET, Marc Lehmann wrote:


Dear Maintainer,

for many years, I started automount with -t 8640, and by now had
forgotten what this was for (or whether I reported the problem). Today, I
removed it and got reminded what it was supposed to work around.

Effectively, when automount expires mountpoints, specifically symlink bind
mounts, it will unmount the target directory. Example, with browse mode
being on:

auto.master:

   /fs /etc/auto.fs symlink  
-vers=4,intr,rsize=1048576,wsize=1048576,tcp,port=2049,fsc


auto.fs:

   bp -fstype=bind:/bp

With this setup, doing ls /fs show a bp directory. ls /fs/bp will replace
it by a symlink to /bp, then killall -USR1 automount will remove /fs/bp
(which I think it shouldn't when in browse mode, bug #1) and ALSO unmount
/bp (bug #2, the real problem).

I guess automount simply calls umount on the symlink and then unlinks it.

killall -HUP automount will bring back the ghosted /fs/bp entry.
alternatively, ls /fs/bp will bring bakc the symolink, butg of course the
target directory stays unmounted.

I think I never reported it because this behaviour was with my own patched
copy, but it is reproducible with the pristine version.


This seems like something to be discussed upstream. I Cc:ed Ian Kent,  
maybe he has some 2¢ to add.


Thanks+Greets,
Mike

--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpT3eFeAT7e_.pgp
Description: Digitale PGP-Signatur

Bug#950285: Remove me from Uploaders

[Ben Hutchings]

Package: libclass-dbi-plugin-pager-perl
Version: 0.566-2
Severity: minor

I initially packaged this module but don't have any interest in it
now.  Please remove me from Uploaders when convenient.

Ben.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libclass-dbi-plugin-pager-perl depends on:
ii  libclass-data-inheritable-perl  0.08-3
pn  libclass-dbi-perl   
pn  libclass-dbi-plugin-abstractcount-perl  
pn  libdata-page-perl   
pn  libsql-abstract-perl
pn  libuniversal-exports-perl   
pn  libuniversal-require-perl   
ii  perl5.30.0-9

libclass-dbi-plugin-pager-perl recommends no packages.

libclass-dbi-plugin-pager-perl suggests no packages.

Bug#950288: Remove me from Uploaders

[Ben Hutchings]

Package: libtime-piece-mysql-perl
Version: 0.06-2
Severity: minor

I initially packaged this module but don't have any interest in it
now.  Please remove me from Uploaders when convenient.

Ben.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtime-piece-mysql-perl depends on:
ii  perl  5.30.0-9

libtime-piece-mysql-perl recommends no packages.

libtime-piece-mysql-perl suggests no packages.

Bug#950286: Remove me from Uploaders

[Ben Hutchings]

Package: libtest-mockmodule-perl
Version: 0.171.0-1
Severity: minor

I initially packaged this module but don't have any interest in it
now.  Please remove me from Uploaders when convenient.

Ben.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtest-mockmodule-perl depends on:
pn  libsuper-perl  
ii  perl   5.30.0-9

libtest-mockmodule-perl recommends no packages.

libtest-mockmodule-perl suggests no packages.

Bug#950287: autofs: automount expriing unmounts target filesystem

[Marc Lehmann]

Package: autofs
Version: 5.1.2-4
Severity: normal

Dear Maintainer,

for many years, I started automount with -t 8640, and by now had
forgotten what this was for (or whether I reported the problem). Today, I
removed it and got reminded what it was supposed to work around.

Effectively, when automount expires mountpoints, specifically symlink bind
mounts, it will unmount the target directory. Example, with browse mode
being on:

auto.master:

   /fs /etc/auto.fs symlink 
-vers=4,intr,rsize=1048576,wsize=1048576,tcp,port=2049,fsc

auto.fs:

   bp -fstype=bind:/bp

With this setup, doing ls /fs show a bp directory. ls /fs/bp will replace
it by a symlink to /bp, then killall -USR1 automount will remove /fs/bp
(which I think it shouldn't when in browse mode, bug #1) and ALSO unmount
/bp (bug #2, the real problem).

I guess automount simply calls umount on the symlink and then unlinks it.

killall -HUP automount will bring back the ghosted /fs/bp entry.
alternatively, ls /fs/bp will bring bakc the symolink, butg of course the
target directory stays unmounted.

I think I never reported it because this behaviour was with my own patched
copy, but it is reproducible with the pristine version.

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), 
(500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), 
(500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 
'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 5.4.15-050415-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autofs depends on:
ii  libc62.28-10
ii  libxml2  2.9.4+dfsg1-7+b3
ii  ucf  3.0038+nmu1

Versions of packages autofs recommends:
ii  e2fsprogs   1.45.5-2
ii  kmod26-1
ii  nfs-common  1:1.3.4-2.5

autofs suggests no packages.

-- debconf information excluded

Bug#950283: Remove me from Uploaders

[Ben Hutchings]

Package: libclass-dbi-mysql-perl
Version: 1.00-4
Severity: minor

I initially packaged this module but don't have any interest in it
now.  Please remove me from Uploaders when convenient.

Ben.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libclass-dbi-mysql-perl depends on:
pn  libclass-dbi-perl  
pn  libdbd-mysql-perl  
ii  perl   5.30.0-9

Versions of packages libclass-dbi-mysql-perl recommends:
pn  libtime-piece-mysql-perl  

libclass-dbi-mysql-perl suggests no packages.

Bug#950284: Remove me from Uploaders

[Ben Hutchings]

Package: libclass-dbi-plugin-abstractcount-perl[
Version: 0.08-2
Severity: minor

I initially packaged this module but don't have any interest in it
now.  Please remove me from Uploaders when convenient.

Ben.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#950282: libmagick++-6.q16hdri-dev: pkgconfig for HDRI case incorrect

[Hermann Vosseler]

Package: libmagick++-6.q16hdri-dev
Version: 8:6.9.10.23+dfsg-2.1
Severity: normal

Dear Maintainer,

as you know, the DEB installs a "default" variant, as well as a
variant for "quantum depth 16" and yet another variant for "quantum depth 16 +
HDRI"

While packaging some software, I need to depend on libmagick++-6.q16hdri-dev

However, this package installs a pkg-config file, which does not work
out of the box, and which sets the flags wrong, so to *disable* the HDRI
feature.

(1) install only libmagick++-6.q16hdri-dev
this pulls the additional dependencies:
  libmagick++-6-headers libmagick++-6.q16hdri-8

(2) pkg-config Magick++-6.Q16HDRI  --cflags

> Package MagickWand was not found in the pkg-config search path.
> Package 'MagickWand', required by 'Magick++-6.Q16HDRI', not found

(3) now try to fix that by installing libmagick++-dev
this again pulls additional dependencies:
  libmagick++-6.q16-dev libmagickcore-6.q16-dev libmagickwand-6.q16-dev

(4) pkg-config Magick++-6.Q16HDRI  --cflags

> -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 \
> -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 \
> -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 \
> -I/usr/include/x86_64-linux-gnu//ImageMagick-6
...

Please note: the HDRI toggle is first enabled, but then disabled again.


The reason is obviously in the two files:
/usr/lib/x86_64-linux-gnu/pkgconfig/ImageMagick++-im6.Q16HDRI.pc
/usr/lib/x86_64-linux-gnu/pkgconfig/MagickWand-6.Q16HDRI.pc

The first one defines a...
> Requires: MagickWand

and the second one defines a...
> Requires: MagickCore


...while in fact both should use the Q16HDRI variants

Moreover, would ImageMagick++-im6.Q16HDRI.pc  properly depend on
MagickWand-6.Q16HDRI.pc, and this again properly depend on
MagicCore-6.QHDRI, then also the problem of the missing package
dependency would be solved, and the HDRI_ENABLE would be =1 correctly




-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
compare:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
convert:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
composite:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
conjure:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
display:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
identify:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
import:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
mogrify:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
montage:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
stream:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (900, 'stable'), (650, 'stable'), (500, 'stable-updates'), (95, 
'testing'), (80, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libmagick++-6.q16hdri-dev depends on:
ii  dpkg 1.19.7
ii  libmagick++-6-headers8:6.9.10.23+dfsg-2.1
ii  libmagick++-6.q16hdri-8  8:6.9.10.23+dfsg-2.1
ii  libmagickcore-6.q16hdri-dev  8:6.9.10.23+dfsg-2.1
ii  libmagickwand-6.q16hdri-dev  8:6.9.10.23+dfsg-2.1
ii  pkg-config   0.29-6

libmagick++-6.q16hdri-dev recommends no packages.

libmagick++-6.q16hdri-dev suggests no packages.

-- no debconf information

Bug#950281: stretch-pu: package libsolv/0.6.24-1+deb9u2

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear Release Team,

I have just uploaded libsolv/0.6.24-1+deb9u2 to stretch...

+  * debian/patches:
++ CVE-2019-20387: Add 0001_CVE-2019-20387.patch. Resolves heap-based
+  buffer over-read in repodata.c (Closes: #949611).

  -> ... fixing CVE-2019-20387.

++ Trivial rebase of patches 1004, 1006 and 2001.

  -> ... and fixing line numbers in patchs 1004, 1006, and 2001.

Greets,
Mike

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libsolv-0.6.24/debian/changelog libsolv-0.6.24/debian/changelog
--- libsolv-0.6.24/debian/changelog 2017-09-18 17:33:32.0 +0200
+++ libsolv-0.6.24/debian/changelog 2020-01-30 18:49:35.0 +0100
@@ -1,3 +1,12 @@
+libsolv (0.6.24-1+deb9u2) stretch; urgency=medium
+
+  * debian/patches:
++ CVE-2019-20387: Add 0001_CVE-2019-20387.patch. Resolves heap-based
+  buffer over-read in repodata.c (Closes: #949611).
++ Trivial rebase of patches 1004, 1006 and 2001.
+
+ -- Mike Gabriel   Thu, 30 Jan 2020 18:49:35 +0100
+
 libsolv (0.6.24-1+deb9u1) stretch; urgency=medium
 
   * debian/control:
diff -Nru libsolv-0.6.24/debian/patches/0001_CVE-2019-20387.patch 
libsolv-0.6.24/debian/patches/0001_CVE-2019-20387.patch
--- libsolv-0.6.24/debian/patches/0001_CVE-2019-20387.patch 1970-01-01 
01:00:00.0 +0100
+++ libsolv-0.6.24/debian/patches/0001_CVE-2019-20387.patch 2020-01-30 
18:49:35.0 +0100
@@ -0,0 +1,32 @@
+From fdb9c9c03508990e4583046b590c30d958f272da Mon Sep 17 00:00:00 2001
+From: Zhipeng Xie 
+Date: Tue, 6 Aug 2019 09:50:57 +0800
+Subject: [PATCH] repodata_schema2id: fix heap-buffer-overflow in memcmp
+
+When the length of last schema in data->schemadata is
+less than length of input schema, we got a read overflow
+in asan test.
+
+Signed-off-by: Zhipeng Xie 
+---
+ src/repodata.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/src/repodata.c
 b/src/repodata.c
+@@ -205,11 +205,13 @@
+   cid = schematahash[h];
+   if (cid)
+ {
+-  if (!memcmp(data->schemadata + data->schemata[cid], schema, len * 
sizeof(Id)))
++  if ((data->schemata[cid] + len <= data->schemadatalen) &&
++!memcmp(data->schemadata + data->schemata[cid], 
schema, len * sizeof(Id)))
+ return cid;
+   /* cache conflict, do a slow search */
+   for (cid = 1; cid < data->nschemata; cid++)
+-if (!memcmp(data->schemadata + data->schemata[cid], schema, len * 
sizeof(Id)))
++if ((data->schemata[cid] + len <= data->schemadatalen) &&
++  !memcmp(data->schemadata + data->schemata[cid], 
schema, len * sizeof(Id)))
+   return cid;
+ }
+   /* a new one */
diff -Nru libsolv-0.6.24/debian/patches/1004_cmake-module-path-fix.patch 
libsolv-0.6.24/debian/patches/1004_cmake-module-path-fix.patch
--- libsolv-0.6.24/debian/patches/1004_cmake-module-path-fix.patch  
2017-09-18 17:31:26.0 +0200
+++ libsolv-0.6.24/debian/patches/1004_cmake-module-path-fix.patch  
2020-01-30 18:49:35.0 +0100
@@ -11,7 +11,7 @@
  
  OPTION (ENABLE_STATIC "Build a static version of the libraries?" OFF)
  OPTION (DISABLE_SHARED "Do not build a shared version of the libraries?" OFF)
-@@ -71,7 +71,7 @@
+@@ -70,7 +70,7 @@
  
  # where to look first for cmake modules, before ${CMAKE_ROOT}/Modules/ is 
checked
  SET (CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
diff -Nru libsolv-0.6.24/debian/patches/1006_various-types.patch 
libsolv-0.6.24/debian/patches/1006_various-types.patch
--- libsolv-0.6.24/debian/patches/1006_various-types.patch  2017-09-18 
17:31:26.0 +0200
+++ libsolv-0.6.24/debian/patches/1006_various-types.patch  2020-01-30 
18:49:35.0 +0100
@@ -120,7 +120,7 @@
  FOR_PROVIDES(p, pp, s->name)
 --- a/src/solver.h
 +++ b/src/solver.h
-@@ -149,10 +149,10 @@
+@@ -143,10 +143,10 @@
 * Solver configuration
 
*-*/
  
@@ -135,7 +135,7 @@
int allowuninstall; /* allow removal of installed solvables 
*/
int noupdateprovide;/* true: update packages needs 
not to provide old package */
int needupdateprovide;  /* true: update packages must provide 
old package */
-@@ -172,10 +172,10 @@
+@@ -167,10 +167,10 @@
Map dupmap;   

Bug#950280: buster-pu: package libsolv/0.6.35-2+deb10u1

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear Release Team,

I have just uploaded libsolv/0.6.35-2+deb10u1 to buster.

+  * debian/patches:
++ CVE-2019-20387: Add 0001_CVE-2019-20387.patch. Resolves heap-based buffer
+  over-read in repodata.c (Closes: #949611).

  -> ... fixing CVE-2019-20387.

++ 1006_various-types.patch: Trivial rebase.
+

  -> ... and fixing lines in patch 1006.

Greets,
Mike


-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libsolv-0.6.35/debian/changelog libsolv-0.6.35/debian/changelog
--- libsolv-0.6.35/debian/changelog 2018-09-03 11:14:21.0 +0200
+++ libsolv-0.6.35/debian/changelog 2020-01-30 22:35:28.0 +0100
@@ -1,3 +1,12 @@
+libsolv (0.6.35-2+deb10u1) buster; urgency=medium
+
+  * debian/patches:
++ CVE-2019-20387: Add 0001_CVE-2019-20387.patch. Resolves heap-based buffer
+  over-read in repodata.c (Closes: #949611).
++ 1006_various-types.patch: Trivial rebase.
+
+ -- Mike Gabriel   Thu, 30 Jan 2020 22:35:28 
+0100
+
 libsolv (0.6.35-2) unstable; urgency=medium
 
   * debian/changelog: White-space cleanup in previous stanza.
diff -Nru libsolv-0.6.35/debian/patches/0001_CVE-2019-20387.patch 
libsolv-0.6.35/debian/patches/0001_CVE-2019-20387.patch
--- libsolv-0.6.35/debian/patches/0001_CVE-2019-20387.patch 1970-01-01 
01:00:00.0 +0100
+++ libsolv-0.6.35/debian/patches/0001_CVE-2019-20387.patch 2020-01-30 
18:50:22.0 +0100
@@ -0,0 +1,32 @@
+From fdb9c9c03508990e4583046b590c30d958f272da Mon Sep 17 00:00:00 2001
+From: Zhipeng Xie 
+Date: Tue, 6 Aug 2019 09:50:57 +0800
+Subject: [PATCH] repodata_schema2id: fix heap-buffer-overflow in memcmp
+
+When the length of last schema in data->schemadata is
+less than length of input schema, we got a read overflow
+in asan test.
+
+Signed-off-by: Zhipeng Xie 
+---
+ src/repodata.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/src/repodata.c
 b/src/repodata.c
+@@ -205,11 +205,13 @@
+   cid = schematahash[h];
+   if (cid)
+ {
+-  if (!memcmp(data->schemadata + data->schemata[cid], schema, len * 
sizeof(Id)))
++  if ((data->schemata[cid] + len <= data->schemadatalen) &&
++!memcmp(data->schemadata + data->schemata[cid], 
schema, len * sizeof(Id)))
+ return cid;
+   /* cache conflict, do a slow search */
+   for (cid = 1; cid < data->nschemata; cid++)
+-if (!memcmp(data->schemadata + data->schemata[cid], schema, len * 
sizeof(Id)))
++if ((data->schemata[cid] + len <= data->schemadatalen) &&
++  !memcmp(data->schemadata + data->schemata[cid], 
schema, len * sizeof(Id)))
+   return cid;
+ }
+   /* a new one */
diff -Nru libsolv-0.6.35/debian/patches/1006_various-types.patch 
libsolv-0.6.35/debian/patches/1006_various-types.patch
--- libsolv-0.6.35/debian/patches/1006_various-types.patch  2018-08-20 
12:35:15.0 +0200
+++ libsolv-0.6.35/debian/patches/1006_various-types.patch  2020-01-30 
22:35:14.0 +0100
@@ -87,7 +87,7 @@
  *-l* 'PKGSPEC'::
 --- a/src/rules.c
 +++ b/src/rules.c
-@@ -1583,7 +1583,7 @@
+@@ -1607,7 +1607,7 @@
  
if (allowedarchs.count && pool->implicitobsoleteusescolors && installed 
&& bestscore)
{
diff -Nru libsolv-0.6.35/debian/patches/series 
libsolv-0.6.35/debian/patches/series
--- libsolv-0.6.35/debian/patches/series2018-04-24 12:45:47.0 
+0200
+++ libsolv-0.6.35/debian/patches/series2020-01-30 22:35:14.0 
+0100
@@ -1,2 +1,3 @@
 1004_cmake-module-path-fix.patch
 1006_various-types.patch
+0001_CVE-2019-20387.patch

Bug#939766: [pkg-cryptsetup-devel] Bug#939766: Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.

[Guilhem Moulin]

On Tue, 14 Jan 2020 at 03:22:20 +0100, Guilhem Moulin wrote:
> If there is a need for a complex logic I guess this could be done once
> and for all in /usr/share/initramfs-tools/hook-functions.

Quick follow up about this: asked Ben for feedback and he agreed that it
would make sense to do it in initramfs-tools.  That's #950254; I'm not
merging the bugs on closing -1 until this is actually implemented, but
we'll hopefully have a fine solution for all packaging using
pthread_cancel() & friends soon :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#851747: sysvinit-utils: drop Essential flag

[Andreas Henriksson]

Hello Thorsten Glaser,

On Thu, Jan 30, 2020 at 07:17:49PM +0100, Thorsten Glaser wrote:
> On Thu, 30 Jan 2020, Andreas Henriksson wrote:
> 
> > the binary packages built from it where downloaded, checked if it
> > had any init script, if it used vars.sh, and if there was a service
> 
> One of mine popped up, and, while I might investigate into
> writing a systemd service for it,

In my opinion it's just time (well overdue if you ask me) that
/everything/ gets native systemd units. The sysvinit compatibility is
just a compatibility shim. It doesn't give you many of the advantages of
systemd that someone using systemd would expect.

As a "side effect" we also happen to get looser coupling that benefits
this case.

(Also feel free to ask for help mentioning which package it is.)

> I wonder: the use of vars.sh goes along with use of
> /lib/lsb/init-functions (which lintian tells users to add a dependency
> on lsb-base for).
> 
> Would it be absurd to let lsb-base pull in vars.sh?

I don't think that's needed as vars.sh (and sysvinit-utils) is
(and likely always will be) guaranteed to be installed on a
sysvinit(-core) system.

The sysvinit-core, sysv-rc, initscripts packages all declare dependency
on sysvinit-utils already (despite sysvinit-utils being Essential: yes).
And IMHO atleast one of those should stay (after Essential: yes has been
dropped).

> 
> If we did that, would most of these be fixed, or just a
> small amount?

I want less coupling, not more... and on that subject I recently filed a
bug about sysvinit-utils gaining a dependency on lsb-base (making it
pseudo-essential).
Given that exists, it's not possible for lsb-base to depend on
sysvinit-utils as it would cause a circular dependency.

Regards,
Andreas Henriksson

Bug#916649: [pkg-cryptsetup-devel] Bug#916649: `/etc/init.d/cryptdisks stop` should ignore devices holding / and /usr

[Guilhem Moulin]

Control: tag -1 pending

Hi there,

I believe


https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/863e91f0e763b92a5f70d84278116a28357e74eb

should fix this, but I had to refactor a bit so would appreciate some
extra tests before releasing the fix.  You can apply the above manually
(after its parent 1d97d98a), but I can also upload to experimental if
you prefer :-)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#949763: python-azure: please consider uploading a new version

[Luca Boccassi]

control: tags -1 patch

On Fri, 24 Jan 2020 17:04:36 + Luca Boccassi 
wrote:
> Source: python-azure
> Version: 20181112+git-3
> Severity: wishlist
> Blocks: 930413
> 
> Dear Maintainer(s),
> 
> Please consider uploading the latest version of python-azure. It is
> needed for the upload of azure-cli.
> 
> If time is lacking, I'm happy to do an NMU.
> 
> Thank you!

Dear Maintainer(s),

I have opened MRs on Salsa to update the package:

https://salsa.debian.org/python-team/modules/python-azure/merge_requests/1
https://salsa.debian.org/python-team/modules/python-azure/merge_requests/2
https://salsa.debian.org/python-team/modules/python-azure/merge_requests/3

At the same time the MR also fixes build reproducibility.

dh_python indicates some missing dependencies, I'll check if they are
mandatory or optional.

Unless there are any objections and/or plans to update the package by
the maintainers, I plan to do a delayed NMU with these changes later
next week once the deps are sorted. I'll send another notice with a
debdiff if/when I do so.

Thanks!

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#950188: gcc-snapshot: FTBFS on hurd-i386

[Svante Signell]

On Thu, 2020-01-30 at 19:46 +0100, Matthias Klose wrote:
> On 1/29/20 10:35 PM, Svante Signell wrote:
> > Source: gcc-snapshot
> > Version: 1:20200124-1
> > Severity: important
> > Tags: patch
> > User: debian-h...@lists.debian.org
> > Usertags: hurd
> > 
> > Hi,
> > 
> > gcc-snapshot FTBFS on hurd-i386 due to missing patches for
> > gccgo. Attached are the three patches needed for a successful
> > build. This bug has been reported and assigned upstream, see
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468
> > but not yet committed.

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? 

> > One thing is confusing:
> > According to upstream you can report bugs against gcc-10, but not
> > upstream. However, in Debian you have both gcc-10-* in experimental
> > and gcc-snapshot in sid. Are these based on the same upstream
> > sources?
> > 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.

See above.

Thanks a lot for your maintaining gcc, et al!

Bug#902061: works for me

[Stefan Monnier]

> it worked for me, because I have a separate /boot partition. After
> changing the uuid of /boot, the machine does not boot.
>
> But IMO it's a problem of grub, using this sort of code in grub.cfg:
>
> if [ x$feature_platform_search_hint = xy ]; then
>   search --no-floppy --fs-uuid --set=root  
> 31147a1b-b3d3-1234-93ee-93854ac2505d
> else
>   search --no-floppy --fs-uuid --set=root 31147a1b-b3d3-1234-93ee-93854ac2505d
> fi
>
> If if would not use uuids here, it may work.

IIRC, this part was not problematic: Grub came up and it did load the
relevant kernel (and initrd), thanks presumably to "sane fallback
defaults".  The problem showed up later when the initrd script somehow
insisted on cheking for the presence of the partition with the
relevant UUID.


Stefan

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Thu, 30 Jan 2020 01:26:09 +0100 Johannes Schauer wrote:

[...]
> the problem is fixed when TMPDIR gets unset for hook.

Wait, does this change the result?

I mean: some commands executed (directly or indirectly) by
setup-testbed perform operations on the directory which mmdebstrap set
up as TMPDIR.
If this is the case (as I think it is, at least for the udev hook
called by update-initramfs), I wonder whether unsetting TMPDIR causes
setup-testbed to perform some of its operations on the wrong directory...

Am I completely off-track?

-- 
 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


pgppmHhNb_ly0.pgp
Description: PGP signature

Bug#949898: casacore-data-jplde 2007.07.05+ds.1-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 949898 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: casacore-data-jplde
Version: 2007.07.05+ds.1-0+deb10u1

Explanation: include tables up to 2040

Bug#950238: lintian: Expand init.d-script-should-always-start-service with NO_START

[Andreas Henriksson]

On Thu, Jan 30, 2020 at 02:11:34PM +0100, Andreas Henriksson wrote:
> On Thu, Jan 30, 2020 at 01:06:32PM +0100, Andreas Henriksson wrote:
> > Package: lintian
> > Version: 2.15.0
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Please consider expanding the init.d-script-should-always-start-service
> > tag with also matching on NO_START. That should catch a few more cases.
> > 
> > There seems to exist both these variants:
> > FOO_NO_START=
> > NO_START=
> [...]
> START=no
[...]

Another popular one seems to be:
START_DAEMON

As used in eg. minidlna, mdadm, wicd, 

Regards,
Andreas Henriksson

Bug#950204: transition: pcl

[Paul Gevers]

Control: tags -1 confirmed

Hi Jochen,

On 30-01-2020 22:25, Jochen Sprickerhof wrote:
>> Is the autotracker [1] correct? Then, let this bug know but you can go
>> ahead.
>>
>> [1] https://release.debian.org/transitions/html/auto-pcl.html
> 
> Good point, a rebuild of ros-pcl-conversions is needed as well, because
> it encodes the PCL version into it's cmake files in the binary package
> but doesn't depend on any .so. I don't see a way to teach that to ben,
> though¹.

Maybe somebody (Emilio?) knows?

> Should I fill a separate NMU request or could you schedule that
> one as well?

We'll do it from here. Please ping this bug if you notice we forgot.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Michael Biebl]

Hi Felipe

Am 30.01.20 um 22:30 schrieb Felipe Sateler:
> 
> 
> On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl  > wrote:
> 
> Am 28.01.20 um 17:27 schrieb Ansgar:
> > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
> >> Am 28.01.20 um 14:59 schrieb Ansgar:
> >>> I tried linking systemd-{sysusers,tmpfiles} statically against
> >>> systemd's private library earlier this month.  It increases the
> >>> binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
> >>> systemd that is just one percent).
> >>
> >> Is that 100K per binary?
> >
> > I checked my notes at it was 100 kB per binary: they are 212 kB larger
> > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested with
> > systemd 243-8.
> >
> > It might be possible to make it a bit smaller if one was to somehow
> > link libsystemd0 for functions available there (libsystemd-shared
> > currently duplicates those).
> 
> 
> That is not possible. There is global state that is not to be shared.
> See https://github.com/systemd/systemd/pull/3516#issuecomment-227482524

What's your thought on how to solve this libsystemd-shared issue should
we consider splitting out systemd-{sysusers,tmpfiles}

- link statically (and carry a downstream patch for eternity)
- move libsystemd-shared to systemd-utils and risk the breakage that can
result from a partial/aborted upgrade
- copy, instead of move, the binaries + libsystemd-shared and make the
resulting systemd-utils package Conflict with systemd (instead of having
systemd depend on systemd-utils)
- something else?

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#950279: RM: pcl [armel] -- ROM; does not build anymore

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal

Hi ftp-masters,

could you please remove the binary packages of pcl, python-pcl
and ros-pcl-conversions on armel? Starting with version 1.10, PCL does
not build anymore on that architecture (hitting the limits of the
address space).

For reference: This was done already for mips and mipsel in #917078.

Thanks!

Jochen

Bug#950273: uwsgi: missing-systemd-service-for-init.d-script

[Andreas Henriksson]

Control: forcemerge 833067 -1

On Thu, Jan 30, 2020 at 09:24:17PM +0100, Andreas Henriksson wrote:
> Source: uwsgi
> Version: 2.0.18-7
> Severity: normal
> 
> Dear Maintainer,
> 
> Please consider shipping a native systemd service masking the
> currently shipped init script (fixing lintian tag[1] in subject).
[...]

Sorry for the noise. I see now that this has already been discussed
in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833067

If someone has interest in working on this, but the only problem
stopping them being not being comfortable with systemd I'd recommend
reaching out to the pkg-systemd-maintainers mailing list where people
are generally helpful in giving helpful systemd related feedback as
long as someone knows how their application/daemon works internally.

FWIW I personally gave a quick glance at the init script and at first it
seemed like it was a simple script that would be quite straight forward,
then I noticed the complicated logic was hidden in the do_command
script. My next thought was that maybe a systemd service file would
simply wrap the do_command script, but unfortunately it can't be
used directly because it relies on being imported from something that
has already imported LSB functionality (which can mostly be disabled
by setting VERBOSE=no, but not all cases unfortunately - eg.
log_message_done). I didn't investigate further.

Regards,
Andreas Henriksson

Bug#938819: wheel: Python2 removal in sid/bullseye

[Dmitry Shachnev]

Hi,

On Thu, Jan 30, 2020 at 10:15:12PM +0100, Ondrej Novy wrote:
> čt 30. 1. 2020 v 10:10 odesílatel Dmitry Shachnev  napsal:
> > setuptools-scm has removed Python 2 support (see #938470), so python-keyring
> > build-dependencies are no longer satisfiable.
> >
> > Thus I am going to remove Python 2 support from python-keyring
>
> please don't, because #938470 should be reverted.

Ok, if that is reverted I can delay it a bit.

However upstream python-keyring has dropped Python 2 support, and I want
to upgrade to a newer release, so Python 2 support will be dropped sooner
or later.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#950276: [Pkg-utopia-maintainers] Bug#950276: network-manager: nm fails to establish connection using usb wlan with predictable device name

[Michael Biebl]

Am 30.01.20 um 22:15 schrieb Jürgen Bausa:

>> That said, this feels like a driver/hardware issue to me.
> 
>> It shouldn't matter what name the interface gets as long as it respects
> 
>> IFNAMSIZ
> 
>  
> 
> It is reproducabel: works as usb-wlan, does not work with the long name.


I'm interested if this is actually a matter of how long the name is.
Could you start with "usb-wlan" and add characters to that bit by bit to
see when it starts failing?

Michael





signature.asc
Description: OpenPGP digital signature

Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Felipe Sateler]

On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl  wrote:

> Am 28.01.20 um 17:27 schrieb Ansgar:
> > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
> >> Am 28.01.20 um 14:59 schrieb Ansgar:
> >>> I tried linking systemd-{sysusers,tmpfiles} statically against
> >>> systemd's private library earlier this month.  It increases the
> >>> binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
> >>> systemd that is just one percent).
> >>
> >> Is that 100K per binary?
> >
> > I checked my notes at it was 100 kB per binary: they are 212 kB larger
> > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested with
> > systemd 243-8.
> >
> > It might be possible to make it a bit smaller if one was to somehow
> > link libsystemd0 for functions available there (libsystemd-shared
> > currently duplicates those).
>

That is not possible. There is global state that is not to be shared.
See https://github.com/systemd/systemd/pull/3516#issuecomment-227482524

-- 

Saludos,
Felipe Sateler

Bug#950204: transition: pcl

[Jochen Sprickerhof]

Control: tags -1 - moreinfo

Hi Paul,

* Paul Gevers  [2020-01-30 18:41]:

On 30-01-2020 07:11, Jochen Sprickerhof wrote:

I would like to transition pcl to the new ABI version. I tested and
updated it's build-rdeps, so I don't expect any problems. Note that the
new version doesn't build on armel anymore due to virtual memory
exhaustion. I will ask the ftp-masters to remove the old binary after I
uploaded the new version.


Is the autotracker [1] correct? Then, let this bug know but you can go
ahead.

[1] https://release.debian.org/transitions/html/auto-pcl.html


Good point, a rebuild of ros-pcl-conversions is needed as well, because 
it encodes the PCL version into it's cmake files in the binary 
package but doesn't depend on any .so. I don't see a way to teach that 
to ben, though¹. Should I fill a separate NMU request or could you 
schedule that one as well?


Cheers Jochen

¹: I could probably list both affected packages manually, but I don't 
think that's a nice. Maybe we could use the buildinfo files for this in 
some future..


signature.asc
Description: PGP signature

Bug#950267: gobject-introspection is built for only one Python 3 version, but has a dependency python3:any

[Simon McVittie]

On Thu, 30 Jan 2020 at 20:21:08 +0100, Matthias Klose wrote:
> gobject-introspection is built for only one Python 3 version, but has a
> dependency python3:any.  This doesn't seem to be correct.  The _giscanner
> module/extension is only built for the default Python3 version.
> 
> Can the package be built for all supported Python3 version? Or should the
> dependency on the default Python version be made explicit?

The default Python version at build-time should probably be made explicit
(so right now it would be python3 (>= 3.7), python3 (<< 3.8)) and updated
by a binNMU when the default changes. It probably needs to pass options
to dh_python3, so that dh_python3 will find its private modules.

gobject-introspection.deb is a set of command-line tools that has private
Python code (with a C extension) as an implementation detail, not an
independently importable Python library, so I don't think it makes a whole
lot of sense to compile it for all supported Python versions in parallel.

Is this urgent to fix? I was hoping to get a bit more progress on the
libffi7 transition (in particular a fix for #950219) before uploading
gobject-introspection again.

Thanks,
smcv

Bug#950219: ruby-gnome: please Build-Depend on libgirepository1.0-dev (>= 1.62.0-4~) and libffi-dev (>= 3.3)

[Simon McVittie]

Control: severity -1 serious
Control: block 949185 by -1
Control: user debian...@lists.debian.org
Control: usertags -1 + regression

On Thu, 30 Jan 2020 at 08:48:22 +, Simon McVittie wrote:
> To prevent broken partial upgrades, please make ruby-gnome Build-Depend
> on libgirepository1.0-dev (>= 1.62.0-4~) and libffi-dev (>= 3.3);
> this will result in a runtime dependency on
> libgirepository-1.0-0 (>= 1.62.0-4~) and libffi7, preventing (A).
> Then we can add a Breaks: ruby-gobject-introspection (<< x~) in
> libgirepository-1.0-0, where x is the version in which you made that
> change, to prevent (B).

Not having this in place seems to be causing autopkgtest regressions
for gobject-introspection that will prevent the libffi transition from
migrating, so I'm increasing this to RC severity.

cjs, gjs and libglib-object-introspection-perl have already had the
equivalent change, so this is the last one that is needed before we can
add all the necessary versioned Breaks in libgirepository-1.0-0.

Thanks,
smcv

Bug#935304: libpam-systemd: Please relax Depends: systemd-sysv

[Michael Biebl]

On Tue, 28 Jan 2020 07:08:17 -0500 Sam Hartman  wrote:
> > "Mark" == Mark Hindley  writes:
> 
> Mark> Thanks for your considered response. I understand and accept that 
> you don't
> Mark> think this is the correct solution to the issue.
> 
> Mark> However, the underlying issue of how to facilitate migration of a 
> system from
> Mark> libpam-systemd to libpam-elogind remains. Do you have other 
> suggestions of how
> Mark> we might address this or find a solution?
> 
> I'm very interested in michael's response.  I wanted to make Mark aware
> of a likely future discussion.  With his policy hat on, Russ said he's
> going to start a discussion on debian-devel about how to track
> dependencies on system services rather than on packages.
> So, for example, to track the availability of the tmpfiles service,
> rather than simply that systemd or opentmpfiles  is installed.
> 
> I think Russ is aware of the elogind issues, but I think bringing those
> issues up in that discussion or reaching out to Russ would both be good
> ideas.
> 
> That may be a more long-term solution.
> So, I think it would still be great to get any input Michael has here.

Tbh, I'm not sure what kind of answer you expect from me.

I guess I already provided my feedback here and mentioned what kind of
solution I prefer. I can repeat this in this bug report, but I'm not
sure if this is helpful.

If I misunderstood what your intentions are, I apologize. Please be more
specific then.

Michael



signature.asc
Description: OpenPGP digital signature

Bug#938819: wheel: Python2 removal in sid/bullseye

[Ondrej Novy]

Hi,

čt 30. 1. 2020 v 10:10 odesílatel Dmitry Shachnev 
napsal:

> setuptools-scm has removed Python 2 support (see #938470), so
> python-keyring
> build-dependencies are no longer satisfiable.
>
> Thus I am going to remove Python 2 support from python-keyring


please don't, because #938470 should be reverted.

-- 
Best regards
 Ondřej Nový

Bug#949853: tigervnc 1.7.0+dfsg-7+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 949853 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: tigervnc
Version: 1.7.0+dfsg-7+deb9u1

Explanation: security updates [CVE-2019-15691 CVE-2019-15692 CVE-2019-15693 
CVE-2019-15694 CVE-2019-15695]

Bug#940477: tmpreaper 1.6.13+nmu1+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 940477 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: tmpreaper
Version: 1.6.13+nmu1+deb9u2

Explanation: add `--protect '/tmp/systemd-private*/*'` to cron job to prevent 
breaking systemd services that have PrivateTmp=true

Bug#948715: xml-security-c 1.7.3-4+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 948715 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: xml-security-c
Version: 1.7.3-4+deb9u2

Explanation: fix "DSA verification crashes OpenSSL on invalid combinations of 
key content

Bug#949838: perl 5.24.1-3+deb9u6 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 949838 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: perl
Version: 5.24.1-3+deb9u6

Explanation: fix interpretation of years from 2020 onwards