Bug#990779: kpartx returns exit code 0 on failure(s)

[Stefan Schwarzer]

Package: kpartx
Version: 0.8.5-2
Severity: minor

Dear Maintainer,

While testing a script, I stumbled over a case where kpartx -av (expectedly) 
failed to
setup loop devices for a standard text file.
The script failed later because the exit code of the command was 0
(echo $? directly after execution of kpartx -av ), which I expected 
to signal
success.

So, it would be great if kpartx one day would return exit codes > 0 on failures 
in line with
other utilities, as this avoids inventing heuristics to parse the output to 
achieve
failure/success detection.




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

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kpartx depends on:
ii  dmsetup 2:1.02.175-2.1
ii  libc6   2.31-12
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  udev247.3-5

kpartx recommends no packages.

kpartx suggests no packages.

-- no debconf information

Bug#984266: Reopen Bug#984266, fixed in experimental

[Rafael Laboissière]

Control: reopen -1
Control: tags -1 + fixed-in-experimental

I am hereby reopening this bug report and tagging it accordingly. The 
fixed version was uploaded to experimental and the version currently in 
sid and testing is impacted by the bug.


Rafael Laboissière

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Christian Marillat]

On 07 juin 2021 09:17, Andreas Beckmann  wrote:

> On 06/06/2021 12.44, Christian Marillat wrote:
>> As requested in your previous e-mail (tesla-450) 450.119.04
>
> Thanks, then I'll try to get that unblocked.
>
> Did you have a chance to test 460.84, yet? The (usually sparse)
> upstream changelog doesn't mention anything related to DP, though, but
> that doesn't mean anything.
> Nobody commented in the forum thread about 460.84 so far.

For me this bug has been fixed in 470.42.01-1 experimental packages.

Christian

Bug#990667: dgit(7) Documentation: MODEL dgit-repo, --overwrite, /fast forward/fast-forward/, --deliberately-not-fast-forward, ...

[Osamu Aoki]

Hi,

On Tue, 2021-07-06 at 18:02 -0700, Sean Whitton wrote:
> Hello Osamu,
> 
> Thank you for this feedback.
> 
> I think our hope is that DDs do not need to read dgit(7) at all.  May I
> ask what prompted you to take a look?  Have you seen the workflow
> tutorial manpages?

In order to try dgit for my imediff package, I was initially reading dgit-maint-
merge(7).  It's basically a Ncurses based merge/split tool for which I took over
upstream.  Since I was upstream, I was comiting everything to devel branch.  
Then I
made a upstream tarball by excluding debian/ directory.  Using this upstream 
tarball,
I was making non-native dpkg 3.0 (quilt) package.  That tarball and uploaded 
debian
package was kept in repo as gbp-style branches (master/upstream/pristine-tar).  
Since
I sometimes made the last minutes change to debian/changelog, master was not 
exactly
as devel.  So after upload, I merged master back to devel.  I got sick of this
complicated scheme and tried git-maint-merge(7).  Basically, devel branch was 
patch
applied while master was sometimes created manually using git-format-patch etc. 
on
devel branch.


Naturally, "Existing git history using another workflow" was the one and I 
started
from my devel branch.  The last part of this document goes as:

>The first dgit push will require --overwrite.  If this is the first
>ever dgit push of the package, consider passing
>--deliberately-not-fast-forward instead of --overwrite.  This avoids
>introducing a new origin commit into your git history.  (This origin
>commit would represent the most recent non-dgit upload of the package,
>but this should already be represented in your git history.)

This talks "first" twice.  What makes "first" not "first ever"? This threw me 
out. 
Besides, "overwrite" sounds scary. Also, at the botton in "INCORPORATING NMUS", 
it
aian recommend to use --overwrite.  Normally, we don't overwrite things without 
fully
understanding its impacts.

Then I went back to the top of the page: "INTRODUCTION" to understand what is 
this
doing.   There,I saw "the information such aseries would contain is readily 
available
from dgit-repos".  This "dgit-repo" made me wonder what exactly is this.  Is 
there
anything more than upload queue and my salsa repo.  

All these lead me to read dgit(7).

It looks like I did OK but I am not sure what exactly happened and where I sent 
the
data.

Osamu

Bug#820848: RFS: phcpack 2.4.84 (NEW)

[Nilesh Patra]

Hi Doug,

On Wed, 7 Jul 2021 at 03:42, Torrance, Douglas 
wrote:

>
> On Wed 19 May 2021 12:37:22 PM EDT, Doug Torrance 
> wrote:
> > I've finished packaging PHCpack, which is written in Ada and solves
> polynomial systems using homotopy continuation, for Debian.  It also
> includes Python and Octave interfaces.
> >
> > Would anyone be willing to review/sponsor?  Note that I currently have
> it set for upload to unstable since it's destined for the NEW queue and I
> don't think that would interfere with the freeze, but perhaps it would make
> sense to upload to experimental instead?
> >
> > https://salsa.debian.org/science-team/phcpack
>
> FYI, I'm still looking for a sponsor for PHCpack.  Upstream recently
> released a new version (2.4.85), and I've updated the packaging in Salsa
> accordingly.
>

./src/Ada/Math_Lib/QD/READ_ME states this:

The main reference for the QD-2.3.9 library is
Y. Hida, X.S. Li, and D.H. Bailey:
"Algorithms for quad-double precision floating point arithmetic."
In 15th IEEE Symposium on Computer Arithmetic (Arith-15 2001),
11-17 June 2001, Vail, CO, USA, pages 155-162. IEEE Computer Society, 2001.
Shortened version of Technical Report LBNL-46996,
software at http://crd.lbl.gov/~dhbailey/mpdist/qd-2.3.9.tar.gz.

Note that the "BSD-LBNL-License" is GPL compatible, although
"If you wish to use the software for commercial purposes
please contact the Technology Transfer Department at t...@lbl.gov or
call 510-286-6457."

I admit, I'm not very sure if I understand the terms there correctly, but
should it be mentioned in d/copyright?
I also see similar stuff in a lot of READ_ME files,
./src/Ada/Root_Counts/MixedVol/READ_ME for instance.

Do they need to be mentioned in d/copyright? If not, IMO adding a
"Comment:" and the reasoning for not adding these in copyright would be
good.


>
> I've also opened a merge request in the Debian Science Blend repo to add
> it to the mathematics task:
> https://salsa.debian.org/blends-team/science/-/merge_requests/7
>
> I'm also still looking for sponsors for a few other packages:
>
> * macaulay2 (new upstream version 1.18, for experimental)
>   https://salsa.debian.org/science-team/macaulay2


Unfortunately, I've got no resources to build it :-(
I hope someone else uploads this. If not, just ping me after your keys are
added to the DM keyring, and I'll grant you DM access for this


> * macaulay2-jupyter-kernel (NEW)
>   https://salsa.debian.org/science-team/macaulay2-jupyter-kernel


Uploaded!


> * qepcad (NEW)
>   https://salsa.debian.org/science-team/qepcad


./plot2d/ADJ2D_plot is a binary file, and I'm sure FTP masters will not
like it. Please repack this and compile the same during the build.


> Good news: my DM application was recently approved, so once the keyring is
> updated, I won't need to ask for sponsorship for non-NEW packages.  :)
>

I'm very happy about this. Whilst I could not advocate you due to us
working on not many packages together, I was definitely cheering on the
sidelines all this while.
I hope you apply for being a DD someday, and by that time I've sponsored
enough packages for you.

Cheers,
Nilesh

Bug#990778: unblock: whois/5.5.10

[Marco d'Itri]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package whois

It has been in unstable for 30 days now and it only contains database 
changes (and one fix for the build process which caused the wrong 
version to be reported).

  * Updated the .lb TLD server.
  * Removed 5 new gTLDs which are no longer active.
  * Updated the charset for whois.lacnic.net, whois.ax, whois.cira.ca
and whois.dns.pt.
  * Fixed reporting an older version number when using --version.

unblock whois/5.5.10

-- 
ciao,
Marco
diff -Nru whois-5.5.9/debian/changelog whois-5.5.10/debian/changelog
--- whois-5.5.9/debian/changelog	2021-03-28 00:38:20.0 +0100
+++ whois-5.5.10/debian/changelog	2021-06-06 19:54:13.0 +0200
@@ -1,3 +1,13 @@
+whois (5.5.10) unstable; urgency=medium
+
+  * Updated the .lb TLD server.
+  * Removed 5 new gTLDs which are no longer active.
+  * Updated the charset for whois.lacnic.net, whois.ax, whois.cira.ca
+and whois.dns.pt.
+  * Fixed reporting an older version number when using --version.
+
+ -- Marco d'Itri   Sun, 06 Jun 2021 19:54:13 +0200
+
 whois (5.5.9) unstable; urgency=medium
 
   * Updated the .ga TLD server.
diff -Nru whois-5.5.9/Makefile whois-5.5.10/Makefile
--- whois-5.5.9/Makefile	2019-12-31 12:14:30.0 +0100
+++ whois-5.5.10/Makefile	2021-06-06 04:13:35.0 +0200
@@ -141,7 +141,7 @@
 	cd po && $(MAKE) install
 
 distclean: clean
-	rm -f po/whois.pot
+	rm -f version.h po/whois.pot
 
 clean:
 	rm -f Makefile.depend as_del.h as32_del.h ip_del.h ip6_del.h \
diff -Nru whois-5.5.9/new_gtlds_list whois-5.5.10/new_gtlds_list
--- whois-5.5.9/new_gtlds_list	2021-02-28 12:58:38.0 +0100
+++ whois-5.5.10/new_gtlds_list	2021-06-06 01:01:07.0 +0200
@@ -383,7 +383,6 @@
 frontier
 ftr
 fujitsu
-fujixerox
 fun
 fund
 furniture
@@ -511,7 +510,6 @@
 istanbul
 itau
 itv
-iveco
 jaguar
 java
 jcb
@@ -664,7 +662,6 @@
 mutual
 nab
 nagoya
-nationwide
 natura
 navy
 nba
@@ -711,7 +708,6 @@
 ong
 onl
 online
-onyourside
 ooo
 open
 oracle
@@ -907,7 +903,6 @@
 space
 sport
 spot
-spreadbetting
 srl
 stada
 staples
diff -Nru whois-5.5.9/servers_charset_list whois-5.5.10/servers_charset_list
--- whois-5.5.9/servers_charset_list	2020-10-03 17:44:03.0 +0200
+++ whois-5.5.10/servers_charset_list	2021-06-06 03:55:46.0 +0200
@@ -4,15 +4,15 @@
 whois.corenic.net	utf-8		-C UTF-8
 whois.online.rs.corenic.net	utf-8	-C UTF-8
 whois.site.rs.corenic.net	utf-8	-C UTF-8
-whois.lacnic.net	iso-8859-1
+whois.lacnic.net	utf-8
 whois.museum		utf-8		-C UTF-8
 whois.ripe.net		iso-8859-1
 
 whois.aeda.net.ae	utf-8
 whois.nic.ar		utf-8
-whois.ax		iso-8859-1
+whois.ax		utf-8
 whois.registro.br	iso-8859-1
-whois.cira.ca		iso-8859-1
+whois.cira.ca		utf-8
 whois.nic.ch		utf-8
 whois.nic.cl		utf-8
 whois.cnnic.cn		utf-8
@@ -47,7 +47,7 @@
 whois.iis.nu		utf-8
 whois.registry.om	utf-8
 whois.registry.pf	utf-8
-whois.dns.pt		iso-8859-1
+whois.dns.pt		utf-8
 whois.registry.qa	utf-8
 whois.nic.re		utf-8
 whois.rnids.rs		utf-8
diff -Nru whois-5.5.9/tld_serv_list whois-5.5.10/tld_serv_list
--- whois-5.5.9/tld_serv_list	2021-02-28 13:25:23.0 +0100
+++ whois-5.5.10/tld_serv_list	2021-06-06 01:00:35.0 +0200
@@ -196,7 +196,7 @@
 .ky	whois.kyregistry.ky
 .kz	whois.nic.kz
 .la	whois.nic.la
-.lb	WEB https://web.aub.edu.lb/cgi-bin/lbdr.pl
+.lb	whois.lbdr.org.lb
 .lc	whois2.afilias-grs.net
 .li	whois.nic.li
 .lk	whois.nic.lk
diff -Nru whois-5.5.9/version.h whois-5.5.10/version.h
--- whois-5.5.9/version.h	2021-02-16 01:54:39.0 +0100
+++ whois-5.5.10/version.h	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-#define VERSION "5.5.8"
-#define IDSTRING "Md5.5.8"


signature.asc
Description: PGP signature

Bug#990775: False positive missing-call-to-dpkg-maintscript-helper

[Gunnar Hjalmarsson]

On 2021-07-07 03:41, Felix Lechner wrote:

On Tue, Jul 6, 2021 at 4:51 PM Gunnar Hjalmarsson
 wrote:

As a result it only contains one mv_conffile command.


Would you please attach the relevant files from the ./debian folder?
Thanks!


Not sure about files (plural), but I attach the .maintscript file. If 
anything else is relevant, this is the repo:


https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/language-selector

--
Cheers,
Gunnar
mv_conffile /etc/fonts/conf.avail/69-language-selector-ar.conf 
/etc/fonts/conf.avail/56-language-selector-ar.conf 0.210~

Bug#990775: False positive missing-call-to-dpkg-maintscript-helper

[Felix Lechner]

Hi Gunnar,

On Tue, Jul 6, 2021 at 4:51 PM Gunnar Hjalmarsson  wrote:
>
> As a result it only contains one mv_conffile command.

Would you please attach the relevant files from the ./debian folder? Thanks!

Kind regards
Felix Lechner

Bug#541316: Jasmine wamah absolutamente le encantó y decidió revelarlo a usted

[Jasmine wamah]

💲👍Usted ha estado sin duda tratando de encontrar algo similar a esto 
http://feedproxy.google.com/~r/78860f/~3/RPQTNe5pL7I



 Jasmine wamah


Muy sinceramente suyo❗

Bug#697039: Quote

[BDO |]

Hello,







I want a quote and I would like to know your availability so that we can send 
you necessary documents as well as drawings and specification.





Thank you,

James Scott

Bug#990776: torbrowser-launcher: apparmor blocks Tor Browser >= 10.5 starting with MOZ_ENABLE_WAYLAND set

[Paul Wise]

Package: torbrowser-launcher
Version: 0.3.3-6
Severity: important
Forwarded: https://github.com/micahflee/torbrowser-launcher/issues/591

Since Tor Browser 10.5, when the MOZ_ENABLE_WAYLAND environment
variable is set, the Firefox build that is part of Tor Browser will try
to use Wayland IPC and if that fails then Tor Browser will not start.
The current torbrowser.Browser.firefox apparmor profile denies access
to the relevant Wayland IPC files/sockets:

   Jul 07 08:23:15 audit[437003]: AVC apparmor="DENIED" operation="mknod" 
profile="torbrowser_firefox" name="/dev/shm/wayland.mozilla.ipc.0" pid=437003 
comm="Compositor" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

   https://blog.torproject.org/new-release-tor-browser-105
   https://gitlab.torproject.org/legacy/trac/-/issues/31729

I was able to workaround this issue using this command:

   sudo sh -c 'echo "owner /dev/shm/wayland.mozilla.ipc.[0-9]* rw," > 
/etc/apparmor.d/local/torbrowser.Browser.firefox ; apparmor_parser -r 
/etc/apparmor.d/torbrowser.Browser.firefox'

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'testing-security')
Architecture: amd64 (x86_64)

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates20210119
ii  gnupg  2.2.27-2
ii  libdbus-glib-1-2   0.110-6
ii  python33.9.2-3
ii  python3-gpg1.14.0-1+b2
ii  python3-packaging  20.9-2
ii  python3-pyqt5  5.15.2+dfsg-3
ii  python3-requests   2.25.1+dfsg-2
ii  python3-socks  1.7.1+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.4.5.9-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.6-10

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990667: dgit(7) Documentation: MODEL dgit-repo, --overwrite, /fast forward/fast-forward/, --deliberately-not-fast-forward, ...

