Bug#971868: Should be removed now?

[Shengjing Zhu]

Control: severity -1 normal

Bug#971868: Should be removed now?

[Shengjing Zhu]

Control: retitle -1 RM: golang-1.14 -- RoQA; superseded by golang-1.15
Control: reassign -1 ftp.debian.org

The last package which B-D on golang-1.14 is migrated to golang-1.15
https://tracker.debian.org/news/1185176/accepted-kubernetes-1193-1-source-into-unstable/

So we can remove golang-1.14 now.

On Fri, Oct 9, 2020 at 3:21 AM Shengjing Zhu  wrote:
>
> Package: golang-1.14
> Severity: serious
> X-Debbugs-Cc: z...@debian.org
>
> So, we have updated golang-defaults to 1.15.
>
> Like buster, bullseye seems to be having only one version of Go compiler.
>
> Let's see if anyone wants 1.14 for bullseye.
> Or later we can convert this to RM bug for ftp.d.o.

-- 
Shengjing Zhu

Bug#972661: pkgreport.cgi: user parameter lost when switching from Unarchived to Archived bugs

[Paul Wise]

Package: bugs.debian.org
Severity: normal

When I load this page:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org=warnings

Then select "Archived" or "Archived and Unarchived" and submit the
format the bottom, I get these pages:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=1;tag=warnings
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;tag=warnings

As you can see, the URLs don't include my user and they are empty.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#972660: trans-de-en: "iBuchen" should be "Buchenbäume {pl}; Buchen" as with upstream

[Axel Beckert]

Package: trans-de-en
Version: 1.8.1-9
Severity: normal

Hi,

"translate fagus" gives me, beyond others, the following result:

iBuchen {pl} (Fagus) (botanische Gattung) [bot.]  | aus Buchenholz :: 
beeches (botanical genus)  | beechen

The first letter "i" seems to be superfluous.

The following command confirms that this is not an output mangling issue
of "translate" but actually an issue in the database file:

$ fgrep iBuchen /usr/share/trans/de-en
iBuchen {pl} (Fagus) (botanische Gattung) [bot.]  | aus Buchenholz :: 
beeches (botanical genus)  | beechen

I also checked the online dictionary of upstream, but couldn't find the
issue there:

https://dict.tu-chemnitz.de/dings.cgi?service=deen=0=0=fagus=

Compared to the data set shown upstream, that seemingly superfluous "i"
should actually be replaced with "Buchenbäume {pl}; ".

Additionally the string "aus Buchenholz" seems to be at some different
position upstream than in the database entry shown above. Might be part
of the difference, too, but looks misplaced upstream compared to the
database entry above.

So in the end this "iBuchen" string might be:

* fixed upstream and an outdated upstream version being in Debian
  Unstable;

* something that broke the file while building the Debian binary
  package; or

* something that broke upstream while generating different provided
  formats.

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

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

trans-de-en depends on no packages.

trans-de-en recommends no packages.

Versions of packages trans-de-en suggests:
ii  ding  1.8.1-9

-- no debconf information

Bug#972525: buildd: sbuild randomly fails to sign changes file despite valid signature keys

[NIIBE Yutaka]

Hello,

IIUC, it is likely a bug of GnuPG.

When a server with higher load, it takes time for a process of gpg-agent
to start listen(2)ing the connection than the value of
SECS_TO_WAIT_FOR_AGENT.  It's five seconds, hard-coded.

Last year, I pushed a change to remove possible race condition around
the initial connect to gpg-agent.

I don't know if this patch fixes the particular problem of sbuild, but,
it should improve the situation, hopefully, much.

-- 

commit b1c56cf9e2bb51abfd47747128bd2a6285ed1623
Author: NIIBE Yutaka 
Date:   Wed Jul 24 15:15:32 2019 +0900

common: Use gnupg_spawn_process_fd to invoke gpg-agent/dirmngr.

* common/asshelp.c (start_new_gpg_agent): Call gnupg_spawn_process_fd
and gnupg_wait_process.
(start_new_dirmngr): Likewise.

--

With --daemon option, gpg-agent/dirmngr detaches by itself.

Signed-off-by: NIIBE Yutaka 

diff --git a/common/asshelp.c b/common/asshelp.c
index 5209ea6cf..600774330 100644
--- a/common/asshelp.c
+++ b/common/asshelp.c
@@ -492,8 +492,13 @@ start_new_gpg_agent (assuan_context_t *r_ctx,
   if (!(err = lock_spawning (, gnupg_homedir (), "agent", verbose))
   && assuan_socket_connect (ctx, sockname, 0, 0))
 {
-  err = gnupg_spawn_process_detached (program? program : agent_program,
-  argv, NULL);
+  pid_t pid;
+
+  err = gnupg_spawn_process_fd (program? program : agent_program,
+argv, -1, -1, -1, );
+  if (!err)
+err = gnupg_wait_process (program? program : agent_program,
+  pid, 1, NULL);
   if (err)
 log_error ("failed to start agent '%s': %s\n",
agent_program, gpg_strerror (err));
@@ -627,7 +632,12 @@ start_new_dirmngr (assuan_context_t *r_ctx,
   if (!(err = lock_spawning (, gnupg_homedir (), "dirmngr", verbose))
   && assuan_socket_connect (ctx, sockname, 0, 0))
 {
-  err = gnupg_spawn_process_detached (dirmngr_program, argv, NULL);
+  pid_t pid;
+
+  err = gnupg_spawn_process_fd (dirmngr_program, argv,
+-1, -1, -1, );
+  if (!err)
+err = gnupg_wait_process (dirmngr_program, pid, 1, NULL);
   if (err)
 log_error ("failed to start the dirmngr '%s': %s\n",
dirmngr_program, gpg_strerror (err));

Bug#892058: debian-keyring: please automatically send reminder emails to people whose keys will expire soon

[Felix Lechner]

Hi Gunnar,

> I will add this, but not to this script

Here is the script I used for today's reminders. It is attached just
for the record. I am still working on automating the uid selection,
the sending of messages, and also calculating the subkey expirations.

Kind regards
Felix Lechner


upcoming-expirations.xz
Description: application/xz

Bug#972659: nmu: tpm2-abrmd

[Ying-Chun Liu (PaulLiu)]

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

Hello,

libtpm2-tss bump the soname of its lib. Make the package
tpm2-abrmd needs to build against the latest libtpm2-tss.
Please see #972118

  nmu tpm2-abrmd:2.3.3-1 . ANY . -m 'Rebuild against the new
libtpm2-tss, see #972118.'

Thanks.|

Yours,
Paul

Bug#972118: tpm2-abrmd: Daemon fails to start: needs to be rebuilt against newer libtss2-esys0

[Ying-Chun Liu (PaulLiu)]

Hi Jan,



Yes, just as you described. I think we need a binNMU here.


Thanks,
Paul





signature.asc
Description: OpenPGP digital signature

Bug#972494: libgrokj2k: please make the documentation reproducible

[Aaron Boxer]

Hi Chris,
Thank you very much! I've fixed this in my current master, and it will go
into my next release.
Unless, you think this should be patched in the current version in unstable.
Cheers,
Aaron

On Mon, Oct 19, 2020 at 6:33 AM Chris Lamb  wrote:

> Source: libgrokj2k
> Version: 7.6.0-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the Reproducible Builds effort [0] we noticed that
> libgrokj2k's documentation could not be built reproducibly.
>
> This is because the doxygen-generated HTML pages reference the
> absolute build path due to use of an incorrect STRIP_FROM_PATH
> directive in the Doxyfile configuration file.
>
> Patch attached.
>
>  [0] https://reproducible-builds.org/
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#971515: kubernetes: excessive vendoring (private libraries)

[Dmitry Smirnov]

On Thursday, 22 October 2020 2:16:16 AM AEDT Sean Whitton wrote:
> I think that we can all agree with everything you've written about the
> reasons why packaging components separately is better. 

Thank you.


> The problem is
> that in this case the choice seems to be between not having recent
> Kubernetes in Debian at all, or giving up on some of those advantages.

Ultimately it is about maintainers comfort then. Because there is a 
compromise to un-vendor most libraries (one by one) and keep some/few 
strategically vendored, when a system library can not be used (determined 
case by case).

Examples of this approach are numerous: syncthing, consul, nomad, vault, 
docker.io, runc, gitlab-runner, libpod, buildah, singularity-container
and _most_ Golang packages.

Kubernetes had no maintainer - that was the problem. Having maintainer who
does not care for shared libraries because he does not want to be bothered
is a different problem.

-- 
Kind regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

In times of universal deceit, telling the truth becomes a revolucionary
act.
-- George Orwell


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

Bug#963059: x11-common: false linebreak in 20x11-common_process-args function has_option

[Josh Triplett]

Sure.

I don't think having a separate reimplementation of Xsession is a good
idea (rather than reusing it), for exactly this kind of reason; this
would break with any future enhancements to Xsession as well. But for
compatibility, until that version of Xsession defines `has_option`
appropriately as well, we *could* move the various helper functions and
variables from Xsession to something like /usr/share/X11/Xsession-common,
have it detect if it's already been sourced so that it only initializes
once, and then source that from the various scripts as well as from
/etc/X11/Xsession itself. That'll fix this issue.

- Josh Triplett

On Thu, Oct 15, 2020 at 05:00:53PM +0300, Timo Aaltonen wrote:
> Josh, please have a look at this, is it possible to fix without reverting
> support for Xsession.d?
> 
> On 15.10.2020 15.51, Andrey Kiselev wrote:
> > Package: x11-common
> > Followup-For: Bug #963059
> > 
> > Dear Maintainer,
> > 
> > The fix coming with the 1:7.7+21 now breaks users resource loading in the
> > gdm3 session. gdm3 has its own Xsession script which was not updated to
> > reflect the changes introduced in latest x11-common. It looks like this in
> > logs:
> > 
> > Oct 15 12:13:29 rose /usr/libexec/gdm-x-session[2516]: /etc/gdm3/Xsession: 
> > Beginning session setup...
> > Oct 15 12:13:29 rose /usr/libexec/gdm-x-session[2516]: /etc/gdm3/Xsession: 
> > 16: /etc/X11/Xsession.d/30x11-common_xresources: has_option: not found
> > 
> > There is a possibility that some other session managers can be the same way
> > affected.
> > 
> > I think that the quick fix is to move has_option() function back into the
> > "20x11-common_process-args" file.
> > 
> > Best regards,
> > Andrey
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> >APT prefers testing
> >APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), LANGUAGE not 
> > set
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages x11-common depends on:
> > ii  lsb-base  11.1.0
> > 
> > x11-common recommends no packages.
> > 
> > x11-common suggests no packages.
> > 
> > -- no debconf information
> > 
> 
> 
> -- 
> t

Bug#971515: kubernetes: excessive vendoring (private libraries)

[Dmitry Smirnov]

On Wednesday, 21 October 2020 8:56:53 PM AEDT Felix Lechner wrote:
> How is the second one inferior, please? I think it includes a crucial
> missing feature (co-installable versions).

To reduce maintainers burden, you want maintainers to look after not one but 
multiple versions of libraries. This is a contradiction (oxymoron).
How many releases (current + obsolete ones) one can meaningfully support?

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

The cure for the evils of democracy is more democracy.
-- H. L. Mencken


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

Bug#972658: hovercraft: autopkgtest regression: test failed

[Boyuan Yang]

Source: hovercraft
Version: 2.7-1
Severity: serious
X-Debbugs-CC: mo...@debian.org

Hi Sandro,

Your new upload of hovercraft 2.7-1 has autopkgtest regressions. The testsuite
provided by upstream is failing:

= test session starts
==
platform linux -- Python 3.8.6, pytest-4.6.11, py-1.9.0, pluggy-0.13.0 --
/usr/bin/python3.8
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.4jxc1vbb/downtmp/build.Hjn/src
collecting ... collected 35 items

tests/test_generator.py::GeneratorTests::test_big
FAILED [  2%]

=== FAILURES
===
___ GeneratorTests.test_big


self = 

def test_big(self):
template = Template(os.path.join(TEST_DATA, "maximal"))
html, deps = rst2html(os.path.join(TEST_DATA, "advanced.rst"),
template)
>   self.assertEqual(html, HTML_OUTPUTS["advanced"])
E   AssertionError: b'NoneNone
signature.asc
Description: This is a digitally signed message part

Bug#972657: partitionmanager: FTBFS on hppa - off_t type size

[John David Anglin]

Package: partitionmanager
Version: 4.2.0-1
Severity: normal

Dear Maintainer,

Configuration fails with following error:

/usr/bin/c++ -D_GNU_SOURCE -D_LARGEFILE64_SOURCE  -g -O2 
-fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -D_OFFT_IS_64BIT -o 
CMakeFiles/cmTC_09a8c.dir/src.cxx.o -c 
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeTmp/src.cxx
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:7:33: warning: 
left shift count >= width of type [-Wshift-count-overflow]
7 | #define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
  |   ~~^
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:8:23: note: in 
expansion of macro ‘LARGE_OFF_T’
8 |   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  |   ^~~
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:7:57: warning: 
left shift count >= width of type [-Wshift-count-overflow]
7 | #define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
  |   ~~^
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:8:23: note: in 
expansion of macro ‘LARGE_OFF_T’
8 |   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];
  |   ^~~
/<>/obj-hppa-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:8:89: error: 
size ‘-1’ of array ‘off_t_is_large’ is negative
8 |   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 
2147483647 == 1) ? 1 : -1];

By default, off_t is a signed long in glibc.  This is 32 bits on 32-bit hppa.
I believe one needs to define _FILE_OFFSET_BITS=64 to ensure a 64-bit typedef
for off_t.

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.202+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages partitionmanager depends on:
pn  kio   
ii  libc6 2.31-3
ii  libgcc-s4 10.2.0-15
ii  libkf5auth5   5.74.0-2
ii  libkf5authcore5   5.74.0-2
ii  libkf5codecs5 5.74.0-2
pn  libkf5completion5 
ii  libkf5configcore5 5.74.0-2
ii  libkf5configgui5  5.74.0-2
ii  libkf5configwidgets5  5.74.0-2
ii  libkf5coreaddons5 5.74.0-2
ii  libkf5crash5  5.74.0-2
ii  libkf5dbusaddons5 5.74.0-2
ii  libkf5i18n5   5.74.0-2
ii  libkf5iconthemes5 5.74.0-2
pn  libkf5jobwidgets5 
pn  libkf5kiocore5
pn  libkf5kiowidgets5 
ii  libkf5service-bin 5.74.0-2
ii  libkf5service55.74.0-2
ii  libkf5widgetsaddons5  5.74.0-3
ii  libkf5xmlgui5 5.74.0-2
pn  libkpmcore9   
ii  libqt5concurrent5 5.14.2+dfsg-6
ii  libqt5core5a  5.14.2+dfsg-6
ii  libqt5dbus5   5.14.2+dfsg-6
ii  libqt5gui55.14.2+dfsg-6
ii  libqt5network55.14.2+dfsg-6
ii  libqt5widgets55.14.2+dfsg-6
ii  libqt5xml55.14.2+dfsg-6
ii  libstdc++610.2.0-15

partitionmanager recommends no packages.

Versions of packages partitionmanager suggests:
pn  btrfs-progs
ii  dosfstools 4.1-2
pn  hfsplus
pn  hfsutils   
pn  jfsutils   
ii  ntfs-3g1:2017.3.23AR.3-3
pn  reiser4progs   
pn  reiserfsprogs  
ii  xfsprogs   5.6.0-1+b1

Bug#961798: python-pyaudio: FTBFS for doc package

[Petter Reinholdtsen]

