Bug#990844: libtheora: reproducible builds: Embedded timestamps in PDF file

[Vagrant Cascadian]

Source: libtheora
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in /usr/share/doc/libtheora-dev/Theora.pdf.gz:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/libtheora.html

  June·15,·2021
  vs.
  July·19,·2022

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/


With this patch and the recently submitted patch removing
examples/Makefile, libtheora should build reproducibly on
tests.reproducible-builds.org


Thanks for maintaining libtheora!


live well,
  vagrant
From 8d3b41850e12792aefed8ea8da6d51e8792abe68 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 9 Jul 2021 05:37:35 +
Subject: [PATCH 1/2] debian/rules: Set FORCE_SOURCE_DATE=1 in order for
 texlive to respect SOURCE_DATE_EPOCH when generating PDF.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 874cf23..c9de1d0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,9 @@ CONFIG_SHELL = /bin/sh
 export CONFIG_SHELL
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@
 
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#990843: libtheora: reproducible-builds: Example Makefile embeds build paths and binary paths

[Vagrant Cascadian]

Source: libtheora
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path and several binary paths are embedded in example Makefile
shipped in the package:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libtheora.html

  ./usr/share/doc/libtheora-dev/examples/Makefile

  ACLOCAL·=·${SHELL}·'/build/1st/libtheora-1.1.1+dfsg.1/missing'·aclocal-1.16
  vs.
  ACLOCAL·=·${SHELL}·'/build/2/libtheora-1.1.1+dfsg.1/2nd/missing'·aclocal-1.16

  GREP·=·/bin/grep  
  vs.
  GREP·=·/usr/bin/grep

Since these values may differ with the installed system, in order to use
the example Makefile, a person would have to regenerate it from
Makefile.am, which is also provided.

The attached patch adjusts debian/libtheora-doc.examples to only install
Makefile.am.


If that is somehow not an option, an alternate option would be to
sanitize the Makefiles stripping the build path (or replacing with
/usr/src?), and possibly passing various variables to configure
(e.g. GREP=/bin/grep, SHELL=/bin/sh, ...).


Thanks for maintaining libtheora!


live well,
  vagrant
From 680fb3e29c50fb59deb1151a850f657532b59f3f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 9 Jul 2021 05:39:06 +
Subject: [PATCH 2/2] Do not install example Makefile.

The build path and several binary paths are embedded in a Makefile
shipped in the package.

Since these values may differ with the installed system, in order to
use the example Makefile, a person would have to regenerate it from
Makefile.am, which is included in the package.
---
 debian/libtheora-doc.examples | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/libtheora-doc.examples b/debian/libtheora-doc.examples
index 7846b89..a6371a7 100644
--- a/debian/libtheora-doc.examples
+++ b/debian/libtheora-doc.examples
@@ -1,4 +1,3 @@
 examples/*.c
 examples/*.h
 examples/*.am
-examples/Makefile
-- 
2.32.0



signature.asc
Description: PGP signature

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

[Otto Kekäläinen]

On Wed, Jul 7, 2021 at 6:37 AM Andreas Beckmann  wrote:
>
> On 06/07/2021 01.25, Otto Kekäläinen wrote:
> > Thanks Andreas for testing potential changes!
>
> So far this looks good, I see no more cases of default-mysql-server
> being held at the buster version (and thus mariadb-server-10.3 instead
> of mariadb-server-10.5 being installed).
>
> > If you file them as MRs at
> > https://salsa.debian.org/mariadb-team/galera-4 and
> > https://salsa.debian.org/mariadb-team/mariadb-10.5 you'll get the
> > additional CI testing run on top of the for free for extra validation.
>
> you can find a 990708 branch in both repositories

Thanks! I am currently working on the mariadb-10.5 repo branch 990708
to finalize it. I will force push a new version soon.

In the meantime you might want to think about the galera-4 branch
990708 because Salsa-CI shows it regressed:
https://salsa.debian.org/mariadb-team/galera-4/-/jobs/1744367

Bug#990580: apache2: [regression] daily cron mails from logrotate: Reloading Apache httpd web server: apache2., caused by #979813

[Yadd]

Le 09/07/2021 à 05:04, Thorsten Glaser a écrit :
> Thanks Adam for the analysis!
> 
>> To stop the mails from logrotate, could you please change back:
>> -   invoke-rc.d apache2 reload
>> +   invoke-rc.d apache2 reload > /dev/null 2>&1
>>
>> otherwise, people running Bullseye will be mightily unhappy.
>>
>> I also wonder why such a cleanup was done late during hard freeze.
> 
> Indeed. ping‽ (I intend to NMU if no activity happens.)
> 
> bye,
> //mirabilos

Hi,

Apache2 is RFH for years, feel free to contribute

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

[Otto Kekäläinen]

> Thanks for clarifying. That was not obvious since the filename of the
> plugin library did not change. And another reason that dropping the
> virtual galera package should not do any harm.
> (If the plugin would have changed the name (e.g. used a proper
> SOVERSION), -3 and -4 should be co-installable and we would not have
> this problem now.) Actually, I don't really like calling it "plugin" any
> more. (A probably good example of packaged plugins would be proftpd*.)

Ideally, yes. Filed https://github.com/codership/galera/issues/599 so
we don't forget this.

> PS: Otto, what do you think about dropping the epoch from
> src:mariadb-10.6 onwards and applying it only to the binary packages
> that don't change their names? If you want to do this, get in touch once
> you start preparing 10.6

Seems a bit messy to have the epoch in some packages but not all. Also
if we want to start doing this, it would need to start with MariaDB
10.7 and be done both upstream and in Debian so that they stay in sync
and we don''t end up with users "upgrading" from MariaDB 10.6 from
Debian.org repos to MariaDB 10.5 in MariaDB.org repos.

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

[Otto Kekäläinen]

> BTW, the following apt option might be helpful for debugging upgrade
> issues in your CI jobs:
>
>Debug::pkgProblemResolver "true";

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089 we went as
far as running apt with:

apt dist-upgrade -o Debug::pkgDepCache::AutoInstall=1 -o
Debug::pkgDepCache::Marker=1 -o Debug::pkgProblemResolver=1

..but this easily gets too verbose. Ideally apt had a mode that if it
fails, it would output a proper error message with a "trace", but in
normal cases stays short and sweet not to clutter the logs too much.

Bug#990580: apache2: [regression] daily cron mails from logrotate: Reloading Apache httpd web server: apache2., caused by #979813

[Thorsten Glaser]

Thanks Adam for the analysis!

> To stop the mails from logrotate, could you please change back:
> -   invoke-rc.d apache2 reload
> +   invoke-rc.d apache2 reload > /dev/null 2>&1
> 
> otherwise, people running Bullseye will be mightily unhappy.
> 
> I also wonder why such a cleanup was done late during hard freeze.

Indeed. ping‽ (I intend to NMU if no activity happens.)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

Bug#257095: MAXPATHLEN

[Eriberto Mota]

Hi Edward,

Where is the version 2.5.1?

Regards,

Eriberto

Bug#990842: gcc-11: ftbfs on mips64el on Cavium machine

[YunQiang Su]

Package: src:gcc-11
Version: 11.1.0-3

GCC 11 run test timeout due to a problem of GDB on Cavium Octeon.
Please drop build-dep on gdb on mipsel and mips64el.

The problem is about a bug of Cavium Octeon:
Sometimes, if there is a branch insn between ll and sc, the CPU may hang.

I will continue to debug the problem.

Bug#989496: Tagging wontfix

[Brian Thompson]

Since this is expected behavior, I am tagging as "wontfix".

I don't think it's a good idea to suppress the error message.
apt-listchanges gives an "Aborting" message prior to throwing the error.

-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)


signature.asc
Description: PGP signature

Bug#990426: www.debian.org: Clarify status of list of old TC decisions

[Sean Whitton]

Hello,

On Thu 08 Jul 2021 at 09:12AM +02, Raphael Hertzog wrote:

> Hi,
>
> On Mon, 28 Jun 2021, Sean Whitton wrote:
>> -NB that decisions from before the 1st of April 2002 are not yet
>> -recorded here.
>> +NB that no decisions from before the 1st of April 2002 are yet recorded
>> +here yet.
>
> That wording doesn't seem correct for me. Maybe:
> « Note that no decisions from before the 1st of April 2002 are recorded
> here. »
> or
> « Note that decisions from before the 1st of April 2002 have not been
> recorded here. »

There should not be two 'yet's, indeed.  Thanks.

>>  Formal nontechnical and procedural decisions
>>
>> @@ -337,8 +337,8 @@ recorded here.
>>
>>  
>>
>> -NB that decisions from before the 31st of January 2002 are not yet
>> -recorded here.
>> +NB that no decisions from before the 31st of January 2002 are recorded 
>> here
>> +yet.

This one doesn't have the same problem and I think is fine.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#990840: apiguardian: reproducible builds: timestamp embedded in shipped .jar file

[Vagrant Cascadian]

Package: apiguardian
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps timezone
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The shipped apiguardian-api-1.1.0.jar embeds the time, date and timezone
in the build:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/apiguardian.html

  /usr/share/java/apiguardian-api-1.1.0.jar

  Build-Date:·2022-07-12\xd 
  vs.
  Build-Date:·2021-06-09\xd

  Build-Time:·01:53:17.318-1200\xd
  vs.
  Build-Time:·21:34:59.146+1400\xd


The attached patch modifies build.gradle to set the timezone to UTC when
the SOURCE_DATE_EPOCH environment variable is defined, and use
SOURCE_DATE_EPOCH to set the timestamp.

With this patch applied, apiguardian should become reproducible in the
tests.reproducible-builds.org infrastructure.


Thanks for maintaining apiguardian!


live well,
  vagrant
From 6e50539b3aef7df874d8890c9dcdb19123189cc9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 8 Jul 2021 23:53:10 +
Subject: [PATCH] debian/patches: Support reproducible timestamps in the .jar
 file.

Patch build.gradle to use SOURCE_DATE_EPOCH to avoid embedding
timestamp in .jar file.

https://reproducible-builds.org/docs/source-date-epoch/
---
 .../03-reproducible-builds-timestamp.patch| 25 +++
 debian/patches/series |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 debian/patches/03-reproducible-builds-timestamp.patch

diff --git a/debian/patches/03-reproducible-builds-timestamp.patch b/debian/patches/03-reproducible-builds-timestamp.patch
new file mode 100644
index 000..4999dd9
--- /dev/null
+++ b/debian/patches/03-reproducible-builds-timestamp.patch
@@ -0,0 +1,25 @@
+Add support for SOURCE_DATE_EPOCH to avoid embedding timestamp in .jar
+file.
+
+https://reproducible-builds.org/docs/source-date-epoch/
+
+Index: apiguardian/build.gradle
+===
+--- apiguardian.orig/build.gradle
 apiguardian/build.gradle
+@@ -8,7 +8,14 @@ plugins {
+ 	id 'signing'
+ }
+ 
+-Date buildTimeAndDate = new Date()
++// https://reproducible-builds.org/docs/source-date-epoch/
++String source_date_epoch = System.getenv("SOURCE_DATE_EPOCH");
++if (source_date_epoch != null) {
++   TimeZone.setDefault(TimeZone.getTimeZone("UTC"))
++}
++Date buildTimeAndDate = source_date_epoch == null ?
++new Date() :
++new Date(1000 * Long.parseLong(source_date_epoch))
+ ext {
+ 	buildDate = new SimpleDateFormat('-MM-dd').format(buildTimeAndDate)
+ 	buildTime = new SimpleDateFormat('HH:mm:ss.SSSZ').format(buildTimeAndDate)
diff --git a/debian/patches/series b/debian/patches/series
index e7ac9c0..fb1a683 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 01-ignore-versioning-plugin.patch
 02-ignore-github-pages-plugin.patch
+03-reproducible-builds-timestamp.patch
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#990720: d-i.debian.org: [INTL:es] "Install the GRUB boot loader" => "Aunque p"

[Holger Wansing]

tags -1 + pending
thanks

Holger Wansing  wrote (Wed, 7 Jul 2021 18:04:36 +0200):
> Hi,
> 
> Javier Fernandez-Sanguino  wrote (Wed, 7 Jul 2021 15:25:41 
> +0200):
> > tag 990720 confirmed fixed-upstream
> > thanks
> > 
> > Dear colleagues,
> > 
> > I have fixed this today in the debian installer GIT repository:
> > 
> > $ git commit -m "Fix error in translation (Closes: #990720)" es.po
> > [master 64d9fb0063] Fix error in translation (Closes: #990720)
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> I cannot find this commit in the GIT repo.
> Maybe you forgot to 'git push'?

Since Javier is currently unable to push his commit to the repo, we have
agreed that I do this in his name.

Done with commit 
4ce6ee55 "Spanish translation update: fix error in translation"


Holger




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

Bug#990839: opentest4j: reproducible builds: timestamp embedded in shipped .jar file

[Vagrant Cascadian]

Package: opentest4j
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps timezone
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The shipped opentest4j-1.2.0.jar embeds the time, date and timezone in
the build:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/opentest4j.html

  ./usr/share/java/opentest4j-1.2.0.jar

  Build-Date:·2022-07-12\xd
  vs.
  Build-Date:·2021-06-09\xd

  Build-Time:·01:50:58.592-1200\xd
  vs.
  Build-Time:·21:32:48.944+1400\xd


The attached patch modifies build.gradle to set the timezone to UTC when
the SOURCE_DATE_EPOCH environment variable is defined, and use
SOURCE_DATE_EPOCH to set the timestamp.


With this patch applied, opentest4j should become reproducible in the
tests.reproducible-builds.org infrastructure.


Thanks for maintaining opentest4j!


live well,
  vagrant
From 851b4d88d014df82203851919906b0925b21bc1f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 8 Jul 2021 23:38:36 +
Subject: [PATCH] debian/patches: Support reproducible timestamps in the .jar
 file.

Patch build.gradle to use SOURCE_DATE_EPOCH to avoid embedding
timestamp in .jar file.

https://reproducible-builds.org/docs/source-date-epoch/
---
 .../04-reproducible-builds-timestamp.patch| 25 +++
 debian/patches/series |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 debian/patches/04-reproducible-builds-timestamp.patch

diff --git a/debian/patches/04-reproducible-builds-timestamp.patch b/debian/patches/04-reproducible-builds-timestamp.patch
new file mode 100644
index 000..e92cde4
--- /dev/null
+++ b/debian/patches/04-reproducible-builds-timestamp.patch
@@ -0,0 +1,25 @@
+Add support for SOURCE_DATE_EPOCH to avoid embedding timestamp in .jar
+file.
+
+https://reproducible-builds.org/docs/source-date-epoch/
+
+Index: opentest4j/build.gradle
+===
+--- opentest4j.orig/build.gradle
 opentest4j/build.gradle
+@@ -9,7 +9,14 @@ plugins {
+ 	id 'signing'
+ }
+ 
+-Date buildTimeAndDate = new Date()
++// https://reproducible-builds.org/docs/source-date-epoch/
++String source_date_epoch = System.getenv("SOURCE_DATE_EPOCH");
++if (source_date_epoch != null) {
++   TimeZone.setDefault(TimeZone.getTimeZone("UTC"))
++}
++Date buildTimeAndDate = source_date_epoch == null ?
++new Date() :
++new Date(1000 * Long.parseLong(source_date_epoch))
+ ext {
+ 	buildDate = new SimpleDateFormat('-MM-dd').format(buildTimeAndDate)
+ 	buildTime = new SimpleDateFormat('HH:mm:ss.SSSZ').format(buildTimeAndDate)
diff --git a/debian/patches/series b/debian/patches/series
index 856631a..cb3366e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 01-ignore-versioning-plugin.patch
 02-ignore-github-pages-plugin.patch
 03-ignore-spotless-plugin.patch
+04-reproducible-builds-timestamp.patch
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#990838: libmad0-dev: Library version in pkgconfig is not updated

[Adrian Heine]

Package: libmad0-dev
Version: 0.15.1b-10
Severity: normal
Tags: patch
X-Debbugs-Cc: deb...@adrianheine.de

In mad.pc, the version is specified as 0.15.0b, while the package's
version is 0.15.1b.


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

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

Versions of packages libmad0-dev depends on:
ii  libmad0  0.15.1b-10

libmad0-dev recommends no packages.

libmad0-dev suggests no packages.

-- no debconf information
--- debian/mad.pc   2021-07-09 01:31:50.181218863 +0200
+++ debian/mad.pc   2021-07-09 01:31:40.605472270 +0200
@@ -6,6 +6,6 @@
 Name: mad
 Description: MPEG Audio Decoder
 Requires:
-Version: 0.15.0b
+Version: 0.15.1b
 Libs: -L${libdir} -lmad
 Cflags: -I${includedir}

Bug#990837: libid3tag0: Library version in pkgconfig is not updated

[Adrian Heine]

Package: libid3tag0
Version: 0.15.1b-14
Severity: normal
Tags: patch
X-Debbugs-Cc: deb...@adrianheine.de

In id3tag.pc, version is specified as 0.15.0b, while the package's
version is 0.15.1b.


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

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

Versions of packages libid3tag0 depends on:
ii  libc6   2.31-12
ii  zlib1g  1:1.2.11.dfsg-2

libid3tag0 recommends no packages.

libid3tag0 suggests no packages.

-- no debconf information
--- debian/id3tag.pc2021-07-09 01:23:18.885534503 +0200
+++ debian/id3tag.pc2021-07-09 01:23:22.092888095 +0200
@@ -6,6 +6,6 @@
 Name: id3tag
 Description: ID3 tag reading library
 Requires:
-Version: 0.15.0b
+Version: 0.15.1b
 Libs: -L${libdir} -lid3tag -lz
 Cflags: -I${includedir}

Bug#990836: grub2: fix "error: can't find command `hwmatch'." on efi-amd64

[Mauricio Faria de Oliveira]

Package: src:grub2
Version: 2.04-19
Tags: patch

When booting on x86_64 EFI this error message might be observed:

error: can't find command `hwmatch'.

It's usually seen on a serial console; depending on settings
such as GRUB_TERMINAL=serial, GRUB_TIMEOUT_STYLE=hidden, and
/etc/grub.d/10_linux:gfxpayload_dynamic="1" (Ubuntu default),
and is easily reproducible with a KVM guest.

The issue seems to be that d/p/gfxpayload-dynamic.patch only
creates it in grub-core/commands/**i386/pc**/hwmatch.c, thus
it's not available in other grub platforms.