[Sean Whitton]

Hello Osamu,

Thank you for this feedback.

I think our hope is that DDs do not need to read dgit(7) at all.  May I
ask what prompted you to take a look?  Have you seen the workflow
tutorial manpages?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#990637: Why do marble have several .desktop files?

[Matthias Klumpp]

Am Di., 6. Juli 2021 um 23:02 Uhr schrieb Petter Reinholdtsen :
>
> [Sune Stolborg Vuorela]
> > I hope this is sufficient response to "is there a good reason", and I
> > think the script you use should be adapted to work with this pattern.
>
> Note, the  script I use operate on the appstream data set, so the fix
> need to be done in the input system for appstream, not in my script.  Or
> in marble. :)

Nah, AppStream is fine - it's just a misconception that AppStream
would work on all desktop files - it interacting with desktop-files is
mostly a convenience feature with limited applicability. The MetaInfo
files are the actual true source for metadata.
If a software ships addons, upstream needs to provide matching addon
AppStream component definitions (see
https://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html
) otherwise their data will not show up in the component index (and
the addons will not be installable or removable via a GUI software
center).

Cheers,
Matthias.

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Otto Kekäläinen]

> I do have this in a VM so I think we can easily repro this.
>
> // Fresh VM install from debian-10.9.0-i386-netinst.iso
> # history
> 1  visudo
> 2  rm /etc/motd
> 3  poweroff
> 4  apt install mariadb-server
> 5  dpkg -l|grep mariadb
> 6  sed -i 's/buster/bullseye/g' /etc/apt/sources.list
> 7  apt update
> 8  apt upgrade
> 9  apt dist-upgrade // output below
>10  dpkg -l|grep mariadb // output below
>11  apt dist-upgrade // output below

I added a CI job that runs about these and indeed it ends up removing
mariadb-server, and thus the upgrade does not progress.

https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/3c93860e3c065c44e007405915fa762468c82afa
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1743608

Now this is reproducible, good.

Bug#990775: False positive missing-call-to-dpkg-maintscript-helper

[Gunnar Hjalmarsson]

Package: lintian

Version: 2.104.0



I decided to clean up debian/.maintscript from old obsolete 
entries. As a result it only contains one mv_conffile command.




However, Lintian doesn't like that:



E: : missing-call-to-dpkg-maintscript-helper postinst (rm_conffile)

E: : missing-call-to-dpkg-maintscript-helper postrm (rm_conffile)



I see no real problem, though. The single mv_conffile command is added 
to postinst and postrm as expected.




If I add back one of the obsolete rm_conffile entries, Lintian gets quiet.



Caveat: This happens with an Ubuntu specific package (language-selector) 
when building in an Ubuntu environment.


--
Rgds,
Gunnar Hjalmarsson

Bug#990774: runit-init: /lib/runit/shutdown does nothing when called with parameters

[Carsten Leonhardt]

Package: runit-init
Version: 2.1.2-40
Severity: important

Hi Lorenzo,

running runit as PID 1, my habitual "shutdown -r now" doesn't work, it
does nothing at all.

This also prevents acpi-support-base from handling the pressing of the
power button to shutdown, the package calls

/sbin/shutdown -h -P now "Power button pressed"

(see /etc/acpi/powerbtn-acpi-support.sh)

In extension, that prevents libvirt to shutdown/reboot a VM running
with runit-init ("virsh shutdown "). That's the reason I switched
back to sysvinit-core for now.

Regards,

Carsten

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages runit-init depends on:
pn  getty-run
ii  initscripts  2.96-7
pn  runit
ii  sysv-rc  2.96-7

runit-init recommends no packages.

runit-init suggests no packages.

Bug#990773: unblock: kf5-messagelib/4:20.08.3-5

[Sandro Knauß]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Please unblock package kf5-messagelib

[ Reason ]
The -5 just fixes the CVE-2021-31855 handled in #989438:
If a user deletes an attachment of a encrypted mail, that this step
will trigger an upload of the encrypted mail to the IMAP server.

[ Impact ]
The software has a known CVE.

[ Tests ]
Uploaded the -5 several days ago without any bad user response. The
upstream bugfix also did not triggered any bad user expierience on other
linux distros.

[ Risks ]
The fix is very simple just a single line. Myself has reviewd the
upstream bugfix, so I'm quite confident, that I'm sure that this fixes
the CVE properly

[ Checklist ]
  [ x ] all changes are documented in the d/changelog
  [ x ] I reviewed all changes and I approve them
  [ x ] attach debdiff against the package in testing

[ Other info ]
Forgotten to mention the bugnumber in d/changelog.

unblock kf5-messagelib/4:20.08.3-5
diff -Nru kf5-messagelib-20.08.3/debian/changelog 
kf5-messagelib-20.08.3/debian/changelog
--- kf5-messagelib-20.08.3/debian/changelog 2021-04-06 16:22:38.0 
+0200
+++ kf5-messagelib-20.08.3/debian/changelog 2021-06-23 12:48:07.0 
+0200
@@ -1,3 +1,10 @@
+kf5-messagelib (4:20.08.3-5) unstable; urgency=high
+
+  [ Norbert Preining ]
+  * Backport upstream fix for CVE-2021-31855.
+
+ -- Sandro Knauß   Wed, 23 Jun 2021 12:48:07 +0200
+
 kf5-messagelib (4:20.08.3-4) unstable; urgency=medium
 
   * Fix broken patch series file (Closes: #986452).
diff -Nru kf5-messagelib-20.08.3/debian/patches/series 
kf5-messagelib-20.08.3/debian/patches/series
--- kf5-messagelib-20.08.3/debian/patches/series2021-04-06 
16:11:15.0 +0200
+++ kf5-messagelib-20.08.3/debian/patches/series2021-06-10 
16:33:14.0 +0200
@@ -4,3 +4,4 @@
 messagecomposer-Move-protected-headers-to-signed-par.patch
 mail-thread-ignored-and-mail-thread-watched-exist-in.patch
 KeyResolver-Enable-ContactPreferences-again.patch
+upstream-3b5b171e-cv-2021-31855.patch
diff -Nru 
kf5-messagelib-20.08.3/debian/patches/upstream-3b5b171e-cv-2021-31855.patch 
kf5-messagelib-20.08.3/debian/patches/upstream-3b5b171e-cv-2021-31855.patch
--- kf5-messagelib-20.08.3/debian/patches/upstream-3b5b171e-cv-2021-31855.patch 
1970-01-01 01:00:00.0 +0100
+++ kf5-messagelib-20.08.3/debian/patches/upstream-3b5b171e-cv-2021-31855.patch 
2021-06-10 16:33:14.0 +0200
@@ -0,0 +1,24 @@
+From 3b5b171e91ce78b966c98b1292a1bcbc8d984799 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ingo=20Kl=C3=B6cker?= 
+Date: Thu, 29 Apr 2021 22:13:38 +0200
+Subject: [PATCH] Fix CVE-2021-31855
+
+Deleting an attachment of a decrypted encrypted message stored on a remote 
server
+(e.g. an IMAP server) causes KMail to upload the decrypted content of the 
message
+to the remote server. This is not easily noticeable by the user because KMail 
does
+not display the decrypted content.
+---
+ messageviewer/src/viewer/viewer_p.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/messageviewer/src/viewer/viewer_p.cpp
 b/messageviewer/src/viewer/viewer_p.cpp
+@@ -418,7 +418,7 @@ bool ViewerPrivate::deleteAttachment(KMi
+ #ifndef QT_NO_TREEVIEW
+ mMimePartTree->mimePartModel()->setRoot(modifiedMessage);
+ #endif
+-mMessageItem.setPayloadFromData(modifiedMessage->encodedContent());
++mMessageItem.setPayloadFromData(mMessage->encodedContent());
+ Akonadi::ItemModifyJob *job = new Akonadi::ItemModifyJob(mMessageItem, 
mSession);
+ job->disableRevisionCheck();
+ connect(job, &KJob::result, this, &ViewerPrivate::itemModifiedResult);

Bug#820848: RFS: phcpack 2.4.84 (NEW)

[Torrance, Douglas]

On Wed 19 May 2021 12:37:22 PM EDT, Doug Torrance  
wrote:

I've finished packaging PHCpack, which is written in Ada and solves polynomial 
systems using homotopy continuation, for Debian.  It also includes Python and 
Octave interfaces.

Would anyone be willing to review/sponsor?  Note that I currently have it set 
for upload to unstable since it's destined for the NEW queue and I don't think 
that would interfere with the freeze, but perhaps it would make sense to upload 
to experimental instead?

https://salsa.debian.org/science-team/phcpack


FYI, I'm still looking for a sponsor for PHCpack.  Upstream recently released a 
new version (2.4.85), and I've updated the packaging in Salsa accordingly.

I've also opened a merge request in the Debian Science Blend repo to add it to 
the mathematics task:
https://salsa.debian.org/blends-team/science/-/merge_requests/7

I'm also still looking for sponsors for a few other packages:

* macaulay2 (new upstream version 1.18, for experimental)
 https://salsa.debian.org/science-team/macaulay2

* macaulay2-jupyter-kernel (NEW)
 https://salsa.debian.org/science-team/macaulay2-jupyter-kernel

* qepcad (NEW)
 https://salsa.debian.org/science-team/qepcad

Good news: my DM application was recently approved, so once the keyring is 
updated, I won't need to ask for sponsorship for non-NEW packages.  :)

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#990637: Why do marble have several .desktop files?

[Petter Reinholdtsen]

[Sune Stolborg Vuorela]
> I hope this is sufficient response to "is there a good reason", and I
> think the script you use should be adapted to work with this pattern.

Note, the  script I use operate on the appstream data set, so the fix
need to be done in the input system for appstream, not in my script.  Or
in marble. :)

CC to Matthias, to make him aware.

-- 
Vennlig hilsen
Petter Reinholdtsen

Bug#988923: RFS: distorm3/3.5.2b-1 -- powerful disassembler library for x86/AMD64 binary streams (Python3 bindings)

[Lin Qigang]

I fixed most of the lintian errors, but some still exist within the upstream 
release. If anything else needs to be fixed let me know.

Lin Qigang 
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

signature.asc
Description: OpenPGP digital signature

Bug#990754: unblock: wpewebkit/2.32.1-1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-07-06 11:20:10 +0200, Alberto Garcia wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package wpewebkit
> 
> webkit2gtk was unblocked last month, testing has the most recent
> stable version and we will provide security updates during the
> lifetime of bullseye, as we already did during buster.
> 
> wpewebkit is another official port of webkit. It's maintained by the
> same team, follows a very similar release schedule and numbering
> system, shares most of the code and almost all CVEs fixes apply to
> both ports.
> 
> Because of this it won't take me too much effort to prepare security
> updates for wpewebkit so the Debian security team is proposing that we
> also provide them.
> 
> If we do this we should unblock the package and put the latest stable
> version in testing. At the moment the only user of wpewebkit in Debian
> is cog, which is a simple, single-window web browser, developed and
> released by the same team. So we should also unblock cog and the two
> other libraries that are part of the wpewebkit releases: libwpe and
> wpebackend-fdo (I don't know if you need separate bugs to unblock
> those).
> 
> If we don't do this then it's probably a good idea to mention in the
> release notes that wpewebkit is not covered by security updates.

What's the security team's take on this? Will browsers other than firefox,
chromium and webkit2gtk itself be security supported throughout bullseye's
lifetime? I'm particularly curious because the release-notes currently
state:


  
  Security status of web browsers and their rendering engines
  
Debian &release; includes several browser engines which are affected by a
steady stream of security vulnerabilities. The high rate of
vulnerabilities and partial lack of upstream support in the form of long
term branches make it very difficult to support these browsers and
engines with backported security fixes.  Additionally, library
interdependencies make it extremely difficult to update to newer upstream
releases. Therefore, browsers built upon e.g. the webkit and khtml
enginesThese engines are shipped in a number of different
source packages and the concern applies to all packages shipping
them. The concern also extends to web rendering engines not explicitly
mentioned here, with the exception of webkit2gtk. are included in
&releasename;, but not
covered by security support. These browsers should not be used against
untrusted websites.
The webkit2gtk source package is
covered by security support.
  
  
For general web browser use we recommend Firefox or Chromium.
They will
be kept up-to-date by rebuilding the current ESR releases for
stable.
The same strategy will be applied for Thunderbird.
  


If the security team extends security support to the involved packages,
then we'd want debdiffs in separate unblock bugs (except for the
upstream changes copied from webkit2gtk to wpewebkit). Also, the
release-notes need to changed accordingly.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990412: pam: Regression - it won't search /lib/security

[Steve Langasek]

On Tue, Jul 06, 2021 at 08:46:30AM -0600, Sam Hartman wrote:
> > "Hideki" == Hideki Yamane  writes:

> control: tags -1 -patch -pending
> I NACK this proposed NMU.

> This many years after multiarch, I think it is entirely reasonable for
> PAM to drop support for non-multiarch paths at the transition between
> buster and bullseye.
> As I said earlier in the bug, I'm happy to add breaks on libpam-yubico
> or other packages as necessary.
> I think Steve is quite familiar with multiarch and while he hasn't
> commented yet I'm assuming he dropped those patch lines as part of
> removing unnecessary upstream deltas.

> I think you failed to read my comments in the 990412 bug log before
> Merging and reassigning.


For the record, I did not intentionally drop those lines, this was a matter
of a mis-merge.

My only concern about dropping support for the legacy path is that this is
an API that may be used by third-party software, not just by Debian
packages.

I'm ok with requiring all Debian packages to use the multiarch path for PAM
modules, provided libpam0g then also declares a Breaks: against older
versions of those packages which use the legacy path.

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


signature.asc
Description: PGP signature

Bug#990637: Why do marble have several .desktop files?

[Sune Stolborg Vuorela]

On Saturday, July 3, 2021 1:53:53 PM CEST Petter Reinholdtsen wrote:
> Package: marble
> Version: 4:17.08.3-3.2
> 
> I just noticed the .desktop files in marble confuses the script used to
> generate https://wiki.debian.org/MimeTypesSupport/PackageList >
> because it contain 9 .desktop files:

Let's start by ignoring the ones placed in KService dir. They are for plugins 
for the KService library.

> % dpkg -L marble|grep desktop
> /usr/share/applications/marble_geo.desktop
> /usr/share/applications/marble_gpx.desktop
> /usr/share/applications/marble_kml.desktop
> /usr/share/applications/marble_kmz.desktop
> /usr/share/applications/marble_shp.desktop
> /usr/share/applications/marble_worldwind.desktop
> /usr/share/applications/org.kde.marble.desktop

 
> Is there a good reason for all these desktop files.  At elast some of
> them seem redundant:
>   MimeType=application/x-gpx+xml;application/x-esri-shape;

