Bug#945926: KDE on Debian 10.2, dual (HDMI & VGA) monitors: Can no longer login through lock screen to same session after disconnecting and reconnecting HDMI monitor

[Judah Richardson]

Package: kde-plasma-desktop
Version: 5:102

Debian Release: 10.2
uname -a: Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)
x86_64 GNU/Linux

Introduction: I have a Debian 10 machine running KDE, described fully
(config, specs, software, etc.) here
.
I had the screen locked using CTRL+ALT+L, which makes the lock screen login
dialog show up on both monitors when the mouse is clicked.

Bug: I recently temporarily disconnected the HDMI monitor from the Debian
10 machine's HDMI port so I could connect the monitor to another machine.
Upon reconnecting the HDMI monitor, the monitor shows a blank screen with a
static cursor. The VGA monitor still shows the lock screen on mouse click,
but when I click the password field to enter my password, no cursor appears
and when I type no characters appear, either.

Expected behavior: I should be able to click the password field and log
back into the desktop session

Bug#919218: non-transition: libqt5gui5-gles

[Graham Inggs]

Hi Dmitry

On Fri, 29 Nov 2019 at 23:03, Dmitry Shachnev  wrote:
> Thanks for setting up the tracker! Given that libqt5gui5-gles package has
> reached testing now, would it be possible to start binNMUs?
>
> As I said earlier, they can be done in any order and not necessarily all
> at once.
>
> Some packages are already green in the tracker. They do not need any action.
> Also, no rebuilds are needed on armel and armhf as on these architectures Qt
> uses OpenGL ES by default.

I started with a binNMU of 2048-qt [1] on its own.

It didn't have the effect on the tracker that I was expecting [2].
Would you please check the binaries and let me know if I should
continue with the rest?

Does the tracker need some adjustment?

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=2048-qt
[2] https://release.debian.org/transitions/html/libqt5gui5-gles.html

Bug#945346: python-skbio ftbfs in unstable

[Andreas Tille]

Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 https://github.com/biocore/scikit-bio/issues/1681

Bug#945925: buster-pu: package gnutls28/3.6.7-4+deb10u1

[Andreas Metzler]

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

Good morning,

I would like to see #933538 fixed in buster, which is a interoperability
problem with old (2.x, that is wheezy) versions of gnutls.

cu Andreas
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   /usr/lib/debug/.build-id/1a/591272a07d9e6d0140db75455b9b4bcc8eeddd.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/1c/a9574531f2bffce01464c8a654b2e0c2ed894b.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/5e/61e31c2ae39982eeb14ae1c8f66aff43e1083a.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/74/0d1a42bc21c173d6a991375b0d8ddb934ec0bd.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/8b/c687d446ade64a2f7c29950e17eda1a2e91e11.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/b1/7a60f0701c7de3d7e5e921305846b5efbc3c91.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/b8/bd0e5aecb48c352850674891129476d08d016a.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/be/692a24b17141539bbe9fe246bbde637669ecff.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/c0/fe9421f82709abe4e7d487af28fd7402ffbb53.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/cb/6160515c1e9b0c02a1d6751325e360b590b83e.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/f3/e7c24dbf4184d814468b89270b4c40cb205b8c.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/f8/818eb8e83e9bd9a3c0cfb9b9cbb656bd1f288b.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/fa/92b545084722f485080b95a6eca92571ece25f.debug

Files in first .changes but not in second
-
-rw-r--r--  root/root   /usr/lib/debug/.build-id/0f/f0796530c37d210935e7808160fd89b3303092.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/11/06d4483482f51e9f04c4fffbf164e0348ba5d3.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/13/874b86eafc2b2965ff1853c87ee6df7987c581.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/4d/66d28cd2e7537e1e1d2905595b260226b22ad2.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/55/58da73c3d0c1fae464c8c1c206dea6279aa5b2.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/70/0562a775625daa6f3892bbd4bfdf2478537723.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/b2/ada5bc7ee4fc083e4a45bd6b2b2b2c5257e68e.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/b4/d85fa0bcde4dd34ea2de34f8bac96e9244b058.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/c4/444a7b5a7906fc1eeca540d1d91064c4a92a3e.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/d1/9c1bb870c8ec979ea276b8f584cddc80e2da61.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/d3/28298de34135fca5f236357f2f2dd56cb109f3.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/d7/52158b357b5875ebc8680001b57a886b94a1a4.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/fe/4c3c0c38af44779c38ae5d1e187b6250f7afe0.debug

Control files of package gnutls-bin: lines which differ (wdiff format)
--
Installed-Size: [-1587-] {+1588+}
Version: [-3.6.7-4-] {+3.6.7-4+deb10u1+}

Control files of package gnutls-bin-dbgsym: lines which differ (wdiff format)
-
Build-Ids: [-0ff0796530c37d210935e7808160fd89b3303092 1106d4483482f51e9f04c4fffbf164e0348ba5d3 13874b86eafc2b2965ff1853c87ee6df7987c581 5558da73c3d0c1fae464c8c1c206dea6279aa5b2 700562a775625daa6f3892bbd4bfdf2478537723 b2ada5bc7ee4fc083e4a45bd6b2b2b2c5257e68e b4d85fa0bcde4dd34ea2de34f8bac96e9244b058 ca7b5a7906fc1eeca540d1d91064c4a92a3e d19c1bb870c8ec979ea276b8f584cddc80e2da61-] {+1a591272a07d9e6d0140db75455b9b4bcc8eeddd 740d1a42bc21c173d6a991375b0d8ddb934ec0bd 8bc687d446ade64a2f7c29950e17eda1a2e91e11 be692a24b17141539bbe9fe246bbde637669ecff c0fe9421f82709abe4e7d487af28fd7402ffbb53 cb6160515c1e9b0c02a1d6751325e360b590b83e f3e7c24dbf4184d814468b89270b4c40cb205b8c f8818eb8e83e9bd9a3c0cfb9b9cbb656bd1f288b fa92b545084722f485080b95a6eca92571ece25f+}
Depends: gnutls-bin (= [-3.6.7-4)-] {+3.6.7-4+deb10u1)+}
Version: [-3.6.7-4-] {+3.6.7-4+deb10u1+}

Control files of package gnutls-doc: lines which differ (wdiff format)
--
Installed-Size: [-7334-] {+7335+}
Version: [-3.6.7-4-] {+3.6.7-4+deb10u1+}

Control files of package libgnutls-dane0: lines which differ (wdiff format)
---
Depends: libgnutls30 (= [-3.6.7-4),-] {+3.6.7-4+deb10u1),+} libc6 (>= 2.14), libunbound8 (>= 1.8.0)
Installed-Size: [-369-] {+370+}
Version: [-3.6.7-4-] {+3.6.7-4+deb10u1+}

Control files of package libgnutls-dane0-dbgsym: lines which differ (wdiff format)
-

Bug#944389: lxc: Fails to work with cgroupv2 / unified hierarchy

[Ryutaroh Matsumoto]

Package: lxc
Version: 1:3.1.0+really3.0.4-2
Followup-For: Bug #944389

Dear Maintainer,

This problem can be worked around by adding

lxc.cgroup.devices.deny =
lxc.cgroup.devices.allow =

to the end of /var/lib/lxc/test-container/config

LXC does not support the V2 device controller until very recently
https://github.com/lxc/lxc/commit/637de040ae55216a0551a35c23ff0de99cd6d719

So there should be no harm of adding 
lxc.cgroup.devices.deny =
lxc.cgroup.devices.allow =

Best regards,
Ryutaroh Matsumoto

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.29-3
ii  libgcc11:8.3.0-6
ii  liblxc11:3.1.0+really3.0.4-2
ii  lsb-base   10.2019051400

Versions of packages lxc recommends:
ii  apparmor 2.13.2-10
ii  bridge-utils 1.6-2
ii  debootstrap  1.0.114
ii  dirmngr  2.2.12-1+deb10u1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  gnupg2.2.12-1+deb10u1
ii  iproute2 4.20.0-2
ii  iptables 1.8.2-4
pn  libpam-cgfs  
ii  lxc-templates3.0.4-1
pn  lxcfs
ii  nftables 0.9.0-2
ii  openssl  1.1.1c-1
ii  rsync3.1.3-8
ii  uidmap   1:4.5-1.1

Versions of packages lxc suggests:
pn  btrfs-progs  
ii  lvm2 2.03.02-3
pn  python3-lxc  

-- debconf information:
  lxc/auto_update_config:

Bug#945924: qemu-system-data: Should "Provides: sgabios"?

[intrigeri]

Package: qemu-system-data
Version: 1:4.1-2
Severity: normal

Hi,

I see that qemu-system-data 1:4.1-2 now Conflicts+Replaces sgabios.
On upgrades, this leads to the removal of libguestfs packages,
since libguestfs0 depends on sgabios:

  
https://qa.debian.org/dose/debcheck/unstable_main/latest/packages/libguestfs0.html

If qemu-system-data now ships the files that libguestfs0 needs,
that were previously in the sgabios package,
perhaps qemu-system-data should have "Provides: sgabios",
so its co-installable with libguestfs packages?

Cheers,
-- 
intrigeri

Bug#877783: RFS: spyne/2.13.11a0-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Sandro Tosi]

> I am looking for a sponsor for the package "spyne" which has a
> py2removal RC bug and will be autoremoved on December 13th. The package
> is Python 2 only but the current alpha version has Python 3 support. I
> uploaded a Python 3 compatible package in January and referenced it in
> #877783 but did not get any response from the maintainer.
>
> Now that the bug is RC I think that it is time for a NMU and hope to
> find a sponsor for the package.

I've reviewed and uploaded the package to DELAYED-5 (since it's a NMU
for a new alpha version in unstable), so that the maintainer may have
a chance to voice their concerns/opinions. Thanks for your
contribution to Debian!

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

Bug#945763: gcc-9 ftbfs on mipsel

[YunQiang Su]

YunQiang Su  于2019年11月30日周六 上午11:19写道：
>
> YunQiang Su  于2019年11月29日周五 下午2:21写道：
> >
> > 在 2019-11-29五的 07:00 +0100，Matthias Klose写道：
> > > On 28.11.19 18:09, YunQiang Su wrote:
> > > > Matthias Klose  于2019年11月28日周四 下午5:51写道：
> > > > > On 28.11.19 10:44, Matthias Klose wrote:
> > > > > > Package: src:gcc-9
> > > > > > Version: 9.2.1-20
> > > > > > Severity: serious
> > > > > > Tags: sid bullseye
> > > > > >
> > > > > > gcc-9 ftbfs on mipsel with a bootstrap comparison failure, most
> > > > > > likely triggered
> > > > > > by the LTO build enabled in -20.
> > > > > >
> > > > > > bootstrap comparison failure!
> > > > > > libbacktrace/elf.o differs
> > > > > > libbacktrace/.libs/elf.o differs
> > > > > > make[4]: *** [Makefile:24878: compare] Error 1
> > > > >
> > > > > Please could you have a look?
> > > >
> > > > sure. I will look at it tomorrow
> > >
> > > hmm, that also fails in gcc-7, which didn't see any code changes from
> > > 7.5.0-1 to
> > > 7.5.0-2.
> >
> > Maybe, it meets a buggy machine?
>
> due to the Loongson's patch to add sync?

I am sure that this is due to that change.
So, please rollback that changes for now. I will try to dig out why.

>
> >
>
>
> --
> YunQiang Su



-- 
YunQiang Su

Bug#945923: ntfs-3g: Please consider installing the library to /usr/lib/ instead of /lib/

[Boyuan Yang]

Source: ntfs-3g
Version: 1:2017.3.23AR.3-3
Severity: minor

Dear ntfs-3g maintainer,