I've uploaded the following patch to the 7 day delayed upload queue, to
fix this RC issue.
-- 
Happy hacking
Petter Reinholdtsen
diff --git a/debian/changelog b/debian/changelog
index 1b533f5..8e8b392 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+python-pyaudio (0.2.11-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix doc build problem. (Closes: #961798)
+  * Updated debhelper version from 9 to 12.
+  * Override dh_clean to remove generated egg-info files.
+
+ -- Petter Reinholdtsen   Wed, 21 Oct 2020 22:01:14 +
+
 python-pyaudio (0.2.11-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/compat b/debian/compat
index ec63514..48082f7 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-9
+12
diff --git a/debian/control b/debian/control
index d55a243..f7f49bf 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: python-pyaudio
 Section: python
 Priority: optional
 Standards-Version: 3.9.8
-Build-Depends: python3-all-dev, debhelper(>= 9), portaudio19-dev, python3-sphinx, dh-linktree, dh-python, libjs-jquery, libjs-underscore
+Build-Depends: python3-all-dev, debhelper(>= 12), portaudio19-dev, python3-sphinx, dh-linktree, dh-python, node-jquery, libjs-underscore
 Maintainer: Hubert Pham 
 Uploaders: Felipe Sateler , Justin Mazzola Paluska 
 Homepage: https://people.csail.mit.edu/hubert/pyaudio/
diff --git a/debian/python-pyaudio-doc.linktrees b/debian/python-pyaudio-doc.linktrees
index 9edc677..0c97614 100644
--- a/debian/python-pyaudio-doc.linktrees
+++ b/debian/python-pyaudio-doc.linktrees
@@ -1,3 +1,3 @@
-replace usr/share/javascript/jquery usr/share/doc/python-pyaudio-doc/docs/_static
+replace usr/share/nodejs/jquery/dist usr/share/doc/python-pyaudio-doc/docs/_static
 replace usr/share/javascript/underscore usr/share/doc/python-pyaudio-doc/docs/_static
 
diff --git a/debian/rules b/debian/rules
index ad236f5..3d8e351 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,10 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 %:
 	dh $@ --with python3,linktree --buildsystem=pybuild
 
+override_dh_clean:
+	dh_clean
+	$(RM) -rf src/PyAudio.egg-info
+
 override_dh_auto_build:
 	dh_auto_build
 	PYTHONPATH=$(PYTHONPATH) make docs

Bug#972371: debian-reference: Add CI to ensure that git is buildable

[Holger Wansing]

Hi,

xiao sheng wen (肖盛文)  wrote:
> Good news!
> 
> The newest git commit run  Pipeline #187465   sucess!*

Tagging this bug as pending.


Holger



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

Bug#971367: [debian-mysql] Bug#971367: Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl

[Otto Kekäläinen]

Great news!

My faith in humanity and the victory of sanity has been restored.

I've now pushed on mariadb-10.5 master the necessary changes in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/ca2574aa88434d1c49456c677b7dcb904902daaf

I will keep this issue open, and start excluding extras/wolfssl in the
gbp.conf next time I import a new upstream (instead of the d/rules
hack done now).

Bug#972282: libllvm10: libllvm has different version, i386 is newer, then amd64, due to synaptic.

[Mark Janes]

The impact of this bug on end-users is high.

You cannot currently install both i386 and amd64 versions of Mesa.

As a result, Valve's Steam store cannot run on Debian Testing.


On Thu, 15 Oct 2020 22:02:51 +0200 =?utf-8?q?Stefan=5FSchr=C3=B6der?= 
 wrote:


> Package: libllvm10
> Version: 1:10.0.1-6
> Severity: minor
> X-Debbugs-Cc: stefan_schroe...@kabelmail.de
>
> Dear Maintainer,
>
> *** 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: bullseye/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libllvm10 depends on:
> ii libc6 2.31-3
> ii libedit2 3.1-20191231-1
> ii libffi7 3.3-4
> ii libgcc-s1 10.2.0-13
> ii libstdc++6 10.2.0-13
> ii libtinfo6 6.2+20200918-1
> ii libz3-4 4.8.9-1
> ii zlib1g 1:1.2.11.dfsg-2
>
> libllvm10 recommends no packages.
>
> libllvm10 suggests no packages.
>
> -- no debconf information
>
>

Bug#972172: Removed package(s) from unstable

[Markus Koschany]

Hi,

Am 21.10.20 um 19:44 schrieb Sean Whitton:
[...]
>> I only requested that the obsolete binary packages got removed from
>> unstable because libnb-absolutelayout-java, the only remaining binary
>> package, did not migrate to testing. It appears you just removed the
>> complete source package src:netbeans. How can we fix this?
> 
> Ooops.  We can fast track it through NEW.

Thanks. I have uploaded the same source package to NEW again.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#972656: hypercorn FTBFS: test failures

[Adrian Bunk]

Source: hypercorn
Version: 0.11.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=hypercorn=all=0.11.1-1=1602683894=0

...
=== FAILURES ===
_ test_protocol_send_response __

protocol = 

@pytest.mark.asyncio
async def test_protocol_send_response(protocol: H11Protocol) -> None:
await protocol.stream_send(Response(stream_id=1, status_code=201, 
headers=[]))
protocol.send.assert_called()
>   assert protocol.send.call_args_list == [
call(
RawData(
data=(
b"HTTP/1.1 201 \r\ndate: Thu, 01 Jan 1970 01:23:20 
GMT\r\n"
b"server: hypercorn-h11\r\nConnection: close\r\n\r\n"
)
)
)
]
E   AssertionError: assert [call(RawData...ddress=None))] == 
[call(RawData(...ddress=None))]
E At index 0 diff: call(RawData(data=b'HTTP/1.1 201 \r\ndate: Thu, 01 
Jan 1970 01:23:20 GMT\r\nserver: hypercorn-h11\r\nconnection: close\r\n\r\n', 
address=None)) != call(RawData(data=b'HTTP/1.1 201 \r\ndate: Thu, 01 Jan 1970 
01:23:20 GMT\r\nserver: hypercorn-h11\r\nConnection: close\r\n\r\n', 
address=None))
E Use -v to get the full diff

protocol   = 

tests/protocol/test_h11.py:42: AssertionError
___ test_protocol_send_body 

protocol = 

@pytest.mark.asyncio
async def test_protocol_send_body(protocol: H11Protocol) -> None:
await protocol.handle(
RawData(data=b"GET / HTTP/1.1\r\nHost: hypercorn\r\nConnection: 
close\r\n\r\n")
)
await protocol.stream_send(
Response(stream_id=1, status_code=200, headers=[(b"content-length", 
b"5")])
)
await protocol.stream_send(Body(stream_id=1, data=b"hello"))
protocol.send.assert_called()
>   assert protocol.send.call_args_list == [
call(
RawData(
data=b"HTTP/1.1 200 \r\ncontent-length: 5\r\ndate: Thu, 01 
Jan 1970 01:23:20 GMT\r\nserver: hypercorn-h11\r\nConnection: close\r\n\r\n"  # 
noqa: E501
)
),
call(RawData(data=b"hello")),
]
E   AssertionError: assert [call(RawData...ddress=None))] == 
[call(RawData(...ddress=None))]
E At index 0 diff: call(RawData(data=b'HTTP/1.1 200 \r\ncontent-length: 
5\r\ndate: Thu, 01 Jan 1970 01:23:20 GMT\r\nserver: 
hypercorn-h11\r\nconnection: close\r\n\r\n', address=None)) != 
call(RawData(data=b'HTTP/1.1 200 \r\ncontent-length: 5\r\ndate: Thu, 01 Jan 
1970 01:23:20 GMT\r\nserver: hypercorn-h11\r\nConnection: close\r\n\r\n', 
address=None))
E Use -v to get the full diff

protocol   = 

tests/protocol/test_h11.py:71: AssertionError
 Captured stderr setup -
Exception ignored in: 
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.9_hypercorn/build/hypercorn/asyncio/tcp_server.py",
 line 79, in run
await self._read_data()
  File 
"/<>/.pybuild/cpython3_3.9_hypercorn/build/hypercorn/asyncio/tcp_server.py",
 line 103, in _read_data
data = await self.reader.read(MAX_RECV)
  File 
"/<>/.pybuild/cpython3_3.9_hypercorn/build/tests/asyncio/helpers.py",
 line 21, in read
return await self.data.get()
  File "/usr/lib/python3.9/asyncio/queues.py", line 168, in get
getter.cancel()  # Just in case getter is not done yet.
  File "/usr/lib/python3.9/asyncio/base_events.py", line 746, in call_soon
self._check_closed()
  File "/usr/lib/python3.9/asyncio/base_events.py", line 510, in _check_closed
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
-- Captured log setup --
ERRORasyncio:base_events.py:1738 Task was destroyed but it is pending!
 task: >/.pybuild/cpython3_3.9_hypercorn/build/hypercorn/asyncio/tcp_server.py:79>
 wait_for=()]>>
ERRORasyncio:base_events.py:1738 Task was destroyed but it is pending!
 task: >/.pybuild/cpython3_3.9_hypercorn/build/hypercorn/asyncio/tcp_server.py:154>
 wait_for= cb=[()]>
ERRORasyncio:base_events.py:1738 Task was destroyed but it is pending!
 task: >/.pybuild/cpython3_3.9_hypercorn/build/hypercorn/protocol/h2.py:147>
 wait_for=>/.pybuild/cpython3_3.9_hypercorn/build/hypercorn/asyncio/tcp_server.py:153>
 wait_for= cb=[()]>>
...
= 2 failed, 165 passed, 2 skipped, 6 warnings in 2.12 seconds ==
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.9_hypercorn/build; python3.9 -m pytest 
--ignore=tests/trio
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 
3.8" returned exit code 13
make: 

Bug#972655: python-magcode-core FTBFS: No module named 'sqlalchemy'

[Adrian Bunk]

Source: python-magcode-core
Version: 1.5.4-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=python-magcode-core=all=1.5.4-4=1602724429=0

...
   dh_auto_test -i -O--buildsystem=pybuild
dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 
in use)
I: pybuild base:217: cd 
/<>/.pybuild/cpython3_3.9_magcode-core/build; python3.9 -m 
unittest discover -v 
magcode.core.database (unittest.loader._FailedTest) ... ERROR
magcode.core.wsgi (unittest.loader._FailedTest) ... ERROR

==
ERROR: magcode.core.database (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: magcode.core.database
Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/loader.py", line 470, in _find_test_path
package = self._get_module_from_name(name)
  File "/usr/lib/python3.9/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File 
"/<>/.pybuild/cpython3_3.9_magcode-core/build/magcode/core/database/__init__.py",
 line 28, in 
from magcode.core.database.utility import *
  File 
"/<>/.pybuild/cpython3_3.9_magcode-core/build/magcode/core/database/utility.py",
 line 29, in 
from sqlalchemy import create_engine
ModuleNotFoundError: No module named 'sqlalchemy'


==
ERROR: magcode.core.wsgi (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: magcode.core.wsgi
Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/loader.py", line 470, in _find_test_path
package = self._get_module_from_name(name)
  File "/usr/lib/python3.9/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File 
"/<>/.pybuild/cpython3_3.9_magcode-core/build/magcode/core/wsgi/__init__.py",
 line 30, in 
from magcode.core.database import *
  File 
"/<>/.pybuild/cpython3_3.9_magcode-core/build/magcode/core/database/__init__.py",
 line 28, in 
from magcode.core.database.utility import *
  File 
"/<>/.pybuild/cpython3_3.9_magcode-core/build/magcode/core/database/utility.py",
 line 29, in 
from sqlalchemy import create_engine
ModuleNotFoundError: No module named 'sqlalchemy'


--
Ran 2 tests in 0.001s

FAILED (errors=2)
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.9_magcode-core/build; python3.9 -m 
unittest discover -v 
dh_auto_test: error: pybuild --test -i python{version} -p "3.9 3.8" returned 
exit code 13
make: *** [debian/rules:10: build-indep] Error 25

Bug#937488: pynast: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Wed, Jan 08, 2020 at 03:03:57PM +0100, Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 https://github.com/biocore/pynast/issues/20
> 
> I managed to create a patch using 2to3 but pynast depends python-cogent
> vesion <= 1.9 which is Python2.  The python3-cogent3 package has a
> different API and is not compatible with pynast any more.  If upstream
> might not be able to adapt to cogent3 we probably need to remove pynast
> from Debian.

Given that there's been no upstream reaction for almost a year, let's
remove?

Cheers,
Moritz

Bug#972654: pulseaudio: sound card or some of its profiles randomly lost on reboot

[neo]

Package: pulseaudio
Version: 13.0-5
Severity: important
X-Debbugs-Cc: n...@nxmail.org

Dear Maintainer,

   * What led up to the situation?
Updating my system
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Rebooting PC always causes pulseaudio to lose random profiles or even a whole 
card
$ pacmd list
profiles:
input:analog-stereo: Analog Stereo Input (priority 65, 
available: no)
output:analog-stereo: Analog Stereo Output (priority 6500, 
available: unknown)
output:analog-stereo+input:analog-stereo: Analog Stereo Duplex 
(priority 6565, available: no)
output:analog-surround-21: Analog Surround 2.1 Output (priority 
1300, available: unknown)
output:analog-surround-40: Analog Surround 4.0 Output (priority 
1200, available: unknown)
output:analog-surround-40+input:analog-stereo: Analog Surround 
4.0 Output + Analog Stereo Input (priority 1265, available: no)
output:iec958-stereo: Digital Stereo (IEC958) Output (priority 
5500, available: unknown)
output:iec958-stereo+input:analog-stereo: Digital Stereo 
(IEC958) Output + Analog Stereo Input (priority 5565, available: no)
off: Off (priority 0, available: unknown)

after applying workaround:
profiles:
input:analog-stereo: Analog Stereo Input (priority 65, 
available: no)
output:analog-stereo: Analog Stereo Output (priority 6500, 
available: unknown)
output:analog-stereo+input:analog-stereo: Analog Stereo Duplex 
(priority 6565, available: no)
output:analog-surround-21: Analog Surround 2.1 Output (priority 
1300, available: unknown)
output:analog-surround-21+input:analog-stereo: Analog Surround 
2.1 Output + Analog Stereo Input (priority 1365, available: no)
output:analog-surround-40: Analog Surround 4.0 Output (priority 
1200, available: unknown)
output:analog-surround-40+input:analog-stereo: Analog Surround 
4.0 Output + Analog Stereo Input (priority 1265, available: no)
output:analog-surround-41: Analog Surround 4.1 Output (priority 
1300, available: unknown)
output:analog-surround-41+input:analog-stereo: Analog Surround 
4.1 Output + Analog Stereo Input (priority 1365, available: no)
output:analog-surround-50: Analog Surround 5.0 Output (priority 
1200, available: unknown)
output:analog-surround-50+input:analog-stereo: Analog Surround 
5.0 Output + Analog Stereo Input (priority 1265, available: no)
output:analog-surround-51: Analog Surround 5.1 Output (priority 
1300, available: unknown)
output:analog-surround-51+input:analog-stereo: Analog Surround 
5.1 Output + Analog Stereo Input (priority 1365, available: no)
output:iec958-stereo: Digital Stereo (IEC958) Output (priority 
5500, available: unknown)
output:iec958-stereo+input:analog-stereo: Digital Stereo 
(IEC958) Output + Analog Stereo Input (priority 5565, available: no)
output:iec958-ac3-surround-51: Digital Surround 5.1 
(IEC958/AC3) Output (priority 300, available: unknown)
output:iec958-ac3-surround-51+input:analog-stereo: Digital 
Surround 5.1 (IEC958/AC3) Output + Analog Stereo Input (priority 365, 
available: no)
off: Off (priority 0, available: unknown)


   * What was the outcome of this action?
There may be no sound, sound may switch to Digital output when Analog card is 
lost
   * What outcome did you expect instead?
Active profile should be selected and available after reboot
Every profile and card should be available after reboot

Workaround:
pulseaudio -k and wait for automatic restart or start manually
after every reboot

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.58
ii  libasound2   1.2.3.2-1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-4
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-1
ii  libgcc-s110.2.0-15
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-14
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse0

Bug#912752: Update on packaging status?

[Raphael Wimmer]

Hi.

Are you still planning to upload a python3-pyfuse3 package?
python3-trio (0.13) is available in Debian unstable/testing.

I would greatly appreciate a Debian package.

Cheers,
Raphael

Bug#936604: FYI: Python 3 migration of distributuion

[Moritz Mühlenhoff]

On Tue, Nov 19, 2019 at 10:43:49PM +0900, Osamu Aoki wrote:
> On Sun, Nov 17, 2019 at 02:28:44PM +0900, Osamu Aoki wrote:
> > Hi,
> >
> > On Wed, Nov 13, 2019 at 11:11:43AM -0600, Charles Cazabon wrote:
> > > Osamu Aoki  wrote:
> > > >
> > > > Currently, getmail is a candidate for removal from the upcoming Debian
> > > > release if it is not updated to support python 3 by someone (not
> > > > necessary by upstream).
> > >
> > > Thanks for the update, Osamu.  I have actually been playing with a 
> > > prototype
> > > refactoring of getmail to not just support but require a recent Python 3.x
> > > version.  Such a project would give me the opportunity to remove a lot of
> > > historical cruft and backwards-compatibility code that getmail has 
> > > accumulated
> > > over 20+ years.
> >
> > That's great.  (I thought you rejected idea to move to 3.0.)
> >
> > I tried to do it around getmail 5.5 days.  (I didn't finish it)
> 
> 
> FYI: I found this repo
> https://gitlab.com/dkg/getmail/commits/python3
> I think this is better work than my local work.

Hi Osamu,
given that a Py3-compatible version is now available as src:getmail6,
let's go ahead and remove getmail?

Cheers,
Moritz

Bug#972653: RM: archivemail -- RoQA; dead upstream, unmaintained, depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove archivemail. It's dead upstream, the last upload was in 2014 and
it depends on Python 2, which is going away.

Cheers,
Moritz

Bug#936146: archivemail - Python 3 porting

[Moritz Mühlenhoff]

On Tue, Aug 04, 2020 at 11:12:51AM +0100, Jonathan Dowland wrote:
> On Mon, Jul 27, 2020 at 12:37:36AM -0400, Sandro Tosi wrote:
> > do you have any plan on completing this port? I'm not a user of
> > archivemail but it looks like it should be removed, not salvaged:
> > 
> > * no new upstream releases since 2011 (!)
> > * last upload to debian in 2014
> > * retired from fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1777616
> > 
> > maybe it's time to let it go?
> > 
> > If i dont hear otherwise in a week, i'll file for its removal
> 
> I think I'm happy for it to go. I'm certainly not going to be able to
> work on porting it, and I'm most likely going to move to something else
> for the purposes I use it.

Since there were no further objections, I've just filed a removal bug.

Cheers,
Moritz

Bug#972651: buster-pu: package fastd/18-3+deb10u1

[Sven Eckelmann]

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

[ Reason ]
The new packet buffer code (and checks) in v20 revealed a long standing issue 
in fastd: A buffer with an invalid packet will just leak.

This results in an assert with v20 and memory exhaustion in earlier versions. 
While v21 (already in unstable) fixed it, the memory exhaustion is still a 
problem for stable and oldstable.

[ Impact ]
The problem can be used to DoS a system. Only some handcrafted (invalid) 
UDP packets have to be send to a server.

[ Tests ]
Tested on a server with an attacker which injects invalid packets on the 
relevant UDP port. v20 "crashed" after a couple of packets. v18 (currently in 
[old]stable) required a couple of minutes to exhaust all memory of the system.

Invalid packets can for example easily created using:

iperf -u -c target.server.example.net -p 1 -t 3000 -b 40M

The problem went completely away after v21 was installed or the proposed 
upload from this ticket was installed.

The stability test of the fixed version is ongoing.

[ Risks ]
None known at the moment

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in (old)stable
  [*] the issue is verified as fixed in unstable

[ Other info ]
See http://bugs.debian.org/972521 for the unstable bug.

I have not yet uploaded the change to stable but will do this after I get an 
approval for the attached change.

Kind regards,
Svendiff -Nru fastd-18/debian/changelog fastd-18/debian/changelog
--- fastd-18/debian/changelog	2018-01-08 20:48:21.0 +0100
+++ fastd-18/debian/changelog	2020-10-19 22:38:02.0 +0200
@@ -1,3 +1,12 @@
+fastd (18-3+deb10u1) buster; urgency=medium
+
+  * debian/patches:
+- Add 0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch,
+  Fix DoS'able memory leak when receiving too many invalid packets
+  (Closes: #972521)
+
+ -- Sven Eckelmann   Mon, 19 Oct 2020 22:38:02 +0200
+
 fastd (18-3) unstable; urgency=medium
 
   * Update to new Debian policy and fix lintian problems.
diff -Nru fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch
--- fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch	1970-01-01 01:00:00.0 +0100
+++ fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch	2020-10-19 22:38:02.0 +0200
@@ -0,0 +1,43 @@
+From: Matthias Schiffer 
+Date: Mon, 19 Oct 2020 21:08:16 +0200
+Subject: receive: fix buffer leak when receiving invalid packets
+
+For fastd versions before v20, this was just a memory leak (which could
+still be used for DoS, as it's remotely triggerable). With the new
+buffer management of fastd v20, this will trigger an assertion failure
+instead as soon as the buffer pool is empty.
+
+Origin: upstream, https://github.com/NeoRaider/fastd/commit/737925113363b6130879729cdff9ccc46c33eaea
+Bug-Debian: https://bugs.debian.org/972521
+---
+ src/receive.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/src/receive.c b/src/receive.c
+index 732d4a7..a3ecfe3 100644
+--- a/src/receive.c
 b/src/receive.c
+@@ -186,6 +186,11 @@ static inline void handle_socket_receive_known(fastd_socket_t *sock, const fastd
+ 
+ 	case PACKET_HANDSHAKE:
+ 		fastd_handshake_handle(sock, local_addr, remote_addr, peer, buffer);
++		break;
++
++	default:
++		fastd_buffer_free(buffer);
++		pr_debug("received packet with invalid type from %P[%I]", peer, remote_addr);
+ 	}
+ }
+ 
+@@ -211,6 +216,11 @@ static inline void handle_socket_receive_unknown(fastd_socket_t *sock, const fas
+ 
+ 	case PACKET_HANDSHAKE:
+ 		fastd_handshake_handle(sock, local_addr, remote_addr, NULL, buffer);
++		break;
++
++	default:
++		fastd_buffer_free(buffer);
++		pr_debug("received packet with invalid type from unknown address %I", remote_addr);
+ 	}
+ }
+ 
diff -Nru fastd-18/debian/patches/series fastd-18/debian/patches/series
--- fastd-18/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ fastd-18/debian/patches/series	2020-10-19 22:38:02.0 +0200
@@ -0,0 +1 @@
+0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch


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

Bug#972652: stretch-pu: package fastd/18-2+deb9u1

[Sven Eckelmann]

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

[ Reason ]
The new packet buffer code (and checks) in v20 revealed a long standing issue 
in fastd: A buffer with an invalid packet will just leak.

This results in an assert with v20 and memory exhaustion in earlier versions. 
While v21 (already in unstable) fixed it, the memory exhaustion is still a 
problem for stable and oldstable.

[ Impact ]
The problem can be used to DoS a system. Only some handcrafted (invalid) 
UDP packets have to be send to a server.

[ Tests ]
Tested on a server with an attacker which injects invalid packets on the 
relevant UDP port. v20 "crashed" after a couple of packets. v18 (currently in 
[old]stable) required a couple of minutes to exhaust all memory of the system.

Invalid packets can for example easily created using:

iperf -u -c target.server.example.net -p 1 -t 3000 -b 40M

The problem went completely away after v21 was installed or the proposed 
upload from this ticket was installed.

The stability test of the fixed version is ongoing.

[ Risks ]
None known at the moment

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in (old)stable
  [*] the issue is verified as fixed in unstable

[ Other info ]
See http://bugs.debian.org/972521 for the unstable bug.

I have not yet uploaded the change to stable but will do this after I get an 
approval for the attached change.

Kind regards,
Svendiff -Nru fastd-18/debian/changelog fastd-18/debian/changelog
--- fastd-18/debian/changelog	2016-05-13 13:37:11.0 +0200
+++ fastd-18/debian/changelog	2020-10-19 22:42:50.0 +0200
@@ -1,3 +1,12 @@
+fastd (18-2+deb9u1) stretch; urgency=medium
+
+  * debian/patches:
+- Add 0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch,
+  Fix DoS'able memory leak when receiving too many invalid packets
+  (Closes: #972521)
+
+ -- Sven Eckelmann   Mon, 19 Oct 2020 22:42:50 +0200
+
 fastd (18-2) unstable; urgency=medium
 
   * Fix operation under systemd (Closes: #823801).
diff -Nru fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch
--- fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch	1970-01-01 01:00:00.0 +0100
+++ fastd-18/debian/patches/0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch	2020-10-19 22:42:50.0 +0200
@@ -0,0 +1,43 @@
+From: Matthias Schiffer 
+Date: Mon, 19 Oct 2020 21:08:16 +0200
+Subject: receive: fix buffer leak when receiving invalid packets
+
+For fastd versions before v20, this was just a memory leak (which could
+still be used for DoS, as it's remotely triggerable). With the new
+buffer management of fastd v20, this will trigger an assertion failure
+instead as soon as the buffer pool is empty.
+
+Origin: upstream, https://github.com/NeoRaider/fastd/commit/737925113363b6130879729cdff9ccc46c33eaea
+Bug-Debian: https://bugs.debian.org/972521
+---
+ src/receive.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/src/receive.c b/src/receive.c
+index 732d4a7..a3ecfe3 100644
+--- a/src/receive.c
 b/src/receive.c
+@@ -186,6 +186,11 @@ static inline void handle_socket_receive_known(fastd_socket_t *sock, const fastd
+ 
+ 	case PACKET_HANDSHAKE:
+ 		fastd_handshake_handle(sock, local_addr, remote_addr, peer, buffer);
++		break;
++
++	default:
++		fastd_buffer_free(buffer);
++		pr_debug("received packet with invalid type from %P[%I]", peer, remote_addr);
+ 	}
+ }
+ 
+@@ -211,6 +216,11 @@ static inline void handle_socket_receive_unknown(fastd_socket_t *sock, const fas
+ 
+ 	case PACKET_HANDSHAKE:
+ 		fastd_handshake_handle(sock, local_addr, remote_addr, NULL, buffer);
++		break;
++
++	default:
++		fastd_buffer_free(buffer);
++		pr_debug("received packet with invalid type from unknown address %I", remote_addr);
+ 	}
+ }
+ 
diff -Nru fastd-18/debian/patches/series fastd-18/debian/patches/series
--- fastd-18/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ fastd-18/debian/patches/series	2020-10-19 22:42:50.0 +0200
@@ -0,0 +1 @@
+0001-receive-fix-buffer-leak-when-receiving-invalid-packe.patch


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

Bug#972602: python-asteval: tests not run during build

[Michael Hudson-Doyle]

On Wed, 21 Oct 2020 at 14:01, Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

>
> On Wed, 21 Oct 2020 at 13:48, Michael Hudson-Doyle 
> wrote:
>
>>
>> This also makes the build fail in sid because Python 3.9 is now a
>> supported version but I think an upstream update will fix that.
>>
>
> It does.
>
>
>> While I'm here, the git repository in Vcs-Git does not exist.
>>
>
> I've just applied (slightly accidentally ;-p) to join the science team on
> salsa so if you let me in, I can fix all of this :) (I'll probably mostly
> work on Python version transitions)
>

Turns out the repository existed but was private, thanks to ginggs for
making it public.

Cheers,
mwh

Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs

[Aurelien Jarno]

Hi,

On 2020-10-21 11:55, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> On 10/19/20 9:12 PM, Aurelien Jarno wrote:
> >>   jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a 
> >> *lot* of architectures
> >>   jrtc27 | if it were up to me the problem would be solved by just 
> >> deleting sbrk...
> >>   jrtc27 | FreeBSD just took the stance of not implementing them for new 
> >> ports
> >>   jrtc27 | so it's arm64 and riscv64 ports just have no sbrk
> >>   jrtc27 | cbmuser: looks like the tests are Debian-specific
> >>   jrtc27 | added as part of Hurd sbrk reworking to test it didn't break
> > 
> > This is a bit exaggerated, this test actually passes on more
> > architectures than it fails. Also this doesn't mean the test is useless,
> > it means those architectures behaves differently, and that something has
> > to be fixed. It could be some architecture specific code or the test
> > itself.
> 
> Well, but if it's in the end a feature that no one is using and a test that 
> isn't even part
> of the upstream tests I don't see the point in testing it.

brk/sbrk is definitely something deprecated. But it is still part of the
API (especially for old architectures) and still used by software like
jemalloc, gcl or libgc. This is therefore important to keep this feature
in a good shape.

It's also used by many less important packages, often just to print a
backtrace.

If someone has spoons it might be worth opening bugs again those
package, so that they stop using brk/sbrk.

> >> Can we disable them? With the tests disabled, glibc should pass its 
> >> testsuite on at least alpha and
> >> sparc64. Not sure what the problem with hppa is at the moment.
> > 
> > We can definitely ignore it on the affected architectures, do you please
> > give more details why the test is so wrong that it should be ignored on
> > *all* architectures?
> 
> I'm just quoting jrtc27 from IRC. I'm not really an expert on that matter.
> 
> > Ignoring it on the affected architectures, will indeed fix alpha. Not
> > sure about hppa, ia64 and sparc64 that have other issues. And there is
> > no build log for m68k and sh4 to judge.
> 
> It seems that these two tests are currently the only tests that are not being 
> ignored
> that are failing unless I'm missing something (I just looked at the build 
> log).

I guess you mean for sparc64. This is indeed the case when building the
sparc64 flavour, but we know that the sparc flavour will fail later.

Aurelien 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#972650: what-is-python: Ubuntu-specific package descriptions

[Adrian Bunk]

Source: what-is-python
Version: 6
Severity: important

...
 In Ubuntu, all python packages use explicit python3 or python2
...
 This package will be installed upon upgrades to Ubuntu 20.04, if
 DEPRECATED python2 was installed.
 .
 python2 is DEPRECATED and will not be provided in the future Ubuntu
 release. It is recommended to remove python2 and this package after
 ensuring that only python3 is in use.
...


These should be changed to a more distribution-agnotic descriptions.

Bug#972648: python2: Can't upgrade to 2.7.18-2

[Alexandre Lymberopoulos]

Package: python2
Version: 2.7.17-2
Severity: normal

Dear Maintainer,

Aptitude suggeste me, a few days ago, to update some python2 packages
from 2.7.17-2 to 2.7.18-2, namely python2, libpython2-stdlib, and
python2-minimal. When I try to perform this update it complains
suggesting to keep all of them at the current version (which I do
marking them to hold).

Any tentative to solve this falls into a "circular dependence" (not
sure if this is the best term to be used here).

Please write back if any further information is necessary.

Thanks in advance and best wishes, Alexandre

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python2 depends on:
hi  libpython2-stdlib  2.7.17-2
hi  python2-minimal2.7.17-2
ii  python2.7  2.7.18-1

python2 recommends no packages.

Versions of packages python2 suggests:
pn  python-tk
pn  python2-doc  

-- no debconf information

Bug#972396: initramfs-tools: Installation fails (no space left on device)

[Bill Wohler]

Ben Hutchings  wrote:

> Control: tag -1 moreinfo
> 
> On Sat, 2020-10-17 at 09:59 -0700, Bill Wohler wrote:
> > Package: initramfs-tools
> > Version: 0.139
> > Severity: normal
> > X-Debbugs-Cc: none
> > 
> > When running aptitude safe-upgrade on bullseye this morning, I got the
> > following error. I suspect this might be a misconfigured internal device
> > that ran out of space, since I have ample memory (29 GB) and disk (1.1
> > TB) free.
> [...]
> 
> And how much space is available on the /boot partition?

[wohler@olgas ~ (olgas:%)]$ df /boot
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1   236M  108M  117M  48% /boot

It's what the Debian installer gave me by default. I haven't touched
this partition manually, and don't keep more than 3 kernels lying
around.

-- 
Bill Wohler  aka 
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Bug#972634: apparmor- profile can not define message queue name or directory

[Bossler Daniela]

Package: apparmor
Version: 2.12-4ubuntu5.1

We want to open a posix message queue in a user defined function under mysqld.
Mysqld has a apparmor-profile without any queue access rigths (/dev/mqueue).
We added /dev/mqueue/** rw  to the profile but mysqld can not open any queue 
with mq_open().
Next we tried to add the queue name to the profil (/sp-example-server w,), but 
the problem/bug? is that the profile entries must begin with a "/" and the 
queue names are passed by mq_open to apparmor without the slash. So it's not 
possible to allow access to the posix-queue.

Is there a workaround?

Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen
Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim 
HRB 510031

Richard Wolf GmbH routinely monitors the content of e-mail sent and received 
via its network for the purposes of ensuring compliance with its policies and 
procedures. Richard Wolf GmbH is not responsible for any changes made to the 
message after it has been sent. Where opinions are expressed, they are not 
necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted 
with it are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you are not the intended addressee, or 
the person responsible for delivering it to them, you may not copy, forward, 
disclose, or otherwise use it or any part of it in any way. To do so may be 
unlawful. If you receive this e-mail by mistake, please advise the sender 
immediately.

Privacy Statement  |  Legal 
Information  |  Terms & 
Conditions

Bug#970517: [Openjdk] Bug#970517: openjdk-11 (and openjdk-14 as well): copyright file does not specify the correct source

[Matthias Klose]

On 9/17/20 10:14 PM, Julian Gilbey wrote:
> Package: openjdk-11-jdk
> Version: 11.0.8+10-1
> Severity: serious
> 
> Justification: violates a "must" directive in policy section 12.5.
> 
> The current /usr/share/doc/openjdk-*/copyright files incorrectly
> states that the upstream source is from download.java.net; that has
> not been the case for a long time.

updating that for the next upload.

> The copyright information is also very out of date.
> 
> It seems that all of the legal files have already been collected in
> /usr/share/doc/openjdk-14-doc/legal (pointing to /usr/lib/jvm);
> presumably it would be possible to refer to this directory in the
> copyright file?

no, debian policy requires this to be a copy, unless it's one of the common
licenses. Needs updating, but not yet for the next upload.

Bug#972647: tpm2-tools FTCBFS: uninstallable build dependency python3-yaml

[Helmut Grohne]

Source: tpm2-tools
Version: 4.3.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

tpm2-tools fails to cross build from source, because its build
dependency on python3-yaml is not installable. The yaml module is used
for unit tests, but unit tests are disabled since there is no dependency
on cmocka. Thus the dependency is completely unused. Please consider
applying the attached patch to drop it.

Helmut
diff --minimal -Nru tpm2-tools-4.3.0/debian/changelog 
tpm2-tools-4.3.0/debian/changelog
--- tpm2-tools-4.3.0/debian/changelog   2020-09-09 11:22:40.0 +0200
+++ tpm2-tools-4.3.0/debian/changelog   2020-10-21 20:19:32.0 +0200
@@ -1,3 +1,10 @@
+tpm2-tools (4.3.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused build dependency on python3-yaml. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 21 Oct 2020 20:19:32 +0200
+
 tpm2-tools (4.3.0-1) unstable; urgency=low
 
   * New upstream release.
diff --minimal -Nru tpm2-tools-4.3.0/debian/control 
tpm2-tools-4.3.0/debian/control
--- tpm2-tools-4.3.0/debian/control 2020-05-17 05:37:13.0 +0200
+++ tpm2-tools-4.3.0/debian/control 2020-10-21 20:19:32.0 +0200
@@ -14,7 +14,6 @@
libtss2-dev (>= 2.3.0),
pandoc,
pkg-config,
-   python3-yaml,
uuid-dev,
xsltproc
 Homepage: https://github.com/01org/tpm2.0-tools

Bug#972646: openconnect FTCBFS: python3 build dependency not installable

[Helmut Grohne]

Source: openconnect
Version: 8.10-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

openconnect fails to cross build from source, because its build
dependency on python3 is not satisfiable. It does not actually need a
host architecture python though, what it really needs is a build
architecture python to run during build. That amounts to depending on
python3:any. Please consider applying the attached patch to make
openconnect cross buildable.

Helmut
diff --minimal -Nru openconnect-8.10/debian/changelog 
openconnect-8.10/debian/changelog
--- openconnect-8.10/debian/changelog   2020-05-14 19:51:18.0 +0200
+++ openconnect-8.10/debian/changelog   2020-10-21 20:13:57.0 +0200
@@ -1,3 +1,10 @@
+openconnect (8.10-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate python3 build dependency with :any. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 21 Oct 2020 20:13:57 +0200
+
 openconnect (8.10-1) unstable; urgency=medium
 
   * Update upstream source from tag 'upstream/8.10'
diff --minimal -Nru openconnect-8.10/debian/control 
openconnect-8.10/debian/control
--- openconnect-8.10/debian/control 2020-05-14 19:51:18.0 +0200
+++ openconnect-8.10/debian/control 2020-10-21 20:13:56.0 +0200
@@ -23,7 +23,7 @@
ocserv (>= 0.12.1-2) [!hurd-i386 !kfreebsd-amd64 
!kfreebsd-i386] ,
openssl ,
pkg-config,
-   python3,
+   python3:any,
softhsm2 [!hurd-i386] ,
zlib1g-dev
 Standards-Version: 4.5.0

Bug#972585: Probable place where the bug is

[Julien Puydt]

Hi,

I don't know perl at all, but looking through the sources, I found that
in Devscripts/Uscan/Downloader.pm, I think there's a function
'download' line 82 (the name 'sub' is probably for subroutine) :

- the start of the function is for http and ftp modes, until line 133
where I think it's for git mode (the comment explains the last 'else',
I suppose) ;

- in line 141, a gitrepo_dir variable gets assigned the name of the
future repository ;

- in line 145, I have no clue why there's a check on the mode being
'svn' : it's definitely not logical to have it there!

- in lines 150-154, a tarball is made (no need for a checkout, it
seems) ;

- in lines 155-168, a clone is made under various options, and lines
169-176, a tarball is made ;

- in lines 178-190, both previous blocks converge : the tarball is
compressed.

and we get out of download, leaving the checkout in place -- and I
think that's where some deletion should be added.


I'll probably be able to learn enough perl to propose a patch tomorrow;
it looks like a one-liner.

Cheers,

JP

Bug#972645: gnome-builder does not start without flatpak package installed

[nodiscc]

Package: gnome-builder
Version: 3.30.3-2
Severity: grave
Debian 10 Buster

Dear maintainer,

gnome-builder does not start at all when the flatpak package is not
installed, and returns code 255. gneom-builder *recommends*
flatpak-builder which in turns depends on flatpak, but if you have
like me disabled installation of recommended packages by defautl the
the program won't start at all.

flatpak should be a hard dependency for the gnome-builder package.

Thanks

$ gnome-builder
ptrace: Operation not permitted.
No threads.
No shared libraries loaded at this time.
# gnome-builder does not start

$ echo $?
255

$ sudo apt install flatpak
...

$ gnome-builder
# gnome-builder starts properly

Bug#972644: CVE-2020-13131 CVE-2020-13132

[Moritz Muehlenhoff]

Package: yubico-piv-tool
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2020-13132
https://www.yubico.com/support/security-advisories/ysa-2020-02/

CVE-2020-13131
https://blog.inhq.net/posts/yubico-libykpiv-vuln/

Cheers,
Moritz

Bug#972643: ITP: libgtk3-imageview-perl -- Gtk3 port of the Gtk2::ImageView image viewer widget

[Jeffrey Ratcliffe]

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

* Package name: libgtk3-imageview-perl
  Version : 1
  Upstream Author : Jeffrey Ratcliffe 
* URL : https://metacpan.org/release/Gtk3-ImageView
* License : Perl
  Programming Lang: Perl
  Description : Gtk3 port of the Gtk2::ImageView image viewer widget

 The Gtk3::ImageView widget allows the user to zoom, pan and select the
 specified image and provides hooks to allow additional tools, e.g. painter,
 to be created and used.

This is going to be a dependency of gscan2pdf.
I will maintain it as part of the Perl team.

Bug#972642: CVE-2020-12648 CVE-2020-17480

[Moritz Muehlenhoff]

Package: tinymce
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2020-12648:
https://labs.bishopfox.com/advisories/tinymce-version-5.2.1

CVE-2020-17480:
https://github.com/tinymce/tinymce/security/advisories/GHSA-27gm-ghr9-4v95

Bug#971367: [debian-mysql] Bug#971367: Bug#971367: Bug#971367: mariadb-10.5 should not embed wolfssl

[Moritz Mühlenhoff]

On Wed, Sep 30, 2020 at 08:09:10PM +0300, Otto Kekäläinen wrote:
> Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-21835
> 
> Note that the upstream MariaDB uses OpenSSL both for building the
> server and the client. In Debian OpenSSL is forbidden in the current
> state (or so has e.g. Clint Byrum stated), so in Debian we build using
> alternatives, which for the server means GnuTLS and for the client
> WolfSSL (former YaSSL).
> 
> The long term solution is to wait for OpenSSL 3.0 to be released and
> build against it (as it has no license issues). The short term
> solution is to hope for upstream to add support for building the
> client with the system WolfSSL library.

Hi Otto,
FTP masters changed their assessment on treating OpenSSL as a system
library, see the FTP meeting log at
http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html
and the followup discussion at
https://lists.debian.org/debian-devel/2020/10/msg00165.html

As such, you can switch to OpenSSL without needing to wait for OpenSSL 3.0 \o/

Cheers,
Moritz

Bug#972641: CVE-2020-11721

[Moritz Muehlenhoff]

Source: libsixel
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-11721:
https://github.com/saitoha/libsixel/issues/134

Cheers,
Moritz
 

Bug#972172: Removed package(s) from unstable

[Sean Whitton]

Hello,

On Mon 19 Oct 2020 at 11:43pm +02, Markus Koschany wrote:

> Hello,
>
> Am 19.10.20 um 23:33 schrieb Debian FTP Masters:
>> We believe that the bug you reported is now fixed; the following
>> package(s) have been removed from unstable:
>>
>> libnb-absolutelayout-java | 12.1-1 | all
>> libnb-apisupport3-java | 10.0-3 | all
>> libnb-ide14-java | 10.0-3 | all
>> libnb-java5-java | 10.0-3 | all
>>   netbeans | 10.0-3 | source, all
>>   netbeans | 12.1-1 | source
>>
>> --- Reason ---
>> NBS; no longer viable to maintain in Debian
>> --
>
> I only requested that the obsolete binary packages got removed from
> unstable because libnb-absolutelayout-java, the only remaining binary
> package, did not migrate to testing. It appears you just removed the
> complete source package src:netbeans. How can we fix this?

Ooops.  We can fast track it through NEW.

-- 
Sean Whitton

Bug#972640: qmake cross wrapper: allow passing -qt5

[Helmut Grohne]

Package: qt5-qmake
Version: 5.14.2+dfsg-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:marble

Hi,

I found a new way to break the -qmake cross wrapper. The
variant resides in marble's debian/rules. It actually does use the cross
wrapper, but it invokes it as "$(QMAKE) -qt=5 -query something". Since
our cross wrapper expects -query to come first, it doesn't recognize the
mode and fails.

Since our wrapper always calls into qt5, we can simply skip that flag.
Doing so should make the marble build happier. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru qtbase-opensource-src-5.14.2+dfsg/debian/changelog 
qtbase-opensource-src-5.14.2+dfsg/debian/changelog
--- qtbase-opensource-src-5.14.2+dfsg/debian/changelog  2020-08-19 
19:40:32.0 +0200
+++ qtbase-opensource-src-5.14.2+dfsg/debian/changelog  2020-10-21 
19:28:25.0 +0200
@@ -1,3 +1,10 @@
+qtbase-opensource-src (5.14.2+dfsg-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * qmake cross wrapper: Allow passing -qt5. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 21 Oct 2020 19:28:25 +0200
+
 qtbase-opensource-src (5.14.2+dfsg-6) unstable; urgency=medium
 
   * Backport upstream patch to fix buffer overflow in XBM parser
diff --minimal -Nru 
qtbase-opensource-src-5.14.2+dfsg/debian/qmake-cross-wrapper.in 
qtbase-opensource-src-5.14.2+dfsg/debian/qmake-cross-wrapper.in
--- qtbase-opensource-src-5.14.2+dfsg/debian/qmake-cross-wrapper.in 
2020-08-19 19:40:32.0 +0200
+++ qtbase-opensource-src-5.14.2+dfsg/debian/qmake-cross-wrapper.in 
2020-10-21 19:28:21.0 +0200
@@ -1,5 +1,9 @@
 #!/bin/sh
 
+if [ "x$1" = x-qt5 ] || [ "x$1" = "x-qt=5" ]; then
+   shift
+fi
+
 QMAKE_MODE=
 
 if [ "x$1" = x-query ]; then

Bug#972341: CVE-2020-8564 CVE-2020-8565 CVE-2020-8566

[Janos LENART]

Thanks :)

CVE-2020-8564 and CVE-2020-8566 are fixed in 1.19.3-1

CVE-2020-8565 is outstanding

On Fri, Oct 16, 2020 at 1:54 PM Moritz Muehlenhoff  wrote:

> Source: kubernetes
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
>
> From https://groups.google.com/g/kubernetes-announce/c/ScdmyORnPDk:
>
> CVE-2020-8566:
> https://github.com/kubernetes/kubernetes/pull/95245
> https://github.com/kubernetes/kubernetes/issues/95624
>
> CVE-2020-8565:
> https://github.com/kubernetes/kubernetes/pull/95316
> https://github.com/kubernetes/kubernetes/issues/95623
>
> CVE-2020-8564:
> https://github.com/kubernetes/kubernetes/pull/94712
> https://github.com/kubernetes/kubernetes/issues/95622
>
> Cheers,
> Moritz
>
>

-- 
LÉNÁRT, János

Bug#972605: jekyll: Please update to new 4.x branch

[calumlikesapplepie]

On Wed, 2020-10-21 at 15:12 +0200, Daniel Leidert wrote:
> Am Dienstag, den 20.10.2020, 23:33 -0400 schrieb Calum McConnell:
> 
> > Jekyll upstream has been concentrating on a new 4.x release branch
> > for the
> > past year.  It provides a significant set of new features that I
> > use, and it
> > would be great if it could be included in debian.
> > 
> > I assume you know all of that already, since 3.9 released after
> > 4.0, but I
> > was wondering what the rationale was for sticking with the 3.x
> > branch.
> 
> It is very stable and well tested. Also not all plugins had been
> ported to
> Jekyll 4 at the beginning of the year (not sure about the current
> state).
> Further it would make backporting to current stable a lot more
> complicated.
> I'm not aware of any ground-breaking changes. What features are you
> referring to?

Its not exactly ground-breaking (I might have exaggerated
'significant'), but the caching system is really handy.  I like to
iterate rapidly, and a cache is really, really helpful for that: it
halves build times.

Also, there a bunch of little changes, such as relative-url, that I
appreciate.  The sort of changes that a user might try to use, and then
be confused as to why they don't work.

The biggest reason, though, is that 3.9 is like Python 2.7: it's
probably the last release of the series.  According to rubygems, 3.9.0
has a third the downloads of 4.1.1, and a sixth of 4.0.0: its clear
people are moving up to the next version, and will eventually need to
do so if they want to keep getting support for plugins.  I believe
there are already some 4.0-only plugins.

In short, we probably ought to have it in Bullseye before we release.

> The 4.x series will be uploaded to experimental eventually. But I'm
> hesitant to upload it to unstable just now.

Okay: fair enough.  But the 4.0 branch is about a year old, and I
haven't really felt any major issues with it.  I think most plugins
have upgraded by now:

Thanks for considering. Let's keep this bug open, so that you don't get
another person reporting.


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

Bug#972639: maxima-src: Incorrect file contents.hhc is generated

[Stanislav Maslovski]

Package: maxima-src
Version: 5.44.0-2.1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: stanislav.maslov...@gmail.com

Hi,

The create_index script in doc/info has an outdated regexp due to
which the file contents.hhc is generated incorrectly. This results in
the broken contents section in the wxmaxima help browser.

A patch that fixes the issue is attached. If needed, I can also
prepare an NMU.

Best,

Stanislav

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

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

Versions of packages maxima-src depends on:
ii  tex-common  6.15

maxima-src recommends no packages.

maxima-src suggests no packages.

-- no debconf information
Description: Fix create_index script
Author: Stanislav Maslovski 
Last-Update: 2020-10-21

--- maxima-5.44.0.orig/doc/info/create_index
+++ maxima-5.44.0/doc/info/create_index
@@ -23,7 +23,7 @@ while ()  {
 print CONTENTS "\n";
 } 
 
-if ( m#.*?.*?\s(.*?)# ) {
+if ( m#.*?.*?\s(.*?)# ) {
 print CONTENTS "\n";
 print CONTENTS "   \n";
 print CONTENTS "   \n";

Bug#972636: Transmission: cannot open *.torrent files through 'File>Open' menu

[Sandro Tosi]

control: tags -1 +unreproducible

> After upgrade to 'testing' I noticed that most of the times *.torrent files 
> cannot open through 'File>Open' menu.
> What I do to tackle this is going through 'File>Open URL...' and provide the 
> URL with the torrent file.

i just tried with transmission/3.00 in unstable and i could add a
torrent via File>Open just fine.

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

Bug#972634: [pkg-apparmor] Bug#972634: apparmor- profile can not define message queue name or directory

[Christian Boltz]

Hello,

Am Mittwoch, 21. Oktober 2020, 16:46:12 CEST schrieb Bossler Daniela:
> We want to open a posix message queue in a user defined function under
> mysqld. Mysqld has a apparmor-profile without any queue access rigths
> (/dev/mqueue). We added /dev/mqueue/** rw  to the profile but mysqld
> can not open any queue with mq_open(). Next we tried to add the queue
> name to the profil (/sp-example-server w,), but the problem/bug? is
> that the profile entries must begin with a "/" and the queue names
> are passed by mq_open to apparmor without the slash. So it's not
> possible to allow access to the posix-queue.
> 
> Is there a workaround?

My crystal ball says that you get a log entry like this:
(irrelevant and unguessable ;-) parts replaced with "...")

type=AVC msg=audit(...): apparmor="DENIED" operation="..." 
info="Failed name lookup - disconnected path" error=-13 profile="..." 
name="sp-example-server" pid=... comm="..." requested_mask="w" 
denied_mask="w" fsuid=... ouid=...

If my guess is right and the message really reports "disconnected path", 
then you'll need to add the   attach_disconnected   flag to the profile, 
something like:

profile mysql /usr/bin/mysqld flags=(attach_disconnected {


If my guess was wrong, please provide the audit.log messages you see - 
they would help to clean the nebulous areas on my crystal ball ;-)


Regards,

Christian Boltz

PS: non-random signature ;-)
-- 
you could be correct in that bugzilla may not be useful in predicting
either when the bug will be resolved, or the weather next month.
so, maybe subscribe to [opensuse-crystal_ball] is the best bet.
[DenverD in opensuse-factory]


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

Bug#968042: upgrading packet python2 from 2.7.17-2 up to 2.7.18-2 asks packets deletion

[Oswald Buddenhagen]

this bug is duplicated by #970430, from which i learned that the 
unversioned packages are indeed supposed to be deleted (see also 
#937695).


this resolution appears satisfactory:

  --\ Remove the following packages:
libpython-dev
libpython-stdlib
python-dev
python-minimal
python
  --\ Install the following packages:
python-dev-is-python2
python-is-python2

however, that's not what apt or aptitude will propose by default, so the 
upgrade experience is anything but optimal. not quite as bad as #970375, 
though. ;-)

Bug#826048: Heb je mijn bericht ontvangen?

[Elvis Edorh]

Bug#972637: Acknowledgement (finch: crashes on startup with "illegal instruction")

[Karsten Hilbert]

Installing the dbg syms for my intel graphics gives a bit more detail:

 Thread 1 "finch" received signal SIGILL, Illegal instruction.

 0xad45d6fb in std::__cxx11::basic_string, 
std::allocator >::compare (this=0x7bcde0, __str="VIDEO_DEC_H264", 
this=0x7bcde0, __str="VIDEO_DEC_H264") at 
/usr/include/c++/10/bits/basic_string.h:2852

 warning: Source file is more recent than executable.

 2852  compare(const basic_string& __str) const

Backtrace:

 #0  0xad45d6fb in std::__cxx11::basic_string, 
std::allocator >::compare (this=0x7bcde0, __str="VIDEO_DEC_H264", 
this=0x7bcde0,
 __str="VIDEO_DEC_H264") at /usr/include/c++/10/bits/basic_string.h:2852
 #1  std::operator< , std::allocator > 
(__rhs="VIDEO_DEC_H264", __lhs="VIDEO_DEC_HEVC") at 
/usr/include/c++/10/bits/basic_string.h:6270
 #2  std::less, 
std::allocator > >::operator() (__y="VIDEO_DEC_H264", 
__x="VIDEO_DEC_HEVC",
this=0xad8c78b0 ::GetCreators[abi:cxx11]()::creators>) at 
/usr/include/c++/10/bits/stl_function.h:386
 #3  std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::_Select1st, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> >, std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > >::_M_get_insert_unique_pos 
(__k="VIDEO_DEC_HEVC", this=0xad8c78b0 ::GetCreators[abi:cxx11]()::creators>)
 at /usr/include/c++/10/bits/stl_tree.h:2101
 #4  std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::_Select1st, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> >, std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::_M_emplace_unique, std::allocator >, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > (
 this=0xad8c78b0 ::GetCreators[abi:cxx11]()::creators>) at 
/usr/include/c++/10/bits/stl_tree.h:2419
 #5  0xad45fb61 in std::map, std::allocator >, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*), std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::insert, 
std::allocator >, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)> > 
(__x=..., this=0xad8c78b0 ::GetCreators[abi:cxx11]()::creators>)
 at /usr/include/c++/10/bits/stl_map.h:816
 #6  MediaDdiFactory::RegisterCodec (key="VIDEO_DEC_HEVC")
 at ./media_driver/linux/common/ddi/media_ddi_factory.h:67
 #7  0xad1ab0a6 in __static_initialization_and_destruction_0 (__initialize_p=1, 
__priority=65535) at /usr/include/c++/10/bits/char_traits.h:322
 #8  _GLOBAL__sub_I_media_ddi_decode_hevc.cpp(void) () at 
./media_driver/linux/common/codec/ddi/media_ddi_decode_hevc.cpp:967
 #9  0xb7fe5e9c in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0xb634, env=0xb63c) at dl-init.c:72
 #10 0xb7fe5fa2 in call_init (env=0xb63c, argv=0xb634, argc=1, 
l=) at dl-init.c:30
 #11 _dl_init (main_map=, argc=1, argv=0xb634, 
env=0xb63c) at dl-init.c:119
 #12 0xb7fe92a7 in call_dl_init (closure=0xbfffe870) at dl-open.c:469
 #13 0xb79a9524 in __GI__dl_catch_exception (exception=, 
operate=, args=) at dl-error-skeleton.c:182
 #14 0xb7fea08d in dl_open_worker (a=) at dl-open.c:758
 #15 0xb79a94c9 in __GI__dl_catch_exception (exception=0xbfffe9a0, 
operate=0xb7fe9990 , args=0xbfffe9ac) at dl-error-skeleton.c:208
 #16 0xb7fe95e6 in _dl_open (file=0x7bc970 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=-2147479294, 
caller_dlopen=0xad918cc3, nsid=, argc=1,
 argv=0xb634, env=0xb63c) at dl-open.c:837
 #17 0xb78652c8 in dlopen_doit (a=0xbfffebac) at dlopen.c:66
 #18 0xb79a94c9 in __GI__dl_catch_exception (exception=0xbfffeb40, 
operate=0xb7865250 , args=0xbfffebac) at dl-error-skeleton.c:208
 #19 0xb79a9590 in __GI__dl_catch_error (objname=0x45d68c, errstring=0x45d690, 
mallocedp=0x45d688, operate=0xb7865250 , args=0xbfffebac)
at dl-error-skeleton.c:227
 #20 0xb7865b11 in _dlerror_run (operate=0xb7865250 , 
args=0xbfffebac) at dlerror.c:170
 #21 0xb7865364 in __dlopen (file=0x7bc970 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=4354) at dlopen.c:87
 #22 0xad918cc3 in ?? () from /usr/lib/i386-linux-gnu/libva.so.2
 #23 0xad919f90 in vaInitialize () from /usr/lib/i386-linux-gnu/libva.so.2
 #24 0xada1b525 in ?? () from /usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
 #25 0xada1bfe7 in ?? () from /usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
 #26 0xada1c3b9 in ?? () from /usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
 #27 0xada15568 in ?? () from /usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#972638: ITP: wlsunset -- Day/night gamma adjustments for Wayland compositors

[Leon Marz]

Package: wnpp
Severity: wishlist
Owner: Leon Marz 
X-Debbugs-Cc: debian-de...@lists.debian.org, lm...@cs.uni-frankfurt.de

* Package name: wlsunset
  Version : 0.1.0
  Upstream Author : Kenny Levinsen <~kennylevinsen/public-in...@lists.sr.ht>
* URL : https://sr.ht/~kennylevinsen/wlsunset
* License : Expat
  Programming Lang: C
  Description : Day/night gamma adjustments for Wayland compositors

wlsunset is a program that adjusts day/night gamma for Wayland compositors
that support wlr-gamma-control-unstable-v1.
Please look at the documentation of your Wayland compositor to figure out,
if it supports this protocol.
The program will calculate the sun trajectory and figure out the time of
dawn, sunrise, sunset and dusk and set the gamma accordingly.

Bug#972632: apache2: please provide compression snippet to support brotli (not only deflate)

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-10-21 16:31:38)
> P.S.
> 
> This bugreport only covers compression applied to _transfer_ encoding. 
> Covering _content_ encoding a.k.a. pre-compressed files is more tricky 
> because it ties more intimately into the kind of data served. Notably 
> it ties into setup of mime module which currently has _file_ extension 
> .br linked with brazilian portuguese lanugage which would need to get 
> fixed first, e.g. to more properly (only!) use extension .pt-br.

Correction: extension .br is _not_ wrongly tied to the country Brazil 
but is correctly tied to the language Breton.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#972637: finch: crashes on startup with "illegal instruction"

[Karsten Hilbert]

Package: finch
Version: 2.13.0-2.2+b1
Severity: important

Dear maintainers,

on startup this happens (taken from systemd journal):

kernel: traps: finch[25048] trap invalid opcode ip:ad38b6fb sp:bfb44fc0 
error:0 in iHD_drv_video.so[ad0ca000+3c2000]

Running under gdb and backtracing:

Thread 1 "finch" received signal SIGILL, Illegal instruction.
 0xad45d6fb in ?? 
() from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
(gdb) bt
#0  0xad45d6fb in ?? () from 
/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#1  0xad45fb61 in ?? () from 
/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#2  0xad1ab0a6 in ?? () from 
/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#3  0xb7fe5e9c in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0xb634, env=0xb63c) at dl-init.c:72
#4  0xb7fe5fa2 in call_init (env=0xb63c, argv=0xb634, argc=1, 
l=) at dl-init.c:30
#5  _dl_init (main_map=, argc=1, argv=0xb634, 
env=0xb63c) at dl-init.c:119
#6  0xb7fe92a7 in call_dl_init (closure=0xbfffe870) at dl-open.c:469
#7  0xb79a9524 in __GI__dl_catch_exception (exception=, 
operate=, args=) at dl-error-skeleton.c:182
#8  0xb7fea08d in dl_open_worker (a=) at dl-open.c:758
#9  0xb79a94c9 in __GI__dl_catch_exception (exception=0xbfffe9a0, 
operate=0xb7fe9990 , args=0xbfffe9ac) at dl-error-skeleton.c:208
#10 0xb7fe95e6 in _dl_open (file=0x7bc970 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=-2147479294, 
caller_dlopen=0xad918cc3, nsid=, argc=1, argv=0xb634, 
env=0xb63c) at dl-open.c:837
#11 0xb78652c8 in dlopen_doit (a=0xbfffebac) at dlopen.c:66
#12 0xb79a94c9 in __GI__dl_catch_exception (exception=0xbfffeb40, 
operate=0xb7865250 , args=0xbfffebac) at dl-error-skeleton.c:208
#13 0xb79a9590 in __GI__dl_catch_error (objname=0x45d68c, 
errstring=0x45d690, mallocedp=0x45d688, operate=0xb7865250 , 
args=0xbfffebac) at dl-error-skeleton.c:227
#14 0xb7865b11 in _dlerror_run (operate=0xb7865250 , 
args=0xbfffebac) at dlerror.c:170
#15 0xb7865364 in __dlopen (file=0x7bc970 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=4354) at dlopen.c:87
#16 0xad918cc3 in ?? () from /usr/lib/i386-linux-gnu/libva.so.2
#17 0xad919f90 in vaInitialize () from 
/usr/lib/i386-linux-gnu/libva.so.2
#18 0xada1b525 in ?? () from 
/usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
#19 0xada1bfe7 in ?? () from 
/usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
#20 0xada1c3b9 in ?? () from 
/usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
#21 0xada15568 in ?? () from 
/usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
#22 0xb7e4d26e in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#23 0xb7e4f24e in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#24 0xb7e5d0cd in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#25 0xb7e5e05b in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#26 0xb7e5e33e in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#27 0xb7e5fe8e in gst_update_registry () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#28 0xb7df10be in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#29 0xb7c7569b in g_option_context_parse () from 
/usr/lib/i386-linux-gnu/libglib-2.0.so.0
#30 0xb7df1d25 in gst_init_check () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#31 0x0042e5a8 in finch_sound_init () at ././finch/gntsound.c:383
#32 0x004313ed in gnt_ui_init () at ././finch/gntui.c:68
#33 0xb7ac2c29 in purple_core_init () from /usr/lib/libpurple.so.0
#34 0x0040f344 in init_libpurple (argv=0xb634, argc=1) at 
././finch/finch.c:383
#35 gnt_start (argc=, argv=) at 
././finch/finch.c:434
#36 main (argc=, argv=) at 
././finch/finch.c:456
(gdb)

Thanks,
Karsten



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug')
Architecture: i386 (i686)

Kernel: Linux 5.8.0-3-686-pae (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages finch depends on:
ii  libc6  2.31-4
ii  libglib2.0-0   2.66.1-2
ii  libgstreamer1.0-0  1.18.0-3
ii  libncursesw6   6.2+20200918-1
ii  libpurple0 2.13.0-2.2+b1
ii  libtinfo6  6.2+20200918-1
ii  libxml22.9.10+dfsg-6.1
ii  pidgin-data2.13.0-2.2

finch recommends no packages.

Versions of packages finch suggests:
ii  libx11-6  2:1.6.12-1

-- no debconf information

Bug#971515: Request for security team input on kubernetes TC bug

[Sean Whitton]

Hello security team,

The TC are being asked about src:kubernetes, and it would be good to
hear from you about whether and how security support is a relevant
consideration in determining whether the level of vendoring in that
package is acceptable.  Could you take a look at #971515 and perhaps
give us some input, please?

Thanks.

-- 
Sean Whitton

Bug#972636: Transmission: cannot open *.torrent files through 'File>Open' menu

[Pavlos Ponos]

Package: transmission
Version: 3.00-1
Severity: normal
X-Debbugs-Cc: pavlos.po...@gmail.com



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

Hello,

After upgrade to 'testing' I noticed that most of the times *.torrent files 
cannot open through 'File>Open' menu.
What I do to tackle this is going through 'File>Open URL...' and provide the 
URL with the torrent file.


Kernel: Linux 5.8.0-2-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages transmission depends on:
ii  transmission-common  3.00-1
ii  transmission-gtk 3.00-1

transmission recommends no packages.

transmission suggests no packages.

-- no debconf information

Bug#971515: kubernetes: excessive vendoring (private libraries)

[Sean Whitton]

Hello,

On Tue 20 Oct 2020 at 06:52pm -07, Felix Lechner wrote:

>  I think our response to the vendoring explosion is at odds with the
> trends in many languages.
>
> It's time to retool. At the two ends of the solution spectrum, I see
>
> 1. Fully vendored source packages; or
> 2. A packaging system that allows different vendor versions to co-exist.
>
> Either one allows dependent sources to consume whichever versions they
> require, but in my view solution (2) is otherwise superior---provided
> that the packaging process is automated. (A language's build system
> also has to distinguish the installed versions.) For each language so
> affected, could we make (2) our goal, and allow (1) until then?

This is a very general (but of course interesting) topic.  Could I ask
that it be kept out of this TC bug, please?  We have to figure out what
to do about this package given our present tooling.

-- 
Sean Whitton

Bug#971515: kubernetes: excessive vendoring (private libraries)

[Sean Whitton]

Hello Dmitry,

On Wed 21 Oct 2020 at 11:21am +11, Dmitry Smirnov wrote:

> On Wednesday, 21 October 2020 6:16:03 AM AEDT Sean Whitton wrote:
>> I think that my message [1] is what makes you think that the package
>> would not have got through NEW?
>
> It was not your message but my own experience with introducing of 100+ 
> packages through NEW, especially those ones with large burden of vendored 
> libraries, including Kubernetes. The main hassle usually is to convince FTP-
> masters when some vendoring is _necessary_ (case by case) and the usual 
> request is to package all vendored libraries separately. With rare exceptions 
> some (few) vendored libraries are allowed like when a library is a fork, 
> customised for the particular project and therefore not re-usable by other 
> software. Another example is when vendored library is an obsolete software 
> phasing out in future releases. Few micro-libraries might be tolerated when 
> vendored, especially when they are not widely used. Also vendoring might be 
> acceptable when software components with mutual/circular dependencies are 
> shipped in one or several name spaces - in other words when a software code 
> base is not from one name space but from several. None of those cases applies 
> to Kubernetes.
>
> A specific example (libpod/podman) is mentioned in 
>
>   https://lists.debian.org/debian-devel/2020/03/msg00441.html
>
> "Podman was rejected due to "many embedded packages in vendor/" with only
>  6 or 7 private libs versus 120 libraries removed in favour of packaged
>  ones."

Fair enough, but again, this is about NEW as a review by experienced
packagers rather than NEW as a blocker for inclusion.

> If your concern is about security support then IMHO Kubernetes can not be 
> meaningfully supported from security prospective, with or without vendored 
> dependencies.

Fair enough.  In the -devel thread the security team indicated that they
thought they could do security support in the case where there is
vendoring.  It would be good to get more input from them in this bug.

> If Debian only cared about maintainers' convenience or reducing maintainers 
> efforts then Debian would not be what it is now. We favour technical elegance 
> often in expense of maintainers' comfort.

I don't think maintainers' comfort is part of Janos' motivation -- it's
the issue of not having recent Kubernetes in Debian at all.

>> Are there issues the TC should think about which do not fall under this
>> way of looking at things?  I.e., weighing the impact on people other
>> than Janos who want to work on the package, vs. the impact on people who
>> want recent kubernetes to be part in the archive at all?
>
> Is Debian ecosystem of packaged reusable libraries worth caring about?
>
> If so then why grant exception to one particular package? We have several (or 
> more) sophisticated Golang packages using hundreds of packaged libraries.
>
> In the early days of packaging Kubernetes we did not even have most 
> components packaged and I've been spending most effort on packaging, 
> introducing and stabilising dependency libraries.
> These days the major work has already been done and the argument for 
> monolithic vendoring is much weaker.
>
> [...]

I think that we can all agree with everything you've written about the
reasons why packaging components separately is better.  The problem is
that in this case the choice seems to be between not having recent
Kubernetes in Debian at all, or giving up on some of those advantages.

-- 
Sean Whitton

Bug#972635: mdtraj: manual pages contain error messages instead of examples, etc.

[Chris Lamb]

Source: mdtraj
Version: 1.9.4-5
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort we noticed that
mdtraj could not be built reproducibly.

This is because (amongst other reasons) the HTML manual pages
contain error messages. For example:

  `nbconvert --execute` requires the jupyter_client package: `pip install 
jupyter_client`

… which contain HTML links to the absolute build path. This particular
message is due to a missing build-dependency, but there are then
others, such as:

  No such kernel named python3

… which seem like some other, underlying, problem.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#972633: breeze-gtk-theme: Missing border in Whisker menu logout dialog (using arrow keys)

[Arjen Balfoort]

Package: breeze-gtk-theme
Version: 5.19.4-1
Severity: normal
X-Debbugs-Cc: arjenbalfo...@hotmail.com

Dear Maintainer,


   * What led up to the situation?
 In Xfce, open the menu logout dialog (Alt-F4) and use the arrow keys to
navigate the buttons. It is not visible which button is active.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Using another theme (Adwaita or older Xfce themes) the active button is
visible. I also tried to edit /usr/share/themes/Breeze/gtk-3.0/gtk.css but
unfortunately I could not find the code responsible for handling the button
borders for the Whisker menu.

   * What was the outcome of this action?
 I could not solve the issue.

   * What outcome did you expect instead?
 Make active buttons visible while using the arrow keys as if hovering over
the buttons with the mouse cursor.




-- System Information:
Distributor ID: Solydxk
Description:SolydX 10 64-bit
Release:10
Codename:   solydxk-10
Architecture: x86_64

Kernel: Linux 4.19.0-12-amd64 (SMP w/1 CPU thread)
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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages breeze-gtk-theme depends on:
ii  gtk2-engines-pixbuf  2.24.32-3

breeze-gtk-theme recommends no packages.

breeze-gtk-theme suggests no packages.

-- no debconf information

Bug#968416: lintian: Gives ridiculous warning about spelling in overrides file

[Felix Lechner]

Hi IOhannes,

On Wed, Oct 21, 2020 at 5:57 AM IOhannes m zmölnig  wrote:
>
> could you please point to the relevant bug-report?

This feature was requested by Paul Wise on IRC. You can reach him on
OFTC as 'pabs'.

> it's good practice to document the context why this
> is not a spelling error in the first place.

I usually reserve comments for non-obvious matters. Given the low
significance of spelling errors with respect to functionality, it
could also be a case of commentitis.

> i therefore propose to ignore spelling errors in lintian-override files
> if they appear in comments directly before any "spelling-in-*" tag

Thanks for the suggestion! We will have a look.

Kind regards
Felix Lechner

Bug#960769: swt4-gtk FTBFS on 32bit

[Sebastiaan Couwenberg]

Hi Paul,

On Thu, 15 Oct 2020 10:07:28 +0200 Paul Gevers wrote:
> On Mon, 5 Oct 2020 06:30:51 +0200 Sebastiaan Couwenberg wrote:
> > > The binaries for the 32-bit architectures were removed in #962915 [1],
> > > but only for version 4.13.0-1 in unstable. 
> > 
> > This was not sufficient to let it migrate to testing.
> > 
> > The britney output logs a bunch of packages on i386.
> > 
> > i386 & amd64 are the NOBREAKALL_ARCHES in britney.conf, see:
> 
> [Release Team member hat on]: I have added hints to allow the breakage
> on i386 as this was now done on purpose. I've been watching this issue
> since August, but was waiting for all the right binary packages in
> unstable to be removed. This bug at severity serious was preventing
> swt4-gtk from migrating to testing, but as the 32 bit packages were
> removed, this bug should no longer blocking migration, hence I downgrade
> it now.

openjfx is still not migrating to testing, the britney output complains
about several arch:all packages on i386:

 trying: openjfx
skipped: openjfx (1, 0, 30)
got: 91+0: a-1:a-0:a-0:a-0:i-89:m-0:m-0:p-0:s-1
* i386: josm, libafterburner.fx-java, libjavafxsvg-java,
libopenjfx-java, mediathekview, pdfsam, starlink-topcat-java, topcat,
topcat-doc, zeroc-ice-all-runtime, zeroc-ice-utils-java, zeroc-icegridgui

Some more allow-uninst hints are likely needed for the other packages.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#972632: apache2: please provide compression snippet to support brotli (not only deflate)

[Jonas Smedegaard]

Package: apache2
Version: 2.4.46-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

apache2 ships with on-the-fly compression modules deflate and brotli,
but whereas deflate is both enabled and configured by default,
brotli is disabled and lack any default configuration.
Moreover, the default deflate configuration conflicts with brotli.

Brotli compresses to roughly %10 smaller output but is less supported -
currently 94% coverage according to https://caniuse.com/?search=brotli

I think it makes sense to continue shipping with deflate enabled and
configured same as now, but change _how_ that is done and extend to support
both a) shifting to brotli and b) using deflate and brotli concurrently.


Please...:

 1) Move mods-available/deflate.conf to conf-available/compression.conf
(i.e. ship the old file only with a comment about its new location)
 2) Have dpkg enable conf compression, on fresh installs
 3) Have dpkg enable conf compression, on migration from 2.4.46-1 or older

Above should be functionally same setup as now, but with these new
features:

  * enable/disable deflate completely using "a2{en,dis}mod deflate"
  * enable selectively per-vhost by using "a2disconf compression"
and adding "include conf-available/compression.conf" within a vhost

Since mods-available/deflate.conf is a conffile, Users who customized
their deflate config will get notified that they might need to adapt.


Then also, please...:

  4) Have conf compression snippet separate detection from use
 i.e. first set ENABLE_COMPRESSION=DEFLATE, unless already defined
 then use ${ENABLE_COMPRESSION}
  5) extend conf compression snippet to first detect mod_brotli
 i.e. enable that _instead_ of deflate if detected or predefined

I.e. the final conf-available/compression.conf file would contain this:


  
Define TRANSFER_COMPRESSION BROTLI_COMPRESS
  


  
Define TRANSFER_COMPRESSION DEFLATE
  


  
AddOutputFilterByType ${TRANSFER_COMPRESSION} text/html text/plain text/xml 
text/css text/javascript
AddOutputFilterByType ${TRANSFER_COMPRESSION} application/x-javascript 
application/javascript application/ecmascript
AddOutputFilterByType ${TRANSFER_COMPRESSION} application/rss+xml
AddOutputFilterByType ${TRANSFER_COMPRESSION} application/xml
  



All of the above together should support all combinations of
none/custom/brotli/deflate for generally/per-vhost scenarios,
and I believe migrations for existing systems is reasonably graceful
but I will leave the final judgement of that in your hands. :-)


 - Jonas


P.S.

This bugreport only covers compression applied to _transfer_ encoding.
Covering _content_ encoding a.k.a. pre-compressed files is more tricky
because it ties more intimately into the kind of data served.
Notably it ties into setup of mime module which currently has _file_
extension .br linked with brazilian portuguese lanugage which would need
to get fixed first, e.g. to more properly (only!) use extension .pt-br.

It might make sense to extend conf compression snippet with the content
of https://httpd.apache.org/docs/2.4/mod/mod_brotli.html#page-header
but a) I think it would be best to then have it commented out i.e.
provided only as an example, and b) it might be better to try refine
scenarios that are reliable to enable by default (e.g. content below
/usr/share/javascript that we can cover by a policy) and then provide as
a separate conf snippet _not_ commented out and maybe even enabled by
default.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+QRkcACgkQLHwxRsGg
ASGN6w/9EmEXUsdQQ8JBmhnRPIiE2fn0DzLh5WQvQhiiirzy7ngSQrVcHhN2/v2o
TBGQrjr/n4uyqMsgdR6llSR4y8Ed7V0r+ECmIPEjR5NXAt9avgRv37WhBtH/r5Bf
2EYW5LHFAqIPSqQAlNBtembUMFafLA8RBcIG9Otl0S1KYzVKKjcRsNWv3NwZExNp
CPe/fHwZ1L+VJY+oKG4d1GVYZyyY+YVxfmtfzwGfcrgN7ncghAgARyTAYj7DneCa
GuOiGqj8X1IihZ4rokQ6AfV2aFxhPIZwts1VYbBP2/o34udLHKM/XWIEBPScY7Gs
5PCyt3JIb/VtzNYW5xLItZolwDqOkro1rbrlcPZwmJHGXF4cuqrvau9WzRXCpk+b
1gEy4rPS8hc1GdISA2Fx5ueWckLYrqQYqFzUgb8pKqtd0pKEofnkNJu1QVSVMhvJ
obSW2DGNgSUBMRxTqk/FYBngX4KWV+GcflWDkgdvjWV+gSNvAIx/iFbOhmgvNFMW
9v0PH5hThUtvV5OmVrIFTpXD/6x7JCU/Pd6cJoiT7wY0scF6VEgkGqKjEhziJIJw
/3iuFsGgIzC9hAFh7EvzYXD7Ucc7WjiPeurTzzwT0Ypu86FyVLxhyMEEZzfwrC3i
Ft7k+XjXzgiourUVFkF+Y2wLYXeJLjzm+elUMIvDadvZsRUINbE=
=6F6H
-END PGP SIGNATURE-

Bug#952262: psgml: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Alberto Garcia]

Control: tags -1 patch pending

On Wed, Oct 21, 2020 at 04:10:41PM +0200, Alberto Garcia wrote:
> I confirm that the patch attached by Claudio Saavedra fixes the bug so
> I'll prepare an NMU (debdiff attached).

Uploaded to DELAYED/5

Berto

Bug#972631: node-proxy: please make the build reproducible

[Chris Lamb]

Source: node-proxy
Version: 1.0.2-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
node-proxy could not be built reproducibly.

This is because it installs a file without processing them using
dh_fixperms.

Patch attached that replaces the exclude with an explicit call to
chmod +x for this particular file instead.

 [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/rules  2020-10-21 15:18:08.191583335 +0100
--- b/debian/rules  2020-10-21 15:20:22.388529788 +0100
@@ -4,4 +4,5 @@
dh $@ --with nodejs
 
 override_dh_fixperms:
-   dh_fixperms --exclude bin/proxy.js
+   dh_fixperms
+   find debian -path '*/bin/proxy.js' -print0 | xargs -0r chmod +x

Bug#972627: Minimal reproducible example

[Benjamin Eikel]

Package: googletest
Version: 1.10.0.20201018-1
Followup-For: Bug #972627

Here is a minimal example that can be used to reproduce the problem:

test.cpp
```
#include 
#include 

#include 

class MyMock {
public:
MOCK_METHOD(void, testPrint, (std::string_view));
};

TEST(Test, test)
{
constexpr std::string_view param{"test"};
MyMock mock;
EXPECT_CALL(mock, testPrint(param))
.Times(1);
}
```

Building with `g++ -std=c++20 test.cpp -lgmock_main -lgmock -lgtest -pthread`
and version 1.10.0.20201018-1 leads to:

```
/usr/bin/ld: /tmp/ccgTGXuD.o: in function `Test_test_Test::TestBody()':
test.cpp:(.text+0x68): undefined reference to 
`testing::Matcher > 
>::Matcher(std::basic_string_view >)'
collect2: error: ld returned 1 exit status
```

Using the same command, but version 1.10.0-3 works.

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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

-- no debconf information

Bug#960742: RFS: lazpaint/6.4.1-1 [ITP] -- Graphics viewer and editor

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #960742
Control: tags -1 -wontfix +moreinfo

Hi Johann

thanks for you working on the package and the progress on it!

FTR, the hard work is done here: 
https://github.com/bgrabitmap/lazpaint/issues/18

(Because of the progress, I'm removing the wontfix tag and replace it with the 
moreinfo;
as per sponsorship conventions this means that the package still needs work)

Thanks Gürkan for helping out, very much appreciated; Once Gürkan is happy with
the package, let me know and I'll take a look.

Cheers,
-- 
tobi

Bug#952262: psgml: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Alberto Garcia]

On Sun, Feb 23, 2020 at 02:22:05PM +0100, Lucas Nussbaum wrote:
> Source: psgml
> Version: 1.4.0-7.1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This bug has been open for almost a year and the package was removed
from testing 7 months go because of it.

I confirm that the patch attached by Claudio Saavedra fixes the bug so
I'll prepare an NMU (debdiff attached).

Berto
diff -u psgml-1.4.0/debian/changelog psgml-1.4.0/debian/changelog
--- psgml-1.4.0/debian/changelog
+++ psgml-1.4.0/debian/changelog
@@ -1,3 +1,11 @@
+psgml (1.4.0-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS due to malformed UTF-8 character (Closes: #952262):
+  - Applied patch for psgml.texi; thanks Claudio Saavedra.
+
+ -- Alberto Garcia   Wed, 21 Oct 2020 16:02:11 +0200
+
 psgml (1.4.0-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u psgml-1.4.0/psgml.texi psgml-1.4.0/psgml.texi
--- psgml-1.4.0/psgml.texi
+++ psgml-1.4.0/psgml.texi
@@ -1572,7 +1572,7 @@
 
 Set the variable @code{sgml-display-char-list-filename} to a file that
 contains mappings between all characters present in the presentation
-character set, and their "standard replacement text" names, e.g. "å"
+character set, and their "standard replacement text" names, e.g. "@U{00e5}"
 -> "[aring ]", e.t.c.
 
 The default value for this variable is `iso88591.map'. 

Bug#972559: perl: please make the build mostly reproducible

[Chris Lamb]

Hi Niko,

> Thanks! For some reason I thought this was a wider issue than
> just those files.

No problem. As far as I can tell, the build path issue is limited to
just these files, but as you later allude to, there are still the
usrmerge-related variations (#914128).

> I'm uneasy with using $(CURDIR) as a regexp in sed.  Similar usage in the
> past led to #585678. Given '+' is not special in sed regexps, this is not
> quite as bad, but still not ideal.

An excellent point. A few moments on codesearch.debian.net suggests
that using sed with CURDIR (what is, after all, untrusted input to
some degree) is a fairly common occurrence. I had yet to see an
instance of it causing problems until I saw #585678, however. I have
filed a wishlist bug against Lintian (#972629) as most of these should
straightforward to detect.

An option is to say
>   $(PERL_TO_USE) -pi -e 's/\Q$(CURDIR)\E/.../'
> like we do elsewhere in the rules already.

Good idea, and I've attached an updated patch for completeness.

Looking forward to seeing this land in the archive.


Best wishes,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   ` a/debian/rules  2020-10-15 11:05:15.531617632 +0100
--- b/debian/rules  2020-10-21 12:50:16.231618188 +0100
@@ -154,6 +154,7 @@
# store probed configuration to support cross builds
for flavour in $(flavours); do \
  install -D -m 644 build-$$flavour/config.sh 
$(configdata)/config.sh.$$flavour; \
+ $(PERL_TO_USE) -pi -e 's@\Q$(CURDIR)\E@/dummy/build/dir@g' 
$(configdata)/config.sh.$$flavour; \
  gzip -n $(configdata)/config.sh.$$flavour; \
done
 
@@ -208,6 +209,11 @@
# fix up generated headers
$(PERL_TO_USE) debian/fixheaders $(tmp)/$(lib)
 
+   # remove references to the build directory in some files
+   find $(tmp) \
+ -path '*/CORE/config.h' -or -path '*/Config_heavy.pl' | \
+   xargs -tr $(PERL_TO_USE) -pi -e 's@\Q$(CURDIR)\E@/dummy/build/dir@g'
+
 ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
# Verify that the headers are usable
for ph in `< debian/headers sed -e 's/\.h$$/.ph/'`; do \

Bug#972629: lintian: Detect sed -e 's@$(CURDIR)@...@' in debian/rules

[Chris Lamb]

Package: lintian
Version: 2.98.0
Severity: wishlist

Hi,

The debian/rules snippet:

  sed -ie 's@$(CURDIR)@...@' target

… initially appears to be harmless. However, $(CURDIR) can contain
regular expression metacharacters (specifically, the '+' character)
which can affect exactly what it can match.

In some cases, this has led to silently broken builds (#585678). We
should be able to detect most instances of this (there are many on
codesearch.debian.net), possibly suggesting the following replacement:

  perl -pi -e 's@\Q$(CURDIR)\E@...@' target

Variants such as $(shell pwd) should probably be checked for too.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#972630: kde-systemsettings-tree.py: is incompatible with python 3

[r.ductor]

Package: kdesdk-scripts
Version: 4:20.08.0-1
Severity: minor

Dear Maintainer,

aptitude full-upgrade resulted in the following (non stopping) SyntaxError:

Setting up kdesdk-scripts (4:20.08.0-1) ...
Failed to byte-compile /usr/bin/kde-systemsettings-tree.py:   File 
"/usr/bin/kde-systemsettings-tree.py", line 50
print "*** Current organization:"
  ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("*** 
Current organization:")?

guess python3 is invoked instead of python2.

Regards
ric


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

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 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 kdesdk-scripts depends on:
ii  perl   5.30.3-4
ii  pkg-kde-tools  0.15.32
ii  python33.8.2-3

Versions of packages kdesdk-scripts recommends:
ii  advancecomp  2.1-2.1
ii  gawk 1:5.0.1+dfsg-1
ii  optipng  0.7.7-1+b1
ii  subversion   1.14.0-2+b1

Versions of packages kdesdk-scripts suggests:
ii  cvs  2:1.12.13+real-27+b2
pn  devscripts   
pn  dmalloc  
ii  gdb  9.2-1
ii  khelpcenter  4:20.04.2-1
ii  valgrind 1:3.16.1-1
pn  xsltproc 

-- no debconf information

Bug#972628: python3-mysqldb: backporting python3-mysqldb not to break backported python3-django

[Salman Mohammadi]

Package: python3-mysqldb
Version: 1.3.10-2
Severity: wishlist

Dear Maintainer(s),

I would kindly ask if it is possible to backport python3-mysqldb from
Bullseye to Buster-backports not break the backported python3-django.

The backported version of python3-django has this line

Breaks: ... , python3-mysqldb (<< 1.3.13)

which could be solved by backporting python3-mysqldb.

Regards,
Salman

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

Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-mysqldb depends on:
ii libc6 2.28-10
ii libmariadb3 1:10.3.25-0+deb10u1
ii libssl1.1 1.1.1d-0+deb10u3
ii python3 3.7.3-1
ii zlib1g 1:1.2.11.dfsg-1

python3-mysqldb recommends no packages.

Versions of packages python3-mysqldb suggests:
pn default-mysql-server | virtual-mysql-server 
pn python-egenix-mxdatetime 
pn python3-mysqldb-dbg 

-- no debconf information

Bug#972627: Upgrade to 1.10.0.20201018-1 leads to undefined references to testing::Matcher::Matcher(std::string_view)

[Benjamin Eikel]

Package: googletest
Version: 1.10.0.20201018-1
Severity: important

After installing the new snapshot version (#970943 points to the new upstream
release scheme), linking my tests fails with a lot of

```
undefined reference to `testing::Matcher > >::Matcher(std::basic_string_view >)'
```

Downgrading googletest, libgmock-dev, and libgtest-dev to 1.10.0-3 fixes the
problem and makes my tests build successfully.

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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

-- no debconf information

Bug#972626: python3-mysqldb: backporting python3-mysqldb not to break backported python3-django

[Salman Mohammadi]

Package: python3-mysqldb
Version: 1.3.10-2
Severity: wishlist

Dear Maintainer(s),

I would kindly ask if it is possible to backport python3-mysqldb from
Bullseye to Buster-backports not break the backported python3-django.

The backported version of python3-django has this line

Breaks: ... , python3-mysqldb (<< 1.3.13)

which could be solved by backporting python3-mysqldb.

Regards,
Salman

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

Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-mysqldb depends on:
ii libc6 2.28-10
ii libmariadb3 1:10.3.25-0+deb10u1
ii libssl1.1 1.1.1d-0+deb10u3
ii python3 3.7.3-1
ii zlib1g 1:1.2.11.dfsg-1

python3-mysqldb recommends no packages.

Versions of packages python3-mysqldb suggests:
pn default-mysql-server | virtual-mysql-server 
pn python-egenix-mxdatetime 
pn python3-mysqldb-dbg 

-- no debconf information

Bug#952262: psgml: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Claudio Saavedra]

Attached is a patch that fixes the build for the texi doc file.
Claudio
--- psgml.texi.orig	2020-10-21 16:44:04.683099515 +0300
+++ psgml.texi	2020-10-21 16:43:52.734915699 +0300
@@ -1572,7 +1572,7 @@ Default: @code{t}.
 
 Set the variable @code{sgml-display-char-list-filename} to a file that
 contains mappings between all characters present in the presentation
-character set, and their "standard replacement text" names, e.g. "å"
+character set, and their "standard replacement text" names, e.g. "@U{00e5}"
 -> "[aring ]", e.t.c.
 
 The default value for this variable is `iso88591.map'. 

Bug#972625: RFS: apvlv/0.1.5+dfsg-4 [QA] [RC] -- PDF viewer with Vim-like behaviour

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: apvlv
   Version : 0.1.5+dfsg-4
   Upstream Author : [fill in name and email of upstream]
 * URL : http://naihe2010.github.io/apvlv/
 * License : LGPL-3 or CC-BY-SA-3.0, GPL-2+
 * Vcs : https://salsa.debian.org/debian/apvlv
   Section : text

It builds those binary packages:

  apvlv - PDF viewer with Vim-like behaviour

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/apvlv/apvlv_0.1.5+dfsg-4.dsc

Changes since the last upload:

 apvlv (0.1.5+dfsg-4) unstable; urgency=medium
 .
   * QA upload.
   * Using new DH level format. Consequently:
   - debian/compat: removed.
   - debian/control: changed from 'debhelper' to 'debhelper-compat' in
 Build-Depends field and bumped level to 13.
   - debian/rules: removed unnecessary --parallel dh argument.
   * debian/control:
   - Added Rules-Requires-Root: no.
   - Bumped Standards-Version to 4.5.0.
   - Updated Vcs-* fields in source stanza to Salsa.
   * debian/gbp.conf: removed.
   * debian/patches/:
   - Renamed ftbfs-gcc-7.patch to 0007-ftbfs-gcc-7.patch for consistency
 with patches index numbering.
   - 0007-ftbfs-gcc-7.patch: added header fields Description, Author,
 Bug-Debian and Last-Update.
   - 0008-fix-ftbfs-gtypes.patch: added to fix FTBFS. (Closes: #971102)
   - series: updated for 0007-ftbfs-gcc-7.patch.
   * debian/upstream/metadata: added Changelog, Homepage and Repository fields.
   * debian/salsa-ci.yml:
   - Added to provide CI tests for Salsa.
   - Allow reprotest to fail in Salsa.

Regards,
-- 
⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich
⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683
⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄  GPG:rsa4096/7EF63B2E



signature.asc
Description: OpenPGP digital signature

Bug#972437: debian-reference: mentions no longer existing packages

[Holger Wansing]

Hi,

Am Mittwoch, 21. Oktober 2020 schrieb xiao sheng wen (肖盛文): 
> One experienced user can know the way of that install old package from 
> oldstable,
> 
> but he perhaps didn't  know  the package ldm.

[...]

> > And there is no need for such logic: if you want to find how the situation
> > was for an old Debian release, you can always look in an old version of
> > the debian-reference. It's always there.
> 
> There is only one version of the debian-reference in d.o now.
> 
> If split it for different target releases (stable, testing) in d.o, 
> perhaps is a better way, I'm not sure.

We talk about experienced users here, but if such users are unable
to find old versions of the debian-reference in the archive, they  should
better not mix up stable and oldstable (and therefore risk to break
the next dist-upgrade and similar), since they are *not* experienced users, 
but - ok, I will stop that here.

Holger 

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#972592: mdtraj non-amd64

[Drew Parsons]

On 2020-10-21 20:56, Adrian Bunk wrote:

On Wed, Oct 21, 2020 at 06:43:56PM +0800, Drew Parsons wrote:


I see. Would the i386 issue be the cause of the segfault in
test_image_molecules?

https://ci.debian.net/data/autopkgtest/testing/i386/m/mdtraj/7659912/log.gz

...


Doesn't look SSE related at first sight.

Is anyone else using this code on 32bit?



Anaconda provides a version for win-32.  I can't locate other i386 
builds though.

Bug#972624: ITP: metkit -- Meterological tookit implementing the MARS language

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: metkit
  Version : 1.6.0
  Upstream Author : European Centre for Medium-Range Weather Forecasts
* URL : http://github.com/ecmwf/metkit
* License : Apache-2
  Programming Lang: C++, Fortran
  Description : Meterological tookit implementing the MARS language

 MetKit is a toolkit from ECMWF for manipulating and describing meteorological
 objects, implementing the MARS language and associated processing and 
semantics.
 MARS is the Meteorological Archive Retrieval System from ECMWF.
 
 libmetkit and its functionality are currently provided by the older "ODB-API"
 package in Debian, but this is being withdrawn and the metkit library (used
 optionally by other tools, eg Metview, in Debian) is being packaged separately.
 

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Paul Wise]

Control: found -1 82.0-1

FTR I am still experiencing this with the latest release.

Steps to reproduce (quit after 10s each time Firefox starts):

mkdir tmp-firefox-profile
firefox -no-remote -profile tmp-firefox-profile
firefox -no-remote -profile tmp-firefox-profile
firefox -no-remote -profile tmp-firefox-profile
firefox -no-remote -profile tmp-firefox-profile
firefox -no-remote -profile tmp-firefox-profile

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#972605: jekyll: Please update to new 4.x branch

[Daniel Leidert]

Am Dienstag, den 20.10.2020, 23:33 -0400 schrieb Calum McConnell:

> Jekyll upstream has been concentrating on a new 4.x release branch for the
> past year.  It provides a significant set of new features that I use, and it
> would be great if it could be included in debian.
> 
> I assume you know all of that already, since 3.9 released after 4.0, but I
> was wondering what the rationale was for sticking with the 3.x branch.

It is very stable and well tested. Also not all plugins had been ported to
Jekyll 4 at the beginning of the year (not sure about the current state).
Further it would make backporting to current stable a lot more complicated.

I'm not aware of any ground-breaking changes. What features are you referring
to?

The 4.x series will be uploaded to experimental eventually. But I'm hesitant to
upload it to unstable just now.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

Bug#972623: Security fixes from the October 2020 CPU

[Lars Tangvald]

Source: mysql-8.0
Version: 8.0.21
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2020 lists CVEs affecting 
MySQL 8.0

that are fixed in 8.0.22

CVE list:

    - CVE-2020-14672 CVE-2020-14765 CVE-2020-14769 CVE-2020-14771
    - CVE-2020-14773 CVE-2020-14775 CVE-2020-14776 CVE-2020-14777
    - CVE-2020-14785 CVE-2020-14786 CVE-2020-14789 CVE-2020-14790
    - CVE-2020-14791 CVE-2020-14793 CVE-2020-14794 CVE-2020-14799
    - CVE-2020-14800 CVE-2020-14804 CVE-2020-14809 CVE-2020-14812
    - CVE-2020-14814 CVE-2020-14821 CVE-2020-14827 CVE-2020-14828
    - CVE-2020-14829 CVE-2020-14830 CVE-2020-14836 CVE-2020-14837
    - CVE-2020-14838 CVE-2020-14839 CVE-2020-14844 CVE-2020-14845
    - CVE-2020-14846 CVE-2020-14848 CVE-2020-14852 CVE-2020-14860
    - CVE-2020-14861 CVE-2020-14866 CVE-2020-14867 CVE-2020-14868
    - CVE-2020-14869 CVE-2020-14870 CVE-2020-14873 CVE-2020-14878
    - CVE-2020-14888 CVE-2020-14891 CVE-2020-14893

Ref: https://www.oracle.com/security-alerts/cpuoct2020.html#AppendixMSQL

Regards,

Lars Tangvald

Bug#968335: kernel crash: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120

[debian-968335]

Unfortunately I'm not 100% convinced yet.

I suffered from hangs with the 4.19.0-10 kernel; on 4.19.0-11 I got at 
least a similar warning message on screen (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968335#27), and last 
saturday I also got a completely hanging system - without any feedback 
in either kern.log, syslog or even on screen. Not responding to 
keyboard. Only similarity I see is that syslog contains a bunch of 
0-bytes at the time of the incident.


While I didn't get anything indicating that this is the same issue as 
before, I'm not convinced that the issue is resolved.


But, I also got a new kernel version (4.19.0-12) today - let's see if 
this one is more stable.


Regards,
Matthijs

Bug#972592: closed by Debian FTP Masters (reply to Drew Parsons ) (Bug#972592: fixed in mdtraj 1.9.4-6)

[Adrian Bunk]

On Wed, Oct 21, 2020 at 06:43:56PM +0800, Drew Parsons wrote:
> On 2020-10-21 18:29, Adrian Bunk wrote:
> > On Wed, Oct 21, 2020 at 10:21:10AM +, Debian Bug Tracking System
> > wrote:
> > > ...
> > >  mdtraj (1.9.4-6) unstable; urgency=medium
> > >  .
> > >* debian patch check_sse2.patch checks if system supports SSE2
> > >  (i.e. if system is x86 or amd64) before compiling with -msse2.
> > >  Closes: #972592.
> > > ...
> > 
> > Unfortunately this does not work for two reasons:
> > 
> > 1. The i386 architecture and all buildds do support SSE2,
> >but using it without runtime check is a baseline violation.
> > 2. The software does use handwritten SSE, which won't compile
> >on non-x86 architectures (the arm64 support in upstream
> >master adds an alternative NEON implementation).
> 
> 
> I see. Would the i386 issue be the cause of the segfault in
> test_image_molecules?
> 
> https://ci.debian.net/data/autopkgtest/testing/i386/m/mdtraj/7659912/log.gz
> 
> tests/test_trajectory.py::test_smooth PASSED [
> 90%]
> tests/test_trajectory.py::test_image_molecules bash: line 1:  4754
> Segmentation fault  bash -ec 'pytest-3' 2> >(tee -a
> /tmp/autopkgtest-lxc.1gyatnly/downtmp/command1-stderr >&2) > >(tee -a
> /tmp/autopkgtest-lxc.1gyatnly/downtmp/command1-stdout)

Doesn't look SSE related at first sight.

Is anyone else using this code on 32bit?

cu
Adrian

Bug#968416: lintian: Gives ridiculous warning about spelling in overrides file

[Debian GNU|Linux]

On Fri, 14 Aug 2020 19:27:46 -0700 Felix Lechner 
 wrote:

> And BTW. are you going
> to check spelling of comments in source code files as well? I'm pretty
> sure you can find a lot of spelling typos there...


> I am sorry but we do not plan to implement your suggestion. You may be
> correct that there are lots of typos in code comments but that task is
> too complicated for us.

i think this was a tongue-in-cheek comment:
lintian doesn't do spell-checking in comments, and i think that's fine.
i (guess i) agree with robert, that lintian shouldn't do spell-checking 
in comments of lintian-override files either.



>
> > what's the point of checking spelling there?
>
> Like most of our tags, this one is based on user suggestions.

could you please point to the relevant bug-report?
i think it is great that lintian does spell-checking.
inevitably it will find false-positives (that's to be expected).
in this case, i think the sensible thing for maintainers is to override 
the false-positive it's good practice to document the context why this 
is not a spelling error in the first place.

in many cases, this will re-produce the false-positive in the comment.
which makes it all a bit tautological.
(if i override the "spelling-in-override-comment" tag, will it trigger 
another warning?)



i therefore propose to ignore spelling errors in lintian-override files 
if they appear in comments directly before any "spelling-in-*" tag in 
the overrides file.


fgmndasr
IOhannes

Bug#972622: ITP: leafletbs -- Firm/Middleware for Consolinno Energy Leaflet (EMS)

[Alex]

Package: wnpp
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
   We want to be able to publish our firm/middleware (GPL)
* 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 ***

Bug#972621: orca: Missing dependency on xkbset

[Colomban Wendling]

Package: orca
Version: 3.38.0-1
Severity: normal

Dear Maintainer,

Orca since 3.37.2 will optionally use xkbset to query the Sticky-Keys
state and follow suite with its own keybindings if active.

For this to work, it depends on calling the `xkbset` utility, thus a
dependency (a Recommends maybe?) would be needed for this feature to
work out of the box.

Regards,
Colomban

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

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

Versions of packages orca depends on:
ii  gir1.2-glib-2.01.66.0-1
ii  gir1.2-gstreamer-1.0   1.18.0-3
ii  gir1.2-gtk-3.0 3.24.23-1
ii  gir1.2-pango-1.0   1.46.1-1
ii  gir1.2-wnck-3.03.36.0-1
ii  gsettings-desktop-schemas  3.38.0-2
ii  gstreamer1.0-plugins-good  1.18.0-1
ii  python33.8.2-3
ii  python3-brlapi 6.0+dfsg-6
ii  python3-cairo  1.16.2-4
ii  python3-gi 3.38.0-1
ii  python3-louis  3.15.0-1
ii  python3-pyatspi2.38.0-1
ii  python3-speechd0.10.1-2
ii  speech-dispatcher  0.10.1-2

Versions of packages orca recommends:
ii  xbrlapi  6.0+dfsg-6

orca suggests no packages.

-- no debconf information

Bug#972593: RFS: filezilla/3.51.0-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Gianfranco Costamagna]

.






Il martedì 20 ottobre 2020, 22:57:30 CEST, Philip Wyett 
 ha scritto: 





Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name    : filezilla
  Version        : 3.51.0-1
  Upstream Author : Tim Kosse 
* URL            : https://filezilla-project.org/
* License        : GPL-2+, BSD-like, permissive, MIT, CC0-1.0
* Vcs            : https://salsa.debian.org/debian/filezilla
  Section        : net

It builds those binary packages:

  filezilla-common - Architecture independent files for filezilla
  filezilla - Full-featured graphical FTP/FTPS/SFTP client

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.51.0-1.dsc

Changes since the last upload:

filezilla (3.51.0-1) unstable; urgency=medium
.
  * Team upload
  * New upstream version 3.51.0
  * Updated libfilezilla-dev versioned build-dep to 0.25.0

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B

signature.asc
Description: PGP signature

Bug#972591: RFS: libfilezilla/0.25.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Gianfranco Costamagna]

.






Il martedì 20 ottobre 2020, 22:45:27 CEST, Philip Wyett 
 ha scritto: 





Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name    : libfilezilla
  Version        : 0.25.0-1
  Upstream Author : Tim Kosse 
* URL            : https://lib.filezilla-project.org/
* License        : GPL-2+
* Vcs            : https://salsa.debian.org/debian/libfilezilla
  Section        : libs

It builds those binary packages:

  libfilezilla0 - build high-performing platform-independent programs
(runtime lib)
  libfilezilla-dev - build high-performing platform-independent
programs (development)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.25.0-1.dsc

Changes since the last upload:

libfilezilla (0.25.0-1) unstable; urgency=medium
.
  * Team upload
  * New upstream version 0.25.0

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


signature.asc
Description: PGP signature

Bug#972228: buster version seems not affected

[Xavier]

Hi,

looking at upstream patch [1], it seems that iotjs 1.0-1 isn't affected
by this security issue: there is no `(*(++stack_top_p))` anywhere.

Cheers,
Xavier

[1]: https://github.com/jerryscript-project/jerryscript/pull/3867/files

Bug#972613: [Pkg-kde-extras] Bug#972613: Bug#972613: Bug#972613: Bug#972613: Bug#972613: ktimetracker FTBFS on 32bit: test failures

[Pino Toscano]

In data mercoledì 21 ottobre 2020 13:59:46 CEST, Adrian Bunk ha scritto:
> On Wed, Oct 21, 2020 at 12:47:31PM +0200, Pino Toscano wrote:
> >...
> > Again, Adrian: please be *patient*, and do *not* rush bug reports like
> > that. Your impatience does *not* help.
> 
> Neither does it help when you are trying to make other peoples work 
> harder.

Your attitude and your impatience are, actually.

> Feel free to ask the Debian Technical Committee if you want general bug 
> reporting restrictions. I do consider this topic closed, and emails from 
> you will no longer reach my INBOX.

Cooperative as usual: not even trying to listen to what other people
tell you. Good job.

-- 
Pino Toscano

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

Bug#972613: [Pkg-kde-extras] Bug#972613: Bug#972613: Bug#972613: Bug#972613: ktimetracker FTBFS on 32bit: test failures

[Adrian Bunk]

On Wed, Oct 21, 2020 at 12:47:31PM +0200, Pino Toscano wrote:
>...
> Again, Adrian: please be *patient*, and do *not* rush bug reports like
> that. Your impatience does *not* help.

Neither does it help when you are trying to make other peoples work 
harder.

Feel free to ask the Debian Technical Committee if you want general bug 
reporting restrictions. I do consider this topic closed, and emails from 
you will no longer reach my INBOX.

cu
Adrian

Bug#972620: building OpenCL kernels fails with error: unknown argument: '-dwarf-column-info'

[Giuseppe Bilotta]

Package: intel-opencl-icd
Version: 20.37.17906-1
Severity: important

Hello,

it seems that the last upgrade has broken the compilation of OpenCL
kernels, resulting in the error

   unknown argument: '-dwarf-column-info'

and thus preventing use of the Intel iGP as compute device.

The error is illustrated even by simply running `clinfo`, optionally directing
stdout to /dev/null so that only the error is visible (on stderr).

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/12 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages intel-opencl-icd depends on:
ii  libc6   2.31-4
ii  libgcc-s1   10.2.0-15
ii  libigc1 1.0.5186-1
ii  libigdfcl1  1.0.5064-2
ii  libigdgmm11 20.3.2+ds1-1
ii  libstdc++6  10.2.0-15
ii  ocl-icd-libopencl1  2.2.12-4

intel-opencl-icd recommends no packages.

intel-opencl-icd suggests no packages.

-- no debconf information

Bug#972601: application tracking broken in GNOME Shell

[Michael Biebl]

Am 21.10.2020 um 12:41 schrieb Carsten Schoenert:
> Hello Michael,
> 
> Am 21.10.20 um 00:43 schrieb Michael Biebl:
>> I notice the following:
>>
>> # grep StartupWMClass
>> /usr/share/applications/net.thunderbird.Thunderbird.desktop
>> StartupWMClass=Thunderbird
>>
>> So, either change that to StartupWMClass=thunderbird or update
>> thunderbird to report Thunderbird as StartupWMClass X property.
> 
> you are the first person that is digging into these parts and also
> provide helpful hints. Thanks for this!
> 
> Some rationale for the reason behind the renamed desktop file.
> 
> Upstream decided to support the AppStream standard and introduced some
> time ago an *appdata.xml file named
> 
>   net.thunderbird.Thunderbird.appdata.xml
> 
> This file is lacking an entry for  as
> upstream isn't shipping an .desktop file yet.
> The .desktop file we use in Debian is the same as Ubuntu is shipping, in
> fact I picked some parts from Ubuntu long ago to get these quite the same.
> 
> I plan to bring the .desktop file into upstream so all Linux distros
> could participate from that and we get some unifying into that. There is
> some more work on translations to do.
> 
> As currently seen this will not work for now without some fallout. :/
> 
> The appdata file for example is currently using 'Thunderbird' with the
> upper case letter 'T' that is chosen unfortunate.
> 
> The issue that of course some manual added new menu entry within the
> GNOME quickstarter is currently not working any longer after my last
> modification did unfortunately come to my attention *after* I've
> uploaded 1:78.3.3-1.
> 
> But your hint about adjusting StartupWMClass should help to solve this
> all together.
> 
> Depending on available time I'm considering to revert the modification
> on this until I can rework it properly. If you want and can provide some
> patches I'm happy to apply them.
> 
> Currently I see the following steps.
> 
> 1. Rename net.thunderbird.Thunderbird.appdata.xml to
>net.thunderbird.thunderbird.appdata.xml

I don't really know anything about AppDate and if that file requires any
changes. So I can't really comment on that, especially the naming of the
file.

> 2. Adjust StartupWMClass to 'thunderbird' in
>net.thunderbird.Thunderbird.desktop
> 
> Do I (still) miss something here?

You can do that or as said change thunderbird to set the WM_CLASS
property to uppercase Thunderbird or net.thunderbird.Thunderbird (in the
latter case, you don't need StartupWMClass in your desktop file).
So it depends on which approach you/upstream prefers.

Regards,
Michael



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



signature.asc
Description: OpenPGP digital signature

Bug#972608: The case of node-rollup-plugins

[Julien Puydt]

Hi,

for node-rollup-plugins, if I understand well, each subproject is made
into a src: ; that's also a possibility for other monorepo projects,
but that is quite unwieldy, especially when there are many subprojects
(for lumino, 18 packages and 1 [working] example makes 19
subprojects!).

Cheers,

JP

Bug#951854: fixed in muchsync 5-2

[Rémi Vanicat]

Le 19 octobre 2020, Michael Biebl a écrit:

> Am 19.10.20 um 22:40 schrieb Michael Biebl:
>> See
>> http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html
>
> See also https://salsa.debian.org/ftp-team/website/-/merge_requests/6
>

Thanks. I've reverted the patch, and upload the brand new upstream
version at the same time.


-- 
Rémi Vanicat