If I understand it correctly, it being marble and the desktop spec, all of the 
extra mime types are supported by marble thru optional plugins; optional 
plugins that distributions might want to carry in different binary packages, or 
maybe even not carry at all, and only if the the plugin for application/x-
esri-shape is installed, marble support this mimetype.

For plugin-based software, this is makes sense.

Also e.g. okular uses the same approach. Here is the Debian package split into 
two packages with the lesser used packages with heavy dependencies resides.

I hope this is sufficient response to "is there a good reason", and I think the 
script you use should be adapted to work with this pattern.

Kind regards
/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#987226: youtube-dl: needs version update to 2021.05.16 to continue working with youtube

[Thorsten Glaser]

found 987226 2021.02.10-2
thanks

Andreas Tille dixit:

>Could you please give some example to reproduce the bug?  When asking

This is… indeed tricky… I tried a couple URLs but they work;
I don’t have a viewing history though. The example from Mike’s
bug still fails, though:

tglase@tglase-nb:/tmp $ youtube-dl -f 18 
OLAK5uy_m3-t4xLGBOHujynldlI3w-3Qp0WU62EAo
[youtube:tab] OLAK5uy_m3-t4xLGBOHujynldlI3w-3Qp0WU62EAo: Downloading webpage
ERROR: Unable to extract yt initial data; please report this issue on 
https://yt-dl.org/bug . Make sure you are using the latest version; see  
https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the 
--verbose flag and include its complete output.
1|tglase@tglase-nb:/tmp $ Youtube-dl -f 18 
OLAK5uy_m3-t4xLGBOHujynldlI3w-3Qp0WU62EAo
[youtube:tab] OLAK5uy_m3-t4xLGBOHujynldlI3w-3Qp0WU62EAo: Downloading webpage
[download] Downloading playlist: New Song
[youtube:tab] playlist New Song: Downloading 11 videos
[download] Downloading video 1 of 11
[youtube] P8kTNCUzC1g: Downloading webpage
[youtube] P8kTNCUzC1g: Downloading player 7acefd5d
^C
ERROR: Interrupted by user

Second one (Youtube-dl with capital Y) is the upstream binary, patched
to have python3 in the shebang, shown to prove they fixed it later on.
I aborted it because I’m not interested in downloading that actually ☺

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#990772: unblock: usb.ids/2021.06.06-1

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package usb.ids

[ Reason ]
This new upstream version of the USB ID database adds a few USB devices.

[ Impact ]
New USB devices won't be displayed with a human readable name for
package using this database.

[ Tests ]
There is no test associated with this database. This package only
contains data, no code. 

[ Risks ]
Risks are very low, such update are routinely done in stable.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
None