I just noticed that the library for ntfs-3g is currently installed
into /lib/. With the trend of usrmerge as well as Debian's gradual
adaptation of usrmerge, it is no longer necessary to override default
installation path for libraries. Please consider installing the
library files into /usr/lib/*/ instead of /lib/*.

Thanks,
Boyuan Yang

Bug#945922: please move/copy systemd.pc out of the daemon package

[Adam Borowski]

Source: systemd
Version: 243-9
Severity: normal

Hi!
The pkg-config file for systemd is in the daemon package, rather than a -dev
package as one would expect.  This means that the maintainer of any package
that uses this .pc has to either:
* make it unbuildable without a chroot
* drop systemd support
* reinvent what .pc would provide

In some cases the last option is reasonable but still hacky, like:
  
https://github.com/kilobyte/ndctl/commit/fce6efb8bf5f39b6a4de13b5961e56abba6bd4ef
but it can get nastier when recursive dependencies are involved.

Because of bin:systemd's special status, the usual ways of gracefully moving
a file would be obnoxious, I propose to, in one package, ship systemd.pc in
/usr/share/pkgconfig/, and in the other, in /usr/lib/$MULTIARCH/pkgconfig/
-- pkg-config's path search makes it DTRT, and, with a hard versioned
dependency, it can't possibly get out of sync.


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

Kernel: Linux 5.4.0-00165-gb4bade9f1b7d (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#945869: lintian: false positive for debian-rules-not-executable

[gregor herrmann]

On Sun, 01 Dec 2019 12:30:00 +1100, Stuart Prescott wrote:

> Checking that the file mode is exactly 0755 when all that is actually desired 
> is that the file be executable seems wrong.

Ack, and getting this message for each and every package I build gets
a bit boring ("my" debian/rules are 775 as well).
 
> checks/debian/rules.pm:
> 
># Check if debian/rules is marked as executable. 
>$self->tag('debian-rules-not-executable') 
>  unless $rules->operm == 0755 or $rules->is_symlink; 
> 
> perhaps a better test would be (my perl is rather rusty):
> 
>  $rules->operm & 0111

I also note that lib/Lintian/Path.pm has

sub is_executable { return $_[0]->_any_bit_in_operm(0111); }

which might be reusable for this test.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: David Bowie: Young Americans


signature.asc
Description: Digital Signature

Bug#945921: handle rules with multiple targets

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.41
Severity: normal

Multiple targets in a rule currently trip up the makefile parser.

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-3
ii  python3-breezy   3.0.2-1
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.13-1+b1
ii  python3-levenshtein  0.12.0-3+b2
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.1
ii  lintian2.39.0
ii  python3-asyncpg0.18.3-2
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  210

-- no debconf information

Bug#945920: Chromium randomly crashes in the latest version.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: chromium
Version: 79.0.3945.56-1
Severity: important

After updating to the latest version, Chromium randomly crashes after a while.
There are no error messages. It happens randomly and just abruptly quits.
There is no "dmesg" messages generated.
I used a temporary profile and it will still happen.

Stack trace:

Received signal 11 SEGV_MAPERR 
#0 0x5653d1480469 
#1 0x5653d13c9a76 
#2 0x5653d147ec63 
#3 0x5653d14803e6 
#4 0x7ffa7263b510 
#5 0x5653d27ed107 
#6 0x5653d0ffd850 
#7 0x5653d0ff5922 
#8 0x5653d1424b35 
#9 0x5653d143403b 
#10 0x5653d14359bc 
#11 0x5653d13e649a 
#12 0x7ffa7171bf3d g_main_context_dispatch
#13 0x7ffa7171c1c0 
#14 0x7ffa7171c24f g_main_context_iteration
#15 0x5653d13e67a0 
#16 0x5653d1435c79 
#17 0x5653d1411cca 
#18 0x5653d0f17cb7 
#19 0x5653cf23d046 
#20 0x5653cf23d1f5 
#21 0x5653cf213477 
#22 0x5653d0e9fba1 
#23 0x5653d0e9fdd8 
#24 0x5653d0ea0147 
#25 0x5653d0ed62a2 
#26 0x5653d0e9db66 
#27 0x5653ce3cc425 ChromeMain
#28 0x7ffa6bae __libc_start_main
#29 0x5653ce3cc26a _start
  r8: 5653dc28af00  r9: 0001 r10: 5653da8dd010 r11: 
7ffa6bc7ec40
 r12: 7ffcf239ae50 r13: 7ffcf239ae30 r14: 7ffcf239ae50 r15: 
5653dc3ae940
  di:   si: 7ffcf239ae30  bp: 7ffcf239adf0  bx: 

  dx: 7ffcf239ae50  ax: 7ff9dc002810  cx: 5653dc45bb20  sp: 
7ffcf239adb0
  ip: 5653d27ed107 efl: 00010202 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: 
[end of stack trace]
Calling _exit(1). Core file will not be generated.
--
Please limit your reply to 7-bit ASCII.
I refuse to see your idiotic emoji in a TTY.
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBcBAEBCAAGBQJd4ySwAAoJENi1YDlFXXQfDFEH/1VzTV+JyJ7ody7FMorh
dSJ+l60HtPNxDrxRCgGydNzJzJHu47FPHqgiwetNeXgNJGEULiyr/XPk0JLQ
6bliAMCjdFJvIth0hBsINPRZK+Oh5f+gUiF1M1CDikwL7CGxc34zeCODscJ2
kTakc5ikZdFMlHg6UnizY+qX0VyETUGEtZb0FwoGUC9UOrJWJTUBHQnK6Umv
jweGFoypgZWyqp9UOsgLeAfWf3OEWMKYOGH1TtasjS7WSIbvd+OncxAYiC9+
0AY7e/TxRqD/h7GxK0DO5CLCWkG6ulvsHyG5hCohYetboluZehXy30aq4REF
tkc6gKGNto1EoWMdcvb1A2A=
=j/ZR
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#945919: ITP: r-bioc-geoquery -- Get data from NCBI Gene Expression Omnibus (GEO)

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-geoquery -- Get data from NCBI Gene Expression Omnibus 
(GEO)
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-geoquery
  Version : 2.54.1
  Upstream Author : Sean Davis 
* URL : https://bioconductor.org/packages/GEOquery/
* License : GPL-2
  Programming Lang: GNU R
  Description : Get data from NCBI Gene Expression Omnibus (GEO)
 The NCBI Gene Expression Omnibus (GEO) is a public repository of
 microarray data. Given the rich and varied nature of this resource, it
 is only natural to want to apply BioConductor tools to these data.
 GEOquery is the bridge between GEO and BioConductor.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-geoquery

Bug#945911: APT leaks repository credentials

[Florian Zumbiehl]

> > The credentials to transmit for a request are selected not based on the
> > host name specified in the sources.list, but rather based on the URI that
> > is being requested. Thus, any repository server that APT ever makes an
> > HTTP(S) request to can issue an HTTP redirect to any URI that points to any
> > of the (other) servers for which credentials are stored in the auth.conf
> > file, and APT will then send those credentials to whatever endpoint that is
> > specified as the redirection target URI.
> 
> Yes, and why please tell, should that be a problem? That's how stuff

Because it might allow operations to happen that the user did not intend to
allow.

> works. If I requests https://a/b/c and it redirects me to https://x/y/z,
> I need login details for x/y/z to login.

It may well be that you _need_ them. But that doesn't say anything about
whether you should _get_ them.

When a web server instructs a browser to submit some request to a different
origin, that request may also _need_ credentials for that other origin to
perform some operation. But just allowing any web server to submit requests
to any other origin with all credentials the browser knows about still is
considered a vulnerability, known as "cross site request forgery".

Just because https://x/y/z needs credentials to be accessed, does not mean
that https://a/b/c should be allowed to cause such an access.

> Saying we should send the credentials for a/b/c to x/y/z does not make
> a whole lot of sense.

Indeed, it doesn't, and maybe I was not entirely clear on this, but I
certainly didn't intend to suggest anything like that.

> This also assumes that you have access to the a/b/c server _and_ the
> x/y/z server.

Yes ... so?!

> > Examples for how this could be exploited are:
> > 
> > - The redirect could point to a different port on the server than where the
> >   repository is hosted, possibly an unprivileged port where an attacker on
> >   that server could be listening to receive the credentials.
> 
> I don't understand. FWIW; credentials can be limited by port, and path.

Yes, they can. But it is absolutely not clear from the documentation that
you are vulnerable to this type of attack if you don't do that. And even if
this were stated clearly in the documentation, it would still be bad
default behaviour.

> > - The redirect could point to an HTTP URI to expose the credentials as
> >   plain text on the wire, even where the sources.list entries for the
> >   respective server point only to HTTPS URIs to protect from eavesdroppers.
> 
> HTTPS->HTTP redirects are not allowed.

Well, that's good, I suppose? But it's also irrelevant for this attack
scenario?!

> > - The redirect could point to an existing resource in the repository the
> >   credentials are actually meant for in order to make APT download that
> >   resource and then use it in a context it wasn't meant for, thus
> >   potentially leaking contents of the password-protected repository.
> 
> I don't understand.

You specify in the sources.list:

| deb http://public.mirror.example/debian buster main

In auth.conf:

| machine internal.server.example
| login top
| password secret

Now, when you request some package list or something from
public.mirror.example, public.mirror.example could redirect you to
http://internal.server.example/whatever/file, and APT would then treat that
file as if it were the packages list that is found on public.mirror.example
- I suppose?

I haven't tried to build a PoC for this, so no clue how exactly you would
exploit this particular scenario.

Bug#945918: ITP: libflame -- High-performance object-based library for DLA computations

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 
X-Debbugs-CC: debian-scie...@lists.debian.org

* Package name: libflame
  Version : x.y.z
  Upstream Author : Field G. Van Zee / UT Austin
* URL : https://github.com/flame/libflame
* License : BSD-3-Clause
  Programming Lang: C
  Description : High-performance object-based library for DLA computations

LAPACK implementation. Faster than existing ones (free) in our archive.

{BLAS=openblas/blis LAPACK=libflame} shows a significant
speed gain in sgesvd (single-precision SVD) compared to
{BLAS=openblas/blis LAPACK=netlib/openblas}

I didn't compare it with MKL. It's unnecessary.

Bug#945917: jh_build: JH_JAR_EXTRA is ignored

[Frédéric Perrin]

Package: javahelper
Version: 0.72.9
Severity: normal

Dear Maintainer,

Option JH_JAR_EXTRA is ignored by jh_build. When setting the script
variable from the environment, the code looks at the existing value,
rather than the env. IOW, it should be:

diff -U0 jh_build.orig jh_build
--- jh_build.orig   2019-12-01 00:25:24.162770395 +
+++ jh_build2019-12-01 00:35:58.528043183 +
@@ -121 +121 @@
-@JH_JAR_EXTRA = split(' ', $ENV{'JH_JAR_EXTRA'}) if @JH_JAR_EXTRA;
+@JH_JAR_EXTRA = split(' ', $ENV{'JH_JAR_EXTRA'}) if $ENV{JH_JAR_EXTRA};



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

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

Versions of packages javahelper depends on:
ii  bsdmainutils 11.1.2+b1
ii  dctrl-tools  2.24-3
ii  debhelper12.1.1
ii  devscripts   2.19.5+deb10u1
ii  dpkg-dev 1.19.7
ii  libarchive-zip-perl  1.64-1
ii  perl 5.28.1-6

javahelper recommends no packages.

javahelper suggests no packages.

-- no debconf information

Bug#945869: lintian: false positive for debian-rules-not-executable

[Stuart Prescott]

Checking that the file mode is exactly 0755 when all that is actually desired 
is that the file be executable seems wrong.

checks/debian/rules.pm:

   # Check if debian/rules is marked as executable. 
   $self->tag('debian-rules-not-executable') 
 unless $rules->operm == 0755 or $rules->is_symlink; 

perhaps a better test would be (my perl is rather rusty):

 $rules->operm & 0111

cheers
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#945051: [debian-mysql] Bug#945051: galera-3: incompatible with fs.protected_regular = 1

[Alexander E. Patrakov]

This is now fixed upstream:

https://github.com/MariaDB/server/pull/1417

Bug#945916: Need to install openssh-server to read documentation of ~/.ssh/known_hosts

[積丹尼 Dan Jacobson]

Package: openssh-client
Version: 1:8.1p1-1
Severity: wishlist

ssh man page says:

  ~/.ssh/known_hosts
 Contains a list of host keys for all hosts the user has logged 
into that are not already in the systemwide list of known host keys.  See 
sshd(8) for further
 details of the format of this file.

Alas, one needs to install the openssh-server package to see this page.
Despite being a need of simple clients.

Bug#940695: micro-httpd FTCBFS: uses the build architecture compiler

[Sudip Mukherjee]

Hi Helmut,

On Thu, Sep 19, 2019 at 06:07:45AM +0200, Helmut Grohne wrote:
> Source: micro-httpd
> Version: 20051212-15.1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> micro-httpd fails to cross build from source, because debian/rules uses
> the build architecture compiler as a make default for CC. The easiest
> way of fixing that is letting dpkg's buildtools.mk initialize it. Please
> consider applying the attached patch.

> diff --minimal -Nru micro-httpd-20051212/debian/rules 
> micro-httpd-20051212/debian/rules
> --- micro-httpd-20051212/debian/rules 2016-07-02 18:14:04.0 +0200
> +++ micro-httpd-20051212/debian/rules 2019-09-19 06:04:09.0 +0200
> @@ -4,6 +4,7 @@
>  BIN  = micro_httpd
>  
>  include debian/debian-vars.mk
> +-include /usr/share/dpkg/buildtools.mk

I think the attached patch will be better. I have tested it on multiple
arcchtectures now and plannig to add it to the next upload.
Please let me know if you have any concern with my patch.

--
Regards
Sudip
>From ebab8af1d226f328b21b16a69f624b257446504e Mon Sep 17 00:00:00 2001
From: Sudip Mukherjee 
Date: Sat, 30 Nov 2019 23:18:22 +
Subject: [PATCH] fix crosscompilation

Use DEB_HOST_GNU_TYPE with CC to crosscompile from source.

Signed-off-by: Sudip Mukherjee 
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 4d42214..c46c6cd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,7 @@ export DH_VERBOSE=1
 
 PACKAGE = micro-httpd
 BIN	= micro_httpd
+CC	= $(DEB_HOST_GNU_TYPE)-gcc
 
 include debian/debian-vars.mk
 
-- 
2.20.1

Bug#908559: openvpn: Openvpn cannot run /sbin/ip if started from systemd

[Anthony DeRobertis]

This is because /bin/ip can have cap_sys_admin set on it, and the 
capability bounding set in the unit doesn't allow that. The simple fix 
is to add cap_sys_admin to the CapabilityBoundingSet in the systemd 
service file.


... of course, cap_sys_admin is (last I checked) quite powerful, so 
maybe that renders CapabilityBoundingSet moot; but without it, openvpn 
won't work.

Bug#937647: marked as done (python-cliapp: Python2 removal in sid/bullseye)

[Antonio Terceiro]

On Fri, Nov 29, 2019 at 08:47:15PM -0500, Sandro Tosi wrote:
> >* QA upload
> >* Drop python2 support (Closes: #937647)
> >* Run tests during build and under autopkgtest
> 
> there are still 2 rdeps
> http://sandrotosi.me/debian/py2removal/python-cliapp_1.svg !

Yes.

$ reverse-depends python-cliapp
Reverse-Depends
===
* live-wrapper
* vmdebootstrap

Packages without architectures listed are reverse-dependencies in: amd64, 
arm64, armel, armhf, i386, mipsel, ppc64el, s390x
$ rmadison live-wrapper vmdebootstrap
live-wrapper  | 0.6+nmu1  | oldstable| source, all
live-wrapper  | 0.8   | stable   | source, all
live-wrapper  | 0.10  | unstable | source, all
vmdebootstrap | 0.5-2 | oldoldstable | source, amd64, armel, armhf, i386
vmdebootstrap | 1.7-1 | oldstable| source, amd64, arm64, armel, 
armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
vmdebootstrap | 1.11-2| stable   | source, amd64, arm64, armel, 
armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
vmdebootstrap | 1.11-2| unstable | source, amd64, arm64, armel, 
armhf, i386, mips64el, mipsel, ppc64el, s390x

Both are out of testing. vmdebootstrap is deprecated, and its removal is
pending; live-wrapper uses vmdebootstrap, and needs to migrate away from
it. more info:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910201

IMO there is no point in blocking on those two.


signature.asc
Description: PGP signature

Bug#945915: ganeti: Ganeti 2.16.0 (buster) fails to work with Ceph versions Mimic and Nautilus

[Martin Weinelt]

Package: ganeti
Version: 2.16.0-5
Severity: important
Tags: upstream patch

Dear Maintainer,

usage of RBD from Ceph versions Mimic (13.x) and Nautilus (14.x) isn't
working due to a change in the `rbd showmapped` JSON output. The
error blocks VM startup.

ERROR: instance vm.example.com: couldn't retrieve status for disk/0 on 
vmhost.example.com: Error while executing backend function: 'list' object has 
no attribute 'values'

Upstream has a fix that can be easily backported: 
https://github.com/ganeti/ganeti/commit/fa9a8fc1

in fact I already tested this locally and it got things working.


-- Package-specific info:
Version symlinks:
  /etc/ganeti/share -> /usr/share/ganeti/2.16
  /etc/ganeti/lib -> /usr/lib/ganeti/2.16
Cluster config version: 2.16.0
Address family: IPv4
Enabled hypervisors: kvm
kvm hypervisor parameters:
  acpi=True
  boot_order=disk
  cpu_cores=0
  cpu_mask=all
  cpu_sockets=0
  cpu_threads=0
  cpu_type=host
  disk_aio=threads
  disk_cache=default
  disk_discard=default
  disk_type=paravirtual
  kernel_args=ro
  keymap=de
  kvm_path=/usr/bin/kvm
  kvm_pci_reservations=4
  migration_bandwidth=110
  migration_caps=postcopy-ram
  migration_downtime=200
  migration_mode=live
  migration_port=8102
  nic_type=paravirtual
  reboot_behavior=reboot
  root_path=/dev/vda1
  scsi_controller_type=lsi
  security_model=none
  serial_console=True
  serial_speed=115200
  spice_ip_version=0
  spice_playback_compression=True
  spice_tls_ciphers=HIGH:-DES:-3DES:-EXPORT:-DH
  spice_use_tls=False
  spice_use_vdagent=True
  use_chroot=False
  use_guest_agent=False
  use_localtime=False
  user_shutdown=False
  vhost_net=True
  virtio_net_queues=1
  vnc_bind_address=127.0.0.1
  vnc_password_file=/etc/ganeti/vnc-cluster-password
  vnc_tls=False
  vnc_x509_verify=False
  vnet_hdr=True

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

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

Versions of packages ganeti depends on:
ii  adduser  3.118
ii  ganeti-2.16  2.16.0-5
ii  ganeti-haskell-2.16  2.16.0-5
ii  ganeti-htools-2.16   2.16.0-5
ii  lsb-base 10.2019051400
ii  python   2.7.16-1

Versions of packages ganeti recommends:
ii  drbd-utils   9.5.0-1
ii  fdisk2.33.1-0.1
ii  ganeti-instance-debootstrap  0.16-6
ii  ndisc6   1.0.4-1
ii  qemu-kvm 1:3.1+dfsg-8+deb10u3

Versions of packages ganeti suggests:
pn  blktap-dkms  
ii  ganeti-doc   2.16.0-5
pn  molly-guard  

-- no debconf information

Bug#945914: Sound broken on Intel Baytrail and Broadwell platforms (regression from bug 940726)

[David Ward]

Package: linux
Version: 5.3.7-1
Severity: important
Owner: Salvatore Bonaccorso 
Tags: patch

The kernel configuration change from Debian bug 940726 is invalid, 
according to Intel: https://bugzilla.kernel.org/show_bug.cgi?id=204237#c15


The options for the SST and SOF drivers for Baytrail/Broadwell cannot 
both be set. This will be enforced via Kconfig beginning in Linux 5.5-rc1:


   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=df7257e544faf838c3e7ad6b4e89ffe59e87f5e1
   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=a6955fe0e2309feeab5ec71e4b0dcbe498f4f497

Intel does not consider SOF ready on these platforms yet. 
https://github.com/thesofproject/linux/pull/1382#discussion_r344755772


The following two lines that were just added in 
debian/config/amd64/config need to be removed:


   CONFIG_SND_SOC_SOF_BAYTRAIL_SUPPORT=y
   CONFIG_SND_SOC_SOF_BROADWELL_SUPPORT=y

This is applicable to sid, bullseye, and buster-backports. Thank you.
diff --git a/debian/config/amd64/config b/debian/config/amd64/config
index 1e35491..161a760 100644
--- a/debian/config/amd64/config
+++ b/debian/config/amd64/config
@@ -295,8 +295,6 @@ CONFIG_SND_SOC_SOF_ACPI=m
 ## file: sound/soc/sof/intel/Kconfig
 ##
 CONFIG_SND_SOC_SOF_INTEL_TOPLEVEL=y
-CONFIG_SND_SOC_SOF_BAYTRAIL_SUPPORT=y
-CONFIG_SND_SOC_SOF_BROADWELL_SUPPORT=y
 CONFIG_SND_SOC_SOF_MERRIFIELD_SUPPORT=y
 CONFIG_SND_SOC_SOF_APOLLOLAKE_SUPPORT=y
 CONFIG_SND_SOC_SOF_GEMINILAKE_SUPPORT=y

Bug#945913: atlas: Arch definitions for m68k

[John Paul Adrian Glaubitz]

Source: atlas
Version: 3.10.3-8
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

I have created the arch definitions for m68k, see attached.

Those were generated on an emulated Mac Quadra 800 with 68040.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


GENERIC32.tar.bz2
Description: BZip2 compressed data

Bug#945881: bgpdump: Segmentation fault

[Christoph Biedl]

Control: tag 945881 pending

Valentin Vidic wrote...

> The program segfaults when started:
>
> $ bgpdump 
> Segmentation fault

Ouch. Thanks for reporting - reason was a failed attempt to make
hardening build work, plus another mess which eventually resulted in no
tests being run at all during build - else it would have been noticed.

This will see a fix as soon as possible. Also in stable (buster).

Christoph


signature.asc
Description: PGP signature

Bug#945912: Kernel 5.3 e100e Detected Hardware Unit Hang

[Russell Mosemann]

Package: linux-image-5.3.0-0.bpo.2-amd64
Severity: important

Dear Maintainer,

   * What led up to the situation?
 
Installed kernel 5.2 and 5.3 on two physical hosts in a KVM virtual cluster, 
each host with two bonded Ethernet ports. After some random amount of time that 
ranges from right after booting to several hours later, the e1000e driver hangs 
and all heck breaks loose with kernel errors. This has happened on both hosts.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 
This problem does not occur with kernel 4.19. I reverted to kernel 4.19.

   * What was the outcome of this action?
 
Using kernel 4.19 fixes the e1000e hang problem.

   * What outcome did you expect instead?
 
Networking would work perfectly in kernels 5.2 and 5.3, just like it does in 
4.19.
 
The hang occurs with eth1 and the e1000e driver, which involves the Intel I210 
Gb adapter.

# lspci | grep I2
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 
05)
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection 
(rev 03)
 
# Lines from the journal during boot
 
Nov 30 04:47:57 vhost002 kernel: e1000e: Intel(R) PRO/1000 Network Driver - 
3.2.6-k
Nov 30 04:47:57 vhost002 kernel: e1000e: Copyright(c) 1999 - 2015 Intel 
Corporation.
Nov 30 04:47:57 vhost002 kernel: e1000e :00:19.0: Interrupt Throttling Rate 
(ints/sec) set to dynamic conservative mode
Nov 30 04:47:57 vhost002 kernel: igb: Intel(R) Gigabit Ethernet Network Driver 
- version 5.6.0-k
Nov 30 04:47:57 vhost002 kernel: igb: Copyright (c) 2007-2014 Intel Corporation.
Nov 30 04:47:57 vhost002 kernel: igb :02:00.0: PHY reset is blocked due to 
SOL/IDER session.
Nov 30 04:47:57 vhost002 kernel: igb :02:00.0: added PHC on eth0
Nov 30 04:47:57 vhost002 kernel: igb :02:00.0: Intel(R) Gigabit Ethernet 
Network Connection
Nov 30 04:47:57 vhost002 kernel: igb :02:00.0: eth0: (PCIe:2.5Gb/s:Width 
x1) d0:50:99:c0:38:b6
Nov 30 04:47:57 vhost002 kernel: igb :02:00.0: eth0: PBA No: 001300-000
Nov 30 04:47:57 vhost002 kernel: igb :02:00.0: Using MSI-X interrupts. 4 rx 
queue(s), 4 tx queue(s)
Nov 30 04:47:57 vhost002 kernel: e1000e :00:19.0 :00:19.0 
(uninitialized): registered PHC clock
Nov 30 04:47:57 vhost002 kernel: e1000e :00:19.0 eth1: (PCI 
Express:2.5GT/s:Width x1) d0:50:99:c0:38:b7
Nov 30 04:47:57 vhost002 kernel: e1000e :00:19.0 eth1: Intel(R) PRO/1000 
Network Connection
Nov 30 04:47:57 vhost002 kernel: e1000e :00:19.0 eth1: MAC: 11, PHY: 12, 
PBA No: FF-0FF
Nov 30 04:47:58 vhost002 kernel: Ethernet Channel Bonding Driver: v3.7.1 (April 
27, 2011)
Nov 30 04:47:58 vhost002 kernel: bonding: bond0 is being created...
Nov 30 04:47:58 vhost002 systemd-udevd[387]: Could not generate persistent MAC 
address for bond0: No such file or directory
Nov 30 04:47:59 vhost002 kernel: igb :02:00.0 eth0: igb: eth0 NIC Link is 
Up 1000 Mbps Full Duplex, Flow Control: RX
Nov 30 04:47:59 vhost002 kernel: bond0: (slave eth0): Enslaving as a backup 
interface with an up link
Nov 30 04:47:59 vhost002 kernel: bond0: (slave eth1): Enslaving as a backup 
interface with a down link
Nov 30 04:47:59 vhost002 kernel: bond0: Warning: No 802.3ad response from the 
link partner for any adapters in the bond
Nov 30 04:47:59 vhost002 kernel: bond0: (slave eth0): link status definitely 
up, 1000 Mbps full duplex
Nov 30 04:47:59 vhost002 kernel: bond0: active interface up!
Nov 30 04:47:59 vhost002 systemd-udevd[445]: link_config: autonegotiation is 
unset or enabled, the speed and duplex are not writable.
Nov 30 04:47:59 vhost002 systemd-udevd[445]: Could not generate persistent MAC 
address for kvmbr0: No such file or directory
Nov 30 04:47:59 vhost002 ifup[781]: Waiting for a max of 0 seconds for bond0 to 
become available.
Nov 30 04:47:59 vhost002 kernel: bridge: filtering via arp/ip/ip6tables is no 
longer available by default. Update your scripts to load br_netfilter if you 
need this.
Nov 30 04:47:59 vhost002 kernel: kvmbr0: port 1(bond0) entered blocking state
Nov 30 04:47:59 vhost002 kernel: kvmbr0: port 1(bond0) entered disabled state
Nov 30 04:47:59 vhost002 kernel: device bond0 entered promiscuous mode
Nov 30 04:47:59 vhost002 kernel: device eth0 entered promiscuous mode
Nov 30 04:47:59 vhost002 kernel: device eth1 entered promiscuous mode
Nov 30 04:47:59 vhost002 kernel: kvmbr0: port 1(bond0) entered blocking state
Nov 30 04:47:59 vhost002 kernel: kvmbr0: port 1(bond0) entered forwarding state
Nov 30 04:47:59 vhost002 ifup[781]: Waiting for kvmbr0 to get ready (MAXWAIT is 
2 seconds).
Nov 30 04:47:59 vhost002 avahi-daemon[711]: Joining mDNS multicast group on 
interface kvmbr0.IPv4 with address 192.168.0.237.
Nov 30 04:47:59 vhost002 avahi-daemon[711]: New relevant interface kvmbr0.IPv4 
for mDNS.
Nov 30 04:47:59 vhost002 avahi-daemon[711]: Registering new address record for 
192.168.0.237 on kvmbr0.IPv4.
Nov 30 04:47:59 vhost002 avahi-daemon[711]: Register

Bug#945911: APT leaks repository credentials

[Julian Andres Klode]

Control: tag -1 moreinfo

On Sat, Nov 30, 2019 at 10:36:29PM +0100, Florian Zumbiehl wrote:
> Package: apt
> Version: 1.8.2
> Severity: critical
> 
> APT now promotes using auth.conf to store repository credentials.
> Unfortunately, the way these credentials are handled causes a confused
> deputy style problem:
> 
> The credentials to transmit for a request are selected not based on the
> host name specified in the sources.list, but rather based on the URI that
> is being requested. Thus, any repository server that APT ever makes an
> HTTP(S) request to can issue an HTTP redirect to any URI that points to any
> of the (other) servers for which credentials are stored in the auth.conf
> file, and APT will then send those credentials to whatever endpoint that is
> specified as the redirection target URI.

Yes, and why please tell, should that be a problem? That's how stuff
works. If I requests https://a/b/c and it redirects me to https://x/y/z,
I need login details for x/y/z to login.

Saying we should send the credentials for a/b/c to x/y/z does not make
a whole lot of sense.

This also assumes that you have access to the a/b/c server _and_ the
x/y/z server.

> 
> Examples for how this could be exploited are:
> 
> - The redirect could point to a different port on the server than where the
>   repository is hosted, possibly an unprivileged port where an attacker on
>   that server could be listening to receive the credentials.

I don't understand. FWIW; credentials can be limited by port, and path.

> 
> - The redirect could point to an HTTP URI to expose the credentials as
>   plain text on the wire, even where the sources.list entries for the
>   respective server point only to HTTPS URIs to protect from eavesdroppers.

HTTPS->HTTP redirects are not allowed.

> 
> - The redirect could point to an existing resource in the repository the
>   credentials are actually meant for in order to make APT download that
>   resource and then use it in a context it wasn't meant for, thus
>   potentially leaking contents of the password-protected repository.

I don't understand.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#943791: general: laptop HP 15_bw0xx does not power-off properly

[christian.quentin]

Hi, sorry for answering late. I had no access to the PC to run the 
test.Actually the splash parameter was not set. I started linux without the 
quiet parameter then stopped it with : sudo shutdown -h now  as you 
suggested.Same behaviour: the PC displays briefly a few lines then goes to a 
black screen but does not power off.ChristianEnvoyé depuis mon smartphone Linux 
Android
 Message d'origine De : Marc Haber 
 Date : 05/11/2019  10:26  (GMT+01:00) À : 
Christian Quentin , 
943...@bugs.debian.org, 943791-submit...@bugs.debian.org Objet : Re: 
Bug#943791: general: laptop HP 15_bw0xx does not power-off
  properly On Tue, Oct 29, 2019 at 09:18:19PM +0100, Christian Quentin wrote:> 
* when I ask Debian to stop (from Gnome), the shutdown sequence seems to 
follow> the usual steps, the a blank screen appears.The screen is not 
completely off.> The PC does not power-off.> * As the PC does not stop, I have 
to press the power button 10 seconds which> does not seem to be the best way to 
stop a computer.> * I would expect the shutdown sequence to power-off the 
computer completely.> * Hint : shutting down Windows 10 (also present on this 
computer) works fine.What does happen when you start your Debian without the 
"quiet splash"boot option and shut it down with "sudo shutdown -h 
now"?GreetingsMarc

Bug#945836: zanshin does not built with new KDEPIM 19.08

[Sandro Knauß]

Control: severity -1 serious

Hey,

the KDEPIM 19.08 transition [1] got accepted.  That's why I raise the severity 
to serious.

hefee

[1] https://release.debian.org/transitions/html/kdepim-19.08.html

--
On Freitag, 29. November 2019 15:54:18 CET Sandro Knauß wrote:
> Package: zanshin
> Version: 0.5.0-2+b1
> Severity: normal
> Tags: patch
> Control: block 945619 by -1
> 
> Hey,
> 
> zanshin doesn't built with KDEPIM 19.08 (currently waiting in experimental).
> Mostly because KCalCore got a cleanup and API change in order to move to
> KDE Frameworks. I requested a merge request (!1) on salsa to fix that.
> 
> hefee
> 
> !1: https://salsa.debian.org/qt-kde-team/extras/zanshin/merge_requests/1
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
> 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1,
> 'experimental') Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages zanshin depends on:
> ii  kio  5.62.1-2
> ii  libc62.29-3
> ii  libgcc1  1:9.2.1-19
> pn  libkf5akonadicalendar5   
> pn  libkf5akonadicalendar5-18.08 
> ii  libkf5akonadicalendar5abi1   4:19.08.2-1~
> ii  libkf5akonadicontact54:19.08.2-1~
> pn  libkf5akonadicontact5-18.08  
> pn  libkf5akonadicore5   
> pn  libkf5akonadicore5-18.08 
> ii  libkf5akonadicore5abi2   4:19.08.2-1~
> ii  libkf5akonadinotes5  4:19.08.2-1~
> pn  libkf5akonadinotes5-18.08
> ii  libkf5akonadisearchpim5  4:19.08.2-1~
> pn  libkf5akonadisearchpim5-18.08
> pn  libkf5akonadiwidgets5
> pn  libkf5akonadiwidgets5-18.08  
> ii  libkf5akonadiwidgets5abi14:19.08.2-1~
> pn  libkf5calendarcore5  
> pn  libkf5calendarcore5-18.08
> ii  libkf5calendarcore5abi2  4:19.08.2-1~
> ii  libkf5codecs55.62.0-1
> ii  libkf5completion55.62.0-1
> ii  libkf5configcore55.62.0-1
> ii  libkf5configgui5 5.62.0-1
> ii  libkf5configwidgets5 5.62.0-1
> ii  libkf5contacts5  4:19.08.2-1~
> pn  libkf5contacts5-18.08
> ii  libkf5coreaddons55.62.0-1
> ii  libkf5i18n5  5.62.0-1
> ii  libkf5identitymanagement519.08.2-1~
> pn  libkf5identitymanagement5-18.08  
> ii  libkf5itemmodels55.62.0-1
> ii  libkf5itemviews5 5.62.0-1
> ii  libkf5jobwidgets55.62.0-1
> ii  libkf5kdelibs4support5   5.62.0-2
> ii  libkf5kiocore5   5.62.1-2
> ii  libkf5kontactinterface5  19.08.2-1~
> pn  libkf5kontactinterface5-18.08
> pn  libkf5ldap5  
> pn  libkf5ldap5-18.08
> ii  libkf5ldap5abi1  19.08.2-1~
> pn  libkf5mime5  
> pn  libkf5mime5-18.08
> ii  libkf5mime5abi1  19.08.2-1~
> ii  libkf5parts5 5.62.0-1
> ii  libkf5runner55.62.0-1
> ii  libkf5wallet-bin 5.62.0-1
> ii  libkf5wallet55.62.0-1
> ii  libkf5widgetsaddons5 5.62.0-1
> ii  libkf5windowsystem5  5.62.0-2
> ii  libkf5xmlgui55.62.0-1+b1
> ii  libqt5core5a 5.12.5+dfsg-2
> ii  libqt5dbus5  5.12.5+dfsg-2
> ii  libqt5gui5   5.12.5+dfsg-2
> ii  libqt5network5   5.12.5+dfsg-2
> ii  libqt5widgets5   5.12.5+dfsg-2
> ii  libstdc++6   9.2.1-19
> 
> zanshin recommends no packages.
> 
> zanshin suggests no packages.




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

Bug#855151: #855151: tasksel: should not be Priority: important

[Cyril Brulebois]

Hi,

Holger Wansing  (2019-11-30):
> Cyril Brulebois  wrote:
> > Thinking about this change a little more, even if we were to publish D-I
> > Bullseye Alpha 1 right now, which will be tested to be working… I think
> > once ftp-masters update their overrides, this will break the published
> > Alpha immediately.
> > 
> > Instead of rushing a change right now (it's been months without a
> > release already), I think I'll ask them to postpone updating their
> > overrides until we're up for an Alpha 2. Which means we'll have a clear
> > breakage at the timing of our choosing, a way to double check the
> > effects of the bug, and to ensure proposed patches do the work
> > appropriately, instead of implementing things blindly in a hurry, right
> > now.
> 
> Maybe, it would be the better way to force installation of tasksel in the
> installer (because we need it there), instead of relying on other things
> (package dependencies, which may change over time)?

That's the plan, yes. Just not for the first alpha. (I don't think I
mentioned dependencies, but you might have thought priorities anyway?
;))

> Means something like adding a postinst hook script in pkgsel...

I didn't dive into it yet, but out of the blue, that looks like a good
place to start from, indeed.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#945911: APT leaks repository credentials

[Florian Zumbiehl]

Package: apt
Version: 1.8.2
Severity: critical

APT now promotes using auth.conf to store repository credentials.
Unfortunately, the way these credentials are handled causes a confused
deputy style problem:

The credentials to transmit for a request are selected not based on the
host name specified in the sources.list, but rather based on the URI that
is being requested. Thus, any repository server that APT ever makes an
HTTP(S) request to can issue an HTTP redirect to any URI that points to any
of the (other) servers for which credentials are stored in the auth.conf
file, and APT will then send those credentials to whatever endpoint that is
specified as the redirection target URI.

Examples for how this could be exploited are:

- The redirect could point to a different port on the server than where the
  repository is hosted, possibly an unprivileged port where an attacker on
  that server could be listening to receive the credentials.

- The redirect could point to an HTTP URI to expose the credentials as
  plain text on the wire, even where the sources.list entries for the
  respective server point only to HTTPS URIs to protect from eavesdroppers.

- The redirect could point to an existing resource in the repository the
  credentials are actually meant for in order to make APT download that
  resource and then use it in a context it wasn't meant for, thus
  potentially leaking contents of the password-protected repository.

IMO, credential use should be limited based on the the URI that was derived
from the sources.list to prevent such exploits: The user should be able to
trust that when they specify credentials for a specific server, say, then
only sources.list entries that name that server get to use those
credentials.

Note: I did not investigate the source on this, I just tested this manually
with socat, redirecting from one hostname to a different hostname on a
random port, and in that scenario I got the credentials for the redirection
target. So, it is possible that some of the scenarios above actually don't
work for some reason, though it seems unlikely.

Bug#944764: abcm2ps: please package 8.14.6

[Nicolas Boulenguez]

Hello.
Patrice's suggestions are attached as git-format patches (2 to 4).
Would you mind an NMU sponsoring them?
Would you mind us becoming Uploaders?
May I create g...@salsa.debian.org:debian/abcm2ps.git, in order to ease
such contributions?
Thanks.
Please CC me.
>From 5758cb4926cf5b781b95a35e3baef8264d9ef9f7 Mon Sep 17 00:00:00 2001
From: Patrice Duroux 
Date: Sat, 30 Nov 2019 22:35:08 +0100
Subject: [PATCH 2/4] Add upstream/metadata.

---
 debian/upstream/metadata | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 debian/upstream/metadata

diff --git a/debian/upstream/metadata b/debian/upstream/metadata
new file mode 100644
index 000..c357fd3
--- /dev/null
+++ b/debian/upstream/metadata
@@ -0,0 +1,5 @@
+Contact: moin...@free.fr
+Name: abcm2ps
+Homepage: http://moinejf.free.fr/
+Repository: https://github.com/leesavide/abcm2ps.git
+Repository-Browse: https://github.com/leesavide/abcm2ps/
-- 
2.20.1

>From 03ced2e84bd658e25ad5250bda37122a3a6addee Mon Sep 17 00:00:00 2001
From: Patrice Duroux 
Date: Sat, 30 Nov 2019 22:35:35 +0100
Subject: [PATCH 3/4] Simplify watch.

---
 debian/watch | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/debian/watch b/debian/watch
index 1b7b7e4..1731513 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,5 +1,2 @@
 version=4
-
-opts=\
-  filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/abcm2ps-$1\.tar\.gz/ \
-https://github.com/leesavide/abcm2ps/releases .*/v?(\d\S+)\.tar\.gz
+https://github.com/leesavide/@PACKAGE@/releases .*/v?@ANY_VERSION@@ARCHIVE_EXT@
-- 
2.20.1