While it might be interesting to try and enable/fix that for
other platforms, it would be nice to have a trivial fix that
can more easily be considered to backport to stable releases.

Since hwmatch apparently never worked on non-i386/pc, simply
replacing the broken call with the equivalent behavior would
be sufficient.

That equivalent behavior is linux_gfx_mode=keep, despite the
error. This happens because in the error case the grub shell
evaluates `if hwmatch ...; then` to true and later evaluates
`if [ $match = 0 ]; then` to true as well, as it's undefined,
which does `set linux_gfx_mode=keep`.

The attached debdiff addresses the issue by checking for the
$grub_platform variable, and only calling hwmatch if that is
'pc', where hwmatch is available; otherwise, just use 'keep'
to keep the current behavior.

Before:

error: can't find command `hwmatch'.
...

grub> hwmatch
error: can't find command `hwmatch'.

grub> echo $grub_platform
efi

grub> echo $linux_gfx_mode
keep

After:


...

grub> hwmatch
error: can't find command `hwmatch'.

grub> echo $grub_platform
efi

grub> echo $linux_gfx_mode
keep

Tested on Bullseye RC2.

cheers,

-- 
Mauricio Faria de Oliveira


grub2_hwmatch.debdiff
Description: Binary data

Bug#967010:

[Munna Pardesi]

Bug#990835: suricata: CVE-2021-35063

[Salvatore Bonaccorso]

Source: suricata
Version: 1:6.0.1-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: fixed -1 1:6.0.3-1~exp1

Hi,

The following vulnerability was published for suricata.

CVE-2021-35063[0], it is mentioned in [1], but not much details
provided.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-35063
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-35063
[1] https://forum.suricata.io/t/suricata-6-0-3-and-5-0-7-released/1489
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1980453

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4

[Aaron M. Ucko]

Paul Gevers  writes:

> On 08-07-2021 21:06, Aaron M. Ucko wrote:
>> I should be able to upload around 22:00 UTC.  (Also, I take it you're OK
>> with the full version, since you didn't indicate otherwise.)  Thanks much!
>
> Yes.

Uploaded.  Thanks again!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#990833: (no subject)

[Heather Ellsworth]

I've proposed the fix here: 
https://salsa.debian.org/debian/libpam-alreadyloggedin/-/merge_requests/1

Bug#990834: ufw: Please set TimeoutStartUSec=infinity to some timedout limit.

[Andres Z]

Package: ufw
Version: 0.36-7.1
Severity: normal
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,

By Default the following parameter is set to ' infinity '
TimeoutStartUSec=infinity

>From time to time, it hangs on startup so, if you are a normal user, it is no
easy to find the problem. It would be possible to set a ' timedout limit time '
by default that no freeze the startup. ?

Thank you in advance.


Regards.


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

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

Versions of packages ufw depends on:
ii  debconf [debconf-2.0]  1.5.75
ii  iptables   1.8.7-1
ii  lsb-base   11.1.0
ii  python33.9.2-3
ii  ucf3.0043

ufw recommends no packages.

Versions of packages ufw suggests:
ii  rsyslog  8.2102.0-2

-- debconf information:
  ufw/existing_configuration:
  ufw/allow_custom_ports:
  ufw/enable: false

Bug#990833: FTBFS: BUG_STAT_MISSING needs to be undefined

[Heather Ellsworth]

Package: libpam-alreadyloggedin 

Version: 0.3-9 

Severity: serious 



Justification: fails to build from source (but built successfully in the 
past)

Tags: ftbfs patch
User: ubuntu-de...@lists.canonical.com
Usertags: origin-ubuntu impish ubuntu-patch


Dear Maintainer,



The BUG_STAT_MISSING flag is defined and builds fine with gcc 10.2, but

when 10.3 comes around (see corresponding launchpad bug [0]), this value

needs to be undefined.



Before the d/rules overhaul [1], there was a CPPFLAG to undefine

BUG_STAT_MISSING and the gcc command had both -DBUG_STAT_MISSING

-UBUG_STAT_MISSING. Rather than re-add -UBUG_STAT_MISSING, I propose

deleting it's mention all together from the list of flags.



[0]
https://bugs.launchpad.net/ubuntu/+bug/1935081
[1]

https://salsa.debian.org/debian/libpam-alreadyloggedin/-/commit/7047397a75a063aeda9958371d4a52dab8f8d24c


Cheers,

Heather



-- System Information:

Debian Release: 11.0

  APT prefers unstable

  APT policy: (500, 'unstable')

Architecture: amd64 (x86_64)



Kernel: Linux 5.11.0-22-generic (SMP w/8 CPU threads)

Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_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)



Versions of packages libpam-alreadyloggedin depends on:

ii  libc6  2.31-12



Versions of packages libpam-alreadyloggedin recommends:

ii  login  1:4.8.1-1



libpam-alreadyloggedin suggests no packages.

Bug#990832: spamass-milter: Postfix has increased unparseable relay failures leading to SPF_FAIL

[William Haller]

Package: spamass-milter
Version: 0.4.0-1+b1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Migration from CentOS 7 to Debian buster. Minor configuration file changes from 
CentOS due to Postfix chroot, but was working there. Users reported missing 
mail on Debian which we discovered was being routed to system
junk files due to SPF failures from spamassassin.

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

Removing the spamass-milter from the stream and letting the spamc program be 
run at delivery time via procmail dropped the number of unparseable relay 
e-mails (and several subsequent SPF failures) from 2600 or so per day
to around 100 per day. No changes to the spamassassin configuration - just 
dropping the spamass-milter. Since SPF is failing, it is almost certainly the 
last hop that is not parsed right (usually the first listed).
A sample is included... I didn't test this message, but I did test some others 
that failed by running them directly through spamc and they gave a correct 
report with no unparseable relay errors.