unblock usb.ids/2021.06.06-1
diff -Nru usb.ids-2021.03.31/debian/changelog 
usb.ids-2021.06.06/debian/changelog
--- usb.ids-2021.03.31/debian/changelog 2021-04-06 00:36:05.0 +0200
+++ usb.ids-2021.06.06/debian/changelog 2021-06-06 22:58:30.0 +0200
@@ -1,3 +1,15 @@
+usb.ids (2021.06.06-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Sun, 06 Jun 2021 22:58:30 +0200
+
+usb.ids (2021.05.18-1) unstable; urgency=medium
+
+  * New upstream version.
+
+ -- Aurelien Jarno   Sun, 23 May 2021 00:05:56 +0200
+
 usb.ids (2021.03.31-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru usb.ids-2021.03.31/usb.ids usb.ids-2021.06.06/usb.ids
--- usb.ids-2021.03.31/usb.ids  2021-03-31 21:34:09.0 +0200
+++ usb.ids-2021.06.06/usb.ids  2021-06-06 21:34:10.0 +0200
@@ -9,8 +9,8 @@
 #  The latest version can be obtained from
 #  http://www.linux-usb.org/usb.ids
 #
-# Version: 2021.03.31
-# Date:2021-03-31 20:34:09
+# Version: 2021.06.06
+# Date:2021-06-06 20:34:10
 #
 
 # Vendors, devices and interfaces. Please keep sorted.
@@ -800,6 +800,7 @@
6014  FT232H Single HS USB-UART/FIFO IC
6015  Bridge(I2C/SPI/UART/FIFO)
601f  Myriad-RF LimeSDR-Mini
+   6ee0  EZO Carrier Board
6f70  HB-RF-USB
8028  Dev board JTAG (FT232H based)
8040  4 Port Hub
@@ -929,6 +930,7 @@
f7c0  ZeitControl Cardsystems TagTracer MIFARE
f850  USB-UIRT (Universal Infrared Receiver+Transmitter)
f918  Ant8 Logic Probe
+   f9d9  Wetterempfanger 147.3kHz
fa00  Matrix Orbital USB Serial
fa01  Matrix Orbital MX2 or MX3
fa02  Matrix Orbital MX4 or MX5
@@ -1447,6 +1449,7 @@
4088  Live! Cam Chat HD [VF0700]
4095  Live! Cam Sync HD [VF0770]
4097  Live! Cam Chat HD [VF0700]
+   4099  Creative VF0800 [RealSense Camera SR300]
4100  Nomad Jukebox 2
4101  Nomad Jukebox 3
4102  NOMAD MuVo^2
@@ -2010,6 +2013,7 @@
b651  Ferrari GT Rumble Force Wheel
b653  RGT Force Feedback Clutch Racing Wheel
b654  Ferrari GT Force Feedback Wheel
+   b677  T150 Racing Wheel
b678  T.Flight Rudder Pedals
b679  T-Rudder
b687  TWCS Throttle
@@ -2690,9 +2694,15 @@
0837  BCC950 ConferenceCam
0840  QuickCam Express
0843  Webcam C930e
+   0845  ConferenceCam CC3000e Camera
+   0846  ConferenceCam CC3000e Speakerphone
+   084b  ConferenceCam Connect Video
0850  QuickCam Web
+   0857  Logi Group Speakerphone
085c  C922 Pro Stream Webcam
+   085e  BRIO Ultra HD Webcam
0870  QuickCam Express
+   0882  Logi Group Speakerphone
0890  QuickCam Traveler
0892  C920 HD Pro Webcam
0893  StreamCam
@@ -3315,6 +3325,7 @@
5002  VideoCam CABO II
5003  VideoCam
8018  Expert Wireless Trackball Mouse (K72359WW)
+   8068  Pro Fit Ergo Vertical Wireless Trackball
 047e  Agere Systems, Inc. (Lucent)
0300  ORiNOCO Card
1001  USS720 Parallel Port
@@ -4462,6 +4473,8 @@
040e  DSC D70s (ptp)
040f  D200 (mass storage mode)
0410  D200 (ptp)
+   0411  D80 (mass storage mode)
+   0412  D80 (MTP/PTP mode)
0413  D40 (mass storage mode)
041e  D60 digital camera (mass storage mode)
0422  D700 (ptp)
@@ -5126,6 +5139,7 @@
e002  MCU
fc2a  Gaming Mouse [Redragon M709]
fc30  Gaming Mouse [Redragon M711]
+   fc38  Gaming Mouse [Redragon M602-RGB]
fc4d  Gaming Mouse [Redragon M908]
fc55  Venus MMO Gaming Mouse
 04da  Panasonic (Matsushita)
@@ -6846,6 +6860,7 @@
0cd3  WH-1000XM3 [Wireless Noise-Canceling Headphones]
0cda  PlayStation Classic controller
0ce0  WF-1000XM3 [Wireless Noise-Canceling Headphones]
+   0cf0  MRW-G1
0d58  WH-1000XM4 [Wireless Noise-Canceling Headphones]
1000  Wireless Buzz! Receiver
 054d  Try Corp.
@@ -7222,7 +7237,19 @@
0001  Monitor
0002  HID Monitor Controls
0003  Device Bay Controller
+   4000  FlexScan EV3237
4001  Monitor
+   4002  USB HID Monitor
+   4014  FlexScan EV2750
+   4026  FlexScan EV2451
+  

Bug#988618: unblock: kodi-pvr-iptvsimple/7.6.5+ds1-1

[Vasyl Gello]

Hi Sebastian!

Upload is done.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#988616: Acknowledgement (unblock: kodi-inputstream-ffmpegdirect/1.21.3+ds1-1)

[Vasyl Gello]

Hi Sebastian!

Upload is done.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#990771: RFS: s2geometry/0.9.0-1 [ITP] -- Computational geometry and spatial indexing on the sphere

[Emmanuel Arias]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "s2geometry":

 * Package name: s2geometry
   Version : 0.9.0-1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://github.com/google/s2geometry
 * License : BSD-3-Clause, Apache-2.0
 * Vcs : https://salsa.debian.org/eamanu/s2geometry
   Section : libs

It builds those binary packages:

  s2geometry - Computational geometry and spatial indexing on the sphere

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/s2geometry/s2geometry_0.9.0-1.dsc

Changes for the initial release:

 s2geometry (0.9.0-1) unstable; urgency=low
 .
   * Initial release. Closes: #962686

Regards,
-- 
  Emmanuel Arias

Bug#990748: Proposed patch/debdiff

[Salvatore Bonaccorso]

Control: tags 990748 + patch
Control: tags 990749 + patch

Hi

Attached is the current proposed debdiff (not yet uploaded).

Regards,
Salvatore
diff -Nru linuxptp-3.1/debian/changelog linuxptp-3.1/debian/changelog
--- linuxptp-3.1/debian/changelog   2020-12-13 23:33:39.0 +0100
+++ linuxptp-3.1/debian/changelog   2021-07-06 20:16:00.0 +0200
@@ -1,3 +1,13 @@
+linuxptp (3.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Validate the messageLength field of incoming messages (CVE-2021-3570)
+(Closes: #990748)
+  * tc: Fix length of follow-up message of one-step sync (CVE-2021-3571)
+(Closes: #990749)
+
+ -- Salvatore Bonaccorso   Tue, 06 Jul 2021 20:16:00 +0200
+
 linuxptp (3.1-2) unstable; urgency=medium
 
   [ Punit Agrawal ]
diff -Nru 
linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
 
linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
--- 
linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
  1970-01-01 01:00:00.0 +0100
+++ 
linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
  2021-07-06 20:11:54.0 +0200
@@ -0,0 +1,96 @@
+From: Richard Cochran 
+Date: Sat, 17 Apr 2021 15:15:18 -0700
+Subject: Validate the messageLength field of incoming messages.
+Origin: 
https://github.com/richardcochran/linuxptp/commit/ce15e4de5926724557e8642ec762a210632f15ca
+Bug-Debian: https://bugs.debian.org/990748
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-3570
+
+The PTP messageLength field is redundant because the length of a PTP
+message is precisely determined by the message type and the appended
+TLVs.  The current implementation validates the sizes of both the main
+message (according to the fixed header length and fixed length by
+type) and the TLVs (by using the 'L' of the TLV).
+
+However, when forwarding a message, the messageLength field is used.
+If a message arrives with a messageLength field larger than the actual
+message size, the code will read and possibly write data beyond the
+allocated buffer.
+
+Fix the issue by validating the field on ingress.  This prevents
+reading and sending data past the message buffer when forwarding a
+management message or other messages when operating as a transparent
+clock, and it also prevents a memory corruption in msg_post_recv()
+after forwarding a management message.
+
+Reported-by: Miroslav Lichvar 
+Signed-off-by: Richard Cochran 
+---
+ msg.c | 18 --
+ 1 file changed, 12 insertions(+), 6 deletions(-)
+
+diff --git a/msg.c b/msg.c
+index d1619d4973f1..5ae8ebbfc3ae 100644
+--- a/msg.c
 b/msg.c
+@@ -186,7 +186,7 @@ static int suffix_post_recv(struct ptp_message *msg, int 
len)
+ {
+   uint8_t *ptr = msg_suffix(msg);
+   struct tlv_extra *extra;
+-  int err;
++  int err, suffix_len = 0;
+ 
+   if (!ptr)
+   return 0;
+@@ -204,12 +204,14 @@ static int suffix_post_recv(struct ptp_message *msg, int 
len)
+   tlv_extra_recycle(extra);
+   return -EBADMSG;
+   }
++  suffix_len += sizeof(struct TLV);
+   len -= sizeof(struct TLV);
+   ptr += sizeof(struct TLV);
+   if (extra->tlv->length > len) {
+   tlv_extra_recycle(extra);
+   return -EBADMSG;
+   }
++  suffix_len += extra->tlv->length;
+   len -= extra->tlv->length;
+   ptr += extra->tlv->length;
+   err = tlv_post_recv(extra);
+@@ -219,7 +221,7 @@ static int suffix_post_recv(struct ptp_message *msg, int 
len)
+   }
+   msg_tlv_attach(msg, extra);
+   }
+-  return 0;
++  return suffix_len;
+ }
+ 
+ static void suffix_pre_send(struct ptp_message *msg)
+@@ -337,7 +339,7 @@ void msg_get(struct ptp_message *m)
+ 
+ int msg_post_recv(struct ptp_message *m, int cnt)
+ {
+-  int pdulen, type, err;
++  int err, pdulen, suffix_len, type;
+ 
+   if (cnt < sizeof(struct ptp_header))
+   return -EBADMSG;
+@@ -422,9 +424,13 @@ int msg_post_recv(struct ptp_message *m, int cnt)
+   break;
+   }
+ 
+-  err = suffix_post_recv(m, cnt - pdulen);
+-  if (err)
+-  return err;
++  suffix_len = suffix_post_recv(m, cnt - pdulen);
++  if (suffix_len < 0) {
++  return suffix_len;
++  }
++  if (pdulen + suffix_len != m->header.messageLength) {
++  return -EBADMSG;
++  }
+ 
+   return 0;
+ }
+-- 
+2.32.0
+
diff -Nru linuxptp-3.1/debian/patches/series linuxptp-3.1/debian/patches/series
--- linuxptp-3.1/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ linuxptp-3.1/debian/patches/series  2021-07-06 20:14:15.0 +0200
@@ -0,0 +1,2 @@
+Validate-the-messageLength-field-of-incoming-message.patch
+tc-Fix-length-

Bug#990770: tcode -- add autopkgtests

[Nilesh Patra]

Package: tcode
Version: 0.1.20080918-3
Severity: normal
Tags: patch
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,

tcode does not have any autopkgtests at the moment,
I've attempted adding these, please consider applying the patch

Nilesh

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

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

Versions of packages tcode depends on:
ii  default-jre   2:1.11-72
pn  latex2html
pn  texlive-bibtex-extra  

tcode recommends no packages.

tcode suggests no packages.
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..ac78501
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,3 @@
+Tests: run-unit-test
+Depends: @, default-jdk-headless
+Restrictions: allow-stderr
diff --git a/debian/tests/example-texjava.java 
b/debian/tests/example-texjava.java
new file mode 100644
index 000..2e775e9
--- /dev/null
+++ b/debian/tests/example-texjava.java
@@ -0,0 +1,52 @@
+\defclass{Complex}
+This class allows one to work with complex numbers of
+the form $a + bi$, where $a$ is the \emph{real} part of
+the number, \emph{b} is the imaginary part and
+$i=\sqrt{-1}$.
+\bigskip\hrule\bigskip
+\begin{code}
+public class Complex\begin{hide} {
+private double realPart;
+private double imagPart;\end{hide}
+public Complex (double realPart, double imagPart)\begin{hide} {
+this.realPart = realPart;
+this.imagPart = imagPart;
+}\end{hide}
+\end{code}
+\begin{tabb} Constructs a new {\tt Complex} number.
+\param{realPart}{The real part corresponding to $a$}
+\param{imagPart}{The imaginary part corresponding to $b$}
+\end{tabb}
+\begin{code}
+public Complex add (Complex c)\begin{hide} {
+realPart += c.realPart;
+imagPart += c.realPart;
+return this;
+}\end{hide}
+
+\end{code}
+\begin{tabb} Adds two complex numbers.
+\param{c}{The complex number to add to this one.}
+\return{This object, allowing to perform more than one operation
+on a single line of code.}
+\end{tabb}
+\begin{code}
+// other methods...
+public String toString()\begin{hide} {
+return "(" + realPart + " + " + imagPart + "i)";
+}
+// Test code
+public static void main(String[] args) {
+   Complex c1 = new Complex(1, 2);
+   Complex c2 = new Complex(2, 3);
+   assert c1.add(c2).toString().equals("(3.0 + 4.0i)");
+   System.out.println("PASS");
+}
+}\end{hide}
+\end{code}
+\begin{tabb}
+ Converts the number to a {\tt String} of
+the form {\tt a + bi}.
+\end{tabb}
+
+
diff --git a/debian/tests/run-unit-test b/debian/tests/run-unit-test
new file mode 100644
index 000..99d8710
--- /dev/null
+++ b/debian/tests/run-unit-test
@@ -0,0 +1,27 @@
+#!/bin/bash
+set -e
+
+pkg=tcode
+CUR_DIR=`pwd`
+
+export LC_ALL=C.UTF-8
+if [ "${AUTOPKGTEST_TMP}" = "" ] ; then
+  AUTOPKGTEST_TMP=$(mktemp -d /tmp/${pkg}-test.XX)
+  trap "rm -rf ${AUTOPKGTEST_TMP}" 0 INT QUIT ABRT PIPE TERM
+fi
+
+cp /usr/share/doc/${pkg}/examples/* "${AUTOPKGTEST_TMP}"
+cd "${AUTOPKGTEST_TMP}"
+
+# Running texjava
+texjava -savelatex example-texjava.java Complex.java
+
+# Verify that the latex part indeed is saved
+fgrep -q "This class allows one to work with complex numbers of" Complex.java
+
+# Running the code
+javac Complex.java
+java -enableassertions Complex
+
+# Cleanup
+rm -f Complex*

Bug#990762: undocumented option to apt-get

[Ian Smith]

Package: apt-get
Version: all

-u option is listed at the top of the man page but not documented there

I assume it is now default behaviour

Cheers,

Ian Smith

Bug#990412: pam: Regression - it won't search /lib/security

[Sam Hartman]

> "Hideki" == Hideki Yamane  writes:
>> I think Steve is quite familiar with multiarch and while he
>> hasn't commented yet I'm assuming he dropped those patch lines as
>> part of removing unnecessary upstream deltas.

Hideki>  I want his comment, too.

Okay, let's hold off until Steve speaks up then.
Meanwhile, I definitely think we should fix libpam-yubico any other PAM
modules we ideftify.
PAM modules need to be multi-arch so that if any non-native application
calls libpam, it works.
So there's at least an important if not serious bug in not having
multi-arch:same for a PAM module.


signature.asc
Description: PGP signature

Bug#985024: python3-num2words: SyntaxWarning during package installation

[Diego M. Rodriguez]

On Thu, 11 Mar 2021 22:01:47 +0100 Andreas Beckmann  wrote:
> during a test with piuparts I noticed your package emits a SyntaxWarning
> during installation:
>   [...]

The bug seems to have been fixed upstream [1], and is part of a newer
0.5.10 release [2] (which coincidentally seems that is not currently
picked up by uscan, likely due to the GitHub URL changes a while back).

[1] https://github.com/savoirfairelinux/num2words/pull/240
[2] https://github.com/savoirfairelinux/num2words/releases/tag/v0.5.10
-- 
Diego M. Rodriguez

Bug#990768: tcode -- Does not build reproducibly

[Nilesh Patra]

Package: tcode
Version: 0.1.20080918-3
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: nil...@debian.org, nil...@debian.org, 
reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

src:tcode fails to build reproducibly because it
vendors a pdf that saves in build dates on several pages.

Hence the best way is to simply remove build date from the said pdf.
Vendoring the "build date" is rarely useful, and hence can be easily
removed.

Please consider applying the attached patch

Nilesh

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

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

Versions of packages tcode depends on:
ii  default-jre   2:1.11-72
pn  latex2html
pn  texlive-bibtex-extra  

tcode recommends no packages.

tcode suggests no packages.
--- a/tcode.tex
+++ b/tcode.tex
@@ -5,7 +5,6 @@
 \usepackage{tcode}
 
 \mytwoheads
-\dateheadtrue
 \tolerance=500
 \textwidth=6.5in
 \textheight=9.5in
@@ -33,7 +32,6 @@
 {\Large\bf TCode} \\[20pt] 
 {\Large\bf User Guide } \\[20pt] 
 {\Large\bf Tools for documenting Java programs in \LaTeX }\\[15pt] 
- Version: \today \\
 \vfill\vfill
 \end {center}
 

Bug#990769: ITP: golang-github-smallstep-assert -- simple assertion framework for Go

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-smallstep-assert
  Version : 0.0~git20200723.82e2b9b-1
  Upstream Author : Smallstep
* URL : https://github.com/smallstep/assert
* License : Expat
  Programming Lang: Go
  Description : simple assertion framework for Go
 This project provides a go library for assertion. 
 Read online reference at http://godoc.org/github.com/smallstep/assert

This package is a dependency of #989857

Bug#990412: pam: Regression - it won't search /lib/security

[Hideki Yamane]

Hi Sam,

On Tue, 06 Jul 2021 08:46:30 -0600 Sam Hartman  wrote:
> This many years after multiarch, I think it is entirely reasonable for
> PAM to drop support for non-multiarch paths at the transition between
> buster and bullseye.

 It was NOT raised as a goal of bullseye for libpam-* packages those
 are not multiarch-ed, IMO. And at this time, last minutes for release,
 we should ensure "it works" as previously to deliver values for users.
 Breaking several libpam-* packages is not.

 Is there any *strong* reason to not deffer make libpam-* packages multiarch-ed
 to bookworm release?


> I think Steve is quite familiar with multiarch and while he hasn't
> commented yet I'm assuming he dropped those patch lines as part of
> removing unnecessary upstream deltas.

 I want his comment, too. git log in his repo just says "refresh
 patches" for this change, and 
debian/patches-applied/lib_security_multiarch_compat
 is the patch for non-multiarch pam modules and still remains. If it
 was intended, it should be removed, I suppose.


> I think you failed to read my comments in the 990412 bug log before
> Merging and reassigning.
 
 Okay, will read again. Thanks!


-- 
Hideki Yamane 

Bug#946649: libnss-unknown breaks adduser and useradd

[Doug Eubanks]

I can confirm this still breaks adding users in Ubuntu 20.04, Kubuntu, and
the current version of KDE Neon.

Bug#990412: pam: Regression - it won't search /lib/security

[Sam Hartman]

> "Hideki" == Hideki Yamane  writes:

control: tags -1 -patch -pending
I NACK this proposed NMU.

This many years after multiarch, I think it is entirely reasonable for
PAM to drop support for non-multiarch paths at the transition between
buster and bullseye.
As I said earlier in the bug, I'm happy to add breaks on libpam-yubico
or other packages as necessary.
I think Steve is quite familiar with multiarch and while he hasn't
commented yet I'm assuming he dropped those patch lines as part of
removing unnecessary upstream deltas.

I think you failed to read my comments in the 990412 bug log before
Merging and reassigning.





signature.asc
Description: PGP signature

Bug#990767: game-data-packager: Add support for gog version of Heretic

[Hans Joachim Desserud]

Package: game-data-packager
Version: 67
Severity: normal
Tags: patch

Dear Maintainer,

The attached patch adds support for the recently released gog
version of Heretic. Got it working after some trial and error, and
from what I can see the wad-file (unsuprisingly) matches the
existing checksums.

Example of working package creation:
$ game-data-packager heretic 
setup_heretic_shadow_of_the_serpent_riders_1.3_\(42801\).exe

identifying setup_heretic_shadow_of_the_serpent_riders_1.3_(42801).exe
identifying 
/tmp/gdptmp.wp8en76y/tmp/setup_heretic_shadow_of_the_serpent_riders_1.3_(42801).exe.d/HERETIC.WAD
INFO:game_data_packager.build:will not produce "heretic-shareware-wad" 
because we have the full version "heretic-wad"
WARNING:game_data_packager.games.doom_common:Unable to load omgifol and 
PIL modules. No icons will get extracted from WAD files.

INFO:game_data_packager.packaging.deb:generating package heretic-wad
generated "/home/debian/Desktop/heretic shadow of the serpent 
riders/heretic-wad_67+nmu4_all.deb"



In other data files I saw metadata fields for gog, for instance
https://salsa.debian.org/games-team/game-data-packager/-/blob/master/data/doom.yaml
However I couldn't find any information on which values are expected
or where these might be used, so I didn't add any.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages game-data-packager depends on:
ii  dpkg1.20.9
ii  fakeroot1.25.3-1.1
ii  python3 3.9.2-3
ii  python3-debian  0.1.39
ii  python3-yaml5.3.1-5

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  67

Versions of packages game-data-packager suggests:
pn  arj
ii  binutils   2.35.2-2
pn  cabextract 
pn  cdparanoia 
pn  dynamite   
ii  gcc4:10.2.1-1
pn  gdebi | gdebi-kde  
ii  gir1.2-gdkpixbuf-2.0   2.42.2+dfsg-1
ii  innoextract1.8-1.2+b1
pn  lgc-pg 
ii  lgogdownloader 3.7-1+b4
pn  lhasa | jlha-utils | lzh-archiver  
ii  make   4.3-4.1
ii  p7zip-full 16.02+dfsg-8
ii  python3-gi 3.38.0-2
pn  python3-omg
pn  python3-pil
pn  steam  
pn  steamcmd   
pn  unace-nonfree  
pn  unar   
pn  unrar  
pn  unshield   
ii  unzip  6.0-26
pn  vorbis-tools   
ii  xdelta 1.1.3-9.3
ii  xdelta33.0.11-dfsg-1+b1

-- no debconf information


--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/data/heretic.yaml b/data/heretic.yaml
index 229089ac..067149e2 100644
--- a/data/heretic.yaml
+++ b/data/heretic.yaml
@@ -62,6 +62,11 @@ files:
 unpack:
   format: zip
 
+  setup_heretic_shadow_of_the_serpent_riders_1.3_(42801).exe:
+unpack:
+  format: innoextract
+provides: ['heretic.wad?1.3']
+
   heretic.wad:
 alternatives:
 - heretic.wad?1.3
@@ -92,6 +97,7 @@ groups:
 11096488 3117e399cdb4298eaa3941625f4b2923 heretic.wad?1.0
 11095516 1e4cb4ef075ad344dd63971637307e04 heretic.wad?1.2
 14189976 66d686b1ed6d35ff103f15dbd30e0341 heretic.wad?1.3
+24813248 695301b720dee55fb9e394534c5c45de setup_heretic_shadow_of_the_serpent_riders_1.3_(42801).exe
 
 sha1sums: |
   c97b176fe0458039219eb426ad315dc5ff155324  license.doc
@@ -103,6 +109,7 @@ sha1sums: |
   15e536e2af20fb6e3cf21e35eb40d17df2276ee6  HTIC_V12.1
   ba5e52bffc34a9e16f1c20d3ce3465cc58fc9968  HTIC_V12.2
   4643f3bfcc5c2d0bdf304025f618e5cd1e32e2e0  htic_v12.exe
+  722132877b25fced7615d37c7c435d47a616f277  setup_heretic_shadow_of_the_serpent_riders_1.3_(42801).exe
 
 sha256sums: |
   5ffbb47e4a5750fef144c312973ee5782266b4a63474b77478103b6c1aaed39d  htic_v12.zip
@@ -110,6 +117,7 @@ sha256sums: |
   5ae52ee961636418e10f5fd71e4c44d56b4adf8116a299350ab3cae15a4a10a8  HTIC_V12.1
   62c9c88adc3e97dc301f155ab1651083c2e6a9b0dde44e817b2d4e39fbbc0176  HTIC_V12.2
   34c44e1153a636278daadcaa5904c9a02ab14cee58518f59bb88af6f481a2d5d  htic_v12.exe
+  e3dac562a6642aff2ffe5c3cf24923eda28eb22a32d73d56e0aae9bc95d6a594  setup_heretic_shadow_of_the_serpent_riders_1.3_(42801).exe
 
 ...
 # vim:set sw=2 sts=2 et:

Bug#968045: golang-gonum-v1-plot: please make the build reproducible

[Nilesh Patra]

Hi Chris,

On Mon, 01 Mar 2021 13:08:03 - "Chris Lamb"  wrote:
> Hi Nilesh,
> 
> (Just to say that I did not see your two emails until now; the bug
> submitter does not automatically receive emails sent directly to the
> bug email address — one should either CC them directly or use the
> 968045-submitter@ alias too.)

CC'ed you this time, and apologies for not having seen these emails till
now, I did not receive this either :)

> > Thanks again, but unfortunately this patch breaks the autopkgtests :/
> > The only way to make it reproducible and allow testing migration would
> > be to disable the tests.
> 
> As I understand the problem:
> 
> * The data underneath /testdata/ has non-deterministic data (PDFs)
> 
> * The patch prevents /testdata/ from being installed in the binary
>   package.
> 
> * The autopkgtests fail as they require this test data.

Yes, that is exactly what is happening

> > What do you think would be better? Please let me know.
> 
> Interesting choice of trade-off. Would it be possible for the
> autopkgtests to build the test data at "autopkgtest time"?

Probably, however this will need a few workarounds
Autopkgtests are triggered with the default autodep8 thing for
dh-make-golang,
So this will likely need a script followed by the normal autopkgtesting stuff

> Alternatively, do we need these PDFs? We could ship the testdata
> directory but not ship the .pdf files?

Probably not.
The build time tests are run as autopkgtests as well, so if you remove
these tests, or patch these out, the effect will be same on both.
One of the things I'm not very fond of about the golang system :)

Several packages keep on shipping these data just for testing purposes
-- nothing wrong, but lack of choice for customisation

> The other, nicer solution could be to patch fpdf to use the
> SOURCE_DATE_EPOCH environment variable if it exists. This would seem
> quite straightforward to do, actually -- this is fpdf.go from the
> "golang-github-jung-kurt-gofpdf" source package:
> 
>   // returns Now() if tm is zero
>   func timeOrNow(tm time.Time) time.Time {
> if tm.IsZero() {
>   return time.Now()
> }
> return tm
>   }

Indeed, I'll give this a shot, and see how this goes, thanks for
pointing this out!

Nilesh


signature.asc
Description: PGP signature

Bug#990766: unblock: kakoune/2020.01.16-3

[Peter Pentchev]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package kakoune to fix a grave bug that makes it
unusable if it is started via "su" before being started from
a normal user account.

[ Reason ]
See #990635 for more information: if, after the system has been
restarted, kakoune is invoked via "su" before it has been invoked
from the session user's account, it will create its runtime
/run/user//kakoune directory owned by root. This will prevent
later instances of kakoune, started with normal user rights, from
running at all.

[ Impact ]
If the user runs `su -c 'kak ...'` before running `kak ...`, they
will be unable to run `kak ...` until they remove the runtime
directory or the system is restarted.

[ Tests ]
None.

[ Risks ]
Leaf package, not widely used. The upstream fix is pretty
straightforward - check user IDs, verify directory ownership,
use a different directory if necessary. Hopefully very low risk.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock kakoune/2020.01.16-3
diff -Nru kakoune-2020.01.16/debian/changelog 
kakoune-2020.01.16/debian/changelog
--- kakoune-2020.01.16/debian/changelog 2020-07-26 01:56:44.0 +0300
+++ kakoune-2020.01.16/debian/changelog 2021-07-05 22:15:28.0 +0300
@@ -1,3 +1,12 @@
+kakoune (2020.01.16-3) unstable; urgency=medium
+
+  * Add the 13-upstream-check-dir-owner and 14-upstream-rework-dir-logic
+patches from the upstream Git repository to stop kakoune started as
+root from making its runtime directory inaccessible to the normal
+user account of the session user. Closes: #990635
+
+ -- Peter Pentchev   Mon, 05 Jul 2021 22:15:28 +0300
+
 kakoune (2020.01.16-2) unstable; urgency=medium
 
   * Add some files to debian/clean to allow kakoune to be built twice in
diff -Nru kakoune-2020.01.16/debian/patches/13-upstream-check-dir-owner.patch 
kakoune-2020.01.16/debian/patches/13-upstream-check-dir-owner.patch
--- kakoune-2020.01.16/debian/patches/13-upstream-check-dir-owner.patch 
1970-01-01 02:00:00.0 +0200
+++ kakoune-2020.01.16/debian/patches/13-upstream-check-dir-owner.patch 
2021-07-05 22:05:35.0 +0300
@@ -0,0 +1,22 @@
+Description: Check XDG_RUNTIME_DIR owner before creating session directory
+ This avoids an issue when using `su` and running Kakoune which creates
+ a session directory owned by root and prevents the user from creating
+ more sessions.
+Origin: upstream; 
https://github.com/mawww/kakoune/commit/7751c7e188bfc7b2f7e4a70e33032677d84597e5
+Author: Maxime Coste 
+Bug-Debian: https://bugs.debian.org/990635
+Last-Update: 2021-07-05
+
+--- a/src/remote.cc
 b/src/remote.cc
+@@ -554,6 +554,10 @@
+ // set sticky bit on the shared kakoune directory
+ make_directory(format("{}/kakoune", tmpdir()), 01777);
+ }
++else if (struct stat st;
++ stat(xdg_runtime_dir.zstr(), &st) == 0 && st.st_uid != geteuid())
++throw runtime_error("XDG_RUNTIME_DIR is not owned by current user");
++
+ make_directory(session_directory(), 0711);
+ }
+ 
diff -Nru kakoune-2020.01.16/debian/patches/14-upstream-rework-dir-logic.patch 
kakoune-2020.01.16/debian/patches/14-upstream-rework-dir-logic.patch
--- kakoune-2020.01.16/debian/patches/14-upstream-rework-dir-logic.patch
1970-01-01 02:00:00.0 +0200
+++ kakoune-2020.01.16/debian/patches/14-upstream-rework-dir-logic.patch
2021-07-05 22:15:28.0 +0300
@@ -0,0 +1,77 @@
+Description: Rework session directory logic
+ Do not use a shared kakoune/ directory for all users to avoid the
+ complexity of having to set the sticky bit on that dir, resolve the
+ session directory only once by using a static variable and an
+ immediately evaluated lambda.
+ .
+ This fixes an annoyance whenever using `su` and having Kakoune refuse
+ to start due to XDG_RUNTIME_DIR still being set.
+Origin: upstream; 
https://github.com/mawww/kakoune/commit/db9ef82398a08bdf985ff26bfb230fb0cd1221a5
+Author: Maxime Coste 
+Bug-Debian: https://bugs.debian.org/990635
+Last-Update: 2021-07-05
+
+--- a/src/remote.cc
 b/src/remote.cc
+@@ -537,28 +537,20 @@
+ return getenv("USER");
+ }
+ 
+-String session_directory()
++const String& session_directory()
+ {
+-StringView xdg_runtime_dir = getenv("XDG_RUNTIME_DIR");
+-if (xdg_runtime_dir.empty())
+-return format("{}/kakoune/{}", tmpdir(), get_user_name());
+-else
+-return format("{}/kakoune", xdg_runtime_dir);
+-}
+-
+-void make_session_directory()
+-{
+-StringView xdg_runtime_dir = getenv("XDG_RUNTIME_DIR");
+-if (xdg_runtime_dir.empty())
+-{
+-// set sticky bit on the shared kakoune directory
+-make_directory(format("{}/kakoune", tmpdir()), 01777);
+-}
+-else if (struct stat st;
+- stat(xdg_runtime_dir.zstr(), &st) == 0 && st.st_uid != g

Bug#990412: pam: Regression - it won't search /lib/security

[Hideki Yamane]

control: tags -1 +patch +pending

Hi,

 I've found the root cause of this bug, and fixed it.
 On my local sid machine, I've tested it with edit /etc/pam.d/su
 as search pam_yubico.so, exec su and it searchs /lib/security/pam_yubico.so :)

 See below debdiff. If it seems to be okay, I'll put it into sid
 and request unblock.

diff -Nru pam-1.4.0/debian/changelog pam-1.4.0/debian/changelog
--- pam-1.4.0/debian/changelog  2021-03-16 04:01:55.0 +0900
+++ pam-1.4.0/debian/changelog  2021-07-06 22:09:15.0 +0900
@@ -1,3 +1,13 @@
+pam (1.4.0-7.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/patches-applied/lib_security_multiarch_compat
+- Fix regression that was introduced in 1.4.0-1, some lines were not
+  applied during refresh patch and it doesn't work.
+  (Closes: #979973, #990412)
+
+ -- Hideki Yamane   Tue, 06 Jul 2021 22:09:15 +0900
+
 pam (1.4.0-7) unstable; urgency=medium
 
   * Updated portuguese debconf translation, thanks Pedro Ribeiro, Closes:
diff -Nru pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat 
pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat
--- pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat  
2021-01-31 07:09:52.0 +0900
+++ pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat  
2021-07-06 22:09:15.0 +0900
@@ -11,11 +11,11 @@
 order to get everything installed where we want it and get absolute paths
 the way we want them.
 
-Index: pam/libpam/pam_handlers.c
+Index: pam-1.4.0/libpam/pam_handlers.c
 ===
 pam.orig/libpam/pam_handlers.c
-+++ pam/libpam/pam_handlers.c
-@@ -735,7 +735,18 @@
+--- pam-1.4.0.orig/libpam/pam_handlers.c
 pam-1.4.0/libpam/pam_handlers.c
+@@ -735,7 +735,27 @@ _pam_load_module(pam_handle_t *pamh, con
success = PAM_ABORT;
  
D(("_pam_load_module: _pam_dlopen(%s)", mod_path));
@@ -31,11 +31,20 @@
 +  } else {
 +  pam_syslog(pamh, LOG_CRIT, "cannot malloc full mod path");
 +  }
++   if (!mod->dl_handle) {
++   if (asprintf(&mod_full_path, "%s/%s",
++_PAM_ISA, mod_path) >= 0) {
++   mod->dl_handle = _pam_dlopen(mod_full_path);
++   _pam_drop(mod_full_path);
++   } else {
++   pam_syslog(pamh, LOG_CRIT, "cannot malloc full mod path");
++   }
++  }
 +  }
D(("_pam_load_module: _pam_dlopen'ed"));
D(("_pam_load_module: dlopen'ed"));
if (mod->dl_handle == NULL) {
-@@ -812,7 +823,6 @@
+@@ -812,7 +832,6 @@ int _pam_add_handler(pam_handle_t *pamh
  struct handler **handler_p2;
  struct handlers *the_handlers;
  const char *sym, *sym2;
@@ -43,7 +52,7 @@
  servicefn func, func2;
  int mod_type = PAM_MT_FAULTY_MOD;
  
-@@ -824,16 +834,7 @@
+@@ -824,16 +843,7 @@ int _pam_add_handler(pam_handle_t *pamh
  
  if ((handler_type == PAM_HT_MODULE || handler_type == 
PAM_HT_SILENT_MODULE) &&
mod_path != NULL) {

Bug#927076: xournalpp packaging in Debian

[Martin Quinson]

> Okay, I used a git snapshot for the version and tarball, and all seems well.

Excellent! that's a very good news. 

It's impressive to see all tests to pass from the first attempt. lintian finds 
a small issue in the debian/copyright file, but that's all that I see.
https://salsa.debian.org/debian/xournalpp/-/jobs/1742060#L32

Thanks, Mt

Bug#990762: undocumented option to apt-get

[Andrei POPESCU]

Control: reassign -1 apt

On Ma, 06 iul 21, 13:09:48, Ian Smith wrote:
> Package: apt-get
> Version: all
> 
> -u option is listed at the top of the man page but not documented there
> 
> I assume it is now default behaviour
> 
> Cheers,
> 
> Ian Smith

Reassigning to correct package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1

[Moritz Mühlenhoff]

Am Wed, Jun 30, 2021 at 08:33:01PM +0200 schrieb Tomas Pospisek:
> reassign 990411 linux-image-5.10.0-7-amd64
> 
> -
> 
> Thanks Michael, reassigning as proposed. Though I'm wondering (and not
> finding) whether there would be a more general package to assign this ticket
> to (such as linux-image-5.x or something).
> 
> Any thoughts on this problem in the security or the kernel team?

I agree it makes sense to disable it by default, but the ultimate
decision is up to the kernel team

Cheers,
Moritz

Bug#927076: xournalpp packaging in Debian

[Barak A. Pearlmutter]

Okay, I used a git snapshot for the version and tarball, and all seems well.

Bug#990765: sshfs: please add Breaks: fuse (<< 2)

[Andreas Beckmann]

Package: sshfs
Version: 3.7.1+repack-1
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

Upgrading sshfs from buster to bullseye requires to replace fuse
with fuse3 in order to install sshfs.
Since there is no clean upgrade path for fuse -> fuse3 (#918984, will
not be fixed for bullseye but only for bookworm), we need to add some
Breaks/Depends elsewhere to make this switch happen without requiring
manual interaction.

One such location is in sshfs itself, others are freedombox and
kdeconnect. Usually two breaks (in distinct packages) are needed to push
apt's scores from 'preferring to keep fuse installed' to 'switching to
fuse3'.

Please see the attached patch.


Andreas
diff -Nru sshfs-fuse-3.7.1+repack/debian/changelog 
sshfs-fuse-3.7.1+repack/debian/changelog
--- sshfs-fuse-3.7.1+repack/debian/changelog2020-11-24 13:40:01.0 
+0100
+++ sshfs-fuse-3.7.1+repack/debian/changelog2021-07-05 14:48:37.0 
+0200
@@ -1,3 +1,10 @@
+sshfs-fuse (3.7.1+repack-2) UNRELEASED; urgency=medium
+
+  * fuse3: Add Breaks: fuse (<< 3) to help switching from fuse to fuse3 on
+upgrades from buster.  (Closes: #-1)
+
+ -- Andreas Beckmann   Mon, 05 Jul 2021 14:48:37 +0200
+
 sshfs-fuse (3.7.1+repack-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru sshfs-fuse-3.7.1+repack/debian/control 
sshfs-fuse-3.7.1+repack/debian/control
--- sshfs-fuse-3.7.1+repack/debian/control  2020-11-24 13:40:01.0 
+0100
+++ sshfs-fuse-3.7.1+repack/debian/control  2021-07-05 14:48:37.0 
+0200
@@ -24,6 +24,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}
 ,fuse3 [linux-any] | fuse4bsd [kfreebsd-any]
 ,openssh-client
+Breaks: fuse (<< 3)
 Description: filesystem client based on SSH File Transfer Protocol
  sshfs is a filesystem client based on the SSH File Transfer Protocol.
  Since most SSH servers already support this protocol it is very easy

Bug#990515: release.debian.org: buster->bullseye upgrade issue: sshfs is not upgraded due to fuse/fuse3

[Andreas Beckmann]

On 01/07/2021 12.04, Andreas Beckmann wrote:
I'm just trying the attached patch which seems to solve the issue for 
the kde metapackages with --install-recommends
kdeconnect is the one depending on sshfs, so it's a good candidate to 
ensure we get fuse3 installed.


I've filed bugs against sshfs, kdeconnect and freedombox to add
  Breaks: fuse (<< 3)
  Depends: fuse3 (>= 3)
which seems to be sufficient to solve all the cases where sshfs was not 
being upgraded.



Andreas

Bug#990764: kdeconnect: please add Breaks: fuse (<< 3) and Depends: fuse3 (>= 3)

[Andreas Beckmann]

Package: kdeconnect
Version: 20.12.3-1
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

Upgrading e.g. kde-full (with --instaill-recommends enabled) from
buster to bullseye requires to replace fuse with fuse3 in order to
install sshfs.
Since there is no clean upgrade path for fuse -> fuse3 (#918984, will
not be fixed for bullseye but only for bookworm), we need to add some
Breaks/Depends elsewhere to make this switch happen without requiring
manual interaction.

Here is an excerpt of the diff of the apt problem resolution from
an upgrade of kde-full (with --install-recommends enabled) from buster
to
  a) current bullseye (which does not upgrade sshfs at all) and
  b) a bullseye with kdeconnect and sshfs patched to carry more Depends/Breaks.
The apt scores change from 'preferring to keep fuse installed' to
'switching to fuse3'.

...
-  Calculating upgrade...Starting pkgProblemResolver with broken count: 50
+  Calculating upgrade...Starting pkgProblemResolver with broken count: 52
...
-  Investigating (0) fuse3:amd64 < none -> 3.10.3-2 @un uN Ib >
-  Broken fuse3:amd64 Breaks on fuse:amd64 < 2.9.9-1+deb10u1 -> 2.9.9-5 @ii umU 
>
-Considering fuse:amd64 4 as a solution to fuse3:amd64 3
-Holding Back fuse3:amd64 rather than change fuse:amd64
-  Investigating (0) sshfs:amd64 < 2.10+repack-2 -> 3.7.1+repack-1 @ii umU Ib >
-  Broken sshfs:amd64 Depends on fuse3:amd64 < none | 3.10.3-2 @un uH >
-Considering fuse3:amd64 3 as a solution to sshfs:amd64 2
-Holding Back sshfs:amd64 rather than change fuse3:amd64
+  Investigating (0) fuse3:amd64 < none -> 3.10.3-2 @un uN Ib >
+  Broken fuse3:amd64 Breaks on fuse:amd64 < 2.9.9-1+deb10u1 -> 2.9.9-5 @ii umU 
>
+Considering fuse:amd64 2 as a solution to fuse3:amd64 5
+Added fuse:amd64 to the remove list
+Conflicts//Breaks against version 2.9.9-1+deb10u1 for fuse but that is not 
InstVer, ignoring
+Fixing fuse3:amd64 via remove of fuse:amd64
...
-   Try to Re-Instate (1) sshfs:amd64
   The following packages will be REMOVED:
-g++-8 gcc-8 kaccessible katepart kde-runtime kde-style-breeze-qt4
+fuse g++-8 gcc-8 kaccessible katepart kde-runtime kde-style-breeze-qt4
...
  The following packages have been kept back:
-sshfs
...
-  1681 upgraded, 302 newly installed, 131 to remove and 1 not upgraded.
+  1681 upgraded, 304 newly installed, 132 to remove and 0 not upgraded.
...

Please see the attached patch.


Andreas
diff -Nru kdeconnect-20.12.3/debian/changelog 
kdeconnect-20.12.3/debian/changelog
--- kdeconnect-20.12.3/debian/changelog 2021-03-08 22:43:49.0 +0100
+++ kdeconnect-20.12.3/debian/changelog 2021-07-01 11:21:47.0 +0200
@@ -1,3 +1,10 @@
+kdeconnect (20.12.3-2) UNRELEASED; urgency=medium
+
+  * kdeconnect: Add Breaks: fuse (<< 3) and Depends: fuse3 (>= 3) to ensure
+fuse gets replaced by fuse3 on upgrades from buster.  (Closes: #-1)
+
+ -- Andreas Beckmann   Thu, 01 Jul 2021 11:21:47 +0200
+
 kdeconnect (20.12.3-1) unstable; urgency=medium
 
   * New upstream release (20.12.3).
diff -Nru kdeconnect-20.12.3/debian/control kdeconnect-20.12.3/debian/control
--- kdeconnect-20.12.3/debian/control   2021-03-08 22:31:44.0 +0100
+++ kdeconnect-20.12.3/debian/control   2021-07-01 11:21:47.0 +0200
@@ -55,9 +55,12 @@
  qml-module-qtquick-particles2,
  qml-module-qtquick-window2,
  qml-module-qtquick2,
- sshfs,
+ sshfs (>= 3),
  ${misc:Depends},
  ${shlibs:Depends},
+# Ensure fuse gets replaced by fuse3 on upgrades from buster s.t. sshfs can be 
installed.
+ fuse3 (>= 3),
+Breaks: fuse (<< 3)
 Description: connect smartphones to your desktop devices
  Tool to integrate your smartphone, tablet, and desktop devices.
  Remote-control, share files, synchronize notifications, and more!

Bug#990763: mariadb-server-core-10.3: MariaDB 10.3.29 is crashing and restarting continuously

[supp...@etes.de]

Package: mariadb-server-core-10.3
Version: 1:10.3.29-0+deb10u1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 Upgrading mariadb-server-core-10.3 from 1:10.3.27-0+deb10u1 to 
1:10.3.29-0+deb10u1 (we see this on two servers)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Reconfigure mariadb to listen on localhost only, no more querys from the 
webserver were received
 mariadb stops crashing
 Checking all tables, no errors have been found
 Running sql-statement from mariadb error log in mariadb console does not 
led to an crash
 reconfigure to listen on network, mariadb is crashing again
 downgrade to 10.3.27-0+deb10u1, mariadb is running stable
   * What was the outcome of this action?
 see obove
   * What outcome did you expect instead?
 we exptected that mariadb would not crash after updating to 
10.3.29-0+deb10u1
   * error.log from mariadb
 
210702  0:02:26 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

Server version: 10.3.29-MariaDB-0+deb10u1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=12
max_threads=153
thread_count=13
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 352741 K  
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7fb1d8007678
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7fb230990dd8 thread_stack 0x3
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55c06f39631e]
/usr/sbin/mysqld(handle_fatal_signal+0x54d)[0x55c06eec157d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7fb234a9a730]
/usr/sbin/mysqld(_Z15optimize_keyuseP4JOINP16st_dynamic_array+0x160)[0x55c06ed17530]
/usr/sbin/mysqld(+0x61c373)[0x55c06ed36373]
/usr/sbin/mysqld(_ZN4JOIN14optimize_innerEv+0xa03)[0x55c06ed3ec73]
/usr/sbin/mysqld(_ZN4JOIN8optimizeEv+0x52)[0x55c06ed3eff2]
/usr/sbin/mysqld(_ZN13st_select_lex31optimize_unflattened_subqueriesEb+0x12d)[0x55c06eccf6dd]
/usr/sbin/mysqld(_ZN4JOIN15optimize_stage2Ev+0x1136)[0x55c06ed3cec6]
/usr/sbin/mysqld(_ZN4JOIN14optimize_innerEv+0xae6)[0x55c06ed3ed56]
/usr/sbin/mysqld(_ZN4JOIN8optimizeEv+0x52)[0x55c06ed3eff2]
/usr/sbin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x7a3)[0x55c06ed40da3]
/usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x14d)[0x55c06ed40ffd]
/usr/sbin/mysqld(+0x5c74ac)[0x55c06ece14ac]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x519f)[0x55c06eceda4f]
/usr/sbin/mysqld(_ZN18Prepared_statement7executeEP6Stringb+0x41e)[0x55c06ed028be]
/usr/sbin/mysqld(_ZN18Prepared_statement12execute_loopEP6StringbPhS2_+0x97)[0x55c06ed02aa7]
/usr/sbin/mysqld(+0x5e99b5)[0x55c06ed039b5]
/usr/sbin/mysqld(_Z19mysqld_stmt_executeP3THDPcj+0x2b)[0x55c06ed03aab]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x14ab)[0x55c06ecf243b]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x122)[0x55c06ecf3842]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x23a)[0x55c06edc617a]
/usr/sbin/mysqld(handle_one_connection+0x3d)[0x55c06edc62fd]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3)[0x7fb234a8ffa3]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fb2349c04cf]



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

Kernel: Linux 4.19.0-17-amd64 (SMP w/2 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 mariadb-server-core-10.3 depends on:
ii  libaio1 0.3.112-3
ii  libc6   2.28-10
ii  libgnutls30 3.6.7-4+deb10u7
ii  liblz4-11.8.3-1+deb10u1
ii  libpcre32:8.39-12
ii  libsnappy1v51.1.7-1
ii  libstdc++6  8.3.0-6
ii  libsystemd0 241-7~deb10u7
ii  mariadb-common  1:10.3.29-0+deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

mariadb-server-core-10.3 recommends no packages.

mariadb-server-core-10.3 suggests no packages.

-- no debconf information

Bug#990761: evolution crash (segfault) on startup without error msg

[Marcus Werner]

Package: evolution
Version: 3.38.3-1
Severity: normal
X-Debbugs-Cc: bugrep...@holozone.de

(amdgpu-pro installed from amd.com, but everything else runs fine)

Starting program: /usr/bin/evolution
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeb3ac700 (LWP 11754)]
[New Thread 0x7fffeabab700 (LWP 11755)]
[New Thread 0x7fffea373700 (LWP 11756)]
[New Thread 0x7fffe9b61700 (LWP 11757)]

Thread 1 "evolution" received signal SIGSEGV, Segmentation fault.
0x72532903 in XAddExtension () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0  0x72532903 in XAddExtension () at /lib/x86_64-linux-gnu/libX11.so.6
#1  0x7fffd1d5f517 in  () at /usr/lib/x86_64-linux-gnu/dri/amdgpu_dri.so
#2  0x7fffd1d63fd9 in eglInitialize () at /usr/lib/x86_64-linux-
gnu/dri/amdgpu_dri.so
#3  0x7fffef4a7d85 in  () at /lib/x86_64-linux-gnu/libcogl.so.20
#4  0x7fffef4a3f15 in  () at /lib/x86_64-linux-gnu/libcogl.so.20
#5  0x7fffef4597d7 in cogl_renderer_connect () at /lib/x86_64-linux-
gnu/libcogl.so.20
#6  0x7fffef554f82 in  () at /lib/x86_64-linux-gnu/libclutter-1.0.so.0
#7  0x7fffef56e7c3 in  () at /lib/x86_64-linux-gnu/libclutter-1.0.so.0
#8  0x7fffef57f58a in  () at /lib/x86_64-linux-gnu/libclutter-1.0.so.0
#9  0x73ae4a46 in  () at /lib/x86_64-linux-gnu/libclutter-gtk-1.0.so.0
#10 0x77210278 in g_option_context_parse () at /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#11 0x73ae4bc1 in gtk_clutter_init_with_args () at /lib/x86_64-linux-
gnu/libclutter-gtk-1.0.so.0
#12 0x8994 in main ()


-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-7-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evolution depends on:
ii  dbus   1.12.20-2
ii  evolution-common   3.38.3-1
ii  evolution-data-server  3.38.3-1
ii  libc6  2.31-12
ii  libcamel-1.2-623.38.3-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.38.3-1
ii  libedataserver-1.2-25  3.38.3-1
ii  libevolution   3.38.3-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4
ii  libical3   3.0.9-2
ii  libnotify4 0.7.9-3
ii  libsoup2.4-1   2.72.0-2
ii  libwebkit2gtk-4.0-37   2.32.1-2
ii  libxml22.9.10+dfsg-6.7
ii  psmisc 23.4-2

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.38.3-1
ii  evolution-plugin-pstimport   3.38.3-1
ii  evolution-plugins3.38.3-1
ii  yelp 3.38.3-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.27-2
ii  network-manager 1.30.0-2

Bug#990580: caused by #979813

[Adam Borowski]

I'm also get spammed 1/day/server.

On Tue, Jul 06, 2021 at 06:54:24AM +0200, Cron Daemon wrote:
> /etc/cron.daily/logrotate:
> Reloading Apache httpd web server: apache2.

The cause is #979813 whose "fix" included:

-   postrotate
-if invoke-rc.d apache2 status > /dev/null 2>&1; then \
-invoke-rc.d apache2 reload > /dev/null 2>&1; \
-fi;
+postrotate
+   if pgrep -f ^/usr/sbin/apache2 > /dev/null; then
+   invoke-rc.d apache2 reload
+   fi

which dropped redirection in the reload line.

Changing querying status to pgrep is also bogus: it will detect any apache2
process rather than just ours.  But this is not the issue at hand.

To stop the mails from logrotate, could you please change back:
-   invoke-rc.d apache2 reload
+   invoke-rc.d apache2 reload > /dev/null 2>&1

otherwise, people running Bullseye will be mightily unhappy.

I also wonder why such a cleanup was done late during hard freeze.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

Bug#868861: Mitigation

[Michiel Hazelhof]

Made two small tweaks to hopefully mitigate this behaviour:

ln -s /usr/sbin/apache2 /usr/sbin/apache2-instancename

edit /usr/sbin/apache2ctl:

change:

SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
case "$SUFFIX" in
    /etc/apache2)
    SUFFIX=""
    ;;
    *)
    SUFFIX="@$SUFFIX"
    ;;
esac

to:

EXTRA=""
SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
case "$SUFFIX" in
    /etc/apache2)
    SUFFIX=""
    ;;
    *)
    EXTRA="-$SUFFIX"
    SUFFIX="@$SUFFIX"
    ;;
esac


change:

HTTPD=${APACHE_HTTPD:-/usr/sbin/apache2}

to:

HTTPD=${APACHE_HTTPD:-/usr/sbin/apache2$EXTRA}


This at least gets it running with a different "name", lets hope this
resolves the "There are processes named 'apache2' running which do not
match your pid file which are left untouched in the name of safety," issue.

With regards,

Michiel Hazelhof.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990760: Provide asn1_compiler in linux-kbuild-*

[Mathieu Malaterre]

Source: linux
Version: 4.19.194-1

It would be super nice to ship asn1_compiler in linux-kbuild-*, this
would simplify build steps for modules such as ksmbd. Right now only
Fedora & RHEL are supported in the stand-alone module install step:

* https://github.com/cifsd-team/ksmbd#installing-as-a-stand-alone-module

On Debian, one can only use the in-kernel compilation:

https://github.com/cifsd-team/ksmbd#installing-as-a-part-of-the-kernel

Thanks

Bug#990759: FW: [Linuxptp-devel] linuxptp: Fixes published for CVE-2021-3570 and CVE-2021-3571

[Geva, Erez]

Package: linuxptp
Version: 3.1-2

CVE-2021-3570
CVE-2021-3571

-Original Message-
From: Richard Cochran  
Sent: Tuesday, 6 July 2021 00:30
To: oss-secur...@lists.openwall.com
Cc: linuxptp-us...@lists.sourceforge.net; linuxptp-de...@lists.sourceforge.net
Subject: [Linuxptp-devel] linuxptp: Fixes published for CVE-2021-3570 and 
CVE-2021-3571

Dear list,

Now that the embargo period has expired, I published fixes for:

   CVE-2021-3570 linuxptp: missing length check of forwarded messages
   CVE-2021-3571 linuxptp: wrong length of one-step follow-up in transparent 
clock

The fixes have been published to SourceForge and to GitHub:
https://sourceforge.net/projects/linuxptp/
https://github.com/richardcochran/linuxptp

The tags with the fixes are as follows:

   v1.5.1
   v1.6.1
   v1.7.1
   v1.8.1
   v1.9.3
   v2.0.1
   v3.1.1

In addition, the head of the master branch (soon to be version 3.2) also 
includes the fixes.

Although it is possible to apply the fix to versions 1.2, 1.3, and 1.4, those 
versions are obsolete and do not pass our CI tests.  For this reason I decided 
to withdraw them instead.

Thanks,
Richard


___
Linuxptp-devel mailing list
linuxptp-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Bug#990756: rsyslog: Please send user errors only to user.log and rotate that file based on size.

[Michael Biebl]

Am 06.07.21 um 12:08 schrieb Michael Biebl:

Am 06.07.21 um 11:51 schrieb Ben Wong:



Ideally, I'd like to see some sort of rate-limiter added to rsyslog.


There is a rater limiter in imuxsock.
https://www.rsyslog.com/how-to-use-rate-limiting-in-rsyslog/

The problem is: a couple of GB of log data is something that a busy log 
server can generate in a couple of minutes which perfectly valid.


On a laptop, a couple of GB of log data is probably unusual.

The problem is to pick a default which suits everyone, which is guess is 
not possible.


https://www.rsyslog.com/doc/v8-stable/configuration/modules/imuxsock.html#syssock-ratelimit-interval

Apparently this feature caused problems, so it was turned off again.


SysSock.RateLimit.Interval
typedefault max mandatory   obsolete legacy directive
integer 0   no  $SystemLogRateLimitInterval

Specifies the rate-limiting interval in seconds. Default value is 0, which 
turns off rate limiting. Set it to a number of seconds (5 recommended) to 
activate rate-limiting. The default of 0 has been chosen as people experienced 
problems with this feature activated by default. Now it needs an explicit 
opt-in by setting this parameter.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#990758: freedombox: please add Breaks: fuse (<< 3) and Depends: fuse3 (>= 3)

[Andreas Beckmann]

Package: freedombox
Version: 21.4.2
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

Upgrading freedombox from buster to bullseye requires to replace fuse
with fuse3 in order to install sshfs.
Since there is no clean upgrade path for fuse -> fuse3 (#918984, will
not be fixed for bullseye but only for bookworm), we need to add some
Breaks/Depends elsewhere to make this switch happen without requiring
manual interaction.

Here is an excerpt of the diff of the apt problem resolution from
an upgrade of buster to
  a) current bullseye (which does not upgrade freedombox at all) and
  b) a bullseye with freedombox and sshfs patched to carry more Depends/Breaks.
The apt scores change from 'preferring to keep fuse installed' to 'switching to 
fuse3'.

...
-  Starting 2 pkgProblemResolver with broken count: 12
+  Starting 2 pkgProblemResolver with broken count: 14
...
-  Investigating (0) fuse3:amd64 < none -> 3.10.3-2 @un uN Ib >
-  Broken fuse3:amd64 Breaks on fuse:amd64 < 2.9.9-1+deb10u1 -> 2.9.9-5 @ii umU 
>
-Considering fuse:amd64 4 as a solution to fuse3:amd64 2
-Holding Back fuse3:amd64 rather than change fuse:amd64
-  Investigating (0) sshfs:amd64 < none -> 3.7.1+repack-1 @un uN Ib >
-  Broken sshfs:amd64 Depends on fuse3:amd64 < none | 3.10.3-2 @un uH >
-Considering fuse3:amd64 2 as a solution to sshfs:amd64 0
-Holding Back sshfs:amd64 rather than change fuse3:amd64
-  Investigating (0) freedombox:amd64 < 19.1+deb10u2 -> 21.4.2 @ii umU Ib >
-  Broken freedombox:amd64 Depends on sshfs:amd64 < none | 3.7.1+repack-1 @un 
uH >
-Considering sshfs:amd64 0 as a solution to freedombox:amd64 0
-Holding Back freedombox:amd64 rather than change sshfs:amd64
+  Investigating (0) fuse3:amd64 < none -> 3.10.3-2 @un uN Ib >
+  Broken fuse3:amd64 Breaks on fuse:amd64 < 2.9.9-1+deb10u1 -> 2.9.9-5 @ii umU 
>
+Considering fuse:amd64 2 as a solution to fuse3:amd64 3
+Added fuse:amd64 to the remove list
+Conflicts//Breaks against version 2.9.9-1+deb10u1 for fuse but that is not 
InstVer, ignoring
+Fixing fuse3:amd64 via remove of fuse:amd64
...
-   Try to Re-Instate (1) freedombox:amd64
   Done
...
   The following packages will be REMOVED:
-g++-8 gcc-8 libgc1c2 libgcc-8-dev libpolkit-backend-1-0 libpython-stdlib
-libstdc++-8-dev php7.3-cli php7.3-common php7.3-fpm php7.3-json
-php7.3-opcache php7.3-readline python python-django-common python-minimal
-python-pyicu python3.7
+fuse g++-8 gcc-8 libgc1c2 libgcc-8-dev libpolkit-backend-1-0
+libpython-stdlib libstdc++-8-dev php7.3-cli php7.3-common php7.3-fpm
+php7.3-json php7.3-opcache php7.3-readline python python-django-common
+python-minimal python-pyicu python3.7
...
-  The following packages have been kept back:
-freedombox
...
-  532 upgraded, 119 newly installed, 18 to remove and 1 not upgraded.
+  532 upgraded, 186 newly installed, 19 to remove and 0 not upgraded.

Please see the attached patch.


Andreas
diff -Nru freedombox-21.4.2/debian/changelog 
freedombox-21.4.2+nmu1~deb11anbe3/debian/changelog
--- freedombox-21.4.2/debian/changelog  2021-03-28 15:23:46.0 +0200
+++ freedombox-21.4.2+nmu1~deb11anbe3/debian/changelog  2021-07-01 
12:43:04.0 +0200
@@ -1,3 +1,10 @@
+freedombox (21.4.3) UNRELEASED; urgency=medium
+
+  * freedombox: Add Breaks: fuse (<< 3) and Depends: fuse3 (>= 3) to ensure
+fuse gets replaced by fuse3 on upgrades from buster.  (Closes: #-1)
+
+ -- Andreas Beckmann   Thu, 01 Jul 2021 12:43:04 +0200
+
 freedombox (21.4.2) unstable; urgency=high
 
   [ Burak Yavuz ]
diff -Nru freedombox-21.4.2/debian/control 
freedombox-21.4.2+nmu1~deb11anbe3/debian/control
--- freedombox-21.4.2/debian/control2021-03-28 15:23:46.0 +0200
+++ freedombox-21.4.2+nmu1~deb11anbe3/debian/control2021-07-01 
12:43:04.0 +0200
@@ -58,6 +58,8 @@
 Breaks:
  freedombox-setup (<< 0.13~),
  plinth (<< 0.46.0~),
+# Ensure fuse gets replaced by fuse3 on upgrades from buster s.t. sshfs can be 
installed.
+ fuse (<< 3),
 Replaces:
  freedombox-setup (<< 0.13~),
  plinth (<< 0.46.0~),
@@ -116,6 +118,8 @@
  python3-yaml,
  sudo,
  wget,
+# Ensure fuse gets replaced by fuse3 on upgrades from buster s.t. sshfs can be 
installed.
+ fuse3 (>= 3),
 Recommends:
 # Priority: standard
  bzip2,

Bug#990756: rsyslog: Please send user errors only to user.log and rotate that file based on size.

[Michael Biebl]

Am 06.07.21 um 11:51 schrieb Ben Wong:


2. /etc/logrotate.d/rsyslog: add "maxsize" so that log files that are
greater than a certain size are rotated even if their time
criteria are not due. I suggest "maxsize 1G" is reasonable for
most people and can be adjusted for those who want more.

3a. Move /etc/cron.daily/logrotate to /etc/cron.hourly/ so that file
 sizes are checked more often. (This also fixes the "bug" where an
 hourly entry in logrotate.conf only gets rotated daily.)


This is basically a duplicate of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954069


Keep in mind that /etc/cron.daily/logrotate is not under the control of 
the rsyslog package.


I'm inclined to merge your bug report accordingly.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990756: rsyslog: Please send user errors only to user.log and rotate that file based on size.

[Michael Biebl]

Am 06.07.21 um 11:51 schrieb Ben Wong:

Package: rsyslog
Version: 8.2102.0-2
Severity: important

Dear Maintainer,

My Debian box's hard disk filled up due to a single buggy user
application spewing messages at syslog. While I blame the application,
Debian's rsyslog should be more robust by default.

This is something I've seen happening more and more frequently.
A typical response people get when googling the problem is
"sudo rm /var/log/* and then set that up to run daily as a cronjob."
That's terrible advice and makes Debian seem shoddy.

Ideally, I'd like to see some sort of rate-limiter added to rsyslog.


There is a rater limiter in imuxsock.
https://www.rsyslog.com/how-to-use-rate-limiting-in-rsyslog/

The problem is: a couple of GB of log data is something that a busy log 
server can generate in a couple of minutes which perfectly valid.


On a laptop, a couple of GB of log data is probably unusual.

The problem is to pick a default which suits everyone, which is guess is 
not possible.






In the meantime, here is a simple three step fix which would improve
stability for many people using Debian.


1. /etc/rsyslog.conf: add user.none to /var/log/syslog, debug, and messages.
That way, the spewage is limited to a single file, user.log.


I'm not really sure we can win this game.
Next time, it's not a user application generating a lot of data but some 
system service.


That said, there is certainly value in cleaning up the default Debian 
rsyslog default config, see e.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508376
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580552
to avoid duplication in log messages.



2. /etc/logrotate.d/rsyslog: add "maxsize" so that log files that are
greater than a certain size are rotated even if their time
criteria are not due. I suggest "maxsize 1G" is reasonable for
most people and can be adjusted for those who want more.


Depends. I'd argue that the systemd journal nowadays is better suited 
for end user systems anyway and syslog/rsyslog more targetted at the 
enterprise area. So I don't think it makes sense to optimize for the former.



3a. Move /etc/cron.daily/logrotate to /etc/cron.hourly/ so that file
 sizes are checked more often. (This also fixes the "bug" where an
 hourly entry in logrotate.conf only gets rotated daily.)

3b. /usr/lib/systemd/system/logrotate.timer: Likewise for systemd.

 [Timer][Timer]
 OnCalendar=daily   -->  OnCalendar=hourly
 AccuracySec=1h AccuracySec=1m
 Persistent=truePersistent=true


Steps 1 and 2 ensure that the disk will not fill up and that important
system messages won't be rotated away too quickly based on file size.

Step 3 is necessary because the time in which a log file can fill up
/var is no longer measured in days. Currently, I have a single
chromium process sending over thirty thousand messages per second and
I doubt that's even close to the maximum possible.


I don't think, changing the cron job to hourly is really going to help 
if you have an application running amok. 1 hour is more then sufficient 
to fill up your disk.



Fwiw, my plan is for bookworm to have rsyslog removed from a default 
installation and rely on journald only (which does size-based log 
truncation), as I think journald is a better fit for end-user systems.


rsyslog would then only be installed by those who explicitly need it 
(those users will most likely will tweak its settings anyway to suit 
their needs).


Regards,
Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#868273: The newer files indeed need cleanup

[Christian Ehrhardt]

Now I'm having a look at the two new suspects that you reported.

/etc/vmware-tools/vm-support
/etc/vmware-tools/guestproxy-ssl.conf

I agree they exist, but they are not orphaned.

You can still remove them (you need purge since they are config files)
as dpkg remembers that they belong to that package.

After clarifying that those were not added by the package itself I tracked
down my assumption that upstreams install has placed and added them.
That is true for a few of them.

/etc/vmware-tools/guestproxy-ssl.conf
Was indeed dropped by 11.0.0 via [1]
This was meant to go away, so I agree we should remove it now.

And /etc/vmware-tools/vm-support
was dropped by 11.1.0 via [2]
This has a new place in /bin - I guess if we try to use mv_conffile or similar
for that we make it worse - since this is long gone already we should
just rm_conffile it.

For those two I'll add an rm_conffile in the 11.3.0 branch that I'm
preparing for Bernd.

I'll consider the bug done by that, but please let me know if there are
really any relevant package upgrade paths anywhere which contain the two
initially reported files.

[1]: 
https://github.com/vmware/open-vm-tools/commit/49eb56393323c9344d10313d104bf20630813578
[2]: 
https://github.com/vmware/open-vm-tools/commit/00d44381a374d60245f286a3faaf3be678a8

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#868273: File /etc/xdg/autostart/vmware-user.desktop still matters

[Christian Ehrhardt]

Hi,

this seems still owned:

# dpkg -S /etc/xdg/autostart/vmware-user.desktop
open-vm-tools-desktop: /etc/xdg/autostart/vmware-user.desktop

So that one IMHO isn't obsole.
And AFAICS it is that way for a long time already.

A very long ago it was part of another package.

The timeline is
2007.09.04-56574-1:
  install -D -m 0644 debian/config/vmware-user.desktop
debian/open-vm-tools/usr/share/autostart/vmware-user.desktop
2008.06.03-96374-2
  Then made it part of open-vm-toolbox
2:9.2.3-1031360-2
  Moved it to open-vm-tools-desktop
debian/2%9.4.0-1280544-7
  Moved it to open-vm-tools-desktop in a new style and under /etc/xdg
path that we have today

Since even oldoldstable is at 2:9.4.6-1770165-8 I don't see any
reasonable upgrade path with anything left from that.
And as explained above the path "/etc/xdg/autostart/vmware-user.desktop" still
is in use.

And some remains of that that needed cleanup were resolved long ago in
bug 639811.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#868273: File /etc/modprobe.d/open-vm-tools.conf seems to have never existed in the package

[Christian Ehrhardt]

You'd think that the file "/etc/modprobe.d/open-vm-tools.conf" really is gone.

Timeline:
This is from debian/2%8.8.0+2012.05.21-724730-2
It moved from package open-vm-tools-dkms to open-vm-tools in
debian/2%9.4.6-1770165-3
It was dropped in debian/2%10.0.0-3000743-1

Even oldstable already has 2:10.1.5-5055683-4+deb9u2 so this also is
quite long ago.

But in more detail, all that was about file
  /lib/modules-load.d/open-vm-tools.conf

Being in /lib made it a non-conffile so it was removed correctly.

The file you reported seems to never have existed in the packaging.

I looked further and found that upstream once had such files created and added
in their scripts and that way it might have slipped in.
But all of that still was part of the dkms/module handling that is long gone.

There were a bunch of other /etc/modprobe.d/vm* files, also all long gone.

The only mention in upstream code for this is on their error-collection
in `vm-support` - but not as a file deployed.

I'm tempted to assume that "/etc/modprobe.d/open-vm-tools.conf" was from maybe
a howto or a guid on the internet - or from a non-archive build of the tool?

Again - I tried, but my analysis might be wrong.
Do you happen to know exactly where this is from - maybe a package version
that still contained this?


-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#990757: imagemagick-6-common: Typo in policy.xml causes next policy line to be ignored

[Graham Cobb]

Package: imagemagick-6-common
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal

Dear Maintainer,

While adjusting /etc/ImageMagick-6/policy.xml after upgrading to
8:6.9.11.60+dfsg-1.3 I noticed that the line:



has been changed to...

" has been lost from the end of
the line. It was present in the version I had previously installed.

Presumably this is an accidental mistake. It causes the following lines to
be ignored until the closing of the next commented line. In the distributed
version the next line is commented, so there is no actual impact but it
could cause problems if people do not notice.



-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
compare:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
convert:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
composite:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
conjure:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
display:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
identify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
import:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
mogrify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
montage:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
stream:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- debconf-show failed

Bug#990756: rsyslog: Please send user errors only to user.log and rotate that file based on size.

[Ben Wong]

Package: rsyslog
Version: 8.2102.0-2
Severity: important

Dear Maintainer,

My Debian box's hard disk filled up due to a single buggy user
application spewing messages at syslog. While I blame the application,
Debian's rsyslog should be more robust by default.

This is something I've seen happening more and more frequently. 
A typical response people get when googling the problem is
"sudo rm /var/log/* and then set that up to run daily as a cronjob." 
That's terrible advice and makes Debian seem shoddy.

Ideally, I'd like to see some sort of rate-limiter added to rsyslog.

In the meantime, here is a simple three step fix which would improve
stability for many people using Debian.


1. /etc/rsyslog.conf: add user.none to /var/log/syslog, debug, and messages.
   That way, the spewage is limited to a single file, user.log.
   
2. /etc/logrotate.d/rsyslog: add "maxsize" so that log files that are
   greater than a certain size are rotated even if their time
   criteria are not due. I suggest "maxsize 1G" is reasonable for
   most people and can be adjusted for those who want more.

3a. Move /etc/cron.daily/logrotate to /etc/cron.hourly/ so that file
sizes are checked more often. (This also fixes the "bug" where an
hourly entry in logrotate.conf only gets rotated daily.)

3b. /usr/lib/systemd/system/logrotate.timer: Likewise for systemd.

[Timer] [Timer]
OnCalendar=daily--> OnCalendar=hourly
AccuracySec=1h  AccuracySec=1m
Persistent=true Persistent=true


Steps 1 and 2 ensure that the disk will not fill up and that important
system messages won't be rotated away too quickly based on file size.

Step 3 is necessary because the time in which a log file can fill up
/var is no longer measured in days. Currently, I have a single
chromium process sending over thirty thousand messages per second and
I doubt that's even close to the maximum possible.

Thank you.


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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.60
ii  libc62.31-12
ii  libestr0 0.1.10-2.1+b1
ii  libfastjson4 0.99.9-1
ii  liblognorm5  2.0.5-1.1
ii  libsystemd0  247.3-5
ii  libuuid1 2.36.1-7
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages rsyslog recommends:
ii  logrotate  3.18.0-2

Versions of packages rsyslog suggests:
pn  rsyslog-doc   
pn  rsyslog-gssapi
pn  rsyslog-mongodb   
pn  rsyslog-mysql | rsyslog-pgsql 
pn  rsyslog-openssl | rsyslog-gnutls  
pn  rsyslog-relp  

-- Configuration Files:
/etc/logrotate.d/rsyslog changed:
# Standard rsyslog log files. For syntax, see logrotate.conf(8)  -*- conf -*- 
/var/log/syslog
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/user.log
/var/log/kern.log
/var/log/auth.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 4
weekly
maxsize 1G
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}

/etc/rsyslog.conf changed:
# /etc/rsyslog.conf configuration file for rsyslog
#
# For more information install rsyslog-doc and see
# /usr/share/doc/rsyslog-doc/html/configuration/index.html


#
 MODULES 
#

module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
#module(load="immark")  # provides --MARK-- message capability

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")


###
 GLOBAL DIRECTIVES 
###

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set the default permissions for all log files.
#
$FileOwne

Bug#989220: solvespace: crashes when starting on Debian stable.

[Zuluaga, Juan P]

Thank you Bernhard,

according to your instructions, here I present:

juan@widgy:~$ gdb solvespace
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 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 "i686-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 solvespace...Reading symbols from 
/usr/lib/debug/.build-id/08/b34dccc7ada9d003ba80595f1a686a34256288.debug...done.
done.
(gdb) run
Starting program: /usr/bin/solvespace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xaf702b40 (LWP 12876)]
malloc(): invalid size (unsorted)

Thread 1 "solvespace" received signal SIGABRT, Aborted.
0xb7fd4d61 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fd4d61 in __kernel_vsyscall ()
#1  0xb6c23382 in __libc_signal_restore_set (set=0xbfffda5c) at 
../sysdeps/unix/sysv/linux/internal-signals.h:84
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb6c0d2b6 in __GI_abort () at abort.c:79
#4  0xb6c64d2c in __libc_message (action=do_abort, fmt=) at 
../sysdeps/posix/libc_fatal.c:181
#5  0xb6c6baed in malloc_printerr (str=str@entry=0xb6d775e8 "malloc(): invalid 
size (unsorted)") at malloc.c:5341
#6  0xb6c6e80b in _int_malloc (av=av@entry=0xb6dce7a0 , 
bytes=bytes@entry=236) at malloc.c:3732
#7  0xb6c70c34 in __libc_calloc (n=1, elem_size=236) at malloc.c:3428
#8  0xb312b867 in nv50_rasterizer_state_create (pipe=0xb59fa0, cso=0xc82780) at 
../src/gallium/drivers/nouveau/nv50/nv50_state.c:230
#9  0xb2ec0ea9 in cso_set_rasterizer (ctx=0xb8b3e0, templ=0xb76964) at 
../src/gallium/auxiliary/cso_cache/cso_context.c:604
#10 0xb3445465 in st_update_rasterizer (st=) at 
../src/mesa/state_tracker/st_atom_rasterizer.c:317
#11 0xb3442e0f in st_validate_state (st=0xb768c0, pipeline=ST_PIPELINE_RENDER) 
at ../src/util/bitscan.h:103
#12 0xb339fea7 in prepare_draw (ctx=0xb5b460, st=0xb768c0) at 
../src/mesa/state_tracker/st_draw.c:123
#13 st_draw_vbo (ctx=0xb5b460, prims=0xb7800c, nr_prims=1, ib=0x0, 
index_bounds_valid=1 '\001', min_index=, max_index=,
tfb_vertcount=0x0, stream=0, indirect=0x0) at 
../src/mesa/state_tracker/st_draw.c:149
#14 0xb329843e in vbo_exec_vtx_flush (exec=, keepUnmapped=1 
'\001') at ../src/mesa/vbo/vbo_exec_draw.c:393
#15 0xb3297e57 in vbo_exec_FlushVertices_internal (unmap=1 '\001', 
exec=) at ../src/mesa/vbo/vbo_exec_api.c:1255
#16 vbo_exec_FlushVertices (ctx=0xb5b460, flags=1) at 
../src/mesa/vbo/vbo_exec_api.c:1255
#17 0xb334477f in line_width (no_error=false, width=, 
ctx=0xb5b460) at ../src/mesa/main/lines.c:70
#18 _mesa_LineWidth (width=) at ../src/mesa/main/lines.c:95
#19 0x004df59f in SolveSpace::ssglLineWidth (width=) at 
./src/glhelper.cpp:97
#20 0x004b2dc1 in SolveSpace::Entity::Draw (this=0xbdbe90, drawAsHidden=false) 
at ./src/drawentity.cpp:117
#21 0x004b2ece in SolveSpace::Entity::DrawAll (drawAsHidden=false) at 
./src/drawentity.cpp:103
#22 0x0049d4d5 in SolveSpace::GraphicsWindow::Paint (this=) at 
./src/draw.cpp:724
#23 0x0048470e in SolveSpace::GraphicsWidget::on_gl_draw (this=0xb57f00) at 
./src/gtk/gtkmain.cpp:524
#24 0x00486f4f in SolveSpace::GlWidget::on_draw (cr=..., this=0xb57f00) at 
./src/gtk/gtkmain.cpp:334
#25 SolveSpace::GlWidget::on_expose_event (this=) at 
./src/gtk/gtkmain.cpp:350
#26 0xb7c8f579 in Gtk::Widget_Class::expose_event_callback(_GtkWidget*, 
_GdkEventExpose*) () from /lib/i386-linux-gnu/libgtkmm-2.4.so.1
--Type  for more, q to quit, c to continue without paging--c
#27 0xb76396e7 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#28 0xb7273138 in g_closure_invoke () from 
/lib/i386-linux-gnu/libgobject-2.0.so.0
#29 0xb72863fd in ?? () from /lib/i386-linux-gnu/libgobject-2.0.so.0
#30 0xb728f9a1 in g_signal_emit_valist () from 
/lib/i386-linux-gnu/libgobject-2.0.so.0
#31 0xb7290465 in g_signal_emit () from /lib/i386-linux-gnu/libgobject-2.0.so.0
#32 0xb775b4d4 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#33 0xb7637b71 in gtk_main_do_event () from 
/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#34 0xb74400ca in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#35 0xb7440077 in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#36 0xb7470f0c in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#37 0xb743c6d4 in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#38 0xb743d052 in gdk_window_process_all_updates () from 
/lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#39 0xb75b8cc3 in ?? () from /

Bug#990718: RFS: duma/2.5.21-1 [ITA] -- Detect Unintended Memory Access (D.U.M.A)

[Peter]

2nd attempt

1) Fix Vcs fields.
2) Leave 984041 open in BTS as requested.



Dear mentors,

I am looking for a sponsor for my package "duma":

 * Package name    : duma
   Version : 2.5.21-1
   Upstream Author : j...@gridfinity.com
 * URL : https://github.com/johnsonjh/duma
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/duma
   Section : devel

It builds those binary packages:

  duma - Detect Unintended Memory Access (D.U.M.A)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/d/duma/duma_2.5.21-1.dsc

Changes since the last upload:

 duma (2.5.21-1) unstable; urgency=medium
 .
   * Adopt package. (Closes: #565925)
   * New Upstream Release. (Closes: #550660, #623495, #655892)
   * Use "-U_FORTIFY_SOURCE" in rules file. (Closes: #532483)
   * Fixes FTBFS with GCC-11  (#984041)
   * Reproducible build. (use changelog file date instead of system date)
   * Enable bindnow.
   * Add autopkgtests
   * DEP-5 copyright

Regards,
--
  Peter Blackman

Bug#990754: unblock: wpewebkit/2.32.1-1

[Alberto Garcia]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package wpewebkit

webkit2gtk was unblocked last month, testing has the most recent
stable version and we will provide security updates during the
lifetime of bullseye, as we already did during buster.

wpewebkit is another official port of webkit. It's maintained by the
same team, follows a very similar release schedule and numbering
system, shares most of the code and almost all CVEs fixes apply to
both ports.

Because of this it won't take me too much effort to prepare security
updates for wpewebkit so the Debian security team is proposing that we
also provide them.

If we do this we should unblock the package and put the latest stable
version in testing. At the moment the only user of wpewebkit in Debian
is cog, which is a simple, single-window web browser, developed and
released by the same team. So we should also unblock cog and the two
other libraries that are part of the wpewebkit releases: libwpe and
wpebackend-fdo (I don't know if you need separate bugs to unblock
those).

If we don't do this then it's probably a good idea to mention in the
release notes that wpewebkit is not covered by security updates.

unblock wpewebkit/2.32.1-1

Bug#990753: libvkd3d-dev: Depends: libvkd3d-headers (= ${binary:Version}) breaks multilib

[Sveinar Søpler]

Package: libvkd3d-dev
Version: 1.2-4 (Debian experimental)
Source: vkd3d

In the 1.2-4 version of libvkd3d-dev package, the control field indicates
Depends: libvkd3d-headers (= ${binary:Version})

This causes libvkd3d-dev:i386 to depend on libvkd3d-headers:i386, but 
libvkd3d-headers is built with Architecture: all and thus cannot satisfy
dependency. (There is no libvkd3d-headers:i386 on amd64 systems)

Tested suggestion:
Build libvkd3d-dev with Depends: libvkd3d-headers (= ${source:Version})
and build libvkd3d-headers with: Multi-Arch: allowed

Next issue then is that libvkd3d-dev generate html docs in the package,
and this causes libvkd3d-dev:amd64 and libvkd3d-dev:i386 to have conflict
when installing docs. (Trying to overwrite)

Tested suggestion:
Build html docs with the libvkd3d-headers package since it is built as
Architecture: all.

Symlink libvkd3d-dev.docs -> docs
and change
libvkd3d-headers.docs:

README
AUTHORS
ANNOUNCE

doc/html
doc/vkd3d.pdf

I know this is not the most logical solution, since you would expect a -dev
package to contain docs, but building wine requires multilib version of
libvkd3d-dev, and i do not know another way of doing this since the html
docs are being generated when the package is being built (and thus probably
not binary the same?).

Best Regards
Sveinar Søpler

Bug#990745: [Pkg-zfsonlinux-devel] Bug#990745: better nvme device detection in cron scripts

[Petter Reinholdtsen]

[M. Zhou]
> get_transp(){

Any chance you can explain how it is better?  It would make it easier to
review the code.  Providing the change as a diff against the baseline
would help too.

--
Happy hacking
Petter Reinholdtsen

Bug#990734: sbuild: option --build-dir is ignored in source directory

[Jochen Sprickerhof]

Control: tags -1 patch

* Jochen Sprickerhof  [2021-07-05 22:53]:

Sadly the change breaks autopkgtests:

$ cd hello*/
$ sbuild --build-dir=/tmp/ --run-autopkgtest
[..]
Unexpected error:
Traceback (most recent call last):
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 739, in mainloop
   command()
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 668, in command
   r = f(c, ce)
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 602, in cmd_copydown
   copyupdown(c, ce, False)
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 490, in copyupdown
   copyupdown_internal(ce[0], c[1:], upp)
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 517, in 
copyupdown_internal
   copydown_shareddir(sd[0], sd[1], dirsp, downtmp_host)
 File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 472, in 
copydown_shareddir
   shutil.copy(host, host_tmp)
 File "/usr/lib/python3.9/shutil.py", line 418, in copy
   copyfile(src, dst, follow_symlinks=follow_symlinks)
 File "/usr/lib/python3.9/shutil.py", line 264, in copyfile
   with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/hello_2.10.orig.tar.gz'


Actually this also happens when using the .dsc so it is an unrelated 
bug. I have opened a merge request here:


https://salsa.debian.org/debian/sbuild/-/merge_requests/13

Tagging this as patch accordingly.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#990752: Local configuration adds 2 dots on hostname, blocking package upgrades

[Utkarsh Gupta]

Source: postfix
Version: 3.5.6-1
Severity: important

Hello,

This bug was originally reported in Ubuntu here[1]. The reporter had a
valid hostname, "saturn", but due to another bug (also reported in
Ubuntu here[2]), the hostname is changed to "saturn.." (that is, 2
dots are added) and this causes the hostname to be invalid, thereby
blocking package upgrades, et al.

I was wondering if this is known or can we do something about this,
please? Thank you!

[1]: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1934381
[2]: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1929786


- u

Bug#990751: ITP: libreadonly-tiny-perl -- Perl module to provide simple, correct readonly values

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libreadonly-tiny-perl
  Version : 4
  Upstream Author : Ben Morrow 
* URL : https://metacpan.org/release/Readonly-Tiny
* License : BSD-2-Clause
  Programming Lang: Perl
  Description : Perl module to provide simple, correct readonly values

Readonly::Tiny provides a simple and correct way of making values readonly.
Unlike Readonly it does not cause arrays and hashes to be tied, it just uses
the core SvREADONLY flag.

Readonly::Tiny  will be used by lintian
(https://lists.debian.org/debian-perl/2021/07/msg0.html)

Bug#990750: ITP: libtest-exports-perl -- Perl module to test that modules export the right symbols

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libtest-exports-perl
  Version : 1
  Upstream Author : Ben Morrow 
* URL : https://metacpan.org/release/Test-Exports
* License : BSD-2-Clause
  Programming Lang: Perl
  Description : Perl module to test that modules export the right symbols

Test::Exports provides simple test functions for testing other modules
"import" methods. Testing is currently limited to checking which subs have been
imported.

In order to keep different calls to ->import separate, Test::Exports performs
these calls from a private package. The symbol-testing functions then test
whether or not symbols are present in this private package, ensuring none of
this interferes with your test script itself.

Test::Exports is a build dependency of Readonly::Tiny which will be used
by lintian (https://lists.debian.org/debian-perl/2021/07/msg0.html)

Bug#990749: linuxptp: CVE-2021-3571

[Salvatore Bonaccorso]

Source: linuxptp
Version: 3.1-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for linuxptp.

CVE-2021-3571[0]:
| linuxptp: wrong length of one-step follow-up in transparent clock

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3571
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3571

Please adjust the affected versions in the BTS as needed.

Note, as for CVE-2021-3570 I set the severity here as well to RC
thinking the fix needs to go into bullseye before the release. Let me
know if I can help with a NMU.

Regards,
Salvatore

Bug#990748: linuxptp: CVE-2021-3570

[Salvatore Bonaccorso]

Source: linuxptp
Version: 3.1-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.9.2-1

Hi,

The following vulnerability was published for linuxptp.

CVE-2021-3570[0]:
| linuxptp: missing length check of forwarded messages

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3570
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3570

Please adjust the affected versions in the BTS as needed.

Note, I did set the severity here straight to RC as I think the fix
should go in bullseye. I can try to help with a NMU if needed.

Regards,
Salvatore