>From 498d5cc1f4a4572e07ec348e557ba4a74837ba9b Mon Sep 17 00:00:00 2001
From: Patrice Duroux 
Date: Sat, 30 Nov 2019 22:40:00 +0100
Subject: [PATCH 4/4] Move to Standards-Version: 4.4.1

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index b35b002..f2adcfc 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends:
  libpango1.0-dev,
  pkg-config,
  python3-docutils,
-Standards-Version: 4.4.0
+Standards-Version: 4.4.1
 Rules-Requires-Root: no
 Homepage: http://moinejf.free.fr/
 
-- 
2.20.1

Bug#945910: opensmtpd: Never sends out email submitted via /usr/sbin/sendmail while smtpd was not running

[Alexander E. Patrakov]

Package: opensmtpd
Version: 6.6.1p1-1
Severity: important

Dear Maintainer,

I was surprised that OpenSMTPD lost a cron mail that cron managed to submit
while smtpd was not running (stopped temporarily for maintenance). I
expected smtpd to send it later, when I start it, but the message just kept
sitting in /var/spool/smtpd/offline.

So, to reproduce:

1. Install OpenSMTPD. The issue is reproducible both in Debian Stable
   and Unstable and needs to be fixed in both.
2. It starts up and creates the hierarchy under /var/spool/smtpd.
3. Stop it, just to pretend that it was stopped and forgotten by accident.
4. Create a "mail.txt" file with mail headers, blank line, and body.
5. Send it: sendmail -f y...@yourmail.com -t < mail.txt
6. At this point, /usr/sbin/sendmail returns 75 and puts the message into
   /var/spool/smtpd/offline, as expected.