Return-Path: 
Delivered-To: emailaddressremo...@autoelect.com
Received: from NFRSProdINF1.us.nfpa.org (NFRSProdINF1.us.nfpa.org 
[161.47.147.140])
by postoffice-2.autoelect.com (Postfix) with ESMTP id 5100AA03E0
for ; Tue,  6 Jul 2021 12:31:48 
-0600 (MDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 postoffice-2.autoelect.com 5100AA03E0
Received: from NFRSProdWeb10.us.nfpa.org ([172.24.32.139]) by 
NFRSProdINF1.us.nfpa.org with Microsoft SMTPSVC(10.0.14393.4169);
Tue, 6 Jul 2021 14:31:47 -0400
Received: from NFRSProdWeb10 ([127.0.0.1]) by NFRSProdWeb10.us.nfpa.org with 
Microsoft SMTPSVC(10.0.14393.4169);
Tue, 6 Jul 2021 14:31:47 -0400
MIME-Version: 1.0
From: emailaddressremo...@nfpa.org
To: emailaddressremo...@autoelect.com
Date: 6 Jul 2021 14:31:47 -0400
Subject: NFPA  70 Document Alert
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
Message-ID: 
X-OriginalArrivalTime: 06 Jul 2021 18:31:47.0761 (UTC) 
FILETIME=[2DF78A10:01D77295]
X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.5.11 
(postoffice-2.autoelect.com [207.109.102.68]); Tue, 06 Jul 2021 12:31:48 -0600 
(MDT)
X-Virus-Scanned: clamav-milter 0.103.2 at postoffice-2.autoelect.com
X-Virus-Status: Clean
X-Spam-Status: No, score=3.7 required=7.0 tests=HTML_IMAGE_ONLY_20,
HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,RDNS_NONE,SPF_FAIL,
T_REMOTE_IMAGE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no
version=3.4.2
X-Spam-Report:
*  0.0 SPF_FAIL SPF: sender does not match SPF record (fail)
*  [SPF failed: Please see 
http://www.openspf.org/Why?s=mfrom;id=EmailAddressRemoved%40nfpa.org;ip=172.24.32.139;r=postoffice-2.autoelect.com]
*  0.0 HTML_MESSAGE BODY: HTML included in message
*  1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
*  0.7 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 bytes of
*  words
*  0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
*  lines
*  1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
*  0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML
*  tag
*  0.0 T_REMOTE_IMAGE Message contains an external image
X-Spam-Level: ***
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
postoffice-2.autoelect.com

body of message omitted.

   * What was the outcome of this action?
Mail was incorrectly flagged as forged and hid from the user.

   * What outcome did you expect instead?
Mail to be correctly parsed and delivered.


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

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

Versions of packages spamass-milter depends on:
ii  adduser 3.118
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libmilter1.0.1  8.15.2-14~deb10u1
ii  libstdc++6  8.3.0-6
ii  spamc   3.4.2-1+deb10u3

Versions of packages spamass-milter recommends:
ii  postfix   3.4.14-0+deb10u1
ii  spamassassin  3.4.2-1+deb10u3

spamass-milter suggests no packages.

-- Configuration Files:
/etc/default/spamass-milter changed [not included]

-- no debconf information

Bug#990339: matplotlib: reproducible builds: embeds current year in documentation

[Vagrant Cascadian]

Control: forwarded 990339 https://github.com/matplotlib/matplotlib/pull/20608

On 2021-06-26, Vagrant Cascadian wrote:
> On 2021-06-26, Sandro Tosi wrote:
>>> The build date is embedded in copyright statements in various .html
>>> documentation:
>>>
>>>   
>>> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/matplotlib.html
>>>
>>>   ./usr/share/doc/python-matplotlib-doc/html/users/whats_new_old.html
>>>
>>>   
>>> ·Copyright·2021·-·2012·John·Hunter...·2012·-·2021·The·Matplotlib·development·team.
>>>   vs.
>>>   
>>> ·Copyright·2021·-·2012·John·Hunter...·2012·-·2022·The·Matplotlib·development·team.
>>>
>>> The attached patch fixes this by patching doc/conf.py to respect
>>> SOURCE_DATE_EPOCH, which is set by dpkg during package builds.
>>
>> did you forward this patch upstream? can you link the PR/commit here?
>
> Will follow up at:
>
>   https://github.com/matplotlib/matplotlib/issues

Done:

  https://github.com/matplotlib/matplotlib/pull/20608


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#584247: brasero: Error checking the integrity of the CD-RW DVD-RW using the file MD5 checksum

[juichenieder-deb...@yahoo.co.uk]

If I understand this bug correctly I think I have just come across it.  The 
error message I received was:  "The file integrity check could not be 
performed, you do not have the required permissions to use this drive".
After some searching on the internet I realised that the problem was because 
the DVD had been mounted and thus not able to get read by Brasero.  I opened up 
the final manager, right clicked on the dvd drive and selected "Unmount drive" 
went back to Brasero to try again and voila no more error message.
I think the error message could get updated to either:1. Cite the drive being 
mounted as a possible cause.2. Automatically check if the drive has been 
mounted and give this info to the user.3. Ask the user if they wish to try to 
unmount the drive from Brasero.4. Automatically unmount the drive from Brasero 
without asking the user.5. Do 3 but with an option box to ask it to do 4 in the 
future.

Best wishes,Jack

Bug#990831: getopts: $OPTIND == 2 although no option arg supplied.

[kalle]

Package: bash
Version: 5.1-2+b2
Severity: important

Dear maintainer,

With bash 5.1-2+b2, the output of

getopts abc opt hello; EC=$?; echo $opt $OPTIND $EC

is

x 2 1

$EC == 1 is correct, $opt == x is strange but irrelevant, but $OPTIND == 2 is
not the
index of the first non-option arg, the correct value is 1.
This corrupts all my scripts which use shift $((OPTIND - 1)) to process the
non-option args.

After downgrading to bash 5.0-4, the output of the above command is

x 1 1

as it should be.


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

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

Versions of packages bash depends on:
ii  base-files   11.1
ii  debianutils  4.11.2
ii  libc62.31-12
ii  libtinfo66.2+20201114-2

Versions of packages bash recommends:
ii  bash-completion  1:2.11-2

Versions of packages bash suggests:
pn  bash-doc  

Bug#990826: lollypop: Segmentation fault - cannot start lollypop

[Andreas Ronnquist]

On Thu, 08 Jul 2021 18:33:25 +0200 Amr Ibrahim
 wrote:
> Package: lollypop
> Version: 1.4.14-1
> Severity: important
> X-Debbugs-Cc: amribrahim1...@hotmail.com
> 
> Dear Maintainer,
> 
> I cannot start lollypop due to a segmentation fault. This is on GNOME
> Shell Wayland.
> 
> To reproduce in a terminal:
> 
- 8< -

Thanks for your report - Could you please try to reproduce when running
lollypop from a terminal using "lollypop -d"? It should give more useful
debugging information.

/Andreas Rönnquist
gus...@debian.org

Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4

[Paul Gevers]

Hi,

On 08-07-2021 21:06, Aaron M. Ucko wrote:
> I should be able to upload around 22:00 UTC.  (Also, I take it you're OK
> with the full version, since you didn't indicate otherwise.)  Thanks much!

Yes.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990823: quakespasm: Caps Lock cannot be bound

[Andrew]

Package: quakespasm
Version: 0.93.2+dfsg-2
Severity: normal
X-Debbugs-Cc: andrew.pin...@tutanota.com

Dear Maintainer,

Caps Lock cannot be bound, it says "capslock" is not a valid key, I've
checked many combinations like caps_lock, caps, capslk, but none work.
Upstream the bug is not present.


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_DK.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 quakespasm depends on:
ii  libc6   2.31-12
ii  libflac81.3.3-2
ii  libgl1  1.3.2-1
ii  libmad0 0.15.1b-10
ii  libmikmod3  3.3.11.1-6
ii  libopusfile00.9+20170913-1.1
ii  libsdl2-2.0-0   2.0.14+dfsg2-3
ii  libvorbisfile3  1.3.7-1

quakespasm recommends no packages.

quakespasm suggests no packages.

-- no debconf information

Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4

[Aaron M. Ucko]

Paul Gevers  writes:

> Hi Aaron,

Hi, Paul.

> Assuming the upload happens shortly, please go ahead.

I should be able to upload around 22:00 UTC.  (Also, I take it you're OK
with the full version, since you didn't indicate otherwise.)  Thanks much!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

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

[Andreas Tille]

On Thu, Jul 08, 2021 at 02:36:16PM +, Thorsten Glaser wrote:
> 
> You can also file an unblock request for pre-approval before
> uploading, that way you’ll know whether they’ll accept it.

I admit I do not expect any *other* RC bug than this one - so most
probably there is no real harm done by an upload to unstable.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#990462: Bug#990319: unblock: intel-microcode/3.20210608.2

[Henrique de Moraes Holschuh]

Just to be clear: the iwlwifi regression has not been fixed.  That happens on 
processor 0x906ea.

-- 
  Henrique de Moraes Holschuh 

Bug#990519: RFS: sentry-python/1.1.0-2 -- new version of Python SDK for Sentry.io

[Emmanuel Arias]

Hello, 

I loooked it and perhaps you can bump debhelper-compat to 13. Also,
maybe it's a good idea add autopkgtests tests. 

Also you missed * Team upload. line in d/changelog.


Cheers, 
eamanu

Bug#990462: Bug#990319: unblock: intel-microcode/3.20210608.2

[Henrique de Moraes Holschuh]

Update re. the intel-microcode regressions.

According to Intel, the newest microcode update for Skylake (0x406e3 and 
0x506e3) should *NOT* hang on boot anymore, even when applied to very old 
systems with too-outdated microcode in BIOS.  The new information about this 
issue was posted to the upstream bug report a few hours ago.

However, to be safe, it requires that one updates directly from the BIOS ucode 
to the new microcode using the kernel's "early update" method.  This is exactly 
what we do in Debian, so it should just work.

-- 
  Henrique de Moraes Holschuh 

Bug#990830: unblock: youtube-dl/2021.06.06-1

[Andreas Tille]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 987...@bugs.debian.org, 989...@bugs.debian.org

Please unblock package youtube-dl

new upstream version is needed to feature new interface

[ Reason ]
I'm aware that no new upstream versions are permitted at this time of
the release.  So feel free to mark the bug wontfix.  On the other hand
the old upstream version does not cope with all download options and
will lack some functionality users might expect.  Since I was advise
that discussion on debian-release@l.d.o will not really work I uploaded
to unstable and file this bug to bring the issue to your attention.

[ Impact ]
There are examples of videos that can not be downloaded.  For instance

youtube-dl 9k4SnovHRRM

does not work with the version in testing.

[ Tests ]
There is a build time test suite that was running.  I tested manually
thet the example above (and some others) are working now.

[ Risks ]
The debdiff is huge (thus xz compressed) since its a new upstream
version.  I felt unable to backport the actual change that is needed
to cope with the example video.  Since youtube-dl is a leaf package
I do not expect any severe risk, thought.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [ ] ** I did NOT checked the changes between the upstream
 version in testing and the recent upload **
  [x] attach debdiff against the package in testing

[ Other info ]
I'd like to stress again that I'm fine with a wontfix and will care
for an upload to backports as soon as this is possible.

unblock youtube-dl/2021.06.06-1


youtube-dl_2021.02.10-2021.06.06.debdiff.xz
Description: application/xz

Bug#990829: dh_missing: check doc installations (other dh_install*)

[Drew Parsons]

Package: debhelper
Version: 13.3.4
Severity: normal

dh_missing reports an error if files in debian/tmp have not been
installed.  But it seems to only check installation by dh_install.

If doc files in debian/tmp are installed using dh_installdocs (e.g. by
setting debian/package.docs), then dh_missing marks these doc files as
"not-installed".

It would make sense for dh_missing to check files installed via the
other debhelper install tools, not only dh_install (any of the
dh_install* tools I guess).

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1+nmu1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.12.0-1
ii  dpkg 1.20.9
ii  dpkg-dev 1.20.9
ii  dwz  0.14-1
ii  file 1:5.39-3
ii  libdebhelper-perl13.3.4
ii  libdpkg-perl 1.20.9
ii  man-db   2.9.4-2
ii  perl 5.32.1-4
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202003

-- no debconf information

Bug#990519: RFS: sentry-python/1.3.0-2 -- new version of Python SDK for Sentry.io

[Eberhard Beilharz]

I uploaded 1.3.0 to mentors:

https://mentors.debian.net/package/sentry-python/ 



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

    dget 
-xhttps://mentors.debian.net/debian/pool/main/s/sentry-python/sentry-python_1.3.0-2.dsc
  

Bug#990232: python3-sentry-sdk: New upstream release 1.1.0

[Eberhard Beilharz]

I uploaded 1.3.0 to mentors:

https://mentors.debian.net/package/sentry-python/ 



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

    dget 
-xhttps://mentors.debian.net/debian/pool/main/s/sentry-python/sentry-python_1.3.0-2.dsc
  

Bug#989120: golang-github-go-sourcemap-sourcemap accesses the network during the build

[Athos Ribeiro]

Package: golang-github-go-sourcemap-sourcemap
Version: 2.1.3+git20201028.eed1c20-2
Followup-For: Bug #989120
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Fixing a typo present in the previous message. Please, ignore the
previous patch.
diff -Nru 
golang-github-go-sourcemap-sourcemap-2.1.3+git20201028.eed1c20/debian/rules 
golang-github-go-sourcemap-sourcemap-2.1.3+git20201028.eed1c20/debian/rules
--- golang-github-go-sourcemap-sourcemap-2.1.3+git20201028.eed1c20/debian/rules 
2021-03-11 16:00:08.0 -0300
+++ golang-github-go-sourcemap-sourcemap-2.1.3+git20201028.eed1c20/debian/rules 
2021-07-08 13:51:34.0 -0300
@@ -2,3 +2,9 @@
 
 %:
dh $@ --buildsystem=golang --with=golang
+
+override_dh_auto_test:
+   # The test suite needs an external network connection to fetch jquery.
+   # Patching it would require adjustments for compliance with the 
available
+   # version of libjs-jquery. This would require adjusting the patch for 
every
+   # new libjs-jquery version. Let's just skip the tests instead.

Bug#990822: debian-policy: Please document version scheme for derivatives

[Sean Whitton]

Hello,

On Thu 08 Jul 2021 at 05:11PM +02, Benjamin Drung wrote:

> Package: debian-policy
> Version: 4.5.1.0
> Severity: wishlist
>
> Hi,
>
> Paragraph 5.6.12. Version describes the version parts epoch,
> upstream_version, and debian_revision. But it does not describe how to
> use the Debian revision in Debian itself and in derivatives like Ubuntu.
>
> To make packages in derivatives work seamlessly with Debian, I propose
> following scheme (which is used in Ubuntu, in-house, and by me
> personally):
>
> The derivative selects a name for using in the debian_revision (e.g.
> Ubuntu uses "ubuntu", we use "ionos" in-house, and I use "bd" for
> personal builds). Then following rules apply:
>
>  * no change in the package version when using the source package
>unmodified (e.g. 1.2-3)
>
>  * Add X to the Debian package version starting with X=1 and
>incrementing X on every new upload when the source package is
>modified (e.g. 1.2-3ubuntu1)
>
>  * If the upstream version is not packaged for Debian yet, use
>0X as debian_revision with X=1 and incrementing X on
>every new upload (e.g. 1.3-0ubuntu1).
>
>  * If the Debian package is backported to an older derivative and needs
>changes for it, add ~X to the debian_revision (e.g.
>1.2-3~bd1).
>
> Is the Debian policy the correct place to document that?

To be honest I'm not sure it is.  What do you think about using a DEP
for this?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#990828: mutt can not delete mails due to access rights

[Hans-J. Ullrich]

Package: mutt
Version: 2.0.5-4.1
Severity: important

Dear Maintainer,

it looks like, that mutt is not able to delete mails due to access rights. 
I checked the settings of the files and directories, but these seem to be ok 
for me. 
This is the output: 

ls -la / | grep var 
drwxr-xr-x  14 root root4096 18. Mai 11:33 var 

ls -la /var | grep mail 
drwxrwsr-x   2 root mail   4096  8. Jul 16:02 mail 

ls -la /var/mail/myusername 
-rw-rw 1 myusername mail 55330396  8. Jul 16:02 /var/mail/myusername 

(The term "myusername" is an alias for my real username)

When I remember correctly, this bug appeared in the past from time to time and 
was fixed. Now it appears again.

It would be nice, if you could take a look at it.

Thank you and best regards

Hans



-- Package-specific info:
Mutt 2.0.5 (2021-01-21)
Copyright (C) 1996-2021 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.10.0-7-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2)
libidn2: 2.3.0 (compiled with 2.3.0)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' 
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-10 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-option-checking' '--disable-silent-rules' 
'--libdir=\${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' 
'--disable-maintainer-mode' '--disable-dependency-tracking' 
'--with-mailpath=/var/mail' '--enable-compressed' '--enable-debug' 
'--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' 
'--enable-smtp' '--enable-pop' '--enable-sidebar' '--enable-dotlock' 
'--disable-fmemopen' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn2' 
'--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' 
'--without-qdbm' '--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 
'CFLAGS=-g -O2 -ffile-prefix-map=/build/mutt-T9kudq/mutt-2.0.5=. 
-fstack-protector-strong -Wformat -Werror=format-security' 
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-ffile-prefix-map=/build/mutt-T9kudq/mutt-2.0.5=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  -HAVE_LIBIDN  +HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  
+USE_SIDEBAR  +USE_COMPRESSED  +USE_INOTIFY  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:

Bug#990827: golang-github-uber-go-atomic: autopkgtest regression on i386 and armhf

[Paul Gevers]

Source: golang-github-uber-go-atomic
Version: 1.8.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of golang-github-uber-go-atomic the autopkgtest of
golang-github-uber-go-atomic fails in testing on i386 and armhf when
that autopkgtest is run with the binary packages of
golang-github-uber-go-atomic from unstable. It passes when run with only
packages from testing. In tabular form:

  passfail
golang-github-uber-go-atomic  from testing1.8.0-1
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report.

This regression will be blocking the migration to testing [1]. Can you
please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=golang-github-uber-go-atomic

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-uber-go-atomic/13437021/log.gz

github.com/uber-go/atomic/internal/gen-atomicint
github.com/uber-go/atomic/internal/gen-atomicwrapper
   dh_auto_test -O--buildsystem=golang
cd obj-arm-linux-gnueabihf && go test -vet=off -v -p 32
github.com/uber-go/atomic
github.com/uber-go/atomic/internal/gen-atomicint
github.com/uber-go/atomic/internal/gen-atomicwrapper
# github.com/uber-go/atomic [github.com/uber-go/atomic.test]
src/github.com/uber-go/atomic/uintptr_test.go:72:29: constant
18446744073709551615 overflows uintptr
FAILgithub.com/uber-go/atomic [build failed]
?   github.com/uber-go/atomic/internal/gen-atomicint[no test files]
?   github.com/uber-go/atomic/internal/gen-atomicwrapper[no test files]
FAIL
dh_auto_test: error: cd obj-arm-linux-gnueabihf && go test -vet=off -v
-p 32 github.com/uber-go/atomic
github.com/uber-go/atomic/internal/gen-atomicint
github.com/uber-go/atomic/internal/gen-atomicwrapper returned exit code 2
make: *** [debian/rules:4: build] Error 25
autopkgtest [03:45:59]: test dh-golang-autopkgtest: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989120: golang-github-go-sourcemap-sourcemap accesses the network during the build

[Athos Ribeiro]

Package: golang-github-go-sourcemap-sourcemap
Version: 2.1.3+git20201028.eed1c20-2
Followup-For: Bug #989120
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,

While patching the test suite to use libjs-jquery from the archive could
be an option, adjusting the tests would require previous knowledge of
the specific jquery version in the archive, meaning the patch would need
adjustments whenever jquery gets updated. A better fix could be to just
stop running the test suite for this package build.

Here is a patch to disable the test suite for this package builds.


  * d/rules: skip test suite run since testing requires network connection
#989120 (LP: #1935066)


Thanks for considering the patch.


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

Kernel: Linux 5.8.0-59-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-go-sourcemap-sourcemap-2.1.3+git20201028.eed1c20/debian/rules 
golang-github-go-sourcemap-sourcemap-2.1.3+git20201028.eed1c20/debian/rules
--- golang-github-go-sourcemap-sourcemap-2.1.3+git20201028.eed1c20/debian/rules 
2021-03-11 16:00:08.0 -0300
+++ golang-github-go-sourcemap-sourcemap-2.1.3+git20201028.eed1c20/debian/rules 
2021-07-08 13:41:23.0 -0300
@@ -2,3 +2,9 @@
 
 %:
dh $@ --buildsystem=golang --with=golang
+
+override_dh_autotest:
+   # The test suite needs an external network connection to fetch jquery.
+   # Patching it would require adjustments for compliance with the 
available
+   # version of libjs-jquery. This would require adjusting the patch for 
every
+   # new libjs-jquery version. Let's just skip the tests instead.

Bug#990826: lollypop: Segmentation fault - cannot start lollypop

[Amr Ibrahim]

Package: lollypop
Version: 1.4.14-1
Severity: important
X-Debbugs-Cc: amribrahim1...@hotmail.com

Dear Maintainer,

I cannot start lollypop due to a segmentation fault. This is on GNOME Shell 
Wayland.

To reproduce in a terminal:

~$ lollypop 
[INFO] 2021-07-08 18:22:25 LastFMWebService::start(): [Errno 2] No such file or 
directory: '/home/amr/.local/share/lollypop/LASTFM_queue.bin'
[INFO] 2021-07-08 18:22:25 LastFMWebService::start(): [Errno 2] No such file or 
directory: '/home/amr/.local/share/lollypop/LASTFM_queue.bin'
[INFO] 2021-07-08 18:22:25 Last.fm web service started
[INFO] 2021-07-08 18:22:25 LastFMWebService::start(): [Errno 2] No such file or 
directory: '/home/amr/.local/share/lollypop/LIBREFM_queue.bin'
[INFO] 2021-07-08 18:22:25 LastFMWebService::start(): [Errno 2] No such file or 
directory: '/home/amr/.local/share/lollypop/LIBREFM_queue.bin'
[INFO] 2021-07-08 18:22:25 Libre.fm web service started
[INFO] 2021-07-08 18:22:25 ListenBrainzWebService::start(): [Errno 2] No such 
file or directory: '/home/amr/.local/share/lollypop/listenbrainz_queue.bin'
[INFO] 2021-07-08 18:22:25 ListenBrainzWebService::start(): [Errno 2] No such 
file or directory: '/home/amr/.local/share/lollypop/listenbrainz_queue.bin'
[INFO] 2021-07-08 18:22:25 ListenBrainz web service started
[ERROR] 2021-07-08 18:22:25 Window::__setup_size_and_position(): list index out 
of range
[INFO] 2021-07-08 18:22:25 Scan started
[INFO] 2021-07-08 18:22:26 lollypop.collection_scanner::__get_objects_for_uris: 
execution time 0:0.425529
Segmentation fault


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

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

Versions of packages lollypop depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-gst-plugins-base-1.0  1.18.4-2
ii  gir1.2-gstreamer-1.0 1.18.4-2
ii  gir1.2-handy-1   1.0.3-2
ii  gir1.2-secret-1  0.20.4-2
ii  gir1.2-soup-2.4  2.72.0-2
ii  gir1.2-totemplparser-1.0 3.26.5-5
ii  libhandy-1-0 1.0.3-2
ii  python3  3.9.2-3
ii  python3-bs4  4.9.3-1
ii  python3-cairo1.16.2-4+b2
ii  python3-gi   3.38.0-2
ii  python3-gi-cairo 3.38.0-2
ii  python3-gst-1.0  1.18.3-1
ii  python3-pil  8.1.2+dfsg-0.1

Versions of packages lollypop recommends:
ii  youtube-dl  2021.02.10-2

Versions of packages lollypop suggests:
ii  gstreamer1.0-libav  1.18.4-3

-- no debconf information

Bug#990820: DefaultErrnoRet not working with runc 1.0

[Rodrigo Campos]

On 7/8/21 5:57 PM, Shengjing Zhu wrote:

Hi,


Hi! :)



On Thu, Jul 8, 2021 at 7:12 PM Rodrigo Campos  wrote:

runc 1.0 from debian repositories doesn't honor DefaultErrnoRet, that


It's expected. As I disable that in
https://salsa.debian.org/go-team/packages/runc/-/blob/experimental/debian/patches/0010-compatible-with-specs-go-1.0.2.41.g7413a7f.patch


Ohh, it makes sense.


The reason behind is just simple.
golang-github-opencontainers-specs-dev in Debian unstable is just at
version 1.0.2.41.g7413a7f-1, which don't support DefaultErrnoRet.
I plan to update the spec package after bullseye release, which is
planned at July 31. But if you really want to use this feature before
that day, I may update the spec package in experimental first.


No, no need to update it now. Your plan is just fine for me :)

When you update the runtime-spec, it will be great if the version is in 
sync with what runc vendors. In particular, if it includes this PR I did 
to the runtime-spec 
(https://github.com/opencontainers/runtime-spec/pull/1074) it will be 
great (the version of the runtime-spec that runc 1.0 vendors already 
includes that :))



Thanks again and sorry for the silly report, didn't see the patch! :)


Best,
Rodrigo

Bug#990462: Bug#990319: unblock: intel-microcode/3.20210608.2

[Sebastian Ramacher]

On 2021-07-08 16:59:42, Justin B Rye wrote:
> Paul Gevers wrote:
> >> We could replace this with "See the instructions in the DSA (also in
> >> the intel-microcode README.Debian)".  Mind you, it would be nice if
> >> that README started with "TLDR: boot with dis_ucode_ldr"!
> > 
> > To get this straight, you only propose to replace the piece between
> > brackets (inclusive) with that right? I think it's worth saying "you can
> > recover".
> 
> Yes, though I was vaguely thinking that in the process of adding
> markup we might reorganise the links, since we don't need full URLs in
> the text.  Something like
> 
>
>  
>  Intel CPU microcode issues
>  
>The intel-microcode package
>currently in bullseye and buster-security (see url="https://www.debian.org/security/2021/dsa-4934;>DSA-4934-1)
>is known to contain two significant bugs. For some CoffeeLake CPUs this
>update 
> url="https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/56;>may
>break network interfaces that use role="package">firmware-iwlwifi, and for some Skylake
>R0/D0 CPUs on systems using a very outdated firmware/BIOS, 
> url="https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31;>the
>system may hang on boot.
>  
>  
>If you held back the update from DSA-4934-1 due to either of these
>issues, or do not have the security archive enabled, be aware that
>upgrading to the role="package">intel-microcode package in bullseye may
>cause your system to hang on boot or break iwlwifi. In that case, you
>can recover by disabling microcode loading on boot; see the
>instructions in the DSA, which are also in the role="package">intel-microcode
>README.Debian.
>  
>
> 
> (When it says "currently in bullseye and buster-security", are there
> plans for this to change?  If not, drop the "currently"; if so, we
> have to remember to update the release notes when it happens.)

This will change, yes. After the next buster release, it should read
buster instead of buster-security. Once there is a fixed
firmware-iwlwifi available, affected users no longer need to disable
microcode loading to work around broken wifi.

Cheers
-- 
Sebastian Ramacher

Bug#990822: debian-policy: Please document version scheme for derivatives

[Bill Allombert]

On Thu, Jul 08, 2021 at 05:11:45PM +0200, Benjamin Drung wrote:
> Package: debian-policy
> Version: 4.5.1.0
> Severity: wishlist
> 
> Hi,
> 
> Paragraph 5.6.12. Version describes the version parts epoch,
> upstream_version, and debian_revision. But it does not describe how to
> use the Debian revision in Debian itself and in derivatives like Ubuntu.
> 
> To make packages in derivatives work seamlessly with Debian, I propose
> following scheme (which is used in Ubuntu, in-house, and by me
> personally):
> 
> The derivative selects a name for using in the debian_revision (e.g.
> Ubuntu uses "ubuntu", we use "ionos" in-house, and I use "bd" for
> personal builds). Then following rules apply:
> 
>  * no change in the package version when using the source package
>unmodified (e.g. 1.2-3)

This one is slightly annoying because it leads to two different binary
packages with identical filenames.

...

> Is the Debian policy the correct place to document that?

This is the issue. Of course policy can document what it wants, but it
does not have authority over non-Debian projects.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#984654: alsa-ucm-conf: please add support for pinephone,pinetab,librem5 hardware

[Nicolas Boulenguez]

Package: alsa-ucm-conf
Followup-For: Bug #984654

Hello.

Upstream will probably more easily accept the pinephone patch with the
output of the alsa-info script on the physical device, with a sound
system including the patch.
upload=true=true=
!!
!!ALSA Information Script v 0.4.65
!!

!!Script ran on: Sat Mar  6 15:35:20 UTC 2021


!!Linux Distribution
!!--

Debian GNU/Linux bullseye/sid \n \l PRETTY_NAME="Debian GNU/Linux bullseye/sid" 
NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/; 
SUPPORT_URL="https://www.debian.org/support; 
BUG_REPORT_URL="https://bugs.debian.org/;


!!DMI Information
!!---

Manufacturer:  
Product Name:  
Product Version:   
Firmware Version:  
System SKU:
Board Vendor:  
Board Name:


!!ACPI Device Status Information
!!---



!!Kernel Information
!!--

Kernel release:5.11-sunxi64
Operating System:  GNU/Linux
Architecture:  aarch64
Processor: unknown
SMP Enabled:   Yes


!!ALSA Version
!!

Driver version: k5.11-sunxi64
Library version:1.2.4
Utilities version:  1.2.4


!!Loaded ALSA modules
!!---

snd_soc_simple_card


!!Sound Servers on this system
!!

Pulseaudio:
  Installed - Yes (/usr/bin/pulseaudio)
  Running - Yes


!!Soundcards recognised by ALSA
!!-

 0 [PinePhone  ]: PinePhone - PinePhone
  PinePhone


!!PCI Soundcards installed in the system
!!--



!!Modprobe options (Sound related)
!!

snd_pcsp: index=-2
snd_usb_audio: index=-2
snd_atiixp_modem: index=-2
snd_intel8x0m: index=-2
snd_via82xx_modem: index=-2


!!Loaded sound module options
!!---

!!Module: snd_soc_simple_card
* : 


!!ALSA Device nodes
!!-

crw-rw+ 1 root audio 116,  4 Mar  6 16:29 /dev/snd/controlC0
crw-rw+ 1 root audio 116,  3 Mar  6 16:29 /dev/snd/pcmC0D0c
crw-rw+ 1 root audio 116,  2 Mar  6 16:29 /dev/snd/pcmC0D0p
crw-rw+ 1 root audio 116,  1 Mar  6 16:29 /dev/snd/seq
crw-rw+ 1 root audio 116, 33 Mar  6 16:29 /dev/snd/timer

/dev/snd/by-path:
total 0
drwxr-xr-x 2 root root  60 Mar  6 16:29 .
drwxr-xr-x 3 root root 160 Mar  6 16:29 ..
lrwxrwxrwx 1 root root  12 Mar  6 16:29 platform-sound -> ../controlC0


!!Aplay/Arecord output
!!

APLAY

 List of PLAYBACK Hardware Devices 
card 0: PinePhone [PinePhone], device 0: 1c22c00.dai-sun8i-codec-aif1 
sun8i-codec-aif1-0 [1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

ARECORD

 List of CAPTURE Hardware Devices 
card 0: PinePhone [PinePhone], device 0: 1c22c00.dai-sun8i-codec-aif1 
sun8i-codec-aif1-0 [1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

!!Amixer output
!!-

!!---Mixer controls for card PinePhone

Card hw:0 'PinePhone'/'PinePhone'
  Mixer name: ''
  Components: ''
  Controls  : 49
  Simple ctrls  : 37
Simple mixer control 'Headphone',0
  Capabilities: pvolume pvolume-joined pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 63
  Mono:
  Front Left: Playback 63 [100%] [0.00dB] [off]
  Front Right: Playback 63 [100%] [0.00dB] [off]
Simple mixer control 'Headphone Source',0
  Capabilities: penum
  Items: 'DAC' 'Mixer'
  Item0: 'DAC'
  Item1: 'DAC'
Simple mixer control 'Line In',0
  Capabilities: pvolume pvolume-joined pswitch cswitch
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: Playback 0 - 7
  Front Left: Playback 3 [43%] [0.00dB] [off] Capture [off]
  Front Right: Playback 3 [43%] [0.00dB] [off] Capture [off]
Simple mixer control 'Line Out',0
  Capabilities: pvolume pvolume-joined pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 31 [100%] [0.00dB] [on]
  Front Right: Playback 31 [100%] [0.00dB] [on]
Simple mixer control 'Line Out Source',0
  Capabilities: penum
  Items: 'Stereo' 'Mono Differential'
  Item0: 'Mono Differential'
  Item1: 'Mono Differential'
Simple mixer control 'Mic1',0
  Capabilities: pvolume pvolume-joined pswitch cswitch
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: Playback 0 - 7
  Front Left: Playback 3 [43%] [0.00dB] [off] Capture [on]
  Front Right: Playback 3 [43%] [0.00dB] [off] Capture [on]
Simple mixer control 'Mic1 Boost',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 7
  Mono: 4 [57%] [33.00dB]
Simple mixer control 'Mic2',0
  Capabilities: pvolume pvolume-joined pswitch cswitch
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  

Bug#990820: DefaultErrnoRet not working with runc 1.0

[Shengjing Zhu]

Hi,

On Thu, Jul 8, 2021 at 7:12 PM Rodrigo Campos  wrote:
> runc 1.0 from debian repositories doesn't honor DefaultErrnoRet, that

It's expected. As I disable that in
https://salsa.debian.org/go-team/packages/runc/-/blob/experimental/debian/patches/0010-compatible-with-specs-go-1.0.2.41.g7413a7f.patch

The reason behind is just simple.
golang-github-opencontainers-specs-dev in Debian unstable is just at
version 1.0.2.41.g7413a7f-1, which don't support DefaultErrnoRet.
I plan to update the spec package after bullseye release, which is
planned at July 31. But if you really want to use this feature before
that day, I may update the spec package in experimental first.

-- 
Shengjing Zhu

Bug#990462: Bug#990319: unblock: intel-microcode/3.20210608.2

[Justin B Rye]

Paul Gevers wrote:
>> We could replace this with "See the instructions in the DSA (also in
>> the intel-microcode README.Debian)".  Mind you, it would be nice if
>> that README started with "TLDR: boot with dis_ucode_ldr"!
> 
> To get this straight, you only propose to replace the piece between
> brackets (inclusive) with that right? I think it's worth saying "you can
> recover".

Yes, though I was vaguely thinking that in the process of adding
markup we might reorganise the links, since we don't need full URLs in
the text.  Something like

   
 
 Intel CPU microcode issues
 
   The intel-microcode package
   currently in bullseye and buster-security (see https://www.debian.org/security/2021/dsa-4934;>DSA-4934-1)
   is known to contain two significant bugs. For some CoffeeLake CPUs this
   update https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/56;>may
   break network interfaces that use firmware-iwlwifi, and for some Skylake
   R0/D0 CPUs on systems using a very outdated firmware/BIOS, https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31;>the
   system may hang on boot.
 
 
   If you held back the update from DSA-4934-1 due to either of these
   issues, or do not have the security archive enabled, be aware that
   upgrading to the intel-microcode package in bullseye may
   cause your system to hang on boot or break iwlwifi. In that case, you
   can recover by disabling microcode loading on boot; see the
   instructions in the DSA, which are also in the intel-microcode
   README.Debian.
 
   

(When it says "currently in bullseye and buster-security", are there
plans for this to change?  If not, drop the "currently"; if so, we
have to remember to update the release notes when it happens.)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Shengjing Zhu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org, t...@security.debian.org

Please unblock package golang-1.15

[ Reason ]
Just received a pre-announcement[1] by Go upstream:

> We plan to issue Go 1.16.6 and Go 1.15.14 on Monday, July 12.
> These are minor releases that include security fixes to the standard library.

[1] https://groups.google.com/g/golang-announce/c/JvWG9FUUYT0/m/VK1iHZosAgAJ

Go upstream defines there levels for security issue, PUBLIC, PRIVATE, and 
URGENT.
This is level PRIVATE.

[ Impact ]

[ Tests ]

[ Risks ]

It's security fix to standard library. So it needs binNMU for all Go packages.
As it's near hard freeze, I'd like to ask whether to fix it before release or 
after.
I don't have preference FWIW.
CCed security team as well.

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

[ Other info ]

That's just pre-announcement by Go upstream. So I really don't have diff yet.

unblock golang-1.15/1.15.9-6

Bug#990824: debian/rules: Filter packages and platforms without build profiles

[Nicolas Boulenguez]

Source: u-boot
Severity: wishlist
Tags: patch

Hi.
This idea has been discussed since #979296, but the initial
implementation was incompatible with the way dpkg-buildpackage breaks
the command line given by its rules-file option.
>From 4852e3a3e00246413d8e38667b7b5d67fadefc50 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 8 Jul 2021 17:11:19 +0200
Subject: [PATCH] debian/rules: Filter packages and platforms without build
 profiles

This idea has been discussed since #979296, but the initial
implementation was incompatible with dpkg-buildpackage.

All three variants should now work:

debian/rules package_filter=u-boot/%rockchip/%sunxi platform_filter=%-rk3399/a64-olinuxino%
dpkg-buildpackage '--rules-file=debian/rules package_filter=...'
sbuild '--debbuildopt=--rules-file=debian/rules package_filter=...'
---
 debian/rules | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/debian/rules b/debian/rules
index 244956f6cc..e14e2cafb3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,22 +28,20 @@ notools := $(filter pkg.uboot.notools,$(DEB_BUILD_PROFILES))
 
 subarchs := $(shell dh_listpackages --arch --no-package=u-boot-tools)
 
-# Each .deb P in subarch contains $(P_platforms).
-# These profiles remove values from $(P_platforms) for debugging.
-
-# DEB_BUILD_PROFILES='pkg.uboot.subarch.P1 pkg.uboot.subarch.P2'
-# removes all platforms but in packages u-boot-P1 u-boot-P2.
-only_subarchs := $(patsubst pkg.uboot.subarch.%,u-boot-%,\
-   $(filter pkg.uboot.subarch.%,$(DEB_BUILD_PROFILES)))
+# For debugging purposes, some filters may restrict the actually built
+# platforms.  The expected contents are Make patterns (with at most
+# one % wildcard), separated by / (because spaces are difficult to
+# escape from dpkg-buildpackage --rules-file).
+#   package_filter=u-boot/%amlogic/%mvebu
+#   platform_filter=khadas-vim%
+
+only_subarchs := $(subst /, ,$(package_filter))
 ifneq (,$(only_subarchs))
   $(foreach pkg,$(filter-out $(only_subarchs),$(subarchs)),$(eval \
 $(pkg)_platforms :=))
 endif
 
-# DEB_BUILD_PROFILES='pkg.uboot.platform.P1 pkg.uboot.platform.P2'
-# removes all platforms but P1 P2.
-only_platforms := $(patsubst pkg.uboot.platform.%,%,\
-$(filter pkg.uboot.platform.%,$(DEB_BUILD_PROFILES)))
+only_platforms := $(subst /, ,$(platform_filter))
 ifneq (,$(only_platforms))
   $(foreach pkg,$(subarchs),$(eval \
 $(pkg)_platforms := $(filter $(only_platforms),$($(pkg)_platforms
-- 
2.30.2

Bug#990822: debian-policy: Please document version scheme for derivatives

[Benjamin Drung]

Package: debian-policy
Version: 4.5.1.0
Severity: wishlist

Hi,

Paragraph 5.6.12. Version describes the version parts epoch,
upstream_version, and debian_revision. But it does not describe how to
use the Debian revision in Debian itself and in derivatives like Ubuntu.

To make packages in derivatives work seamlessly with Debian, I propose
following scheme (which is used in Ubuntu, in-house, and by me
personally):

The derivative selects a name for using in the debian_revision (e.g.
Ubuntu uses "ubuntu", we use "ionos" in-house, and I use "bd" for
personal builds). Then following rules apply:

 * no change in the package version when using the source package
   unmodified (e.g. 1.2-3)

 * Add X to the Debian package version starting with X=1 and
   incrementing X on every new upload when the source package is
   modified (e.g. 1.2-3ubuntu1)

 * If the upstream version is not packaged for Debian yet, use
   0X as debian_revision with X=1 and incrementing X on
   every new upload (e.g. 1.3-0ubuntu1).

 * If the Debian package is backported to an older derivative and needs
   changes for it, add ~X to the debian_revision (e.g.
   1.2-3~bd1).

Is the Debian policy the correct place to document that?

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#990821: aptly fails to run if both gnupg2 and gnupg1 are installed

[Christoph Berg]

Package: aptly
Version: 1.4.0+ds1-4+b3
Severity: normal

As soon as gpg1 (package gnupg1) and gpgv (from gnupg 2) are
installed, aptly fails to run. I think aptly should "Conflicts:
gnupg1", but maybe there is a better fix.

$ aptly repo add stretch sl_5.02-1+b1_amd64.deb
panic: gpg and gpgv versions don't match [recovered]
panic: gpg and gpgv versions don't match

goroutine 1 [running]:
github.com/aptly-dev/aptly/cmd.Run.func1(0xc00039ff70)
github.com/aptly-dev/aptly/cmd/run.go:17 +0x10f
panic(0xe0f5c0, 0xc9c130)
runtime/panic.go:969 +0x1b9
github.com/aptly-dev/aptly/pgp.NewGpgVerifier(0x10df1c0, 0xc0004dca50, 0x3)
github.com/aptly-dev/aptly/pgp/gnupg.go:160 +0x191
github.com/aptly-dev/aptly/context.(*AptlyContext).GetVerifier(0xc0004ea000, 
0x0, 0x0)
github.com/aptly-dev/aptly/context/context.go:438 +0xb2
github.com/aptly-dev/aptly/cmd.aptlyRepoAdd(0xc0004d2d80, 0xc0004d8a20, 0x2, 
0x2, 0x10d5e80, 0xc0004e80e0)
github.com/aptly-dev/aptly/cmd/repo_add.go:23 +0x79
github.com/smira/commander.(*Command).Dispatch(0xc0004d2d80, 0xc0004d8a20, 0x2, 
0x2, 0xc00039fe10, 0x59e3da)
github.com/smira/commander/commands.go:305 +0x27e
github.com/smira/commander.(*Command).Dispatch(0xc0004d3c20, 0xc0004d8a10, 0x3, 
0x3, 0x4100b8, 0x30)
github.com/smira/commander/commands.go:283 +0x131
github.com/smira/commander.(*Command).Dispatch(0xc0004d5e60, 0xc0004d8a00, 0x4, 
0x4, 0xc0004e00e0, 0xc0004d8a00)
github.com/smira/commander/commands.go:283 +0x131
github.com/aptly-dev/aptly/cmd.Run(0xc0004d5e60, 0xc320b0, 0x4, 0x4, 
0xff01, 0x0)
github.com/aptly-dev/aptly/cmd/run.go:41 +0x21c
main.main()
github.com/aptly-dev/aptly/main.go:24 +0x13b

There is a switch to configure the gnupg version per repo, but it
doesn't have any effect:

aptly repo edit -gpg-provider=gpg1 stretch
aptly repo edit -gpg-provider=gpg2 stretch


$ gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.8.8
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/cbe/.gnupg
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
   CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

$ gpgv --version
gpgv (GnuPG) 2.2.27
libgcrypt 1.8.8
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ gpg1 --version
gpg (GnuPG) 1.4.23
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2



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

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

Versions of packages aptly depends on:
ii  bzip2 1.0.8-4
ii  gnupg 2.2.27-2
ii  gpgv  2.2.27-2
ii  libc6 2.31-12
ii  xz-utils  5.2.5-2

aptly recommends no packages.

Versions of packages aptly suggests:
ii  graphviz  2.42.2-5

-- no debconf information

Christoph

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

[Thorsten Glaser]

Andreas Tille dixit:

>So this seems to be an issue.  I'll go in uploading and will file an
>unblock request.

You can also file an unblock request for pre-approval before
uploading, that way you’ll know whether they’ll accept it.

On the other hand, time’s short…

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

Bug#990519: RFS: sentry-python/1.1.0-2 -- new version of Python SDK for Sentry.io

[Emmanuel Arias]

Hello, 

There's a new upstream release version (1.3.0).

Please consider package it. 

Cheers, 
eamanu

Bug#990232: python3-sentry-sdk: New upstream release 1.1.0

[Emmanuel Arias]

Hi, 

please see #990519

Cheers,
eamanu

Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4

[Paul Gevers]

Control: tags -1 confirmed moreinfo

Hi Aaron,

On 06-07-2021 04:23, Aaron M. Ucko wrote:
> [ Introduction / Reason ]
> I would like to issue a new ncbi-entrez-direct upload (patch attached)
> adjusting two wrapper scripts to account fully for their wrappees'
> repertoire of options, or at minimum acknowledging that NCBI's efetch
> accepts -docsum as shorthand for -format docsum for the sake of
> ncbi-blast+'s get_species_taxids script.
> (https://bugs.debian.org/990741 has more details.)

Assuming the upload happens shortly, please go ahead.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

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

[Andreas Tille]

Hi,

I can confirm the issue with the even simpler command

   youtube-dl 9k4SnovHRRM
   youtube-dl RiA7pTaAag0
   ... other single videos of this sequence

So this seems to be an issue.  I'll go in uploading and will file an
unblock request.

Kind regards

Andreas.

On Tue, Jul 06, 2021 at 07:09:57PM +, Thorsten Glaser wrote:
> found 987226 2021.02.10-2
> thanks
> 
> Andreas Tille dixit:
> 
> >Could you please give some example to reproduce the bug?  When asking
> 
> This is… indeed tricky… I tried a couple URLs but they work;
> I don’t have a viewing history though. The example from Mike’s
> bug still fails, though:
> 
> tglase@tglase-nb:/tmp $ youtube-dl -f 18 
> OLAK5uy_m3-t4xLGBOHujynldlI3w-3Qp0WU62EAo
> [youtube:tab] OLAK5uy_m3-t4xLGBOHujynldlI3w-3Qp0WU62EAo: Downloading webpage
> ERROR: Unable to extract yt initial data; please report this issue on 
> https://yt-dl.org/bug . Make sure you are using the latest version; see  
> https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with 
> the --verbose flag and include its complete output.
> 1|tglase@tglase-nb:/tmp $ Youtube-dl -f 18 
> OLAK5uy_m3-t4xLGBOHujynldlI3w-3Qp0WU62EAo
> [youtube:tab] OLAK5uy_m3-t4xLGBOHujynldlI3w-3Qp0WU62EAo: Downloading webpage
> [download] Downloading playlist: New Song
> [youtube:tab] playlist New Song: Downloading 11 videos
> [download] Downloading video 1 of 11
> [youtube] P8kTNCUzC1g: Downloading webpage
> [youtube] P8kTNCUzC1g: Downloading player 7acefd5d
> ^C
> ERROR: Interrupted by user
> 
> Second one (Youtube-dl with capital Y) is the upstream binary, patched
> to have python3 in the shebang, shown to prove they fixed it later on.
> I aborted it because I’m not interested in downloading that actually ☺
> 
> bye,
> //mirabilos
> -- 
> Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
> gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
> reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
>   (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
> 

-- 
http://fam-tille.de

Bug#990462: Bug#990319: unblock: intel-microcode/3.20210608.2

[Paul Gevers]

Hi Justin,

On 08-07-2021 07:20, Justin B Rye wrote:
>> (https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/56)
>> and some for Skylake R0/D0 CPUs on systems using a very outdated
>   
> Typo for "so"?

Yes, but I think "for some".

>> If you held back the update from DSA-4934-1 due to any of these two
>  
> "Either of these issues"
> 
>> issues or do not have the security archive enabled, be aware that
>> upgrading to the intel-firwmare package in bullseye may cause your
>  
> As above.
> 
>> system to hang on boot or break iwlwifi. In that case, you can recover by
>> disabling microcode loading on boot (as documented in README.Debian,
>> also available online at
>> https://salsa.debian.org/hmh/intel-microcode/-/blob/master/debian/README.Debian)
> 
> We could replace this with "See the instructions in the DSA (also in
> the intel-microcode README.Debian)".  Mind you, it would be nice if
> that README started with "TLDR: boot with dis_ucode_ldr"!

To get this straight, you only propose to replace the piece between
brackets (inclusive) with that right? I think it's worth saying "you can
recover".

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#915114: fontconfig-config: Unnecessary dependency on ucf

[Simon McVittie]

Control: tags -1 + patch

On Fri, 30 Nov 2018 at 16:17:25 +, Simon McVittie wrote:
> While investigating how to reduce the package list for a container in a
> Debian derivative, I found that fontconfig-config Depends on ucf but
> doesn't appear to need it.

Please consider this change for bookworm:
https://salsa.debian.org/freedesktop-team/fontconfig/-/merge_requests/8

Thanks,
smcv

Bug#990308: FTBFS on non-vanilla system, pthread detection

[Lisandro Damián Nicanor Pérez Meyer]

Hi Eduard! Sorry for the delay, I'm currently without a powerful-enough machine.

On Fri, 25 Jun 2021 at 06:18, Eduard Bloch  wrote:
>
> Package: qtcreator
> Version: 4.14.1-1
> Severity: important
> Tags: ftbfs
>
> Hi,
>
> see below, smells like missing -lpthread in the minimum linker flags of
> subsequent tests.

I think that was part of a previous testand I guess the issue is LLVM/Clang:

[snip]
> CMake Error at /usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake:699 
> (message):
>   The imported target "clangBasic" references the file
>
>  "/usr/lib/llvm-12/lib/libclangBasic.a"
>
>   but this file does not exist.  Possible reasons include:
>
>   * The file was deleted, renamed, or moved to another location.
>
>   * An install or uninstall procedure did not complete successfully.
>
>   * The installation package was faulty and contained
>
>  "/usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake"
>
>   but not all the files it references.


I don't know if creator is ready for llvm 12, but I'm pretty sure we
will find out as soon as bullseye is released.

Thanks for the bug report, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#990718: RFS: duma/2.5.21-1 [ITA] -- Detect Unintended Memory Access - A Red-Zone memory allocator

[Peter]

 duma (2.5.21-1) unstable; urgency=medium
 .
   * Adopt package. (Closes: #565925)
   * New Upstream Release. (Closes: #550660, #623495, #655892)
   * Fixes FTBFS with GCC-11  (#984041)
   * Use hardening flags, fixes bindnow, (Closes: #532483)
   * Use changelog file date instead of system date for build date
   * DEP-5 copyright
   * Add autopkgtests
   * Preserve Debian's CFLAGS etc (use += , not just = , in makefile)


I have dropped the patch from bug #532483 as Ubuntu dropped it in Focal Fossa.


Regards,
Peter Blackman

Bug#990202: u-boot: [debian/rules] Make more settings explicit in build logs

[Nicolas Boulenguez]

Source: u-boot
Followup-For: Bug #990202

Hello.
You are right that the UBOOTVERSION stuff is unrelated with this bug.
Actually, it is not even specific to Debian.
Instead of doing anything at the Debian level for now, I suggest to
forward the attached second patch to upstream maintainers and see what
happens.
>From b46f4e7e399b3eceb823db6ef75af132fe516ef6 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 8 Jul 2021 12:36:14 +0200
Subject: [PATCH] debian/rules: Replace exports with assignments visible in
 build logs

Set build parameters via the Make command line instead of the
environment.

Improve separation of concerns in debian/rules with a common_make_args
variable.
---
 debian/rules | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/debian/rules b/debian/rules
index 244956f6cc..7b012abbf9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,7 +2,9 @@
 
 include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/pkg-info.mk
-export DEBIAN_REVISION ?= $(shell echo $(DEB_VERSION) | sed -e 's,.*+dfsg,+dfsg,')
+
+DEBIAN_REVISION ?= $(shell echo $(DEB_VERSION) | sed -e 's,.*+dfsg,+dfsg,')
+common_make_args += DEBIAN_REVISION='$(DEBIAN_REVISION)'
 
 include debian/targets.mk
 
@@ -17,6 +19,7 @@ VERBOSE=0
 else
 VERBOSE=1
 endif
+common_make_args += V=$(VERBOSE)
 
 # the upstream build passes LDFLAGS directly to ld instead of calling gcc for
 # linking; so instead of passing -Wl,foo in LDFLAGS as in automake builds, one
@@ -50,7 +53,8 @@ ifneq (,$(only_platforms))
 endif
 
 # Enable debugging symbols and remove build paths
-export HOSTCFLAGS = -g -ffile-prefix-map=$(CURDIR)=.
+HOSTCFLAGS = -g -ffile-prefix-map=$(CURDIR)=.
+common_make_args += HOSTCFLAGS='$(HOSTCFLAGS)'
 
 %:
 	dh $@
@@ -76,12 +80,14 @@ define build_template
 	# debian/rules: building platform: $(platform)
 	mkdir -p debian/build/$(platform)
 
-	dh_auto_build -- V=$(VERBOSE) O=debian/build/$(platform) \
+	dh_auto_build -- $(common_make_args) \
+	  O=debian/build/$(platform) \
 	  CROSS_COMPILE=$(or $($(platform)_CROSS_COMPILE),$(CROSS_COMPILE)) \
 	  $($(package)_assigns) $($(platform)_assigns) \
 	  $(platform)_defconfig
 	sed -i 's,CONFIG_FIT_SIGNATURE=y,# CONFIG_FIT_SIGNATURE is not set,' debian/build/$(platform)/.config
-	dh_auto_build -- V=$(VERBOSE) O=debian/build/$(platform) \
+	dh_auto_build -- $(common_make_args) \
+	  O=debian/build/$(platform) \
 	  CROSS_COMPILE=$(or $($(platform)_CROSS_COMPILE),$(CROSS_COMPILE)) \
 	  $($(package)_assigns) $($(platform)_assigns)
 
@@ -106,10 +112,14 @@ $(foreach package, u-boot-qemu $(subarchs),\
 
 TOOLSDIR := debian/build/tools
 build-tools:
-	dh_auto_build -- V=$(VERBOSE) O=$(TOOLSDIR) CROSS_COMPILE=$(CROSS_COMPILE) tools-only_defconfig
+	dh_auto_build -- $(common_make_args) \
+	  O=$(TOOLSDIR) \
+	  CROSS_COMPILE=$(CROSS_COMPILE) \
+	  tools-only_defconfig
 	cp $(TOOLSDIR)/.config $(TOOLSDIR)/config
 	# board-independent tools
-	dh_auto_build -- V=$(VERBOSE) O=$(TOOLSDIR) \
+	dh_auto_build -- $(common_make_args) \
+		O=$(TOOLSDIR) \
 		CROSS_COMPILE=$(CROSS_COMPILE) \
 		CROSS_BUILD_TOOLS=$(cross_build_tools) \
 		NO_SDL=1 \
-- 
2.30.2

Description: allow a downstream suffix in the version show during boot
  It may be convenient for redistributors or people compiling locally
  to add a revision number to the U-boot version, which is displayed
  at boot and can be helpful to determine which specific version is
  used.
Author: Vagrant Cascadian 
Author: Nicolas Boulenguez 

Signed-By: Nicolas Boulenguez 

--- a/Makefile
+++ b/Makefile
@@ -447,7 +447,7 @@
 
 # Read UBOOTRELEASE from include/config/uboot.release (if it exists)
 UBOOTRELEASE = $(shell cat include/config/uboot.release 2> /dev/null)
-UBOOTVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
+UBOOTVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)$(BUILD_VERSION)
 
 export VERSION PATCHLEVEL SUBLEVEL UBOOTRELEASE UBOOTVERSION
 export ARCH CPU BOARD VENDOR SOC CPUDIR BOARDDIR
--- a/doc/build/gcc.rst
+++ b/doc/build/gcc.rst
@@ -118,6 +118,11 @@
 * O= - generate all output files in directory , including .config
 * V=1 - verbose build
 
+If you are modifying the upstream sources, please make this visible
+at boot time by defining the BUILD_VERSION version suffix.
+
+* BUILD_VERSION=+<...>
+
 Other build targets
 ~~~
 

Bug#990819: Does not work with gir1.2-ayatanaappindicator3-0.1 (under GNOME)

[Michael Biebl]

Package: virt-manager
Version: 1:3.2.0-3
Severity: normal

Hi,

I'm running GNOME with the gnome-shell-extension-appindicator installed.

virt-manager recommends gir1.2-ayatanaappindicator3-0.1 as first
alternative but having this package installed does not actually make
virt-manager show up in the systray.

Only after installing (the deprecated?) gir1.2-appindicator3-0.1, I get
a virt-manager icon in the systray.

Regards,
Michael



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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-gtk-3.0   3.24.24-4
ii  gir1.2-gtk-vnc-2.0   1.0.0-1
ii  gir1.2-gtksource-4   4.8.0-1
ii  gir1.2-libosinfo-1.0 1.8.0-1
ii  gir1.2-libvirt-glib-1.0  3.0.0-1
ii  gir1.2-vte-2.91  0.62.3-1
ii  python3  3.9.2-3
ii  python3-dbus 1.2.16-5
ii  python3-gi   3.38.0-2
ii  python3-gi-cairo 3.38.0-2
ii  python3-libvirt  7.0.0-2
ii  virtinst 1:3.2.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-appindicator3-0.1 0.4.92-8
ii  gir1.2-ayatanaappindicator3-0.1  0.5.5-3
ii  gir1.2-spiceclientglib-2.0   0.39-1
ii  gir1.2-spiceclientgtk-3.00.39-1
ii  libvirt-daemon-system7.0.0-3

Versions of packages virt-manager suggests:
ii  gir1.2-secret-1  0.20.4-2
ii  gnome-keyring3.36.0-1
pn  python3-guestfs  
ii  ssh-askpass  1:1.2.4.1-10+b1
ii  virt-viewer  7.0-2

Versions of packages virt-manager is related to:
ii  libvirt-clients  7.0.0-3
ii  libvirt-daemon   7.0.0-3
ii  libvirt0 7.0.0-3
ii  osinfo-db0.20210215-1

-- no debconf information

Bug#990570: unblock: slurm-wlm/20.11.7-1

[Paul Gevers]

Hi,

On 06-07-2021 13:03, Gennaro Oliva wrote:
>>>   [X] I reviewed all changes and I approve them
>>
>> All 6000 lines?
> 
> I had a quick review to the relevant changes contained in the attached
> patch.

I'm confused. This line doesn't sound like this is appropriate material
for an unblock. We want targeted fixes in bullseye right now, and a
"quick review" doesn't sound like you did the appropriate checking. To
be clear, you as the requestor of the unblock should make the judgement
call if the new version of the package follows the freeze rules [1,2]
and convince us of that. We don't have the bandwidth to do this
ourselves, we can only try do judge if you made the right call.

And to avoid more back and forth, if the new upstream doesn't meet the
freeze requirements, please revert the new upstream release (e.g. by
using a "+really" version number) and upload with only the CVE fix
backported to the version in bullseye.

Paul

[1] https://release.debian.org/bullseye/freeze_policy.html
[2] https://release.debian.org/bullseye/FAQ.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989540: unblock: git/1:2.32.0-1

[Paul Gevers]

Hi Jonathan,

On 26-06-2021 22:24, Paul Gevers wrote:
> Ping...

Ping again.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990818: rtags: flaky autopkgtest: regularly times out after 2:47 h

[Paul Gevers]

Source: rtags
Version: 2.38-3
Severity: serious
Tags: bulleye-ignore
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky timeout

Dear maintainer(s),

Your package has an autopkgtest, great. However, due to glibc reporting
a regression, I looked into the history of your autopkgtest [1] and I
noticed it fails regularly on ppc64el (and I spotted a similar failure
on i386). I copied some of the output at the bottom of this report. It
hits the autopkgtest time out after 2hours and 47 minutes. Successful
runs pass in a couple of minutes.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

[Release team member hat on: as we are so late in the freeze, I don't
want this bug to kick your package out of bulleye. Hence, the
bulleye-ignore tag.]

[1] https://ci.debian.net/packages/r/rtags/testing/ppc64el/

https://ci.debian.net/data/autopkgtest/testing/ppc64el/r/rtags/13432732/log.gz

autopkgtest [01:18:38]: test run-test: [---
= test session starts
==
platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0
-- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/build.A6f/src
collecting ... collected 14 items

tests/automated/test_misc.py::test_location[InlineConstructorWrongTarget] PASSED
tests/automated/test_misc.py::test_location[ClassTemplatesMultipleTU] PASSED
tests/automated/test_misc.py::test_location[OneTU] PASSED
tests/automated/test_misc.py::test_location[ClassTemplates] PASSED
tests/automated/test_misc.py::test_location[MetaPrograms] PASSED
tests/automated/test_misc.py::test_location[ForwardDeclaration] PASSED
tests/automated/test_misc.py::test_location[AnonymousUnion] PASSED
tests/automated/test_misc.py::test_location[FunctionTemplates] PASSED
tests/automated/test_misc.py::test_location[MultipleTU] PASSED
tests/automated/test_misc.py::test_location[FunctionPointerField] PASSED
tests/automated/test_misc.py::test_parse[Parsing] PASSED
tests/automated/test_misc.py::test_completion[Completion] PASSED
tests/automated/test_misc.py::test_output[PrintIncludePathOutput]
autopkgtest [04:05:18]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/build.A6f/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/build.A6f/src/debian/tests/run-test;
touch /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-stdout
/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-stderr;
/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/build.A6f/src/debian/tests/run-test 2>
>(tee -a /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-stderr >&2) >
>(tee -a /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-stdout);" (kind:
test)
autopkgtest [04:05:19]: test run-test: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990817: libxtensor-dev: trying to overwrite '/usr/include/xtensor/xaccessible.hpp', which is also in package xtensor-dev:amd64 0.22.0-3

[Dmitry Shachnev]

Package: libxtensor-dev
Version: 0.22.0-4
Severity: serious
Justification: fails to install/upgrade

Dear Maintainer,

Updating xtensor packages fails with the following error:

  Unpacking libxtensor-dev:amd64 (0.22.0-4) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-iqY5kI/67-libxtensor-dev_0.22.0-4_amd64.deb (--unpack):
   trying to overwrite '/usr/include/xtensor/xaccessible.hpp', which is also in 
package xtensor-dev:amd64 0.22.0-3

Looks like forgotten Breaks/Replaces.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#746415: Changing LANG is not a solution

[Vincent Lefevre]

On 2020-06-06 13:49:31 +0100, graeme vetterlein wrote:
> Is this defect being addressed, It seems to have been important for 6 years?

I cannot reproduce this bug, even after setting LC_ALL=C in
/etc/default/locale. And it is tagged fixed-upstream.

So, what's the status of this bug?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#990816: python3-nosehtmloutput: nosetests3 --with-html fails with RuntimeWarning

[Enrique]

Package: python3-nosehtmloutput
Version: 0.0.5-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: cqu...@arcor.de

Dear Maintainer,

I have installed python3-nosehtmloutput package but it seems as if the plugin
has a problem and it is not possible to use the --with-html option of
nosetests3  that would activate the plugin:

$ nosetests3 --with-html
/usr/lib/python3/dist-packages/nose/plugins/manager.py:394: RuntimeWarning:
Unable to load plugin html-output = htmloutput.htmloutput:HtmlOutput: No module
named 'version'
  warn("Unable to load plugin %s: %s" % (ep, e),
Usage: nosetests3 [options]

nosetests3: error: no such option: --with-html

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 python3-nosehtmloutput depends on:
ii  python3   3.9.2-3
ii  python3-nose  1.3.7-7

python3-nosehtmloutput recommends no packages.

python3-nosehtmloutput suggests no packages.

Bug#990678: budgie-desktop: Software windows don't display correctly, move badly or stay on the screen after being shut

[Pascal]

Package: budgie-desktop
Version: 10.5.2-3
Followup-For: Bug #990678
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer,

Thanks for your response and your advice. I turned off window animations in
budgie desktop settings and now all is OK with MPV. Even the horizontal defect
(~10% of the ~top screen for a fraction of a second at the beginning of
fullscreen display) has disappeared. And this (minor) defect is present also in
Gnome. When I say Gnome I mean regular Gnome, with Xorg, not Wayland which,
though it has improved a lot since Debian 11, is still a little awkward to use
I think. In Debian 10, some applications couldn't even be used in Gnome
Wayland.
As this window display problem has disappeared in MPV, where it was permanent,
the other applications should work fine too everytime.

As for Mutter, I checked the package page & bugs. There doesn't seem to have
been recent bug reports. I gathered that this question of X11 vs Wayland is no
picnic, and I understand that we'll have to wait that the developers go to the
end of it.
But if a bug has to be reported to Mutter maintainers about our problem, please
do it because I don't master this subject at all.

Again thanks for your quick responses and I wish you all the best for polishing
that jewel of a desktop that Budgie is. Simple yet powerful, all that I like.
Long ago I lost my tool bar/panel, it happened very unexpectedly and looked
like a bug (No data damage whatsoever). Well it took me very little time to
recreate a panel and get things back to normal. That's a good sign of the
easiness and efficiency of that desktop.

Cordially,
Pascal.

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages budgie-desktop depends on:
ii  budgie-core  10.5.2-3
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-budgie-1.010.5.2-3
ii  gnome-control-center 1:3.38.4-1
ii  gnome-menus  3.36.0-1
ii  network-manager-gnome1.20.0-3

Versions of packages budgie-desktop recommends:
ii  budgie-desktop-view  1.1.1-1

Versions of packages budgie-desktop suggests:
ii  gnome-terminal  3.38.3-1
ii  nautilus3.38.2-1
pn  slick-greeter   

Bug#990815: ruby2.7: CVE-2021-31799 CVE-2021-31810 CVE-2021-32066

[Moritz Mühlenhoff]

Source: ruby2.7
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for ruby2.7.

CVE-2021-31799[0]:
A command injection vulnerability in RDoc

https://www.ruby-lang.org/en/news/2021/05/02/os-command-injection-in-rdoc/
https://github.com/ruby/ruby/commit/483f303d02e768b69e476e0b9be4ab2f26389522 
(2.7)


CVE-2021-31810[1]:
Trusting FTP PASV responses vulnerability in Net::FTP

https://www.ruby-lang.org/en/news/2021/07/07/trusting-pasv-responses-in-net-ftp/
https://github.com/ruby/ruby/commit/3ca1399150ed4eacfd2fe1ee251b966f8d1ee469 
(2.7)


CVE-2021-32066[2]:
A StartTLS stripping vulnerability in Net::IMAP

https://www.ruby-lang.org/en/news/2021/07/07/starttls-stripping-in-net-imap/
https://github.com/ruby/ruby/commit/a21a3b7d23704a01d34bd79d09dc37897e00922a 
(2.7)


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-31799
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31799
[1] https://security-tracker.debian.org/tracker/CVE-2021-31810
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31810
[2] https://security-tracker.debian.org/tracker/CVE-2021-32066
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32066

Please adjust the affected versions in the BTS as needed.

Bug#990814: krita: desktop file defines invalid MIME type jpeg/jfif

[arne anka]

Package: krita
Version: 1:4.4.2+dfsg-1
Severity: minor

Dear Maintainer,

while installing a package yesterday I got the error message:

Error in file "/usr/share/applications/krita_jpeg.desktop": "jpeg/jfif" is an 
invalid MIME type ("jpeg" is an unregistered media type)

the offending line would be

MimeType=image/jpeg;jpeg/jfif

w/o further research, I presume it should be

MimeType=image/jpeg;image/jfif

if at all.

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

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

Versions of packages krita depends on:
ii  krita-data1:4.4.2+dfsg-1
ii  libc6 2.31-13
ii  libexiv2-27   0.27.3-3
ii  libfftw3-double3  3.3.8-2
ii  libgcc-s1 10.2.1-6
ii  libgif7   5.1.9-2
ii  libgsl25  2.6+dfsg-2
ii  libheif1  1.11.0-1
ii  libilmbase25  2.5.4-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  libkf5completion5 5.78.0-3
ii  libkf5configcore5 5.78.0-4
ii  libkf5configgui5  5.78.0-4
ii  libkf5coreaddons5 5.78.0-4
ii  libkf5crash5  5.78.0-3
ii  libkf5guiaddons5  5.78.0-3
ii  libkf5i18n5   5.78.0-2
ii  libkf5itemviews5  5.78.0-2
ii  libkf5widgetsaddons5  5.78.0-2
ii  libkf5windowsystem5   5.78.0-2
ii  liblcms2-22.12~rc1-2
ii  libopencolorio1v5 1.1.1~dfsg0-7
ii  libopenexr25  2.5.4-2
ii  libopenjp2-7  2.4.0-3
ii  libpng16-16   1.6.37-3
ii  libpoppler-qt5-1  20.09.0-3.1
ii  libpython3.9  3.9.2-1
ii  libqt5concurrent5 5.15.2+dfsg-9
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5dbus5   5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5multimedia5 5.15.2-3
ii  libqt5network55.15.2+dfsg-9
ii  libqt5printsupport5   5.15.2+dfsg-9
ii  libqt5qml55.15.2+dfsg-6
ii  libqt5quick5  5.15.2+dfsg-6
ii  libqt5quickwidgets5   5.15.2+dfsg-6
ii  libqt5svg55.15.2-3
ii  libqt5widgets55.15.2+dfsg-9
ii  libqt5x11extras5  5.15.2-2
ii  libqt5xml55.15.2+dfsg-9
ii  libquazip5-1  0.9.1-1
ii  libraw20  0.20.2-1
ii  libstdc++610.2.1-6
ii  libtiff5  4.2.0-1
ii  libx11-6  2:1.7.1-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages krita recommends:
pn  krita-gmic   
ii  python3-pyqt55.15.2+dfsg-3
ii  python3-sip  4.19.25+dfsg-1
ii  qml-module-qtmultimedia  5.15.2-3

Versions of packages krita suggests:
pn  colord  
ii  ffmpeg  10:4.4-dmo3
pn  krita-l10n  

-- no debconf information

Bug#987905: patch

[Bastian Germann]

tags 987905 patch

Bug#990783: espeakup: Russian in debian-installer seems incomprehensible

[Philip Hands]

Samuel Thibault  writes:

> Control: reassign -1 espeak-ng
>
> Hello,
>
> Philip Hands, le mer. 07 juil. 2021 12:25:02 +0200, a ecrit:
>> I'm not sure if this is an issue with espeakup or perhaps espeak-ng-data-udeb
>> (which is at version 1.50+dfsg-7) -- please reassign as you see fit.
>
> espeak-ng -v ru "Выберите местонахождение"
>
> seems to be producing the same output, so reassigning to espeak-ng.
>
>> I'm not a Russian speaker myself, but having asked someone who is to listen 
>> to
>> this they report that they are unable to understand the audio even when the 
>> text
>> that is supposedly being read is in front of them.
>
> Hum, that's bad. Does it help if we slow the speed down? E.g.
>
> espeak-ng -s 100 -v ru "Выберите местонахождение"

I guess we need a native Russian speaker to have a listen.

The person I asked is fluent but not native and suspects that someone
who's familiar with the synthesised voice, and a native, might have a
better time with it.

She has the impression that the phonemes are all being given an equal
amount of time/emphasis when they should get varying emphasis (or
something like that) and that is making it very hard to understand.

> Possibly it's just the default speed which is bad for russian. Trying
> translate.google.com, it seems that -s 100 provides the same kind of
> speed.

I note that changing the speed settings in english seems to make rather
more difference to the outcome than is seems to in russian, but perhaps
that's just because I can follow what's going on in english.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#990813: Acknowledgement (Regressions in ledger 3.2.1 (upgrading from buster to bullseye))

[Martin Michlmayr]

And one more to revert:

commit 869302ae9ce303b532fa4700f78d208c3bd89310
Author: John Wiegley 
Date:   Thu May 7 21:22:20 2020 -0700

Revert "Correction to the way parens are parsed in query expressions"

This reverts commit 49b07a1c19489547b859d61fbc5c240aff224dda.

Bug#990426: www.debian.org: Clarify status of list of old TC decisions

[Raphael Hertzog]

Hi,

On Mon, 28 Jun 2021, Sean Whitton wrote:
> -NB that decisions from before the 1st of April 2002 are not yet
> -recorded here.
> +NB that no decisions from before the 1st of April 2002 are yet recorded
> +here yet.

That wording doesn't seem correct for me. Maybe:
« Note that no decisions from before the 1st of April 2002 are recorded
here. »
or 
« Note that decisions from before the 1st of April 2002 have not been
recorded here. »

>  Formal nontechnical and procedural decisions
>  
> @@ -337,8 +337,8 @@ recorded here.
>  
>  
>  
> -NB that decisions from before the 31st of January 2002 are not yet
> -recorded here.
> +NB that no decisions from before the 31st of January 2002 are recorded 
> here
> +yet.

Same here.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#990813: Regressions in ledger 3.2.1 (upgrading from buster to bullseye)

[Martin Michlmayr]

Package: ledger
Version: 3.2.1-7
Severity: important

I just noticed a severe performance regression in ledger after
upgrading from buster to bullseye.

The change was already reverted upstream, see
https://github.com/ledger/ledger/issues/1907
and commit 7f78cadea4a2359f1f53ce9c0c66b6d3fafd81c4

And this reminds me that there was another important regression in
3.2.1 that got reverted later:
commit 1600ee1f64f659b151c1c873d478baa1bdab89f2

I suggest you apply both of these reverts to the Debian package.
I think these qualify as important fixes.

I can release 3.2.2 with these fixes if you want.  I should probably
do that anyway...

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#860027: ITP: elpa-page-break-lines -- Emacs mode to display ugly ^L page breaks as tidy horizontal lines

[Martin]

Control: retitle -1 ITP: elpa-page-break-lines -- Emacs mode to display ugly ^L 
page breaks as tidy horizontal lines

Package is in NEW now:
https://ftp-master.debian.org/new.html

Packaging repository is here:
https://salsa.debian.org/emacsen-team/elpa-page-break-lines

Bug#941217: pjsip show contacts displays double entries for each contact

[Bernhard Schmidt]

Hi,

> And when it will be updated? I see only bugged version 16.2.1 in> repository. 
> When it will be updated to 16.10.0?
The bullseye release (due on 22.7. I believe) will carry 16.16.1. This
version is also available in buster-backports.

Bernhard