7. systemctl restart opensmtpd

Expectation: smtpd should pick up the file from the offline queue.
Actual result:

# ls -l /var/spool/smtpd/offline
-rw--- 1 root root 237 Nov 30 18:08 1575137330.MwS8bP

The file just sits there, and smtpd ignores it.


This has been traced to the permission differences between OpenSMTPD
expectations (based on how it is shipped on OpenBSD) and the reality on
Debian systems.

First of all, OpenSMTPD contains code that checks permissions on the files
in the offline queue:

https://github.com/OpenSMTPD/OpenSMTPD/blob/c139eb1610e931739d6cde4194c9560124b08165/smtpd/smtpd.c#L1604

The directory is owned by root:opensmtpdq, and the file by root:root. The
mismatch can be attributed to two things:

1. Difference between the directory group semantics between BSD (where
   OpenSMTPD comes from) and Linux. On BSD, all directories behave like
   they do on Linux with the (Linux) setgid bit.

# ls -ld /var/spool/smtpd/offline
drwxrwx--- 2 root opensmtpq 6 Nov 30 21:40 /var/spool/smtpd/offline

2. Difference between the ownership of /usr/sbin/smtpctl:

OpenBSD: it is setgid.

# ls -l /usr/sbin/smtpctl
-r-xr-sr-x  1 root  _smtpq  217736 Oct 12 21:34 /usr/sbin/smtpctl

Linux: it is just a regular binary.

# ls -l /usr/sbin/smtpctl
-rwxr-xr-x 1 root root 211896 Nov 19 17:06 /usr/sbin/smtpctl

Therefore, it cannot create offline messages with the correct ownership.

In fact, fixing (1) makes offline mail work for root. Fixing (2) alone
makes it work for everyone.

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.12-arch1-1 (SMP w/8 CPU cores; PREEMPT) # LXC container
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE # wireguard
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages opensmtpd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  ed 1.15-1
ii  init-system-helpers1.56+nmu1
ii  libasr01.0.2-2
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libevent-2.1-7 2.1.11-stable-1
ii  libpam0g   1.3.1-5
ii  libssl1.1  1.1.1d-0+deb10u2
ii  lsb-base   10.2019051400
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages opensmtpd recommends:
pn  opensmtpd-extras  

Versions of packages opensmtpd suggests:
ii  ca-certificates  20190110

-- Configuration Files:
/etc/smtpd.conf changed [not included]

-- debconf information excluded

Bug#941218: guile-2.0: FTBFS on ppc64el

[Daniel Kolesa]

On Sat, Nov 30, 2019, at 22:42, Daniel Kolesa wrote:
> Hello,
> 
> On 9/26/19 5:45 PM, Gianfranco Costamagna wrote:
> > Source: guile-2.0
> > Version: 2.0.13+1-5.2
> > Severity: serious
> >
> >
> > Hello, looks like guile-2.0 FTBFS on ppc64el, probably after readline 
> > transition (Ubuntu has this problem since the rebuild against the new 
> > readline)
> >
> > I remember I tried to cherry-pick fixes from guile-2.2 but I didn't find 
> > anything related to this failure
> >
> >
> > cat alist.doc arbiters.doc array-handle.doc array-map.doc arrays.doc 
> > async.doc backtrace.doc boolean.doc bitvectors.doc bytevectors.doc 
> > chars.doc control.doc continuations.doc debug.doc deprecated.doc 
> > deprecation.doc dynl.doc dynwind.doc eq.doc error.doc eval.doc evalext.doc 
> > expand.doc extensions.doc feature.doc filesys.doc fluids.doc foreign.doc 
> > fports.doc gc-malloc.doc gc.doc gettext.doc generalized-arrays.doc 
> > generalized-vectors.doc goops.doc gsubr.doc guardians.doc hash.doc 
> > hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc list.doc 
> > load.doc macros.doc mallocs.doc memoize.doc modules.doc numbers.doc 
> > objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc 
> > procs.doc promises.doc r6rs-ports.doc random.doc rdelim.doc read.doc 
> > root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc 
> > srcprop.doc srfi-1.doc srfi-4.doc srfi-13.doc srfi-14.doc srfi-60.doc 
> > stackchk.doc stacks.doc stime.doc strings.doc strorder.doc strports.doc 
> > struct.doc symbols.doc threads.doc throw.doc trees.doc unicode.doc 
> > uniform.doc values.doc variable.doc vectors.doc version.doc vports.doc 
> > weaks.doc dynl.doc posix.doc net_db.doc socket.doc regex-posix.doc | 
> > GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 ../meta/build-env guild 
> > snarf-check-and-output-texi  > guile-procedures.texi || { rm 
> > guile-procedures.texi; false; }
> > make[4]: Leaving directory '/<>/libguile'
> > make[3]: Leaving directory '/<>/libguile'
> > Making all in module
> > make[3]: Entering directory '/<>/module'
> > GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
> > ../meta/build-env   \
> > guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
> > -Warity-mismatch -Wformat \
> >-L "/<>/module" -L "/<>/module"
> > \
> >-L "/<>/guile-readline" \
> >-o "ice-9/eval.go" "ice-9/eval.scm"
> > wrote `ice-9/eval.go'
> > GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
> > ../meta/build-env   \
> > guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
> > -Warity-mismatch -Wformat \
> >-L "/<>/module" -L "/<>/module"
> > \
> >-L "/<>/guile-readline" \
> >-o "ice-9/psyntax-pp.go" "./ice-9/psyntax.scm"
> > GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
> > ../meta/build-env   \
> > guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
> > -Warity-mismatch -Wformat \
> >-L "/<>/module" -L "/<>/module"
> > \
> >-L "/<>/guile-readline" \
> >-o "ice-9/boot-9.go" "ice-9/boot-9.scm"
> > GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
> > ../meta/build-env   \
> > guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
> > -Warity-mismatch -Wformat \
> >-L "/<>/module" -L "/<>/module"
> > \
> >-L "/<>/guile-readline" \
> >-o "ice-9/vlist.go" "ice-9/vlist.scm"
> > GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
> > ../meta/build-env   \
> > guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
> > -Warity-mismatch -Wformat \
> >-L "/<>/module" -L "/<>/module"
> > \
> >-L "/<>/guile-readline" \
> >-o "srfi/srfi-1.go" "srfi/srfi-1.scm"
> > Backtrace:
> > In ice-9/eval.scm:
> >   387: 19 [eval # #]
> >   387: 18 [eval # #]
> >   387: 17 [eval # #]
> >   387: 16 [eval # #]
> >   387: 15 [eval # #]
> >   440: 14 [eval # #]
> >   440: 13 [eval # #]
> >   411: 12 [eval # #]
> >   411: 11 [eval # #]
> >   411: 10 [eval # #]
> >   387: 9 [eval # #]
> >   432: 8 [eval # #]
> >   432: 7 [eval # #]
> >   471: 6 [eval # #]
> >   481: 5 [lp (#) (#f)]
> >   471: 4 [eval # #]
> >   486: 3 [eval # #]
> >   381: 2 [eval # #]
> > In unknown file:
> > ?: 1 [# > value: #> _>> #]
> > In ice-9/eval.scm:
> >   481: 0 [lp (#) ((#))]
> >
> > ice-9/eval.scm:481:19: guile: uncaught throw to unbound-variable: 
> > (module-lookup Unbound variable: ~S (apply-smob/1) #f)
> > make[3]: *** [Makefile:2238: ice-9/vlist.go] Error 1
> > make[3]: *** Waiting for unfinished jobs
> > Backtrace:
> > In ice-9/eval.scm:
> >   387: 19 [eval # #]
> >   387: 18 [eval # #]
> >   387: 17 [eval # #]
> >   387: 16 [eval # #]
> >   387: 15 [eval # #

Bug#941218: guile-2.0: FTBFS on ppc64el

[Daniel Kolesa]

Hello,

On 9/26/19 5:45 PM, Gianfranco Costamagna wrote:

Source: guile-2.0
Version: 2.0.13+1-5.2
Severity: serious


Hello, looks like guile-2.0 FTBFS on ppc64el, probably after readline 
transition (Ubuntu has this problem since the rebuild against the new readline)

I remember I tried to cherry-pick fixes from guile-2.2 but I didn't find 
anything related to this failure


cat alist.doc arbiters.doc array-handle.doc array-map.doc arrays.doc async.doc 
backtrace.doc boolean.doc bitvectors.doc bytevectors.doc chars.doc control.doc 
continuations.doc debug.doc deprecated.doc deprecation.doc dynl.doc dynwind.doc 
eq.doc error.doc eval.doc evalext.doc expand.doc extensions.doc feature.doc 
filesys.doc fluids.doc foreign.doc fports.doc gc-malloc.doc gc.doc gettext.doc 
generalized-arrays.doc generalized-vectors.doc goops.doc gsubr.doc guardians.doc 
hash.doc hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc list.doc 
load.doc macros.doc mallocs.doc memoize.doc modules.doc numbers.doc objprop.doc 
options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc promises.doc 
r6rs-ports.doc random.doc rdelim.doc read.doc root.doc rw.doc scmsigs.doc 
script.doc simpos.doc smob.doc sort.doc srcprop.doc srfi-1.doc srfi-4.doc 
srfi-13.doc srfi-14.doc srfi-60.doc stackchk.doc stacks.doc stime.doc strings.doc 
strorder.doc strports.doc struct.doc symbols.doc threads.doc throw.doc trees.doc 
unicode.doc uniform.doc values.doc variable.doc vectors.doc version.doc vports.doc 
weaks.doc dynl.doc posix.doc net_db.doc socket.doc regex-posix.doc | 
GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 ../meta/build-env guild 
snarf-check-and-output-texi  > guile-procedures.texi || { rm 
guile-procedures.texi; false; }
make[4]: Leaving directory '/<>/libguile'
make[3]: Leaving directory '/<>/libguile'
Making all in module
make[3]: Entering directory '/<>/module'
GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
../meta/build-env   \
guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
-Warity-mismatch -Wformat   \
   -L "/<>/module" -L "/<>/module"\
   -L "/<>/guile-readline"   \
   -o "ice-9/eval.go" "ice-9/eval.scm"
wrote `ice-9/eval.go'
GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
../meta/build-env   \
guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
-Warity-mismatch -Wformat   \
   -L "/<>/module" -L "/<>/module"
\
   -L "/<>/guile-readline"   \
   -o "ice-9/psyntax-pp.go" "./ice-9/psyntax.scm"
GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
../meta/build-env   \
guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
-Warity-mismatch -Wformat   \
   -L "/<>/module" -L "/<>/module"\
   -L "/<>/guile-readline"   \
   -o "ice-9/boot-9.go" "ice-9/boot-9.scm"
GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
../meta/build-env   \
guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
-Warity-mismatch -Wformat   \
   -L "/<>/module" -L "/<>/module"\
   -L "/<>/guile-readline"   \
   -o "ice-9/vlist.go" "ice-9/vlist.scm"
GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 \
../meta/build-env   \
guild compile --target="powerpc64le-unknown-linux-gnu" -Wunbound-variable 
-Warity-mismatch -Wformat   \
   -L "/<>/module" -L "/<>/module"\
   -L "/<>/guile-readline"   \
   -o "srfi/srfi-1.go" "srfi/srfi-1.scm"
Backtrace:
In ice-9/eval.scm:
  387: 19 [eval # #]
  387: 18 [eval # #]
  387: 17 [eval # #]
  387: 16 [eval # #]
  387: 15 [eval # #]
  440: 14 [eval # #]
  440: 13 [eval # #]
  411: 12 [eval # #]
  411: 11 [eval # #]
  411: 10 [eval # #]
  387: 9 [eval # #]
  432: 8 [eval # #]
  432: 7 [eval # #]
  471: 6 [eval # #]
  481: 5 [lp (#) (#f)]
  471: 4 [eval # #]
  486: 3 [eval # #]
  381: 2 [eval # #]
In unknown file:
?: 1 [#> _>> #]
In ice-9/eval.scm:
  481: 0 [lp (#) ((#))]

ice-9/eval.scm:481:19: guile: uncaught throw to unbound-variable: 
(module-lookup Unbound variable: ~S (apply-smob/1) #f)
make[3]: *** [Makefile:2238: ice-9/vlist.go] Error 1
make[3]: *** Waiting for unfinished jobs
Backtrace:
In ice-9/eval.scm:
  387: 19 [eval # #]
  387: 18 [eval # #]
  387: 17 [eval # #]
  387: 16 [eval # #]
  387: 15 [eval # #]
  440: 14 [eval # #]
  440: 13 [eval # #]
  411: 12 [eval # #]
  411: 11 [eval # #]
  411: 10 [eval # #]
  387: 9 [eval # #]
  432: 8 [eval # #]
  432: 7 [eval # #]
  471: 6 [eval # #]
  481: 5 [lp (#) (#f)]
  471: 4 [eval # #]
  486: 3 [eval # #]
  381: 2 [eval # #]
In unknown file:
?: 1 [#> _>> #]
In ice-9/eval.scm:
  481: 0 [lp (#) ((#))]

ice-9/eval.scm:481:19: guile: uncaught throw to unbound-variable: 
(module-lookup Unbound variable: ~S (apply-smob/1) #f)
make[3]: *** [Makefile:2238:

Bug#936537: reverse build depends still exist

[Paul Gevers]

Control: severity -1 normal

Oops, wrong bug. [first version sent to #937695]

On 29-11-2019 19:54, Paul Gevers wrote:
> Control: severity -1 normal
> 
> This package still has a reverse build depends. Let's not make this bug
> RC just yet.
> 
> paul@testavoira ~ $ reverse-depends fontcustom -b
> Reverse-Build-Depends
> =
> * fonts-fork-awesome
> 
> Paul
> 



signature.asc
Description: OpenPGP digital signature

Bug#945846: task-kde-desktop: Use print-manager instead of system-config-printer for KDE installation task

[Holger Wansing]

Hi,

Shmerl  wrote:
> Package: task-kde-desktop
[...]
> Currently, when selecting KDE in Debian installer, task-kde-desktop pulls in
> system-config-printer for
> printer settings, which is part of Gnome project and isn't well integrated 
> with
> KDE Plasma. Instead, it
> should use print-manager, which provides printer settings in KDE's own System
> Settings interface, and as
> well allows printer queue access for active jobs in notifications area (system
> tray).

If print-manager is that well integrated in KDE, it should probably be a
Recommends in the kde-baseapps or kde-plasma-desktop metapackage, maybe?

CC'ing KDE people for advice.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#855151: #855151: tasksel: should not be Priority: important

[Holger Wansing]

Hi,

Cyril Brulebois  wrote:
> Thinking about this change a little more, even if we were to publish D-I
> Bullseye Alpha 1 right now, which will be tested to be working… I think
> once ftp-masters update their overrides, this will break the published
> Alpha immediately.
> 
> Instead of rushing a change right now (it's been months without a
> release already), I think I'll ask them to postpone updating their
> overrides until we're up for an Alpha 2. Which means we'll have a clear
> breakage at the timing of our choosing, a way to double check the
> effects of the bug, and to ensure proposed patches do the work
> appropriately, instead of implementing things blindly in a hurry, right
> now.

Maybe, it would be the better way to force installation of tasksel in the
installer (because we need it there), instead of relying on other things
(package dependencies, which may change over time)?

Means something like adding a postinst hook script in pkgsel...


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#945909: man-db: When outputting 'ps' output from man, apparmor logs an error

[Bruce Momjian,,,]

Package: man-db
Version: 2.8.5-2
Severity: normal
Tags: patch

Dear Maintainer,

When outputting 'ps' output from man, e.g., 'man -Tps bash', a log apparmor 
error is generated in reading /etc/papersize.  The log error line shown by 
dmesg is:

   [1033342.844116] audit: type=1400 audit(1575057625.770:30): 
apparmor="DENIED" operation="open" profile="man_groff" name="/etc/papersize" 
pid=19233 comm="troff" requested_mask="r" denied_mask="r" fsuid=0
   ouid=0

The fix is to add this line to /etc/apparmor.d/usr.bin.man:

profile man_groff {
  ...
  /etc/papersize r,
}

This avoids the error message and allows 'man' to read the file properly.

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/16 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 man-db depends on:
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  groff-base 1.22.4-3
ii  libc6  2.28-10
ii  libgdbm6   1.18.1-4
ii  libpipeline1   1.5.1-2
ii  libseccomp22.3.3-4
ii  zlib1g 1:1.2.11.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor   2.13.2-10
ii  firefox-esr [www-browser]  68.2.0esr-1~deb10u1
ii  groff  1.22.4-3
ii  less   487-0.1+b1
ii  lynx [www-browser] 2.8.9rel.1-3
ii  w3m [www-browser]  0.5.3-37

-- Configuration Files:
/etc/apparmor.d/usr.bin.man changed:
/usr/bin/man {
  #include 
  # Use a special profile when man calls anything groff-related.  We only
  # include the programs that actually parse input data in a non-trivial
  # way, not wrappers such as groff and nroff, since the latter would need a
  # broader profile.
  /usr/bin/eqn rmCx -> &man_groff,
  /usr/bin/grap rmCx -> &man_groff,
  /usr/bin/pic rmCx -> &man_groff,
  /usr/bin/preconv rmCx -> &man_groff,
  /usr/bin/refer rmCx -> &man_groff,
  /usr/bin/tbl rmCx -> &man_groff,
  /usr/bin/troff rmCx -> &man_groff,
  /usr/bin/vgrind rmCx -> &man_groff,
  # Similarly, use a special profile when man calls decompressors and other
  # simple filters.
  /{,usr/}bin/bzip2 rmCx -> &man_filter,
  /{,usr/}bin/gzip rmCx -> &man_filter,
  /usr/bin/col rmCx -> &man_filter,
  /usr/bin/compress rmCx -> &man_filter,
  /usr/bin/iconv rmCx -> &man_filter,
  /usr/bin/lzip.lzip rmCx -> &man_filter,
  /usr/bin/tr rmCx -> &man_filter,
  /usr/bin/xz rmCx -> &man_filter,
  # Allow basically anything in terms of file system access, subject to DAC.
  # The purpose of this profile isn't to confine man itself (that might be
  # nice in the future, but is tricky since it's quite configurable), but to
  # confine the processes it calls that parse untrusted data.
  /** mrixwlk,
  unix,
  capability setuid,
  capability setgid,
  signal peer=@{profile_name},
  signal peer=/usr/bin/man//&man_groff,
  signal peer=/usr/bin/man//&man_filter,
  # Site-specific additions and overrides.  See local/README for details.
  #include 
}
profile man_groff {
  #include 
  # Recent kernels revalidate open FDs, and there are often some still
  # open on TTYs.  This is temporary until man learns to close irrelevant
  # open FDs before execve.
  #include 
  # man always runs its groff pipeline with the input file open on stdin,
  # so we can skip .
  /usr/bin/eqn rm,
  /usr/bin/grap rm,
  /usr/bin/pic rm,
  /usr/bin/preconv rm,
  /usr/bin/refer rm,
  /usr/bin/tbl rm,
  /usr/bin/troff rm,
  /usr/bin/vgrind rm,
  /etc/groff/** r,
  /usr/lib/groff/site-tmac/** r,
  /usr/share/groff/** r,
  signal peer=/usr/bin/man,
  # @{profile_name} doesn't seem to work here.
  signal peer=/usr/bin/man//&man_groff,
  #include 
}
profile man_filter {
  #include 
  # Recent kernels revalidate open FDs, and there are often some still
  # open on TTYs.  This is temporary until man learns to close irrelevant
  # open FDs before execve.
  #include 
  /{,usr/}bin/bzip2 rm,
  /{,usr/}bin/gzip rm,
  /usr/bin/col rm,
  /usr/bin/compress rm,
  /usr/bin/iconv rm,
  /usr/bin/lzip.lzip rm,
  /usr/bin/tr rm,
  /usr/bin/xz rm,
  # Manual pages can be more or less anywhere, especially with "man -l", and
  # there's no harm in allowing wide read access here since the worst it can
  # do is feed data to the invoking man process.
  /** r,
  signal peer=/usr/bin/man,
  # @{profile_name} doesn't seem to work here.
  signal peer=/usr/bin/man//&man_filter,
}

/etc/manpath.config changed:
MANDATORY_MANPATH   /usr/man
MANDATORY_MANPATH   /usr/share/man
MANDATORY_MANPATH  

Bug#945908: dehydrated: hook.sh example uses systemctl instead of service

[Adam Borowski]

Package: dehydrated
Version: 0.6.2-2+deb10u1
Severity: normal

Hi!
The example (which serves as documentation) for hook.sh says in multiple
places:
# systemctl reload nginx
instead of rc-agnostic
# service nginx reload

Of the three methods:
/etc/init.d/nginx reload
service nginx reload
systemctl reload nginx
the middle one is a wrapper meant to work for everyone.

Thus, could you please use it?


Meow!
-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.120--std-ipv6-64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dehydrated depends on:
ii  ca-certificates  20190110
ii  curl 7.64.0-4
ii  openssl  1.1.1d-0+deb10u2

dehydrated recommends no packages.

dehydrated suggests no packages.

-- no debconf information

Bug#945619: transition: kdepim 19.08

[Paul Gevers]

Control: tags -1 confirmed

Hi Sandro,

On 30-11-2019 00:08, Sandro Knauß wrote:
>  I prepared a patch for zanshin [!1]. That means I could now built every 
> reverse dependency with KDEPIM 19.08 and nothing is stopping me to start with 
> the transition (except the ACK from your side).

Please, go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#940726: linux-source-5.2: Enable SOF audio driver and back-port fixes required to 5.2 kernel

[David Ward]

On 11/10/19 1:05 PM, David Ward wrote:
Unfortunately, this has caused a regression. The SST and SOF drivers 
cannot both be enabled for the same Intel platform in the kernel 
configuration, according to Intel. 
https://bugzilla.kernel.org/show_bug.cgi?id=204237#c15


To clarify, the statement above applies to the Baytrail and Broadwell 
platforms (only).



These lines that were just added in debian/config/amd64/config need to 
be removed:


   CONFIG_SND_SOC_SOF_BAYTRAIL_SUPPORT=y
   CONFIG_SND_SOC_SOF_BROADWELL_SUPPORT=y

This will be enforced via Kconfig beginning in Linux 5.5-rc1:

   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=df7257e544faf838c3e7ad6b4e89ffe59e87f5e1
   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=a6955fe0e2309feeab5ec71e4b0dcbe498f4f497


The SOF drivers/firmware for the Broadwell and Baytrail platforms have 
issues, and Intel does not consider them ready for use in distributions yet:

https://github.com/thesofproject/linux/pull/1382#discussion_r344755772


Thank you.

Bug#945907: qtmultimedia-opensource-src: FTBFS on hppa - stack overflow

[John David Anglin]

Source: qtmultimedia-opensource-src
Version: 5.11.3-2
Severity: normal

Dear Maintainer,

The build fails in the testsuite:

make[4]: Leaving directory '/<>/tests/auto/unit/qcamerawidgets'
make[4]: Leaving directory '/<>/tests/auto/unit/qcameraviewfinder'
cd qmediaplayerwidgets/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o 
Makefile 
/<>/tests/auto/unit/qmediaplayerwidgets/qmediaplayerwidgets.pro 
'QMAKE_CFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g 
-O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' QMAKE_STRIP=: PREFIX=/usr 
QT_BUILD_PARTS+=tests ) && make -f Makefile check
cd qaudiorecorder/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile 
/<>/tests/auto/unit/qaudiorecorder/qaudiorecorder.pro 
'QMAKE_CFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g 
-O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' QMAKE_STRIP=: PREFIX=/usr 
QT_BUILD_PARTS+=tests ) && make -f Makefile check
make[4]: Entering directory 
'/<>/tests/auto/unit/qabstractvideosurface'
/<>/tests/auto/unit/qabstractvideosurface/target_wrapper.sh  
./tst_qabstractvideosurface 
make[4]: *** [Makefile:456: check] Segmentation fault
make[4]: Leaving directory 
'/<>/tests/auto/unit/qdeclarativemultimediaglobal'
make[3]: *** [Makefile.multimediaqml:473: 
sub-qdeclarativemultimediaglobal-check] Error 2
make[3]: Leaving directory '/<>/tests/auto/unit'
make[2]: *** [Makefile:405: sub-multimediaqml-pro-check] Error 2
make[2]: *** Waiting for unfinished jobs

tst_qdeclarativemultimediaglobal drops core due to a stack overflow:

dave@atlas:~/debian/qtmultimedia-opensource-src/qtmultimedia-opensource-src-5.12
.5/tests/auto/unit/qdeclarativemultimediaglobal$ gdb -c core 
tst_qdeclarativemultimediaglobal
GNU gdb (Debian 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "hppa-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tst_qdeclarativemultimediaglobal...

warning: core file may not match specified executable file.
[New LWP 11794]
[New LWP 11778]
[New LWP 11729]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/hppa-linux-gnu/libthread_db.so.1".
Core was generated by `./tst_qdeclarativemultimediaglobal'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xf6c7fbfc in _int_malloc (av=0xf8700010, bytes=4) at malloc.c:3563
3563malloc.c: No such file or directory.
[Current thread is 1 (Thread 0xe53723c0 (LWP 11794))]
(gdb) bt
#0  0xf6c7fbfc in _int_malloc (av=0xf8700010, bytes=4) at malloc.c:3563
#1  0xf6c81dc8 in __GI___libc_malloc (bytes=4) at malloc.c:3075
#2  0xf735fb48 in operator new(unsigned int) ()
   from /usr/lib/hppa-linux-gnu/libstdc++.so.6
#3  0xf473ac10 in ?? () from /usr/lib/hppa-linux-gnu/libQt5Qml.so.5
#4  0xf473850c in 
QV4::Compiler::JSUnitGenerator::registerQmlContextPropertyGetterLookup(int) () 
from /usr/lib/hppa-linux-gnu/libQt5Qml.so.5
#5  0xf474b290 in QV4::Compiler::Codegen::Reference::loadInAccumulator() const
() from /usr/lib/hppa-linux-gnu/libQt5Qml.so.5
#6  0xf47511b8 in QV4::Compiler::Codegen::Reference::doStoreOnStack(int) const
() from /usr/lib/hppa-linux-gnu/libQt5Qml.so.5
#7  0xf475149c in QV4::Compiler::Codegen::Reference::storeOnStack() const ()
   from /usr/lib/hppa-linux-gnu/libQt5Qml.so.5
#8  0xf4750e8c in QV4::Compiler::Codegen::Reference::storeAccumulator() const
() from /usr/lib/hppa-linux-gnu/libQt5Qml.so.5
#9  0xf475106c in QV4::Compiler::Codegen::Reference::storeConsumeAccumulator() 
const () from /usr/lib/hppa-linux-gnu/libQt5Qml.so.5
#10 0xf47511cc in QV4::Compiler::Codegen::Reference::doStoreOnStack(int) const
() from /usr/lib/hppa-linux-gnu/libQt5Qml.so.5
#11 0xf47

Bug#945906: dev-ref 4.6.4.1: text about unstable during the freeze might mislead

[Sean Whitton]

Package: developers-reference
Version: 11.0.7

Dear maintainer,

4.6.4.1 says

Note that development under unstable continues during the freeze
period, since the unstable distribution remains in place in parallel
with testing.

During the freeze maintainers should not upload stuff to unstable unless
(a) the package is not in testing, or (b) they are planning to request
an unblock.

The current text seems to suggest everything carries on as normal in
unstable.

Maybe experimental should be mentioned as partly taking over the usual
role of unstable during the freeze.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945904: Update hugo to v0.60.1 and backport?

[John Zaitseff]

Package: hugo
Version: 0.58.3-1
Severity: wishlist

Firstly, thank you for packaging Hugo for Debian!  I find your
package is better than upstream's, particularly in having manual
pages and Bash completions and, of course, of a binary that is
"properly built" against other Go packages.

I note that version 0.60.1 has been released.  Is it possible to
package that for Debian Sid?

In addition, is it at all easy (or even possible) to backport this
version to Debian Buster, to be placed on backports.debian.org?  I
know that is a big thing to ask!

Yours truly,

John Zaitseff

-- 
John Zaitseff  ╭───╮   Email: j.zaits...@zap.org.au
The ZAP Group  │ Z │   GnuPG: 0x0D254111C4EE569B
Sydney, Australia  ╰───╯   https://www.zap.org.au/~john/

Bug#945905: qtractor FTCBFS: uses AC_TRY_RUN to compute sizeof(float)

[Helmut Grohne]

Source: qtractor
Version: 0.9.11-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qtractor fails to cross build from source, because it uses AC_TRY_RUN to
figure out sizeof(float). AC_TRY_RUN does not work at all during cross
compilation. For sizeof, autoconf has a better alternative
AC_CHECK_SIZEOF though. Replacing this AC_TRY_RUN actually makes the
code simpler and more portable. Please consider applying the attached
patch.

It still fails to cross build, because qtractor has more AC_TRY_RUN.
Please close this bug anyhow when fixing the float check.

Helmut
--- qtractor-0.9.11.orig/configure.ac
+++ qtractor-0.9.11/configure.ac
@@ -599,13 +599,8 @@
 
 
 # Check for IEEE 32bit float optimizations.
-AC_CACHE_CHECK([for IEEE 32bit float optimizations],
-   ac_cv_float32, [
-   AC_TRY_RUN([
-  int main() { return (sizeof(float) == 4 ? 0 : 1); }
-   ], ac_cv_float32="yes", ac_cv_float32="no")
-])
-ac_float32=$ac_cv_float32
+AC_CHECK_SIZEOF(float)
+AS_IF([test "$ac_cv_sizeof_float" = 4],[ac_float32=yes],[ac_float32=no])
 if test "x$ac_float32" = "xyes"; then
AC_DEFINE(CONFIG_FLOAT32, 1, [Define if IEEE 32bit float optimizations are enabled.])
 fi

Bug#945886: creduce: build-depends on package that is not in testing.

[Matthias Klose]

On 30.11.19 16:17, peter green wrote:
> Package: creduce
> Version: 2.10.0-2
> Severity: serious
> 
> creduce build-depends on frama-c-base which is built by the frama-c source
> package which is not currently in testing.
> 
> Either frama-c needs to be fixed to get it back in testing, creduce needs to
> eliminate the dependency (no idea if this is possible, i'm just looking at
> dependency issues in debian, i don't know anything about the details of this
> package) or creduce needs to leave testing too.

that would be pretty bad. but maybe such is life.

Bug#945542: [Pkg-rust-maintainers] Bug#945542: debcargo -- Randomly adds and removes binary packages

[Daniel Kahn Gillmor]

Hi all--

I've been trying to make sense of the current struggles around rust
packaging in Debian, and this bug report (#945542) seems to be where
they're crystallzing.  (it's not clear to me how this bug report is
supposed to be distinct from #942898, which already captures some of
these details.  if the reporter or maintainer wants to merge them, i
think that'd be reasonable)

Full disclosure: i *want* rust software to work in a well-established
way in Debian. i am involved in helping with some of the rust packaging.
and at the same time, i am also frustrated at the immaturity and flux
that i see in some parts of the Rust ecosystem.  And i also find myself
frustrated with some of the frameworks involved with NEW queue
processing and unstable-to-testing migration, which i think are
occasionally counter-productive to debian's goals as a whole, and are
wasteful of the limited time that all of us (on the Rust team and the
FTP team) have to spend on Debian.

So i acknowledge that there is legitimate friction here, and i hope we
can work through it in a way that makes both Debian and the Rust ecosystem
healthier in the long run.

Identifying problems


The claims that have been listed here (but actually seem distinct to me)
are:

 a) A small number of Rust packages provide very long Provides lines,
which break some other infrastructure (e.g. reprepro)

 b) Many Rust source packages produce a handful of additional binary
packages that are empty but have different dependencies, as a way of
capturing crate "features" without introducing a large mass of
interlocked circular dependencies.

 c) The subject of this bug report is "Randomly adds and removes binary
packages".  I but haven't been able to find evidence of randomness
here -- the binary packages that do trigger additional passes
through NEW are not random -- they represent evolution of the
features offered by upstream software.  Surely this is similar to
evolution of other upstream software that is packaged for Debian
(though perhaps the scale is different).

 d) There is an assertion that binary packages are specifically
problematic for the FTP team.  For example:

On Sat 2019-11-30 12:15:55 +0100, Bastian Blank wrote:
> This problem is already listed since a long time in
> https://ftp-master.debian.org/REJECT-FAQ.html.

But reading this page, the closest thing i can find is its
description of "Package Split", which reads:

>>> You split a package too much or in a broken way. Well, broken or too
>>> much is a wide definition, so this is a case-by-case thing, but you
>>> should really think about a split before you do it. For example it
>>> doesn't make any sense to split a 50k arch:all package from a 250k
>>> arch:any one. Or splitting a package for only one file, depending on
>>> the main package. Yes, big dependency chains can be a reason. Or big
>>> documentation split into one -doc package. The point there is big.

Bastian, if you meant something else, please correct me here!


Evaluating solutions


(a) appears to be quite real, as lengthy Provides: lines have caused
failures in other pieces of software.  However, I'm a bit surprised that
i didn't easily find a bug report that either references or affects
reprepro, one of the packages known to have line-length limitations.
Someone who has encountered this bug in the wild and has documented it
should make sure that it is adequately represented on its own as a
specific bug report (or more than one), so we can peel this particular
situation off from the other issues.

(b) appears to be important to make it possible to avoid significant
bootstrapping difficulties with rust packages in the debian
ecosystem. Ximin has already explained some of the issues related to
re-bootstrapping a bunch of indpendent packages that have circular
dependencies so i won't go into it in more detail, but the goal here is
to facilitate package maintenance and require less manual intervention.
These are good goals.

There are potential performance concerns about what these extra binary
packages do to consumers of the archive -- both for mirrors and for
typical debian installations.  I asked for some clear profiling of these
performance issues over on #942898, but no one concerned about the
performance loss has stepped up to provide measurements.  I believe
these risks are real, but i also believe that there are real advantages
(to both Rust and Debian) to making sure that packaging rust software
for debian is easy and straightforward.

I'm not convincd that (c) represents a real problem, or at least it's
not one unique to the Rust ecosystem.  While shifts in upstream designs
may be annoying/frustrating to the debian maintainers of this software
and to the FTP team, the changes in stated feature sets by each version
of a rust crate upstream is no different than a C library package that
pushes changes to the SONAME more rapidly.  As

Bug#945903: dh-python: py3compile in postinst fails on scripts in /usr/share/doc

[Drew Parsons]

Package: dh-python
Version: 4.20191017
Severity: serious
Justification: 14.3
Control: block 945338 -1
Control: block 945339 -1

dh_python3 sets up a py3compile entry in the postinst script for a
package containing python scripts.

dh_installexamples installs example scripts into
/usr/share/doc//examples

It is well possible that some of those example scripts may be python,
so they are detected by dh_python3 and registered for processing by
py3compile.

But we are currently being hit with RC bugs saying that this
situation is a serious bug, since it is possible that /usr/share/doc
may not be installed, might not be present, Debian Policy 12.3.
See for example petsc bug#945338, slepc bug#945339.

It seems to me reasonable that you would install to example python scripts
using dh_installexamples. Yes you could install elsewhere using
dh_install, but then what is the point of dh_installexamples?

In that case dh_python3 needs to be updated to comply with Policy
12.3, to let the py3compile snippet not break when acting on python
files in /usr/share/doc/*/examples


-- 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/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-python depends on:
ii  python33.7.5-3
ii  python3-distutils  3.8.0-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.19.7
ii  libdpkg-perl  1.19.7

-- no debconf information

Bug#945902: orage FTCBFS: unsatisfiable libxml-parser-perl dependency

[Helmut Grohne]

Source: orage
Version: 4.12.1-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

orage fails to cross build from source, because its libxml-parser-perl
dependency cannot be satisfied. It's interpreted as host architecture
and results in an architecture conflict with the native perl.

It turns out however that orage no longer (directly) uses
libxml-parser-perl. Instead, it now uses intltool (which uses
libxml-parser-perl and is a dependency of orage), so we no longer need
this dependency. Dropping it is sufficient to make orage cross
buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru orage-4.12.1/debian/changelog orage-4.12.1/debian/changelog
--- orage-4.12.1/debian/changelog   2018-12-27 16:11:41.0 +0100
+++ orage-4.12.1/debian/changelog   2019-11-30 20:08:09.0 +0100
@@ -1,3 +1,10 @@
+orage (4.12.1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Drop unused libxml-parser-perl build dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 30 Nov 2019 20:08:09 +0100
+
 orage (4.12.1-6) unstable; urgency=medium
 
   * add a new orage-data binary package
diff --minimal -Nru orage-4.12.1/debian/control orage-4.12.1/debian/control
--- orage-4.12.1/debian/control 2018-12-27 16:11:41.0 +0100
+++ orage-4.12.1/debian/control 2019-11-30 20:08:08.0 +0100
@@ -10,7 +10,6 @@
libical-dev,
libnotify-dev,
libpopt-dev,
-   libxml-parser-perl,
xfce4-dev-tools,
xfce4-panel-dev
 Standards-Version: 4.3.0

Bug#945901: zynaddsubfx FTCBFS: misdetects fistpl instruction using wrong assembler

[Helmut Grohne]

Source: zynaddsubfx
Version: 3.0.5-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

zynaddsubfx fails to cross build from source, because it tries to use
the fistpl assembler instruction on non-x86 and that makes compilation
fail. The cause is misdetection of the availability of the instruction.
zynaddsubfx checks for it by summoning "as", which is the right
assembler on unix for native compilation. When a user supplies a C++
compiler, this badly fails as is happening during cross compilation.

The attached patch changes the check to use try_compile, which uses the
very same compiler as is used for compiling the sources. That makes the
check reliable. Please consider applying it.

Please note that this patch won't make zynaddsubfx cross buildable. It
still runs some host arch tool much later during build. I haven't found
a solution for that. Please close this bug when just fixing the asm
check though. It is an incremental improvement that also helps other
platforms and distributions.

Helmut
--- zynaddsubfx-3.0.5.orig/src/CMakeLists.txt
+++ zynaddsubfx-3.0.5/src/CMakeLists.txt
@@ -63,9 +63,7 @@
 set(CMAKE_REQUIRED_FLAGS "")
 
 
-execute_process(COMMAND echo fistpl 0
-COMMAND as -
-ERROR_VARIABLE AVOID_ASM)
+try_compile(USE_ASM ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/check_asm.cpp)
 
 # Settings ###
 # NOTE: These cache variables should normally not be changed in this
@@ -316,7 +314,7 @@
 add_definitions(--system-header-prefix="FL/")
 endif()
 
-if(NOT AVOID_ASM)
+if(USE_ASM)
 	message(STATUS "Compiling with x86 opcode support")
 add_definitions(-DASM_F2I_YES)
 endif()
--- /dev/null
+++ zynaddsubfx-3.0.5/src/check_asm.cpp
@@ -0,0 +1,5 @@
+int main()
+{
+	__asm__ __volatile__("fistpl 0");
+	return 0;
+}

Bug#945900: ITP: ruby-unleash -- Unleash feature toggle client

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ruby-unleash
  Version : 0.1.6
  Upstream Author : Renato Arruda
* URL : https://github.com/unleash/unleash-client-ruby
* License : Apache-2.0
  Description : Unleash feature toggle client
 This is the ruby client for Unleash, a powerful feature toggle system that
 gives a great overview over all feature toggles across all the 
applications

 and services.

Bug#945542: [Pkg-rust-maintainers] Bug#945542: debcargo -- Randomly adds and removes binary packages

[Russ Allbery]

Bastian Blank  writes:
> On Fri, Nov 29, 2019 at 10:35:04AM -0800, Russ Allbery wrote:

>> Procedurally in Debian neither of these are justifications for setting
>> the severity to serious.  This is not a Policy requirement that has
>> reached consensus, and the release team is the team in Debian that has
>> the delegated responsibility to determine which bugs are
>> release-critical for the next release.

> My plan was to get the problem acknowledged and then accept the
> remaining waiting Rust packages from NEW.

> This problem is already listed since a long time in
> https://ftp-master.debian.org/REJECT-FAQ.html.

I assume you mean the "Package split" point there?  If so, I think it's
clear the Rust packaging team did think about this split and is doing it
for specific technical reasons, and the disagreement is over the merits of
those reasons.

(If you mean some other point of the REJECT FAQ, I'm not sure which one
you're referring to.)

>> I realize that you're frustrated, and I suspect you're feeling like the
>> Rust package maintainers are not respecting something that you think is
>> obvious, but I don't think that fighting over the bug severity is the
>> right way to approach this disagreement in Debian.  If you feel that
>> you've reached an impasse in this discussion, this is what the
>> Technical Committee is for.

> The problem is not about severities, but about the Rust team to
> acknowledge that there is a problem.

Right, but it's not in the power of anyone in Debian to require some other
person in Debian acknowledge there is a problem (and this is good).

I don't think there's a disagreement here over the technical impact of the
packaging model used for Rust crates.  The disagreement is about tradeoffs
between ease of packaging, dependency resolution, and the size of the
Packages file, and different people are arriving at different conclusions
because of their different weighing of those concerns.

In that situation, if that discussion reaches an impasse and no one can
come up with a breakthrough technical solution to resolve the problem, it
seems appropriate to me to invoke the Technical Committee to help evaluate
the tradeoffs.

-- 
Russ Allbery (r...@debian.org)  

Bug#945899: kde-full: System-V support

[Bardot Jerome]

Package: kde-full
Severity: important

Dear Maintainer,

All in the title,
I test several things on my debian and mainly the few use packages, tools and
software.

In order to keep debian as universal as possible there is a way to have a kde
that can be work with system v.
I pretty sure this should be report upstream.

If i can help let me know i will try to find the time.




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

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

Versions of packages kde-full depends on:
pn  kde-plasma-desktop   
pn  kde-standard 
pn  kdeadmin 
pn  kdeedu   
pn  kdegames 
pn  kdegraphics  
pn  kdemultimedia
pn  kdenetwork   
pn  kdepim   
pn  kdeutils 
pn  plasma-workspace-wallpapers  

Versions of packages kde-full recommends:
pn  kdeaccessibility  
pn  kdesdk
ii  kdetoys   4:17.08.3+5.104
pn  kdewebdev 

Versions of packages kde-full suggests:
pn  calligra  
ii  xorg  1:7.7+20

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Guillem Jover  writes:

> The way I see it, any pathname "owned" by a package is within the realm
> of dpkg, which is in charge of tracking and managing the filesystem
> contents for system software. I've, for example, always found it a big
> defficiency that when querying dpkg about system pathnames it cannot
> give a proper answer in many cases. The same with verification of system
> pathnames. But this goes beyond temporary files, this includes things
> like log or cache files, or other volatile pathnames, for example.

I completely agree with all of this.  I was curious what you anticipated
using as an implementation strategy.

> I don't mind much how this could end up being hooked into various init
> systems and chroot/container managers. I can see how it could be done by
> the respective imeplementations themselves or provided by dpkg itself,
> I'm open to any of these TBH.

One possibly interesting option would be for dpkg to take responsibility
for writing the tmpfiles.d configuration file for a package based on its
own metadata (and registering that file as part of the package), which
accomplishes a lot of the same goals (for instance, local administrators
used to other systemd-based distributions will find configuration in the
expected place and working in the expected way) but leaves open support
from other init systems.

Obviously it would be a lot easier to do that if the package format dpkg
consumed used a compatible format to systemd-tmpfiles (and there would be
some, probably minor, learning-curve benefits if it used the same format).

> To me that seems like an extremely unsatisfying and restrictive way to
> characterize cross-distribution. This implies GNU/Linux-only ones, not
> even things like musl-based, for example. I consider portability of
> paramount importance, and I'll not stop caring about it, even if the
> Debian project decided otherwise, less so as an upstream. (See my GR
> amendment. :)

I understand, and I don't want you to stop caring about that.  I think
there are approaches that might satisfy both goals at the same time, such
as dpkg using systemd's native services and configuration files to
integrate with systemd-using systems.

-- 
Russ Allbery (r...@debian.org)  

Bug#945898: linux-image-5.3.0-2-amd64: No i2c_amd_mp2 kernel module

[Colin M Strickland]

Package: src:linux
Version: 5.3.9-3
Severity: normal

Dear Maintainer,

I have a Lenovo Ideapad 530s with an AMD ryzen cpu. This has been running fine
under Debian, since I first bought the computer, although the touchpad does not
work after boot. I found a very simple remedy for this using the
https://github.com/Syniurge/i2c-amd-mp2 driver, which is supplied as a DKMS
build, and simply installed and worked. When I apt upgraded my machine at the
start of this week, and moved to a 5.3 series debian kernel, the DKMS build
stopped working, and after boot I was surprised to have no trackpad again.

I looked at the build problem with the module, and it was a very simple
problem, where the prototype for one of the functions from device.h has become
slightly more strict. When I submitted this change to the upstream repo, the
reply from the author is that the module should be merged into the upstream
kernel since releasae 5.2 and a separated build should not be necessary for
kernels > 5.1. They report that the debian kernel seems to be exluding this
module, but they don't know why.

( see https://github.com/Syniurge/i2c-amd-mp2/pull/14 )

Is there a reason this is not available in the debian kernel image? Do I need
to install additional packages, or perhaps make such a package myself.

Thanks
cms



-- Package-specific info:
** Version:
Linux version 5.3.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191109 (Debian 9.2.1-19)) #1 SMP Debian 5.3.9-3 (2019-11-19)

** Command line:
BOOT_IMAGE=/vmlinuz-5.3.0-2-amd64 root=/dev/mapper/blink--vg-root ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
(Note that use of the override may cause unknown side effects.)
[   17.594132] ath10k_pci :01:00.0: htt-ver 3.56 wmi-op 4 htt-op 3 cal otp 
max-sta 32 raw 0 hwcrypto 1
[   17.596964] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   17.622248] mc: Linux media interface: v0.10
[   17.622285] EDAC amd64: Node 0: DRAM ECC disabled.
[   17.622289] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[   17.644207] videodev: Linux video capture interface: v2.00
[   17.672957] ath: EEPROM regdomain: 0x6c
[   17.672960] ath: EEPROM indicates we should expect a direct regpair map
[   17.672963] ath: Country alpha2 being used: 00
[   17.672964] ath: Regpair used: 0x6c
[   17.677797] ath10k_pci :01:00.0 wlp1s0: renamed from wlan0
[   17.688653] EDAC amd64: Node 0: DRAM ECC disabled.
[   17.688655] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[   17.698121] Bluetooth: Core ver 2.22
[   17.698153] NET: Registered protocol family 31
[   17.698154] Bluetooth: HCI device and connection manager initialized
[   17.698330] Bluetooth: HCI socket layer initialized
[   17.698333] Bluetooth: L2CAP socket layer initialized
[   17.698338] Bluetooth: SCO socket layer initialized
[   17.712914] usbcore: registered new interface driver btusb
[   17.765968] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b61e)
[   17.782522] uvcvideo 3-2:1.0: Entity type for entity Realtek Extended 
Controls Unit was not initialized!
[   17.782525] uvcvideo 3-2:1.0: Entity type for entity Extension 4 was not 
initialized!
[   17.782526] uvcvideo 3-2:1.0: Entity type for entity Processing 2 was not 
initialized!
[   17.782528] uvcvideo 3-2:1.0: Entity type for entity Camera 1 was not 
initialized!
[   17.782785] input: Integrated Camera: Integrated C as 
/devices/pci:00/:00:08.1/:03:00.4/usb3/3-2/3-2:1.0/input/input18
[   17.783339] usbcore: registered new interface driver uvcvideo
[   17.783341] USB Video Class driver (1.1.1)
[   17.904204] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   17.904207] Bluetooth: BNEP filters: protocol multicast
[   17.904214] Bluetooth: BNEP socket layer initialized
[   18.761123] ath10k_pci :01:00.0: unsupported HTC service id: 1536
[   18.895397] pcieport :00:01.2: AER: Multiple Corrected error received: 
:00:01.0
[   18.895410] pcieport :00:01.2: AER: PCIe Bus Error: severity=Corrected, 
type=Data Link Layer, (Receiver ID)
[   18.896225] pcieport :00:01.2: AER:   device [1022:15d3] error 
status/mask=0080/6000
[   18.897225] pcieport :00:01.2: AER:[ 7] BadDLLP   
[   18.929438] pcieport :00:01.2: AER: Multiple Corrected error received: 
:00:01.0
[   18.929452] pcieport :00:01.2: AER: PCIe Bus Error: severity=Corrected, 
type=Data Link Layer, (Receiver ID)
[   18.931291] pcieport :00:01.2: AER:   device [1022:15d3

Bug#944719: golang-gopkg-stretchr-testify.v1: duplicate of golang-testify

[Thorsten Alteholz]

Control: severity -1 normal

Hi Andreas,

thanks for spotting this.

This package is a dependency of grafana, that I want to reintroduce into 
Debian again. As there are so much dependencies I don't want to start with 
creating and maintaining lots of patches and thus just take everything as 
it is.


In a later step such things can be improved.

  Thorsten

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Guillem Jover]

Hi!

On Fri, 2019-11-29 at 09:13:47 -0800, Russ Allbery wrote:
> Guillem Jover  writes:
> > As I mentioned on debian-devel, I think major parts of this and of the
> > sysuser stuff fall under dpkg realm. And my plan is to implement this
> > kind of functionality natively in dpkg, regardless of whatever the
> > outcome of that GR is.
> 
> > Of course some parts of the functionality needed to manage/track
> > temporary pathnames requires integration or hooking into an init system
> > or chroot/container manager, but that's true regardless of the
> > implementation.
> 
> Could you say more about how you think dpkg would be able to handle
> systemd-tmpfiles?  As you mention, this is something that has to be done
> at every system boot, which seems pretty far afield from dpkg's domain.
> Do you want to maintain custom dpkg plugins for every init system that a
> dpkg system may support?

The way I see it, any pathname "owned" by a package is within the
realm of dpkg, which is in charge of tracking and managing the
filesystem contents for system software. I've, for example, always
found it a big defficiency that when querying dpkg about system
pathnames it cannot give a proper answer in many cases. The same with
verification of system pathnames. But this goes beyond temporary files,
this includes things like log or cache files, or other volatile
pathnames, for example.

These kinds of pathnames are also potential package cruft, that should
be cleaned up on package remove/purge (ideally in a configurable way,
as in “I want logs to be left behind after purge”), and w/o requiring
maintainer scripts.

  

I don't mind much how this could end up being hooked into various init
systems and chroot/container managers. I can see how it could be done by
the respective imeplementations themselves or provided by dpkg itself,
I'm open to any of these TBH.

> (My recollection is that dpkg supports other OSes like Solaris.)

  
  

> (systemd-sysusers is another matter and a bit more obviously doable with
> dpkg, although if Sam's option three wins, I'd ask everyone in the
> project, including you as dpkg maintainer, to consider the possible
> benefits of using cross-distribution mechanisms instead of Debian-specific
> mechanisms.)

  

To me that seems like an extremely unsatisfying and restrictive way
to characterize cross-distribution. This implies GNU/Linux-only ones,
not even things like musl-based, for example. I consider portability
of paramount importance, and I'll not stop caring about it, even if
the Debian project decided otherwise, less so as an upstream. (See my
GR amendment. :)

I find integration within Debian and with the wider dpkg ecosystem to
be way more interesting, and interfaces in dpkg that can work anywhere
where it would be available. That's why I'll work on this no matter
what, even if Debian decided to not use these features (which I'd find
rather unfortunate), I'd spend time on this at the expense of other
stuff.

Thanks,
Guillem

Bug#945897: ITP: dynsim -- DynamicSimulator is an open source project for helping with visualization and simulation of physical systems.

[Rômulo Cenci]

Package: wnpp
Severity: wishlist
Owner: Rômulo Cenci 

* Package name: dynsim
  Version : 1.0.0
  Upstream Author : Rômulo Cenci 
* URL : https://romcenci.github.io/DynamicSimulator/
* License : BSD
  Programming Lang: C
  Description : DynamicSimulator is an open source project for helping with
visualization and simulation of physical systems.

It is writen in C and use OpenGL and GLFW to create a window that shows the
simulation, the data for the program is passed by the pipe "|" program, mostly
present on linux systems. For now, are 5 modes of visualization, one-
dimensional mode that shows a grid with color scale, one one-dimensional mode
with particles, a two-dimensional mode of grid, and a two-dimensional mode of
circles (particles), and for addition we are working on a mode of arrows, for
systems like the Heisenberg model.

Bug#945896: buster-pu: package ros-ros-comm/1.14.3+ds1-5

[Jochen Sprickerhof]

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

Hi release team,

The ros-ros-comm version in buster is affected affected by
CVE-2019-13566 which was flagged no-dsa by the security team. I propose
the attached patch to fix the issue. Would you be fine with me uploading
it?

The same patch (modulo the version number) applies to stretch as well.
Can I upload it as well or do you want an extra ticket?

Cheers Jochen

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 3f3bc57..02ec0a5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ros-ros-comm (1.14.3+ds1-5+deb10u1) stable; urgency=high
+
+  * Add https://github.com/ros/ros_comm/pull/1771 (Fix CVE-2019-13566)
+
+ -- Jochen Sprickerhof   Sun, 24 Nov 2019 17:06:34 +0100
+
 ros-ros-comm (1.14.3+ds1-5) unstable; urgency=medium
 
   * install ros/transport headers (LP: #1815896)
diff --git a/debian/patches/0008-fixing-string-check.patch 
b/debian/patches/0008-fixing-string-check.patch
new file mode 100644
index 000..513acfe
--- /dev/null
+++ b/debian/patches/0008-fixing-string-check.patch
@@ -0,0 +1,65 @@
+From: Daniel Wang 
+Date: Mon, 22 Jul 2019 15:47:21 -0700
+Subject: fixing string check
+
+Signed-off-by: Daniel Wang 
+---
+ clients/roscpp/src/libros/transport/transport_tcp.cpp | 8 
+ clients/roscpp/src/libros/transport/transport_udp.cpp | 4 ++--
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/clients/roscpp/src/libros/transport/transport_tcp.cpp 
b/clients/roscpp/src/libros/transport/transport_tcp.cpp
+index f33a355..ddc47f5 100644
+--- a/clients/roscpp/src/libros/transport/transport_tcp.cpp
 b/clients/roscpp/src/libros/transport/transport_tcp.cpp
+@@ -276,7 +276,7 @@ bool TransportTCP::connect(const std::string& host, int 
port)
+ 
+ bool found = false;
+ struct addrinfo* it = addr;
+-char namebuf[128];
++char namebuf[128] = {};
+ for (; it; it = it->ai_next)
+ {
+   if (!s_use_ipv6_ && it->ai_family == AF_INET)
+@@ -288,7 +288,7 @@ bool TransportTCP::connect(const std::string& host, int 
port)
+ address->sin_family = it->ai_family;
+ address->sin_port = htons(port);
+   
+-strcpy(namebuf, inet_ntoa(address->sin_addr));
++strncpy(namebuf, inet_ntoa(address->sin_addr), sizeof(namebuf)-1);
+ found = true;
+ break;
+   }
+@@ -734,14 +734,14 @@ std::string TransportTCP::getClientURI()
+   sockaddr_in *sin = (sockaddr_in *)&sas;
+   sockaddr_in6 *sin6 = (sockaddr_in6 *)&sas;
+ 
+-  char namebuf[128];
++  char namebuf[128] = {};
+   int port;
+ 
+   switch (sas.ss_family)
+   {
+ case AF_INET:
+   port = ntohs(sin->sin_port);
+-  strcpy(namebuf, inet_ntoa(sin->sin_addr));
++  strncpy(namebuf, inet_ntoa(sin->sin_addr), sizeof(namebuf)-1);
+   break;
+ case AF_INET6:
+   port = ntohs(sin6->sin6_port);
+diff --git a/clients/roscpp/src/libros/transport/transport_udp.cpp 
b/clients/roscpp/src/libros/transport/transport_udp.cpp
+index 47d969e..45f817e 100644
+--- a/clients/roscpp/src/libros/transport/transport_udp.cpp
 b/clients/roscpp/src/libros/transport/transport_udp.cpp
+@@ -710,9 +710,9 @@ std::string TransportUDP::getClientURI()
+ 
+   sockaddr_in *sin = (sockaddr_in *)&sas;
+ 
+-  char namebuf[128];
++  char namebuf[128] = {};
+   int port = ntohs(sin->sin_port);
+-  strcpy(namebuf, inet_ntoa(sin->sin_addr));
++  strncpy(namebuf, inet_ntoa(sin->sin_addr), sizeof(namebuf)-1);
+ 
+   std::string ip = namebuf;
+   std::stringstream uri;
diff --git a/debian/patches/series b/debian/patches/series
index 6e4e210..19f293d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@
 0005-Add-defaults-to-roswtf.patch
 0006-Use-system-libb64.patch
 0007-Build-Python-3-version-of-roslz4.patch
+0008-fixing-string-check.patch

Bug#945894: RM: python-leveldb -- RoM; python2-only, dead upstream, better option exist

[GCS]

Package: ftp.debian.org
Severity: normal

Hi FTP Masters,

Please remove src:python-leveldb from unstable. Its upstream
discontinued for a long time and there's already an other, maintained
alternative in the archive.

Thanks,
Laszlo/GCS

Bug#945895: RM: selectors34 -- RoM; python2-only, not needed anymore

[GCS]

Package: ftp.debian.org
Severity: normal

Hi FTP Masters,

Please remove src:selectors34 from unstable. It was needed for python2
variant of pyro4 which is no longer built.

Thanks,
Laszlo/GCS

Bug#941005: [Pkg-shadow-devel] Bug#941005: Bug#941005: shadow uses obsolete SELinux API

[Serge E. Hallyn]

On Sat, Nov 30, 2019 at 06:47:28PM +0100, Christian Göttsche wrote:
> As the change got merged upstream [1], and upstream releases roughly
> once a year, any chance this gets cherry-picked in the next Debian

Digs aside, the goal is 4x/year, and the next one is scheduled for December.
I was intending to do it next week.

> upload?
> 
> [1] 
> https://github.com/shadow-maint/shadow/commit/a8a921184fdf950194cb887d241e0cbc588759c4
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#945893: RFS: libt3highlight/0.5.0-1

[Gertjan Halkes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libt3highlight"

* Package name: libt3highlight
  Version : 0.5.0-1
  Upstream Author : Gertjan Halkes 
* URL : https://os.ghalkes.nl/t3/libt3highlight.html
* License : GPLv3
  Section : libs

It builds those binary packages:

  libt3highlight-dev - Development files for libt3highlight
  libt3highlight2 - Syntax highlighting library
  t3highlight - Command-line syntax highligher

To access further information about this package, please visit the following
URL:

https://mentors.debian.net/package/libt3highlight

Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/libt/libt3highlight/libt3highlight_0.5.0-1.dsc

Changes since the last upload:

  * New upstream release.

Regards,
  Gertjan Halkes

Bug#933192: Found, issue in Dulwich

[Jelmer Vernooij]

reassign 933192 python3-dulwich
thanks

I've finally managed to track this bug down - it's due to a lack of
expansion of ~ in Dulwich.


signature.asc
Description: PGP signature

Bug#943705: dh_installman: man-recode integration gets confused if both foo.1 and foo.1.gz exist

[Santiago Vila]

On Sun, Nov 17, 2019 at 04:08:00PM +, Niels Thykier wrote:

> I think the proper solution here is to either pick a "winner"
> deterministically OR reject the situation as a conflict and have the
> packager sort out the issue.
> 
> I am learning towards the latter as a long term solution (compat 13) and
> the former as a short term (current compat levels).
> Suggestions/feedback welcome.

I also believe that packages that used to work in a certain compat
level should continue to work in the same compat level, i.e. if you
have to break things that used to work in the past, it will always be
more elegant to do so in a new compat level.

Thanks.

Bug#941005: [Pkg-shadow-devel] Bug#941005: shadow uses obsolete SELinux API

[Christian Göttsche]

As the change got merged upstream [1], and upstream releases roughly
once a year, any chance this gets cherry-picked in the next Debian
upload?

[1] 
https://github.com/shadow-maint/shadow/commit/a8a921184fdf950194cb887d241e0cbc588759c4

Bug#945521: [ltsp] libfuse3 / sshfs v3 don't support nonempty option anymore

[Wolfgang Schweer]

On Tue, 26 Nov 2019 11:17:35 + Mike Gabriel 
 wrote:
> The first test system wouldn't allow user logins due to failures in  
> login/pamltsp:

This issue has been fixed upstream, see:
https://github.com/ltsp/ltsp/issues/99

Wolfgang


signature.asc
Description: PGP signature

Bug#933749: Workaround

[Jakob Haufe]

fail2ban up and including to 0.10.4 does not contain code to actually
purge DB entries based on dbpurgeage.

Code for this has been introduced in
681bc2ef07ebdf749ccef624d8d598de42b0c6b6 in branch 0.11 but this has
not seen a release yet.

I am currently running the attached script on a daily basis to keep the
database at a sane size. (It previously grew up to 2.5GB which put some
load on the machine...)

-- 
ceterum censeo microsoftem esse delendam.


fail2ban-cleanup
Description: Binary data


pgpWzJQivS0qa.pgp
Description: OpenPGP digital signature

Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown

[Marc Lehmann]

On Sat, Nov 30, 2019 at 06:02:17PM +0100, Michael Biebl  
wrote:
> > That's silly and dishonest.
> 
> I guess you just proved the point, thank you.

Your point is that when _you_ start throwing around ad-hominems that this
is a sign that the _other_ side has stopped being constructive? Is this
designed to leave me speechless?

Anyway, wwhatever pleases you, I guess - I have explained why you have all
the necessary information, and you have not explained why you would need
the contents of my script, which are clearly not needed.

It is clearly you who stopped being "collaborative". Being an arrogant
prick and needlessly starting to insult bug reporters who act in good
faith doesn't help things.

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

Bug#945862: /etc/cron.daily/apt-compat: Use "sleep" later in the script

[Julian Andres Klode]

On Fri, Nov 29, 2019 at 11:51:51PM +, Bjarni Ingi Gislason wrote:
> Package: apt
> Version: 1.8.4
> Severity: minor
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>   The "sleep" funtion was shown in the output of "ps".
> 
> ###
> 
>   Do not put the script to a sleep, if it is afterwards not going to do
> its job.
> 
>   Therefor call "random_sleep" after "check_power || exit 0".

That would be wrong. If we sleep 30 min and you remove your power within
those 30 minutes, we'd run when we shouldn't.

I guess we could do the power check twice. But then people might complain
that we check power first and the script does not run because they plugged
in too late or something.

I mean, meh, you could just use systemd if you want sane behavior.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#945892: RFS: libt3window/0.4.0-1

[Gertjan Halkes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libt3window"

* Package name: libt3window
  Version : 0.4.0-1
  Upstream Author : Gertjan Halkes 
* URL : https://os.ghalkes.nl/t3/libt3window.html
* License : GPLv3
  Section : libs

It builds those binary packages:

  libt3window-dev - Development files for libt3window
  libt3window0 - Library for creating window-based terminal programs

To access further information about this package, please visit the following
URL:

https://mentors.debian.net/package/libt3window

Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/libt/libt3window/libt3window_0.4.0-1.dsc

Changes since the last upload:

  * New upstream release.

Regards,
  Gertjan Halkes

Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown

[Michael Biebl]

Am 30.11.19 um 17:56 schrieb Marc Lehmann:
> On Sat, Nov 30, 2019 at 04:14:55PM +0100, Michael Biebl  
> wrote:
>> I assume there  is no further interest to work collaboratively on this
>> from the bug reporters side, so closing the issue.
> 
> Your assumption is wrong, lacks good faith and is unnecessarily insulting
> - I provided all information requested and necessary to fix this issue
> and just don't have enough time to chase extra info that is clearly
> unnecessary and just adds a lot of extra work for me or requires me to
> disclose information that is neither public nor needed to fix this issue,
> _as I already have explained_. What else do you want, a full filesysstem
> dump? Sorry, but the ball is in your court - either fix the bug or don't
> fix it, but don't make me responsible for it: I did my part.
> 
> Seriously, just admit that you just don't want to fix this bug (because
> that iws clearly the issue here) and don't try to bury it under an
> unreasonable list of extra requirements so you can spread FUD about me not
> wanting to work on this collaboratively, as is already disproven by the
> effort I made documenting this issue and reporting it.
> 
> That's silly and dishonest.
> 

I guess you just proved the point, thank you.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#945891: lintian: please update list of DEB_BUILD_PROFILES

[Simon McVittie]

Package: lintian
Version: 2.39.0
Severity: wishlist

Following discussion in the threads starting at
 and
,
I've added the noinsttest build profile to
.
Please add this to /usr/share/lintian/data/fields/build-profiles.

I also noticed that the list in
/usr/share/lintian/tags/i/invalid-profile-name-in-build-profiles-field.desc
is incomplete, and does not list some recent additions such as noruby.

Thanks,
smcv

Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown

[Marc Lehmann]

On Sat, Nov 30, 2019 at 04:14:55PM +0100, Michael Biebl  
wrote:
> I assume there  is no further interest to work collaboratively on this
> from the bug reporters side, so closing the issue.

Your assumption is wrong, lacks good faith and is unnecessarily insulting
- I provided all information requested and necessary to fix this issue
and just don't have enough time to chase extra info that is clearly
unnecessary and just adds a lot of extra work for me or requires me to
disclose information that is neither public nor needed to fix this issue,
_as I already have explained_. What else do you want, a full filesysstem
dump? Sorry, but the ball is in your court - either fix the bug or don't
fix it, but don't make me responsible for it: I did my part.

Seriously, just admit that you just don't want to fix this bug (because
that iws clearly the issue here) and don't try to bury it under an
unreasonable list of extra requirements so you can spread FUD about me not
wanting to work on this collaboratively, as is already disproven by the
effort I made documenting this issue and reporting it.

That's silly and dishonest.

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

Bug#936207: biosig4c++: Python2 removal in sid/bullseye

[Alois Schlögl]

On Tue, 5 Nov 2019 12:27:42 -0800 Steve Langasek
 wrote:

However, after applying that patch, the package fails to build because:

- it tries to invoke python, which is not present. Fixed by setting
PYTHON=python3 in MAKEOPTS from debian/rules.
- the python3 pkgconfig handling is completely messed up in
python/setup.py; it tries to find a pkgconfig file in the system
directory (why, when it's part of the same source package we're just
building right now?), and when it doesn't find it, under python3 it
raises a different exception than ValueError, so the fallback code
doesn't work. And if I set PKG_CONFIG_PATH to point at the libbiosig.pc
in the parent directory, it just fails later at linking time because ../
isn't on the linker path.

I'm stopping my investigation there, it really looks like this needs some
upstream cleanup.

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



Dear Steve,


the attached patch should fix this problem.

Moreover, the dependency on python-pkgconfig (and pythen3-pkgconfig) 
becomes obsolote.



Kind regards,

   Alois

diff --git a/biosig4c++/python/setup.py b/biosig4c++/python/setup.py
index 556d306a..4e046e29 100644
--- a/biosig4c++/python/setup.py
+++ b/biosig4c++/python/setup.py
@@ -6,23 +6,12 @@ except ImportError:
 from distutils.extension import Extension
 
 import numpy.distutils.misc_util as mu
-try:
-import pkgconfig
-PKG=pkgconfig.parse('libbiosig')
-CPATH=PKG['include_dirs']
-LIBS=PKG['libraries']
-LIBDIR=PKG['library_dirs']
-except ValueError:
-print('cannot load pkgconfig(libbiosig) - use default location')
-CPATH='/usr/local/include'
-LIBS='-lbiosig'
-LIBDIR='/usr/local/lib'
 
 module_biosig = Extension('biosig',
 define_macros = [('MAJOR_VERSION', '1'), ('MINOR_VERSION', '9')],
-include_dirs = [CPATH, mu.get_numpy_include_dirs()[0]],
-libraries= LIBS,
-library_dirs = LIBDIR,
+include_dirs = ['./..', mu.get_numpy_include_dirs()[0]],
+libraries= ['biosig'],
+library_dirs = ['./..'],
 sources  = ['biosigmodule.c'])
 
 setup (name = 'Biosig',
@@ -34,6 +23,6 @@ setup (name = 'Biosig',
url = 'https://biosig.sourceforge.io',
long_description = '''This is the biosig demo package.''',
keywords = 'EEG ECG EKG EMG EOG Polysomnography ECoG biomedical signals SCP EDF GDF HEKA CFS ABF',
-   install_requires=['numpy','pkgconfig','setuptools'],
+   install_requires=['numpy','setuptools'],
ext_modules = [module_biosig])
 

Bug#945890: mtree-netbsd: build-depends on obsolete package.

[peter green]

Package: mtree-netbsd
Version: 20180822-4
Severity: serious
Tags: patch

mtree-netbsd build-depends on bsdtar which is no longer built by the libarchive 
source package. It is still present in unstable as a cruft package but is 
completely gone from testing.

Please update your build-dependency to libarchive-tools.

Bug#937003: meep: Python2 removal in sid/bullseye

[peter green]

Severity 937003 serious
Thanks

meep build-depends on python-h5py, which is no longer built by the h5py source 
package. It is still present in unstable as a cruft package, but is completely 
gone from testing.

Bug#945887: jupyter-notebook: pip3 is not working after installation

[Patrice Duroux]

Sorry finally I found the guilty: python3-testpath
that is pulled by python3-nbconvert

Thanks

Bug#945889: lilypond, build-depends on obsolete package.

[peter green]

Package: lilypond
Version: 2.19.81+really-2.18.2-13
Severity: serious
Tags: patch

lilypond build-depends on texlive-generic-recommended, which has been dropped 
by the texlive-base source package. It is still present in unstable as a cruft 
package but is completely gone from testing.

Please update your build-dependency to texlive-plain-generic.

Bug#945888: The nscd daemon use a wrong path to open cache files

[André Rodier]

Package: nscd
Version: 2.28-10

When using AppArmor and ldap for users database, and nscd on Debian, a
lot of errors are visible in the AppArmor logs, when any program
queries nscd.

The nscd daemon tries to open files in "var/cache/nscd/..." instead of
"/var/cache/nscd/...". Note the missing slash character at the
beginning. AppArmor complains about the file access denied, but the
error is really a missing '/' character in the path of the cache files.

This happens both on Stretch and Buster.

I cannot use reportbug script anymore, I have removed the package.

Thanks.

Bug#945867: lintian: Unable to override warning in -dbgsym

[Dmitry Smirnov]

On Saturday, 30 November 2019 9:25:31 PM AEDT Chris Lamb wrote:
> Hm, is this #945276 / #945299 or a seperate, new, issue about overrides?

Looks like a new (unrelated) issue to me. Besides, both of those bugs are 
fixed in 2.38.0 which is a version I'm currently using which manifests the 
problem...

-- 
Regards,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


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

Bug#945887: jupyter-notebook: pip3 is not working after installation

[Patrice DUROUX]

Package: jupyter-notebook
Version: 6.0.0-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

$ apt install jupyter-notebook

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

$ pip3 check

   * What was the outcome of this action?

$ pip3 check
Exception:
Traceback (most recent call last):
  File 
"/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py",
 line 2649, in version
return self._version
  File 
"/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py",
 line 2756, in __getattr__
raise AttributeError(attr)
AttributeError: _version

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 
143, in main
status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/check.py", line 
19, in run
package_set = create_package_set_from_installed()
  File "/usr/lib/python3/dist-packages/pip/_internal/operations/check.py", line 
41, in create_package_set_from_installed
package_set[name] = PackageDetails(dist.version, dist.requires())
  File 
"/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py",
 line 2654, in version
raise ValueError(tmpl % self.PKG_INFO, self)
ValueError: ("Missing 'Version:' header and/or PKG-INFO file", testpath 
[unknown version] (/usr/lib/python3/dist-packages))

   * What outcome did you expect instead?

$ pip3 check
No broken requirements found.


*** End of the template - remove these template lines ***

Thanks,
Patrice

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

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

Versions of packages jupyter-notebook depends on:
ii  init-system-helpers  1.57
ii  jupyter-core 4.6.1-1
ii  python3  3.7.5-3
ii  python3-notebook 6.0.0-1

jupyter-notebook recommends no packages.

jupyter-notebook suggests no packages.

-- no debconf information

Bug#939117: grilo-plugins: Python2 removal in sid/bullseye -- drop python-dbusmock build dependency

[peter green]

Severity 939117 serious
Thanks

The python-dbusmock binary package is no longer present in testing or unstable.

This issue is already fixed in unstable, unfortunately unstable's grilo-plugins 
can't migrate to testing because of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945830

Bug#940872: KDE Frameworks 5.62 coming to unstable

[luca.pedrielli]

Il 30/11/19 16:25, Antonio ha scritto:

Performed all the steps: now it works.
I hope it's applied to the repository package.
Thanks.


From: "luca.pedrielli" 
To: 940...@bugs.debian.org
Date: Thu, 28 Nov 2019 14:32:02 +0100

I found this solution

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942429#25

Best, Luca.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945833

--
Saluti, Luca Pedrielli

Bug#945858: [Pkg-gtkpod-devel] Bug#945858: b-d on python3-all-dev, but not built for all supported Python3 versions

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2019-11-30 at 00:19 +0100, Sebastien Bacher wrote:
> Package: libplist
> Version: 2.0.1~git20190104.3f96731-1
> 
> The package build-depends on python3-all-dev, but does not build for all
> supported python3 versions, it should rather b-d on python3-dev if it
> only needs to build with the current python version

Hi, thanks for the heads up. I have to admit I don't have much clue about
python stuff in Debian, I'll move the build-dep then (I have no idea how to
actually support multiple python versions)

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3iixkACgkQ3rYcyPpX
RFsygAf/YiSbN2e0tFgkeC7qvO94wPIARMO4EvuxYINYS2HJznqJTY1GVhK4vYWE
lE/kdB4TJQ54LekcCgS7+S+vb9yjHcmjrF6v35vatmnvFUeu6Rq8gIbpBEtYRnk0
hLI3iOEU+dnE45lpY1aeUJFHNcdVPN5vdFpQXJmky5Gq++ou1DSWmv+bkYGWfFEc
NznTd25TScj9S1dVyZAbGAUmkHXRi7kroTi9QYrMZu/fI8WP8sdcCdENXFn7mwvG
1UfIcB7B0FiqfaY4rnxcSuE/OyH86DkALq3uNycrhWubnlQ0nzs/4nRA9OugZsLm
2vIQoKBbGhPH7dhQPRWEMeJecbT1ZQ==
=Bfl4
-END PGP SIGNATURE-

Bug#891507: [Pkg-gtkpod-devel] Bug#891507: usbmuxd: Plugging device second time does not start usbmuxd

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2019-11-30 at 02:49 -0800, Brian Clinkenbeard wrote:
> Any updates regarding the Ubuntu patch?

Hi, I'm not sure what you mean by “the Ubuntu patch”?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3iitUACgkQ3rYcyPpX
RFu8XQf/bIMZp0APAZHNm+H90Xz5wfW+vzzD92zR+QuDhiVO3VFpYQ1/XAujRVSS
atDBgUuz09lv8Tf0gJ4o8ZVlmPdEATcv59EgH8fQ2NqanPMSI8cR7KOiMnSoIE8A
CbPpQZSoc1we9ZU0SLTa6K6fB6CTspdPfpX3htKoNFpXlZ0C6fCVSsmBS7pAEhVG
ibuzThWXTvTu5UxFFMqCeWfYoOTDR73zneY3VZpH7f5Misj7gVLOUJPpqUzKh2uG
kSv6o514K03ryfM/+FrYRb5txasB/NC9RfiK/pPZBhN4S2t6YnJyXD7/xjhU0x9L
+SXmeGFJlcupscl9ui9amfAqN9lIlA==
=nsfa
-END PGP SIGNATURE-

Bug#940872: KDE Frameworks 5.62 coming to unstable

[Antonio]

Performed all the steps: now it works.
I hope it's applied to the repository package.
Thanks.

>From: "luca.pedrielli" 
>To: 940...@bugs.debian.org
>Date: Thu, 28 Nov 2019 14:32:02 +0100
>
>I found this solution
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942429#25
>
> Best, Luca.

Bug#945886: creduce: build-depends on package that is not in testing.

[peter green]

Package: creduce
Version: 2.10.0-2
Severity: serious

creduce build-depends on frama-c-base which is built by the frama-c source 
package which is not currently in testing.

Either frama-c needs to be fixed to get it back in testing, creduce needs to 
eliminate the dependency (no idea if this is possible, i'm just looking at 
dependency issues in debian, i don't know anything about the details of this 
package) or creduce needs to leave testing too.

Bug#936294: chemfp: Python2 removal in sid/bullseye

[peter green]

severity 936294 serious
thanks

chemfp build-depends on python-openbabel which is no longer built by the 
openbabel source package and is gone from testing/unstable.

Bug#945885: beads: build-depends on package that is gone.

[peter green]

Package: beads
Version: 1.1.18+dfsg-3
Tags: bullseye, sid
Severity: serious

beads build-depends on libquazip5-headers which is no longer built by the 
libquazip source package and is gone from testing and unstable. I believe you 
need to change your build-dependency to libquazip5-dev.

Bug#945877: ifupdown.prerm: script stops networking.service, results in network "break" (kills, e.g., ssh)

[Thomas Lamprecht]

Followup, just re-checked a Debian Stretch installation. There it's all OK,
the offending lines are missing from the prerm script. This then seems to
be a regression which was triggered by the newer compat level 12 and the
different behavior of dh_installsystemd under that level.

Bug#945884: aptly, build-depends on package that is no longer in testing.

[peter green]

Package: aptly
Version: 1.3.0+ds1-2.3
Severity: serious

aptly build-depends on golang-go.tools which has been dropped by the 
golang-golang-x-tools source package. It is still present in unstable as a 
cruft package but is completely gone from testing.

Please update your build-dependency to golang-golang-x-tools-dev

Bug#945883: python-urllib3: Update python3-urllib3 on unstable

[Emmanuel Arias]

Package: python-urllib3
Version: 1.19.1-1
Severity: wishlist

Dear Maintainer,

I am working on update elasticsearch-curator, and this package need
urllib3 >= 1.24.2. Currently the version 1.25.6 is on experimental
is there some  possiblity to move it to unstable, please?

Thanks!
Cheers

Bug#945882: RFS: libt3key/0.2.10-1

[Gertjan Halkes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libt3key"

* Package name: libt3key
  Version : 0.2.10-1
  Upstream Author : Gertjan Halkes 
* URL : https://os.ghalkes.nl/t3/libt3key.html
* License : GPLv3
  Section : libs

It builds those binary packages:

  libt3key-dev - Development files for libt3key
  libt3key1 - Terminal key sequence database library
  libt3key-bin - Utilities for working with libt3key terminal descriptions

To access further information about this package, please visit the following
URL:

https://mentors.debian.net/package/libt3key

Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/libt/libt3key/libt3key_0.2.10-1.dsc

Changes since the last upload:

  * New upstream release.

Regards,
  Gertjan Halkes

Bug#945881: bgpdump: Segmentation fault

[Valentin Vidic]

Package: bgpdump
Version: 1.6.0-1
Severity: grave

Dear Maintainer,

The program segfaults when started:

$ bgpdump 
Segmentation fault

Based on gdb info it seems like the call to log_to_stderr fails:

(gdb) bt
#0  0x2246 in ?? ()
#1  0x77fef5cf in main ()

(gdb) disas main
Dump of assembler code for function main:
   0x77fef5a0 <+0>: push   %r15
   0x77fef5a2 <+2>: xor%r15d,%r15d
   0x77fef5a5 <+5>: push   %r14
   0x77fef5a7 <+7>: mov$0x1,%r14d
   0x77fef5ad <+13>:push   %r13
   0x77fef5af <+15>:lea0xa055(%rip),%r13# 0x77ff960b
   0x77fef5b6 <+22>:push   %r12
   0x77fef5b8 <+24>:mov%rsi,%r12
   0x77fef5bb <+27>:push   %rbp
   0x77fef5bc <+28>:mov%edi,%ebp
   0x77fef5be <+30>:push   %rbx
   0x77fef5bf <+31>:lea0xa7c2(%rip),%rbx# 0x77ff9d88
   0x77fef5c6 <+38>:sub$0x18,%rsp
=> 0x77fef5ca <+42>:callq  0x77fef240 

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

Kernel: Linux 4.19.0-6-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 bgpdump depends on:
ii  libbsd0 0.9.1-2
ii  libbz2-1.0  1.0.6-9.2~deb10u1
ii  libc6   2.28-10
ii  zlib1g  1:1.2.11.dfsg-1

bgpdump recommends no packages.

bgpdump suggests no packages.

-- no debconf information

Bug#945880: XFCE4 menu does not properly display "run program" option icon.

[Leonardo Bruno]

Package: xfce4-appfinder
Version: 4.12.0-2
Severity: minor

XFCE4 menu does not properly display "run program" option icon.

I suggest editing the file "/usr/share/applications/xfce4-run.desktop" to fix 
the error with:
sed -i 's / gtk-run / system-run / g' /usr/share/applications/xfce4-run.desktop

Replace string "gtk-execute" with "system-run". After this the icon is 
displayed correctly.

Bug#937420: Remove pydhcplib from the distribution

[Philipp Kern]

retitle 937420 RM: pydhcplib -- removal triggered by the Python2 removal
thanks

Rationale: package is unmaintained, has very low popcon and no rdeps